Observing China’s LLM Evolution: From Trillion-Parameter MoE to Agent Capabilities

The domestic large model landscape recently saw a significant release: a vendor introduced its most capable flagship model to date, featuring roughly three trillion total parameters, a one-million-token context window, and a high-speed variant with two to three times faster output. What makes this release worth technical scrutiny is not the headline numbers per se, but what it reveals about the maturing approach to architecture selection, capability evaluation, and pricing strategy across China’s LLM ecosystem. This article breaks down the release from four angles—parameter interpretation, benchmark analysis, engineering capabilities, and selection guidance—to help developers and enterprise users build a clearer decision framework.

1. How to Read the “Three Trillion Parameters”: Total vs. Activated Parameters in MoE

A first reaction to “three trillion parameters” is often concern about inference costs. This requires clarifying what the parameter count actually means.

Virtually all frontier-scale models today use the Mixture of Experts (MoE) architecture. The core idea is to split the model into multiple expert sub-networks, with a gating mechanism that activates only a small subset during each forward pass. This creates two distinct parameter concepts:

• Total Parameters: The sum of all expert weights across the entire model, reflecting the model’s capacity ceiling and knowledge storage scale.
• Activated Parameters: The parameters actually engaged during a single inference pass, directly determining per-request compute cost.

In this release, total parameters are on the order of three trillion, while activated parameters per inference are around one hundred billion. In effect, although the model’s “knowledge base” is enormous, the per-inference compute cost approximates that of a hundred-billion-scale dense model. This is precisely why MoE can substantially increase model capacity while keeping inference costs manageable.

The gating logic can be illustrated with simplified pseudocode:

# Simplified MoE forward pass
def moe_forward(x, experts, gate):
    # gate outputs a weight distribution over experts
    scores = gate(x)                        # shape: [num_experts]
    topk_scores, topk_idx = top_k(scores, k=2)  # activate only top-k experts
    output = 0
    for score, idx in zip(topk_scores, topk_idx):
        output += score * experts[idx](x)
    return output

From an engineering standpoint, MoE introduces challenges around training stability, expert load balancing, and inference-time communication overhead. If routing becomes imbalanced—some experts overloaded while others sit idle—effective compute utilization degrades significantly. Mature MoE implementations typically incorporate auxiliary load-balancing losses, capacity factor constraints, and expert parallelism strategies. For enterprise users, understanding this matters: when evaluating inference services, don’t measure cost purely by total parameter count. Instead, look at activated parameters, batch efficiency, and memory footprint—metrics that actually appear on your bill.

A one-million-token context window is also a practically meaningful capability boundary. It means the model can hold, in a single request, the core file set of a medium-sized code repository or several hundred pages of technical documentation—enabling cross-file code understanding, long-document summarization, and complex multi-turn reasoning. Native vision understanding further extends applicability to mixed text-and-image inputs, such as UI screenshot analysis, chart interpretation, and structured document extraction.

One notable industry trend: some vendors release new models on third-party evaluation platforms under anonymous codenames for developer blind testing, then publicly claim the model only after sufficient data accumulates. This “fight first, release later” workflow complements the traditional “publish a tech report, then ship a product” path. Blind-test results are arguably more informative, since the environment more closely mirrors unbiased real-world comparison.

2. Benchmark Breakdown: Agent Capability as the New Dividing Line

Parameter scale is only the foundation; what truly determines usability is performance on concrete tasks. The published evaluation results cover terminal coding agents, long-horizon software engineering, cross-domain agent tasks, and 3D reconstruction—revealing several notable trends.

First, coding-agent capability has entered the top tier. On a benchmark examining coding agents in realistic terminal environments, the model scored 65.7%, beating one closed-source flagship by nearly 7.5 percentage points and trailing another coding-specialized closed-source model by only 0.7 points. Terminal-based coding agent tasks require the model to autonomously handle file reads/writes, dependency installation, error diagnosis, and iterative fixes in a command-line environment—demanding accurate tool invocation, multi-step planning, and robust context management. This result indicates that domestic models are moving beyond “being able to write code” toward “being able to independently complete engineering tasks.”

Second, long-horizon advantages are even more pronounced. On the long-cycle software engineering benchmark, the model scored 51.7%, surpassing both comparison closed-source flagships. Long-horizon tasks involve many steps, complex state, and continuously maintained intermediate results—stress-testing the model’s context retention and drift resistance. This strength aligns logically with the million-token context design: longer context means the model is less likely to “forget” early constraints during extended tasks.

