Kimi K3.1 Pro Open Weights: 1.56TB Model Needs 2TB VRAM, Macs 6x Short

True Open Weights, But License Has Commercial Restrictions

Moonshot AI uploaded the full Kimi K3.1 Pro inference weights to Hugging Face on 2026-11-02 and publicly released them on 2026-11-04, simultaneously on ModelScope. The release covers the standard version (not the Highspeed variant). The license is not OSI-approved nor pure MIT; it is a custom "Kimi K3.1-Pro License" that adds two restrictions on top of MIT:

Companies providing model-as-a-service (MaaS) with >$20M annual revenue must sign a separate agreement with Moonshot AI.

Products with >100M MAU or >$20M monthly revenue must prominently display "Kimi K3.1-Pro" in their UI.

Internal use (running locally, not exposing model capabilities externally) is fully exempt. For individual developers and internal enterprise deployment the license poses no obstacle, but anyone planning to sell inference services should read the license first.

Three Numbers You Must Not Confuse

2.8T = total parameters (precisely 2.78T, ~2,780,110,363,392). This describes model size, not file size.

5.6TB = BF16 theoretical size (2.8T × 2 bytes). The vendor never released this version ; do not use it as a scare tactic.

1.56TB = actual MXFP4 weight size , split into 96 safetensors shards (~1,561,293,160,568 bytes). About 2.72T parameters are MXFP4 routed experts; ~57.4B parameters (shared experts, attention, vision tower MoonViT-V2, 401M params) remain BF16. Average ~0.56 bytes/parameter (~4.5 bits).

Runtime VRAM exceeds 1.56TB because attention, shared experts, and vision tower stay BF16. The official vLLM recipe pegs MXFP4 footprint at 1874GB; adding KV cache and overhead pushes single-node VRAM requirement to ≥2TB .

Further quantization cannot help — the model is already trained with quantization-aware training at MXFP4 weights / MXFP8 activations. Going to 2-bit or 1-bit is the only path. Last year's K3 1-bit UD-IQ1_S (594GB) on 4×A100 + 2TB RAM achieved only 0.10 tok/s (~10 seconds per token, 1h23m for 500 tokens). That was K3, not K3.1 Pro.

How Far Your Mac Falls Short

Comparing the 1.56TB weight against Mac unified memory:

24GB → ~65× short

64GB → ~24× short

128GB → ~12× short

256GB → 6.1× short (source of "6×" in title)

512GB Mac Studio → 3× short

This is weight only; runtime VRAM demand is even higher. No Mac can hold the full weights.

Community progress (as of 2026-11-10):

DevQuasar's experimental 2-bit GGUF (Q2_K ~1.01TB) on Hugging Face, based on third-party kimi-k31 fork, labeled VERY EXPERIMENTAL . Still ~2× larger than 512GB Mac, quality unverified.

Rumor of a 220GB MLX repack by Inferencer Labs that offloads experts to storage on M3 Ultra 512GB, but speed column blank ("~ tokens/s"), unverifiable.

Do not expect a future quantization to fit on a Mac — even a true 2-bit build would far exceed top-end unified memory.

Two Viable Paths to Use the Model

Path 1: Data-center GPU self-deployment. Official vLLM recipe minimum: 8-GPU tensor parallel — two GB300 trays, or one 8×B300, or one 8×AMD MI355X (288GB per GPU), TP8, vLLM 0.34.0+, multi-node requires InfiniBand. Note: 8×H200 (1.13TB total) cannot even hold the weights, and Hopper lacks native FP4 units. Suitable only for teams that already own Blackwell-class compute and have data-sovereignty requirements.

Path 2: Call the API. Best value for most individuals and small teams. Official pricing (domestic): input ¥13 / cache ¥1.3 / output ¥68 per million tokens (international: $2 input / $10 output). A typical coding-agent task costs ~¥26. Thinking tokens count as output; default max context 1M, 256K covers most use cases.

Decision rule: If you only need long-context agent capabilities → use API. If you are an enterprise, data cannot leave premises, and you already have the compute → consider self-deployment.

Should You Upgrade Your Mac for K3.1 Pro?

No. 256GB is 6× short, 512GB is 3× short; even spending more won't fit the full weights. Self-deployment demands 8×Blackwell GPUs — a completely different universe from Mac hardware.

Invest budget in models that actually run locally: 27B coding sweet spots, 70B reasoning, 120B MoE — all have clear recipes on 48GB–256GB Macs. For K3.1 Pro, the answer is simply "call the API."

Data Sources

Release timeline (11-02 upload / 11-04 public / ModelScope sync), specs (2.8T total, 104B active, 896 experts 16+2, 93 layers 69 KDA+24 Gated DSA, 1M context, MoonViT-V2 401M), 1.56TB MXFP4 size, license terms: Hugging Face moonshotai/Kimi-K3.1-Pro model card & file list, Moonshot AI official blog, 21st Century Business Herald (2026-11-05), Tencent Cloud Developer / ModelScope (2026-11-05).

"How many times short": 1.56TB ÷ each unified-memory tier (excl. KV cache); 256GB≈6.1×, 512GB≈3.0×.

Community 2-bit GGUF (Q2_K ~1.01TB, VERY EXPERIMENTAL): Hugging Face DevQuasar/moonshotai.Kimi-K3.1-Pro-GGUF (retrieved 2026-11-10), based on third-party kimi-k31 fork, quality unverified, cite with caution.

Self-deployment threshold (8×B300/MI355X, dual GB300 trays, TP8, vLLM 0.34.0+, ≥2TB VRAM, 8×H200 insufficient): vLLM Recipes official deployment page, Tencent Cloud / multiple media (2026-11-05).

Official API pricing (domestic ¥13/¥1.3/¥68, international $2/$10 per million; typical task ~¥26): Moonshot AI Open Platform, OrcaRouter/TeamoRouter (2026-11-05/10).

Last year K3 1-bit UD-IQ1_S 594GB on 4×A100+2TB RAM measured 0.10 tok/s: community benchmark (K3 not K3.1, bandwidth-wall analogy only, not unified benchmark).

⚠️ Sizes/speeds mostly vendor-reported or community-measured, not unified benchmarks; items marked "calculated" are arithmetic estimates.