China’s Ultra-Large-Scale MoE Model Tested: Closing in on Closed-Source Flagships

Competition among large language models in China is moving away from a simple race over parameter count toward a broader contest over effective intelligence, long-context handling, agent-task capability, and cost per unit of inference. A newly tested Chinese ultra-large-scale MoE model has drawn attention not only because of its 3-trillion-level total parameter count, but because it attempts to answer three questions at once: first, can it genuinely approach the intelligence level of closed-source flagship models; second, can it handle very long context and multimodal input; third, can architectural and engineering optimizations reduce inference costs to a lower range.

According to public information, the model has 3-trillion-level total parameters, a context window expanded to 1 million tokens, and native support for visual understanding. A high-speed inference version was also introduced, maintaining overall intelligence while providing higher output throughput. For developers, these changes mean that large-model applications are no longer limited to simple question-and-answer interactions. They can now support heavier tasks such as long-document analysis, code repository understanding, agent automation, complex report generation, and multimodal content review.

1. Understanding 3 Trillion Parameters: MoE Capacity and Sparse Activation

When discussing ultra-large-scale models, the first distinction is between total parameters and activated parameters.

In a traditional dense model, every inference pass involves all parameters in the computation. As the parameter scale grows, the compute pressure of each inference becomes more pronounced. Mixture-of-Experts, or MoE, addresses this by expanding model capacity through multiple expert networks that run in parallel, while a gating mechanism decides which experts are activated for each token. In other words, the model’s total parameter count can be very large, but only a subset of those parameters participates in computation during each inference.

This design has three direct effects:

1. Greater knowledge capacity: More expert parameters can carry a broader distribution of knowledge.
2. Controllable single-inference cost: Although the total parameter count is high, the number of parameters activated per inference is much lower than the total.
3. Higher engineering complexity: Expert routing, load balancing, memory footprint, and distributed communication become new optimization priorities.

According to public technical descriptions, the model has 3-trillion-level total parameters. Some reports also cite approximately 2.8 trillion total parameters and about 104 billion activated parameters per inference. The key point is that 3 trillion represents the model’s upper bound for capability and knowledge capacity, while 104 billion is closer to the actual compute burden during a single inference. This is also why MoE models can pursue lower pricing while retaining large capacity.

A generic pseudocode example helps illustrate the routing idea of MoE:

# Generic MoE routing illustration
def moe_forward(x, experts, gate, top_k=2):
    scores = gate(x)
    selected = top_k_indices(scores, top_k)
    return sum(scores[i] * experts[i](x) for i in selected)

This code does not correspond to a specific product interface. It only illustrates the core MoE mechanism: the input first passes through a gating network to calculate expert scores, and then the highest-scoring experts participate in computation. For engineering teams, the important question is not merely how many experts exist, but whether routing is stable, whether expert load is balanced, whether inference throughput is acceptable, and whether memory usage remains controllable under long context.

2. 1 Million Token Context: A Key Threshold for Long-Horizon Tasks

The 1-million-token context window is another important observation from this test.

For ordinary chat applications, tens of thousands of tokens may already be sufficient. But for code repositories, legal contracts, technical documents, log analysis, and multi-turn agent tasks, context length directly determines whether the model can “see the whole picture at once.” For example:

• A medium-sized code repository may contain dozens of source files, configuration files, and test scripts.
• A complete financial report may contain tables, footnotes, management discussion, and risk disclosures.
• A complex automation task may include historical instructions, tool return values, intermediate states, and records of failed retries.

If the context is insufficient, the system has to rely on chunking, summarization, or retrieval stitching, which can cause information loss or broken logic. The value of a 1-million-token context is not simply that it can hold more text. It is that it provides a more complete input foundation for long-horizon tasks.

However, long context also introduces new engineering challenges:

1. Higher attention and cache costs: Longer sequences significantly increase KV cache and memory pressure.
2. More information noise: The longer the context, the more important structured organization and retrieval ranking become.
3. A tradeoff between latency and throughput: Very long inputs can affect time-to-first-token and overall throughput.
4. Summarization and retrieval become more important: Not all content is suitable for full injection into the context.

