TL;DR
- Das Mixture-of-Experts-Modell Kimi K3 bringt 1,45 TB Gewicht mit — kein Laptop-RAM fasst das. Der Fork Deltafin lagert die Experts auf NVMe-SSDs und streamt sie schichtweise ins RAM.
- Messwerte vom 8. September 2026: 1,00 Tokens pro Sekunde Decode auf einem M5 Max MacBook Pro mit 128 GB und vier SSDs — bei 6,3 Minuten bis zum ersten Token nach einem 512-Token-Prompt.
- Der kopierbare Kern ist ein Layer-Budget-Check in drei Rechenschritten: Er zeigt, welche Modellklasse auf eigener Hardware läuft, und wie stark zusätzliche SSDs wirklich beschleunigen.
Das Problem: Riesen-Modelle, begrenzter RAM
Kimi K3 von Moonshot ist ein Mixture-of-Experts-Modell (MoE) mit 2,8 Billionen Parametern. Die Expertengewichte umfassen 1,45 TB — das ist rund elfmal mehr Speicher, als ein MacBook Pro mit 128 GB überhaupt fassen kann.
Ein normaler Ladeprozess scheitert an dieser Grenze: Das Modell passt nicht komplett in den Arbeitsspeicher. Genau hier setzt Layer-Streaming an, wie es der Fork argonautlabsai/deltafin umsetzt.
Die Lösung: Schichtweise Streamen von NVMe
Das Prinzip ist simpel: Heiße Layer bleiben im RAM, der Rest liegt auf maximal vier SSDs und wird bei Bedarf nachgeladen. Jedes Token wird dennoch von K3 selbst entschieden — nichts wird gekappt, kein Expert übersprungen.
Alle 16 Experts pro Token kommen zum Einsatz, exakt wie Moonshot sie ausgeliefert hat. Ein kleines Draft-Model darf vorausraten, K3 prüft aber jeden dieser Vorschläge und bestätigt jedes Token. Das Ergebnis ist volle Modellqualität bei minimalem RAM-Fußabdruck.
Die Zahlensprache ist auffallend ehrlich: Jeder Wert stammt aus einem einzigen Cold Run mit exaktem Prompt, Protokolle und Placement-Manifeste liegen offen im Repo.
Die Messwerte vom 8. September 2026
| Metrik | Drafter aus | Drafter an |
|---|---|---|
| Decode-Rate, 512-Token-Antwort (tok/s) | 0,92 | 1,00 |
| Decode-Rate, 128-Token-Antwort (tok/s) | 0,93 | 1,13 |
| Öffentlicher 17-Token-Prompt, Median aus 3 (tok/s) | — | 0,96 |
| Zeit bis zum ersten Token, 512-Token-Prompt | 6,3 min | 6,3 min |
Zum Vergleich: Das Upstream-Repo meldet 0,2901 tok/s auf einem M1 Max — die M5-Max-Kombination mit vier SSDs ist also gut dreimal so schnell. Der öffentliche 17-Token-Prompt lag mit 0,96 tok/s klar über dem, was Upstream mit 0,68 berichtet hatte.
Die SSD-Skalierung: mehr Platten, weniger linear
Die vier SSDs sind kein Trick für die Schlagzeile, sondern messbare Physik. Die Staffel auf identischen Prompts:
- 1 SSD: ≈ 52 % der Vier-Platten-Geschwindigkeit
- 2 SSDs: ≈ 73 %
- 3 SSDs: ≈ 90 %
- 4 SSDs: 100 % (Referenz)
Der Grund: Pro Layer laufen 16 Reads parallel, und der langsamste Satz setzt das Tempo. Gesamtbandbreite hilft nur, wenn die Einzelzüge schnell genug sind.
Die ehrliche Grenze: Prefill und Time-to-First-Token
Die Decode-Rate von ~1 tok/s ist nur die halbe Geschichte. Ein 512-Token-Prompt braucht 6,3 Minuten bis zum ersten Token (Time-to-First-Token, TTFT) — das ist die echte Designgrenze.
Als Ursache hat das Team ausgemacht, dass der Prefill-Durchlauf die Experts jeder Layer achtmal neu liest. Ein Fix ist geplant, aber zum Messzeitpunkt noch nicht gebaut. Für die Praxis heißt das: kurze, präzise Prompts bringen das beste Verhältnis von Wartezeit zu Antwort.
Der kopierbare Layer-Budget-Check
Diese drei Schritte funktionieren mit jedem MoE-Modell und jeder Hardware — ohne das Repo zu brauchen:
- Gesamtgewicht der Gewichte notieren. Beispiel K3: 1.450 GB. Die Zahl steht in der Model Card oder ergibt sich aus der Größe der Gewichtsdateien.
- Heißen Anteil berechnen. Nutzbarer RAM geteilt durch Gesamtgewicht: 128 / 1450 ≈ 9 Prozent der Gewichte bleiben dauerhaft im RAM. Das ist der Sockel, von dem aus gestreamt wird.
- SSD-Staffel anwenden. Von 1,00 tok/s bei vier Platten ablesen: eine Platte ≈ 0,52, zwei ≈ 0,73, drei ≈ 0,90 tok/s. So lässt sich der Wert jeder eigenen Konfiguration grob vorhersagen.
Der Check lohnt sich besonders beim Vergleich mit der Cloud-API: Bei ~1 tok/s entspricht eine 100-Token-Antwort etwa 100 Sekunden Laufzeit — für asynchrone Batch-Jobs okay, für interaktive Chat-Antworten mit mehreren Prompts pro Minute nicht.
Was heißt das für den Agent-Stack?
- Große MoE-Flagschiffe werden lokal lauffähig, ohne dass 1,45 TB in einen Arbeitsspeicher gequetscht werden müssen. Die Qualität bleibt bei voller Expert-Nutzung unangetastet.
- Die Latenz ist die neue Währung: Wer TTFT und Decode-Rate nicht einplant, bekommt einen 6-Minuten-Stau pro Prompt.
- Der Budget-Check wird zur Entscheidungsregel: Erst die 256-GB- und Mehr-Platten-Klassen heben die lokale Inferenz aus dem Nischen-Bereich — genau die Konfigurationen, die auch im Apple-Hardware-Artikel dieses Blogs im Mittelpunkt stehen.
Fazit
Deltafin zeigt, dass Layer-Streaming von NVMe die Lücke zwischen 128-GB-Laptop-RAM und 1,45-TB-Modellgröße wirklich schließt — mit sauberen, reproduzierbaren Messungen statt Prosaversprechen. Der Hebel ist die SSD-Anzahl, die Bremse ist der Prefill. Für Builder heißt das: MoE-Flagschiffe sind lokal keine Theorie mehr, aber ihr Tempo muss pro Workflow durchgerechnet werden, nicht abgelesen.
Häufige Fragen
Wie viele SSDs braucht Deltafin wirklich? Die Referenzmessung läuft mit vier NVMe-Platten und erreicht dort 1,00 tok/s. Eine einzelne Platte liefert immerhin noch etwa 52 Prozent dieses Tempos, zwei Platten 73 Prozent und drei 90 Prozent — der Sprung von eins auf zwei ist also der lohnendste. Wer nur einen Job pro Minute braucht, fährt mit zwei Platten bestens; für parallele Antworten lohnt sich der volle Ausbau.
Warum ist der erste Token nach 512-Token-Prompts so langsam? Der Prefill-Durchlauf liest die Experts jeder Layer achtmal, und jede dieser Leseserien muss vor dem ersten ausgegebenen Token fertig sein. Das summiert sich auf gemessene 6,3 Minuten für einen 512-Token-Prompt. Ein Fix ist im Repo angekündigt, zum Messzeitpunkt aber noch nicht implementiert.
Lohnt sich 128 GB RAM für lokale Inferenz? Mit 128 GB lässt sich Kimi K3 über Layer-Streaming tatsächlich betreiben, der heiße Anteil von rund 9 Prozent der Gewichte trägt den Betrieb. Die 256-GB-Klasse verschiebt die Grenze weiter nach oben und entschärft kleinere Prefill-Ketten. Die ehrliche Antwort hängt am Anwendungsfall: Für lange Prompts bleibt die Zeit bis zum ersten Token der Engpass, nicht der RAM.
Wie rechne ich den Layer-Budget-Check für mein eigenes Modell? Teile deinen nutzbaren RAM durch das Gesamtgewicht der Gewichte aus der Modellbeschreibung, und du kennst deinen heißen Anteil. Multipliziere die Referenz-Decode-Rate danach mit der SSD-Staffel (0,52 / 0,73 / 0,90 / 1,00). Das Ergebnis ist eine grobe, aber nachvollziehbare Vorhersage — abgleichen lässt sie sich mit den offenen Protokollen im k3-public-bench-Ordner des Repos.
Ersetzt das eine Cloud-API? Für asynchrone Aufgaben mit einem Token pro Sekunde ist das lokal gut brauchbar, etwa bei Notiz-Verdichtung oder nächtlichen Batch-Läufen. Für interaktive Ketten aus fünf Prompts mit je 300 Token summiert sich die Laufzeit aber auf mehrere Minuten. Die pragmatische Mischung bleibt: großes Modell lokal als Anker, kleine, schnelle Draft-Arbeit wie gehabt in der Cloud.
Quellen
- https://github.com/argonautlabsai/deltafin — Fork mit Benchmarks, Messprotokollen und Layer-Placement-Manifesten
- https://github.com/gavamedia/deltafin — Upstream-Engine (MIT), Original von gavamedia
- https://github.com/argonautlabsai/argodrive — Mess- und Diagnose-Tools (ARGODRIVE)
- https://news.ycombinator.com/ — Diskussion des Runs mit 198 Beiträgen