TL;DR: Kimi K3 is Moonshot AI’s 2.8-trillion-parameter open-weight MoE — the largest open model released to date, and it lands near the top of the closed frontier on agentic benchmarks. But even its native 4-bit weights are roughly 1.4TB, so no single consumer GPU comes close. Until the weights drop on July 27, the only sane paths are the API, a rented multi-GPU pod, or a big-memory Mac cluster running a lossy quant.

	Kimi K3 API	RunPod multi-GPU	Big-memory local build
Best for	99% of home labs	Bursty heavy use, tuning	Data-can’t-leave, always-on
Cost	$0.30 cached / $3 in / $15 out per M tok	~$2.89/hr per H100, 8×+ needed	~$40k (4× Mac Studio) and up
Speed	Managed, fast	Usable	Slow, degraded quant
Memory needed	None	~1.4TB VRAM (rented)	700GB–1.7TB unified/RAM
The catch	Prompts leave your machine	Billed by the hour	Expensive, lossy, and the weights aren’t out yet

Honest take: For nearly every reader, K3 is an API model — not a card you buy. If you want local trillion-class inference today, the model that actually fits real hardware is Kimi K2.7 Code, whose 2-bit build is a confirmed 325GB. Wait for K3’s technical report and community GGUFs on July 27 before you spend a dollar on hardware.

What Kimi K3 actually is

Moonshot AI released Kimi K3 on July 16, 2026, calling it the largest open-source model in the world. The headline number is 2.8 trillion total parameters — nearly triple its predecessor, the ~1T Kimi K2 family — and Moonshot has promised the full open weights by July 27, 2026 under the same permissive terms as the K2 line.

The architecture is where it gets interesting:

• 2.8T total parameters in a sparse Mixture-of-Experts built on Moonshot’s Stable LatentMoE framework
• 16 of 896 experts active per token — an extreme sparsity ratio (under 2% of experts fire on any forward pass)
• Kimi Delta Attention (KDA), a hybrid linear-attention mechanism, plus Attention Residuals (AttnRes) to keep information flowing through a very deep, very long-context stack
• 1M-token context window and native visual understanding (it’s multimodal, not text-only)
• Quantile Balancing routing and a Per-Head Muon optimizer — training-side changes that, per Moonshot, remove the fragile hyperparameters that break most MoE models at this scale

Moonshot hasn’t published the exact active-parameter count yet. The 16-of-896 routing and early coverage put it somewhere in the ~40–60B active range, roughly double K2’s confirmed 32B active — but treat that as unconfirmed until the technical report lands. It matters, because active parameters set your speed while total parameters set your memory bill, and those are two very different problems.

The 2.8T trap: storage is the wall, not compute

This is the single most important thing to understand before you price out hardware. MoE sparsity means only ~40–60B parameters are computed per token — but the router picks a different set of experts on every token, so all 2.8T weights must stay resident in memory. You cannot stream them in from disk fast enough; the whole model has to be loaded.

That’s exactly the wall we hit with the Qwen3-Coder 480B guide and again with Inkling 975B: active-parameter count is your throughput lever, total-parameter count is your capacity requirement. K3 has the friendliest compute profile of any frontier open model relative to its size — but the worst capacity profile, simply because there’s so much of it to hold.

Why the native footprint is already ~1.4TB

Here’s the twist that separates K3 from earlier releases. Moonshot ships K3 with native MXFP4 weights and MXFP8 activations — the model was trained and released in a 4-bit microscaling floating-point format, not FP16 or BF16. Each weight is stored in ~4 bits with per-block scaling factors.

Do the arithmetic: 2.8T parameters × 4 bits ÷ 8 = ~1.4TB of weight data, before you add routing metadata, KV-cache buffers, and the memory a 1M-token context demands. And because MXFP4 is the native format, that 1.4TB is roughly the full-quality footprint. Going smaller means genuinely lossy community quantization below what Moonshot intended — unlike models shipped in FP16, where a 4-bit GGUF is the first compression step, not a further one.

That reframes the whole “can I quantize it down” question. With K3, 4-bit isn’t a discount — it’s the starting line.

The VRAM math (estimates — anchored on real numbers)

