New 700GB-class workload: the Muse Spark Open VRAM guide separates its exact 533.011GB NVFP4 files from Meta’s official 700GB minimum and compares 640GB, 705GB, 720GB and 768GB pools.
Evaluating the tight 640GB boundary? See whether eight H100 80GB GPUs can run Kimi K2.5, including per-device margin and validation gates.
Ready to choose a platform? The Kimi K2.5 hardware guide compares ten NVIDIA and AMD capacity paths from 640GB through 864GB.
Short answer: the official moonshotai/Kimi-K2.5 checkpoint contains 595,177,988,208 bytes of listed .safetensors files—595.178 GB in decimal units. A 600GB pool clears the files by only 4.822GB, while 640GB leaves 44.822GB before runtime memory. For a practical full-model deployment, 768GB is the safer planning tier; it leaves 172.822GB for runtime overhead, cache, multimodal processing, and imperfect placement.
Kimi K2.5 checkpoint facts
- Official repository: moonshotai/Kimi-K2.5
- Listed safetensors: 64 files totaling 595,177,988,208 bytes (595.178GB decimal)
- Index metadata total: 595,148,192,736 bytes (595.148GB)
- Model card: 1T total parameters, 32B activated parameters, 256K context, and a 400M-parameter vision encoder
- Configuration: 61 layers, 384 routed experts, 8 experts selected per token, 262,144 maximum positions
- Quantization: mixed compressed-tensors configuration with groupwise 4-bit weights (group size 32), while numerous modules are explicitly excluded
The file listing and index metadata differ by 29,795,472 bytes, about 0.0298GB. That small difference reflects different accounting surfaces. For storage and the hard “can I even place these files?” boundary, this guide uses the actual listed blob total: 595.178GB.
VRAM capacity table
| Total VRAM | Margin after 595.178GB weights | Planning verdict |
|---|---|---|
| 512GB | −83.178GB | No: weights alone do not fit |
| 576GB | −19.178GB | No: weights alone do not fit |
| 600GB | +4.822GB | Paper fit only; not a practical runtime budget |
| 640GB (8×80GB) | +44.822GB | Very tight; topology, placement, runtime, and workload can break the fit |
| 705GB (5×141GB) | +109.822GB | More credible, but validate engine and per-device placement |
| 720GB (4×180GB) | +124.822GB | Workable planning tier with validation |
| 768GB (8×96GB) | +172.822GB | Safer full-model target |
| 864GB (3×288GB) | +268.822GB | Comfortable capacity tier |
| 1,024GB | +428.822GB | High headroom for demanding contexts and concurrency |
Capacity is aggregate only. It does not prove that a specific engine can shard every component evenly across those devices.
Why “32B active” does not mean 32B worth of VRAM
Kimi K2.5 is a mixture-of-experts model. Only a subset of experts is activated for each token, which reduces compute compared with activating all one trillion parameters. But the full expert set still has to be stored somewhere: GPU memory, system memory, or storage through an offload scheme. “32B activated” is therefore not a weight-storage estimate.
Why a simple 4-bit calculation is misleading
The checkpoint declares groupwise 4-bit weight quantization, but its configuration also lists many ignored modules, including attention components, shared experts, the vision tower, projector, and language-model head. Mixed treatment plus scales and packing metadata makes “1T × 4 bits = 500GB” an unsafe estimate. The official blobs provide the stronger capacity number: 595.178GB.
600GB versus 640GB versus 768GB
600GB: a mathematical boundary, not a recommendation
Only 4.822GB remains after the files. That is insufficient as a general runtime allowance. Framework state, CUDA allocations, kernels, buffers, cache, and uneven placement all compete for memory.
640GB: plausible but tight
Eight 80GB accelerators provide 640GB aggregate, leaving 44.822GB. The average margin is just 5.603GB per device before accounting for components that may not shard evenly. Treat this as a configuration to prove with the exact runtime and workload—not as a guaranteed fit.
768GB: the safer default plan
Eight 96GB devices provide 768GB and 172.822GB of aggregate margin. That does not guarantee success, but it creates substantially more space for the live serving process, multimodal inputs, longer contexts, and placement imbalance.
Context and multimodal memory
The configuration ceiling of 262,144 positions is not a promise that every deployment can serve that context economically. KV cache grows with context length, batch size, concurrency, precision, and engine design. Kimi K2.5 also includes a vision encoder and projector. Image and video workloads add preprocessing and live-memory demands beyond static weight storage.
Deployment safeguards
- Verify the engine supports Kimi K2.5 and its mixed compressed-tensors format.
- Check per-device placement, not just aggregate VRAM. A 640GB pool can still fail if one device receives an oversized unsharded component.
- Start with short context and batch size 1, then raise context and concurrency while recording peak memory.
- Reserve explicit runtime headroom. Do not budget every remaining gigabyte to KV cache.
- Model offload honestly. CPU or NVMe offload changes latency and bandwidth requirements; it does not make the weights disappear.
- Test multimodal workloads separately. Text-only success does not establish image/video capacity.
Practical recommendation
Use 595.178GB as the minimum official-checkpoint storage figure. Consider 640GB an experimental, tight configuration, 720GB a more credible planning tier, and 768GB the safer default target when the goal is a full-model GPU deployment with useful runtime headroom. If cost or hardware access rules those out, plan for offload or a smaller/derived checkpoint and measure the performance tradeoff.
Continue planning
- Plan a multi-GPU LLM build
- Understand multimodal VRAM overhead
- Compare NVIDIA high-VRAM hardware
- Compare AMD high-VRAM hardware
- Browse the hardware guide
- Submit missing hardware or corrections
Primary sources and method
- Official model card
- Hugging Face repository API with blob sizes
- Official configuration
- Official safetensors index
- Official GitHub repository
- Official deployment guidance
Method: summed the byte sizes of all 64 .safetensors entries returned by the official repository API, converted bytes to decimal GB (1GB = 1,000,000,000 bytes), and subtracted that result from each hardware tier. This is a capacity analysis, not a speed benchmark. Last checked October 25, 2026.