开发GLM（GLM）时模型偶有惊人乃至不安的能力。2025年10月我们研究强化其网络安全能力，认为系编码延伸。不到一年安全伙伴用其发现真实代码库数千漏洞，模型重塑安全也带新危险，遂设计可信访问计划。近期根本转变是GLM渐助构建AI自身，它完成原需资深工程师团队数周的基础设施任务，将直接改变下一代模型训练。

开发 GLM 时，模型偶尔展现出令我们惊讶甚至不安的能力。

2025年10月，我们开始研究如何增强其网络安全能力。当时逻辑很简单：网络安全是编程的自然延伸。能理解复杂代码的模型也应能理解其漏洞。我们没预料到后续发展。不到一年，安全合作伙伴用 GLM 在真实代码库中发现了数千个漏洞。模型开始重塑网络安全，也带来了前所未有的危险。为负责任地使用此能力，我们设计了可信访问计划。

最近一次震撼来自更根本的转变：GLM 正越来越多地帮助构建 AI 本身。我们看到模型完成了一项基础设施任务，以往这需要资深基础设施工程师团队花数周。当我们意识到这工作将直接改变下一代模型训练方式时，更加确信：我们的继承者正是我们自己创造的 AI 系统。

坦白说，在 GLM-4.7 之前，内部使用 GLM 编程带有某种任务性质，毕竟是自家产物，当时编程产品市场契合尚未到来。如今，GLM-5.3 已成为团队每人不可或缺的每日编程伙伴，并稳步走向取代我们。若趋势延续，给定足够算力和时间，终点是一个能完全自主设计并训练继承者的系统，即递归自我改进（RSI）。

我们尚未到达，但早期形态已出现，以下便是一个早期例子。

将模型从在新硬件上首次成功运行，到能可靠处理生产流量的高性能推理服务，是重大系统工程。GLM-5.3-Flash 的发布遵循此路径。我们在一群超过 10 万颗国产 AI 加速器组成的集群上，从零构建了完整生产级推理服务。GLM-5.3-Flash 的所有生产推理都在此系统上运行。

这并不容易。此前无人以如此规模部署国产加速器集群。我们面临芯片内存容量和带宽相对有限，还需支持新模型架构、100 万 token 上下文窗口和多模态请求。生态不成熟，内核支持不全，许多本应文档化的内容只能猜测。最终工作完成了，并非仅靠基础设施工程师团队，大部分工作由一个由 GLM-5.3 驱动的 Infra Agent 完成。

随后熟悉的一幕发生。GLM-5.3-Flash 以匿名模型名 Ox-Alpha 在 OpenCode 和 OpenRouter 上通过真实使用测试。发布一周内，它成为两个平台最常用的模型，六天处理超 62 万亿 token。

我们实施了一系列激进内存优化，包括用计算换带宽、用通信换设备内存的自定义方法。最终技术栈结合了多项关键技术：线性注意力和 LM Head 的节点内张量并行、ReplaySSM、W8A8 量化、INT8/FP8/BF16 混合精度缓存量化，以及 Layer Split。在此基础上，引入编码-预填-解码（EPD）分离架构。这些优化使端到端服务性能提升约 3 倍。硬件利用效率和单 token 成本均达到可比肩主流 NVIDIA GPU 的水平。

在 Infra Agent 反馈循环贯穿优化过程的情况下，GLM-5.3-Flash 从初始模型适配到生产就绪不到两周，最终端到端吞吐较初始基线提升三倍。图1展示了其从首次成功运行到生产发布的性能轨迹。

在此过程中，我们逐渐意识到 Infra Agent 的工程效力不仅取决于模型代码生成和推理能力，更取决于系统能否持续提供可追溯到具体原因的有效反馈。代码库只提供静态上下文。推理系统中的数值偏差、性能回退和优化目标未达，常源于内核实现、并行策略、通信行为、内存管理和服务编排等多层动态交互。即使智能体理解整个代码库，改动后“数值精度测试失败”“TTFT 增 30%”“输出吞吐降 20%”等反馈仍让它难以确定哪层负责、当前假设为何错、下一步测什么。端到端指标只能告知结果变差，无法解释原因。因此，除提升智能体写改代码能力，还需解决更根本的系统问题：如何将稀疏端到端结果转化为细粒度、可归因、能直接指导下一步行动的工程反馈？这也是为 Infra Agent 构建有效反馈循环的关键。

从端到端指标到可归因反馈

