MHD0815的博客

摘要：计算强度(FLOPs/Byte)是算法固有属性，描述每字节数据对应的计算量，与硬件无关。芯片算力(TOPS)决定性能上限，而实际性能受"带宽×计算强度"限制（Roofline模型）。低计算强度任务易受内存带宽制约，高计算强度任务则更依赖芯片算力。优化需区分瓶颈：访存受限时应提升带宽或优化数据复用，计算受限时需增强芯片算力。理解计算强度与芯片算力的关系，对模型优化和硬件选型至关重要。

本文介绍了五种常见数字签名算法的签名长度特性：1. RSA签名长度等于密钥长度（如2048位对应256字节）；2. ECDSA签名为曲线坐标位数的两倍（如P-256曲线为64字节）；3. EdDSA采用固定长度设计（Ed25519为64字节）；4. SM2国密算法类似ECDSA（P-256曲线64字节）；5. HMAC长度等于哈希输出（如SHA-256为32字节）。文章通过对比表格展示各算法的典型参数，并建议根据安全性、性能和兼容性需求选择签名长度，其中Ed25519等短签名适合资源受限场景，而更长密钥提供

AI 芯片算力精度”指的是：芯片在特定数值精度（如 FP16、INT8、INT4）下所能达到的计算吞吐能力（TOPS/TFLOPS）。它反映了“硬件对不同数据格式的加速能力”，是选型 AI 芯片时必须结合模型需求和部署场景来综合判断的关键指标。

大模型精度选择的核心是在模型效果与效率之间权衡：训练阶段必须使用FP16/BF16浮点精度保证收敛，而推理阶段可大幅降低精度。不同精度适用于不同场景：FP16用于高精度推理，INT8是主流推理选择，INT4则适用于超大规模模型部署。国产芯片普遍支持INT8/INT4推理，但训练仍需FP16/BF16。实际应用中，同一模型可转换为不同精度版本，70B级大模型通常需要INT4量化才能在消费级硬件上运行。关键是根据部署需求（性能/精度/功耗）选择合适的量化方案，而非特定模型固定使用某种精度。

《AI芯片算力浪费的根源与优化策略》 摘要：当前AI芯片面临严重的算力浪费问题，典型利用率仅20%左右，80%算力因"内存墙"瓶颈而闲置。根本原因在于计算单元增速(年增2-3倍)远超内存带宽提升(年增1.2-1.5倍)，导致芯片长期处于"等数据"状态。以昇腾910B为例，其256TFLOPS算力在运行Llama-2-7B模型时利用率不足10%。解决方案需三管齐下：1)通过量化、稀疏化降低访存量；2)采用HBM高带宽内存和片上缓存；3)优化算法提高计算强度。评估AI芯片

主流AI芯片计算精度对比与应用指南（2025） AI芯片的计算精度直接影响其性能与应用场景。目前主流精度包括FP64（科学计算）、FP32（传统训练）、FP16/BF16（大模型训练）、INT8/INT4（高效推理）和新兴FP8（下一代推理）。NVIDIA H100、华为昇腾910C和Google TPU v5e等旗舰芯片已全面支持BF16和INT8/INT4，其中H100还率先支持FP8。国产芯片如寒武纪MLU590和瀚博SV103主要聚焦INT8/INT4推理。选型建议：大模型训练首选BF16（H100

摘要： 生成ECC私钥需在指定曲线范围内（1到n-1）使用密码学安全随机数（CSPRNG）。NIST标准推荐两种方法：拒绝采样（无偏差，最安全）和模规约（适用于P-256等曲线）。代码示例（Python/OpenSSL/C）需结合硬件TRNG或安全模块（如HSM），并严格避免弱熵或可预测值。关键原则包括：使用CSPRNG、范围检查、抗侧信道及安全存储。禁止使用普通随机函数或时间戳生成私钥。生产环境必须依赖HSM或SoC的TRNG，确保私钥的随机性、范围合规性和存储安全性。

是的，AI 芯片的算力和内存带宽密切相关，正是因为：所有 AI 计算（包括卷积、矩阵乘、注意力）都必须先从内存读取大量数据才能运算；如果带宽不足，计算单元就会空转等待，导致高算力无法发挥——这就是“算力受带宽制约”的根本原因。

关键点说明计算需要数据没有数据，再强的算力也无用武之地数据来自内存必须通过总线从 DRAM/SRAM 读取带宽决定“喂料速度”带宽低 → 计算单元饥饿 → 实际性能低AI 尤其吃带宽因为模型大、参数多、计算强度低理想系统 = 算力与带宽匹配否则一方浪费🎯记住一句话“算力决定上限，带宽决定下限。—— 你能跑多快，不取决于引擎多强，而取决于油管有多粗。

摘要：算力与带宽的关系决定了AI芯片的实际性能。冯·诺依曼架构的"访存墙"导致数据搬运速度远慢于计算速度，AI计算中99%时间可能花在搬数据而非运算。算力与带宽需匹配，公式为：最小带宽=算力/计算强度。若带宽不足，算力利用率会骤降（如100TFLOPS芯片配4FLOPs/Byte模型需25TB/s带宽，但HBM3e仅1.2TB/s）。解决方案包括片上SRAM缓存、HBM堆叠内存及存内计算技术，但目前仍以高速缓存+HBM+软件优化为主。核心结论："算力决定上限，带宽决定下限&qu

模型计算强度 = 5 FLOPs/Byte” 表示每传输 1 字节数据可做 5 次浮点运算；在 1.6 TB/s 带宽下，每秒最多支撑 8 TFLOPS 的有效计算；相比 312 TFLOPS 的理论峰值，利用率仅 25.6% ——这意味着芯片确实大部分时间在“等数据”，这是 AI 芯片的常态，也是“内存墙”问题的直接体现。

全互联 = 任意两个计算节点之间都有直接、高带宽、低延迟的通信链路。对于N 个节点，需要N×(N−1)/2 条独立链路通信无瓶颈、延迟恒定、带宽对称硬件成本和复杂度随 N² 增长“全互联”不限于 8 卡，但 8 卡是当前单机物理全互联的工程上限。≤8 卡：可用 NVLink/NVSwitch 实现真正的物理全互联>8 卡：采用“8卡全互联节点 + 高速网络”的分层架构，在系统级提供近似全互联体验超大规模（如 Google TPU Pod）

FP32（单精度浮点数，Single-Precision）32-bit IEEE 754 单精度浮点结构（按 IEEE 754 标准）：1 位符号（Sign）8 位指数（Exponent）23 位尾数（Mantissa / Fraction）精度：约7 位十进制有效数字数值范围：约±1.2 × 10⁻³⁸ 到 ±3.4 × 10³⁸FP32 是“高精度标准格式”，FP16 是“为速度和效率牺牲部分精度的压缩格式”。在 AI 中，FP16（或 BF16）已成为训练和推理的主流。

摘要：TOPS（每秒万亿次操作）是衡量AI芯片算力的常用单位，但必须标明精度（如INT8、FP16）才有意义。不同精度的TOPS不能直接比较，例如INT8算力通常高于FP16，但实际性能取决于硬件设计和应用场景。建议关注精度类型、能效比（TOPS/W）和实测性能（如MLPerf基准），避免被峰值理论值误导。例如，某芯片INT8算力更高，但因内存和优化不足，实际吞吐可能更低。总结：脱离精度和实际负载的TOPS宣传缺乏参考价值。

AI芯片性能瓶颈分析：内存带宽是关键挑战 核心结论：在AI计算中，芯片访问外部存储（如HBM/DDR）的带宽是限制算力发挥的主要瓶颈，被称为"内存墙"。 关键发现： AI计算具有强访存特性，现代DRAM带宽难以匹配计算单元速度 大模型参数远超片上缓存容量（如Llama3需140GB），必须频繁访问外部存储 实测显示A100等芯片利用率常低于30%，主要因数据供给不足 行业应对方案： 增大片上缓存（如TPUv4的120MB） 采用HBM高带宽内存（1-3.5TB/s） 数据压缩和近存计算技

AI芯片算力本质上是执行矩阵/向量运算的能力，核心指标为TOPS和TFLOPS。算力不等于实际性能，需考虑内存带宽、软件优化等因素。主流AI芯片（2023-2025）如NVIDIA H100达1979TOPS，但实际利用率仅30%-70%。评估需综合算力、带宽、能效比和实际测试表现。

AI芯片性能的关键瓶颈在于外部内存带宽，而非计算能力本身。当前AI模型呈现"访存密集型"特征，计算单元常因等待数据而闲置。随着模型参数规模膨胀（如Llama-3达140GB），远超片上缓存容量，必须频繁访问高成本的外部DRAM。以NVIDIA A100为例，其理论算力利用率受1.6TB/s带宽限制，实际运行低计算强度模型时利用率可低于10%。芯片厂商通过大容量片上SRAM、HBM存储、数据压缩等技术缓解"内存墙"问题。对于绝大多数AI应用，尤其是推理场景，决定算力发挥

摘要： “全互联”（FullMesh）指任意计算节点间具备高带宽、低延迟的通信能力，其规模可从小型单机扩展至超大规模集群。单机层面，8卡（如NVIDIA DGX H100）是当前物理全互联的工程上限，受限于NVSwitch端口数、功耗及性价比。超大规模（如千卡级）通过分层架构实现：单机8卡NVLink全互联，机间采用InfiniBand/NVLink over Fabric等高速网络，逻辑上逼近全互联性能。Google TPUv4 Pod则通过定制3D Torus网络实现4096芯片全互联。实际应用中，“全

PCIe设备间支持P2P直连通信，但需满足硬件、固件和软件三方面条件。硬件需CPU/芯片组和PCIe交换器支持P2P，BIOS需开启相关设置，操作系统和驱动也要适配。消费级GPU通常禁用此功能，且PCIe P2P性能（128GB/s带宽）远低于NVLink（900GB/s）。常见限制包括ACS阻断、IOMMU隔离和带宽瓶颈。可通过nvidia-smi或NCCL测试验证P2P是否生效。该技术适合异构设备通信，但需注意配置调优。

摘要：NVIDIA通过专用NVLink+NVSwitch技术实现GPU全互联，相比传统PCIe方案具有显著优势。PCIe受限于树形拓扑结构，存在带宽共享、路径不对称等瓶颈，8卡系统跨CPU通信延迟翻倍、带宽减半。而NVLink提供900GB/s双向带宽，NVSwitch构建全连接网络，实现任意GPU间1跳直达、微秒级延迟，完全绕过CPU。专用互联协议相比通用PCIe在AI计算中效率更高，已成为高端AI芯片的标配方案。该技术对大规模GPU协同计算至关重要，是构建高效AI训练集群的关键基础。

摘要：OutboundATU与IOMMU虽然都涉及地址转换，但存在本质差异。OutboundATU专注于设备对外部资源的单向地址映射（如AXI转系统地址），适用于嵌入式系统、跨设备通信等场景，具有低延迟但无安全隔离功能。IOMMU则提供双向地址转换（IOVA↔HPA）及硬件级安全隔离，是虚拟化、RDMA等场景的核心组件，支持多级转换但开销较高。二者互补共存：OutboundATU解决设备访问问题，IOMMU确保访问安全性，在虚拟化等场景中IOMMU不可或缺。（149字）

无论是 SEND/RECV 双边操作，还是 WRITE/READ 单边操作，都必须通过 QP 提交工作请求（Work Request）。而 QP 的正确初始化与状态迁移，是 RDMA 通信能否成功的关键前提。：在《2.4 数据传输操作：RDMA Send/Recv与Read/Write》中，我们将深入四种核心操作的编程细节与性能对比。：能够独立编写代码完成 QP 初始化、状态迁移，并建立可靠的 RDMA 连接。RDMA QP 必须按严格顺序进行状态迁移，否则操作将失败。在 RDMA 编程中，

本文系统阐述了如何实现单个物理设备（如AI加速器、GPU等）的安全多租户共享方案。从硬件基础、软件架构到典型实现三个层面展开： 硬件层面要求设备支持SMMU/MMU、多任务队列、PASID等关键特性，实现地址空间隔离和资源分配。软件架构根据不同场景（裸金属/虚拟化）提供多种解决方案，包括SR-IOV、mdev和共享PF+PASID等模式，并详细说明其隔离机制。文章还列举了NVIDIA、Intel等厂商的典型产品实现方案。 核心目标是确保资源隔离、安全防护、公平调度和高效共享，为云原生AI和多租户平台提供基础

摘要：IOMMU（输入输出内存管理单元）为设备DMA访问提供了类似CPU MMU的虚拟内存管理能力。启用IOMMU后，设备使用IO虚拟地址(IOVA)而非物理地址，所有DMA请求需经IOMMU的地址转换和权限检查。IOMMU支持虚拟化直通、非连续内存映射和安全防护等关键功能，通过IOTLB、ATS和大页技术优化性能。其本质是将SDMA从直接访问升级为受管虚拟内存模式，实现了内存隔离、权限控制和虚拟化支持，是现代服务器和云平台不可或缺的安全基础设施。

