Short answer: treat 80GB as a file-size boundary for 4-bit Qwen3.5-122B-A10B, 96GB as the practical 4-bit tier, 128GB as a tight FP8/Q8 boundary, 160GB as the practical FP8/Q8 tier, and 256GB/320GB as the very-tight/practical tiers for Qwen’s official 250.173GB BF16 checkpoint. Multi-device placement and per-device headroom matter as much as summed capacity.
A10B is not a 10B storage requirement. Qwen3.5-122B-A10B is a sparse MoE model. The active-parameter label describes routed computation; the runtime still needs access to the full expert-weight set plus vision, cache and runtime allocations.
Qwen3.5-122B-A10B files and practical tiers
| Deployment path | Repository total | Planning tier | Provenance |
|---|---|---|---|
| Community Q4_K_M + F16 projector | 77.446GB | 80GB very tight; 96GB practical | Unsloth conversion |
| Official GPTQ-Int4 safetensors | 78.864GB | 80GB very tight; 96GB practical | First-party Qwen |
| Official FP8 safetensors | 127.163GB | 128GB tight; 160GB practical | First-party Qwen |
| Community Q8_0 + F16 projector | 130.781GB | 128GB does not hold files; 160GB practical | Unsloth conversion |
| Official BF16 safetensors | 250.173GB | 256GB very tight; 320GB practical | First-party Qwen |
Why 80GB, 128GB and 256GB are boundary cases
The official GPTQ checkpoint already totals 78.864GB, and the community Q4 plus projector totals 77.446GB. An 80GB deployment therefore leaves little room for cache, hybrid-attention state, vision processing, allocator behavior, compute buffers or display use. Likewise, official FP8 totals 127.163GB before runtime state, while community Q8 plus projector exceeds 128GB. The BF16 checkpoint totals 250.173GB, leaving less than 6GB across a nominal 256GB pool before runtime allocations.
Hybrid attention: calculate only the justified component
Qwen’s official configuration lists 48 language layers in a repeating pattern of three linear-attention layers followed by one full-attention layer. That yields 36 linear-attention layers and 12 full-attention layers. The full-attention blocks use two KV heads with a 256-element head dimension.
With FP16/BF16 keys and values, the sequence-linear full-attention component is 2 × 12 × 2 × 256 × 2 = 24,576 bytes, or 24KiB per allocated token. Do not apply a conventional KV-cache formula to all 48 layers: the linear-attention layers maintain implementation-dependent recurrent and convolution state.
| Allocated tokens | Full-attention KV payload only |
|---|---|
| 8K | 0.1875GiB |
| 32K | 0.75GiB |
| 64K | 1.5GiB |
| 128K | 3GiB |
| 256K native maximum | 6GiB |
Multi-device and MoE safeguards
- Experts: Qwen’s configuration documents 256 experts and eight routed experts per token; active computation is not stored-weight memory.
- Placement: record tensor, pipeline and expert parallelism plus every shard, expert and projector assignment.
- Per-device fit: summed capacity is not automatic pooling; each device needs local headroom for its assigned weights and temporary allocations.
- Topology: record PCIe, NVLink/NVSwitch and host layout; capacity does not establish throughput.
- Vision: test image/video input, not only text generation; community GGUF needs the matching projector.
- Runtime: verify exact-version support for Qwen3.5 MoE, Gated DeltaNet, quantization and multimodal kernels.
Qwen3.5-122B-A10B versus 35B-A3B
The Qwen3.5-35B-A3B guide covers a smaller sparse sibling whose community Q4-plus-projector pair is 22.915GB and official BF16 checkpoint is 71.904GB. Both use 256 experts and eight routed experts per token, but their stored weights, architecture depth and deployment tiers differ. Fit does not establish a universal speed, quality or visual-accuracy winner.
Reproducible multi-device fit test
- Record the exact repository, revision, quantization, every shard/projector file and checksum.
- Record runtime/version and verify Qwen3.5 MoE, hybrid attention and image/video support.
- Record tensor/pipeline/expert parallelism, per-device placement, offload and topology.
- Record weight, projector, full-attention KV and linear-state precision.
- Fix context allocation, image/video workload, output target and concurrency.
- Measure accelerator and system memory per device before load, after load, after vision encoding and at peak generation.
- Capture preprocessing time, time to first token, throughput, communication/fallback and errors.
Continue with the Qwen3.5 family hub, MoE VRAM guide, multi-GPU memory guide, 48GB–96GB capacity guide, multimodal hub, VRAM calculator, workload test, benchmark submission or all guides and tools.
Sources and limits
- Qwen official BF16 repository
- Qwen official FP8 repository
- Qwen official GPTQ-Int4 repository
- Qwen official configuration
- Unsloth community GGUF conversion
- HighVRAM methodology
Reviewed October 25, 2026. Repository totals were summed from all displayed shards. Qwen BF16, FP8 and GPTQ are first-party; GGUF/projector totals are from the separately labeled Unsloth conversion. HighVRAM has not independently benchmarked every topology, runtime, kernel, quantization or multimodal workload. File size is not peak resident memory.
96GB versus larger shared-memory path: compare the Mac Studio M5 Ultra and RTX 5090 against the exact 122B Qwen artifact sizes, including the tight 256GB shared-memory boundary.
80GB, 94GB or 96GB platform path: compare RTX PRO 6000 Blackwell with H100 using this guide’s exact 122B GPTQ, Q4-plus-projector, FP8, Q8-plus-projector and BF16 totals.
Larger Qwen3.5 MoE: the Qwen3.5-397B-A17B VRAM guide covers exact official GPTQ, FP8 and BF16 totals plus 256GB-to-1TB multi-device planning.
Hardware path comparison: compare 96GB RTX PRO, 141GB H200, 192GB MI300X and larger multi-device capacity paths for Qwen3.5-122B and 397B.
Track matching hardware
Save a private browser-only hardware watchlist or choose a focused RSS feed. No account or email address is required; the watchlist stays in this browser and does not send price alerts.
192GB accelerator path: see the MI300X local-AI guide for official HBM3/platform evidence and Qwen3.5-122B FP8 single-device safeguards.
Unified-memory path: see the M5 Ultra Mac Studio guide for 96GB/256GB/512GB Qwen3.5-122B capacity and MLX/runtime checks.
\n\nPlanning a dedicated-HBM deployment? Compare MI300X 192GB with H200 141GB for this model’s GPTQ, FP8, Q8 and BF16 paths.
\n\nConsidering a 256GB AMD accelerator? The MI325X guide shows why the 250.173GB BF16 files remain a file-only boundary rather than a practical fit guarantee.
A 288GB accelerator adds meaningful BF16 file headroom; see the exact arithmetic in the MI350X and MI355X 288GB guide.
For a CUDA datacenter path near this BF16 boundary, see the NVIDIA B300 288GB guide and its 270GB usable-capacity calculation.
Compare how the same checkpoint boundary differs across CUDA and ROCm systems in B300 vs MI355X.
Choosing an NVIDIA datacenter tier for this model? See the B200 vs B300 model-fit comparison for exact 122B margins through BF16.
Considering 180GB NVIDIA hardware? See the B200 model-fit guide for exact 122B margins through BF16.
Choosing between 80GB and 180GB NVIDIA tiers? See the H100 vs B200 model-fit comparison for exact 122B margins.
Choosing among 192GB-to-288GB AMD tiers? See the AMD Instinct decision hub for exact 122B margins.
Workstation-to-Hopper boundary: compare RTX 6000 Ada 48GB with H100 80GB and 94GB using this model’s exact 4-bit file margins and platform safeguards.
Older workstation-to-Hopper boundary: compare RTX A6000 48GB with H100 80GB and 94GB using this model’s exact 4-bit file margins and platform safeguards.
Testing the 80GB file boundary on Ampere? Compare RTX A6000 48GB with A100 40GB/80GB; the 77.446GB and 78.864GB 4-bit paths remain unsafe on nominal 80GB.
Testing the 80GB boundary against a 48GB Ada workstation? Compare RTX 6000 Ada with A100 40GB/80GB; the 77.446GB and 78.864GB paths remain unsafe on nominal 80GB.
Testing the 80GB server boundary? Compare L40S 48GB with A100 40GB/80GB; the 77.446GB and 78.864GB paths remain unsafe on nominal 80GB.
Testing 80GB and 94GB Hopper against a 48GB server card? Compare L40S with H100; the 122B 4-bit margins remain unsafe on ordinary 80GB.
Testing the 80GB boundary within Ampere? Compare A40 48GB with A100 40GB/80GB; the 122B 4-bit margins remain unsafe on nominal 80GB.
Applying the 122B boundaries to NVIDIA servers? Compare A40 48GB with H100 80GB/94GB, including the unsafe 80GB 4-bit margins and exact platform requirements.
Testing the 80GB/94GB boundary? Compare RTX 5090 with H100 to see why the listed 122B 4-bit files remain unsafe on 80GB and bounded on 94GB.
Testing the 141GB boundary? Compare RTX 5090 with H200 to see the exact 122B GPTQ, Q4, FP8, Q8 and BF16 file outcomes.
128GB system check: see which listed 122B artifacts pass the first file-size gate in RTX 5090 vs DGX Spark and why 127.163GB remains unsafe.
128GB boundary: compare the listed 122B artifacts in DGX Spark vs Mac Studio and see why the 127.163GB FP8 file is unsafe on either 128GB system.
96GB-versus-128GB boundary: compare the listed 122B artifacts in DGX Spark vs RTX PRO 6000.
DGX Spark alternatives: Map the listed 122B artifacts to DGX Spark alternatives in the constraint-first comparison hub.
DGX Spark vs H100: Map the listed 122B boundaries to DGX Spark and H100 in the exact capacity and platform comparison.
DGX Spark vs H200: Map the exact 122B boundaries to DGX Spark and H200 in the exact 128GB-versus-141GB comparison.
See the exact 128GB-shared-versus-40GB/80GB-dedicated decision in DGX Spark vs A100.
For a 24GB no-fit path versus a 128GB shared-memory path, compare RTX 4090 with DGX Spark.
For a 24GB no-fit path versus a 128GB shared-memory path, compare RTX 3090 with DGX Spark.
Testing this model’s 80GB boundary? Apply the exact 77.446GB and 78.864GB margins in the A100 80GB versus H100 80GB buyer guide; both remain unsafe before runtime allocations.