Last updated: July 2026
Key Takeaways
- Unsloth released dynamic GGUF quantizations of Kimi K3 on July 29, 2026. The 1-bit build is listed between 594GB and 620GB across same-day revisions, with a 650GB-plus floor of combined RAM and VRAM, and it loads through a dedicated llama.cpp branch or Unsloth Studio.
- The floor still sits above every single consumer machine, a maxed-out 512GB Mac Studio included. Our July call that a 2-bit-class build would land north of 700GB held: the guide's fuller revision lists its 2-bit builds at 711GB and 861GB.
- The narrowest real path is a two-machine cluster, such as a 512GB Mac Studio linked to a 128GB node. Everyone else should run what fits: our VRAM-tier guide maps the best model at every memory level.
Still no for almost everyone, but the answer finally has measurements attached. Unsloth published calibrated GGUF quantizations of Kimi K3 on July 29, 2026. The smallest 1-bit build is listed between 594GB and 620GB, with Unsloth citing a 650GB-plus working floor of combined RAM and VRAM. That is a two-machine number, not a desktop number.
This page has tracked one question through three phases: the July 16 launch, when every figure was an estimate; July 27, when Moonshot published the weights and the estimates became checkable; and July 29, when real sub-4-bit quantizations began landing and could be measured instead of projected. Here is what changed, what held, and who can actually press enter.
What Moonshot Actually Released
The release is complete. The official Hugging Face repository carries safetensors shards, a model card, a LICENSE file, and the full architecture table, with the technical report published to GitHub the same day. For serving, the model card names three engines: vLLM, SGLang, and TokenSpeed. It does not name llama.cpp, Ollama, or LM Studio, and that omission is exactly what this week's news is about, because a third party has now partially closed the gap.
| Specification | Kimi K2.6 | Kimi K3 |
|---|---|---|
| Total parameters | 1 trillion | 2.8 trillion |
| Activated per token | 32 billion | 104 billion |
| Expert routing | 8 of 384, plus 1 shared | 16 of 896, plus 2 shared |
| Attention layers | MLA | 93 layers: 69 KDA plus 24 Gated MLA |
| Context window | 256K tokens | 1,048,576 tokens |
| Vision encoder | None | MoonViT-V2, 401 million parameters |
| License | Modified MIT | Kimi K3 License (bespoke) |
K3 figures from Moonshot's official model card, July 27, 2026.
How K3 stacks up against the closed flagships is its own argument with its own messy details; our breakdown of the Kimi K3 benchmark claims covers which leads are real and which sit inside the margin of error.
Fix it, don't live with it
WiFi acting up? The right gear fixes it.
Tested refurbished gear. 90-day warranty, free returns.
What's your WiFi problem?
The 594GB Number Finally Means Something
When the weights dropped, a 594GB download figure was circulating everywhere, and this article declined to repeat it: it did not reconcile with 2.8 trillion parameters at 4-bit precision, and we could not verify it against the repository. That skepticism turns out to have been right about what the number was not. It was never the size of the model. It is the size of a 1-bit quantization, and as of July 29 that build is real, published by Unsloth alongside the rest of a quantization ladder.
Sub-4-bit was supposed to be off the table, and for uniform quantization it still is: K3 was trained quantization-aware and ships natively at 4-bit, so the compression that normally shrinks an open model after release was spent before it. Unsloth's route around that is dynamic quantization. Most weights drop to 1 or 2 bits while the layers that matter most are upcast to 8-bit, and the result is calibrated against a lossless 8-bit reference build. That calibration is the difference between these files and the earlier community GGUFs we warned against, which were converted blind because nothing could run the model to calibrate. Unsloth could, through a dedicated llama.cpp branch, and shipped the ladder below.
| Build | Download size | RAM + VRAM to run it |
|---|---|---|
| Dynamic 1-bit (UD-IQ1_S) | 594GB to 620GB across same-day revisions | 650GB and up, per Unsloth |
| Dynamic 2-bit (UD-Q2 family) | 711GB and 861GB in the fuller revision | Roughly 730GB to 880GB |
| 4-bit (UD-Q4_K_XL) | 1,510GB | About 1.55TB, near full precision |
| 8-bit (UD-Q8_K_XL) | 1,560GB | About 1.6TB, lossless against the release build |
All figures are Unsloth-reported. As we published on July 29, 2026, Unsloth's guide still carried a warning that quants were uploading and the page was a work in progress, with even smaller 1-bit builds promised; the 1-bit size moved between revisions during the day. Treat exact figures as provisional until the page settles and independent runs land.
On quality, Unsloth's calibration data, published in one revision of the guide, reports the 1-bit agreeing with the full model on roughly 79 percent of token choices, rising to about 90 percent for the larger 2-bit build. Read that as the quantizer grading its own work: plausible, consistent with its track record on the K2 family, and not yet checked by anyone independent. Whether four out of five token choices is enough to preserve K3's headline coding and agentic behavior is exactly the open question, and a model this size will not get casual third-party evaluation quickly.
Grading our own July math: we wrote that a 2-bit-class build would still land north of 700GB, and both listed 2-bit builds did, at 711GB and 861GB. What we did not predict was a calibrated 1-bit landing roughly 60 percent below the release build while keeping most token choices intact, by the quantizer's own measure. The verdict on this page's question barely moves even so. The floor dropped from 1.4TB to roughly 620GB, and roughly 620GB is still not a computer you own.
Who Can Actually Run the 1-Bit Build
Three hardware paths clear that floor today, and none of them is a normal computer. Unsloth's rule of thumb: combined RAM plus VRAM should roughly match the quant size. Below that, llama.cpp will still run by streaming weights from storage, at speeds that make it a demonstration rather than a tool.
A two-machine Apple cluster. A 512GB Mac Studio alone still does not reach the floor; that July conclusion stands. Unsloth's documented path pairs it with a second 128GB machine over llama.cpp's network mode for 640GB of pooled memory, which squeezes under the 650GB guidance only with some offloading, or with the smaller 1-bit builds Unsloth says are coming. It is the least expensive route on this list, it is two computers and a network hop, and no consumer speed figures have been published for it.
A used server with 768GB or more of RAM. Retired EPYC and Xeon platforms take enough memory to hold the 1-bit build for CPU-only inference. It will load, and it will answer; on a mixture-of-experts model this size, expect it to test your patience rather than replace an API. Where server-class economics start to make sense is covered in our local AI hardware guide.
Datacenter accelerators. Unsloth's quoted throughput, more than 100 tokens per second, comes from NVIDIA B200-class GPUs. That figure does not transfer to anything in a house, and no consumer benchmark for these quants existed as of this update. We will add real numbers when they exist rather than invent them now.
One consumer detail before you provision anything: this download is roughly half of a typical 1.2TB monthly data cap. If your ISP meters you, check where you stand first.
How to Try It, If You Clear the Bar
Two supported routes exist as of July 29, and both come from Unsloth rather than from Moonshot or the mainline projects. The quickest is Unsloth Studio, an open-source local UI that handles downloads, RAM offload, and multi-GPU detection:
curl -fsSL https://unsloth.ai/install.sh | sh
unsloth studio
Then search for Kimi-K3 in the model hub and pick a quant your memory can hold. The second route is llama.cpp, where K3 support currently lives in a dedicated pull request rather than any stable release, which is also why Ollama and LM Studio cannot load these files yet. Manual downloads come from the Kimi-K3-GGUF repository:
hf download unsloth/Kimi-K3-GGUF \
--local-dir unsloth/Kimi-K3-GGUF \
--include "*UD-IQ1_S*"
Treat Unsloth's Kimi K3 guide as canonical for the exact branch, build flags, and sampling parameters; it was being actively edited as we published and will outrun this snapshot.
The Ollama Listing Is Still a Cloud Service
The Kimi K3 page in Ollama's library continues to look like local support arrived. It has not. The tag carries a cloud suffix, requests route to Ollama's servers, and the listing requires a paid tier that consumes usage credits. That is a hosted API wearing a familiar command: a legitimate way to try the model, and not local inference, since your prompts leave your machine exactly as they would through any other provider. Genuine local support in Ollama and LM Studio waits on the llama.cpp work above reaching a stable release.
The License Is Not MIT, and It Is Not Apache
Now that running K3 yourself is physically possible, its license matters to more people. It is a bespoke Kimi K3 License, not Apache 2.0 as one widely shared deployment guide claims, and not the Modified MIT of the K2 line. Per reporting on the license text, corroborated by open-model researcher Nathan Lambert's public reading, it runs MIT-like until two gates. Model-as-a-service businesses need a separate agreement with Moonshot once revenue across you and your affiliates passes 20 million US dollars over any consecutive twelve months. And a commercial product above 100 million monthly active users, or 20 million US dollars in monthly revenue, must display "Kimi K3" prominently in its interface. Neither gate touches internal use or a homelab. Read the LICENSE file before building anything commercial on it, and have counsel confirm your specific case.
One more monthly fee to kill
Renting your modem? That's $120+ a year.
Own it instead. It pays for itself in months. 90-day warranty, free returns.
Pick your provider:
Why Open Weights Matter More This Week
"You cannot run it" was never the same as "this does not concern you," and this week sharpened every structural reason. Price: released weights can be served by any host with the hardware, and third-party rates already undercut first-party pricing. Permanence: published weights cannot be recalled, and the option to run K3 yourself stopped being theoretical on July 29; it is now merely expensive. Jurisdiction: with weights and a working quant, an organization chooses where inference happens, down to its own rack. If you use the hosted product instead, our companion piece on what Kimi's privacy policy actually says is the more urgent read. And the quiet payoff stands: the checkpoint almost nobody can run becomes a teacher for models that fit in 16GB, a pipeline that has delivered every year so far. Until it does, run what fits. Our guide to the best local AI models by VRAM tier maps what is genuinely good at every memory level today.
Frequently Asked Questions
Can you run Kimi K3 locally now?
Technically yes, practically no for consumer hardware. Unsloth's 1-bit dynamic GGUF needs a 650GB-plus floor of combined RAM and VRAM by its own guidance, which no single consumer machine reaches. The working paths are a two-machine cluster such as a 512GB Mac Studio plus a 128GB node, a server holding 768GB or more of RAM, or datacenter accelerators.
How big is the Kimi K3 download?
Between roughly 594GB and 620GB for the smallest 1-bit build, figures Unsloth's guide listed in same-day revisions, rising to 1,560GB for the lossless 8-bit version, against about 1.57TB at full precision. The 594GB number that circulated at launch turned out to describe a 1-bit quant, not the model. On a typical 1.2TB monthly data cap, this download alone is about half your month.
Will quantization make Kimi K3 fit on my machine?
Not on a normal one. K3 ships natively at 4-bit, so calibrated dynamic quantization is the only route below that, and its current floor is a roughly 600GB 1-bit build that keeps about 79 percent of token choices, per Unsloth's own measurements. Nothing announced brings K3 near a 24GB GPU or a 128GB workstation; run a model sized for your memory instead.
Can a 512GB Mac Studio run Kimi K3?
Not by itself: 512GB sits under the 1-bit build's memory floor. Unsloth's documented workaround links the Studio to a second 128GB device through llama.cpp's network mode, pooling 640GB, with offloading covering the remainder. That makes it the least expensive route to K3 at home, and still a two-computer cluster with no published speed figures yet.
What license does Kimi K3 use?
A bespoke Kimi K3 License, not Apache 2.0 and not the K2 family's Modified MIT. It reads MIT-like, then requires a separate Moonshot agreement for model-as-a-service businesses above 20 million US dollars in twelve-month revenue, and prominent Kimi K3 attribution for products above 100 million monthly active users or 20 million US dollars in monthly revenue. Internal use carries no obligation.
What can I run at home instead?
Plenty, and it is genuinely good now. Open models in the 8GB to 128GB range handle coding, summarization, document work, and light agent tasks well, and a dedicated always-on box is affordable. Our mini PC guide for local AI covers the hardware tiers plus how to keep an AI box properly isolated on your home network.

