Deltafin, a project that appeared on GitHub in late July 2026, demonstrates that the full 2.8-trillion-parameter Kimi K3 can run on a 64 GB MacBook Pro by streaming mixture-of-experts weights from SSDs instead of holding them in GPU memory. The catch: every throughput figure available is self-reported by the author with no independent replication, the two published numbers disagree by roughly 5x, and the best evidenced rate is 0.2901 tokens per second, not the roughly 1 tok/s circulating in discussion. At that speed, SSD-streamed K3 is a batch tool, not an interactive one, and that distinction should drive any hardware budget.
What deltafin actually demonstrated
The factual core of the project is narrow and verifiable. According to the project’s GitHub README, deltafin is a single native binary that runs the full, unpruned Kimi K3: “Nothing pruned. Nothing skipped.” Kimi K3 is a Moonshot mixture-of-experts model designed for infrastructure on the scale of 16 nodes and roughly 4.8 TB of aggregate VRAM, with a 1M-token context window. Deltafin’s claim is that the same model, with MXFP4-quantized expert weights, fits into the memory envelope of a consumer laptop because most of those weights never sit in memory at all.
The memory math is the real result. The Learn AI wiki entry on deltafin describes the working footprint dropping from over 1.5 terabytes to a level manageable on machines with as little as 64 GB of unified memory, provided sufficient SSD capacity holds the rest. That is a genuine architectural statement: the constraint moved from how much VRAM you can buy to how fast your storage can feed the compute units.
The speed result is softer. The same README’s benchmark section reports 0.2901 tokens per second (3.447 seconds per token) on an M1 Max laptop, described as a 1.9% improvement over the previous update. A third-party writeup from ExplainX reports roughly 16 seconds per token, about 0.0625 tok/s, on an M1 Max 64 GB machine. Those numbers cannot both describe the same build and configuration, and nothing in the available coverage reconciles them. Treat both as hypotheses about what favorable conditions look like, not measurements you can plan against. The roughly 1 tok/s figure in some discussions appears in neither source, nor anywhere else in the fetched record.
Why streaming experts changes the bottleneck
The mechanism is worth understanding because it generalizes beyond this one project. Kimi K3’s architecture uses 896 experts with 16-of-896 routing across 92 layers, according to the Learn AI entry. In a dense model, every parameter participates in every token, so the weights must be resident where compute happens. In a sparse MoE, only 16 of 896 experts fire for a given token at a given layer. That sparsity is what makes streaming conceivable: at any moment, the model needs a small, predictable slice of its total parameter count, and the rest can wait on disk.
Deltafin’s weight-loading pipeline, expert routing, and I/O strategy are engineered specifically around that structure. The trade it makes is explicit. A 16-node, 4.8 TB VRAM deployment keeps every expert permanently resident and pays for that residency in hardware. Deltafin keeps a compact resident set in unified memory and pays for each token in storage reads instead. Per generated token, the router pulls 16 experts across 92 layers, totaling 25.8 GB of expert data, plus a resident spine (attention, shared experts, latents, embeddings) of roughly 114 GB that sits on the disk I/O path, per the ExplainX writeup.
That arithmetic explains the observed speed directly. If generating one token requires reading on the order of 25.8 GB of expert weights, then throughput is bounded by sustained SSD bandwidth divided by that per-token read volume. A drive sustaining, say, 7 GB/s would imply a ceiling near a quarter of a token per second on expert reads alone, before accounting for the spine traffic, compute, and overhead. The exact ceiling depends on configuration details the sources do not pin down, so treat that back-of-envelope as inference, not measurement. The direction, though, is not in doubt: in this design, NVMe bandwidth is the binding constraint, and RAM is mostly a cache sizing question.
One more mechanism matters for interpreting the speed claims. Per a Medium explainer on the project, deltafin uses speculative decoding in which smaller models propose candidate tokens, but every token is verified by the original Kimi K3 before being returned; smaller models never generate final output. The draft models in question are the DSpark checkpoint and optional Qwen checkpoints, per the project README. This is how a system bound by expert reads can still post a higher effective token rate: when the draft model guesses runs of tokens correctly, one expensive K3 pass verifies several tokens at once. That also means the reported tok/s figure is sensitive to how speculatable the workload is, which is one plausible contributor to the benchmark gap below.
The benchmark gap, and why you should not average it away
Two speed claims exist on the same hardware class, and they differ by about 5x:
- The project README: 0.2901 tok/s (3.447 s/token) on an M1 Max laptop, the project’s own latest benchmark.
- The ExplainX writeup: ~16 s/token (~0.0625 tok/s) on an M1 Max 64 GB machine.
Neither comes with an independent replication. The discrepancy plausibly reflects different builds, dates, prompt types, or speculative-decoding acceptance rates, but the sources do not say, so any reconciliation is speculation. The honest summary is: at best, expect one token every 3.4 seconds; at worst, one every 16.
There is also a strong reason to distrust the stability of either number. The Learn AI timeline tracks throughput climbing from 0.0141 tok/s on July 27 to 0.2901 tok/s by mid-August 2026, a roughly twentyfold improvement in three weeks through software optimization alone, on unchanged hardware. That trajectory cuts both ways. It suggests the ceiling is not yet found, which is encouraging for the approach. It also means any benchmark cited today, including the ones in this article, may be obsolete within weeks, and today’s bottleneck analysis is more durable than today’s number.
Which workloads tolerate a token every few seconds
The project’s own documentation is unusually candid here. Per the Learn AI entry, it explicitly discourages daily coding agents, production webhooks, and multi-tenant serving, and characterizes suitable applications as overnight batch jobs, email-paced interaction, and systems research. That guidance is consistent with the arithmetic, and it maps cleanly onto a triage:
| Workload | Tolerates 0.06–0.29 tok/s? | Why |
|---|---|---|
| Overnight document summarization, batch translation | Yes | Latency is irrelevant if the queue drains by morning; total token volume is what matters |
| Offline eval harnesses and regression suites | Yes | Throughput-bound, schedulable, and insensitive to per-request delay |
| Code migration or lint passes over a repo | Yes, if batched | Fire-and-forget jobs; check output hours later |
| Email-paced or chat-adjacent personal use | Marginal | A 500-token reply takes 30 minutes to 2.3 hours at the evidenced rates |
| Interactive coding agents | No | Agent loops need dozens of round trips per task; seconds-per-token compounds to hours per edit |
| Production webhooks, request-serving APIs | No | Even one concurrent user multiplies wait times past any reasonable timeout |
| Multi-tenant serving | No | The project itself rules this out, and the bandwidth math cannot support concurrent streams |
The practical consequence is counterintuitive: deltafin ships an OpenAI-compatible API server (per the ExplainX writeup), which makes it look like a serving stack. The API surface is a convenience for local tools, not evidence that serving workloads are viable. The per-token cost of 25.8 GB of expert reads does not amortize across concurrent users the way resident-VRAM inference does, because bandwidth, not capacity, is the scarce resource.
Budgeting: NVMe first, RAM second
If you take one planning rule from this project, it is to invert the usual local-inference shopping list. The conventional question, “how much VRAM or unified memory do I need?”, has a known floor here: 64 GB of unified memory on Apple Silicon, per the Learn AI entry. Above that floor, additional memory helps as cache but is not the constraint.
Storage has two dimensions, and the sources give figures for both. Capacity: the ExplainX writeup describes a 1.7 TB full install or a 215 GB streamed footprint. Do not conflate these; the smaller figure is the streaming-mode working set, not the whole model. Bandwidth: with roughly 25.8 GB of expert reads per token plus the ~114 GB spine on the I/O path, sustained read throughput is what converts dollars into tokens per second. The sources do not benchmark specific drives or array configurations, so claims about, for example, multi-SSD stripe setups would be speculation here. What the evidence supports is the direction: the marginal dollar goes to faster, higher-endurance storage before it goes to memory beyond 64 GB.
Portability is broader than the MacBook story implies. Per the Medium explainer, deltafin supports Apple Silicon Macs and Linux systems, automatically selecting CPU, CUDA, or Apple’s Metal backend depending on available hardware. The evidenced benchmarks are all M1 Max, though, so Linux and CUDA performance is an open question, not a data point.
Licensing is a split decision
The project’s tracked code is MIT-licensed, according to the GitHub README. The weights are not. Kimi K3 weights, the DSpark checkpoint, and optional Qwen checkpoints all retain their upstream terms, which for K3 means Moonshot’s license, not MIT. For overnight batch experiments this is unlikely to matter; for anything commercial, the weight license, not the code license, is the document to read. This distinction is stated plainly in the project’s own materials, which counts in its favor, but it is easy to miss in the excitement of a front-page thread.
The verdict
Deltafin is real, runnable today, and architecturally instructive: it converts the question “can I afford enough VRAM for a 2.8T model?” into “can my storage sustain tens of gigabytes of reads per token?”. For overnight batch summarization, offline eval harnesses, and systems research, a 64 GB Mac or Linux box with fast NVMe is a defensible alternative to rented GPU inference, especially when the alternative is not running the full unpruned model at all. For anything interactive, the evidenced rates of 0.29 tok/s at best, and possibly 16 seconds per token, keep rented GPUs unambiguously ahead, and the project’s own documentation says so.
The strongest limitation is the evidence base itself. Every performance number is author-reported with zero independent replication in the available coverage, the two speed figures disagree by roughly 5x on the same hardware class, and a codebase that improved 20x in three weeks will not hold still for citation. The per-token I/O math and the workload-tolerance framework will outlive any specific benchmark. The specific benchmarks will not, and neither should your confidence in them.
Frequently Asked Questions
What is the minimum RAM required to run Kimi K3 with deltafin?
The Learn AI wiki entry on deltafin describes the working footprint dropping from over 1.5 terabytes to a level manageable on machines with as little as 64 GB of unified memory, provided sufficient SSD capacity holds the rest.
How much storage space does deltafin require?
Capacity: the ExplainX writeup describes a 1.7 TB full install or a 215 GB streamed footprint. Do not conflate these; the smaller figure is the streaming-mode working set, not the whole model.
What workloads are suitable for deltafin?
Per the Learn AI entry, it explicitly discourages daily coding agents, production webhooks, and multi-tenant serving, and characterizes suitable applications as overnight batch jobs, email-paced interaction, and systems research.