Third, capability distribution is uneven; choose by scenario. On the cross-domain agent task benchmark, the model scored 43.2, higher than one comparison’s 32.8 and marginally above another’s 42.6. But on 3D reconstruction benchmarks, its 92.7% trailed the comparisons’ 95.9% and 96.2%. This underscores that no single leaderboard should be the sole basis for model selection. Enterprises should build evaluation sets tailored to their own business scenarios rather than chasing comprehensive rankings.

For reference, the published results can be organized as follows:

Benchmark Dimension	Released Model	Comparison A	Comparison B
Terminal Coding Agent	65.7%	58.2%	66.4%
Long-horizon Software Engineering	51.7%	42.5%	46.3%
Cross-domain Agent Tasks	43.2	32.8	42.6
3D Reconstruction Benchmarks	92.7%	95.9%	96.2%

The picture is clear: in agent and software engineering directions, domestic models now compete head-to-head with international closed-source flagships; in some vertical perception tasks, there is still ground to close. This pattern—“locally ahead, overall approaching”—is a realistic snapshot of the current competitive landscape.

3. The Engineering Logic Behind Pricing: Why Costs Can Be Driven Down

Equally noteworthy as capability is pricing strategy. According to public information, this model’s API price is roughly one-fifth that of a major international closed-source flagship. This is not mere subsidy; it is backed by concrete engineering.

First, the MoE architecture’s activated-parameter control keeps per-inference compute costs far below what a dense model of equivalent total size would require. Second, while a million-token context increases per-request information capacity, optimizations such as paged attention and sparse attention effectively amortize the additional overhead of long contexts. Third, the high-speed variant is essentially a product of inference-side system optimizations—operator fusion, improved batch scheduling, speculative decoding, and similar techniques—raising throughput without proportionally increasing compute costs, thereby satisfying latency-sensitive scenarios.

For enterprise users, here is a practical cost evaluation method: don’t look only at the per-million-token sticker price. Instead, estimate actual per-request cost by factoring in your input/output ratio, average context length, and concurrency profile. For example, long-document summarization workloads have very high input-token proportions, so the context-window capability and input pricing weight more heavily than output speed. Code-generation workloads, by contrast, are more sensitive to output speed and time-to-first-token.

# Simplified per-request cost estimation
def cost_per_request(input_tokens, output_tokens,
                     price_in_per_m, price_out_per_m):
    return (input_tokens / 1_000_000) * price_in_per_m + \
           (output_tokens / 1_000_000) * price_out_per_m
# Example: long-document summarization, input >> output
print(cost_per_request(200_000, 2_000, p_in, p_out))
# Example: code generation, higher output share and latency-sensitive
print(cost_per_request(4_000, 8_000, p_in, p_out))

4. Practical Selection and Implementation Advice for Developers

Synthesizing the above, several actionable recommendations emerge.

Map your task type to model capability. If your workload is dominated by multi-step, long-cycle software engineering, prioritize models with strong long-horizon task performance and tool-calling reliability. If your workload is dominated by vertical perception tasks, construct a scenario-specific evaluation set to validate effectiveness rather than relying on general-purpose leaderboards.

Focus on context engineering, not blindly maximizing length. A million-token context is a ceiling, not a mandate to fill every request. In practice, use retrieval augmentation, segment summarization, and structured prompting to place genuinely relevant information in context—this both reduces cost and minimizes information interference in long contexts.

Use the high-speed variant for interaction-dense scenarios. For code completion, real-time Q&A, and other scenarios sensitive to time-to-first-token and output speed, the high-speed variant is the better fit. For offline batch processing and deep analysis tasks, the standard variant offers better cost efficiency.

Build your own regression evaluation pipeline. Model iteration is rapid. Maintain a private evaluation set covering your core business scenarios, and automatically run regression tests on each new model version. Let data drive upgrade decisions rather than passively following release cycles.

Overall, this release reflects the stage-level progress of domestic large models along three parallel tracks: architectural efficiency, agent capability, and cost control. Three trillion parameters and a million-token context form the capability foundation; agent benchmark results validate progress in task execution; and pricing makes that capability ready for scaled deployment. For developers, the real takeaway is not to chase any single parameter number, but to understand the engineering trade-offs behind these technological choices—and translate them into sound technical decisions for your own business.