Z.ai称，GLM-5.3参与优化服务GLM-5.3-Flash的推理系统。系统从初次跑通到生产就绪用时不到两周，端到端吞吐相对初始基线提升约3倍。
<2周
生产就绪。
3.22×
图表终点。
10万+
国产加速器。
图注：Z.ai 展示的 GLM-5.3-Flash 端到端吞吐优化曲线，终点为 3.22 倍基线。
这张曲线图的横轴是开发时间，纵轴是端到端吞吐增益。优化过程分成系统启动与调度、并行与通信、内核优化、上线四个阶段。图表标出的最终点是3.22倍，Z.ai在官方账号中将结果概括为相对初始基线提升约3倍。
真正的工程对象是一套推理系统。
Z.ai的官方技术文章称，这套系统部署在超过10万枚中国制造的AI加速器上。它承担GLM-5.3-Flash的生产推理。硬件单卡内存和带宽受限。模型还要处理最长1百万Token的上下文与多模态请求，软件生态中的算子支持和文档也不完整。
优化工作落到了具体的系统层。包括线性注意力与语言模型头的节点内张量并行、ReplaySSM。还包括混合INT8/FP8/BF16缓存量化。系统还用EPD架构拆开编码、Prefill和Decode的调度。每项修改都伴随着计算、显存、通信和调度之间的交换。
Agent缺少的输入，不是更多日志。
当端到端吞吐下降20%，这个数字只说明结果变差。它无法直接指出问题位于哪个层，也无法告诉Agent应该验证哪条假设。Z.ai把正确性测试、运行时日志、执行轨迹、运行时事件、微基准和端到端指标接入同一条迭代链。这套方法被称为“dense feedback”。
这套反馈有三个工程条件：信号要尽量贴近具体内核、输入条件或代码路径；获取成本要低，能在假设提出后快速返回；结果要能通过参考实现、测试或受控实验核验。Agent因此可以先验证局部变化，再决定是否进入完整服务测试。
▸ 正确性反馈：结果有没有算对。
▸ 系统行为反馈：时间消耗在哪个环节。
▸ 性能反馈：哪个方案在什么条件下更快。
三个优化案例说明了反馈如何落到代码。
第一处是KDA上下文并行路径中的精度漂移。随着序列变长，TF32舍入误差在连续状态矩阵合并中累积。问题最终定位到Flash Linear Attention，相关修复已合入上游第1180号PR。
第二处是KV传输没有和DeepEP调度重叠。Agent沿着Python与C++之间的调用链追踪，找到节点内路径没有释放GIL这一环节。Z.ai称，修复后传输开销从30%以上降到1%以下。
第三处是一个Decode内核因为分块方式重复计算同一归一化过程四次。重构后获得1.71倍加速。这个优化思路来自Agent读取多个项目内核后整理出的“优化骨架”。相关项目包括SGLang、Flash Linear Attention和DeepGEMM。
人类工程师的工作位置发生了移动。
Jie Tang在帖子中写道，工程师仍然定义目标、搭建反馈环境，并审查高风险修改。审查范围包括数值语义、并发行为和生产风险。GLM-5.3负责分析、提出假设和改代码，实验环境负责返回可观察、可验证的结果。
这条分工把基础设施Agent和普通代码生成工具区分开来。代码能否写出来只是起点。Agent还要根据局部反馈判断下一次实验该测什么，以及改动是否改善了目标路径。工程师需要设计反馈接口，并把可接受的风险范围写进系统。
Z.ai把这次工作称为“递归自我改进”最小闭环的出现。当前公开材料显示，模型参与优化了服务自身的推理系统。吞吐曲线在两周内从1.00倍基线走到3.22倍。目标选择、边界设定和高风险审查仍由人完成。
SOURCES。
Z.ai 官方技术文章：Toward Recursive Self-Improvement。
Z.ai 官方账号与 Jie Tang 公开帖子。
图片来源：Z.ai 官方技术文章配图，经本地转为 JPEG。