1. Background: Trillion-Parameter Models Go Open-Weight

For the past two years, large models that crossed the trillion-parameter threshold were almost exclusively available through closed-source APIs. Enterprises could call the models via endpoints but never touched the weights directly. That pattern has recently shifted: a leading team released a new flagship model in late October with a public commitment to open the weights by November 4 — and delivered on schedule. The full weights are now downloadable from open-weight hosting platforms. A companion evaluation dataset was also published: on the day of release, a third-party agent evaluation platform ranked the model #1 among open-weight models and #13 overall.

Core specifications:

• Approximately 2.8 trillion total parameters in a Mixture-of-Experts (MoE) architecture, with roughly 104B parameters activated per token.
• 1-million-token context window with mixed text-and-image input support.
• Weights stored in 4-bit microscaling floating-point (MXFP4) format; activations computed in 8-bit precision.
• The training pipeline used quantization-aware training (QAT), per official documentation.

For enterprises and technical teams, “open weight” means three things: on-premise deployment with data staying within organizational boundaries, incremental fine-tuning for domain-specific needs, and the ability to audit model behavior for compliance and safety. That is why the community pays close attention to such releases despite the formidable hardware requirements — which we will quantify later.

2. Architecture Breakdown: MoE Sparse Activation + Hybrid Attention

2.1 MoE: Decoupling Capacity from Compute

With 2.8 trillion total parameters but only ~104B activated per token, the activation rate is roughly 3.7%. That is the core benefit of MoE: the model’s knowledge capacity is determined by all experts collectively, while inference cost is tied only to the small subset of experts routed per token.

Specific expert configuration:

• 93 total layers; expert layers contain 896 experts.
• A router selects 16 experts out of 896 for each token.
• 2 additional shared experts are always activated for every token.

Shared experts consolidate high-frequency, cross-scenario general computation into a permanently active path, freeing routed experts to specialize in differentiated, niche patterns. This avoids redundancy where multiple experts would otherwise learn the same general capabilities. For teams planning fine-tuning, understanding this structure matters because expert routing behavior directly influences fine-tuning strategy choices.

2.2 Hybrid Attention: 69 Layers of Linear Attention + 24 Layers of Gated Sparse Attention

Of the 93 layers, only 24 retain gated sparse attention; the remaining 69 use linear attention with incremental state updates. According to the official documentation, this generation replaces most global-attention layers from the predecessor with gated sparse attention to achieve more efficient long-context modeling.

Why this design? Two cost dimensions explain it:

• Compute: Standard global attention scales quadratically with sequence length. At a 1-million-token context, even a single attention layer becomes extremely expensive.
• Memory: KV cache grows linearly with sequence length and in long-context scenarios often consumes more memory than the weights themselves.

Linear attention replaces explicit full-history Key/Value caching with a fixed-size recurrent state, making both costs approximately independent of sequence length. Gated sparse attention, kept in a minority of layers, preserves on-demand precise global retrieval, with a gating mechanism controlling information flow. The hybrid design is grounded in a repeatedly validated empirical observation: not every layer needs full global attention — sparse most layers with negligible quality loss, and keep precise retrieval in a few critical layers to maintain long-range dependency capability.

2.3 Lightweight Vision Encoder

The multimodal component is handled by a lightweight vision encoder of roughly 400 million parameters, which converts images into token sequences for unified processing with text. Because the vision module is a tiny fraction of total parameters, the design philosophy is clearly “text-backbone-first, vision as a lightweight add-on” — a common approach in current vision-language models.

3. Quantization and Storage: MXFP4/MXFP8 and Quantization-Aware Training

3.1 What Is Microscaling Floating-Point?

Weights are stored in MXFP4 and activations are computed in MXFP8. MXFP4/MXFP8 are microscaling floating-point formats: a small group of values shares a single scale factor, while each element records only a very low bit-width mantissa. Compared to traditional per-tensor scaling, block-level shared scale factors preserve usable dynamic range even at 4-bit precision.