传统推理系统优化不缺测试、日志、剖析工具和微基准，但它们通常分散在不同工具和工程阶段。资深工程师用负载测试结果决定下一步观察什么，逐步检查内核输出、执行时间线、通信事件或线程状态，串联不同工具信息。对智能体，除非这些观察和验证方法被组织成可直接访问、可重复的工作流，否则它能用的反馈依然稀疏。它可能知道吞吐未达标，却仍无法判断：

• 是某个内核耗时过长，还是计算设备闲置？
• 是 KV Transfer 本身太慢，还是高层调度未能及时推进传输？
• 优化对哪些输入形状有效，什么条件会回退？

单一端到端指标无法回答。因此我们正确性测试、运行时日志、执行追踪、运行时事件、微基准和端到端指标纳入智能体迭代工作流，将全系统优化过程拆为可本地观察和验证的步骤。内核级对比验证数值正确；微基准测量特定输入下本地性能；执行追踪和运行时事件揭示计算、等待和通信的时序关系。智能体可为当前假设选合适验证法，而非每次改动后都等全服务部署和端到端负载测试。

我们称此方法为“密集反馈”。“密集”非指给智能体喂尽量多日志指标，而是强调三特性。第一，反馈须足够局部。尽可能绑定特定引擎启动参数、代码改动、内核、输入条件、线程、执行间隔或代码路径，助智能体缩小问题范围。例如不报“融合优化后模型精度下降”，而识别某请求改动前后输出差异，让智能体更好构建最小复现并分析成因。第二，反馈须获取成本低且及时。智能体提假设、做改动或建受控实验时，应有合适验证方式。内核测试或本地微基准能答的问题，不应每次都需全服务部署和端到端负载测试。更短验证周期助其及时纠偏，少在无益假设上费力。第三，反馈须支持客观验证。改动是否正确、性能是否提升，应由参考实现、测试结果和可比实验指标判定。运行时信号助找可能原因，但仅观察间关联不能立根因，仍需受控实验验证特定路径改动是否达预期。三者决定反馈是否可执行。正确性反馈答“计算对否”；系统行为反馈指“时间花哪”；性能反馈定“哪种方案更好、何条件下好”。验证法不必固定顺序，应匹配当前假设，让每次实验答具体问题。

本地验证和端到端测试角色不同。前者早筛错误无效改动并识候选；后者确认本地收益是否转为真实服务改进，及提议改动是否在实际负载引入新回退。基于这些原则，GLM-5.3-Flash 发布建立了工程师、Infra Agent 和实验环境的优化循环。工程师定目标和系统边界；智能体负责分析、假设和代码改动；实验环境提供分层、及时、可验证反馈。三者将以往靠工程师经验串联的诊断过程，变为智能体可持续执行的工程工作流。

这进程包含直接提吞吐的性能优化，以及不立提吞吐但对正确可靠发布至关重要的 bug 修复。以下三案例说明密集反馈如何助智能体确保系统“算得对”、“为何不够快”、“如何更快”。

正确性反馈：帮助智能体判断模型计算是否正确

推理性能优化须以数值正确为基。对智能体，验证始于确切建推理引擎执行哪些计算。高层并行策略改变内核输入划分、执行路径和结果合并方式。仅未划分条件下测内核输出不足覆盖实际部署行为。为此，我们建立从推理引擎并行策略到内核实现的映射，将系统级部署配置转为智能体可逐个验证的内核级任务。这帮智能体识别并行配置涉及哪些内核、输入如何划分、哪些计算路径需与未划分实现比对。

在此基础上，我们让智能体比对不同划分与未划分执行路径的数值精度。同输入下，对齐计算语义和输出位置后，检查不同执行方法结果是否满足数值误差容限。这连通并行配置、内核路径和观测误差。一旦测试暴露差异，智能体可继续查相应划分方案和计算路径，而非从全模型级重启诊断。正在此内核验证中，我们发现 KDA 内核的 Context Parallelism（CP）路径存在数值精度问题。CP 与非 CP 结果差异将调查指向并行执行引入的状态传播和合并计算。CP 划分需合并不同上下文分片状态。其核心计算可简化为：M = tl.dot(Mchunk, M)（合并分片间状态变换），Snext = tl.dot(M, S) + H（更新下一分片初始状态）。

