Moonshot AI put the weights for Kimi K3 online on July 27, making the largest open model ever released free for anyone to download. It is a 2.8 trillion parameter system from a Beijing startup founded in 2023, it reads images as well as text, and it accepts a million tokens in a single query, enough to hold an entire codebase at once.
What made the industry pay attention was where it landed on the leaderboards. Independent trackers place K3 near the very top of the field, behind only Claude Fable and GPT-5.6 Sol Max on Artificial Analysis's intelligence index and first on Frontend Code Arena, at a fraction of the cost to run. Open weights means anyone can download it, inspect it, adapt it and keep it inside their own network, which none of the leading closed models permit at any price. That is the part that unsettled a lot of people last week, and it is why the release has been read as a competitive move against OpenAI and Anthropic rather than just a research milestone.
There is a catch that gets less attention. Downloadable is not the same as runnable. The files come to 1.56 terabytes, which in practice means a multi node rack of datacenter GPUs. For anyone without that, open weights has mostly been a technicality.
Pipe Network has published an open source port that narrows the gap, getting a working version of K3 onto a single Apple Silicon desktop.
The obstacle was always memory. Even in its most compressed form, K3 needs roughly 870GB. The largest Mac that exists, the M3 Ultra Mac Studio, tops out at 512GB of unified memory. That is not a near miss.
Two pieces of engineering close it.
Streaming the conversion
Before a model can run on a Mac at all, its files have to be rewritten into the format Apple's machine learning software reads. The standard tools do that by loading the whole model into memory, changing it, then saving it back out. That works for the small models people run at home. It cannot work here, because K3 in its raw form is 5.6TB and no machine on sale has anywhere near that much memory.
A model is not one solid block. It is a stack of sections, and K3 has 93 of them, each doing a piece of the work before handing off to the next. The port's converter takes advantage of that. It loads one section, translates it, writes it to disk, throws it away, then moves to the next. At no point does the whole thing need to exist at once, so the machine doing the work never needs more than a few tens of gigabytes of memory rather than thousands. It is plumbing rather than anything glamorous, but nothing else in the project happens without it.
Pruning experts you don't use
Most of K3 is not doing anything at any given moment, and that is by design. Rather than one enormous general purpose network, it is built as a panel of narrow specialists. Each of its 93 sections holds 896 of them, and a router picks the 16 best suited to the word being processed. The rest sit out. Add it up and roughly 98% of the model's bulk on disk is specialists that are idle at any instant, all of them still taking up space.
These specialists are called experts, and REAP, a technique from Cerebras, is a way of deciding which ones to keep. It runs a sample of the kind of text you actually care about through the model, watches which experts do the heavy lifting, and discards the ones that never earn their space. Applied to K3, that takes 1.56TB down to 350GB, which fits inside a Mac Studio with room to spare.
The corpus is the product
The most interesting result in the repo is that the sample text you calibrate on determines what the finished model can do.
The team measured which experts different kinds of content rely on. European languages cluster together. Code clusters together. Chinese and code barely overlap at all, less than you would expect from random chance.
The consequences show up in the output. A build calibrated on English and code loses Chinese completely and starts repeating itself. A build calibrated only on Chinese writes clean Chinese and then fails to produce working code. A build calibrated on both holds both. You are not just compressing a model, you are choosing which of its capabilities survive.
The team is careful to note this rests on a small number of test prompts rather than a formal evaluation, and that an earlier version of the same experiment produced a conclusion they later found to be wrong.
The honest caveat
Training is what teaches a model. Inference is what happens every time you use one, the work of turning your prompt into an answer, one word at a time. Each of those words requires the machine to sweep through a large portion of the model's weights, which is why inference speed is mostly a question of how fast a computer can move data around rather than how clever it is.
Speed here is 0.14 to 0.20 tokens per second. A single sentence takes minutes. Every word generated requires reading about 87GB out of memory, so this is a hardware ceiling rather than a software bug, and pruning more aggressively does not fix it. A build 100GB smaller ran barely faster.
That is the real lesson of the project. Fitting the model onto the machine was solvable with software. Making it usable was not, and it demonstrates fairly precisely how much hardware a model this size still demands before "local" becomes a meaningful description. This is a batch tool for jobs you set running and come back to, not a chatbot. Memory bandwidth on consumer machines keeps climbing, though, and the software groundwork is now done and public for whenever it catches up.
Two things do work cleanly. The vision component was tested against Moonshot's own code and matches to within rounding error, so images work end to end. And the surviving experts are bit for bit identical to the originals, because the source format and Apple's format happen to encode numbers the same way. The only information lost is the pruning itself.
The repo is also unusually direct about what has not been tested. The full unpruned versions have never generated a single token, because no computer exists that can hold them.