它亲手揭开了 Scaling 时代的皇帝新装。
原来，把千亿参数的大模型变成复读机一样只会反复说同一个东西，并且代码生成也会出现乱码的情况。不需要黑客攻击、数据污染也可以实现。
只需要把并发请求调高一点。
没错，没有听错。这两天在技术圈里流传很广的 " 智谱降智门 " 的核心猛料就是这样的情况。自己发出来的叫 Scaling Pain
规模扩张所造成的痛苦。
但是恕我直言，这不是阵痛，而是高烧不退、系统在叫喊。
看完他们几千字的技术博客之后，我只有一个感觉：我们所有人可能都低估了把 AI 模型真正 " 用起来 " 的残酷性。
以前吹的牛，现在都要用一行行崩溃的日志来还。
智谱的 GLM-5，很厉害吧？国产大模型的一个排面。
但是自从它全面开放之后，特别是接住大量的 Coding Agent 任务的时候起怪事就出现了。
有些用户发现，让它写一段复杂的逻辑时会突然开始鬼打墙，并且同一行代码无限重复。
或者输出一堆看不懂的乱码以及生僻字。
更奇怪的是，用同样的请求在自己家里的环境里反复测试，并没有出现什么问题。
问题一直无法复现。
用户那边骂娘，工程师这边挠头。
感觉就像是买了一辆顶级超跑，在 4S 店试驾的时候地板油丝滑顺畅，一回家上高速之后发动机就开始咳痰了。
你把车开回去检修，师傅检测后各项指标都很好。
然后你就陷入了 " 车主傻 X" 和 " 车有病但查不出 " 的罗生门之中。
智谱的工程师也经历了这样的循环。
他们开始的时候也是懵的。模型有问题吗？可以离线测试几百次，结果非常稳定。
直到有人灵光一现：线上和线下最大的不同是什么？
每秒成千上万的并发请求，如同海啸一般冲击着推理服务器的大坝。
于是他们模拟线上高压环境，疯狂提高负载。
果然，妖魔鬼怪现身了。
每处理一万次请求就会产生三个到五个 " 精神病 " 的输出。
万分之几的概率，似乎不大？
但是智谱的调用量每天是数亿次。
这就意味着每天都有成千上万的用户在某个时刻会遇到一个发疯般的 GLM-5。
生产力本应该是 AI 编程助手的宗旨，但是这样就出问题了。
原因挖出来之后，非常底层、很硬核。
简单地说，就是大食堂（GPU 集群）在高峰期要给几万人（并发请求）打饭。
厨师（计算核心）的手速很快，但是负责递盘子、收碗筷的后勤系统出问题了。
盘子还没有洗完就擦干了，就被急着用了起来之后下一个客人吃到残渣（KV Cache 竞态）。
菜还没有炒好，就被端上桌了，客人吃的是夹生的（HiCache 加载时序问题）。
根本问题在于 " 预填充 " 阶段出现瓶颈。
可以将 AI 生成的回答看作两种生命状态：先理解长问题（Prefill），再一个字一个字地往外蹦答案（Decode）。
以前人们认为 Decode 是慢活、瓶颈。
但是现在，在动辄几万 token 的代码生成场景中，理解你那冗长的需求说明（Prefill）已经成了最累、堵得慌的过程。
这直接造成了内存、通信的 " 春运 "。
为了治疗这个疾病，智谱的工程师们使出浑身解数。
比如给 KV Cache（可以理解为模型的 " 短期工作记忆 "）做分层存储，每个 GPU 只保存一部分数据，在需要的时候再广播拼接起来使用。
比如，在重要的数据加载和计算步骤之间，强制加入 " 确认眼神 " 的同步锁，并且没有准备好就坚决不开始工作。
把异常率从 " 万分之十几 " 降到 " 万分之三以下 "。
不错吧？工程团队的实力毋庸置疑。
但是我的 " 暴论 " 来了。
这篇博客给我印象最深的，并不是他们有多厉害，解决了多少难题。
而是它无情地暴露出所有 AI 公司，包括 OpenAI、谷歌等，在背后默默承受着的真相：
AI 竞赛的第一阶段就是比拼参数量、排行榜分数。
下半场就是比拼运维、工程，看哪家的 "AI 大食堂 " 在流量洪峰的时候不会垮掉。
近几年来，镁光灯下的华丽比拼已经习以为常：我的模型参数量是你的十倍以上，MMLU 分数也高出 0.5 分。
胜负手只存在于实验室中。
智谱这篇 " 痛苦文学 " 一巴掌把我们全都打醒了。
它告诉我们，决定一个 AI 产品生死的，并不是 arXiv 上最新的论文，而是深夜机房里运维工程师面对满屏报警时揪着头发的那个时刻。
它叫 "Scaling Pain"。
我更愿意称其为 " 系统债 "。
所有的疯狂扩张、追逐 Scaling Law 时所欠下的技术债，在现实世界中的高并发铁拳之下，被一次性收回。
这不只智谱一家的损失。
所有把模型从 Demo 推到亿级用户的公司，都会踩上这个坑。
有圈内的朋友看完之后就跟我吐槽说，这个问题半年前就有同行怀疑是 KV Cache 一致性在高压力下出现的边界问题。
果然，太阳底下没有新鲜事。
所有的科技巨头，无论其表面如何光鲜亮丽，在地下都有人默默地清理着下水道。
智谱的坦率，值得称赞也让人感到痛苦。
这就等于把自家系统的软弱之处以及被攻击的漏洞全部暴露给所有的竞争对手和用户。
也给所有人展示了什么叫真正的 " 工程化能力 "。
这不是为了展示自己的技巧，而是为保命。
因此，不要再只盯着哪个模型又多支持了 100K 上下文了。
问一下，当一万个用户同时把 100K 的文本塞给它去总结的时候，会不会当场 " 降智 " 给你看。
问问自己，在业务高峰期的凌晨三点，那个酷炫的 AI Agent 会不会突然开始胡言乱语。
但是无法支撑起 Scaling 的工程系统，就是走向 " 降智 " 的捷径。
智谱的这篇博客，吹响了下半场竞赛的号角。
下一次比赛的主要评判标准，可能不再是对智商的考验（Benchmark 分数），而是在保证服务质量的同时应对突发流量冲击的能力。
未来一年，更多的 " 明星模型 " 将会在大规模应用的压力下暴露出来。
也会发现，那些把 " 运维 "、" 系统 " 刻在基因里的公司后来居上。
AI 的魔力，终将归于电力一样的基础设施。
而基础设施没有神话，只有深夜的警报声以及一颗颗汗水滴落的声音。
这场 " 降智 " 风波，与其说是智谱的问题，不如说是中国科技界走向成熟的一个标志。
潮水退去之后，才发觉谁在裸泳。
当并发到极致的时候，才知道谁的系统在裸奔。
下一个被 "Scaling Pain" 绊倒的人是谁？
