Kimi K3, the flagship model developed by Beijing startup Moonshot AI, went live in July. It is the largest open-weight model to date, with 2.8 trillion parameters and the ability to process one million tokens in a single query (enough to hold an entire medium-sized code repository).

The model has won industry plaudits for its capabilities. Independent trackers Frontend Code Arena and Artificial Analysis rank it among the likes of Claude Fable and GPT-5.6 Sol Max, with the model debuting at first and third on their respective leaderboards.

As an open-weight model, K3 is available for anyone to download and run within their own network. Previously, its prohibitively large 1.56 terabyte size meant few could actually do this in practice, with even the most heavily compressed 883 GB version still far beyond the capabilities of home computers.

However, this has all changed in recent weeks. Decentralized AI cloud computing firm Pipe Network published an open-source port at the end of July that allows Kimi K3 to run on certain Apple silicon desktops.

Pipe’s Kimi K3 port reduces its memory footprint by over 75%

Pipe Network engineers were able to trim the memory required to run a version of the model from 883 GB down to 350 GB, bringing it within the capabilities of a max-spec Mac Studio, which tops out at 512 GB of unified memory.

They did this through a system of pruning that streamlines the model’s workflow. K3 uses a Mixture-of-Experts (MoE) machine learning architecture that delegates queries across a panel of “experts,” essentially sub-networks designed for specific tasks. K3 contains 93 layers, 92 of which contain 896 routed experts. For each token, the model selects just 16 of those experts to perform the computation. Up to 98% of these are therefore idle for any given token.

However, a normal deployment still needs the full set of expert weights available in memory because different tokens can route to different experts - a highly memory-intensive process far beyond the capabilities of consumer hardware. Pipe’s approach reduces this requirement by pruning hundreds of low-impact experts from the model beforehand, producing a much smaller version that can fit entirely within a Mac Studio’s unified memory.

This slashes the memory footprint for host machines considerably, meaning that the entire thing can run inside a single Mac.

The REAP system trims both memory requirements and model capabilities

To decide which experts to keep and which to discard for any particular task, the converter uses a technique known as REAP (Router-weighted Expert Activation Pruning), developed by AI computing company Cerebras. By running sample text through the model, this system can detect which experts have the most consistent impact on output. Those that are rarely activated for specific query types, or seldom make meaningful changes, are cut from the lineup.

It is important to note that the end result is not entirely the same as running the full version of Kimi K3. The sample text fed into the adapted model changes the capabilities of the end product, as this determines which experts are pruned and which are kept active.

For example, a build calibrated on purely English sample text will have a heavily degraded ability to return results in Chinese, and vice versa. Pipe Network’s converter therefore narrows the capabilities of the model, which becomes specialized for the domains represented in the calibration data. The parent model still boasts greater breadth, in exchange for a much larger memory footprint.

Another caveat is the speed of the adapted model’s output. Since each token of input still needs to be processed and delegated to an expert, processing power is still a major limiting factor. Pipe Network’s adaptations managed to prune the model down so it can feasibly run on a Mac, but each token of output still requires reading approximately 87 GB out of memory. Running at an average of 5.5 tokens per second, the pruned K3 can process one sentence in roughly six seconds - far slower than most cloud-based models that average over a hundred tokens per second.

Greater or lesser degrees of pruning have little effect on this, as it’s a hardware constraint that cannot be circumvented with clever software engineering. Advancements in memory bandwidth for consumer machines are needed for that gap to close.