模型發布
Qwen3.8-Max Scales to a 2.4T Sparse MoE, With 27B and Flagship Weights Set to Open Next Week
Alibaba is moving Qwen3.8-Max to a production API, targeting software development and long-running knowledge work, while announcing plans to release weights for both the flagship and 27B models. The model ranks near the top of a community coding arena, but complete technical documentation on its architecture, active parameter count, and self-hosting costs remains unavailable.
Alibaba’s Qwen team has officially launched Qwen3.8-Max, promoting the previously limited-preview model to its next-generation flagship. The company says the model uses a sparse Mixture-of-Experts architecture with 2.4 trillion total parameters. Its product focus has shifted from general conversation toward software development, document processing, and long-running “cowork” tasks. Of particular interest to the open-source community, the team says it will release the weights for Qwen3.8-Max and the more locally deployable Qwen3.8-27B next week.
If the release proceeds as planned, its technical significance will go beyond the arrival of another large checkpoint. The deployability of a 2.4T MoE depends on how many parameters are actually activated per token, how experts are distributed, the size of the KV cache, and whether vLLM, SGLang, Transformers, and quantization tools can immediately recognize the new architecture. Even if the active parameter count is far below the total, loading the complete weights could still require rack-scale memory. The 27B version may instead become the primary model that developers can realistically evaluate on a workstation or single-node server.
Independent signals currently come mainly from blind testing on Arena. Qwen3.8-Max at one point achieved an Elo rating of approximately 1,668 on Frontend Code Arena, placing it among the leaders and close to more expensive models. However, Arena measures user preferences for generated websites, and results can be affected by the agent framework, sampling settings, and model version. They therefore cannot be directly extrapolated to the model’s ability to maintain large codebases or invoke tools correctly.
Engineering teams should not switch production models based solely on launch charts at this stage. The next step is to wait for the official model card, license terms, active parameter count, context-window specifications, and quantization details, then compare the API and self-hosted weights using a fixed evaluation harness. Teams should pay particular attention to repetitive loops during long-running tasks, the stability of tool-call parameters, comprehension of Chinese-language programming requirements, and whether different inference frameworks produce observable differences in quality.