Ultra-Scale MoE Architecture and Long-Horizon Agents: Technical Evolution and Engineering Practices

    This article breaks down a recently open-sourced mixture-of-experts (MoE) model with 2.8T total parameters and 104B activated parameters, which natively supports 1M-token contexts and multimodal image-text understanding. It covers the architectural innovations behind the model—including Gated Dynamic Sparse Attention (DSA), the Kimi Delta Attention hybrid stack, and multi-domain joint reinforcement learning post-training—along with its long-horizon agent capabilities in software engineering and knowledge work. It then turns to enterprise deployment: MXFP4 quantization, serving with frameworks such as vLLM and SGLang, containerized cluster setup, and multi-turn tool-calling integration through OpenAI-compatible APIs, including a working code example and best practices for preserving full reasoning and tool-call history.

    As large language models scale toward trillions of parameters, a core challenge emerges at both the infrastructure and algorithm levels: how to keep inference compute costs under control while giving models the ability to handle extremely long contexts and execute long-horizon, multi-step tasks. A recently open-sourced MoE (mixture-of-experts) model—2.8 trillion total parameters with 104B activated per inference—tackles this challenge head-on. It natively supports 1M-token context input and multimodal image-text understanding, and its post-training stage incorporates joint reinforcement learning spanning hundreds of domains. The result is a model with remarkable potential for long-horizon agents, software engineering, and complex digital office scenarios. This article analyzes the core logic of this technical approach and its practical guidance across four dimensions: architecture evolution, agent capability building, engineering deployment, and enterprise adoption.

    1. MoE Architecture Evolution and Sparse Attention Innovation

    In ultra-large models, traditional dense networks drive inference memory usage and computational complexity up linearly or even exponentially. The MoE architecture used here carries 2.8T total parameters but activates only 104B, with a dynamic routing mechanism that assigns each input to the most relevant expert networks—effectively balancing model capacity against inference cost.

    1.1 Engineering Refinements to Sparse Attention

    At million-token context lengths, the O(N²) complexity of conventional self-attention becomes a prohibitive bottleneck. This model’s attention stack was deeply restructured: the original 24-layer Gated MLA was replaced with Gated DSA (Dynamic Sparse Attention) and combined with 69 layers of Kimi Delta Attention.

    • Dynamic sparse selection: At every attention computation, DSA dynamically selects the 2,048 most relevant historical tokens to participate. This importance-based sparse sampling lets the model retain global awareness of long documents while significantly reducing memory read/write bandwidth pressure.
    • Gating and attention coordination: A gating mechanism further regulates information flow, ensuring that key logical anchors and multi-step instructions are not drowned out in ultra-long contexts—markedly improving the coherence of long-horizon reasoning.

    1.2 Multi-Domain Joint Reinforcement Learning Post-Training

    Pre-training establishes the model’s base capabilities, but agent skills such as instruction following and tool calling depend heavily on the post-training stage. This model was post-trained with joint reinforcement learning covering hundreds of downstream domains. In addition, MXFP4 weight quantization drastically shrinks the model’s weight footprint while preserving accuracy, making single-node and multi-node inference practical.

    2. Building Long-Horizon Agent Capabilities and Key Scenarios

    The essence of a long-horizon agent is a closed execution loop: understand the goal, decompose it into steps, call tools, and correct based on feedback. With native multimodal input and ultra-long context, the model demonstrates strong potential for real-world engineering applications in the following high-value scenarios:

    2.1 Code Development and Complex Software Engineering

    For long-horizon coding agent tasks, the model needs to do more than generate code—it must handle terminal operations, code repair, and 3D CAD generation. On software engineering benchmarks such as SWE Marathon and DeepSWE, the model can combine external tools to autonomously complete long task chains: environment setup, code reading, bug localization, multi-file modification, and test verification.

    2.2 Multimodal Agents and Knowledge Workflows

    In knowledge work scenarios such as office document processing and financial research, the model supports native image-text input and web search. Developers can configure one of three thinking budgets—low, high, or max—depending on the task’s latency and depth requirements:

    • Low: for low-latency scenarios such as simple Q&A and information extraction.
    • High: for general logical reasoning and single tool calls.
    • Max: for complex multi-step agent tasks (such as automatically drafting in-depth research reports or generating 3D modeling instructions), enabling deep chain-of-thought reasoning.

    3. Enterprise-Grade Containerized Deployment and Inference Serving

    Open-source models lower the barrier to entry, but plugging them smoothly into an enterprise’s existing IT architecture still depends on solid cloud-native infrastructure. In practice, high-availability inference clusters are typically built by combining a container platform, distributed storage, and load balancing services.

    3.1 Inference Framework Adaptation and Quantized Deployment

    The model’s weights use the MXFP4 quantization format, which requires the underlying inference engine to parse the corresponding precision. Mainstream open-source inference frameworks such as vLLM and SGLang already offer deep integration. At deployment time, you can use container orchestration to spin up inference pods and mount the massive model weights from a high-speed distributed file system or object storage, enabling fast loading across nodes.

    3.2 Compatible APIs and Multi-Turn Tool Calling Integration

    To fit into existing business systems quickly, inference services are usually wrapped in an API gateway exposing OpenAI- or Anthropic-compatible endpoints. In long-horizon agent scenarios, how you handle the history of multi-turn tool calls is especially critical.

    Engineering best practice: Across multi-turn conversations and tool calls, developers must retain the complete “thinking history” and “tool call messages” in every request. In long-horizon tasks, the model depends on the reasoning context of earlier steps and on tool execution results to decide its next action. The following is a simplified example of building multi-turn agent calls:

    1. import requests
    2. import json
    3. # Internal enterprise inference gateway (OpenAI-compatible API standard)
    4. API_ENDPOINT = "https://internal-inference-gateway/v1/chat/completions"
    5. def execute_long_horizon_task(system_prompt, user_query, tool_definitions):
    6. """
    7. Example of executing a long-horizon agent task
    8. """
    9. messages = [
    10. {"role": "system", "content": system_prompt},
    11. {"role": "user", "content": user_query}
    12. ]
    13. max_iterations = 10
    14. for i in range(max_iterations):
    15. payload = {
    16. "model": "moe-2.8t-agent",
    17. "messages": messages, # The full history chain must be preserved
    18. "tools": tool_definitions,
    19. "tool_choice": "auto",
    20. "thinking_budget": "max" # Enable the highest thinking budget tier
    21. }
    22. response = requests.post(API_ENDPOINT, json=payload)
    23. res_json = response.json()
    24. assistant_message = res_json["choices"][0]["message"]
    25. # Append the assistant reply (including thinking and tool call directives) to the history
    26. messages.append(assistant_message)
    27. if not assistant_message.get("tool_calls"):
    28. # No tool calls means the model has reached a final conclusion
    29. print("Task Completed.")
    30. return assistant_message["content"]
    31. # Execute external tools and feed results back (retain full tool call messages)
    32. for tool_call in assistant_message["tool_calls"]:
    33. tool_name = tool_call["function"]["name"]
    34. tool_args = json.loads(tool_call["function"]["arguments"])
    35. # Execute the concrete tool logic (e.g., querying a database, calling an API)
    36. tool_result = execute_external_tool(tool_name, tool_args)
    37. # Append the tool result to the context with the dedicated tool role
    38. messages.append({
    39. "role": "tool",
    40. "tool_call_id": tool_call["id"],
    41. "content": str(tool_result)
    42. })
    43. return "Max iterations reached without final answer."

    In this workflow, an enterprise can hook logging services and monitoring/alerting systems into the API gateway to track, in real time, token consumption under different thinking budgets, tool call success rates, and average response latency—then continuously refine the agent’s prompts and tool definitions.

    4. Summary and Outlook

    From the open-sourcing of a 2.8T MoE architecture, to the introduction of Gated DSA sparse attention, to the deep integration of tiered thinking budgets with long-horizon agent capabilities, this release reflects the industry’s broader shift from “purely stacking parameters” toward “complex task executors.” For developers and enterprises, provided they comply with the applicable open-source license terms (such as a custom non-permissive license), mature cloud-native infrastructure and containerized deployment make it realistic to quickly bring a model with million-token context and multi-step reasoning into internal business workflows—moving from knowledge Q&A toward automated knowledge work.