当参数规模突破2.8万亿，编译器的优化空间还剩多少

看到Kimi K3在Frontend Code Arena登顶的消息，第一反应不是兴奋，而是打开内存带宽计算器。2.8万亿参数，即便采用FP16推理，单次前向传播的理论访存量超过5.6TB。以当前H100 3.35TB/s的带宽，纯参数加载就需要接近2秒。这个数字让我立刻意识到，月之暗面绝对不可能做全参数激活的密集推理。

[!tip] 结论先行

Kimi K3登顶证明了工程调优的价值，但这不是“全面超越”，而是特定任务上的工程优化局部胜利。彭博社的论断过于笼统，美国在基础硬件和框架生态上的优势依然存在。

先看技术细节。2.8万亿参数，100万上下文，这俩数字放在一起，显存容量就是第一道坎。假设采用MoE（混合专家）架构，每个token激活约几十亿参数，加上KV cache膨胀，单卡显存根本放不下。月之暗面很可能采用了一种稀疏激活+层级显存管理的方案，类似Google的GShard或Meta的FSDP，但针对昇腾硬件做了定制。

从编译器视角，关键瓶颈在于：

1. 算子融合。当模型包含大量稀疏门控、专家路由时，控制流和数据依赖复杂，传统编译器很难做全图融合。需要在IR层添加稀疏算子标记，让后端知道哪些分支可以并行发射。

2. 内存带宽。2.8万亿参数即使只激活1%，每token也有28亿参数，依然需要从HBM搬运大量数据。昇腾的HBM带宽约1.6TB/s，相比H100是劣势，但通过计算与传输重叠可以缓解。Kimi K3很可能使用了多级流水线——预取下一层参数，同时计算当前层。

3. 量化。FP16已经不够，需要混合精度，甚至引入4-bit量化。但代码生成任务对精度敏感，量化要在推理速度和代码正确性之间做平衡。

对比Claude Fable 5的1673分，Kimi K3的1679分优势极小，几乎在误差范围内。Frontend Code Arena这个榜单本身有局限性：它评估的是前端代码生成，不是通用能力。月之暗面可能针对这个场景做了专项优化，比如在训练数据中增加前端代码比例，或者在推理时使用专门的采样策略。

彭博社的报道忽略了一个关键点：Kimi K3的参数量是Claude Fable 5的数十倍，但得分只多了0.3%。这恰恰说明，参数规模的边际收益在递减。真正的突破应该体现在同参数量下的性能提升，或者同性能下的计算成本降低。

从工程落地看，月之暗面面临的问题比榜单分数更现实：推理成本。2.8万亿参数，即使MoE激活率极低，每个token的推理成本仍然远高于Claude。如果用户量上来，算力投入将是个天文数字。他们可能通过torch.compile或自定义编译器做源到源优化，但昇腾的软件栈成熟度不如CUDA，很多优化只能手写。

最后，留一个开放性问题：当参数规模继续增长到10万亿甚至100万亿，现有的稀疏化、量化、算子融合手段还能撑住吗？还是说，我们最终需要像人脑一样，发展出真正的“稀疏计算”架构，而不是在现有硬件上做修修补补？

原文链接：https://www.ithome.com/0/978/670.htm