Qwen3.8-Max

Qwen3.8-Max is Alibaba's flagship Qwen model, and it is the largest the team has shipped: a sparse mixture-of-experts system with 2.4 trillion total parameters and roughly 95 billion active per token. It is multimodal (text, images, video, and documents in, text out), carries a 1M-token context window, and is positioned against frontier closed models rather than the small local models Qwen is best known for. Alibaba serves it through Alibaba Cloud Model Studio and QwenCloud at $2 per million input tokens and $6 per million output tokens. Open weights are promised for the week after launch, with no licence specified at the time of writing.

The practical headline for anyone building on this: Qwen3.8-Max is a datacenter-class model. It leads Alibaba's published benchmark table on PaperBench (93.0) and IFBench (82.8), and it is competitive on GPQA Diamond (92.6). It also trails Claude Fable 5 on SWE-bench Pro by 12.3 points (67.7 vs 80.0) and on HLE (43.6 vs 53.3). Several of those rows are Alibaba's own internal benchmarks (QwenSWEBench, QwenQoderBench, CoWorkBench, SkillsBench), so treat them as directional rather than independently verified.

If you landed here because you want to run Qwen locally, read the Running Locally section before you get excited. The 2.4T figure is not a typo, and it changes everything about hardware requirements.

Qwen3.8-Max uses a sparse mixture-of-experts architecture. Total parameter count is 2.4T; active parameters per token are about 95B. That ratio (roughly 4% active) is what makes the model servable at all. A dense 2.4T model would be prohibitively slow and expensive; a sparse MoE routes each token through a small subset of experts, so compute scales with active parameters while capacity scales with total.

For inference, the number that governs speed is 95B active. That is still large by local standards: it is roughly the compute footprint of a dense ~95B model per token, well beyond any single consumer GPU. VRAM, however, is driven by total parameters, not active ones, because all experts must be resident (or paged) to route correctly. At Q4_K_M, 2.4T parameters land around 1.2TB of weights. At FP8, closer to 2.4TB. No consumer configuration holds this.

The 1M-token context window is the other defining spec. It enables whole-repository code analysis, long document sets (contracts, filings, design specs), and multi-hour agent traces without chunking. Alibaba lists 991K maximum input, 131K maximum output, and 262K maximum reasoning on the QwenCloud model page.

Listed capabilities: chat, code, vision, reasoning, function-calling.

• Coding: strong on agentic and frontend generation tasks. Alibaba's internal QwenReactBench and QwenSVGBench show leads, but the public SWE-bench Pro gap to Claude Fable 5 (67.7 vs 80.0) is real. Good for long-horizon repo work; verify before trusting it on hard bug-fix benchmarks.
• Reasoning: GPQA Diamond at 92.6 puts it level with Opus 4.8 and Fable 5. HLE at 43.6 sits behind Fable 5's 53.3.
• Vision: native multimodal, the first Qwen above 1T parameters to ship with it. Useful for document understanding, chart and diagram reasoning, and screenshot-driven agent loops.
• Function-calling and agents: endpoints speak both OpenAI and Anthropic protocols, so it drops into Claude Code, Cursor, and OpenCode without harness changes. CoWorkBench and SkillsBench (internal) target long-horizon autonomous tasks.
• Professional work: Alibaba explicitly targets legal, financial, and design tasks, which is where the 1M context matters most.

You cannot run the full Qwen3.8-Max on consumer hardware. This is not a "needs a 4090" situation; it is a "needs a rack" situation.

VRAM requirements by precision (weights only, before KV cache and activations):

• FP16: ~4.8TB
• FP8: ~2.4TB
• Q4_K_M: ~1.2TB
• Q2_K: ~600GB (quality loss is severe at this scale)

For reference, an RTX 4090 has 24GB, an M4 Max tops out at 128GB of unified memory, and a maxed Mac Studio M3 Ultra reaches 512GB. None of these fit even a Q2 build of the full model. Multi-GPU H100 or H200 nodes with 1.5TB+ of aggregate VRAM are the realistic floor.

Tokens per second depends almost entirely on the serving stack and interconnect. On an 8x H200 node with FP8 and expert parallelism, expect low double-digit to low triple-digit tok/s for single-stream generation, higher under batched serving. On anything less, you are paging experts off disk, and throughput collapses.

Best quantization for Qwen3.8-Max: FP8 is the practical production choice. Q4_K_M is only relevant if you are running the open weights on a very large unified-memory box, and the quality hit at that scale is not worth it for most workloads.

Ollama: there is no ollama pull qwen3.8-max that fits your machine. If you want a locally runnable Qwen, look at the smaller siblings in the family (Qwen3 30B-A3B and similar MoE variants) that target consumer VRAM budgets. Those are the models madebyagents.com covers in the local-hardware tier.

If your actual goal is local inference, Qwen3.8-Max is the wrong target. Use it through Alibaba Cloud Model Studio as a reference or teacher model, and run a smaller Qwen locally.

vs Kimi K3 (Moonshot): Kimi K3 is open-weight and launched days before Qwen3.8-Max's preview. If open weights ship on schedule, Qwen3.8-Max competes on context length (1M) and multimodal breadth; Kimi K3 competes on openness and licensing clarity. Both are datacenter models, not local ones.

vs Claude Fable 5: Fable 5 leads on SWE-bench Pro (80.0 vs 67.7) and HLE (53.3 vs 43.6). Qwen3.8-Max wins on PaperBench (93.0) and IFBench (82.8), and it is cheaper at $2/$6 per million tokens. Choose Qwen3.8-Max when cost and 1M context dominate; choose Fable 5 when hard agentic coding accuracy is the priority.

For local deployments, neither is the answer. The comparison that matters for madebyagents.com readers is between the smaller Qwen MoE variants you can actually run, and those are a different page.