大模型规模膨胀这个背景行业里喊了快两年但很多人对“膨胀”的体感还停留在参数数量上。真正在一线做训练和部署的人体会完全是另一回事单卡显存从装得下到装不下集群通信从锦上添花变成瓶颈本来能跑的算子在新架构上直接缺实现。这个阶段再去比单片AI芯片的峰值算力意义已经不大。国内AI芯片厂商真正要过的坎是能不能提供一个从硬件到框架、到算子库、到并行策略、再到应用部署都能协同发力的完整栈。这是胜负手也是我接下来想展开的核心。1. 大模型膨胀背后的硬约束算力、显存与互联的三重压力1.1 从显存账开始算起为什么单卡越来越难先算一笔最简单的账。一个7B参数的模型光FP16权重就需要14GB显存。推理时加上KV Cache和激活值单卡勉强还能跑一旦进入训练梯度、优化器状态、中间激活全部叠加显存需求直接翻三四倍。到了70B参数这个量级FP16权重就是140GB单张80GB的卡根本放不下哪怕用INT8量化70GB也只是刚刚卡线。这就逼着所有团队必须上多卡分布式要么张量并行切模型要么流水线并行分阶段要么数据并行配ZeRO显存优化。这个变化对AI芯片设计的影响是根本性的。过去做AI芯片大家盯着单芯片的TOPS算力指标觉得算力堆上去就能赢。但大模型时代单卡再强显存装不下一个模型就必须靠多卡互联。而一旦互联起来通信效率、同步开销、负载均衡这些问题立刻变成了决定系统整体性能的瓶颈。我实测过不少集群单卡算力很漂亮跑起来效率却只有30%左右问题几乎都出在通信和并行策略的配合上。1.2 算力峰值不再稀缺稀缺的是有效算力行业里考核AI芯片过去习惯看TOPS、TFLOPS这类峰值指标。但大模型训练和推理的实际情况是峰值算力根本跑不满。核心原因有两层第一层是硬件本身的利用率也就是芯片的算力能否被算子持续打满这里面涉及存储带宽、缓存命中率、指令流水线调度等微架构问题第二层是系统级利用率也就是多卡并行时通信等待、同步开销、负载不均带来的浪费。业界常用MFUModel FLOPs Utilization模型算力利用率来衡量这种系统级效率。一个参考数据是行业头部GPU集群训练GPT级别模型MFU大致在35%到50%之间这已经算非常优秀。国产芯片如果MFU能做到30%在相同集群规模下就有竞争力如果只有10%出头哪怕峰值算力翻倍实际训练耗时反而更长。所以真正该对比的不是单卡峰值而是同等规模集群跑一个标准模型比如Llama 7B或者70B的端到端时间。1.3 通信带宽MoE架构和长上下文带来的新天花板参数规模只是故事的一半。最近一两年MoE混合专家架构和长上下文成为大模型的主流方向这两者对通信带宽的消耗远超传统稠密模型。MoE模型的特点是每次推理只激活一部分专家但路由决策需要全局同步而且专家在不同卡之间做All-to-All通信。模型规模越大专家数量越多通信量就越大。DeepSeek V2/R1这类使用MoE和MLAMulti-head Latent Attention的模型已经把注意力机制的KV Cache压缩到了极致但通信瓶颈依然显著。在我实际部署经验里使用DeepSeek系列模型做推理时整个集群有一半以上的时间可能都花在节点间的数据传输上。长上下文带来的问题更直接。上下文从4K扩展到128K甚至1MKV Cache的存储需求线性增长。为了保证低延迟芯片的HBM带宽必须足够高否则decode阶段每个token的生成都会被带宽卡住。这就是为什么很多号称高算力的芯片跑长上下文推理时吞吐惨不忍睹——算力足够带宽喂不饱。全栈协同在这里的具体含义是芯片的存储层次设计与推理框架的KV Cache管理策略必须深度配合才能在有限带宽下榨出性能。2. 全栈协同的四个层面从芯片到应用的一次系统设计2.1 芯片层算力、存储与互联的平衡设计全栈协同的根基在芯片。AI芯片设计不能只追求单点指标需要在计算单元、片上存储、片间互联三个维度做平衡。计算单元方面矩阵乘法的算力密度依然是核心。大模型训练90%以上的FLOPs集中在矩阵乘上Tensor Core这类专用矩阵单元是必备品。但在算力之外芯片的存储层次设计同样关键。HBM的容量和带宽决定了单卡能装多大模型、decode阶段能跑多快片上SRAM的大小决定了算子融合的可行性——FlashAttention之所以能大幅提速核心就是把QKV计算和注意力分数计算融合在一个kernel里避免中间结果写回HBM这依赖足够的片上缓存。片间互联是全栈协同最容易出问题的环节。训练70B级别模型张量并行会在每层forward和backward都产生大量AllReduce通信互联带宽不够的话加速比会严重衰减。国内AI芯片厂商近几年在互联上投入很大但实际效果需要看集群测试而不是看单卡规格表。2.2 系统软件层算子库、编译器与通信库缺一不可芯片之上是系统软件层这也是国内AI芯片与国际主流差距最大的地方。有人把CUDA生态比作人工智能领域的Windows虽然不完全准确但思路是对的。CUDA不只是硬件接口而是一个包含cuBLAS矩阵运算库、cuDNN深度神经网络库、NCCL多卡通信库、cuBLASLt、TensorRT在内的庞大软件栈这些库经过十数年迭代针对各类模型结构做了极致优化。国产芯片厂商要补的课首先是算子库的覆盖度与性能。以Llama架构为例核心算子包括矩阵乘GEMM、LayerNorm、RMSNorm、RoPE旋转位置编码、Softmax、SiLU激活、KV Cache管理、以及各种融合算子。如果这些算子在库中缺乏高性能实现只能走编译器自动生成或者手写内核性能会大打折扣。我在实际调优中发现即便是同样的算子针对不同序列长度和batch size做tiling和调度优化性能差异可以达到几倍。编译器是另一块硬骨头。现代AI芯片普遍采用编译栈方案从高层计算图到低级IR再到机器码中间需要做算子融合、内存规划、指令调度等优化。这个栈的成熟度直接决定新算子能否快速支持。很多团队评估芯片时会拿PyTorch代码直接跑如果编译栈不成熟可能连标准的Transformer模型都跑不通更别提优化。2.3 框架适配层PyTorch兼容只是及格线大模型时代的训练和推理几乎统一在PyTorch生态下。用户跑的代码大多是Hugging Face Transformers、vLLM、SGLang、DeepSpeed这些开源项目。AI芯片要进入用户的真实工作流必须在这些框架上开箱即用。PyTorch兼容有两层含义。第一层是算子和设备接口的适配能跑通torch.matmul、torch.nn.functional.scaled_dot_product_attention这类标准算子第二层是分布式框架的适配比如与NCCL对应的通信库接口、与DDP/FSDP对应的显存管理策略。现实情况是国产芯片适配PyTorch往往需要维护一个定制的PyTorch分支或者接入torch.compile的后端。这个工作的难点在于同步维护和版本兼容。PyTorch每几个月就发布一个版本适配的速度直接决定了用户用上新特性的速度。我见过不少团队卡在PyTorch版本升级的问题上旧版本跑不了新模型新版本又没适配完。2.4 算法与模型层量化、KV Cache与稀疏化的软硬协同全栈协同的最后一层在算法和模型。这一层往往是用户最容易忽略的但恰恰是性能差距的关键来源。量化方面INT8和FP8已经被大模型训练和推理广泛采用。国产芯片要做出竞争力硬件需要原生支持FP8的矩阵计算和格式转换软件栈需要支持FP8的自动缩放和混合精度策略。如果只是把FP8当作一个开关而不在算子层做精度和吞吐的联合调优很容易出现精度下降或者性能不升反降。KV Cache的软件化优化同样重要。vLLM中的PagedAttention、DeepSeek的MLA、各种StreamingLLM和稀疏注意力机制都是围绕KV Cache做文章。芯片的显存管理单元如果支持细粒度的内存分页和异步拷贝就能为这类算法提供更好的支撑。反过来推理框架也要针对芯片的存储层次调整KV Cache的布局这些都需要软硬件协同设计不是单方面能解决的。3. 国产AI芯片的突破口从追峰值到拼系统效率3.1 别被峰值算力带偏有效算力是更靠谱的参照系这些年我看过不少国产芯片的发布参数单卡FP16算力都在几百TOPS到上千TOPS之间看起来与主流产品持平甚至更高。但实际测试下来跑真实模型时有些卡的性能只有同算力主流产品的50%。差距主要来自软件栈对算子的覆盖度和调度效率。所以我的建议是评估AI芯片先跑三个测试第一跑PyTorch标准实现的一个Transformer block看端到端时延第二跑一个7B模型的完整推理测decode吞吐第三跑两卡或四卡的数据并行训练测加速比和可扩展性。这三个测试的结果比任何PPT上的峰值数据都有说服力。行业里常提到的“千卡集群有效算力”说到底就是把这一套测试扩展到千卡规模MFU才是真正能对比的指标。3.2 算子库的覆盖度直接决定训练天花板大模型训练核心算子的种类其实不多但每个算子的性能都极其敏感。以Llama训练为例核心路径上要调用的算子包括线性层GEMM、Embedding、LayerNorm/RMSNorm、Softmax、RoPE、以及自动微分相关的反向算子。如果芯片的算子库在这些核心kernel上做不到与主流芯片相当的性能训练效率就不要指望追平。这里有一个容易被忽视的小点GEMM的性能不仅取决于芯片算力还取决于shape。大模型训练GEMM的M、N、K维度随batch size和序列长度变化不同shape的最优tiling方案差异很大。成熟的算子库会根据shape自动选择kernel而缺乏积累的算子库往往只能针对少数shape调好遇到真实训练任务就吃力。3.3 通信库与并行策略的适配决定集群扩展性大模型训练一定上集群通信库NCCL的成熟度直接决定多卡扩展效率。国产芯片普遍需要自己实现通信库这就产生两个挑战第一是协议兼容能否与NCCL接口对齐让PyTorch的分布式套件直接可用第二是拓扑适配通信库需要感知节点的网络拓扑比如环形、Torus、Clos才能选择最优的通信路径。我在实际项目中遇到过一个典型问题某款芯片单卡性能尚可但8卡训练时加速比只有5倍。分析后发现是通信库的AllReduce实现没有针对多卡拓扑优化导致PCIe Switch上的流量拥塞。换用分层通信策略后加速比提升到7倍以上。这种细节就是全栈协同的日常。3.4 生态与工具链开发体验也是效率的一部分除了跑得快的算子库和通信库完整的开发工具链同样重要。Profiler工具能帮开发者定位性能瓶颈调试工具能分析显存泄漏分布式看板能观察集群状态。这些工具在国内芯片上往往处于“能跑但不顺手”的状态导致用户的调优效率大打折扣。深度学习工程师的时间也是成本。如果在一个芯片上用三天才能定位的问题在另一个芯片上半小时就能找到前者的生态成熟度就值得怀疑即使它能跑得更快。这是我在和多个团队交流时反复被强调的点开发体验和运行时性能是同等重要的竞争力。4. 快速评估一款芯片的全栈成熟度三步走与避坑清单4.1 第一步跑标准模型而不是只看benchmark评估AI芯片最忌讳的是直接看厂商提供的benchmark。这些结果通常经过精心选择只覆盖芯片擅长的场景。科学做法是选择你实际要跑的模型比如Llama 3 8B、Qwen 2.5 7B或DeepSeek MoE模型在芯片上做端到端测试。具体操作流程可以这样第一步确认环境。操作系统、驱动、PyTorch版本、模型框架都要安装到位记录安装时间和踩坑数量。第二步跑推理。用一个小batch size比如1测试单请求延迟再用一个大batch size比如32或者64测试吞吐。第三步跑训练。选择一个中等规模模型7B级别进行少量步数的训练观察显存占用和MFU。第四步查问题。如果性能远低于预期用profiler定位瓶颈在算子还是通信。4.2 第二步集群可扩展性测试谁扩不动谁出局单卡性能只能说明一部分问题大模型场景必须跑多卡和多节点。搭建一个四节点的测试集群每节点8卡跑数据并行或者ZeRO-2/ZeRO-3的分布式训练。记录1卡、2卡、4卡、8卡、16卡、32卡的吞吐数据计算加速比曲线。正常的加速曲线应当接近线性比如32卡达到单卡的25倍以上。如果加速比在8卡以后迅速饱和说明通信或内存瓶颈严重。在这个测试中还要关注稳定性长时间运行是否有显存泄漏、通信超时、死锁。长稳测试是很多评估容易忽略的一环但恰恰是生产环境最看重的。4.3 避坑清单这五个错误判断最容易误导决策第一个误区是只看单卡峰值算力不看MFU。第二个误区是只用官方部署好的镜像测试不看真实环境的适配难度。第三个误区是拿主流芯片做基准测试的数据直接对比而不考虑软件栈版本的差异。第四个误区是只测推理不测训练——要知道训练对通信、内存和算子的要求比推理高得多。第五个误区是忽略开发工具链的成熟度团队上手的时间和调试效率同样算成本。我见过一个较为典型的案例某团队因为只看峰值算力选择了某芯片结果在标准模型训练上花了两周才把环境跑通又花了四周调性能最终MFU只到15%。如果一开始就用上述三步评估法恐怕一天之内就能得出“软件栈尚未成熟”的结论。5. 全栈协同的竞争格局与未来演化5.1 海外启示技术护城河从来不止硬件从全球视角看主流GPU厂商建立的优势是整个系统生态。CUDA、cuDNN、NCCL、TensorRT、Triton Inference Server、NVIDIA AI Enterprise——这些组件构成了从芯片到应用的完整闭环。开发者一旦习惯了这套工作流切换到其他芯片的迁移成本极高。这种生态粘性才是真正的护城河硬件性能反而是可以追赶的部分。值得注意的变化是最近两年开源社区出现了大量去CUDA化的工具链比如Triton编程语言、OpenAI的Triton编译器、AMD的ROCm、以及各种统一推理引擎。这些项目正在降低不同芯片之间的软件迁移成本对国产芯片来说是一个机会窗口。但窗口期不会太长谁能尽早把技术栈的软件部分补全谁就有更大的概率进入主流用户的替换清单。5.2 国内现状从芯片优先到软件优先过去几年国内AI芯片行业的资源高度集中在芯片设计本身软件栈的投入占比偏小。这个局面正在改变。越来越多的从业者意识到光有一颗好芯片没有配套的算子库和框架适配根本进不了大模型训练的主力市场。行业里有句话叫“芯片是骨架软件是血肉”说的就是这个道理。实际操作层面我看到的方向有三个一是大力投入算子库和基础库的开发对标业界主流标准二是主动适配PyTorch和vLLM这些主流开源框架而不是要求用户改写代码三是建立完整的开发工具链和文档体系降低用户的上手门槛。这三个方向都做扎实全栈协同才不是一句空话。5.3 未来技术方向异构计算、统一框架与软硬协同设计展望未来几年我认为有三个趋势值得注意。第一异构计算会成为常态。大模型训练和推理会混合使用GPU、NPU、FPGA等不同芯片如何让它们协同工作是新的系统级挑战。第二统一编程框架会加速成熟比如Triton这类领域特定语言用Python编写内核并自动映射到不同硬件这会让算子开发的成本大幅降低。第三软硬协同设计会从口号变成方法论。新一代AI芯片在立项阶段就会把目标工作负载和软件路径纳入设计约束而不是先做硬件再补软件。对大模型应用开发者来说这些变化意味着选择空间会变大但评估成本也会上升。我的建议是关注芯片厂商在软件栈上的投入力度和进度这比关注参数表更有参考价值。我在实际部署和优化中的体会是全栈协同的品质最终体现在一个细节上当一个标准的大模型repo下载下来执行pip install和python run时整个过程是否顺畅。跑通只是第一步跑得快、跑得稳、跑得省显存才是真正的决胜点。这个看似平凡的标准背后是整个技术栈从芯片到应用每个环节的协同质量。最后分享一个选型心得。评估国产AI芯片不要被发布会的数字带节奏也不要被各种峰会演讲迷惑。拉一支小团队用两周时间跑一遍标准模型的训练和推理记录下MFU、加速比、上手时间、踩坑个数结果会说明一切。大模型时代的芯片竞争不是比谁的数字大而是比谁能让这些数字落到真实用户的代码里。