For enterprise deployment, a layered context strategy is generally more suitable than stuffing all materials into the model at once.

# Pseudocode: layered organization for long context
context = (
    system_instruction
    + summarize(long_history)
    + retrieve_relevant_docs(query, knowledge_base)
    + current_task_state
)
response = model_client.chat(
    messages=[{"role": "user", "content": context}],
    max_output_tokens=4096
)

The advantage of this approach is that it uses long-context capability while controlling noise and cost.

3. Native Visual Understanding: Practical Boundaries of Multimodal Capability

In addition to text capability, the model emphasizes native visual understanding. For enterprise applications, this means the model can directly process images, screenshots, charts, scanned documents, and UI design drafts without relying entirely on external OCR or a separate image model.

Common use cases include:

• Reading charts and generating business interpretations.
• Analyzing UI screenshots to assist frontend restoration or testing.
• Recognizing document layouts and extracting structured information.
• Assisting with understanding tasks related to 3D reconstruction or spatial layout.
• Processing intermediate results with visual input in agent tasks.

In public testing, this type of model performed close to closed-source flagship models on 3D-reconstruction-style visual tasks, but still showed a small gap. This suggests that multimodal capability already has practical value, but in high-precision spatial understanding and complex image reasoning, further validation against business-specific evaluation sets is still necessary.

4. Benchmark Interpretation: Terminal Coding, Long-Horizon Tasks, and Agent Capability

From public benchmark results, the strengths of this Chinese MoE model are concentrated in three areas: terminal coding, long-cycle software engineering, and comprehensive agent tasks.

4.1 Terminal Coding Approaches the First Tier of Closed-Source Models

In a real terminal-environment coding benchmark, the model scored about 65.7%, approximately 7.5 points higher than some closed-source flagship models and only about 0.7 points behind the strongest closed-source flagship model.

These tasks are not simply about writing code. They require the model to understand commands, execute steps, observe return values, modify files, run tests, and fix errors. This is closer to agent workflows in real development scenarios. For developers, improvements in this area mean the model can participate in:

• Code repository maintenance.
• Automated script generation.
• Log investigation.
• Test failure diagnosis.
• Build process repair.
• Command-line task orchestration.

4.2 Clear Advantage in Long-Horizon Software Engineering Tasks

In a long-cycle software engineering benchmark, the model scored about 51.7%, exceeding some closed-source flagship models. Long-horizon tasks usually require the model to maintain goal consistency across multiple steps, handle dependencies, and continue correcting itself after mid-course errors.

This is different from ordinary question answering. Ordinary question answering focuses more on single-turn correctness, while long-horizon tasks focus on whether the model can continuously complete a goal. They test:

• Task decomposition ability.
• Context memory.
• Tool-call planning.
• Error recovery.
• State management.
• Final delivery consistency.

For enterprises, this type of capability is better suited to scenarios such as developer assistants, operations assistants, and automation process agents.

4.3 Leading Performance in Comprehensive Agent Tasks

In a comprehensive agent-capability test, the model scored about 43.2, ahead of some closed-source flagship models. Agent tasks usually include tool calling, environment interaction, multi-turn decision-making, and completion of complex goals. They are an important dimension for evaluating whether a model can actually perform work.

From an engineering perspective, agent capability is more complex than simple text generation. It requires the model not only to answer questions, but also to plan, call tools, read results, and adjust its path. If enterprises build agent systems, they should also pay attention to permission control, tool execution isolation, result validation, and rollback mechanisms.

5. Third-Party Intelligence Index: Open Weights May Narrow the Gap with Closed Source

An independent evaluation organization reported an intelligence index score of about 55 for the model, ranking fourth globally and improving by 11 points compared with the previous generation. More importantly, the evaluator judged that if the weights are opened, the model could become one of the highest-scoring models in the open-weight camp, and the intelligence gap between open-weight and closed-source models could shrink from around 12 points to around 3 points.

