Can Full Kimi K3 Run on a 64GB M1 Max? The 1.7TB SSD Reality

Evidence checked August 1, 2026. This is a source-audited technical report, not a Kingy hardware test. The available machine was a 24GB M4 Pro with insufficient storage, so no Kimi K3 weights were downloaded and no local result was invented.

Yes—but only in the narrow technical sense. Deltafin has produced exact Kimi K3 token completions on a 64GB M1 Max while keeping the full expert pool on a roughly 1.7TB local install. The best reported three-run decode median is 0.266 token/s, or 3.76 seconds per token, on one favorable 17-token continuation. That proves the model can emit valid output without all of its weights residing in memory. It does not prove useful interactive inference: realistic code, long-document and tool-call runs have not been published, prompt prefill is expensive, and network-streamed experts fall to minutes per token.

What changed since Kingy’s 128GB Mac Studio audit

Kingy’s earlier 128GB Mac Studio analysis had to stop at “technically plausible.” Unsloth had described disk offload for a heavily compressed 594GB GGUF, but there was no pinned standalone-Mac command, prompt, decode trace or reproducible speed result. The responsible conclusion was that SSD-backed execution might generate, not that it ran well.

Deltafin changes the quality of that evidence. It publishes the runtime, pins the Kimi checkpoint, describes what stays on disk, exposes profiling, supplies exact output-token oracles and reports a three-process benchmark from a 64GB M1 Max. This is a different route from the GGUF experiment. Deltafin uses Kimi’s complete native expert pool, a derived int8 resident spine, native Metal/MPS paths and target-verified speculative drafting.

The result closes one question and opens another. A full K3 target can now be shown generating on a first-generation Max chip with 64GB. What remains unproven is whether that existence proof produces enough useful work per hour to justify the storage, setup time and operational friction.

How SSD-streamed Kimi K3 works

Kimi K3 is a mixture-of-experts model. Moonshot’s official model card lists 896 routed experts and selects 16 for a token. Sparse routing reduces the computation performed at one position, but it does not identify one permanent subset that can be discarded. Later tokens can select different experts.

Deltafin splits the problem into two storage paths:

• Resident spine: attention, shared experts, projections, embeddings and other non-routed weights total about 114GB in the downloaded form. The reference setup converts that spine to roughly 53–54GB of int8 data and streams it layer by layer.
• Routed expert pool: 82,432 per-layer expert files—896 in each of 92 mixture-of-experts layers—occupy about 1.45TB. For a single-position pass, the router selects 16 experts in each layer, touching about 25.8GB of expert data.

The full local install puts both pools on the Mac’s SSD. Deltafin overlaps reads, preloads upcoming layers and uses memory mapping or native buffers where appropriate, but storage remains inside the inference loop. On the reference M1 Max, the repository’s hardware study measured the internal Apple NVMe at about 6.6GB/s for uncached parallel reads. That is consistent with roughly four seconds to fetch a single-position expert footprint. It is fast storage and still radically slower than unified memory.

More important, one target pass also sweeps the int8 spine. A 64GB machine cannot keep the 53–54GB spine, two draft assistants, model state, temporary buffers and the operating system comfortably resident at once. Deltafin therefore saves time by reducing the number of full target passes rather than pretending SSD is RAM.

What “full Kimi K3” means here

“Full” needs a precise definition. Deltafin does not prune experts, reduce top-k routing or let a smaller model replace K3. Its supported runtime requires all 16 selected experts in every routed layer, retains all 82,432 per-layer expert modules—896 in each of 92 layers—and uses K3 as the authority for every emitted token. That is the material distinction from a pruned or reduced-expert build.

It is not a byte-for-byte execution of every tensor in its original stored representation. Kimi’s released checkpoint already uses native MXFP4 for targeted linear weights, while Deltafin converts the non-expert spine to int8 for the reported benchmark. The project says its checks found no meaningful quality change and supplies exact-token parity for the tested continuations, but it has not published a broad independent capability evaluation of the int8 path. “Full, unpruned target” is defensible. “Untouched original numerics” is not.

This also is not proof of K3’s full advertised one-million-token context on a laptop. Long context support in the architecture does not remove prefill time, recurrent state, MLA cache or the cost of rereading a growing chat. Deltafin’s OpenAI-compatible server currently prefills the submitted history again for each request.

Speculative drafting: proposals are not final-token authority

The headline result relies heavily on a pair of small local Qwen3 assistants. A 0.6B model handles admission and a 1.7B model can make wider proposals. Together they consume about 4.63GB of unified memory. They are not substitutes for K3.

The assistant proposes text, Deltafin retokenizes that text with K3’s tokenizer, and the full K3 target verifies the candidate positions. Only the longest prefix that K3 itself accepts can be emitted. A mismatch restores the last committed target state and falls back to a narrower or single-token pass. Confidence can decide whether a proposal is worth checking; it cannot authorize output.

That distinction is why several tokens can share one costly spine sweep without silently turning the run into “Qwen answers, Kimi approves occasionally.” In the favorable France benchmark, three post-prefill target passes emitted 16 tokens because K3 accepted 13 of 13 proposed draft tokens. A different prompt accepted drafts less efficiently. Speculation changes I/O amortization, not the identity of the final model.

