kimi-k3-in-c: ein 2,78-Billionen-Parameter-Modell, das aus 8,24 GB RAM antwortet

Das Problem: ein Checkpoint von 1,56 TB auf einem Laptop

Die README nennt das Modell selbst und die Zahl daneben: 2,78 Billionen Parameter, 1,56 TB auf der Platte. Ein solcher Checkpoint passt in keinen einzelnen Rechner, den ein normaler Entwickler besitzt, und die übliche Antwort darauf ist ein Cluster oder ein Server mit vielen GPUs. Das Projekt verfolgt die entgegengesetzte Richtung und behauptet, dasselbe Modell mit derselben Antwort auf jedem Rechner laufen zu lassen, den man schon hat. Der Satz aus der README lautet, mehr Speicher kaufe nur Geschwindigkeit.

Die Zielgruppe ist damit klar umrissen: Systemprogrammierer, die verstehen wollen, wie ein Mixture-of-Experts-Modell tatsächlich Bytes bewegt, und Anwender, die ein großes Modell auf einer Maschine ohne GPU prüfen wollen. Es ist kein Werkzeug für einen Chat-Dienst. Die beiden Beispiele in der README sind ein Basismodell ohne Chat-Template, weshalb auf "The capital of France is" die Fortsetzung " Paris." folgt und keine Antwort. Wer Dialogverhalten erwartet, hat das falsche Projekt vor sich.

Vier Entscheidungen darüber, wo Bytes liegen

Die Architekturbeschreibung in der README ist erfreulich konkret. Der dichte Trunk bleibt bis zu einer wählbaren Tiefe im Speicher, der Rest wird gestreamt. Die 1,45 TB der gerouteten Experten sind nie resident und werden direkt aus ihrer gepackten 4-Bit-Form multipliziert. Die README fasst das in vier Entscheidungen darüber zusammen, wo Bytes leben, und illustriert sie mit einem Diagramm vom Servercluster bis zum Laptop.

Die Konsequenz ist der eigentliche Kern des Projekts: dasselbe Modell läuft in 8 GB und in 224 GB und erzeugt bei jedem Budget zwischen diesen Werten byte-identische Ausgabe. Das ist eine starke Behauptung, aber sie ist testbar, weil sie sich auf die Ausgabe bezieht und nicht auf die Laufzeit. Die README trennt beides sauber: "Same short prompt at every size, and the output is byte-identical from the smallest machine to the largest; only the clock changes." Genau diese Trennung macht das Projekt interessant. Die Speichergrenze verschiebt sich nicht mit dem Budget, nur die Wartezeit.

Interessant ist auch, was das über die Expertenwahl sagt. Wenn 1,45 TB an Expertengewichten nie resident sind, aber pro Token nur ein Bruchteil davon gebraucht wird, dann ist der Engpass nicht die Rechenleistung, sondern der Durchsatz der Platte. Die README bestätigt das indirekt: Bei den ersten drei Presets liest selbst eine Maschine mit 124 Kernen und schneller NVMe das Modell bei jedem Schritt von der Platte, und eine langsamere Platte ist dort langsamer.

Installation: Makefile, Presets und ein Modell ohne Chat-Template

Der Quick-Start ist laut README in etwa einer Minute erledigt und braucht kein Modell: klonen, bauen, verifizieren. Der vollständige Weg führt über einen Aufruf, den die README wörtlich zeigt:

./bin/k3 ~/k3model --trunk ~/k3trunk --preset laptop --tok ~/k3model --prompt "The capital of France is" --gen 8 --incremental

Die Optionen sind sprechend: --trunk verweist auf den residenten Teil, --tok auf das Tokenizer-Verzeichnis, --prompt und --gen steuern Eingabe und Länge, --incremental schaltet den schrittweisen Modus. Der Preset-Name entscheidet über das Speicherbudget. Im Beispiel oben steht laptop für 8 GB, im zweiten Beispiel server für 128 GB und mehr. Die README listet weitere Diagnoseoptionen, Umgebungsvariablen und Exit-Codes, ohne sie im zitierten Ausschnitt auszubreiten.

Ein Detail, das man leicht überliest: Das Modell ist ein Basismodell. Es gibt kein Chat-Template. Die README sagt das ausdrücklich und liefert die Begründung gleich mit, warum auf den Frankreich-Prompt ein Eigenname folgt statt eines Satzes. Für Experimente mit Fortsetzungen ist das unproblematisch, für alles, was wie ein Assistent aussehen soll, fehlt die Vorlage.

Was die Zahlen sagen und was sie nicht sagen

