Short answer: treat 256GB as a tight boundary for 4-bit Qwen3.5-397B-A17B, 320GB as the practical 4-bit tier, 480GB as a tight FP8/Q8 boundary, 512GB as the practical FP8/Q8 tier, and 1TB as the practical tier for Qwen’s official 806.796GB BF16 checkpoint. File fit is only the first gate: multi-device placement, topology and per-device headroom determine whether a deployment actually works.
A17B does not mean 17GB of stored weights. Qwen3.5-397B-A17B is a sparse mixture-of-experts model. The active-parameter label describes routed computation; the runtime still needs access to the full expert-weight set, vision components, cache and working allocations.
Qwen3.5-397B-A17B files and practical tiers
| Deployment path | Repository total | Planning tier | Provenance |
|---|---|---|---|
| Official GPTQ-Int4 safetensors | 235.708GB | 256GB tight; 320GB practical | First-party Qwen |
| Community Q4_K_M + F16 projector | 245.012GB | 256GB very tight; 320GB practical | Unsloth conversion |
| Official FP8 safetensors | 406.152GB | 480GB tight; 512GB practical | First-party Qwen |
| Community Q8_0 + F16 projector | 422.426GB | 480GB tight; 512GB practical | Unsloth conversion |
| Official BF16 safetensors | 806.796GB | 800GB does not hold files; 1TB practical | First-party Qwen |
Why 256GB, 480GB and 800GB are boundary cases
The official GPTQ checkpoint already totals 235.708GB, while community Q4_K_M plus its F16 projector totals 245.012GB. A nominal 256GB pool therefore leaves limited space for cache, hybrid-attention state, vision processing, allocator behavior and compute buffers. Official FP8 totals 406.152GB and community Q8_0 plus projector totals 422.426GB, so 480GB can be workable but still demands measured headroom. The official BF16 checkpoint exceeds 800GB before the runtime allocates anything; 800GB is not a valid all-accelerator file-fit tier.
Hybrid attention: calculate only the justified component
Qwen’s official configuration lists 60 language layers in a repeating pattern of three linear-attention layers followed by one full-attention layer. That yields 45 linear-attention layers and 15 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 × 15 × 2 × 256 × 2 = 30,720 bytes, or 30KiB per allocated token. Do not apply a conventional KV-cache formula to all 60 layers: the linear-attention layers maintain implementation-dependent recurrent and convolution state.
| Allocated tokens | Full-attention KV payload only |
|---|---|
| 8K | 0.2344GiB |
| 32K | 0.9375GiB |
| 64K | 1.875GiB |
| 128K | 3.75GiB |
| 256K native maximum | 7.5GiB |
Multi-device and MoE safeguards
- Experts: Qwen’s configuration documents 512 experts and ten 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 accelerator needs local headroom for its assigned weights and temporary allocations.
- Topology: record PCIe, NVLink/NVSwitch, InfiniBand and host layout; capacity alone 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, the MTP layer and multimodal kernels.
- Offload: report CPU or storage offload separately; system RAM is not dedicated VRAM and transfer overhead can dominate.
Qwen3.5-397B-A17B versus 122B-A10B
The Qwen3.5-122B-A10B guide covers a smaller sparse sibling whose official GPTQ checkpoint totals 78.864GB and BF16 checkpoint totals 250.173GB. The 397B model increases the expert count from 256 to 512 and routed experts from eight to ten. 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, MTP and image/video support.
- Record tensor/pipeline/expert parallelism, per-device placement, offload and interconnect topology.
- Record weight, projector, full-attention KV and linear-state precision.
- Fix context allocation, image/video workload, output target, batch size 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, interconnect traffic, 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.
Large-model workstation path: compare the Mac Studio M5 Ultra and RTX 5090 against the exact 397B Qwen artifact sizes, including the 256GB and 512GB unified-memory boundaries.
Hardware path comparison: map 96GB through 1TB-class systems to exact Qwen3.5-122B and 397B files without confusing aggregate capacity with automatic pooling.
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: use the MI300X local-AI guide to map two, three, six and eight-accelerator capacity to Qwen3.5-397B artifacts without assuming automatic pooling.
512GB unified-memory path: use the M5 Ultra Mac Studio guide to distinguish 397B 4-bit/FP8 file fit from shared-memory headroom and measured performance.
\n\nSplitting 397B across datacenter accelerators? The MI300X vs H200 guide shows arithmetic minima, per-device headroom and topology safeguards.
\n\nOne-device 397B 4-bit candidate: review the MI325X 256GB guide for exact GPTQ/Q4 margins and multi-device FP8, Q8 and BF16 paths.
The 288GB tier can hold the listed 4-bit files on one accelerator; review the caveats in the MI350X and MI355X model-fit guide.
One B300 can hold the listed 4-bit files by capacity; see the exact margins and platform caveats in the NVIDIA B300 guide.
The 288GB-class one-device 4-bit paths are compared directly in NVIDIA B300 vs AMD MI355X.
Choosing an NVIDIA datacenter tier for this model? See the B200 vs B300 model-fit comparison for exact 397B device-count boundaries.
Considering 180GB NVIDIA hardware? See the B200 model-fit guide for exact 397B device-count boundaries.
Choosing between 80GB and 180GB NVIDIA tiers? See the H100 vs B200 model-fit comparison for exact 397B device-count boundaries.
Choosing among 192GB-to-288GB AMD tiers? See the AMD Instinct decision hub for exact 397B device-count boundaries.
One-system capacity path: compare DGX Spark with Mac Studio to see which 397B artifacts require 256GB or 512GB unified memory.