This reflects an important trend: open-weight models are moving from “usable” to “highly usable.” For enterprises, the value of open weights is not only cost. It also includes:

1. Private deployment possibilities: Suitable for scenarios sensitive to data boundaries.
2. Stronger controllability: Easier to support fine-tuning, distillation, quantization, and inference optimization.
3. Reduced single-vendor lock-in: Enables multi-model routing and failover.
4. More flexible ecosystem integration: Can be embedded into internal platforms, toolchains, and business workflows.

However, open weights also mean enterprises must take on more security responsibilities, including compliance in model usage, output risk control, inference service operations, version upgrade management, and abuse prevention.

6. Pricing at About One-Fifth: Where Does Low Cost Come From?

Another widely discussed point is that the model’s invocation price is about one-fifth that of some closed-source flagship models. This low price is not simply a market subsidy. It is more likely the result of several factors working together.

6.1 MoE Architecture Reduces Compute per Activation

As noted earlier, MoE activates only part of the parameters for each inference. Even if the total parameter count is very large, the actual compute for a single inference can be kept at a relatively low level. This provides an architectural foundation for lower pricing.

6.2 Inference Engineering Optimizations Improve Throughput

The cost of large-model inference depends not only on model size, but also on scheduling efficiency. Common optimizations include:

• Continuous batching.
• Dynamic batching.
• KV cache reuse.
• Quantized inference.
• Expert parallel scheduling.
• Request priority queues.
• Separation of long and short requests.

These optimizations can significantly improve GPU utilization and reduce cost per token.

6.3 Long Context and High-Speed Versions Create Portfolio Choices

For latency-sensitive scenarios, teams can choose the high-speed version. For offline batch processing, the standard version may be more suitable. For very long documents, the long-context capability can reduce the number of chunking operations. Different business needs can be optimized by balancing cost, latency, and quality.

6.4 Real Enterprise Cost Is Not Just Unit Price

When evaluating cost, developers should not look only at price per thousand tokens. They should also consider total cost:

# Pseudocode: estimating total invocation cost
total_cost = (
    input_tokens * input_price
    + output_tokens * output_price
    + retry_tokens * retry_factor
    + tool_call_cost
    + storage_cost
    + observability_cost
)

If a model can complete tasks in fewer rounds, total cost may be lower even if the unit price is slightly higher. Conversely, if a model requires repeated retries, manual fallback, or heavy retrieval stitching, the low-price advantage may be offset.

7. Enterprise Adoption: From “Usable” to “Stable in Production”

For enterprise developers, the real value of this type of model is not benchmark scores, but whether it can be reliably integrated into existing business systems. Several engineering recommendations are important.

7.1 Start with Small-Scale Scenario Validation

It is not advisable to replace everything at once. A more reasonable approach is to pilot in low-risk, measurable, and reversible scenarios, such as:

• Internal document question answering.
• Code comment generation.
• Ticket classification.
• Log summarization.
• First-draft report generation.
• Customer-service knowledge retrieval augmentation.

Baseline metrics should be established during the pilot before deciding whether to expand.

7.2 Build a Unified Model Gateway

Enterprises should avoid hard-coding model calls directly into business code. A unified model gateway can provide:

• Authentication and quota management.
• Multi-model routing.
• Canary releases.
• Rate limiting and circuit breaking.
• Call logging.
• Cost and token statistics.
• Failure fallback strategies.

# Pseudocode: unified model gateway
def generate(prompt, scene="general"):
    if scene == "code":
        model = route_to_code_model(prompt)
    elif scene == "long_doc":
        model = route_to_long_context_model(prompt)
    else:
        model = route_to_general_model(prompt)
    return model.chat(prompt)

7.3 Long Context Requires Input Governance

Enterprises should not indiscriminately put all content into the context. Safer practices include:

• Retrieve first, then inject.
• Use rolling summaries for historical conversations.
• Record key states in a structured format.
• Chunk long documents and retain indexes.
• Compress and rank tool return values.