On the inference side, the common pattern is “8-bit weights + 8-bit activations.” Pushing weights to 4 bits halves storage and memory footprint — which is what makes hosting a 2.8-trillion-parameter model on a single server feasible in principle.

3.2 Quantization-Aware Training: Low Precision by Design, Not by Afterthought

The official documentation confirms quantization-aware training (QAT), which is fundamentally different from post-training quantization (PTQ):

• PTQ compresses high-precision weights to low precision after training is complete. At 4-bit levels this typically introduces noticeable quality degradation and requires complex calibration and compensation.
• QAT simulates low-precision numerical behavior during training, letting the model adapt to quantization noise from the start. The resulting weight distribution is natively suited to low-precision representation.

For users, this means 4-bit storage does not imply a “crippled compressed version.” The model was designed natively for low-precision inference, and the quality gap versus a high-precision counterpart is expected to be manageable.

3.3 Verifying Parameter Count from Repository Size

The open-weight repository occupies roughly 1.56 TB. Based on standard weight storage formats, the counted parameter total is approximately 2.78 trillion. The two figures cross-validate each other:

Weight bytes ≈ parameter count × bytes per parameter
2.78T × 0.5 B (4 bit) ≈ 1.39 TB

Adding embedding layers, output heads (typically saved at higher precision), vision encoder weights, group scale factors, and metadata indices brings the total to the observed 1.56 TB range. The difference between the nominal “2.8 trillion” and the counted “2.78 trillion” stems from differing counting conventions.

4. On-Premise Deployment: How High Is the Bar, and What Are the Options?

4.1 Memory Estimation

Beyond the weights themselves, deployment memory must account for activations, KV cache, and framework runtime overhead:

Total GPU memory ≈ weight memory + activation memory + KV cache + framework/communication overhead

Weights alone start at roughly 1.4 TB. Although sparse attention significantly compresses KV cache, in long-context scenarios the cache still grows with concurrency. Third-party developers have estimated a viable configuration at 8 flagship data-center GPUs totaling approximately 2.3 TB of memory on a single server, with hardware costs in the range of $550K–$650K. This is a community estimate; the official team has not published hardware recommendations, and actual configuration depends on target concurrency, context length, and latency requirements.

4.2 Inference Engine Support and Hidden Costs

Multiple mainstream open-source inference engines released deployment guides concurrent with the weight release, covering tensor parallelism, expert parallelism, and other distributed strategies. However, there is a wide gap between “it runs” and “it runs economically.” High-speed interconnect networking, fault-tolerant scheduling, and elastic scaling are the bulk of the hidden engineering cost for self-hosting.

4.3 Alternative Paths

For most teams, three more practical options exist:

• API calls: Zero operations overhead, pay-per-use, suitable for the majority of business scenarios.
• Cloud-hosted inference: Leverage elastic GPU compute, model hosting, and monitoring services from cloud providers (such as Baidu AI Cloud) to offload cluster operations to the platform side while the team focuses on business integration and tuning.
• Distillation or pruning to smaller models: Use the large model as a teacher to distill a business model several orders of magnitude smaller, balancing cost and effectiveness.

5. API In Practice: Inference Intensity and Tool-Calling Engineering Details

5.1 Interface Shape and Version Selection

The model’s API is compatible with widely adopted chat-completion protocol conventions, so migration from other mainstream models requires minimal code changes. Two tiers are offered — standard and high-speed — with the high-speed variant delivering 2–3× the throughput. Latency-sensitive online workloads such as customer-service bots and interactive assistants should evaluate the high-speed tier first.

5.2 Inference Intensity: Tuning Between Quality and Cost

The inference intensity parameter supports three levels — low, high, and max — with max as the default. Tuning it controls the token budget the model spends on “internal reasoning”:

• max: Complex agent tasks, multi-step reasoning, high-difficulty code.
• high: A balanced choice for most production scenarios.
• low: Simple classification, format conversion, short Q&A — significantly reduces latency and cost.

Defaulting to max rather than low signals a quality-first positioning, but it also means out-of-the-box integration costs may exceed expectations. Teams should explicitly evaluate and set this parameter during onboarding.

