What is available now?
Qwen3.8 at a glance
Every row beyond the 2.4T parameter count and multimodal description is estimated from Qwen3 family precedent or community reports. Alibaba has not published architecture details, a model card, or a technical report. Treat all specifications as projected until official artifacts appear.
Qwen3.8 hardware requirements
No single consumer or prosumer device can hold Qwen3.8. The storage problem is fundamental: for MoE models, all expert weights must stay resident in memory even though only a subset activates per token. The MoE advantage reduces compute (fewer FLOPs per token), not memory.Weight-only memory at each quantization level
Weight memory is only the floor. Runtime overhead adds KV cache (which grows with context length and can exceed 100 GB per concurrent sequence at 1M context), CUDA graphs (5–15% of weight memory), framework overhead (2–8 GB), and OS reservation (4–16 GB).
Multi-node cluster requirements
These are theoretical calculations based on weight-only memory. Actual deployments need additional headroom for KV cache, runtime buffers, and concurrent request handling. The numbers above represent minimum node counts, not recommended configurations.
Can I run Qwen3.8 locally?
Not on a single device. Qwen3.8 requires a multi-node cluster at every quantization level. Here is what that means practically:- Enthusiast hardware (RTX 4090, single DGX Spark, single Strix Halo) — not viable. Even at Q2 quantization (~600 GB), you need at minimum 5 DGX Sparks or 50+ RTX 4090s.
- Prosumer clusters (2–4 DGX Sparks) — still insufficient. Four Sparks pool 512 GB, which falls short of even the Q2 weight floor.
- Mid-scale clusters (10–20 DGX Sparks, 16–32 H100s) — the minimum viable range. Q4 quantization across 10 Sparks or 16 H100s is theoretically feasible but leaves little headroom for context.
- Datacenter scale (20–40 nodes) — the realistic deployment target for FP8 or full-precision serving.
What you need
Minimum viable hardware at each quantization level:
Network interconnect matters at this scale. Tensor parallelism across nodes requires high-bandwidth, low-latency links (InfiniBand or RoCE). Standard Ethernet bottlenecks token generation.
Runtime support
No runtime supports Qwen3.8 today. Based on prior Qwen releases, expect this sequence after weights arrive:Smaller Qwen3.8 variants (e.g., a distilled dense model or a smaller MoE) may ship alongside or after the flagship. Those variants could fit single-node hardware and would have different runtime requirements. This page tracks the 2.4T flagship only.
What to expect when weights release
Based on the Qwen3 launch pattern:- HuggingFace model card appears with
config.jsonand weights - Transformers support via existing or new Qwen architecture handler
- vLLM and SGLang PRs for architecture support (hours to days)
- llama.cpp GGUF conversion and community quantizations (days to weeks)
- Ollama tags appear for any variants that fit single-node hardware
Qwen3.8 vs Qwen3-235B
Hardware recommendations by budget
Preparation checklist
If you plan to run Qwen3.8 when weights release:- Assess your cluster budget. At Q4, you need ~1.2 TB of GPU memory. For DGX Spark, that’s 10+ units. For H100 servers, that’s 16+ GPUs.
- Plan interconnects. Multi-node inference requires high-bandwidth networking. 200 Gb/s QSFP direct links between DGX Spark units have been demonstrated. For larger clusters, InfiniBand or RoCE is recommended.
- Benchmark current models. Run Qwen3-235B-A22B or Qwen3.5-122B-A10B now to establish baseline throughput and identify bottlenecks in your cluster configuration.
- Monitor runtime repos. Watch vLLM, SGLang, and llama.cpp repositories for Qwen3.8 architecture support PRs.
- Prepare storage. Full BF16 weights will be ~4.8 TB. Even Q4 GGUF files will be ~1.2 TB. Ensure adequate fast storage.
What to watch for
Key milestones that will change the content on this page:- Weights release — Alibaba confirmed open-weight but gave no date. Watch the Qwen HuggingFace organization and the QwenLM GitHub for the model card and checkpoint files.
- Architecture disclosure — dense vs MoE, active parameter count, expert routing, and context window are all unconfirmed.
- License publication — determines commercial use. Qwen3 used Apache 2.0.
- First runtime support — vLLM or SGLang PR for architecture support is the signal that self-hosting is possible.
- GGUF availability — required for llama.cpp multi-node RPC, which is the most likely path for DGX Spark and Strix Halo clusters.
- Smaller variants — if Alibaba ships distilled or smaller MoE variants, those may be the models most people actually run locally.
DGX Spark
Understand DGX Spark cluster sizing, memory pooling, and model compatibility.
Hardware reference
Compare GPU memory, interconnects, and pricing across consumer and datacenter hardware.
Qwen3.6
The current Qwen3 family (up to 235B) runs on single-node hardware today.
Model fit calculator
Calculate whether a model fits your hardware based on parameter count and quantization.
Quickstart
Pair a connector and register a local model that is available today.
Model serving and scaling
Understand tensor, pipeline, and expert parallelism before planning a frontier-scale cluster.