1. 大模型规模膨胀背后的真实困境过去两年我一直在做AI推理侧的系统优化和部署工作从最早在单卡上跑7B模型到后来折腾多卡推理、显存优化、算子融合再到最近帮几个团队做国产芯片的适配评估。说实话大模型参数量的增长速度远超大多数人的预期。2023年初大家还在讨论13B能不能跑在消费级显卡上到了2024年70B已经成了很多场景的起步门槛MoE架构的模型更是把总参数量推到了千亿甚至万亿级别。这个趋势带来的直接后果就是算力需求不再是线性增长而是指数级膨胀。训练侧还好说毕竟训练任务可以排队、可以切分、可以用时间换空间。但推理侧不一样推理是要面向真实用户的延迟、吞吐、并发每一个指标都卡得很死。你不可能让用户等三十秒才看到一个回答也不可能为了省算力就把模型量化到效果崩掉。这就引出了一个很现实的问题国内AI芯片到底能不能扛住这波大模型的压力我见过太多团队在选型时踩坑。有人只看纸面算力觉得某款芯片的TOPS数字很漂亮就下单了结果模型一部署发现算子不支持、显存带宽跟不上、多卡通信效率低得离谱。也有人迷信生态觉得只要兼容CUDA就万事大吉结果发现兼容层带来的性能损耗高达百分之三四十根本达不到业务要求。这些问题的根源其实不在于某一颗芯片本身不够强而在于整个技术栈没有形成协同。芯片、编译器、框架、算子库、模型结构、部署工具这六个环节但凡有一个掉链子整体性能就会大打折扣。我经常跟团队里的人说做AI芯片适配就像组一支篮球队不是把五个最强的球员堆在一起就能赢球关键是配合。所以当我看到“大模型规模膨胀时代国内AI芯片的胜负手在全栈协同”这个判断时我是深有同感的。这篇文章我想从一线实操的角度把全栈协同这件事拆开来讲清楚为什么它重要、难在哪里、怎么落地、有哪些坑可以提前避开。无论你是做芯片选型的架构师还是做模型部署的工程师或者只是对国产AI芯片生态感兴趣的技术人希望这些经验能帮你少走一些弯路。2. 全栈协同到底在协同什么2.1 从一颗芯片到一次推理请求的完整链路很多人理解AI芯片就是看它的算力峰值。但在实际部署中一颗芯片从接收到推理请求到返回结果中间要经过一条很长的链路。我把它拆成六个环节芯片硬件层包括计算单元、显存、片间互联、PCIe带宽等物理资源。驱动与运行时层负责资源调度、内存管理、任务分发。编译器与算子库层把高层算子映射到硬件指令决定实际执行效率。深度学习框架层PyTorch、TensorFlow等提供模型表达和自动微分能力。模型结构与算法层Transformer、MoE、注意力机制的具体实现。部署与服务层推理引擎、批处理策略、KV Cache管理、流式输出。这六层每一层都有自己的优化空间但真正的挑战在于层与层之间的接口。比如编译器生成的指令能不能充分利用硬件的矩阵计算单元框架的算子实现能不能匹配编译器的优化模式部署引擎的批处理策略能不能和芯片的显存带宽相匹配我举个具体的例子。某国产芯片的矩阵计算单元理论峰值是256 TFLOPS但在跑一个70B模型时实测只跑出了不到60 TFLOPS。排查下来发现问题出在算子库的注意力实现上它没有针对该芯片的显存层次结构做分块优化导致大量时间花在数据搬运上计算单元经常处于空闲状态。这就是典型的“硬件很强但软件没跟上”。2.2 为什么单点突破解决不了问题过去几年国内AI芯片的新闻很多今天这家发布新品明天那家宣布融资。但如果你真正做过部署就会发现一个残酷的现实纸面参数和实际性能之间的差距往往比想象中大得多。我整理过一个对比表是我们在实际项目中测试过的几款国产芯片在跑同一个70B模型时的表现芯片型号理论算力(FP16)实测吞吐(tokens/s)算力利用率主要瓶颈A芯片256 TFLOPS42018%算子库不完善B芯片200 TFLOPS38021%显存带宽不足C芯片300 TFLOPS51019%多卡通信效率低D芯片180 TFLOPS35022%编译器优化不足注意看最后一列没有一款芯片的算力利用率超过25%。这意味着超过四分之三的算力被浪费掉了。浪费在哪里不是硬件不行而是软件栈没有把硬件的潜力释放出来。这就是为什么我说单点突破解决不了问题。你把芯片的算力再翻一倍如果软件栈还是这个水平利用率可能反而更低。真正需要的是全栈协同优化芯片设计时就要考虑编译器的需求编译器要理解框架的算子模式框架要适配部署引擎的调度策略部署引擎要针对模型结构做专门优化。2.3 全栈协同的三个核心维度根据我的实操经验全栈协同可以归纳为三个核心维度第一个维度是纵向协同也就是从芯片到应用的自上而下打通。这要求芯片厂商不能只卖硬件还要提供完整的软件栈支持。我见过一些团队买了芯片之后发现连基本的PyTorch适配都没有要自己写算子、自己调驱动这个成本高得离谱。第二个维度是横向协同也就是不同组件之间的接口标准化。比如编译器的中间表示IR要能同时对接多种框架算子库要能同时支持多种芯片架构。这需要行业层面的标准推动但短期内更现实的做法是选择生态相对成熟的方案。第三个维度是动态协同也就是在运行时根据实际负载动态调整策略。比如根据请求的batch size动态选择最优的算子实现根据显存压力动态调整KV Cache的存储策略。这需要部署引擎和底层运行时之间有良好的反馈机制。实操心得在做芯片选型时不要只看芯片厂商提供的benchmark数据。一定要拿你自己的模型、你自己的数据、你自己的业务场景去实测。我见过太多“实验室性能”和“生产性能”差距巨大的案例。3. 芯片、编译器、框架的三角关系怎么理顺3.1 编译器被低估的关键环节在大模型部署的讨论中编译器往往是被忽视的一环。大家更关注芯片的算力、框架的功能、模型的效果但编译器才是把这三者连接起来的桥梁。我打个比方芯片是发动机框架是方向盘模型是目的地编译器就是变速箱。发动机再强如果变速箱匹配不好车也跑不快。国内AI芯片的编译器生态目前主要有三种模式自研编译器芯片厂商自己开发一套编译器针对自家硬件做深度优化。优点是优化程度高缺点是生态封闭迁移成本大。基于开源编译器二次开发比如基于TVM、MLIR等开源项目做定制。优点是生态相对开放缺点是优化深度可能不够。兼容主流编译器通过兼容CUDA或其他主流生态来降低迁移成本。优点是上手快缺点是性能损耗大。我们团队在多个项目中对比过这三种模式结论是短期看兼容模式最省事长期看自研模式最有潜力但中期最现实的是基于开源做深度定制。为什么这么说兼容模式的性能损耗通常在20%到40%之间对于延迟敏感的业务来说是不可接受的。自研模式虽然优化好但生态建设需要时间而且容易形成技术锁定。基于开源做定制既能利用社区的力量又能针对特定硬件做优化是目前比较平衡的选择。3.2 算子库决定实际性能的胜负手如果说编译器是变速箱那算子库就是发动机的燃油喷射系统。它决定了每一滴“算力燃油”能不能被充分燃烧。大模型的核心算子其实不多矩阵乘法、注意力、层归一化、激活函数、Softmax等。但就是这几个算子在不同芯片上的实现差异巨大。我以注意力算子为例。标准的注意力计算包括QK^T、Softmax、与V的乘法三个步骤。在GPU上通常会用FlashAttention这样的融合算子来减少显存访问。但在国产芯片上FlashAttention的适配往往是个大问题。我们曾经在一个项目上遇到过这样的情况某国产芯片的矩阵乘法算子性能很好但注意力算子没有做融合优化导致中间结果要反复写入显存再读出来显存带宽成了瓶颈。后来我们和芯片厂商的工程师一起针对该芯片的显存层次结构重新设计了分块策略把注意力算子的性能提升了将近两倍。这个经历让我深刻体会到算子库不是写完就完了而是要针对具体硬件做持续调优。而且这个调优不是一劳永逸的模型结构一变最优的算子实现可能就要跟着变。3.3 框架适配不只是“能跑就行”PyTorch目前是国内大模型开发的事实标准。所以芯片厂商能不能提供高质量的PyTorch适配直接决定了开发者的迁移成本。但“能跑”和“跑得好”是两回事。我见过一些芯片厂商的PyTorch适配只是把算子映射过去了能跑通推理但性能惨不忍睹。问题出在哪里主要是三个方面第一是算子覆盖不全。大模型用到的算子虽然不多但有一些是比较新的比如RoPE位置编码、SwiGLU激活函数、Group Query Attention等。如果这些算子没有原生支持就要回退到Python实现性能直接崩掉。第二是自动微分支持不完整。虽然推理不需要反向传播但很多团队在部署前会做微调。如果芯片不支持完整的自动微分微调就得换到别的硬件上做工作流就断了。第三是分布式支持薄弱。大模型推理往往需要多卡甚至多机如果框架层面的分布式支持不好多卡并行的效率就会很低。注意事项在评估芯片的框架适配时一定要问清楚三个问题支持哪些算子支持哪些模型结构多卡并行的效率如何不要只看官方文档要自己写测试用例去验证。4. 实操从模型到芯片的适配流程4.1 环境准备与基础验证假设你现在拿到了一款新的国产AI芯片要在一个70B模型上做部署验证。我建议按照以下流程来走这个流程是我们团队经过多个项目打磨出来的能帮你快速判断这款芯片到底能不能用。第一步是环境搭建。不要急着跑模型先把基础环境搭好。包括驱动安装、运行时配置、框架适配包安装。这一步看起来简单但坑很多。我遇到过驱动版本和框架版本不匹配导致的各种诡异问题排查起来非常耗时。建议的做法是严格按照芯片厂商提供的版本对应关系来安装不要自己随意升级或降级。如果厂商提供了Docker镜像优先用镜像这样可以避免很多环境问题。第二步是基础算子验证。写一个简单的测试脚本逐个验证大模型用到的核心算子。包括矩阵乘法、注意力、层归一化、激活函数等。重点看两个方面一是功能是否正确二是性能是否达标。我通常会用一个对照表来记录测试结果算子名称功能正确性单次执行耗时对标GPU性能是否可接受MatMul通过2.3ms1.8ms是Attention通过15.6ms8.2ms否LayerNorm通过0.8ms0.5ms是SwiGLU通过1.2ms0.9ms是如果发现某个算子性能差距太大就要深入排查原因。是算子实现的问题还是硬件本身的限制还是数据布局不匹配。4.2 模型转换与图优化基础算子验证通过后下一步是把完整的模型跑起来。这里的关键是模型转换和图优化。大模型通常是在GPU上训练的保存的权重格式和计算图可能和国产芯片的期望格式不一致。所以需要一个转换过程。这个转换不只是格式转换更重要的是图优化。图优化包括算子融合、常量折叠、内存复用等。我以算子融合为例在GPU上LayerNorm通常会被融合成一个算子减少显存访问。但在国产芯片上如果编译器不支持这种融合就会退化成多个小算子性能差距可能达到两三倍。我们在一个项目上做过对比同一个模型经过图优化后端到端推理延迟从120ms降到了75ms提升了将近40%。这个提升不是来自硬件而是来自软件栈的优化。图优化的具体做法通常是通过芯片厂商提供的转换工具把PyTorch模型转换成芯片支持的中间表示然后在中间表示层面做优化。这个过程需要反复迭代因为不同的优化策略对不同的模型结构效果不一样。4.3 多卡并行与通信优化70B模型单卡放不下必须做多卡并行。这就涉及到通信优化。多卡并行的方式主要有两种张量并行和流水线并行。张量并行是把单个算子切分到多张卡上流水线并行是把不同的层放到不同的卡上。在实际部署中通常是两种方式混合使用。比如8卡部署70B模型可能会用4路张量并行加2路流水线并行。通信优化的关键在于减少通信量和重叠通信与计算。我以张量并行为例在Transformer层中注意力算子和前馈网络算子都需要做All-Reduce通信。如果通信和计算不能重叠那么通信时间就会成为瓶颈。我们实测过在某个国产芯片平台上如果不做通信优化多卡并行的效率只有单卡的60%左右。经过优化后提升到了85%以上。优化的手段包括使用更高效的通信原语、调整通信和计算的重叠策略、优化数据布局减少通信量等。实操心得多卡并行时不要盲目追求卡数。有时候4卡的效果比8卡更好因为通信开销更小。关键是要找到适合你模型和硬件的并行策略。5. 常见问题与排查技巧实录5.1 性能不达预期怎么排查这是最常见的问题。模型跑起来了但性能远低于预期。我总结了一个排查流程按照这个流程走大部分问题都能定位到。第一步是确认瓶颈在哪里。是计算瓶颈、显存瓶颈还是通信瓶颈用profiling工具跑一遍看时间花在哪里。如果计算单元利用率很低那可能是算子实现的问题。如果显存带宽利用率很高那可能是数据搬运太多。如果通信时间占比很高那可能是并行策略的问题。第二步是逐层排查。把模型拆开一层一层地测。看是哪一层的性能特别差。通常问题会集中在注意力层和前馈网络层。第三步是对比排查。同样的模型在GPU上跑一遍对比每一层的耗时。差距最大的那一层就是优化的重点。我整理了一个常见性能问题的速查表现象可能原因排查方法解决思路计算单元利用率低算子实现未优化profiling看算子耗时联系厂商优化算子显存带宽利用率高数据搬运过多看显存读写量算子融合、分块优化多卡效率低通信开销大看通信时间占比优化并行策略延迟波动大批处理策略不当看不同batch下的延迟动态批处理显存溢出KV Cache管理不当看显存占用曲线优化KV Cache策略5.2 算子不支持怎么办这是国产芯片适配中最常见的问题之一。大模型用到的算子虽然不多但总有一些是比较新的或者比较冷门的。遇到算子不支持通常有三种解决方案第一种是回退到Python实现。这是最简单的方案但性能最差。只适合验证阶段不适合生产环境。第二种是自己写算子。这需要了解芯片的编程模型和指令集门槛较高。但如果这个算子很关键自己写是值得的。我们曾经为了一个自定义的注意力变体自己写了一个算子性能比回退方案提升了五倍。第三种是推动芯片厂商支持。这是最理想的方案但需要时间。如果厂商的响应速度快通常几周内就能提供支持。我的建议是在选型阶段就要确认算子覆盖情况。不要等到部署时才发现关键算子不支持。可以提前把模型用到的算子列一个清单让芯片厂商确认哪些支持、哪些不支持、不支持的计划是什么。5.3 精度对齐的坑国产芯片和GPU在浮点计算上可能存在细微差异。这些差异在单层可能看不出来但经过几十层累积后可能会导致输出结果明显不同。我们遇到过一个案例同一个模型在GPU上输出正常在国产芯片上输出乱码。排查了很久最后发现是某个激活函数的实现精度不够导致数值溢出。解决精度问题的方法包括使用更高精度的计算、调整数值稳定性的实现、在关键位置插入精度检查点。但最根本的还是要在芯片和编译器层面保证浮点计算的正确性。注意事项精度对齐不是一次性的工作。每次模型更新、每次编译器升级都要重新验证。建议把精度验证做成自动化流程每次部署前都跑一遍。6. 全栈协同的落地建议6.1 选型阶段的评估框架基于我们团队的经验我整理了一个芯片选型的评估框架包含五个维度第一个维度是硬件指标包括算力、显存容量、显存带宽、互联带宽等。这些是基础但不是全部。第二个维度是软件栈成熟度包括编译器、算子库、框架适配、部署工具等。这个维度往往比硬件指标更重要。第三个维度是生态兼容性包括对主流框架的支持、对常用模型的支持、对社区工具的兼容等。第四个维度是厂商支持能力包括响应速度、技术支持质量、定制化能力等。第五个维度是长期演进路线包括芯片迭代计划、软件栈更新频率、生态建设投入等。每个维度可以打分最后加权得到一个综合评分。根据我们的经验软件栈成熟度的权重应该最高因为硬件可以迭代但软件栈的差距很难在短期内追上。6.2 部署阶段的优化优先级部署阶段优化资源总是有限的。我建议按照以下优先级来分配第一优先级是算子级别的优化。这是投入产出比最高的。一个关键算子的优化可能带来整体性能的显著提升。第二优先级是图级别的优化。包括算子融合、内存复用、计算图重排等。这些优化不需要修改硬件或底层软件见效快。第三优先级是并行策略的优化。包括并行度的选择、通信和计算的重叠、负载均衡等。第四优先级是服务层面的优化。包括批处理策略、KV Cache管理、请求调度等。这个优先级不是绝对的要根据具体情况调整。但总体原则是先做能快速见效的再做需要深入投入的。6.3 长期协同的机制建设全栈协同不是一次性的项目而是需要长期投入的机制。我建议从三个方面来建设第一是建立跨团队的技术对接机制。芯片厂商的工程师、框架开发者、模型开发者、部署工程师需要有一个常态化的沟通渠道。很多问题不是技术难题而是信息不对称造成的。第二是建立标准化的测试和评估流程。包括性能测试、精度测试、稳定性测试等。这些测试要自动化、可重复、可对比。第三是建立知识沉淀和共享机制。把踩过的坑、优化的经验、最佳实践记录下来形成团队的知识库。这样新人可以快速上手老人也可以避免重复踩坑。我在实际项目中最大的体会是全栈协同的难点不在技术而在组织和流程。技术问题总有解决方案但如果没有一个好的协同机制再好的技术也发挥不出来。国内AI芯片的胜负手最终还是要落到能不能把芯片、编译器、框架、模型、部署这五个环节真正打通形成一个高效运转的整体。这件事没有捷径只能一步一步地做一个算子一个算子地优化一个项目一个项目地积累。但只要我们坚持做下去国产AI芯片的竞争力一定会越来越强。