5.3 Multi-Turn Tool Calling: Why You Must Echo Back Reasoning Content

An easily overlooked engineering detail: in multi-turn tool-calling scenarios, the reasoning content from the previous turn must be sent back along with the tool-call request. The structure looks like this (field names follow the actual API documentation):

{
  "messages": [
    { "role": "user", "content": "Troubleshoot the online API timeout issue" },
    {
      "role": "assistant",
      "content": null,
      "reasoning_content": "First check recent deployment records, then review monitoring metrics…",
      "tool_calls": [{ "name": "query_logs", "arguments": "{...}" }]
    },
    { "role": "tool", "content": "Log query results…" }
  ]
}

The reason: the reasoning chain is part of the model’s working memory. Dropping prior reasoning content in the next turn forces the model to re-infer its own earlier thought process from conclusion-only text, which can cause contradictions, repeated reasoning, or even reversal of completed steps in long-chain tasks. Full echo-back preserves cross-turn consistency — a key integration detail that distinguishes reasoning models from ordinary chat models.

6. Agent Evaluation: Real Conversations Over Benchmark Gaming

6.1 The Evaluation Methodology Itself

Another noteworthy aspect of this release is the evaluation method. The third-party agent evaluation platform does not rely on hand-crafted static test sets. Instead, it draws from real user agent sessions — over 17,500 long-horizon conversations — and extracts several signals:

• Whether the user explicitly confirmed task success.
• Praise and complaints directed at the model.
• Response quality after user corrections.
• Whether command-line commands executed successfully.

A “net lift” metric is computed by combining positive and negative signals. Compared to static benchmarks, this approach is harder to game and more closely aligned with the real-world production question: “Did the task actually get done?”

6.2 Reading the Numbers

At the max inference intensity setting, the model achieved a net lift of +5.1%, ranking #1 among open-weight models and #13 overall. It also ranked #1 among open models in the office, code, and conversation sub-categories. The previous-generation model scored +0.91% net lift (#6 among open models). The most telling sub-metric is command-line execution reliability: it jumped from −4.5% (open-model #13) in the prior generation to +7.9% (open-model #1).

Three takeaways:

• Tool execution reliability is the foundation of agent capability. The prior generation’s negative score meant “executing commands made things worse more often than it helped.” The reversal indicates a substantive improvement in the “think-before-acting, verify-after-executing” behavior pattern.
• #1 among open models but #13 overall shows that while the open-weight cohort is still behind top closed-source flagships in aggregate, the gap is narrowing rapidly.
• Single-score rankings offer limited insight; multi-dimensional metrics like net lift and per-category reliability carry more engineering value.

7. Actionable Recommendations for Technical Teams

Based on the analysis above, here is a decision checklist:

1. Define requirements before choosing a path. If data must stay on-premise, deep fine-tuning is needed, or model-behavior auditing is required, open weights offer irreplaceable value. Otherwise, API calls and cloud-hosted inference (via platforms such as Baidu AI Cloud) win on cost and agility.
2. Run three cost calculations before self-hosting: hardware procurement, cluster operations headcount, and inference optimization investment — downloading the weights is only step one.
3. When integrating a reasoning model, explicitly set the inference intensity level and implement full reasoning-content echo-back for multi-turn tool calls to avoid consistency issues in long-chain tasks.
4. Don’t rely solely on leaderboard rankings. Adopt the “real sessions + net lift” mindset: build a small-scale evaluation on your own business workload before deciding to switch models.
5. Watch the architectural trends. MoE sparse activation, hybrid sparse attention, and native low-precision quantization have become the “three-piece toolkit” for making ultra-large models more cost-effective. The open ecosystem is likely to evolve along this trajectory — worth tracking closely.

In sum, this weight release is more than “another large model you can download.” It showcases the current engineering state of the art across architecture, quantization, deployment, and evaluation for trillion-scale models, and provides a rare reference sample for teams preparing to adopt large-model capabilities.