On September 17, Zhipu's GLM team published a technical blog post whose title makes you pause on two phrases: recursive self-improvement (RSI), the notion of a system improving the very machinery that improves it, and "built its own" (How GLM Built Its Own Inference Infrastructure). Set the concepts aside for a moment and put the numbers on the table first. All production inference for GLM-5.3-Flash runs on a cluster of more than 100,000 Chinese-made AI accelerators; the trip from the first successful run on the new hardware to carrying full production traffic took less than two weeks. End-to-end serving performance has been lifted to roughly 3× the initial baseline, and hardware efficiency and per-token cost have reached levels comparable to mainstream NVIDIA GPUs. In anonymous pre-release testing, under the alias Ox-Alpha (which the Chinese community reads as "here comes the bull"), it became the most-used model on both OpenCode and OpenRouter within a week, processing more than 62 trillion tokens in six days.
What this material answers is not "how strong is the model," but a more practical question: how, exactly, is large-scale inference infrastructure built? This article takes the machine apart in three layers: foundation engineering (engine, architecture, and memory), feedback engineering (the dense feedback methodology), and the engineering loop (how humans and Agents divide the work). The primary source is the September 17 RSI post, supplemented by the August 26 GLM-5.3-Flash official announcement and technical blog. Post-training is the preceding chapter of this model's story; we took it apart in A Generational Upgrade Without a New Engine: GLM-5.3 and the Second Half of Post-Training, which makes a useful companion read.
Foundation Engineering: Breaking "Nobody Has Done This" into a Checklist
Moving a large model from "first successful run on new hardware" to "stably serving production requests" is heavy systems-engineering work. What makes this round unusual is that three constraints were present at once: the domestic chips offer relatively limited memory capacity and interconnect bandwidth; the model side must support a 1M-token context window (the maximum input the model can process in one go) and multimodal requests; and the software ecosystem is still early, with incomplete kernel support, so much of the reference material had to be worked out by the team itself. GLM-5.3-Flash is also the first natively multimodal model in the GLM-5 family (320B total · 18B active), so when it came to serving this model on this hardware, there was almost no ready-made experience to borrow.
The team broke the engineering moves into four buckets. Engine: a dedicated inference engine built for this hardware on top of the open-source inference framework SGLang. Architecture: a production-grade Encode-Prefill-Decode (EPD) disaggregated serving architecture, splitting multimodal encoding (turning images and other inputs into representations the model can process), prefill (digesting the input prompt), and decode (emitting tokens one by one) into worker pools that are scheduled and scaled independently.
Memory: a combined playbook of trading compute for bandwidth and trading communication for memory, including intra-node tensor parallelism for the linear-attention layers and the LM head (tensor parallelism spreads one layer's matrices across the accelerators inside a single node; the LM head is the output layer that maps hidden states to token probabilities), ReplaySSM (replaying a stretch of computation to trade for memory), W8A8 quantization (both weights and activations compressed to 8 bits), mixed INT8/FP8/BF16 cache quantization, and Layer Split. Model: the architecture itself is designed for extremely low-cost inference: a hybrid of sparse attention and linear attention, attention variants whose compute and memory grow far more slowly with context length than the standard full-attention mechanism, a first for the GLM family; mHC (Manifold-Constrained Hyper-Connections, further improving scaling efficiency); and IndexPool (weighted-pooling the indexer's four key vectors into one). Compared with GLM-5.3, attention computation drops to 1/3 and the KV cache (the stored intermediate state of already-processed context) shrinks to less than 1/4.
The four are not parallel efforts but a relay: the model architecture is responsible for computing less, the engineering stack for computing cheaply, and the two directions merge in a single delivery, one handing off to the other. The final scorecard: end-to-end serving performance lifted to roughly 3× the initial baseline, with per-token cost comparable to mainstream NVIDIA GPUs. The official conclusion is stated with restraint: domestic chips can support frontier-model inference in large-scale settings, efficiently and economically. The bar for verifying that sentence sits far above "it runs"; it demands a cost line proven under full production traffic.
Feedback Engineering: Dense Feedback Turns Debugging Intuition into a Product
Had the post only reported optimization results, it would read like most engineering retrospectives: throw people at the problem, burn calendar time, produce numbers. What sets it apart is the method in the middle, which the team calls dense feedback: feedback delivered at fine grain at every step of the loop, instead of only at the sparse end-to-end endpoints.
The problem is defined with precision. In inference-system optimization, an Agent seldom struggles to write code; what it lacks is the answer to "why did the system get worse?" When an end-to-end metric reports "throughput dropped 20%," it only signals that something broke. It cannot tell the Agent which layer broke, where the current hypothesis went wrong, or what to verify next. Senior engineers run on intuition earned over years: when to read an execution timeline, when to run a microbenchmark, which module's outputs to compare. What dense feedback does is turn that intuition into feedback mechanisms an Agent can call directly.
It has three traits. Local enough: feedback must bind to a specific launch parameter, code change, kernel, input condition, thread, or execution interval, helping the Agent shrink the search space. A report that "accuracy dropped after a fusion pass" gets the Agent nowhere; a before-and-after output diff for one specific request lets it construct a minimal reproduction. Cheap and timely: questions a single kernel test or a local microbenchmark can answer should never require spinning up a full deployment and an end-to-end load test every time; short verification cycles let the Agent correct course early instead of burning resources on hopeless hypotheses. Objectively verifiable: whether a change is correct, and whether performance genuinely improved, is adjudicated by reference implementations, test results, and comparable experimental metrics; runtime signals can indicate the direction of causality, but correlation does not establish root cause.
Three kinds of feedback each answer one question: correctness feedback answers "is the computation right"; system-behavior feedback answers "where does the time go"; performance feedback answers "which approach is better, and under what conditions." The team also warns of the flip side: dense does not mean pouring every log and metric you can collect into the Agent; a flood of unstructured logs actually drowns the key signals in noise. And performance profiles with incomplete coverage steer attribution in the wrong direction.
Three Case Studies: From "It Got Worse" to "Why It Got Worse"
The post uses three case studies to show this feedback machinery at work, one each for "is it right," "why isn't it fast enough," and "how to make it faster."
Correctness: precision drift on the KDA context-parallel path. KDA is one of the model's kernels. Context parallelism (CP) requires merging the states of different shards, and the essential computation reduces to two lines of matrix multiplication: merge the state transformation across shards, then update the initial state of the next shard. In the original implementation, tl.dot (the matrix-multiply operator in Triton) defaulted to TF32 even with FP32 inputs in pursuit of performance (TF32 is a floating-point format on NVIDIA GPUs with lower precision than FP32). The precision loss accumulated through the repeated merges and updates of a long context, and the error grew steadily more visible. By comparing results from the CP and non-CP execution paths, the Agent localized the problem to state propagation and merging. The fix explicitly set both operations to input_precision="tf32x3", composing three TF32 tensor-core operations to recover higher precision while balancing error against performance. The fix has since been merged upstream into the open-source Flash Linear Attention project (PR #1180).
System behavior: a concurrency bottleneck between KV Transfer (handing the KV cache from one stage's workers to another's) and DeepEP. In scenario-by-scenario tests defined by the engineers, KV transfer and the scheduling of DeepEP, an open-source communication library for expert parallelism (the pattern that routes tokens to distributed experts), failed to overlap effectively; overhead exceeded 20%, while the comparison test demanded <5%. The Agent kept tracing along the Python and C++ call chains and found that the intra-node path did not release Python's Global Interpreter Lock (GIL) in time, so transfer tasks could not proceed; the cross-node version's source code, by contrast, already released it. After the fix, KV Transfer's overhead dropped from over 20% to below 1%, comfortably inside the <5% target.
Performance: the 1.71× on the KDA Decode kernel. ReplaySSM, introduced to trade for memory, actually made the kernel slower in the move from v0 to v1. A division optimization cut v1's execution time by a further 9.6%. The Agent then received feedback that compute was the bottleneck and found that the original implementation split along the V dimension, so the same set of FP32 normalization and gating computations was executed four times over. It merged tiles into a single thread block, kept shared intermediate results resident in registers, and replaced per-tile recomputation with a warp-level reduction (aggregating results inside a single GPU thread group), trading part of its parallelism for the elimination of redundancy, for a 1.71× speedup over v2.
In this stretch of optimization, the provenance of the method deserves more attention than the numbers. The Agent distilled "optimization skeletons" from existing kernels in SGLang, Flash Linear Attention, DeepGEMM, and other open-source projects. Each skeleton carries a four-piece kit: applicability conditions, transformation method, resource constraints, and verification evidence; the Agent then judges applicability against the current system's feedback. For the first time, optimization experience moved from being an engineer's personal know-how to being a structured asset reusable across hardware.
What the three cases share: problems at different layers (numerical semantics, concurrency behavior, kernel microarchitecture) were all decomposed into hypothesis chains that are observable, experimentable, and attributable. One line from the post closes the section well: the value of feedback lies in whether it helps the Agent answer the question at hand, and sheer quantity counts for little.
The Engineering Loop: Agents Propose Hypotheses, Engineers Hold the Boundary
The organizational form that makes this method run is a three-party loop. Engineers own three things: defining optimization goals and system constraints, building feedback environments the Agent can use directly, and reviewing every change that touches system architecture, async concurrency, or production risk. The Agent handles analysis, hypotheses, code changes, and experiments, then keeps, revises, or kills its own proposals based on the feedback it receives. The experimental environment supplies layered, timely, verifiable feedback. The post's own description lands well: this transformed "a diagnostic process previously connected by engineers' experience" into "an engineering workflow the agent could execute continuously."
Both roles are shifting. The model has moved from "helping write code" to "understanding why the system changed"; the engineer has moved from "solving each concrete problem" toward "designing feedback systems." And every optimization that passes verification flows back into the skeleton library, lowering the engineering cost of the next deployment, and the one after that. That is the compounding dividend of the loop in this article's title: the model optimizes the system, the system runs the model.
The boundary is drawn just as clearly: this has not yet reached recursive self-improvement; goal selection, boundary setting, and risk assessment remain human responsibilities. An early form of RSI has arrived, and its present shape is not a science-fiction narrative but a tightly disciplined engineering process.
The Business Flywheel: How 3× Efficiency Becomes 1/40 the Price
The 3× efficiency on the technical side transmitted quickly into pricing. GLM-5.3-Flash's API is priced at 1/10 of GLM-5.3's, 1/20 under a limited-time discount, and roughly 1/40 of Claude Opus 4.8's. The official tagline says it plainly; translated from the Chinese, it reads, "Same intelligence at 1/40 the price: for the first time, frontier intelligence you don't need to ration." On the Artificial Analysis intelligence index, maintained by an independent benchmarking outfit, it scores 57 at $0.045 per task (discount price), with the official annotation that this is "a level of intelligence previously only available at roughly 10× the cost." On coding and agent benchmarks it outperforms GLM-5.2 across the board (DeepSWE v1.1: 63.4 vs 46.2; AutomationBench: 48.8 vs 26.2), approaching Opus 4.8 overall (29.0 vs. 29.5 on Z.ai Code Bench at max effort).
The demand explosion that the price cut triggered has a clear timeline in the public record. After GLM-5 launched in February, call volume grew 10-fold and compute reserves were exhausted within the launch week; the Coding Plan subscription was briefly pulled from sale, and after reopening, sales grew more than 15-fold. On September 11 the company completed a fresh financing round of ~$5B (~$2B placement + ~$3B convertible bonds). On September 16 it raised its annual recurring revenue (ARR) guidance to $3B. On September 18, FlashX went live: speed up to 5× (peaking at 200 tokens/s), pricing up to 2.5×. From the September 11 financing to the September 18 price increase, the swing—cut prices to grab scale, raise prices to book profit—completed inside a single week.
The industry-level implication lands on the domestic-chip stretch: from "it runs" to "carrying all production traffic," and then to "per-token cost benchmarked against mainstream NVIDIA," the verification bar rose two notches in a row, and 62 trillion tokens is production-grade evidence. Of course, two caveats are worth flagging. First, the public wording on the "self-developed high-bandwidth interconnect network" remains vague, and the supporting details of the ecosystem are still a black box. Second, the KV cache remains slightly larger than Kimi-K3's and DeepSeek-V4-Flash's (per the team's own account; there is still room to optimize). For the full picture of inference economics, read this alongside our earlier The Token Factory Ledger: Inference Economics in SiliconFlow's Prospectus: one side is a model company building its own stack, the other is the cost structure of a third-party inference factory.
Summary and Judgment
Three judgments.
First, the unit of competition in inference infrastructure is shifting from "chip/model" to "engineering loop." The most reusable asset in this case is the combined method of dense feedback plus an engineering loop. It answers the most expensive question in infrastructure engineering (why did it get worse) and productizes the way answers to it get organized and reused. It depends on no specific chip: the three feedback traits and the skeleton library hold on any hardware, which means the method will diffuse faster than any single-point technique.
Second, the verification bar for domestic chips has been upgraded to "production traffic plus cost benchmarking." The step from "running one model" to "carrying full production traffic at per-token cost comparable to mainstream GPUs" has already been taken. The next gate sits in the ecosystem: the interconnect black box, the remaining room in KV optimization, and a second wave of validation across multiple models and vendors will decide whether the step holds.
Third, read the RSI narrative in a falsifiable way. The team itself drew the boundary: goals, limits, and risk remain with humans. The real indicator to watch is not the slogan "is AI rewriting itself," but whether the feedback environment keeps producing structured engineering data and whether the skeleton library stays reusable across generations. If the engineering cost of each deployment keeps falling, the minimal closed loop amplifies itself; if it stalls at isolated cases, it remains just a well-told engineering story.
What to watch next: first, disclosures on GLM-6.0's "fully self-trained" progress; second, whether the dense feedback apparatus gets released as a paper or a tool; third, real-world experience and pricing follow-through after FlashX; fourth, how quickly more vendors adopt the Infra Agent engineering loop (Agents taking on infrastructure optimization); fifth, the next batch of production validation on domestic-accelerator clusters, this time across multiple models.
Sources
- Zhipu GLM team: Toward Recursive Self-Improvement: How GLM Built Its Own Inference Infrastructure (z.ai blog, 2026-09-17, https://z.ai/blog/glm-built-its-inference-infrastructure ): less than two weeks, 100,000 accelerators, roughly 3×, 62 trillion tokens, the three traits of dense feedback, the three case studies, the engineering loop and its boundary statement
- Zhipu GLM team: GLM-5.3-Flash: Frontier Intelligence, Flash Cost (z.ai blog, 2026-08-26, https://z.ai/blog/glm-5.3-flash ): model architecture and benchmarks, the domestic-accelerator serving section, the 3× and cost-comparability statements
- Zhipu official announcement: 《GLM-5.3-Flash：前沿智能进入普惠时代》 (2026-08-26; cross-checked via a Zhitong Finance mirror): pricing structure (1/10, limited-time 1/20, 1/40 of Opus 4.8), Ox-Alpha, engineering-stack details
- Business-side public information: ~$5B fundraise (2026-09-11, financial-press reports); ARR guidance raised to $3B (2026-09-16, analyst-call coverage); GLM-5.3-FlashX launch (Sina Tech, 2026-09-18); GLM-6.0 "fully self-trained" blueprint disclosed (2026-09-15/16, public reporting)
- Earlier locsic pieces: A Generational Upgrade Without a New Engine: GLM-5.3 and the Second Half of Post-Training; The Token Factory Ledger: Inference Economics in SiliconFlow's Prospectus