1. 云端推理芯片选型的底层逻辑1.1 为什么云端推理和训练是两套完全不同的选型逻辑很多刚接触AI基础设施的朋友会有一个惯性思维训练用什么卡推理就用什么卡。这个思路在2019年之前基本成立但放到今天如果你还按这个逻辑做选型预算至少浪费一半延迟还压不下来。训练和推理对芯片的要求本质上是两种不同的负载特征。训练是吞吐密集型它关心的是大规模矩阵乘法的持续算力、显存带宽、卡间互联带宽因为要反复做前向和反向传播梯度同步的开销非常大。推理是延迟敏感型它关心的是单次前向传播的响应时间、单位算力的成本、并发请求下的吞吐稳定性以及量化精度损失。我拿一个实际场景举例。你有一个70B参数的大模型训练阶段可能用几百张高带宽互联的卡跑几周这时候单卡算力峰值和互联带宽是核心指标。但到了线上推理用户请求是零散到达的你要的是在保证首token延迟低于某个阈值的前提下把每瓦特、每美元的token产出拉到最高。这时候一张训练卡跑推理算力利用率可能只有20%到30%剩下的算力全在等显存和调度。所以云端推理选型的第一原则是不要用训练卡的思维选推理卡。你要盯的是推理场景下的有效算力、显存容量与带宽的平衡、量化支持能力、以及软件栈的成熟度。1.2 云端推理的四个核心约束在展开具体芯片之前我先把云端推理的约束条件列清楚后面所有选型判断都围绕这四个维度展开。延迟约束。线上服务对首token延迟TTFT和每token输出延迟TPOT都有硬性要求。TTFT主要受prefill阶段算力影响TPOT受decode阶段显存带宽影响。这两个阶段的瓶颈不一样选型时要分开看。吞吐约束。单卡吞吐决定了你需要多少张卡来扛峰值QPS。吞吐又和batch size强相关大batch能摊薄权重加载开销但会推高延迟。这里有个权衡曲线后面会细讲。成本约束。云端推理的成本不只是卡的价格还包括整机功耗、机房散热、运维人力。我见过太多团队只看单卡算力价格比结果上线后发现电费和散热成本把预算吃掉了三成。生态约束。芯片再好如果框架支持不到位、算子库不全、量化工具链缺失落地周期会拉长到无法接受。这一条在国产芯片选型里尤其关键。1.3 主流云端推理芯片的全景对比目前云端推理市场大致分四个阵营国际通用GPU阵营、国产通用GPU/NPU阵营、FPGA阵营、以及专用ASIC阵营。我按标题里提到的几个关键词把赛灵思、寒武纪、昇腾这几个代表拉出来做个横向对比。芯片/平台架构类型典型推理精度显存/片上存储软件栈成熟度适用场景赛灵思 Alveo 系列FPGAINT8/INT4依赖板载DDR/HBM中等需要定制低延迟、可变batch、特定算子加速寒武纪 MLU 系列专用NPUINT8/INT16板载大显存中等偏上生态在补齐通用推理、国产化替代昇腾 310/910 系列NPUINT8/FP16HBM片上缓存较成熟CANN栈完整大模型推理、云端服务通用GPU国际SIMTINT8/FP16/FP8HBM最成熟全场景通用这张表只是入门级对比实际选型要细到具体型号。比如昇腾系列里310偏向边缘和轻量推理910系列才是云端大模型推理的主力。寒武纪的MLU370和MLU590定位也不同前者偏推理后者偏训练推理一体。赛灵思的FPGA在推理场景里更多是作为特定算子的加速器存在而不是通用推理主力。提示选型时不要只看峰值算力TOPS要看有效算力。厂商标称的INT8 TOPS往往是在理想条件下的理论值实际推理中受显存带宽、调度开销、算子融合程度影响能跑到50%就算不错。2. 昇腾NPU云端推理的实操拆解2.1 昇腾软件栈的整体结构昇腾的软件栈叫CANN全称是Compute Architecture for Neural Networks。它大致分四层最底层是驱动和固件往上是算子库和运行时再往上是图编译和优化层最上面是框架适配层。框架适配层支持PyTorch、TensorFlow、MindSpore等主流框架。你如果是从PyTorch迁过来的走torch_npu这个适配层大部分模型代码不用大改把device从cuda换成npu就行。但要注意不是所有算子都有NPU实现遇到不支持的算子会回退到CPU性能直接崩掉。图编译层是昇腾的核心竞争力之一。它会把你的模型图做算子融合、内存复用、流水线编排。这一步对推理性能影响极大我实测下来同一个模型经过图编译优化后端到端延迟能降30%到40%。2.2 从PyTorch模型到昇腾推理服务的完整链路我拿一个实际项目走一遍完整流程。假设你有一个基于Transformer的推理模型要部署到昇腾910上做云端服务。第一步是模型转换。昇腾支持两种路径一种是通过torch_npu直接在PyTorch里跑另一种是转成OM模型Offline Model用AscendCL推理。前者开发快后者性能好。生产环境我建议走OM路径。模型转换的核心工具是ATCAscend Tensor Compiler。你把PyTorch的pth或者ONNX模型喂给ATC它会输出一个om文件。这里有几个关键参数atc --modelmodel.onnx \ --framework5 \ --outputmodel_bs1 \ --soc_versionAscend910B \ --input_shapeinput_ids:1,512;attention_mask:1,512 \ --precision_modeallow_mix_precision \ --op_select_implmodehigh_precision--soc_version必须和你的实际芯片型号匹配填错了编译出来的模型跑不起来。--input_shape要固定batch size和序列长度昇腾的OM模型对动态shape支持有限动态batch需要额外配置。--precision_mode控制精度模式allow_mix_precision会混合使用FP16和FP32精度损失可控的情况下能明显提速。第二步是推理服务封装。昇腾提供了AscendCL的Python和C接口。Python接口开发快但性能有损耗C接口性能好但开发周期长。我一般用Python做原型验证用C做生产部署。第三步是性能调优。这里有几个关键手段算子融合、内存复用、流水线并行、动态batch。算子融合靠图编译自动做内存复用需要你在代码里显式管理流水线并行是把prefill和decode分到不同卡上动态batch是根据请求量动态调整batch size。2.3 量化在昇腾上的落地细节量化是推理降本的核心手段。昇腾支持INT8和INT4量化但量化不是无脑开的精度损失控制不好模型效果会崩。昇腾的量化工具叫AMCTAscend Model Compression Toolkit。它的流程是先做量化感知训练QAT或者训练后量化PTQ然后用ATC编译成量化模型。PTQ的流程相对简单你准备一个校准数据集跑一遍前向传播AMCT会统计各层的激活值分布自动计算量化scale。但PTQ对某些模型效果不好尤其是激活值分布长尾的模型。这时候就要上QAT在训练阶段就模拟量化误差让模型自己适应。我踩过的一个坑是校准数据集的分布必须和线上请求分布一致。有一次我用了一个通用语料做校准结果上线后发现特定领域的请求精度掉得厉害。后来换成线上真实请求采样做校准精度就回来了。注意量化后的模型一定要做端到端评测不能只看单层误差。有些层单看误差很小但误差累积到最后一层输出就完全不对了。2.4 昇腾系列GPU的常见误解澄清热搜词里有个问题是“昇腾系列有哪些GPU”。这里要澄清一个概念昇腾是NPU不是GPU。NPU和GPU在架构上有本质区别。GPU是SIMT架构大量线程并行执行相同指令NPU是专用架构针对神经网络算子做了硬件定制。这个区别带来的实际影响是NPU在标准神经网络算子上效率极高但遇到非标准算子或者动态控制流性能会掉得厉害。GPU则更通用什么算子都能跑但效率不一定最优。所以选型时如果你的模型结构比较标准NPU的性价比很高如果你的模型有大量自定义算子或者动态逻辑GPU更稳妥。3. 赛灵思FPGA在推理场景的定位3.1 FPGA做推理的优势和代价赛灵思的FPGA在云端推理里是一个特殊存在。它的核心优势是可编程性和低延迟。你可以把特定的算子硬化成电路延迟能压到纳秒级。而且FPGA的功耗通常比同算力的GPU低。但代价也很明显开发周期长、算子覆盖有限、生态不如GPU成熟。你用FPGA做推理基本等于要自己写硬件逻辑团队里得有懂RTL或者HLS的人。这对大多数AI团队来说门槛太高。所以FPGA在云端推理的典型场景是特定算子的加速比如推荐系统里的embedding lookup、或者金融风控里的低延迟推理。它不是通用推理的主力而是作为GPU/NPU的补充。3.2 赛灵思Alveo的推理部署路径如果你确实要用Alveo做推理大致路径是这样的先用Vitis AI或者FINN把模型量化并编译成FPGA bitstream然后用XRT运行时加载bitstream并执行推理。Vitis AI支持PyTorch和TensorFlow的模型导入但它对模型结构有要求不是所有模型都能直接编译。遇到不支持的层你要么换模型结构要么自己写HLS算子。我个人的经验是FPGA推理适合做长期稳定的特定负载。如果你的模型结构经常变FPGA的重新编译周期会让你很痛苦。但如果你的模型结构固定且对延迟极度敏感FPGA是很好的选择。4. 寒武纪MLU的推理落地实践4.1 寒武纪软件栈的现状寒武纪的软件栈叫Cambricon Neuware包含驱动、运行时、算子库、框架适配层。框架适配层支持PyTorch和TensorFlow通过cnrt和cnml接口对接。寒武纪的生态成熟度介于昇腾和赛灵思之间。它的算子库覆盖了主流神经网络算子但一些新算子或者自定义算子的支持不如昇腾及时。量化工具链也在补齐中。4.2 MLU推理的性能调优要点寒武纪MLU的推理调优核心是batch size选择和内存管理。MLU的片上存储有限大batch会导致频繁的片外访存性能反而下降。我实测下来MLU370在batch size为8到16时性价比最高。另一个要点是算子融合。寒武纪的编译器支持一定程度的算子融合但不如昇腾激进。你可以通过手动合并一些算子来提升性能比如把LayerNorm和后面的线性层合并。4.3 国产化替代场景下的选型建议如果你的项目有国产化要求寒武纪和昇腾都是可选方案。我的建议是先看软件栈成熟度再看算力。软件栈不成熟算力再高也发挥不出来。具体来说如果你的模型是标准Transformer结构昇腾的CANN栈更成熟落地更快。如果你的模型有较多自定义算子寒武纪的灵活性可能更好。但无论选哪个都要预留足够的适配时间国产芯片的算子适配往往比预期多花两到三周。5. 云端推理选型的常见问题与排查技巧5.1 延迟不达标的排查思路延迟不达标是最常见的问题。排查顺序应该是先看prefill还是decode慢再看是算力瓶颈还是显存瓶颈最后看是不是调度开销。如果是prefill慢通常是算力不够或者算子融合没做好。你可以尝试降低精度、增加算子融合、或者换更高算力的卡。如果是decode慢通常是显存带宽不够。你可以尝试减小batch size、用更激进的量化、或者换显存带宽更高的卡。5.2 精度损失的定位方法量化后精度损失定位方法是逐层对比。你把量化模型和原始模型的中间层输出都dump出来逐层算余弦相似度。哪一层相似度掉得厉害就重点看那一层。常见原因是激活值分布长尾或者某些层的量化scale选得不好。解决办法是换校准数据集、调整量化策略、或者对敏感层保留高精度。5.3 并发吞吐上不去的调优手段并发吞吐上不去先看是不是batch size太小。小batch下权重加载开销占比高吞吐自然上不去。你可以尝试增大batch size但要注意延迟会上升。另一个手段是请求调度优化。把prefill和decode分到不同实例上prefill用大batch跑decode用小batch跑这样能同时优化吞吐和延迟。5.4 常见问题速查表问题现象可能原因排查手段解决方向首token延迟高prefill算力不足看prefill阶段GPU/NPU利用率换高算力卡、降精度、算子融合每token延迟高decode显存带宽不足看显存带宽利用率减小batch、量化、换高带宽卡吞吐上不去batch size太小看权重加载开销占比增大batch、请求调度优化量化后精度崩校准数据分布不对逐层对比相似度换校准集、调整量化策略模型跑不起来算子不支持看回退日志换算子实现、换芯片提示排查问题时先确认瓶颈在哪个阶段再针对性调优。不要一上来就换卡很多时候是软件配置问题。6. 我个人在云端推理选型中的几点体会做了这么多项目我最大的体会是选型不是选最强的是选最合适的。一张卡算力再高如果软件栈不成熟、算子不支持、量化工具链缺失落地周期会拖到你怀疑人生。第二个体会是量化是推理降本的核心手段但量化不是免费的。你要花时间做校准、做评测、做精度补偿。这部分工作量往往被低估。第三个体会是国产芯片在快速进步但生态差距仍然存在。昇腾的CANN栈这两年进步很大寒武纪也在补齐工具链。如果你的项目有国产化要求尽早开始适配不要等到上线前才动手。最后分享一个小技巧做选型时先跑一个端到端的benchmark不要只看厂商标称数据。同一个模型在不同芯片上的实际表现可能和标称数据差很远。benchmark要覆盖你的真实请求分布、真实batch size、真实序列长度这样得出的结论才靠谱。
