Scaling Law 不会告诉你：模型越大，Bug 越诡异
Scaling Law 告诉我们会随着参数量和数据量的增长，模型能力会稳定提升。但 Scaling Law 没有告诉你的是——当模型规模跨越某个阈值后，服务化过程中会出现概率性的、极难复现的 garbled outputs（乱码输出）。
智谱 AI（THUDM）在 4 月 29 日发布了一篇技术博客，题为 Scaling Pain: Debugging GLM-5 Serving at Scale，详细公开了他们在服务 GLM-5 时遇到的大规模推理问题及调试方法论。这篇帖子获得了 843 个赞和 295 次收藏，在社区引发了广泛讨论。
问题：偶发性乱码，只在大规模服务时出现
GLM-5 是一个 744B 参数的 MoE 模型。在单机或少量机器上测试时，一切正常。但当部署到生产级别的分布式集群后，团队遇到了一个诡异的问题：
输出中偶尔出现 garbled text（乱码文本），但这种错误极其罕见且难以复现。
这不是常见的编码问题或 tokenization 错误——它只在特定的分布式服务配置下、以特定的概率出现。团队花了大量精力才建立起可靠的复现流程。
调试方法论
智谱团队在博客中分享了三步调试框架：
| 步骤 | 方法 | 产出 |
|---|---|---|
| 复现 | 构建确定性测试用例，在特定 seed 下强制触发 | 可重复的 garbled output 样本 |
| 定位 | 逐层检查分布式推理管线中的张量通信 | 发现特定节点间的数值漂移 |
| 修复 | 调整混合精度策略，引入数值稳定性 guard | garbled output 消除，性能无损 |
核心发现是：在大规模 MoE 推理中，不同 expert 间的数值精度不一致会累积到足以影响输出质量的程度。这在高并发场景下尤为明显。
为什么这条信息重要
这篇博客的价值在于它是少有的公开披露大模型服务化 Scaling Pain 的一手材料。行业内关于”模型能力”的讨论铺天盖地，但关于”如何让 744B MoE 模型在生产环境中稳定运行”的分享屈指可数。
对于正在考虑自部署国产大模型的企业和开发者来说，这些信息极具参考价值：
- 不要假设单机测试通过就能直接上生产：分布式推理引入了全新的故障模式
- 数值稳定性是 MoE 的隐藏挑战：expert 并行架构下，不同 GPU 间的精度漂移会被放大
- 建立确定性复现管线比盲目调参更有效：智谱团队的第一步是构建可复现的测试用例，而不是直接修改模型代码
行动建议
如果你计划在生产环境中部署 GLM-5.1 或类似规模的国产 MoE 模型：
- 在上线前进行压力测试：模拟生产级别的并发量，观察是否出现偶发性 garbled output
- 监控数值精度：在不同 GPU 节点间检查激活值的分布差异
- 参考智谱的混合精度策略：他们对某些 layer 采用 FP32 而非 BF16 的策略值得借鉴
- 关注 THUDM 的后续更新：智谱团队已经将修复合入 GLM-5 的开源代码
GLM-5.1（3 月 27 日发布）已经是一个成熟的版本，在 SWE-Bench 上达到 94-95% 的 Claude Opus 4.6 水平。这篇博客更像是给后来者的一份”避坑指南”——从 Scaling 的痛苦中提炼出的工程经验。