Die README nennt vier Messpunkte für dasselbe kurze Prompt: 26,5 s pro Token bei 8 GB, 24,2 s bei 32 GB, 19,8 s bei 64 GB und 5,6 s bei 128 GB und mehr. Zwischen 8 und 64 GB verbessert sich die Zeit also nur um etwa ein Viertel, obwohl der Speicher um das Achtfache wächst. Der Sprung kommt erst, wenn das Modell vollständig in den Speicher passt und die Plattenwartezeit verschwindet. Wer plant, von 8 auf 32 GB aufzurüsten, sollte diese Zahlen vorher lesen.

Die beiden Konsolenbeispiele in der README zeigen andere Werte, 32,69 s und 10,69 s pro Token, und die README erklärt die Abweichung selbst: Es sind die ursprünglichen Aufnahmen auf einer langsameren Platte. Das ist ehrlich, aber es bedeutet auch, dass die Zeiten stark von der eigenen Hardware abhängen und nicht als feste Kennzahlen übertragbar sind. Wer eine langsame SATA-Platte hat, wird die genannten Werte nicht erreichen.

Für v1.0.0 nennt die README Verbesserungen gegenüber der Vorgängerversion auf derselben Maschine mit 124 Kernen: etwa achtmal weniger Rechenarbeit pro Token, eine Folgefrage im Chat 3,9-mal schneller, lange Prompts etwa halb so teuer. Das sind Angaben aus der README, keine unabhängig nachvollzogenen Messungen. Ich habe das Projekt nicht gebaut und nicht ausgeführt; alle Zahlen in diesem Text stammen aus dem Repository.

KDA und MLA: zwei Reduktionen mit unterschiedlichen Kosten

Die README beschreibt zwei Aufmerksamkeitsvarianten als Teil des Mechanismus. KDA steht dort für Aufmerksamkeit mit einem Speicher, der nie wächst. MLA ersetzt 96 Köpfe durch ein einzelnes Latent. Beide senken den Speicherbedarf während der Inferenz, aber auf verschiedene Weise, und genau darin liegt der Unterschied, den man beim Lesen des Codes prüfen sollte.

Eine Aufmerksamkeit mit konstantem Zustandsspeicher ist für lange Kontexte attraktiv, weil die Kosten pro zusätzlichem Token nicht mit der Kontextlänge wachsen. Ein einzelnes Latent statt vieler Köpfe senkt dagegen den Speicher für die Projektionen selbst. Die README behandelt beide unter der Überschrift der Reduktionen, ohne im zitierten Ausschnitt zu sagen, wie sich die beiden Verfahren bei der Ausgabequalität schlagen. Das ist eine Lücke. Wer das Projekt für lange Kontexte einsetzen will, sollte im Code oder in docs/data/ nachsehen, ob es dazu Messungen gibt, statt die Architekturbeschreibung als Qualitätsaussage zu lesen.

Der Expertenpfad ist der dritte Mechanismus. Die Experten liegen bereits in halber Byte-Größe vor, also in 4-Bit-Form, und werden laut README direkt aus dieser gepackten Form multipliziert. Das ist der Grund, warum 1,45 TB Gewichte überhaupt in einem 8-GB-Budget durchlaufen können. Der Preis ist, dass jeder Schritt dieselben Bytes erneut von der Platte holt.

Wann das der falsche Motor ist

Die größte Einschränkung steht in der README selbst, nur nicht als Warnung formuliert: Bei 8 GB streamt das gesamte Modell bei jedem Schritt von der Platte. 26,5 Sekunden pro Token bedeuten für einen Absatz von hundert Token über 44 Minuten. Für Stapelverarbeitung über Nacht mag das akzeptabel sein. Für alles Interaktive ist es unbrauchbar, und kein Preset-Wechsel behebt das ohne zusätzlichen Speicher.

Ein zweiter Punkt ist die Plattform. Die README verlinkt auf Linux x86-64, und die Themenliste nennt AVX2. Portable C99 heißt hier also nicht, dass der Code überall gleich schnell läuft oder überhaupt überall gebaut wird. Wer auf ARM oder macOS plant, findet im vorliegenden Material keinen Beleg, dass das Projekt dort läuft. Das sollte man vor dem Klonen prüfen, nicht danach.

Drittens die Modellbeschaffung. Das Projekt liefert den Motor, nicht die Gewichte. Ohne 1,56 TB Checkpoint und den passenden Trunk läuft nichts. Wer diesen Speicherplatz und die Bandbreite zum Herunterladen nicht hat, kann das Projekt nicht sinnvoll evaluieren, unabhängig davon, wie klein der Motor selbst ist. Die README nennt 176 KB für den gesamten Motor; das ist die Größe des Codes, nicht die des Problems.

