Short answer: Meta’s official Llama 3.2 90B Vision Instruct checkpoint contains 177.187GB across 37 BF16 safetensor shards. A community GGUF repository lists 55.6GB Q4_K_M, 95.8GB Q8_0 and 177GB F16. That makes 64GB a constrained Q4 path, 96GB a Q8 file-size trap, 128GB the practical Q8 tier, 192GB a constrained BF16 path, and 256GB the safer BF16 tier. Image processing, cache, runtime state and device placement can move each boundary upward.
Do not plan this like a text-only 90B model. Meta describes a separately trained vision adapter whose cross-attention layers feed image-encoder representations into the core language model. The image path has its own allocations and compatibility requirements.
Official Llama 3.2 90B Vision checkpoint
| Official evidence | Value | Planning meaning |
|---|---|---|
| BF16 shards | 37 files | All shards contribute to the checkpoint |
| Total bytes | 177,186,907,758 | 177.187GB / 165.018GiB before runtime state |
| Model parameters | 88.8B | Meta’s published exact count behind the 90B label |
| Input/output | Text + image in; text out | Budget vision processing as well as generation |
| Architectural context | 128K | Maximum accepted length, not a memory-fit promise |
64GB, 96GB, 128GB, 192GB or 256GB?
- 64GB: the 55.6GB community Q4_K_M example leaves about 8.4GB on the decimal labels before language cache, vision state and runtime buffers. Treat it as constrained.
- 96GB: the 95.8GB Q8_0 example is already a file-size trap. It leaves about 0.2GB before the rest of the workload.
- 128GB: the practical listed tier for Q8_0, with room that still depends on image count, context and runtime.
- 192GB: the official 177.187GB checkpoint leaves about 14.8GB on decimal labels. That can be consumed by a long cache, vision allocations and runtime state.
- 256GB: the safer BF16 planning tier, subject to software support and whether the platform exposes enough memory to the runtime.
Compare the 48GB-through-96GB tiers and use the VRAM calculator only as a starting range; it does not model every vision allocation.
Exact language-cache arithmetic
Meta’s architecture listing records 80 language layers, 8 KV heads, 64 attention heads and an 8,192 hidden size. The head dimension is 8,192 ÷ 64 = 128. For one sequence with a two-byte FP16/BF16 cache and every language layer on the accelerator:
bytes per token = 2 × 80 layers × 8 KV heads × 128 head dimension × 2 bytes
= 327,680 bytes
= 320 KiB per token| Allocated text-token slots | Illustrative FP16/BF16 KV payload |
|---|---|
| 4,096 | 1.25GiB |
| 8,192 | 2.5GiB |
| 32,768 | 10GiB |
| 131,072 | 40GiB |
A 32K cache plus the official checkpoint already consumes roughly the nominal 192GB margin before vision and runtime state. The 128K architectural maximum adds an illustrative 40GiB cache, which is why 192GB cannot be treated as a full-context BF16 guarantee.
What changes from the 11B Vision model?
The 11B Vision guide uses the same first-party method, but the language architecture changes from 32 to 80 layers and from 4,096 to 8,192 hidden dimensions. Meta lists 20 vision cross-attention layers for the 90B instruct model versus 8 for the 11B instruct model. Do not scale memory from the model-name ratio alone.
Community GGUF evidence is not a Meta release
The 55.6GB Q4_K_M, 95.8GB Q8_0 and 177GB F16 examples come from a third-party conversion, not Meta. Verify its revision, checksums, projector packaging, runtime compatibility and license obligations. Use the quantization guide without assuming that a smaller file preserves the same image or language behavior.
One large pool versus multiple devices
Two or more GPUs retain separate memory pools. A compatible runtime must explicitly place model components across them, and cross-device transfers can affect latency and throughput. Unified-memory systems share the pool with the operating system and applications. Review multi-GPU placement and VRAM versus unified memory before treating labels as equivalent.
A reproducible 90B Vision fit test
- Record exact repository, revision, license acceptance, all files and checksums.
- Record projector packaging, precision and runtime/version.
- Record every accelerator, device placement, interconnect, system RAM, OS and driver.
- Record image dimensions, chunk count, image count, text-token allocation, output target, concurrency and cache precision.
- Measure memory before load, after load, after image encoding and at peak generation on every device.
- Capture preprocessing time, time to first token, throughput, host-device traffic and any fallback or out-of-memory error.
- Evaluate image-grounded output quality; a successful load or generated sentence does not prove correct visual reasoning.
Run the same disclosed workload and share a reproducible result.
Continue planning
Official sources and limits
- Meta official gated model repository
- Meta official model card
- Meta Llama model list and context lengths
- Meta official architecture listing
- Community GGUF example
- HighVRAM methodology
Reviewed October 25, 2026. Official shard sizes, model identity and architecture fields come from Meta repositories; community GGUF examples are labeled separately. HighVRAM has not independently benchmarked every file, image configuration or runtime. Fit does not establish speed or output quality.
Compare the whole family: the Llama 3.2 VRAM hub places this 90B Vision checkpoint beside the official 1B, 3B and 11B Vision variants with exact cache geometry.