去年有段时间我所在的团队接到一个让我连续失眠好几晚的任务把当时刚开源的一个百亿级大模型完整跑通到一批国产AI加速卡上不光要训练还要上线在线推理服务。接到任务的第一时间我脑子里浮现的全是算子不支持显存溢出驱动崩溃之类的问题清单。真踩进去才发现坑确实存在但不是按个数算的是按工程阶段算的——单卡适配、集群调度、推理优化、容错恢复每个环节都有它自己的暗坑。不过回头来看这段经历的价值恰恰在这里。越来越多的团队正在面临同样的选择在一线GPU供应紧张、成本高企的现实下国产AI加速芯片不再只是PPT上的概念而是要被拿来跑真实负载、承担真实业务的第二平台。这篇文章就是我基于这段部署实战写的工程笔记覆盖从单卡选型评估到十万卡量级集群管理的完整链路希望能给准备或正在做国产算力部署的工程师一份少走弯路的参考。1. 当第二梯队不再是备选算力选型背后的现实逻辑1.1 为什么我不得不认真对待国产AI芯片生态过去提到国产AI芯片很多工程师的反应是兼容性问题一堆性能差距明显能不用就不用。但这两年情况起了变化。供应链的现实压力让国产加速卡从备胎变成了常规选项尤其在互联网厂商和AI创业公司里基于国产芯片跑起来的训练任务和推理服务已经不再是试验性质而是正经的业务负载。我在评估阶段做过一个粗略统计在主流深度学习框架生态里常见模型结构的核心算子覆盖率已经能做到八九成GPT风格解码器、常规CNN、Embedding加Attention这些主干路径基本都能跑通。这意味着什么意味着对一个工程团队来说真正的成本不再是能不能跑而是能不能高效跑、稳定跑——这恰好是文档里最不会写、实战里最折磨人的部分。还有一个反直觉的点推理场景比训练场景更早达到可用状态。原因并不复杂推理负载相对固定算子路径窄模型结构一旦确定需要验证的组合就那么多训练则是动态图、反向传播、分布式通信全都要通任何一个环节的隐性缺陷都会被放大。所以如果你所在团队打算试水国产算力我建议从推理服务切入而不是一上来就挑战大规模训练。1.2 一个快速判断芯片可用性的十分钟检查法面对一款没接触过的国产加速卡怎么快速判断它能不能接活等到集成完再做完整测试肯定来不及我一般会在正式立项前用一套固定流程给芯片打分十分钟左右就能得出一个相当靠谱的结论。我总结的检查清单分六步每一步都有一个明确的通过标准步骤检查内容通过标准不通过的常见原因1驱动与固件nvidia-smi对应工具能正常输出设备信息系统内核版本不在支持列表2开发工具链官方示例能编译通过依赖库缺失、编译工具链不匹配3框架连通性PyTorch或对应框架能识别设备并分配显存框架补丁版本和芯片驱动不匹配4基础算子基准matmul、conv、attention等核心算子结果与CPU/GPU结果误差在容忍范围算子库有未实现的回退路径占位5模型前向验证跑通一个标准Transformer小模型输出shape和数值合理融合kernel在特定shape下崩溃6实际带宽测试实测显存带宽达到理论值的50%以上内存分配策略错误走入了慢速路径这里有个经验大多数不能用的卡其实不是硬件不行而是开发环境不完整。我遇到过不止一次芯片本身没问题但厂商给的容器镜像版本和宿主机内核不匹配导致驱动加载失败被误判为硬件有问题。所以检查环境时一定不要只按厂商文档装最新版要先确认自己目标集群的操作系统版本和内核版本在官方兼容列表里。2. 一张加速卡的适配工程算子、编译器与框架三件套2.1 算子层的真实状态不要上来就写算子拿到一款新芯片后团队里最容易出现的冲动是遇到不支持的算子立刻想自己写一个。我的建议恰恰相反——能不问芯片厂商要就别自己写能绕开就别硬碰。国产芯片生态这几年的进步比很多人想象中大主流模型的算子覆盖度已经不差真正缺的是边缘算子像某些新的归一化方式、特殊的RoPE变体、定制化的Attention Mask处理。我们当时有个例子印象很深模型里用到了一种非常新的门控激活函数芯片自带的算子库不认识报了一个fallback to CPU的警告。没有立刻写自定义算子而是先翻算子库文档发现可以用两个基础数学算子的组合替代实现——这种组合方案不要任何额外开发性能损失也只在2%左右远比自己写kernel划算。真正需要手写算子的场景一般集中在三类一是新的融合模式比如把QKV投影和旋转位置编码融合成一个kernel二是高性能Attention变体比如需要在kernel内部做memory-efficient的mask处理三是自定义量化逻辑。如果你确实要手写务必先确认芯片工具的profile功能是否完善没有profile工具做手写算子优化就是盲人摸象。2.2 从CUDA到类CUDA迁移成本的真相国内主流AI加速芯片的开发接口大多走类CUDA路线语法风格、执行模型都借鉴了成熟生态。但类CUDA不意味着兼容CUDA我在移植一段自定义kernel时踩过非常典型的坑。那段代码原本在主流GPU上运行良好逻辑是对一个二维张量做原子加操作。迁移到国产芯片后编译能过、运行能跑但结果就是不对——同样的输入跑两次得到两个不同的数值。排查了半天最后定位到问题出在原子操作语义该芯片的硬件并不保证全局内存上的原子操作在默认配置下是线程安全的必须在编译参数里显式开启某个选项或者改用shared memory先做局部归约再写回。这段经历给我的教训是迁移kernel时不能只对照函数名翻译代码要逐项核对硬件执行模型。重点检查这几处线程块的调度顺序是否与预期一致shared memory的容量和bank冲突行为原子操作是否有硬件级支持锁页内存、零拷贝内存是否真正的零拷贝另外还有编译参数层面的隐藏差异。同一段代码在主流GPU生态里加一个编译选项能自动展开循环优化在国产工具链上却可能是未定义行为。建议在项目初期就锁定一套稳定的编译参数组合不要频繁升级工具链版本否则排查问题时分不清是代码问题还是编译器行为变化。2.3 框架适配PyTorch之外的推理引擎选择模型能否跑起来归根结底看框架适配。国产芯片厂商通常会提供两种接入路径一是自己维护一个PyTorch分支或补丁二是提供独立的推理引擎。两条路各有取舍。训练阶段基本没得选PyTorch生态是事实标准只能在厂商的PyTorch补丁上做文章。这里最需要注意的是版本锁定。厂商补丁往往只支持特定版本的PyTorch如果你项目里还有其他依赖强制要求更高版本就可能陷入依赖地狱。稳妥做法是把国产芯片的训练环境单独做成一个容器镜像固定在项目周期内不随便升级。推理阶段选择就多了这也是国产芯片目前做得相对好的环节。很多厂商提供了带OpenAI兼容API的推理服务上层业务不用改代码URL指过来就能用。我们的经验是优先选这种标准化方案不要自己从底层推理引擎开始搭。毕竟推理服务要操心的是并发管理、流式输出、超时熔断这些用现成引擎比自己造轮子省太多事。还有个容易忽略的关键点一个模型在训练框架里能跑通和在推理引擎里能达到生产性能完全是两码事。训练框架验证的是可计算推理引擎考核的是低延迟、高吞吐、能多并发。3. 十万卡级集群的隐形战场调度、互联与容错3.1 单卡到万卡的性能损失网络拓扑是第一个瓶颈单卡能跑的模型堆到集群上不意味着能训练更大的模型。AI集群的性能上限更多由互联而不是单卡算力决定。这个道理很多工程师都懂但真正规划大规模集群时还是会低估网络的影响。举一个直观的例子数据并行训练中每步迭代都需要做一次全局梯度同步这个同步操作耗时正比于模型参数量反比于节点间通信带宽。假设一个70B参数模型梯度同步至少需要传输140GB数据70亿参数每个参数梯度是2个字节的FP16。在400Gbps互联下理论传输耗时也要28秒——这个数字已经远超单步计算耗时了等于网络成了绝对瓶颈。这也是为什么大模型训练一定要上张量并行、流水线并行本质上就是把频繁全量同步转化为稀疏局部通信。所以规划集群时最该先确认的不是单卡FLOPS而是这三件事机内多卡互联带宽和拓扑全部走PCIe还是部分走直连跨机互联带宽是否支持RDMA是否配置了拥塞控制南北向带宽与东西向带宽的配比我们在实际部署中发现有些厂商的集群配置说明书写得天花乱坠实际跑起来却发现跨机通信走了虚拟化转发路径延迟比预期高出一个数量级。这种问题靠看文档发现不了必须用集合通信基准工具实测。3.2 资源调度排队不是唯一的问题十万卡量级的集群任务调度根本不是排队那么简单。我遇到过最头疼的问题是资源碎片化一个大模型训练任务申请256张卡但集群里所有空闲卡分布在四个不同的交换域里每个域只有64张可用调度器无法满足需求任务就一直排队。看着资源利用率不高其实有大把卡闲着。解决思路一般是分级队列加配额管理把集群按拓扑域划分成几个resource pool每个pool内部有独立的调度约束训练任务绑定pool推理任务则可以跨pool弹性伸缩。比较关键的是要设计好优先级抢占的策略训练任务通常有明确的检查点重启成本推理任务的SLA又靠副本数保障两者混部在同一批机器上时应该给推理服务更高的优先级还是给训练任务更高的资源保障需要根据业务线目标权衡。对于做AI基础设施的团队我会推荐采用binpack优先的策略做在线推理任务的调度把尽可能多的推理实例压缩到少量节点上留出整块的空闲节点给大规模训练任务。离线训练之间则采用spread策略避免多个训练任务在同一批节点上争抢网络带宽造成邻居噪音。3.3 容错设计训练挂了能重来推理挂了要兜底在万卡量级上硬件的概率性故障不是会不会发生而是什么时候发生的问题。我们观测到的数据是一次大训练任务跑几周中间大概率会遇到至少一次卡掉线或节点重启。训练侧的容错思路相对成熟周期性保存检查点一旦故障从检查点恢复。但这里有几个工程细节值得注意检查点不能只存一份要存到分布式文件系统而不是本地盘保存频率要根据故障概率和恢复成本平衡太频繁会拖慢训练太稀疏会增加失败后的回退量。推理侧的容错完全是另一套逻辑。在线服务不能等故障了再恢复必须做多副本部署和优雅降级。我们的做法是每个模型实例至少三副本分布在不同的容错域不同的机架或不同的电源域负载均衡层做健康检查单实例故障能在十秒内被摘除并补建。同时要预留一定的冗余额度——不要因为显存紧张就把所有卡都跑满负载适当留出5%~10%的空闲容量应对突发故障比事后紧急扩容可靠得多。4. 推理性能的真正瓶颈显存带宽、KV Cache与量化4.1 算力足够但QPS上不去问题出在哪里很多团队第一次把大模型部署到国产AI芯片上时都会困惑一个问题看算力TOPS明明不低为什么推理的每秒请求数QPS上不去原因在于大模型推理是一个访存密集型任务瓶颈往往是显存带宽而不是算力。用生活化的类比来解释你雇了一个手艺很好的厨师算力但厨房的备菜通道很窄显存带宽厨师再快也得等着原材料送到手边。自回归生成的时候每个Token的产出都依赖读取完整的模型权重和当前的KV Cache。假设模型是70B参数权重用FP16存储就有140GB每生成一个Token理论上要把这些权重全部读一遍。如果芯片的显存带宽是1TB/s那么每生成一个Token的理论耗时下限就是140ms换算下来每秒最多生成7个Token——这和芯片宣称的庞大算力几乎没有关系。这个估算方式对任何硬件平台都适用。选型时不要只看算力数字要直接看显存带宽这个指标再结合目标模型参数量算一下单Token延迟下限。如果目标场景是长文档总结这类大批量生成任务带宽比算力重要得多。4.2 KV Cache显存容量的隐藏黑洞除了带宽显存容量是推理服务的另一个硬约束。长上下文场景里KV Cache的显存占用会迅速吞噬可用空间一个128K上下文的对话请求KV Cache大小可能比模型权重本身还大好几倍。我们实测过一个32K上下文的场景70B模型权重占140GB但KV Cache峰值可以冲到384GB以上。如果芯片单卡显存只有64GB那就必须做多卡张量并行否则一个请求都放不下。这个环节最容易踩的坑是只按模型权重估算显存需求就上线扩容结果长请求一来直接OOM。应对手段主要有三一是限制最大上下文长度宁可截断也不无限放大缓存二是采用PagedAttention这类分页管理机制消除KV Cache的碎片浪费三是做prefill和decode分离——prefill阶段算力密集但对显存带宽要求低decode阶段正好相反把这两个阶段分别调度到不同配置的卡上能同时提升两块硬件的利用率。4.3 量化的真实收益和代价提到推理优化几乎所有人都会想到量化。FP16转INT8确实能把模型体积和带宽需求减半但在国产芯片上是否值得做需要先搞清楚硬件对低精度运算的支持程度。即便在成熟GPU生态里INT8加速也不是所有算子全覆盖的。国产芯片的量化支持往往更不均质有些算子能跑INT8且速度翻倍有些算子则根本没有INT8实现只能反量化回FP16计算然后再量化回去。这种部分加速模式下模型整体吞吐的提升可能只有百分之二三十远低于理论值。更麻烦的是精度问题。我们对一个量化后的模型做了逐层对比发现某些层在INT8路径下的数值误差明显偏大导致生成质量在长尾场景下退化——不是因为量化算法不行而是该芯片的INT8算子在特定输入分布下采用了不同的实现细节。所以我的建议是做量化之前务必先在目标芯片上做算子级精度审计别拿别的平台上的量化经验直接套用。如果目标是纯粹降低显存占用而不是追求加速可以先考虑FP8或者混合精度方案牺牲不那么明显。5. 部署中踩过的真实坑位三份问题记录5.1 同名算子不同精度同图不同结果的排查这是我们在国产芯片上遇到的第一个灵异事件。同一个模型代码在主流GPU上跑和国产芯片上跑加载相同的权重和输入输出结果明显不同——不是精度差异那种级别的不同而是完全对不上。排查过程走了很久弯路先怀疑权重加载逐字节对比没发现问题再怀疑框架版本统一容器镜像后依旧最后是把每一层的输出都dump出来和GPU端对照才定位到问题根源某个融合算子在这款芯片上自动走了低精度路径。它不报错不告警只是悄悄换了一种实现方式。解决方式说起来简单做起来繁琐——给这层算子强制指定精度路径。但这个案例的启示价值在于不同硬件平台上即使算子同名其结果也可能存在语义级差异。批量做模型迁移时一定不要只比对最终loss或最终输出要分层比对中间张量。把模型切成十段逐段对比输出分布能最快锁定问题算子。5.2 超参在第二生态上的敏感度变化把已经训练好的模型迁移到新芯片上做微调时一个容易犯的错误是沿用原来的全部训练超参。我们的体验是学习率、梯度裁剪阈值、batch size在国产芯片上往往需要重新扫描。原因有几个方面。一是数值范围差异不同芯片的浮点运算中间精度和处理舍入的策略不同前向计算得出的梯度分布会有些微差别积累起来就导致最优学习率偏移。二是通信库行为差异梯度同步时采用的压缩算法和Allreduce实现不同等价于隐式改变了有效batch size。三是混合精度策略差异某些芯片的FP16算子在累加时自动使用FP32中间值有些则直接在FP16上累加梯度量级因此不同。我的建议是换平台时不要追求一次到位先把学习率降到原来的三分之一左右跑几十步看loss曲线形态再稳步回升。不要相信同样的代码同样的超参这种说法底层实现差异决定了超参的可迁移性是有限的。5.3 可观测性集群必须有的三样东西跑大规模国产芯片集群我体会最深的一点就是可观测性比硬件本身性能更影响交付效率。因为没有成熟的生态工具积累出问题时调试手段有限只能在可观测性上做足功课。我们最后的标配是三件套。第一是实时监控面板覆盖卡利用率、显存占用、温度、互联带宽、集合通信耗时等核心指标时间粒度至少到秒级。对GPU集群的惯性认知是显存高就是热点但这个经验在国产芯片上并不总是成立——互联带宽饱和导致的集体卡顿比单卡显存OOM更常见且更容易被忽视。第二是结构化日志。所有训练和推理服务必须输出格式统一的日志包含时间戳、任务ID、设备ID、事件类型。听起来基础但大规模高并发下没有结构化日志就等同于没有排查能力事后回看全靠翻文本文件效率低到崩溃。第三是自动告警而且是按芯片特性调过阈值的告警。直接把以前平台上的告警规则搬过来会误报不断。比如某些国产卡的温度墙设置和主流GPU不同风扇策略更激进温度波动幅度大如果沿用旧的温度告警阈值半夜三点你会被无意义的告警轰炸。在这三件套落地之后我们处理集群故障的平均时间从小时级缩短到了分钟级这比任何单项性能优化带来的收益都大。部署结束之后的最后一点感想一个项目做完回头看最深的体会是国产AI芯片的部署问题本质上不是能不能用的问题而是怎么用才顺的问题。它需要工程团队调整预期——不是把它当成谁的替代品而是当成一个拥有自己特性的独立平台来适配。花时间把算子、编译器、框架、集群、推理、容错这条路完整走通一遍之后你会发现大多数不稳定其实都有明确的技术根源能被定位、被解决、被沉淀为团队自己的工程资产。如果让我给后来者一句建议从推理场景切入选一个接口标准化的推理服务方案先跑通一个真实业务再扩大规模。在这个过程里把可观测性和算子精度审计当成与业务交付同等重要的事项来做你会发现许多传闻中的坑其实远没有想象中那么可怕。