MakeBoxExplore tools Kimi K3.
Small RAM.
Big trade-off.
A 2.78-trillion-parameter model, a tiny C runtime, and a striking memory claim. The real story is where the weights live—and how long you wait.
Explore the measurements ↗Keep the weights. Stream the work. Pay with time.
Peak process RSS
Reported original experiment
Independent C project by FareedKhan-dev and contributors. These are different quantities—not a model compressed into 176 KB.
Watch the MakeBox explainer
Running the model
doesn’t mean keeping
every weight in RAM.
The project kimi-k3-in-c implements CPU inference for Kimi K3 in C. Its headline number is a measured process-memory result. It does not mean that an entire trillion-parameter checkpoint occupies eight gigabytes of storage.
Moonshot’s official model card describes K3 as a roughly 2.8T-parameter mixture of experts, with 104B activated parameters and 16 selected routed experts out of 896. The independent runtime reads needed weights from disk and reuses a bounded memory window. Project architecture.
“Full model” here is the project’s claim about preserving the text-model computation and shipped weight representations—not a promise that this C application includes every capability of the hosted Kimi product. The current repository documents text chat, but not images, tools, serving or context compaction in that chat mode. Scope and usage.
This is a November 3 explainer of an existing project. Its version 1.1.0 changelog is dated October 2. It is not a new Moonshot launch or an official Moonshot CPU runtime. Release history.
Follow the bytes.
SCROLL TO EXPLORE · SWIPE ON MOBILE
A huge library
stays on disk.
The weights still have to exist somewhere. The storage requirement survives the smaller RAM footprint.
Keep a working
window in memory.
Pin what fits, stream the rest, then reuse space. Moving bytes becomes part of the cost of each step.
working window
Capacity is one
question. Speed is another.
A successful run proves a path can finish. A useful assistant also needs a response time that fits your task.
Memory.
Time.
Illustrative byte movement—not a live trace or a simulation of the measured timings.
Move the budget.
Read the actual RSS.
The nominal memory budget, measured resident memory and elapsed time are different fields. This explorer uses the author’s recorded values. It does not predict your laptop’s performance.
Source A: raw memory ladder and performance methodology. Source B: August follow-up. MakeBox checked the published records, not the inference run.
The original ladder was measured on a two-socket AMD EPYC machine with 124 vCPU, 228 GiB RAM and fast NVMe, using memory caps. The author reports substantial run-to-run noise. The August follow-up uses a different storage setup, so comparing the reports is not a clean software-only speed test.
The follow-up’s “128+ GB” row reports 179 GB peak RSS. Its nominal 8 GB row reports 8.73 GB. A preset name is not a hardware guarantee. Check measured usage, units and operating-system headroom before deciding a machine fits. Longer prompts and conversation history can also change the memory requirement.
Swipe the table to see all columns.
| Nominal budget | Peak RSS | Seconds / token |
|---|---|---|
| 8 GB | 8.24 GB | 32.69 |
| 32 GB | 31.9 GB | 31.44 |
| 64 GB | 63.71 GB | 28.6 |
| 96 GB | 95.51 GB | 24.4 |
| 128 GB | 128.18 GB | 29.4 |
| 224 GB | 223.82 GB | 19.21 |
One token.
Nearly sixteen minutes.
The repository also records an 8 GB-class Jetson Orin Nano Super experiment: four one-token runs, all 93 text-model layers, zero expert drops. Mean inference time was 949.4358 seconds; maximum process RSS was 2.573 GiB. Read the proof-of-life report.
For one generated token—not an entire answer.
The capital of France isParisRecorded token ID 17374The line above loops for illustration; it is not real-time playback. The experiment used internal NVMe for the trunk and an external rotating HDD for experts. It is a different workload and machine from the EPYC ladder.
MakeBox checked all four small result JSON files: they contain the same generated token, 93 completed layers and zero expert drops. The report also states matching logit hashes; the large logit dumps are not included in the repository. We did not download the weights or reproduce inference.
This matters in both directions. It is stronger evidence than a slogan that merely says “8 GB.” It is also much narrower than evidence of a responsive daily-use chatbot. The result is a proof of completion under a tight memory budget.
The storage bill
doesn’t disappear.
The project’s setup estimate is roughly 1.56 TB for the checkpoint plus 109 GB for the packed trunk, or about 1.7 TB of free space in its planning guidance. The reported 176 KB binary is executable code, not the model weights. Repository requirements.
The phrase “no GPU” tells you which processor performs inference. It does not remove the need for storage bandwidth, CPU time or preparation. If a workflow needs instant replies, a slow proof of life is not a substitute for a latency budget. If the goal is learning how inference works, the same project may be valuable without ever downloading the giant checkpoint.
Keep the proof
as narrow as the test.
| Viral claim | What the record supports |
|---|---|
| “A 2.78T model in 8 GB” | A low-RSS execution path with large weight storage and reported timing costs. |
| “The entire engine is 176 KB” | A reported compiled binary size, distinct from source code, dependencies and checkpoint. |
| “Same outputs as a supercomputer” | Matching recorded token IDs across tested memory budgets; not universal parity with a hosted service. |
| “Works on Linux, Mac and Windows” | Engine ports are documented; helper scripts have their own platform limits. |
| “Full Kimi capabilities” | The model card and this particular text-chat runtime have different scopes. |
The original ladder records the same eight output token IDs at every budget. That is useful evidence that its memory placement did not change those outputs. It is not a benchmark of broad reasoning quality, long conversations or parity with every model-serving stack.
Precision wording also matters. The project preserves the checkpoint’s shipped representations, including packed MXFP4 expert weights. “No additional precision dropped by this streaming path” is more specific than claiming equivalence to an unquantized model. Architecture and numerical path.
Inspect first.
Build small.
Download deliberately.
The project separates engine tests from a full-model run. Its quickstart recommends building and checking the engine before the weight download. Model access and the checkpoint’s own license are separate from the C project’s Apache-2.0 license. Quickstart · Official model card.
One practical trap: at the inspected commit, k3-doctor.sh explicitly exits on non-Linux systems, even though current engine ports include macOS and Windows. Follow platform-specific instructions rather than treating a viral three-command recipe as universal. Inspect the doctor script.
Show the project’s build-only starting point
git clone https://github.com/FareedKhan-dev/kimi-k3-in-c.git
cd kimi-k3-in-c
make -j
make test
# Linux diagnostic helper; inspect before running:
./scripts/k3-doctor.shReference commands from the project—not commands executed by this article. Check current toolchain/platform notes. The diagnostic helper writes a disk-probe file; it is not just a passive hardware read. Full inference additionally requires the checkpoint, packed trunk and suitable configuration.
A capacity breakthrough
isn’t a speed breakthrough.
Ask where bytes live.
A lower resident-memory number can come from moving work to storage. Read RAM, disk and executable sizes separately.
Ask what was tested.
One prompt, one token and a capped workstation each answer a different question. Keep those boundaries visible.
Match it to the job.
An educational systems experiment and a customer-facing assistant have different response-time requirements.
The interesting engineering idea is making memory placement controllable while preserving a specified computational path. That deserves attention on its own. It does not need an exaggerated promise that every ordinary desktop now behaves like a fast frontier-model service.
For a business, start with the job’s acceptable wait, data requirements and operating budget. For a builder, study the storage and caching design. Both are better starting points than purchasing hardware based on a single RAM number.
Understand the system
behind the headline.
Explore practical AI learning at MakeBox School.
Sources & reading
- Independent runtime repository — FareedKhan-dev and contributors; Apache-2.0.
- Moonshot AI’s Kimi K3 model card — model architecture, capabilities and separate model license.
- Original raw memory ladder · Performance report — reported values and test conditions.
- August speed follow-up — separate setup and measured RSS.
- Jetson proof-of-life report — four one-token runs and linked JSON records.
- Architecture · Changelog — implementation and version scope.
- Quickstart · Doctor script — platform and preparation limits.
Reviewed November 2, 2026. Repository snapshot 81bb6c23ccee. This article reports author-supplied measurements; MakeBox did not execute the runtime or download its checkpoint. Kimi branding comes from the official model card; repository charts are attributed to their authors. The storage illustration is AI-generated. Published November 3, 2026.