Der Unterschied zu llama.cpp und zu Server-Stacks

Der naheliegende Vergleich ist llama.cpp, das ebenfalls in C geschrieben ist und ohne Framework auskommt. Der Unterschied liegt nicht in der Sprache, sondern im Speichermodell. llama.cpp ist darauf ausgelegt, Gewichte in den Speicher zu laden und dort zu halten, mit Quantisierung als Mittel, um sie klein genug zu machen. kimi-k3-in-c geht davon aus, dass ein Teil des Modells nie resident sein wird, und streamt die gerouteten Experten bei jedem Schritt von der Platte. Das ist ein anderer Kompromiss: llama.cpp tauscht Genauigkeit gegen Speicher, kimi-k3-in-c tauscht Zeit gegen Speicher.

Gegenüber einem Server-Stack mit mehreren GPUs ist der Unterschied noch deutlicher. Dort liegt das Modell im Beschleunigerspeicher, und die Kosten skalieren mit der Anzahl der Karten. Hier bleibt die Ausgabe laut README über alle Speicherbudgets hinweg byte-identisch, und zusätzlicher Speicher ändert nur die Uhr. Für Reproduzierbarkeitsexperimente ist das ein Vorteil, weil man nicht für jedes Budget eine andere Quantisierungsstufe in Kauf nehmen muss.

Der Preis dieser Entscheidung ist die Abhängigkeit von der Platte. Die README sagt es selbst: Bei den ersten drei Presets liest auch eine Maschine mit 124 Kernen das Modell bei jedem Schritt von der Platte. Man kann also nicht durch mehr CPU-Leistung aus dem Problem herausrechnen. Nur mehr Speicher hilft.

Pflege, Lizenz und was vor dem ersten Lauf zu klären ist

Das Projekt steht unter Apache-2.0, was die kommerzielle Nutzung und Änderung erlaubt, solange Lizenz- und Urheberrechtshinweise erhalten bleiben. Das ist eine Aussage über den Code in diesem Repository. Sie sagt nichts über die Lizenz des Modells, dessen Gewichte man separat beschaffen muss. Wer das Ergebnis produktiv einsetzen will, muss die Bedingungen des Modells selbst prüfen; die README behandelt diesen Punkt im zitierten Ausschnitt nicht, und aus dem Repository lässt sich dazu nichts ableiten. Rechtsberatung ist das hier nicht.

Der Wartungsaufwand wirkt überschaubar, aber das ist eine Einschätzung auf Basis der Struktur, nicht auf Basis von Betriebserfahrung. Der Motor umfasst laut README 176 KB, hat keine externen Abhängigkeiten außer der C-Standardbibliothek und wird über ein Makefile gebaut. Es gibt zwei Releases, v0.1.0 vom 2. August 2026 und v1.0.0 vom 7. August 2026, sowie einen CI-Workflow. Der Abstand zwischen den Releases beträgt fünf Tage, was eher auf eine frühe Phase hindeutet als auf einen eingefrorenen Stand.

Konkret vor dem ersten Lauf zu prüfen: ob der gewählte Preset-Name zum tatsächlichen RAM passt, denn die Zeiten in der README hängen direkt daran. Ob die Platte schnell genug ist, weil die ersten drei Presets bei jedem Schritt lesen. Und ob im Verzeichnis docs/data/ Messwerte liegen, die zur eigenen Konfiguration passen, statt sich auf die vier Zeilen aus der README zu verlassen.

Redaktionelles Fazit

Wer ein 2,78T-Modell auf vorhandener Hardware prüfen will und Sekunden pro Token akzeptiert, findet hier einen kleinen, nachvollziehbaren Motor mit Apache-2.0-Lizenz. Wer interaktives Chatten mit vertretbarer Latenz braucht, ist hier falsch; dafür ist der Durchsatz zu niedrig und das Modell ein Basismodell ohne Chat-Template. Vor dem ersten Lauf zu klären: ob die 1,56 TB Checkpoint plus Trunk tatsächlich lokal liegen, ob der Preset-Name zum RAM passt, und ob die eigene Platte die im Dokument genannten Zeiten überhaupt erreicht, denn die ersten drei Presets lesen das Modell bei jedem Schritt erneut von der Platte.

Offizielle Quellen

1. FareedKhan-dev/kimi-k3-in-c on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases