《AI大模型应用开发实战从入门到精通共60篇》050、芯片视角：从GPU到NPU，大模型推理的硬件加速原理
050、芯片视角：从GPU到NPU，大模型推理的硬件加速原理
一、一个让我半夜惊醒的bug
去年冬天，我在调试一个7B模型的推理服务。模型加载完，第一次推理耗时12秒——这还算正常。但第二次推理，居然飙到了47秒。我盯着终端输出，CPU占用率不到30%，GPU利用率在0%和100%之间疯狂跳变，像心电图上濒死的心律失常。
我以为是显存碎片化，调了torch.cuda.empty_cache()，没用。我以为是CUDA kernel launch overhead，加了torch.cuda.synchronize()，也没用。最后用nsys profile抓了一轮，发现每次推理时，模型权重从HBM到SM的搬运时间占了总耗时的68%。
那一刻我意识到：大模型推理的瓶颈，从来不是算力，而是带宽。这个认知，直接改变了我对硬件加速的理解方式。
二、GPU的“偏科”问题
GPU是为并行计算设计的，但它的并行是“数据并行”——成千上万个线程同时执行相同的指令，处理不同的数据。这在CNN时代是完美的：卷积操作就是一堆乘加，数据复用率高，计算密度大。
但Transformer推理是另一回事。
以自注意力机制为例，Q @ K^T这一步，需要把整个序列的Q和K都搬进寄存器。假设序列长度是2048，hidden_dim是4096，单是这一步就需要搬运2048×4096×2×2字节（FP16）≈ 64MB的数据。而A100的HBM带宽是2TB/s，L1/L2 cache带宽是HBM的10倍以上——问题在于，这些数据在cache里根本待不住，每次推理都要重新从HBM搬。
这就是所谓的“memory-bound”场景。GPU的SM（Streaming Multiprocessor）单元在大部分时间里都在等数据，真正的计算单元利用率可能不到20%。我见过不少团队花大价钱买A100跑7B模型，结果吞吐量还不如优化后的T4——因为T4的HBM带宽虽然只有A100的1/3，但小模型对带宽的敏感度没那么高，而A100的SM空转浪费更严重。
别这样写代码：for i in range(num_layers): output = self.layers[i](output)——这种逐层串行推理，每层都要从HBM读一遍权重，带宽利用率极低。正确的做法是算子融合（Operator Fusion），把多个连续的矩阵乘和激活函数合并成一个kernel，减少中间结果的HBM读写。
三、NPU的“偏科”解法
NPU（Neural Processing Unit）的诞生，本质上是对GPU“偏科”的修正。GPU的SM是通用计算单元，能跑CUDA、OpenCL、甚至光线追踪。NPU则彻底放弃了通用性，把晶体管全部押注在矩阵乘法和数据搬运上。
以华为昇腾910B为例，它的核心是达芬奇架构的Cube Unit。每个Cube Unit包含16×16×16的MAC阵列，一次指令就能完成4096个乘加操作。更重要的是，Cube Unit旁边紧贴着Local Memory（类似GPU的Shared Memory），数据搬运路径被压缩到极致。
这里有个关键差异：GPU的HBM到SM的数据路径要经过L2 cache，而NPU的Cube Unit可以直接从Local Memory取数。Local Memory的带宽是HBM的5-10倍，延迟只有1/10。这意味着，对于Transformer中的矩阵乘，NPU能把数据搬运的开销降低一个数量级。
我在测试中对比过：同样跑LLaMA-7B，A100的HBM带宽利用率大约在60%-70%（已经算优化得不错了），而昇腾910B的带宽利用率能到85%以上。原因很简单——NPU的指令集里专门设计了“矩阵乘+数据预取”的融合指令，计算单元在算当前batch的时候，数据搬运单元已经在搬下一个batch了。这种“流水线重叠”在GPU上需要手动用CUDA streams实现，而在NPU上是硬件原生支持的。
这里踩过坑：在NPU上写推理代码，千万别用PyTorch的默认算子。昇腾的CANN（Compute Architecture for Neural Networks）提供了专门的算子库，比如matmul算子会默认开启数据预取。如果你用torch.bmm，CANN会fallback到通用实现，性能直接腰斩。我见过有人把GPU代码直接迁移到NPU，结果推理速度比GPU还慢——不是NPU不行，是算子没选对。
四、量化与稀疏：硬件视角的“降维打击”
硬件加速不只是芯片架构的事，算法层面的配合同样关键。这里说两个我实际验证过的方案。
INT4量化：很多人觉得量化就是精度换速度，但硬件视角完全不同。以英伟达的Turing架构为例，它的Tensor Core支持INT4的矩阵乘，理论算力是FP16的4倍。但实际收益不止于此——INT4的权重体积是FP16的1/4，意味着同样带宽下，数据搬运时间缩短到1/4。对于memory-bound的Transformer推理，这相当于把HBM带宽“虚拟”提升了4倍。
我在部署Qwen-7B时，用GPTQ做了4bit量化，推理速度从12 token/s提升到38 token/s。代价是困惑度（PPL）从5.2升到5.8——对于对话场景，这个损失几乎不可感知。但要注意，量化后的模型对硬件有要求：Turing架构以上的GPU才支持INT4 Tensor Core，老架构（如Pascal）只能走CUDA core模拟，速度反而更慢。
稀疏化：NPU对稀疏的支持比GPU激进得多。昇腾的Cube Unit支持2:4结构化稀疏——每4个权重中强制2个为0，硬件直接跳过零值的计算。这意味着，在保持模型结构不变的前提下，算力翻倍。我在测试中试过，对LLaMA-2-13B做2:4稀疏后，推理速度提升约1.8倍，精度损失在0.3%以内。
但稀疏化有个陷阱：不是所有层都适合稀疏。Attention层的QKV投影对精度敏感，稀疏后PPL会明显上升；而FFN层的中间层（gate_proj、up_proj）对稀疏容忍度很高。我建议的做法是：只对FFN层做稀疏，Attention层保持稠密。这样能在精度损失<0.1%的前提下，获得约1.4倍的加速。
五、部署时的“最后一公里”优化
硬件加速的最终效果，取决于软件栈的配合。这里分享三个我在实际部署中验证过的经验。
第一，内存池化。大模型推理时，显存分配和释放是高频操作。默认的cudaMalloc每次都要和驱动交互，开销极大。正确的做法是预分配一个内存池，推理时从池里取，推理完归还。PyTorch 2.0的torch.cuda.memory.CUDAPluggableAllocator可以自定义分配器，我写了一个简单的环形缓冲池，把显存分配耗时从平均120μs降到了3μs。
第二，batch size的“黄金分割点”。很多人以为batch越大吞吐越高，但实际不是线性关系。当batch size超过某个阈值时，显存带宽会被多个请求争抢，每个请求的延迟反而上升。我在A100上测过，对于7B模型，batch size=8时吞吐最高（约120 token/s），batch size=16时吞吐反而降到105 token/s。这个阈值和模型大小、显存带宽、算子实现都有关，建议用perf工具实际跑一轮找到最优值。
第三，CPU-GPU协同。推理不只是GPU的事。Tokenization、采样、后处理这些步骤在CPU上跑，如果CPU跟不上，GPU就会空等。我见过一个案例：GPU推理只用了50ms，但CPU的采样用了200ms，导致整体延迟250ms。解决方案是把采样也放到GPU上（用torch.multinomial），或者用多线程异步处理。我倾向于后者——CPU负责采样和tokenization，GPU负责推理，两者通过一个环形缓冲区异步通信，延迟从250ms降到了80ms。
六、个人经验性建议
别迷信硬件参数。TFLOPS再高，带宽跟不上就是白搭。选芯片时，先算一下“带宽利用率”——用实际推理的吞吐除以理论带宽，低于50%说明软件栈有问题，低于30%说明硬件选型错了。
NPU不是GPU的替代品。昇腾、寒武纪这些NPU在特定场景（如固定batch size、固定序列长度）下确实比GPU强，但灵活性差很多。如果你的模型经常变，或者需要支持动态shape，GPU仍然是更稳妥的选择。
量化是性价比最高的优化。花几万块买A100，不如花几天时间做INT4量化。后者带来的速度提升可能比换硬件还大，而且成本为零。
永远不要相信“开箱即用”。无论是GPU还是NPU，默认配置的性能通常只有理论峰值的30%-50%。花时间调优算子、内存管理、流水线，收益远超换硬件。
最后一条，也是最重要的一条：大模型推理的优化，本质上是“数据搬运”的优化。你写的每一行代码，都应该问自己：这行代码减少了多少数据搬运？如果答案是不确定，那它大概率是性能瓶颈。