Open-Weight Release and Agent Capability Evaluation for a 2.8T-Parameter MoE Model: Architecture, Deployment, and API Practices

1. Background and Industry Significance

Open-weight releases of large language models have consistently served as a catalyst for technology democratization and ecosystem growth. Recently, a leading AI lab followed through on its roadmap commitment by publishing the full weights of its flagship reasoning model. The release attracted significant attention not only because the model contains roughly 2.8 trillion parameters, but also because it achieved the top ranking among open-weight models on a widely referenced agent capability benchmark, while providing the developer community with a new reference for deploying and optimizing very large Mixture of Experts (MoE) models.

This release represents a meaningful evolution in how frontier models interact with the open-source community. Compared with closed API-only approaches, publishing full weights enables research institutions, enterprise engineering teams, and individual developers to conduct deeper audits, fine-tune the model for specific use cases, and deploy it locally. This has substantial implications for safety and transparency research, domain-specific adaptation, and privacy-sensitive applications where core data must remain within a controlled environment.

2. Model Architecture Deep Dive

2.1 Overall Parameter Count and Structure

The model uses a standard MoE architecture with approximately 2.8 trillion total parameters. However, not all parameters are activated during a given forward pass. Due to the sparse activation property of MoE, the model only activates about 104 billion parameters per token. This design philosophy greatly expands the model’s knowledge capacity and representational power while keeping per-token computational cost manageable, making deployment on existing hardware feasible.

2.2 Attention Mechanism Innovation: KDA Layers Combined with Gated DSA

According to the public model card, the model contains 93 Transformer layers. Of these, 69 layers use KDA (Key-Value Directed Attention), while the remaining 24 layers use Gated DSA (Gated DeepSeek Sparse Attention).

This hybrid layered design is a core architectural breakthrough for long-context modeling. KDA layers handle conventional global information interaction, while Gated DSA layers address the computational and memory challenges posed by very long sequences. By introducing sparse attention mechanisms combined with gating units, DSA dynamically determines which historical information needs to be revisited in detail and which can be sparsified or ignored. This preserves high-quality contextual understanding while substantially reducing computational complexity and KV cache memory usage during long-sequence inference. The combination of full attention and gated sparse attention is a key technical foundation for the model’s claimed support for context windows of up to one million tokens.

2.3 Expert Routing Mechanism

The MoE layers are configured with 896 expert modules. At each token, 16 experts are dynamically selected and activated. In addition, two shared experts are always active regardless of the token’s semantic characteristics, ensuring that common knowledge such as grammatical rules and basic logical reasoning remains available. This pattern of a large expert pool, a relatively high number of activated experts, and shared experts aims to balance expert specialization with computational efficiency. The large number of experts enables finer-grained knowledge partitioning, while activating 16 experts provides sufficient tolerance and combination space when the model draws on knowledge from different domains.

3. Quantization, Storage, and Deployment

3.1 MXFP4 Storage and MXFP8 Activation

Weight file size and memory consumption are the primary practical obstacles for deploying very large models. This model stores weights in MXFP4 (Microscaling Floating Point 4-bit) format, while activations during inference use MXFP8 (8-bit) precision. According to the official description, this is not a simple post-training quantization pipeline; it uses quantization-aware training.

This means the model was adapted to low-bit weight representations during pretraining, minimizing the impact of quantization error on model performance. Although weights are stored in 4-bit format, activations remain in 8-bit and use the MX format, a floating-point format with fine-grained scaling factors. As a result, the effective precision loss compared with traditional FP16 or BF16 inference is controlled within a narrow range. This approach significantly reduces memory bandwidth pressure, making it possible to fit the entire model, approximately 1.56 TB of repository files, on eight high-end accelerators with roughly 288 GB of memory each.

3.2 Compatibility with Mainstream Inference Frameworks

For production deployment, ecosystem readiness is critical. The three major inference engines, vLLM, SGLang, and TokenSpeed, already provide ready-made deployment recipes for this model architecture. Developers do not need to write custom C++ or CUDA kernels to support gated sparse attention from scratch. After downloading the weights, they can modify configuration files and specify the model path to start serving within their local inference framework. This out-of-the-box experience reflects close collaboration between the model team and the community before release.

3.3 Hardware Requirements and Cost Estimates