原实现中，tl.dot 默认用 TF32 计算求更好性能，即使输入为 FP32。此较低计算精度导致误差在变换合并和状态更新中累积，长上下文下更明显。修复是对两操作显式设 input_precision="tf32x3"，结合三次 TF32 Tensor Core 操作产更高精度结果，在保 Tensor Core 性能优势同时减累积误差。

此例中，反馈环境在问题浮现前已发挥作用。并行到内核映射定测什么；划分与非划分路径比对暴露数值差异；计算精度分析解释来源；回归测试提供持续验证基础。对工作流，这将系统级并行设计变为可执行、可追溯的正确性任务。本地验证后，候选实现仍须回目标部署做模型级精度和服务性能终验。相关数值精度修复已合并至 Flash Linear Attention，详见 PR #1180。

系统行为反馈：定位 KV Transfer 并发瓶颈

对系统级性能问题，明确定义测试场景和性能约束给智能体识别异常和选分析方向的起点。推理优化工程师为智能体定测试场景，含仅 Prefill、Prefill+KV Transfer、仅 Decode，以隔离不同阶段及组合的性能效应，并设各场景验收标准。如同等工作负载下，Prefill+KV Transfer 与仅 Prefill 基线性能差距不超 5%。

但智能体发现某些场景差距超 20%。此反馈将调查缩至 KV Transfer 引入的额外开销和并发交互。智能体详查 KV Transfer 时间线，发现异常：这些场景中，Python 端 KV Transfer 执行从未与 DeepEP dispatch/combine 调用间隔重叠。此观察引智能体循调用链查 DeepEP 与 Mooncake Transfer 间并发，至 Python/C++ 边界。在我们用的 DeepEP v1.2.1 中，intranodedispatch 和 intranodecombine 均未显式释放 Python GIL。此外，dispatch 需接收 token 数时，会在 CPU 等待 GPU 返回该信息。

关键是进 C++ 不自动释 GIL。这些调用持锁时，同进程负责 Mooncake Transfer 的 Python 线程无法及时获 GIL，传输任务调度和提交延迟，减 KV Transfer 与后续计算重叠机会。即使底层传输机制支持异步，高层提交阻塞可阻预期并行充分实现。源码也直证：同版本 internode_dispatch 已显式释 GIL，注释说明为避免 CPU 等待时阻塞他线程 KV Transfer。这进一步支持智能体对节点内路径评估。

关键修复是在相关 C++ 执行间隔释放 GIL，让 Mooncake Transfer Python 线程及时推任务。修复须对照时间线和原性能约束验证。前者查调度传输是否获与计算重叠机会；后者定此改动是否改善实际服务性能。同测试条件下，修复后 Prefill+KV Transfer 与仅 Prefill 差距降至 1% 内。

此例中，性能约束先将“不达预期”变明确定义测试差异；时间线再将调查缩至两组件间并发；终代码分析定位 GIL 持有范围。密集反馈连通端到端性能、跨层运行时行为和特定实现细节，为智能体每步分析供证。

性能反馈：立足现有内核优化专长并转化为系统级收益

内核优化须答两问：如何定优化有效，何处找有希望方向。一，内核性能须在推理引擎实际执行环境评。如给计算内核更多资源或缩短自身时间，却留更少给 KV Transfer 内核，终拖慢整体流水线。智能体须超越单内核延迟，在目标负载、资源约束、任务重叠和端到端收益背景下建正确优化目标。二，大量优化专长嵌于 SGLang、Flash Linear Attention、DeepGEMM 等手写内核。智能体需从此代码提优化技巧及适用条件，为当前内核和目标硬件开发候选方案，并通过实验验实际效果。现有代码供方向；系统反馈定优化实践是否成立。

我们让 GLM-5.3 驱动的 Infra Agent 从跨代码库、语言、硬件的现有内核学优化技巧。通过增量和消融实验，将其提炼为含适用条件、变换法、资源约束和验证证据的“优化骨架”。对新内核，智能体从骨架始，用剖析和分层测试重评分块、内存访问和资源分配策略。已验改动及适用条件反馈回骨架库。工程师主要定目标和约束，审涉数值语义、并发行为和生产风险的关键改动。

