从模型跑通到承载线上流量，两周

智谱在一篇技术复盘里讲了 GLM-5.3-Flash 的上线过程：生产推理完全跑在一套超过十万张国产加速卡的集群上，从模型首次跑通到能够稳定承载线上流量，用了不到两周，端到端吞吐相对初始基线提升到大约三倍。参与这件事的不只是基础设施工程师，还有一个由 GLM-5.3 驱动的 Infra Agent——工程师定义目标和系统边界，智能体负责分析、提出假设、改代码。

夕阳下的风力发电机阵列与麦田

硬件之外，还有一堆"没人走过"的问题

显存容量和带宽相对有限，同时要支持新的模型架构、百万级上下文窗口和多模态请求；生态不成熟，内核支持不完整，本该有文档的地方常常只能靠猜。这是 "人少、时间紧、没有先例" 的典型现场，也是最容易被低估的部分——它考验的不是某一行代码写得漂不漂亮，而是能不能在没有参考实现的时候把系统推到可用的状态。

真正的门槛：把端到端指标变成可归因的反馈

文章里最值得借鉴的一段，是它对 "反馈" 的拆解。"准确率测试失败""首 token 延迟涨了三成""吞吐掉了两成" 这类结论只能说明变差了，说不出问题在哪一层：是某个 kernel 太慢，还是计算设备在空转；是 KV 传输本身慢，还是上层调度没有及时推进；哪个输入形状下优化有效，什么条件下又会退化。

团队的做法是把正确性测试、运行日志、执行轨迹、运行时事件、微基准和端到端指标都接进智能体的迭代流程，并提出 "稠密反馈" 的三个要求：反馈要足够局部，能落到具体的 kernel、输入条件和代码路径上；获取要便宜及时，能用微基准回答的问题不必每次都跑全链路压测；必须支持客观验证，相关性不等于根因，结论要靠对照实验说话。依靠这条回路，团队定位到了 KDA kernel 在上下文并行路径上的数值精度问题。

可迁移的作业：先修反馈回路，再谈模型

这套方法论里最 "贵" 的部分是十万张卡，而最可复用的部分恰恰不在硬件上：把资深工程师脑子里的诊断经验，拆成机器可以连续执行的观察与验证动作。任何想把 AI 用进生产系统的团队，第一件事都不是再换一个更强的模型，而是先问自己——我的系统能否持续产出可追溯、可复现、可验证的反馈。模型优化系统，系统运行模型，这句话的分量在于：它把 AI 落地的重心，从模型能力挪到了工程闭环上。