We won’t publish invented K3 footprint figures. Until Unsloth and the community post real GGUF sizes on July 27, every K3 number below is an estimate scaled from the confirmed K2 family. What’s not an estimate is the K2 baseline, so start there:

Model (confirmed, Unsloth)	Full precision	Dynamic 2-bit
Kimi K2.6 (~1T)	610GB	350GB
Kimi K2.7 Code (~1T)	605GB	325GB (UD-Q2_K_XL)

Those are the real, measured, on-disk build sizes — the kind of numbers you can actually plan a build around today. Now scale by K3’s ~2.8× parameter count:

K3 build (estimated)	Approx. size	Reality check
Native MXFP4 (~4-bit)	~1.4TB	Full quality; needs a rack
Dynamic 2-bit class	~1TB	Lossy; multi-node only
Aggressive ~1.8-bit	~650–700GB	Very lossy; 512GB Mac still can’t hold it alone

Even the most aggressive sub-2-bit quant — the kind that already costs real accuracy — lands around 650–700GB. That’s more than a single 512GB Mac Studio can hold. The memory rule of thumb from the Unsloth docs is simple: your VRAM + system RAM combined should equal the size of the quant you’re downloading. For K3, that means a terabyte-class memory pool no matter how hard you compress.

The hardware paths (and why none of them is one GPU)

No single consumer GPU runs K3. Not a 24GB RTX 3090, not a 32GB RTX 5090, not even a 96GB RTX PRO 6000. You’d need to combine ~20–30 used 3090s just to reach the memory floor, and at that point the PCIe fabric, power, and NCCL headaches make it a science project, not a home lab. Here are the paths that actually make sense:

1. The API (recommended for almost everyone). Kimi K3 runs on Moonshot’s platform at $0.30 per million cached input tokens, $3 uncached input, and $15 output — flat across the full 1M-token window, with a 90% cache discount that does the heavy lifting for agentic and repo-scale workloads. Zero hardware, zero maintenance. The catch is the obvious one: your prompts leave your machine.

2. A rented multi-GPU pod. For bursty heavy use or fine-tuning, RunPod H100 SXM nodes run roughly $2.89/hr each, and you’d need 8 or more (TP=8 across ~640GB of VRAM, and more for the native MXFP4 build) to hold K3. Moonshot has contributed a vLLM KDA prefill-cache implementation slated to ship with the weights on July 27, so the serving stack should be ready on day one — a meaningful detail, because exotic attention mechanisms often take weeks to land in inference engines.

3. A big-memory Mac cluster. This is the only “buy it and keep it” local path, and it’s the same one we detailed in the Mac Studio RDMA cluster guide. A single 512GB Mac Studio M3 Ultra (~$9,499, 819 GB/s memory bandwidth) can’t hold even a 700GB quant alone. A 4-node cluster — ~$40k for 1.5TB of unified memory over Thunderbolt 5 with RDMA — is the realistic minimum for a usable K3 quant, and even then you’re running a compressed build slower than the API.

4. A CPU-offload big-RAM server. A dual-socket EPYC box with 1–1.5TB of DDR5 can technically hold a K3 quant in system RAM and grind through it on CPU. Expect single-digit tokens per second — fine for offline batch work, painful for anything interactive. The MoE sparsity helps here (only ~40–60B active parameters move per token), but 1M-context prompt processing will still crawl.

Speed: the one number that works in your favor

There’s a silver lining. Because only ~40–60B parameters are active per token, K3’s inference speed behaves like a ~50B dense model on whatever hardware holds it — not a 2.8T monster. On a properly provisioned 8×H100 node you’d expect throughput in the same ballpark as other large MoEs, not 3× slower just because the total is 3× bigger. The trillion-plus total parameters cost you memory and money, not proportional latency. That’s the whole point of the LatentMoE design: buy capacity, pay for it in RAM, but keep the per-token compute cheap.

For context on how this plays out at the 1T tier that you can run at home, see our confirmed-numbers writeups for Kimi K2.7 Code and the original Kimi K2 local inference guide — the same active-vs-total logic, but with GGUFs that actually exist today.

Is it any good? The benchmarks