Source-audited setup and storage requirements

The following is the reproducible configuration described by the project, not a Kingy-run installation. The audit pins Deltafin at commit 905d8ed145776a75e08344094dc5ed819dca775f, dated July 30, 2026.

git clone https://github.com/gavamedia/deltafin.git
cd deltafin
git checkout 905d8ed145776a75e08344094dc5ed819dca775f

python3 -m venv venv
./venv/bin/python -m pip install torch
./venv/bin/python -m pip install -r requirements.txt
./venv/bin/python tools/build_native.py
./venv/bin/python tools/setup_k3.py --full
./venv/bin/python tools/convert_spine_int8.py

The project’s installation guide recommends the full mode because it removes network access from inference. Running setup with no mode automatically chooses full only when the volume has sufficient capacity; otherwise it falls back to streaming and reports the shortfall.

Reported M1 Max performance

The headline campaign used the raw five-token prompt The capital of France is and checked all 17 output token IDs. It is a useful exactness oracle because each run can be compared token for token. It is not a demanding language or coding benchmark.

A separate prompt—The largest planet in our solar system is—exposed the risk in treating 3.76 seconds as a universal speed. The shipping hybrid assistant reached 4.682 seconds per token in one exact run. With speculation disabled, the same 17 output IDs took 12.530 seconds per token. Both figures are real project measurements, but each is a short, deterministic raw continuation. Neither tells us how K3 behaves on a repository repair, a 50-page document or a strict tool schema.

What different completion lengths would feel like

The table below is arithmetic, not a benchmark. It holds the favorable 23.2-second first-token time and 3.76-second steady median constant. Real answers may draft less successfully, use chat prompts with 60 or more tokens, spend time reasoning, or end earlier.

Interactive coding is especially mismatched. An agent sends a large system prompt, tool definitions and growing history, waits for tool decisions, then repeats. Deltafin handles one request at a time, returns 429 for a concurrent request, uses greedy decoding, and currently rebuilds the model cache and prefills the full submitted history on each chat turn. Its own documentation calls agents a curiosity rather than a workflow.

Local SSD versus network streaming

The two Deltafin install modes answer different questions.

Full local mode proves that all K3 experts can remain under one machine’s physical control without living in unified memory. Inference uses no network after setup, but it needs roughly 1.7TB of fast local capacity. That is the mode behind the 3.76-second result.

Network-streaming mode proves that the installation can start with roughly 215GB. It does not preserve the headline speed. Deltafin estimates about three or more minutes for each token whose experts are not already cached. A community WSL2/CPU run using the stream mode took about 45 minutes to produce three new tokens: 1,982 seconds of prefill followed by roughly 379 and 361 seconds for the next tokens. The cache grew to 121GB during that single run.

A network share is not equivalent to a local NVMe either. The project’s on-demand mode issues many HTTP range requests for expert spans. Latency, provider throttling and the volume of expert traffic dominate. If the goal is useful local experimentation rather than proving a token can arrive eventually, the 1.7TB full install is the real entry price.

SSD wear, heat, power, noise and stability

The M1 evidence is strongest on throughput and weakest on operations. The repository reports an 8TB internal Apple SSD, 6.6GB/s uncached read throughput and a 1.91GB/s write test. It does not publish temperature logs, wall power, fan acoustics, battery behavior, SSD SMART changes or total bytes written for the three-run K3 campaign.

Read traffic should not be confused with NAND write endurance. The largest unavoidable write is the installation itself; network-streaming mode also grows an expert cache, and memory pressure can add swap writes. The repository’s hardware study recorded 28.5GB already in swap at the start of its broader characterization session, but the three-run K3 result does not publish before-and-after swap counters. There is therefore no defensible terabytes-written or SSD-life estimate.

The same limit applies to heat and noise. Sustained GPU, CPU and SSD activity is a plausible thermal load, but plausible is not measured. A separate community 128GB M5 Max campaign reported zero swap and no macOS thermal or performance warnings on AC power across its test runs. That is encouraging evidence for a different machine, not a temperature or power result for the 64GB M1 Max.

Stability is narrower than production reliability. The M1 France campaign completed three fresh processes with a tight speed range and identical tokens. The public evidence does not include the requested realistic prompt suite, long-duration soak test, corrupted-output audit, crash census or recovery test. Deltafin is moving quickly—the repository was only created on July 28—and open pull requests still discuss server queuing and error handling.

64GB versus 128GB Apple Silicon

More memory helps, but there is no clean same-chip 64GB-versus-128GB benchmark. On 64GB, the roughly 53–54GB int8 spine alone consumes most of the physical capacity before the 4.63GB assistants, templates, cache and macOS are counted. Deltafin rereads substantial spine data and budgets resident layers conservatively.

The community’s 128GB M5 Max result at the same Deltafin commit reached 0.6840 token/s, or 1.462 seconds per token, across three default-hybrid France runs and reported zero network fetches. A larger follow-up campaign with position batching enabled reached 0.7439 token/s. Those results cannot be credited to memory alone: the M5 chip, SSD, software paths and page-cache state differ from the M1 reference. The useful conclusion is architectural, not a purchasing ratio. More RAM gives Deltafin room for the spine and filesystem cache; newer silicon supplies more compute and bandwidth. Both reduce the penalty, but neither turns K3 into a normal low-latency desktop model.

