Advancing Chinese Foundation Models: A Technical Analysis of Ultra-Large-Scale MoE Architectures and Agent Capabilities

Recent releases from Chinese foundation model vendors show a clear trend: parameter counts are climbing into the trillions, benchmark scores are approaching those of leading closed-source international models, and inference pricing remains significantly lower. This article breaks down these ultra-large-scale Mixture-of-Experts (MoE) models across four dimensions—architecture, capability evaluation, engineering usability, and cost structure—to help developers build a clearer framework for technical selection.

1. Parameter Accounting: 3 Trillion Total Parameters Does Not Equal 3 Trillion in Computation

Before discussing trillion-parameter models, it is essential to clarify what “parameter scale” actually means. Otherwise, cost expectations can be significantly misaligned with reality.

Current mainstream ultra-large-scale models commonly adopt the MoE (Mixture of Experts) architecture. The core idea is straightforward: the model consists of a large number of parallel expert sub-networks, plus a gating router network. During each forward pass, the gating network selects only a small number of experts for each token, while the remaining experts remain inactive. This yields two critical numbers:

• Total parameters: The sum of all expert parameters, representing the model’s capacity ceiling and knowledge storage scale.
• Activated parameters (per token): The parameter count actually involved in computation for a single token, directly determining compute cost and inference latency.

With typical industry configurations, it is common to see total parameters in the trillions while activated parameters per token are in the hundreds of billions. This “large capacity, small activation” structure has two direct consequences:

1. Inference cost is significantly lower than a dense model with the same total parameter count. A dense model routes every token through all parameters, whereas an MoE model processes only a subset. The FLOPs difference per token can reach an order of magnitude.
2. Memory usage remains a hard constraint. Although compute is lower, all expert weights must remain resident in memory or be efficiently swapped in. Memory planning cannot be estimated based on activated parameters alone.

Therefore, when evaluating such models, it is recommended to track three metrics simultaneously: total parameters (capacity ceiling), activated parameters (inference cost), and actual concurrent throughput (engineering usability). Looking only at total parameter count will both overestimate cost and misjudge capability.

# Conceptual illustration: MoE forward pass
input_token
  -> gating_network (routing score)
  -> top-k expert selection (select a small number of experts)
  -> activated expert forward computation (only k experts participate)
  -> weighted aggregation output
# Compute cost ~ activated parameters, memory cost ~ total parameters

2. Long Context and Multimodality: From “Reading” to “Acting”

The engineering value of a million-token context window is not that “the number is bigger.” It changes how tasks can be organized.

First, repository-level code understanding becomes a practical scenario. A mid-sized codebase—source code, configuration files, and test cases—often totals several hundred thousand tokens. A million-token window means the full context can be loaded in one pass, allowing the model to perform cross-file refactoring, dependency analysis, and bug localization with global visibility, rather than relying on chunked retrieval and stitching that tends to lose information.

Second, long context is particularly critical for agentic tasks. Agents generate a large amount of intermediate state during multi-step execution: tool call results, error logs, and historical decisions. A short window forces the system to compress or discard history frequently, leading to mid-task “amnesia.” Long windows, combined with sound context management strategies, can meaningfully improve completion rates for long-horizon tasks.

Third, native vision understanding expands input modalities. With image input support, models can directly process UI screenshots, architecture diagrams, charts, and scanned documents. This reduces the need for additional OCR and format-conversion steps in scenarios such as automated testing, UI reviews, and document structuring. Note that actual vision performance depends heavily on image-text alignment quality and resolution-handling strategy. Selection should be based on validation with your own business samples, not just general benchmark scores.

3. Capability Evaluation: Agentic Coding and Long-Horizon Tasks Are the Differentiator

General benchmark scores saturate quickly. What really distinguishes the engineering value of a model is its performance on agentic and long-cycle tasks. Three dimensions matter:

(1) Agentic coding capability in real terminal environments. These benchmarks require multi-step operations in real command-line environments: reading and writing files, running builds, parsing errors, and iterating on fixes. They test not single-shot code generation quality but the full loop of “perception—decision—execution—correction.” On these tasks, the latest MoE models have reached within one point of leading closed-source international models, while clearly outperforming some contemporaries. This means Chinese models are now a practical replacement candidate in scenarios like automated operations, CI repair, and script orchestration.

(2) Long-horizon software engineering tasks. These benchmarks simulate engineering workflows that span multiple interaction rounds and require continuous maintenance of task state. They place extreme demands on context retention and planning. Some models outperform competitors with higher aggregate scores, confirming that “high overall score” does not imply “strong long-horizon performance.” Evaluation must be broken down by task type.

(3) Comprehensive agent exam-style benchmarks. These cover tool use, multi-step reasoning, and environment interaction. Score gaps here are often more predictive of real deployment experience than general language benchmarks.

There are also measurable weaknesses. On scientific-computing terminal tasks and certain vertical knowledge domains, ultra-large-scale MoE models still trail top closed-source models. A practical approach is a “primary model + specialized toolchain” combination, rather than expecting one model to cover every scenario.

A practical evaluation workflow:

1. Extract 50–200 real tasks from your own business and build a private evaluation set
2. Stratify by task type: single-turn generation / multi-step agent / long-context understanding / multimodal
3. For each candidate model, record: task completion rate, average interaction rounds, cost per task
4. Attribute failures: capability gap / context loss / tool call error
5. Make the final selection using a combined "completion rate × cost" metric

4. A Shift in Release Paradigm: Anonymous Blind Testing Before Official Claims

A notable trend is that some Chinese models enter third-party arenas under anonymous identities for blind testing by developers before their official release. Only after collecting real adversarial data do vendors claim their identity. This reverses the traditional sequence of “technical report first, product later.”

The technical rationale is sound. Arena-style evaluation uses pairwise comparison with user votes or automated judgment, which reduces the score inflation caused by benchmark overfitting. Failure cases collected during the anonymous phase also allow vendors to patch issues before public release. For developers, this provides an additional signal from real usage distribution, beyond public leaderboard scores.

However, it is important to recognize that blind-test win rates reflect “relative preference,” not “absolute capability.” Arena sample distributions often differ significantly from your own business distribution. A rational approach is to treat blind-test results as a screening signal and make final decisions based on private evaluation sets.

5. Cost Structure: Low Prices Come from Architecture, Not Subsidies

The ability of ultra-large-scale MoE models to price significantly below leading closed-source international models stems from an architectural advantage in per-token compute cost, not simply from commercial subsidies. Understanding this is important for long-term cost planning:

• Low per-token cost is well-suited for high-concurrency, long-output, and batch-processing workloads.
• High memory requirements mean self-hosted deployment has significant hardware barriers. Expert parallelism and weight-swapping strategies require careful planning.
• Caching and batching further reduce costs. Repeated prefixes—long system prompts, fixed knowledge bases—benefit from cache hits.
• Layered routing is the better solution. Use lightweight models for high-frequency simple tasks and route complex agentic tasks to flagship models. This compresses overall spend while preserving quality.

For enterprise users, establish a closed loop of “task tiering—model routing—cost accounting.” Classify tasks by complexity, assign models and budget ceilings per tier, and optimize for cost per task rather than token price alone.

6. Summary of Selection Recommendations

Overall, the technical positioning of this generation of ultra-large-scale MoE models is now clear:

1. Capability: On engineering-oriented benchmarks such as agentic coding and long-horizon tasks, they approach leading closed-source international models. Gaps remain in general knowledge tasks.
2. Cost: The per-token compute advantage of MoE is structural, making these models suitable for cost-sensitive high-frequency scenarios.
3. Engineering: Million-token context and native multimodality reduce system-integration complexity but impose new requirements on memory and context management.
4. Evaluation: Prioritize private evaluation sets, combine blind-test signals, and use layered cost accounting for final decisions.

Model selection has never been about “who scores higher wins.” It is about matching capability boundaries, cost structure, and business distribution. Understanding the real meaning behind architectural parameter counts will deliver more long-term value than memorizing differences of a few percentage points.