他们愿意牺牲GPU利用率也要守住的设计，到底藏着什么秘密

朋友，你有没有发现一个有趣的现象？当大多数AI公司都在拼命优化推理速度、压榨GPU利用率的时候，DeepSeekV4却做了一个让人意外的选择——为了保留一个叫批次不变性的特性，心甘情愿地放慢了脚步。这背后到底有什么考量？今天咱们就来好好聊聊这个话题。

一个常常被忽视的设计难题

先说说批次不变性是什么意思。打个比方，你今天向AI问了同一个问题，可能是和A、B两个请求拼在一起处理的；明天你再问同样的问题，可能恰好和C、D两个请求凑成了一组。只要系统用了批次不变性设计，那么无论批次怎么组合、GPU负载怎么波动，同一个问题必然得到同样的答案。这听起来很简单对吧？但实际操作中，光是让kernel归约顺序保持一致，就足以让工程师们抓狂。

DeepSeekV4面临的真实情况是，它的系统里堆叠了太多复杂的东西——长上下文attention、压缩KV、稀疏注意力、MoE、FP4/FP8、Muon、mHC、自研kernel……随便数数就有十来个关键组件。组件越多，可能引入数值误差的环节就越多。如果没有一条硬约束来保证底层计算结果的稳定性，那训练过程中的微小扰动可能会改变采样路径，采样路径一变，reward信号、师生对齐效果、训练信号全都会跟着变。最终可能导致模型行为失控，而这个失控的来源，你可能根本定位不到。

他们为什么坚持这么做

DeepSeek的工程师们显然想得很清楚这个问题。V4有预训练、SFT、RL、on-policydistillation、推理服务等多条链路同时运行。如果底层计算路径不稳定，当模型表现出现波动时，你根本无法判断问题究竟出在数据变化、RL调整、蒸馏效果、量化精度，还是出在batch组合方式上。有了批次不变性这个约束，工程团队至少可以排除一个干扰项——问题不可能来自batch组织方式的变化。

这种确定性对于需要精准复现实验结果的研发场景来说太重要了。一个异常行为如果能稳定复现，那它就能被修复；一个异常行为如果随机出现，那它就几乎无解。DeepSeek选择牺牲一部分性能，换来的正是这种可复现性。

代价与收获的权衡

话说回来，为了这个特性，DeepSeek放弃了不少常见优化手段。比如split-KV优化会把单条序列的注意力计算分摊到多个SM上提高利用率，但这种方式会改变并行归约路径，影响逐比特一致性。矩阵乘法中的split-K优化也是同理，把归约维度K切开并行计算，多路并行求和后再归约，浮点加法顺序一变，结果可能就不完全一样了。

DeepSeek的解决方案是双管齐下：在attention侧准备两套计算程序，GPU满载时用一套，不满时用另一套，但两套程序的结果必须逐比特一致；在GEMM侧用自研DeepGEMM替代通用的cuBLAS，在受约束的框架内完成运算。工程复杂度大幅上升，但换来的是训练推理RL全链路可复现的能力。

这种选择意味着什么

具体来看，DeepSeek牺牲的是GPU利用率、小批量处理速度、原生算子兼容性、部分稀疏加速自由度，换取的是训练推理RL三个阶段逐比特可复现、长上下文和Agent系统的稳定度、多机多卡结果完全对齐。对于从事复杂推理任务研发的团队，对于需要在生产环境部署长程推理能力的企业用户，这个交换其实是超值的。

当你真正需要精准控制模型行为、需要快速定位异常来源、需要在大规模分布式环境中保持结果一致性的时候，你就会明白DeepSeek这个选择的高明之处了。有些东西表面上看起来是牺牲，实际上是为更重要的目标腾出了空间。