图4展代表性 KDA Decode 内核性能演进。引入 ReplaySSM 用计算换内存使内核执行时间从 v0 到 v1 首增。智能体 division 优化使 v1 时间减 9.6%。随后因收到计算为主瓶颈反馈，Infra Agent 发现原实现沿 V 维分块，致相同 FP32 归一化和门控计算重复四次。它将分块合并入单线程块，共享中间结果留寄存器，以单次 warp 级规约替冗余逐块计算。牺牲些并行，从源头消冗余计算，较 v2 提速 1.71 倍。此例中，GLM-5.3 驱动的 Infra Agent 从现有实现提取优化专长并用于跑自身推理的内核。从骨架始调各组件，用分层验证决留何改，靠端到端性能定实际价值。已验洞见回流骨架库。模型由此参与优化自身推理系统，每次部署积累的经验减下轮优化工程力。

让反馈驱动行动，让实验检验假设

三案例共表，反馈价值不在量，而在是否助智能体答当下问。大量非结构日志可掩关键信号；覆盖不全剖析可致错误归因；微基准有效的优化或难转端到端收益。建反馈环境不只供测试日志性能数据，还需指明每类观察可支何判断、限何在、哪些结论须进一步实验确认。工程师在此过程有三关键责：定优化目标和系统约束、建智能体可直接用反馈环境、审涉系统架构异步并发和生产风险的关键改动。此框架内，智能体提假设、实改动、跑实验，再用反馈保留修订或拒当前法。正确性、稳定性和端到端性能共定终验标准。

回望 GLM-5.3-Flash 发布，内核数值精度 bug、跨 Python/C++ 边界并发问题、关键内核性能优化各代表不同层工程挑战。通过本地测试、跨层观察和分层基准，初模糊异常渐变为可测工程假设。复杂系统问题被拆为系列可观察、可实验测迭代与可归因结果。正此反馈循环中，智能体编码推理能力转化为可验证工程进展。GLM-5.3 驱动的 Infra Agent 助建推理基础设施。工程师与智能体共优的系统转而使 GLM-5.3-Flash 可靠服务用户。模型优化系统；系统运行模型。 这力证缩短系统工程周期不只需更强模型能力，还需使模型持续收反馈、测判断、修行动的智能体工程循环。

当然，我们尚未达递归自我改进。选目标、设边界、评风险仍属人责。我们相信人类应长此守住此线。但那些数字——两周、三倍吞吐、10 万加速器——告诉我们，此边界进展不会仅因我们意愿而放缓。

社区普遍赞赏中国团队在出口管制下建成十万国产加速器的生产级推理系统，但不少用户对Z.ai的定价飙升、实际响应慢与品牌认知度低提出质疑，另有少数人指控其训练手段不正当。

认为美国芯片出口限制反而加速了中国自主AI基础设施创新

• 较多人指出，美国对芯片的短视封锁迫使中国AI产业要么适应要么自研，Z.ai据此建成超十万国产加速器集群并写出扎实技术报告，堪称壮举；也有人好奇是否真实现端到端本土制造（较多人）。
• > 美国对芯片的短视保护迫使中国AI产业适应或死亡，而他们用发明给出了回应（@jonstewart）

赞赏其生产级推理系统与务实技术写作

• 较多人认可文章展示的激进内存优化与集群工程像真正懂行的人手笔，而非空谈炒作，过去GLM也偏技术导向（较多人）。
• > 整篇读起来像工业级自动研究，却是由切实理解底层的人完成的（@throwa356262）

质疑Z.ai定价飙升且实际服务体验不佳

• 较多人发现套餐价格从以往约20美元涨至80美元且贵过Claude，实际使用推理像蜗牛并很快触达严格限额，推测是扩展瓶颈所致（较多人）。
• > 若价格这么快就猛涨，说明他们肯定撞上了极其严重的扩展上限（@embedding-shape）

不满文章预设读者熟知GLM与z.ai

• 部分读者表示根本不知GLM或z.ai为何物，批评厂商傲慢地假设人尽皆知，并疑问为何不选更知名的对手（较多人）。
• > 文章让我立刻困惑“GLM到底是什么”，他们未免太想当然（@rob74）

指控Z.ai通过非法路由竞品请求进行蒸馏

• 少数人指责其部分基础设施来自把付费客户请求秘密导给Anthropic模型以实施蒸馏攻击，并非完全自研（少数人）。
• > 除了那些通过非法把客户请求导给Anthropic模型做蒸馏得来的基础设施之外（@bbor）

有价值的补充

• 完整版GLM-5.3（744B混合专家）可通过从NVMe固态硬盘流式加载专家参数，在单台128GB内存的MacBook Pro M5 Max上运行，多盘条带后速度达每秒3.5令牌且输出逐字节一致（@Argonautlabs）。