去年下半年我一口气测了三款国产AI芯片，跑的模型从7B到72B，从Dense到MoE都有。结果挺有意思：单看规格参数，有的芯片算力标称已经能对标A100了，但实际跑大模型推理，吞吐量差距比纸面数字难看得多。有的芯片显存带宽看着不高，帧率反而稳。这让我把注意力从“芯片本身”挪到了“芯片周围那一大圈软件和系统”上——大模型规模膨胀之后，国内AI芯片的胜负手确实不在裸算力，而在全栈协同。
这篇文章我想把那段时间的测试心得、跟多家厂商工程师聊出来的信息，以及自己踩过的坑，系统梳理一遍。重点回答几个问题：为什么芯片跑分好看、实际跑大模型却跟不上；大模型的结构演进到底在哪些维度卡住了芯片；所谓“全栈协同”具体协同什么、怎么落地；以及国内AI芯片要打好这场仗，现实路径里有哪些关键取舍和常见陷阱。
1. 为什么芯片跑分好看，实际跑大模型却跟不上
1.1 大模型不是“更大的卷积网络”，而是全新的访存与调度难题
我最早做芯片评测那会儿，流行用ResNet-50、BERT-base这类模型测吞吐。这些任务的规律是：计算量集中、访存模式规整，只要芯片的TOPS高、MFU（峰值算力利用率）能做到四五十个百分点，看起来就够漂亮。可大模型完全不是这么回事。
Transformer架构的核心算子是矩阵乘法和Attention。矩阵乘法本身确实是计算密集型的，但Attention、RMSNorm、RoPE、GELU这些算子访存占比极高，尤其是自回归生成阶段，每一步都要把整个KV Cache读一遍。模型规模越大，KV Cache越长，访存量呈线性甚至超线性上涨。我接触过一家公司，自研芯片FP16算力标称能做到200TFLOPS以上，跑ResNet-50妥妥的，可一上开源7B模型做连续推理，算力利用率直接掉到十几个百分点。原因很简单：大量时间花在等显存数据上，算力单元在空转。
这就像一辆发动机功率三百千瓦的跑车，理论上限速能标到三百多，可你把它扔进早晚高峰的城市道路，实际通勤速度跟一辆小电驴没多大区别。问题不在发动机，在道路系统。这个类比放到大模型场景里特别贴切——芯片是发动机，而显存带宽、卡间互联、算子调度、运行时分配就是那套城市路网。全栈协同优化的本质，就是别只堆发动机功率，要把路网、信号灯、立交桥一起设计好。
1.2 峰值算力是纸面数据，真实世界看计算密度与有效利用率
行业里有个词叫“计算密度”，指的是芯片在给定显存带宽、缓存层级、互联拓扑下，每秒实际能完成的端到端有效计算量。这个指标比峰值TFLOPS更能反映大模型体验。GPU这边，英伟达强的不只是裸算力，而是HBM带宽、NVLink、cuBLAS/CUTLASS、TensorRT-LLM这一整套东西组合出来的有效密度。
国产芯片真正的问题往往不是算力不够，而是配套系统拖后腿。比如有些芯片为了赶进度，编译器只支持少数几种静态shape下的算子调优，一遇到动态序列长度、变长batch、KV Cache增长，就得退回慢速路径，性能直接腰斩。再比如有的芯片单卡跑得还行，一上多卡就要走PCIe而不是专用互联，卡间通信带宽可能只有英伟达NVLink的十分之一，大规模并行时通信开销把计算收益全吃掉。
我做测试的习惯是：拿到芯片第一周，不看厂商给的跑分PPT，先拿自己的模型和压测脚本上去跑一轮。看三个数——首Token延迟、每秒生成Token数、能持续稳定跑多久不抖动。这三个数才是大模型用户真正体感的东西。同一颗芯片，软栈调好和没调好比出来常常是两三倍的差距，这个差距比不同芯片之间的硬件差距还大。
2. 模型结构膨胀的三个典型特征，每个都卡在芯片要害上
2.1 Key-Value Cache让内存膨胀，带宽远比算力值钱
先讲一个很多人容易忽略的事实：大模型推理生成阶段算力需求其实比预填充阶段低不少，真正的瓶颈从“算力”转移到了“带宽”。
自回归生成时，模型每生成一个Token，都要把之前所有Token的K和V向量取出来做Attention计算。这些K和V缓存下来就是KV Cache。序列越长，KV Cache越大；模型层数越多、头数越多，KV Cache翻倍更狠。行业里的说法是，一个70B模型在长上下文场景下，KV Cache产生的显存占用可能比模型权重本身还高。
所以大模型不断膨胀之后，芯片设计里最值钱的能力不是堆FP16算力，而是HBM带宽、片上缓存容量、以及把Attention算子融合进硬件流水线的能力。业界后来搞出GQA、MLA这些结构改进，本质上都是在“压缩KV Cache的表达，降低访存压力”，而不是在提升算力。这对芯片的影响是巨大的——如果芯片的软件栈没有为Attention算子的访存模式做专门优化，哪怕峰值算力再高也白搭。
2.2 稀疏专家网络（MoE）把“稀疏”难题甩给了硬件调度
大模型的另一个膨胀方向是参数量暴涨，但计算量不希望跟着暴涨，于是MoE（Mixture of Experts，混合专家）架构火了起来。MoE的思路是：模型里塞几百个专家子网络，每次推理只激活其中几个，这样参数规模看着几百B，实际算力消耗却按几十B来算。
听着很聪明对吧？但它把麻烦甩给了芯片和调度系统。路由机制决定了每个Token去哪些专家，这个调度天然存在负载不均衡——有些专家被疯抢，有些专家闲着。而且更关键的是，专家并行会把不同专家放到不同卡上，Token要去访问不在本卡的专家，就得走卡间通信。Dense模型里那种“数据就在身边”的美好假设，在MoE里不存在了。
我今年测了几个主流开源MoE模型，发现一旦专家切分策略和芯片的互联拓扑不匹配，通信延迟可能占掉整体延迟的三成以上。这个比例在英伟达的NVLink加持下能压得比较低，但在互联带宽先天不足的国产芯片上就特别刺眼。软栈如果能做拓扑感知的专家放置、在通信前做充分的批量聚合，情况会好很多；否则就算单卡算力再强，MoE模型照样跑不起来。
2.3 长上下文把通信压力推到了临界点
大模型这两年还有一个明显趋势：上下文窗口从4K、8K卷到128K甚至200K。序列越长，Attention的计算量按平方涨，卡间的集合通信量和中间激活量也同步涨。传统的并行策略——张量并行、流水线并行、序列并行——在面对超长序列时，通信模式会发生根本性变化。
我自己在测试长文本综述、长代码分析这类任务时就遇到过一个现象：把上下文从32K加到128K，生成速度并没有线性下降，而是阶梯式跳崖。后来分析才发现，跨卡的AllReduce通信在某个阈值之后开始频繁触发同步等待，整个集群的计算流水线被通信卡死。这不是换一颗算力更强的卡能解决的，得靠互联拓扑、通信调度和模型并行切分方式一起重新设计。
2.4 小结：模型结构演进对芯片的战略含义
把上面三件事放一起看，结论很清晰：大模型规模膨胀之后，决定芯片体验的物理量从“单点算力”变成了“系统链路的整体带宽与调度效率”。这对国产AI芯片意味着一个战略转向——不能只追着H100的TOPS指标打，要在显存带宽、互联设计、软件调度这些维度建立自己的护城河。而恰好这些维度的优化，没有一家只靠硬件完成，都是软硬协同的结果。
| 模型特征 | 芯片压力点 | 软栈关键应对 |
|---|---|---|
| KV Cache膨胀 | 显存带宽、容量 | Attention算子融合、KV管理优化 |
| MoE稀疏激活 | 卡间通信、负载均衡 | 专家放置、通信流调度 |
| 长上下文 | 通信量、中间激活 | 并行策略拓扑感知、序列并行优化 |
3. 全栈协同的六个层次，缺哪一层都会拖后腿
3.1 硬件定义算力上限，软件决定真正利用率
讲到全栈协同，很多人的第一反应是“软硬结合”这碗鸡汤。但实际拆开来看，这件事有非常具体的层次，每一层都有自己独立的技术难点。我习惯把全栈协同拆成六个层面：
- 芯片硬件层：算力单元、SRAM容量、片内互联、HBM控制器、卡间互联拓扑
- 编译器与算子库层：算子融合、循环优化、内存布局转换、自动调度
- AI框架与推理引擎层：动态batch、KV Cache管理、算子图优化、连续批处理
- 模型算法层：KV Cache压缩、量化、注意力改写、并行切分策略
- 集群与通信层：集合通信库、负载均衡、故障处理、拓扑感知路由
- 应用与服务层：服务化吞吐、弹性伸缩、多用户调度、端到端延迟控制
每一层的短板都会成为整个系统的瓶颈。我在测试中反复看到同一个现象：芯片厂商把算子库做得很漂亮，框架层没有对应的动态Shape支持，一跑真实负载立刻打回原形；或者推理引擎适配得很好，集群通信库又是从开源项目抄过来没做过调优，一上大规模并行就炸。全栈协同不是说每一层都做到世界顶尖，而是每一层的短板都不能明显拖后腿，并且层与层之间要以一种可预期的方式配合。
3.2 从生态兼容到原生自研：两条路线的不同代价
国产AI芯片目前在软件生态上分成两条路线。一类走兼容路线，尽量让CUDA的代码和算子库直接迁移过来，主打“无缝替换”；另一类走原生自研路线，开发自己的编译器、算子库、运行时，通过深度优化争取性能上限。
两者各有代价。兼容路线的优点是产业迁移成本低、上手快，但问题在于兼容接口翻译层常常是性能黑洞——你写的调用看着是熟悉的CUDA API，实际落到硬件时可能被翻译成了低效的内存操作序列，性能损耗逃不掉。我见过一个团队从英伟达迁移过来，本来以为改改编译参数就完事，结果跑了几天原子操作相关算子，性能只有原平台的十分之一，最后不得不重写一遍。
自研路线的优势当然是没有翻译开销，而且可以为自家芯片的架构特点做深度定制；问题是生态积累薄、开发者学习成本高、工具链不成熟。现实点说，自研软栈的成熟周期不是一两年，可能要持续投入五个迭代版本以上。这也是为什么很多国产芯片厂商今年开始重点做一件事：把主流推理引擎（比如vLLM、SGLang这类）直接适配进自家软栈，而不是让用户自己去补适配层。
3.3 框架与引擎：大模型推理引擎的移植成本是一道隐形门槛
提到大模型推理，vLLM和SGLang这几年几乎成了标配。vLLM里的PagedAttention能高效管理KV Cache内存，连续批处理能大幅提高吞吐。问题来了：这些机制跟硬件细节绑定极深——显存分配方式、内核调度、异步流水——不是换个编译目标就能自动跑通的。
我在做国产芯片适配时发现，最耗时的就是推理引擎的内存管理模块。PagedAttention假设了GPU显存的分页结构，换到国产芯片上，如果芯片的显存管理模型跟CUDA不一样，要么重写这一层，要么退化为低效的静态分配。这一层做得好不好，直接决定服务端的吞吐水平。所以在选型国产AI芯片时，我建议先去看它对vLLM这类主流引擎的支持到底到哪一层，是真适配还是“理论上支持”。
3.4 模型工程：量化、剪枝、蒸馏，都是协同的一部分
全栈协同还包括模型侧的动作。量化是个典型——芯片标称支持INT8、FP8，但实际跑起来精度和速度能不能兼得，还要看硬件原生的低精度算力、量化算子的粒度、反量化的开销。大模型蒸馏和剪枝也一样，不是模型团队单方面的工作，需要知道目标芯片的架构特点来决定怎么压缩。
模型算法与硬件之间其实存在一个双向适配空间，这也是目前最缺复合型人才的地方。我接触过一些做得不错的团队，他们的算法工程师能看懂芯片的opcode手册，硬件工程师能理解Flash Attention的原理，两边一起开会，把模型结构里最容易卡带宽的算子改成更适合目标芯片的等价形式。这种协同价值，是任何单一技术团队都很难单独突破的。
4. 全栈协同的落地姿势：几个可以立刻上手的实战方向
4.1 算子融合：把碎片化计算拼成整块
全栈协同最经典的实践是算子融合。拿Flash Attention来说，它的核心思想是：标准Attention会反复在HBM（显存）和SRAM（片上缓存）之间搬运中间矩阵。每算一步就写回显存，再读出来算下一步，访存开销巨大。Flash Attention把Attention的多个步骤融合到一次片上计算里，按分块方式在SRAM内算完再写回，访存量减少了一个数量级。
这个优化在英伟达平台上已经普及，但在国产芯片上还是需要重新做一遍的，原因有两个：一是不同芯片的SRAM大小、寄存器布局差异很大，代码不能通用；二是融合调度涉及chiplet架构、多核同步等细节，没有硬件厂商深度支持很难自己实现。做算子融合有一个原则：优先融合访存占比最高的算子链，比如Attention块、MLP块、RoPE+RMSNorm+量化这几组场景，融合收益最明显。
4.2 并行策略适配：换一个切分维度，性能能差出数倍
大模型训练推理并行全家桶包括数据并行、张量并行、流水线并行、序列并行、专家并行。它们的通信开销天差地别：
- 数据并行：通信量小，主要在梯度聚合
- 张量并行：每个Transformer层内需要多次AllReduce，通信频繁但单次量不大
- 流水线并行：通信量小，但气泡率影响效率
- 序列并行：长序列下通信量猛增，对互联带宽极敏感
- 专家并行：路由通信，随机且不可预测
我在实际项目里见过最离谱的一次：同样是训练一个13B模型，单纯把张量并行和序列并行做对调，吞吐差距到了将近三倍。原因就是这家芯片的卡间互联拓扑是环状而非全连接，序列并行在环状拓扑下会产生大量跨跳访问，张量并行反而更贴合。英伟达的NVLink是全连接的，所以很多开源框架的默认切法都是按NVLink假设调的；国产芯片拓扑五花八门，直接套默认配置大概率吃亏。正确的做法是，先拿一张卡间拓扑图，再决定哪个维度做并行切分，哪个维度放在同一张卡内。
4.3 量化格式：不要只看“支持INT8”这种宣传口径
量化是让大模型跑得更快最直接的手段，但这里水也很深。我建议拿到一颗芯片，先问四个问题：
- 低精度算力是否原生支持，还是靠模拟运算然后转换回高精度？
- 反量化算子是否和主算子融合了？
- 支持哪些量化粒度（per-tensor、per-channel、per-group）？
- 激活值量化和权重量化是不是都能跑在低精度单元上？
这四个问题的答案，决定了理论压缩倍数能不能兑现。如果芯片只支持per-tensor量化，而业界最佳实践已经卷到per-group（比如每128个元素一组），模型精度损失就会变大，需要额外的校准技术来补偿，效果还不一定好。反之，如果原生支持混合精度和分组量化，你就能直接用业界成熟的量化方案，速度提升立竿见影。行业里现在有一个很清晰的趋势：国产芯片能不能跑好INT4/FP8混精模型，基本决定了它能不能进主流大模型部署市场。
4.4 用一个检查清单评估软栈真实成熟度
被各种官网指标晃过几次之后，我整理了一份评估软栈成熟度的自检问题清单，提供给团队做芯片选型时使用。前五个问题是最容易暴露短板的：
- 推理引擎层是否支持连续批处理和PagedAttention同级的KV Cache管理？
- 动态Shape是否会触发重新编译或慢速路径？
- 低精度算子是否覆盖训练和推理全流程？
- 大规模并行时，集合通信库是否做拓扑感知的调度？
- 故障恢复能力如何，单卡掉线后任务能否自动重分配？
这些问题的答案，比任何单一benchmark更能反映真实水平。上次我拿这份清单去问一家国产芯片厂商，对方工程师苦笑着说：能答上大半的国内团队，两只手数得过来。
5. 国内AI芯片全栈协同的两条路线，和常见的四个坑
5.1 兼容CUDA生态 vs 自研软栈，是路线选择不是道德判断
每次聊到国产AI芯片，总有人把“兼容CUDA”和“自立门户”当成一个站队问题。我的看法其实很现实：这是一个阶段性的成本和收益考量。
兼容CUDA的好处是初期生态红利明显，开发者迁移成本低，vLLM、DeepSpeed这些框架可以直接跑起来。但风险是，兼容层永远跟在别人生态后面走，而且CUDA本身也在快速迭代，一旦英伟达更新底层指令集或引入新特性，兼容层就不一定跟得上。自研软栈的收获在于能完全掌控性能和演进节奏，代价是前期的投入巨大，而且在应用生态成熟之前，开发者用脚投票的意愿不强。
从我的观察看，国内芯片厂商现在普遍走的是“中间路线”：底层指令集自研，顶层API尽量兼容主流框架，中间通过自研编译器做高效翻译。这个路线能不能跑通，关键看编译器的翻译质量能不能做到“源码不动、性能有竞争力”。
5.2 常见坑一：接口层“兼容”不等于性能兼容
这是一个高频坑。很多芯片宣称“兼容CUDA”，实际是把CUDA API翻译成自己的底层调用。单个简单算子的翻译还好，但大模型里的复杂融合算子翻译过去经常变成一串碎片化的小操作，显存反复读写，性能差距被放大数倍。
我建议任何想用“兼容模式”加速的团队都做一个先验证：拿Flash Attention或SDPA这类访存密集算子，写一个微基准测试，跑一天，看性能是否接近原厂的CUTLASS实现。如果差距超过一倍，就说明翻译层还需要打磨，这时候简简单单的代码迁移计划要大改。
5.3 常见坑二：重算子优化、轻运行时与调度
有些国产芯片的算子库单看一个算子性能不错，但整体跑起来调度开销很大。问题出在“动态Shape管理、内存池、多流并发调度、内核启动开销”这些运行时环节，它们几乎决定了大模型动态推理场景的最终体验。
我踩过的一个典型例子是：某芯片的单算子性能能到参考实现的九成，可一旦同时启动多个不同shape的Attention调用，显存管理开始频繁申请释放，延迟翻了三倍。原因就是它缺少类似CUDA Graph或者统一内存池的机制、内核启动也要逐次等待。这些运行时层面的问题，单靠加算子优化是补不回来的。
5.4 常见坑三：只顾单卡性能，忽略集群互联
不少国产芯片厂商在单卡指标上下了大功夫，跑分漂亮，但多卡并行时问题就露馅了。这里面最悲催的场景是：单卡推理能打A100的八成，结果上128卡训练一个大模型，因为互联带宽不足、集合通信库优化不够，扩展效率惨不忍睹，整体算力折算下来连A100集群的五成都不到。
测试集群能力有个简单有效的方法——跑一次全Reduce AllReduce的延迟和带宽测试，再做一次“强缩放”（固定模型规模、不断增加卡数）的训练实验。正常来说扩展效率应该保持在百分之七八十以上，低于这个数就说明互联或通信库有明显短板。这个环节在选型时尤其别跳过。
5.5 常见坑四：用传统模型的评测方式验收大模型效果
经典benchmark验收方式（固定batch、固定shape、短序列）已经严重过时了。大模型场景的真实负载是长尾的、动态的、混合的：不同请求的序列长度相差极大，有些是短问快答，有些要读几十万字材料，还有多用户并发高峰。评测一个芯片的综合大模型能力，至少要看三组数据：单请求流式生成的平稳性、多请求并发时的吞吐和尾延迟、超长上下文下的性能衰减曲线。
我还遇到一个更隐蔽的问题：温度漂移。高强度连续推理会让某些芯片触发降频，跑半小时后吞吐量掉一截，指标好看但稳不住。这种问题在短跑测里完全看不出来，所以我的建议是，大模型芯片的验收测试至少持续跑几小时以上，且要覆盖高峰与低谷的负载交替。
5.6 跨越“工程协同”与“生态协同”
除了上述技术层面的全栈协同，还有一个更宏观的维度：工程协同和生态协同。工程协同指的是芯片厂商和框架厂商、模型厂商、云服务厂商之间要做联合调试，而不是各干各的，最后交付一堆兼容性补丁。生态协同指的是人才培养和社区建设，让更多开发者能在这套软栈上做出贡献，而不是只靠厂商自己的几百号工程师打全场。
我看下来，国内AI芯片在工程协同上有进步，但在生态协同上的差距还很明显。一个优秀的开源推理引擎适配到国产芯片后，后续的持续优化和版本同步能否跟上，往往比初次适配更重要，而这依赖的是一个活跃的开发者社区，不是一家公司的单方面努力。
结尾处，想给正在做技术选型或芯片适配的团队一些个人层面的建议。
一个是我反复强调的操作原则：不要在发布会上被峰值数据吸引，也不要在第一周就被benchmark的兴奋冲昏头脑。拿你真实的模型、真实的并发模式，跑满连续几天，看长期稳定性和尾延迟，这两个指标才是大模型部署的生死线。
另一个是你如果要在国产芯片上搞大模型优化，建议团队里一定要有能同时看懂模型结构和硬件手册的人。全栈协同这个事，本质上不是一个系统工程师关起门来调优就行的，它要求懂模型的人能理解硬件的带宽焦虑，懂硬件的人能理解模型的稀疏机会。能把这两拨人对齐到一起的团队，在接下来的大模型芯片竞争里会占据一个很舒服的位置。
最后我想说的是，这篇文章写到的各种坑和优化方向，本质上都不是某一家厂商单独能解决的。大模型规模膨胀带来的问题已经超出了“算得快”范畴，变成了“系统跑得稳、生态转得动”的综合博弈。谁能在芯片之上把软件、框架、模型、应用这一整条链路协同起来，谁就真正掌握了这场竞争的胜负手。
