Yes, in a narrow and still unverified sense. A new open-source engine appears designed to execute Kimi K3’s complete 93-layer language stack while keeping almost all of the weights on storage. Its author reports 8.24GB peak process memory and 32.69 seconds per generated token.
That result does not show Kimi K3 running as a practical chatbot on an 8GB laptop. The measurement came from an 8G Linux cgroup on a dual-socket AMD EPYC server with 228GiB of physical memory, 124 exposed CPU cores and fast local storage. The project itself refuses its smallest preset when less than 10GB is available. It also requires the official 1.56TB checkpoint plus a roughly 109GB packed copy of the model’s dense trunk.
Testing disclosure, checked August 2, 2026: Kingy.ai inspected kimi-k3-in-c at commit 85ab2cd, its C source, benchmark scripts, committed measurement files and captured host environment. We independently checked the official Kimi K3 model card, configuration and Hugging Face file inventory. We did not download the 1.56TB checkpoint or reproduce a full-model run. All speed, memory, output and parity results attributed to the project remain author-reported.
The claim audit in one table
| Question | Evidence-based answer |
|---|---|
| Does the engine target the full Kimi K3 language stack? | Yes. The source binds all 93 text-model layers and streams routed experts from the official checkpoint. Full-checkpoint correctness and output claims have not been independently reproduced. |
| Was it demonstrated on a physical 8GB computer? | No. The project imposed an 8G cgroup on a 228GiB server. It reports 8.24GB peak RSS for the process and asks for at least 10GB of available host memory. |
| Does the full checkpoint fit in RAM? | No. About 1.45TB of routed-expert weights remain on storage. Only the selected experts and a bounded slice of the dense trunk are held in memory at a time. |
| Is the 1.7TB storage requirement real? | Yes. The 96 official weight shards total 1,560,936,091,448 bytes, and the project creates an additional 108.81GB packed trunk. The combined payload is about 1.670TB before normal filesystem headroom. |
| Is 32.69 seconds per token a verified decode speed? | No. It is one author-reported eight-token average that includes first-step prompt work and cold-start effects. It is not a separately measured steady-state decode rate. |
| Is this a usable Kimi chatbot? | No. The current engine has no chat template, sampling, vision path or serving API. It performs greedy base-model continuations. |
| Does it run on Apple Silicon? | Not this implementation. The engine targets x86-64 Linux with AVX2/FMA and Linux-specific I/O and memory controls. |
How a 1.56TB model can execute in 8.24GB
Moonshot AI’s official model card describes Kimi K3 as a 2.8-trillion-parameter mixture-of-experts model with about 104 billion parameters activated for a token. It has 896 routed experts and selects 16 of them in each routed layer.
The active-parameter count is a compute fact, not a storage total. Different tokens can select different experts, so the entire expert pool must remain reachable. Conventional serving keeps those weights in accelerator memory across a large cluster. The C engine tries a different systems trade: leave the expert pool on storage, read only the selected experts for the current token, multiply them directly from Kimi’s packed MXFP4 representation, then reuse or evict them through a bounded cache.
The project divides the checkpoint into three practical pieces:
- Routed experts: roughly 1.45TB on disk. The author reports reading about 25.83GB of expert data per token in the lowest-memory configuration.
- Dense trunk: 108.81GB of higher-precision weights repacked into a separate file. More RAM can pin more layers; the 8G test streams the trunk layer by layer.
- Always-resident data and working state: embeddings, the output head, caches, activations, indices and runtime buffers share the small memory budget.
This is full-model execution by storage streaming. It is not model compression in the usual sense. The weights have not been pruned down to an 8GB checkpoint, and the sleeping experts have not disappeared. The SSD substitutes capacity, not bandwidth.
The 1.7TB catch is an extra copy, not a rounding error
Kingy.ai queried the official Hugging Face model API at revision 9f62e4e and summed the 96 .safetensors shard sizes. They total 1,560,936,091,448 bytes: 1.561TB in decimal units or about 1.420TiB.
The engine still needs those original shards because routed experts are read from them during inference. Its setup then creates a separate packed trunk of about 108.81GB so the 93 dense-layer segments can be fetched efficiently. Together, those two payloads consume about 1,669,746,091,448 bytes. Configuration files, tokenizer data, build artifacts and filesystem reserve add a little more.
A nominal 2TB SSD may clear the project’s minimum when nearly empty, but it leaves little operating margin. The setup is also storage-performance sensitive. The author’s campaign used a 3.2TB local device measured at 3.2GB/s with direct I/O, and the engine reported higher sustained trunk-read rates during runs. A network volume, a nearly full system drive or a consumer external SSD should not be assumed to match that behavior.
“8GB RAM” describes a process ceiling, not the test machine
The project’s memory-ladder harness uses Linux systemd-run to impose hard cgroup limits and disables swap. That is a sensible way to test whether the process stays below a budget. It does not recreate the rest of an 8GB PC.
The captured environment identifies two AMD EPYC 7763 sockets, 124 CPU cores, 228GiB of RAM and four idle Nvidia L40 GPUs. The GPUs did not perform inference, so CPU-only is accurate. “One CPU” and “an ordinary 8GB laptop” are not.
There is another practical clue in the project’s own hardware doctor. It chooses the laptop preset only when the Linux kernel reports at least 10GB available and calls anything below that its floor. Peak RSS measures the engine process; the operating system, filesystem, shell and background services still need memory.
Loading, prompt processing and decode are different clocks
The headline 32.69 seconds per token does not cover the entire ownership experience. Downloading 1.56TB, packing the 108.81GB trunk, indexing shards and some initial loading work sit outside the generation average.
Inside a generation run, the first step is also different from later steps. It processes the prompt, initializes carried state and can pay the first-touch cost of pinning trunk layers. Later incremental steps process one newly generated token at a time.
The project’s roughly 128GB example makes the distinction visible. With the five-token prompt “Hello! My name is,” the author reports 53.04 seconds for step zero and about 8.7 to 8.9 seconds for subsequent steps. Averaged across 24 generated tokens, the run lands at 10.66 seconds per token.
The 8.24GB headline is an eight-token average, not a clean steady-decode measurement. At that reported average, 100 output tokens would take about 54.5 minutes if the rate held. At 10.69 seconds per token, the same arithmetic is about 17.8 minutes. Those are illustrations, not fresh benchmarks; prompt length, cold-start amortization, storage behavior and expert routing can move the result.
The “128GB configuration” does not have one speed
One 28-token server-preset run reports 127.92GB peak RSS and 10.69 seconds per token. It is tempting to treat that as the 128GB result. The repository’s other measurements make that too neat.
The published memory ladder lists 29.40 seconds per token at a nominal 128GB budget. A separate allocation sweep reports 16.80 seconds per token when most of the same budget is assigned to the trunk. The longer 10.69-second run amortizes its first step across more output tokens. These samples also came from a campaign in which three identical runs ranged from 14.67 to 20.14 seconds per token, a 33.1% spread.
The author deserves credit for publishing that noise result and for warning readers not to overinterpret single samples. The project’s roadmap says the broader campaign still needs to be repeated under its newer three-run harness. For now, “roughly 10.7 seconds per token in one longer 128GB-class run” is defensible. “Kimi K3 runs at 10.69 seconds per token in 128GB” is too strong.
Full-model execution is only one layer of the Kimi product
The engine’s current scope is narrower than Moonshot’s official Kimi K3 experience. According to the project’s own limitations, it has:
- no XTML chat template, so it produces base-model continuations rather than normal assistant replies;
- greedy decoding only, with no temperature, top-p or top-k sampling;
- no vision encoder, despite Kimi K3’s native multimodal architecture;
- no HTTP or OpenAI-compatible serving API;
- no chunked prefill and a current 32,768-token engine ceiling, far below the official 1,048,576-token configuration;
- no quality benchmark, task evaluation or broad comparison with an established Kimi runtime.
The author’s “capital of France” demonstration begins with the expected Paris continuation, then drifts into a fragment that resembles structured text. That is useful evidence that the engine can emit plausible tokens. It is not a chat evaluation, a coding-agent test or evidence that the full Kimi product behavior survives this runtime.
What Kingy.ai independently found
Four parts of the story survive without trusting the stopwatch:
- The storage premise is real. The official checkpoint contains 96 shards totaling 1.561TB, verified through the current Hugging Face API.
- The sparse architecture supports the mechanism. Official Kimi materials specify 896 routed experts with 16 selected per token. Streaming the selected weights is technically coherent.
- The repository implements a genuine storage-backed path. Source inspection shows shard indexing, direct expert reads, a bounded expert cache and a packed trunk that can be pinned or streamed by layer.
- The evidence boundary is clear. Public CI validates kernels, I/O and a small 13-layer oracle without the official checkpoint. Full 93-layer parity, RAM and speed evidence comes from committed author logs, not an independent CI job or outside reproduction.
The repository is also extremely new. It was created on August 1, and version 0.1.0 was published on August 2. At the time of this audit, there were no public user issues or independent full-checkpoint results in the repository. Its download helper follows the moving model repository rather than pinning a revision and checks shard sizes rather than cryptographic hashes. Anyone attempting a reproduction should pin both code and checkpoint revisions and verify the files independently.
Who should care about this result?
Systems researchers: yes. This is an unusually concrete exploration of how far sparse routing, direct storage reads and strict memory budgeting can push a giant checkpoint.
Owners of an existing x86 Linux server with very fast storage: perhaps. The setup is a demanding experiment with a 1.7TB entry fee, long waits and a young codebase.
People hoping to turn an 8GB laptop into a Kimi workstation: no. The project has not demonstrated that physical configuration, and its own doctor asks for more available memory.
Interactive chat, coding or team service: no. At the published speeds and current feature scope, the engine is an execution proof rather than a useful assistant.
Apple Silicon users: this project is not the relevant implementation. Kingy’s separate 64GB M1 Max audit covers Deltafin, a different runtime with different quantization, speculative decoding and author-reported performance. The earlier 128GB Mac Studio analysis explains why a compressed checkpoint still does not become a normal in-memory desktop model.
FAQ
Can Kimi K3 really run in 8GB RAM?
The project author reports 8.24GB peak RSS while executing the full 93-layer language stack under an 8G cgroup. That demonstrates a process-level memory result on the author’s server, not a successful run on a physical 8GB computer. Kingy.ai has not reproduced it.
Why does it still need 1.7TB of SSD space?
The engine does not shrink the official 1.56TB checkpoint to 8GB. It leaves the routed experts in the original shards and creates an additional 108.81GB packed trunk for efficient streaming. RAM holds a working window; storage holds the model.
Is 32.69 seconds per token the chatbot response speed?
No. It is one eight-token author average that includes the first prompt-processing step. The engine currently produces greedy base-model continuations and has no chat template or server.
Does more RAM solve the speed problem?
It helps because more of the dense trunk can remain resident, but the reported data is noisy and configuration-sensitive. One longer 127.92GB run averaged 10.69 seconds per token; other roughly 128GB samples were slower.
Can it run on a Mac or Windows PC?
Not as published. The full streaming path targets x86-64 Linux, AVX2/FMA, OpenMP, O_DIRECT, /proc and Linux cgroups. The repository does not provide an Apple Silicon, macOS or Windows runtime.
Methodology and primary sources
Kingy.ai reviewed the following sources through August 2, 2026:
- kimi-k3-in-c at audited commit 85ab2cd: implementation, setup, scope and author-reported headline results.
- Project performance report and raw-data links: memory ladder, cache behavior, timing caveats and 33.1% noise result.
- Official Moonshot AI model card and configuration: architecture, active experts, layer count and official context configuration.
- Official Kimi K3 technical report: precise parameter count, attention design and native expert quantization.
- Official checkpoint file tree and model API: live shard inventory and byte sizes.
The narrow conclusion is plausible and important: Kimi K3’s full language stack can, according to the project author, generate from a resident set of 8.24GB by moving the capacity burden to storage. The same evidence also shows why this does not overturn the practical hardware math. The model still occupies about 1.7TB, the benchmark ran on a large server, each token can take tens of seconds, and the current engine is not a chatbot.