This reduces noise and improves answer stability.

7.4 Agent Tasks Must Have Safety Boundaries

If a model needs to execute commands, call interfaces, or modify files, safety boundaries must be established:

• Least-privilege principle.
• Command allowlists.
• Sandboxed execution environments.
• Human approval for critical operations.
• End-to-end log tracing.
• Operation rollback mechanisms.
• Masking of sensitive data.

Otherwise, the stronger the agent capability, the higher the risk of erroneous operations.

7.5 Observability Should Be Designed Up Front

After large-model applications go live, a common problem is not that they cannot answer, but that answers become unstable. Monitoring systems should therefore be designed before launch, including:

• Request latency.
• Token consumption.
• Error rate.
• Retry rate.
• Context length distribution.
• Tool-call failure rate.
• User feedback.
• Human fallback rate.

For cloud-based implementations, teams can use general cloud capabilities to operationalize the system: object storage can hold documents and model input materials; container platforms can host applications and inference services; message queues can decouple offline batch jobs; logging services can record call chains; and monitoring and alerting systems can track latency, error rates, and resource utilization. Where relevant, these capabilities can be provided by cloud platforms such as Baidu AI Cloud. This helps embed model capabilities into a broader application architecture rather than treating the model as an isolated API call.

8. Limitations and Risks: Be Cautious Beyond the Leaderboard

Although the benchmark results are impressive, enterprises should remain rational when selecting models.

8.1 Leaderboard Scores Are Not Business Results

Benchmarks usually have fixed distributions and scoring standards, while real business scenarios are often more complex. Customer service may involve multi-turn interruptions. Coding scenarios may involve private dependencies. Financial document scenarios may involve strict formatting and compliance requirements. Enterprises must therefore run secondary evaluations with their own data.

8.2 Ultra-Large Models Still Have Deployment Barriers

Even if MoE reduces the cost of each activation, 3-trillion-level total parameters still bring substantial memory, storage, and deployment complexity. For small and medium-sized enterprises, direct private deployment may not be cost-effective. Cloud services or managed access may be more suitable.

8.3 Long Context Does Not Automatically Mean High Quality

The longer the context, the more the model needs good retrieval, ranking, and summarization. If there is too much input noise, long context may actually reduce stability.

8.4 Multimodal Capability Still Needs Segment-Specific Evaluation

Image understanding may seem general, but actual performance is heavily affected by image quality, layout complexity, text density, and chart type. Enterprises should build evaluation sets tailored to their own material types.

8.5 Open Weights Bring Higher Operational Responsibility

Open-weight models are customizable, but enterprises must handle safety filtering, version upgrades, inference optimization, and compliance management themselves. Teams without mature capabilities should choose carefully.

9. Conclusion: Chinese Large Models Enter a Competition of Capability and Cost

The trend reflected by this test is not simply the score of a single model, but a change in the logic of competition among Chinese large models: from “larger parameters” to “more complete capability,” from “higher leaderboard scores” to “lower cost per unit,” and from “single-turn question answering” to “long context and agent tasks.”

A 3-trillion-level total parameter count, a 1-million-token context, native visual understanding, an intelligence index approaching closed-source flagships, and significantly lower invocation cost together form the core appeal of this type of model. For developers, the real opportunity lies in turning these capabilities into stable, controllable, and measurable business value.

When selecting models, enterprises should focus on four things:

1. Whether the model can complete their real tasks, not just general leaderboard tasks.
2. Whether it can handle long context within acceptable latency.
3. Whether it offers sufficiently low unit cost.
4. Whether it can integrate with existing security, monitoring, operations, and compliance systems.

Overall, Chinese ultra-large-scale MoE models are pushing large-model applications toward a stage of higher density, lower cost, and longer task chains. For teams that need long-document processing, code intelligence, or complex agent automation, this type of model deserves serious evaluation. However, before deployment, scenario-specific validation and engineering design are still required.