Choosing a platform? Compare the 8×96GB, H200, B200/B300 and AMD Instinct hardware paths using the exact 689.483GB checkpoint boundary.
DeepSeek-V3.2 and DeepSeek-V3.2-Speciale are approximately 685B-parameter mixture-of-experts models, but parameter count alone is not the safest way to plan memory. Each official repository contains 163 safetensors files totaling 689,483,049,129 bytes, or 689.483GB in decimal units. The configs declare FP8 quantization with smaller BF16 and F32 tensors.
Short answer
- 640GB aggregate (8×80GB): the official files are 49.483GB larger than the nominal total. They do not fit wholly in accelerator memory before runtime overhead.
- 768GB aggregate (8×96GB): 78.517GB file-only margin. This is a lower-bound capacity check, not proof that an eight-device runtime has viable per-device shards or context headroom.
- 864GB aggregate: 174.517GB file-only margin.
- 1,024GB aggregate: 334.517GB file-only margin.
CPU or storage offload can make smaller accelerator configurations load, but placement and performance change. Report offload rather than calling it a resident fit.
The multi-GPU guide explains why aggregate memory is not one automatic pool. For smaller models, use the LLM VRAM calculator and hardware recommender.
Official repository facts
| Official repository | Repository parameter metadata | Maximum positions | Safetensors files | Total bytes | Decimal GB |
|---|---|---|---|---|---|
| deepseek-ai/DeepSeek-V3.2 | ~685.355B tensors across FP8, BF16 and F32 metadata | 163,840 | 163 | 689,483,049,129 | 689.483GB |
| deepseek-ai/DeepSeek-V3.2-Speciale | ~685.397B tensors across FP8, BF16 and F32 metadata | 163,840 | 163 | 689,483,049,129 | 689.483GB |
Both configs identify deepseek_v32, 61 layers, 256 routed experts, eight experts per token and max_position_embeddings: 163840. The repositories are not pure one-byte-per-parameter files: metadata reports mostly FP8 tensors plus smaller BF16 and F32 groups. That is why this guide sums the artifacts rather than multiplying a rounded parameter label.
File-only multi-accelerator boundaries
| Nominal aggregate accelerator memory | Checkpoint difference | File-only result |
|---|---|---|
| 512GB | 177.483GB short | Does not fit by files |
| 640GB (8×80GB) | 49.483GB short | Does not fit by files |
| 720GB | 30.517GB margin | Files fit in aggregate; very constrained before runtime memory |
| 768GB (8×96GB) | 78.517GB margin | Files fit in aggregate; placement and headroom still unproven |
| 864GB | 174.517GB margin | Files fit in aggregate |
| 960GB | 270.517GB margin | Files fit in aggregate |
| 1,024GB | 334.517GB margin | Files fit in aggregate |
Why eight 80GB GPUs are not enough by files
Eight nominal 80GB accelerators total 640GB, 49.483GB less than the official checkpoint files. No amount of tensor-parallel configuration turns 640GB into 689.483GB. A deployment can still load with host-memory or storage offload, but then it is not a wholly accelerator-resident eight-by-80GB run. The source should record how much resides on each device, host RAM, offloaded tensors, communication topology and observed transfer behavior.
Eight 96GB devices total 768GB and clear the file boundary by 78.517GB. That does not guarantee success: some allocations may be duplicated, shards may not balance evenly, expert placement can be constrained, and the framework needs room for cache, activations and communication buffers on every device.
Long context is a separate memory problem
The 163,840-position config value is an architecture ceiling, not a promise that the maximum sequence fits on a minimum file-capacity setup. KV cache, attention state, batch and concurrency consume additional memory. DeepSeek Sparse Attention is designed to reduce long-context computation, but “more efficient attention” does not eliminate checkpoint storage or prove a specific peak-memory figure.
For every result, state actual input length, generated tokens, batch, concurrency, cache precision and whether prefix caching or other runtime features were enabled.
V3.2 versus V3.2-Speciale
The official model card describes V3.2-Speciale as a high-compute reasoning variant. The two repositories currently have the same summed safetensors byte total, but they are different model artifacts and should not be treated as interchangeable benchmark workloads. Record the exact repository and revision. Output quality, reasoning behavior and speed are separate from file size.
Reproducible deployment checklist
- Name the exact variant: DeepSeek-V3.2 or DeepSeek-V3.2-Speciale, plus revision or commit.
- Record all devices: exact accelerator, form factor, exposed memory and count.
- Describe topology: PCIe, NVLink/NVSwitch, Infinity Fabric or other fabric and host layout.
- Record placement: tensor, pipeline, expert or data parallelism and per-device allocation.
- Disclose offload: host RAM, CPU placement, storage-backed tensors and transfer behavior.
- Pin software: runtime, version/commit, driver, kernels, operating system and launch flags.
- Define the workload: input/output tokens, context setting, batch, concurrency and cache precision.
- Measure separately: per-device peak memory, system memory, prompt processing, decode speed and time to first token.
Primary sources
- Official DeepSeek-V3.2 model card
- Official DeepSeek-V3.2-Speciale model card
- Official V3.2 repository API with blob sizes
- Official Speciale repository API with blob sizes
Reviewed October 25, 2026. File-size arithmetic is not an independent benchmark. Model capability statements remain vendor claims unless separately reproduced.