Although deployment recipes are mature, the physical hardware barrier remains high. Based on community estimates using default configurations, a minimal viable inference cluster requires eight flagship accelerators, such as B300-class products with approximately 2.3 TB of memory per card, with hardware procurement costs alone ranging from $550,000 to $650,000. This figure highlights the practical deployment challenges for small and mid-sized organizations and pushes many teams toward API access or managed inference services. It is worth noting that these are third-party estimates. The official release does not specify a mandatory hardware recommendation list, so users can adjust parallelism strategies and memory optimization based on their own throughput and latency requirements.

4. API Integration and Engineering Practices

For most application development teams, API access is the most cost-effective option. The model’s API service is compatible with both OpenAI and Anthropic interface protocols, which lowers migration costs. The API model identifier is kimi-k3.1-pro, with a high-speed variant kimi-k3.1-pro-highspeed that officially claims response speeds two to three times faster than the standard version, suitable for latency-sensitive scenarios.

For controlling inference behavior, the API exposes a reasoning_effort parameter with options low, high, and max, defaulting to max. Developers can dynamically adjust reasoning depth based on task complexity, balancing thinking time and answer quality.

Important: Multi-turn Tool Call Handling

When handling multi-turn tool calls, such as multi-step function calling in agent tasks, one implementation detail is critical: in subsequent requests, the reasoning_content returned by the model in the previous turn, along with the tool_calls, must be passed back to the server as part of the conversation history. If reasoning_content is not explicitly returned, the model loses its internal reasoning context, and subsequent tool selection may drift from the correct behavior. This requirement is essential for developers building complex agent applications on top of this API.

5. Agent Capability Evaluation: Methodology and Real-Session Analysis

5.1 Evaluation Data: Real Sessions, Not Static Benchmarks

The model’s leading position among open-weight models is primarily based on an evaluation leaderboard called Agent Arena. The key characteristic of this benchmark is that its data does not come from artificially constructed static test sets. Instead, it is derived from real user interactions with models in genuine agent scenarios. The evaluation pipeline extracts signals from more than 17,500 long-horizon sessions to assess model performance on complex tasks.

5.2 Core Metric: Net Lift

To objectively measure how much a model improves user experience, the evaluation framework defines a core metric called Net Lift. Rather than simply calculating task success rates, it combines four types of behavioral signals:

• Whether users explicitly confirm successful task completion during the conversation;
• Whether user responses contain positive or negative language about the model’s answers;
• Whether the model correctly understands and follows corrective feedback after a user provides it;
• Whether shell commands executed during agent tasks succeed and return expected results.

By weighting these signals, the system calculates the model’s net helpfulness relative to a baseline in real-world usage.

5.3 Benchmark Performance

In the latest evaluation round, the model was evaluated with max reasoning effort and achieved a Net Lift of +5.1%, a significant improvement over its predecessor’s +0.91%. This result places it first among open-weight models and 13th in the overall leaderboard including closed-source commercial models. The model showed broad improvements across several dimensions:

• Bash tool call reliability: Net Lift of +7.9%, ranking first among open models. Its predecessor scored -4.5% on this metric. This reversal strongly validates the benefits of the Gated DSA architecture in maintaining tool-calling stability during long-range reasoning.
• Code generation: Ranked first among open-weight models in the Code category, benefiting from extensive training on code corpora with the 2.8T parameter architecture.
• General chat: Also ranked best in the Chat category, reflecting solid base language capabilities.

These results reveal two key insights. First, model scale remains a fundamental enabler of agent capability. Second, architectural optimization for sparse attention has clear positive effects on handling long-window, multi-step tool-calling tasks.

6. Summary and Technical Outlook

This open-weight release of a 2.8T-parameter model sends several important signals to the industry. First, sparse and hybrid attention architectures for very large models are maturing and helping resolve the long-standing tension between capacity and cost. Second, quantization-aware training has moved from theory to large-scale practice, and MXFP4 may become a de facto industry standard for storing and transferring next-generation large models. Third, agent capability evaluation is shifting from static code repository test sets toward large-scale analysis of real conversations, with dynamic metrics such as Net Lift becoming increasingly important for measuring practical model value.

For teams making technology decisions, full open weights provide the missing piece for private deployment. Despite the still-high hardware costs, some organizations with strong data security or customization requirements will seriously evaluate the capital expenditure. For smaller teams that cannot afford infrastructure investment, adopting APIs compatible with OpenAI or Anthropic protocols remains the fastest way to build products. The localization and intelligent application of large models are accelerating across the digital landscape through this dual-track model of private deployment and managed API access.