摘要：SDMA（System Direct Memory Access）是PCIe设备直接访问主机内存的核心机制，使外设无需CPU干预即可高效读写系统RAM。其实现原理包括：设备作为主控发起DMA请求，通过PCIe Memory TLP访问主机物理地址；完整通路涉及驱动分配DMA安全内存、设备配置、地址转换（IOMMU）和中断通知等步骤；关键技术涵盖地址类型（HPA/IOVA）、TLP格式、缓存一致性和安全防护机制。SDMA广泛应用于GPU、网卡、NVMe等高性能场景，是现代异构计算的基础技术，需软硬件协同

本文深入探讨了RDMA中的内存注册与密钥机制。内存注册（Memory Registration）通过锁定物理页和生成访问密钥（lkey/rkey），在保证安全性的同时实现零拷贝数据传输。lkey用于本地操作，rkey用于远程访问，权限需严格管控以避免安全风险。内存注册开销较大（约110μs），建议采用预注册内存池策略而非频繁注册/注销。常见问题包括权限配置错误、密钥传递不当等，可通过内核日志和工具排查。该机制是RDMA高性能与安全访问的关键基础，需遵循最小权限和资源复用原则。

本章详细探讨了RDMA驱动中完成队列（CQ）的事件通知机制，重点分析了轮询与中断两种模式的实现原理及优化策略。CQ作为操作结果的报告载体，其核心功能包括结果反馈、事件通知和资源同步。轮询模式通过主动查询实现低延迟，适合高性能场景；中断模式通过被动通知节省CPU资源，适用于低频事件处理。驱动实现需考虑CQ溢出防护、多QP共享同步等关键问题，并提供事件通道机制将CQE传递给用户态。通过对比两种模式的优缺点及适用场景，揭示了RDMA系统在性能与资源间的权衡机制。

本文摘要： 本章详细讲解了如何从零开始开发一个最小化的RDMA驱动模块。主要内容包括：1) RDMA驱动架构概览，展示内核分层设计；2) 实现驱动骨架，注册虚拟HCA设备；3) 实现基础Verbs回调函数，支持ibv_devinfo查询；4) 实现CQ创建功能；5) 提供完整的Makefile和测试脚本；6) 介绍调试技巧。通过这个最小驱动示例，读者可以掌握RDMA驱动的核心开发技术，包括设备注册、回调机制和用户态交互原理。文章最后还提出了三个思考题，帮助读者深入理解驱动开发的关键问题。

摘要：本章详细介绍了RDMA驱动开发环境的搭建流程，包括Linux内核编译（开启InfiniBand支持）、OFED驱动安装策略和调试工具部署。重点讲解了如何配置内核选项启用RDMA功能，提供了OFED安装的实用建议以避免内核模块冲突，并介绍了KGDB、ftrace等调试工具的使用方法。最后通过一个简单的"Hello RDMA"内核模块验证了开发环境的正确性，为后续RDMA驱动开发奠定了基础。本章强调在开发过程中应合理选择OFED安装方式，并充分利用各种调试工具进行问题排查。

摘要：本章详细介绍了RDMA驱动开发环境的硬件搭建要求，重点推荐使用Mellanox ConnectX系列网卡，因其开源驱动、完善文档和社区支持。内容涵盖服务器配置（CPU/内存/BIOS设置）、固件版本管理、操作系统选择（推荐Ubuntu/Rocky Linux）、内核开发工具安装，以及推荐的直连网络拓扑结构。最后提供了硬件就绪验证步骤，强调驱动开发对环境的严格要求，为后续内核开发环境搭建奠定基础。

本文深入解析了RDMA数据传输的四种核心操作：双边操作SEND/RECV（类似Socket）和单边操作WRITE/READ（真正远程内存访问）。通过对比分析，WRITE延迟最低适合数据推送，READ延迟较高适合数据拉取，SEND/RECV适用于需确认场景。文章详细介绍了编程示例、性能对比（ConnectX-6Dx实测）、高级特性（内联数据/信号控制）及常见陷阱（如未预提交RECV导致hang）。最佳实践建议：小消息用内联+WRITE，批量操作用非signaled模式。RDMA通过灵活的原语组合，为高性能网络

本文摘要：RDMA编程的核心API——Verbs与libibverbs详解。Verbs是RDMA的标准编程接口，提供类似系统调用的原子操作，而libibverbs是其官方实现。文章系统介绍了Verbs的核心对象模型（设备、上下文、保护域、内存区域等）和典型编程流程（服务端初始化、客户端连接等）。重点讲解了资源管理、错误处理及API调用路径，为后续RDMA开发奠定基础。文中还包含编程陷阱提示和学习思考题，帮助深入理解RDMA编程机制。