A 128GB machine is the more credible research host if this experiment is the priority. A 64GB M1 Max is the more surprising proof. Neither should be purchased specifically for interactive K3 without a representative workload benchmark.

Buyer and operator verdict

For systems researchers: Deltafin is worth studying. It demonstrates exact target-authorized generation from a model far larger than RAM, with auditable source, pinned revisions and unusually candid caveats.

For overnight or queued jobs: maybe. A fixed, short, deterministic workload could be acceptable if privacy matters more than turnaround and the operator validates output on that exact task. The current evidence does not establish reliable long-document, code-repair or structured-output behavior.

For interactive coding, chat or a team service: no. Even the favorable completion arrives at roughly 16 tokens per minute, long prompts are expensive, one request runs at a time and every growing chat is prefilled again.

For a buying decision: do not buy an M1 Max and a multi-terabyte SSD to avoid API fees. If the machine and storage already exist, Deltafin is a remarkable experiment. If useful K3 capability is the goal, a hosted endpoint remains the practical baseline. Kingy’s Kimi K3 versus DeepSeek V4 Flash comparison covers the current API and home-lab trade-offs, while the open-weights download guide documents the official checkpoint and cluster-scale deployment reality.

FAQ

Can full Kimi K3 really run on a 64GB M1 Max?

Yes, if “run” means the complete unpruned target can read weights from local SSD and emit K3-verified tokens. Deltafin reports three exact 17-token completions on a 64GB M1 Max. The weights do not fit in RAM, and the result is not interactive by normal standards.

Does the full model require 1.7TB of free SSD space?

From an empty install, Deltafin’s capacity check requires about 1.66TB free: roughly 1.56TB of source weights plus 100GB of headroom. The project rounds that total to about 1.7TB. Its later int8 spine and 4.63GB draft-model pair consume part of that margin, so operators should still leave normal filesystem and macOS working space rather than filling a volume to the limit.

Can an external SSD run Kimi K3?

Deltafin supports model data under its configured root, but the published 64GB M1 result used an internal 8TB Apple NVMe. No equivalent external-drive benchmark is published. Interface bandwidth, enclosure cooling, filesystem and sustained random-read behavior would need to be measured rather than inferred from a peak USB4 or Thunderbolt label.

Can Deltafin use only 215GB?

Yes, in network-streaming mode. The resident spine stays local and missing experts arrive from Hugging Face on demand. That mode is an installation shortcut, not a fast inference configuration; uncached tokens can take minutes.

Is 3.76 seconds per token the normal speed?

No. It is a three-run median for one short raw continuation with 13 of 13 submitted drafts accepted. Another exact prompt took 4.682 seconds per token with the shipping hybrid assistant, and target-only decoding took 12.530 seconds per token. Real workload speed remains unmeasured.

Does speculative decoding lower Kimi K3 quality?

The available evidence does not establish broad quality parity. Deltafin asks smaller Qwen models for proposals, retokenizes them and runs the full K3 target to verify the accepted prefix, so the assistants do not independently authorize output. Its exact-token tests validate the checked greedy continuations; a broader independent capability comparison of the complete int8 runtime has not been published.

Can it analyze long documents or act as a coding agent?

In principle, Deltafin exposes an OpenAI-compatible server. In practice, its documentation warns that chat prefill is expensive, full history is resubmitted and only one request runs at a time. No published 64GB M1 Max benchmark covers code generation, code repair, long-document analysis or structured tool calls.

Methodology and evidence limits

Kingy reviewed the official Kimi K3 model card and pinned checkpoint, Deltafin commit 905d8ed, its README, optimization guide, hardware study, commit history and public issues through August 1, 2026. Reported project measurements, community reports, arithmetic calculations and Kingy inference are labeled separately.

No suitable 64GB M1 Max with the required storage was available. Kingy did not download the 1.56TB checkpoint, run Deltafin, inspect the reference machine, verify SSD SMART data or reproduce any completion. The published M1 evidence does not provide realistic multi-prompt results, a true cold-cache campaign, power or temperature telemetry, or an SSD-endurance trace. Those gaps limit the verdict to technical feasibility and reported speed—not general usefulness.

Primary sources

• Deltafin README at the audited commit — installation modes, architecture, M1 reference metrics and operational caveats.
• Deltafin optimization guide — target authorization, speculative drafting and correctness boundaries.
• Deltafin model-source manifest — pinned Kimi revision and verified inventory identity.
• Official Kimi K3 model card — model architecture, native quantization and license.
• Community 128GB M5 Max campaign and network-streaming result — separately labeled comparison points.

Kingy Launch Brief

Put the week’s verified AI launches in your inbox.

The public Friday pilot has not sent its first issue yet. Join for a source-checked launch briefing with a clear try, watch or skip verdict, then check your inbox and confirm your address.

Free · Friday pilot · Double opt-in · Unsubscribe anytime