Yes — and that’s why the hardware story matters at all. On GDPval-AA v2 (real-world tasks across 44 occupations), K3 scored 1,687, placing third overall behind only Claude Fable 5 Max (1,815) and GPT-5.6 Sol Max (1,747.8) — and ahead of Claude Opus 4.8 (1,600). On AA-Briefcase, a long-horizon agentic benchmark, it hit 1,527, second place, beating GPT-5.6 Sol Max (1,495).

An open-weight model landing between the top two closed frontier systems on agentic work is genuinely new. It’s also, as several observers noted, a signal that the era of “cheap Chinese open models” is ending — K3’s API pricing sits much closer to the Western frontier than K2’s did.

Should you wait for the weights?

Almost certainly yes. As of July 16 there was no Hugging Face model card, no license file, and no download for K3 — only the API and a promise of weights “by July 27.” Note the word by: Moonshot gave a deadline, not a date, and trillion-scale releases have slipped before.

Our advice: use the API now, watch for the technical report, and hold off on any hardware purchase until Unsloth publishes real GGUF sizes and the vLLM KDA path is confirmed working. When those land, we’ll update this guide with measured footprints instead of scaled estimates. If you need private, local inference this month, buy for K2.7 Code — a used 3090 pair plus 128GB of system RAM already runs its 2-bit build — not for a K3 quant that doesn’t exist yet.

FAQ

Can I run Kimi K3 on an RTX 5090? No. A single 32GB RTX 5090 can’t hold even 2.5% of K3’s smallest realistic quant. K3 needs a terabyte-class memory pool. The 5090 is a great card for 27B–70B models — see our best LLM for every RTX 50-series GPU guide — but trillion-parameter MoEs are out of its league.

How much VRAM does Kimi K3 actually need? The native MXFP4 weights are ~1.4TB, and even an aggressive sub-2-bit quant is an estimated ~650–700GB. These are scaled from Kimi K2’s confirmed 610GB (full) / 325–350GB (2-bit) builds. Real K3 numbers arrive with the weights on July 27.

Is Kimi K3 better than K2.7 for local use? For local use, K2.7 wins by default — it fits real hardware today (325GB 2-bit build). K3 scores higher on benchmarks but is roughly 2.8× larger and, until July 27, API-only.

What is MXFP4 and why does it matter? MXFP4 is a 4-bit microscaling floating-point format. K3 ships in it natively, meaning 4-bit is full quality — any smaller quant is genuinely lossy, unlike FP16 models where 4-bit is the first compression step.

Can I fine-tune Kimi K3 at home? Not on consumer hardware. Fine-tuning a 2.8T model requires data-center-class memory. Rent a multi-GPU pod on RunPod or wait for a smaller distilled variant, if Moonshot ships one.

Sources

• China’s Moonshot AI releases Kimi K3, the largest open-source model ever — VentureBeat
• Moonshot AI Releases Kimi K3: A 2.8 Trillion Parameter Open MoE Model With Kimi Delta Attention and 1M Context — MarkTechPost
• Kimi K3 Model Overview: 2.8T Parameters, MXFP4 Quantization — Hugging Face blog
• Can You Run Kimi K3 Locally? The 2.8T Hardware Reality — ModemGuides
• Kimi K2.7 Code — How to Run Locally (Unsloth Documentation)
• Kimi K3 API Pricing and Cache-Hit Math — Apidog
• Kimi K3, and what we can still learn from the pelican benchmark — Simon Willison

Recommended Gear

Only relevant if you’re building for the trillion-parameter tier you can run at home (Kimi K2.7), not K3 itself:

• Used RTX 3090 24GB — ~$1,254 avg (July 2026); the value pick for a dual-GPU 48GB local rig
• Mac Studio M3 Ultra — 512GB config ~$9,499, 819 GB/s; one node of a would-be K3 cluster
• Corsair Vengeance 64GB DDR5 — system RAM is the cheapest way to hold big-MoE weights for CPU/offload inference

For open-source self-hosting and license deep-dives, see aifoss.dev; for wiring a local trillion-class model into Cursor or Cline, see aicoderscope.com.

Prices and specs as of July 2026 and move weekly. All Kimi K3 footprint figures are estimates scaled from the confirmed Kimi K2 family; this guide will be updated with measured numbers when the weights ship on July 27, 2026.