Eight 80GB accelerators sound like a 640GB platform, but the official DeepSeek-V3.2 checkpoint files total 689.483GB. The files alone exceed that nominal aggregate by 49.483GB—before KV cache, runtime workspaces, communication buffers or per-device imbalance. This is an arithmetic capacity failure, not a benchmark result.
The decisive boundary
- 640GB (8×80GB): 49.483GB short by official files. A wholly accelerator-resident load is impossible at this capacity.
- 720GB: 30.517GB file-only margin. That is extremely constrained before live state and uneven placement.
- 768GB (8×96GB): 78.517GB file-only margin. The files clear aggregate capacity, but a viable distributed run is still unproven.
- 864GB: 174.517GB file-only margin, with topology, software and workload checks still required.
The full DeepSeek-V3.2 VRAM guide documents both the standard and Speciale repositories, exact blob totals, the 163,840-position configuration ceiling and every boundary from 512GB through 1,024GB.
Why eight 80GB GPUs cannot hold the official files
Both official repositories contain 163 safetensors files totaling 689,483,049,129 bytes. Tensor parallelism, pipeline parallelism or expert placement can distribute those files, but none can turn 640GB into 689.483GB. A smaller configuration can load only by changing the artifact or placing some tensors in host memory or storage. That may be useful, but it must be reported as offload rather than a resident fit.
Why 768GB is a starting point, not a guarantee
Eight nominal 96GB devices provide 768GB in aggregate, leaving 78.517GB after the checkpoint files. Real deployments need memory on every device for cache, activations, communication and temporary workspaces. Expert or tensor shards may not balance perfectly, and some allocations may be duplicated. The runtime, driver, kernels, topology and exact placement plan must all support the chosen model.
The configs publish a maximum of 163,840 positions. That is an architecture ceiling, not proof that maximum context fits on a minimum-capacity cluster. Report actual input tokens, generated tokens, cache precision, batch and concurrency rather than quoting the ceiling as a workload.
Standard versus Speciale
DeepSeek-V3.2-Speciale is described by its publisher as a high-compute reasoning variant. Its current official checkpoint has the same summed file total as the standard model, but it remains a different artifact. Benchmark records should name the exact repository and revision; equal file size does not establish equal behavior, quality or speed.
What a useful result must disclose
- Exact V3.2 or V3.2-Speciale repository and revision.
- Every accelerator, its exposed memory and the host system.
- Interconnect and physical topology.
- Tensor, pipeline, expert or other placement per device.
- Host-memory or storage offload, if any.
- Runtime, build, driver, kernels and launch flags.
- Input/output tokens, context setting, batch, concurrency and cache precision.
- Per-device peak memory, system-memory peak, prompt processing, decode and time to first token.
Plan multi-GPU placement, compare NVIDIA data-center tiers, check source-specific measurements, or build a reproducible DeepSeek record. Follow the RSS feed for future evidence.
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
Published October 25, 2026. File-size arithmetic is not an independent performance benchmark.