摘要：RDMA技术从DMA发展而来，实现了远程内存直接访问的革命性突破。DMA仅支持单机内存访问，而RDMA通过创新语义（WRITE/READ单边操作）克服了传统网络通信的高延迟、CPU占用和带宽利用率问题。RDMA演进经历了InfiniBand、RoCE等关键阶段，延迟可降至1微秒以下，CPU占用几乎为零。这项技术将网络视为"内存扩展"，显著提升了分布式系统性能，为高性能计算和云基础设施提供了关键支持。

本文详细介绍了Mellanox RDMA网卡的配置与OFED安装流程。主要内容包括：1）硬件选型建议，推荐Mellanox ConnectX系列网卡；2）操作系统要求与OFED软件栈安装步骤；3）RDMA环境验证方法；4）常见问题解决方案；5）可选开发环境增强配置。通过本文指导，读者可完成完整的RDMA开发环境搭建，为后续驱动开发奠定基础。文中还提供了测试命令、故障排查技巧及思考题，帮助深入理解RDMA技术。

摘要：本文详细介绍了RDMA开发环境的搭建流程，涵盖单机回环和双机直连两种典型配置模式。主要内容包括：1）通过配置IP地址激活RoCE功能；2）使用ibv_rc_pingpong工具验证RDMA通信；3）关键网络优化参数调整（如DCQCN拥塞控制）；4）开发工具链准备及第一个RDMA程序"HelloRDMA"的编写与编译；5）调试工具的使用方法。文章为RDMA开发者提供了从环境搭建到基础开发的完整指导，特别强调了网络拓扑选择对实验效果的影响，并解答了常见配置问题。

RDMA三大核心技术解析：零拷贝、内核旁路和CPU卸载共同实现了微秒级延迟和近乎零CPU开销。零拷贝通过内存注册机制消除数据拷贝，内核旁路让应用直接与网卡交互，CPU卸载将网络处理任务交给网卡硬件。三者协同作用，使RDMA在延迟（1.2μs）、吞吐（95Gbps）和CPU占用（<1%）上远超传统TCP/IP网络。这些技术特别适合AI训练、分布式存储等高性能场景，通过端到端的优化架构彻底改变了网络通信模式。

本文系统梳理了NPU与主机CPU的连接方式及数据交互机制。硬件连接主要包括SoC片上集成（主流）、PCIe接口（独立加速卡）和USB/以太网（调试用）三种方式。软件层面通过设备树或PCIe枚举识别NPU设备，采用寄存器编程、共享内存、中断通知和命令队列等机制实现CPU-NPU协同。重点分析了SoC集成场景的数据流，并对比了不同连接方式对驱动设计的影响。理解这些连接特性对开发高效NPU驱动至关重要，需结合芯片手册和具体连接方式处理寄存器访问、中断管理和DMA等关键问题。

本文详细介绍了搭建Linux内核编译与NPU仿真平台的完整流程。主要内容包括：1）使用QEMU搭建ARM64仿真环境的必要性；2）配置交叉编译工具链；3）编译支持KGDB调试的Linux内核；4）构建最小根文件系统；5）通过修改设备树添加虚拟NPU设备；6）配置KGDB调试环境；7）引入开源Gemmini NPU IP作为参考。文章提供了从环境搭建到编写简单NPU驱动的完整实践指南，包含具体命令和配置方法，适用于希望学习NPU驱动开发的工程师。最后还给出了常用命令速查表，方便开发者快速参考使用。

本文快速回顾了Linux字符设备驱动的核心知识，重点针对NPU驱动开发需求。主要内容包括：1) 字符设备驱动框架file_operations及其关键函数；2) ioctl用户态控制接口的实现；3) mmap零拷贝数据传输技术；4) 设备树与platform driver模型；5) NPU特别关注的DMA内存分配与同步机制。文章强调NPU驱动开发中需要掌握的关键技术点，为后续实现真正的NPU驱动打下基础，适合有一定Linux基础的工程师快速复习相关知识点。

本文介绍了一个NPU驱动开发教程，从零开始实现基础通信功能。主要内容包括：1)定义模拟NPU寄存器布局；2)搭建platform driver和字符设备框架；3)实现probe函数初始化硬件资源；4)通过ioctl接口提交任务；5)更新设备树配置；6)编写用户态测试程序。该驱动支持寄存器映射、中断处理和基本任务提交，为后续开发奠定基础。文中还指出了当前实现的局限性，如缺乏DMA内存管理和并发保护，并预告后续将重点解决内存管理问题。本教程适合具备Linux驱动基础的开发者学习NPU驱动开发。