Kimi K3 mit 2,78 Billionen Parametern läuft auf einer CPU mit 8 GB RAM

Worum es geht

Das GitHub-Projekt kimi-k3-in-c von Fareed Khan (und weiteren Mitwirkenden) zeigt, dass sich selbst ein Modell mit 2,78 Billionen Parametern auf gewöhnlicher Hardware ausführen lässt – wenn man bereit ist, sehr lange zu warten. Es handelt sich um eine Inferenz-Engine für Kimi K3 von Moonshot AI, geschrieben in portablem C99: ohne BLAS-Bibliothek (Bibliothek für schnelle Matrixrechnung), ohne KI-Framework, ohne GPU. Die gesamte Engine ist laut README 176 KB groß. Gemessen wurde ein Spitzenverbrauch von 8,24 GB RAM bei einem Checkpoint von 1,56 TB auf der Festplatte. Das Projekt steht unter Apache-2.0, trägt die Version 1.1.0 und läuft unter Linux (Referenz), macOS/arm64 und Windows.

Wichtig: Es ist kein neues Modell, sondern ein Werkzeug, um ein vorhandenes Modell zu betreiben. Die Gewichte von Kimi K3 lädst du separat von Hugging Face herunter.

Der Trick: Speicher wird zum Regler

Kimi K3 ist ein Mixture-of-Experts-Modell – es besteht aus sehr vielen Teilnetzen („Experten“), von denen pro Token nur wenige aktiv sind. Laut README werden pro Schritt 16 von 896 Experten ausgewählt. Die Engine nutzt das radikal aus. Vier Entscheidungen, wo welche Bytes liegen, sollen das Modell vom Server-Cluster auf den Laptop bringen:

1. Experten bleiben 4-bit: Die rund 1,45 TB an Experten-Gewichten werden nie komplett in den Speicher geladen und direkt aus ihrer gepackten 4-Bit-Form (MXFP4) multipliziert; sie werden ohnehin schon so ausgeliefert.
2. KDA-Attention: Ein Aufmerksamkeitsmechanismus, dessen Gedächtnis nicht mit der Textlänge wächst.
3. MLA: Statt 96 Attention-Köpfen wird ein gemeinsamer komprimierter Vektor („Latent“) gespeichert, was den Zwischenspeicher klein hält.
4. Streaming des Stamms: Die dichten 93 Schichten („Trunk“) werden einmalig in eine 109 GB große Datei umgepackt, sodass jede Schicht mit einem einzigen Lesezugriff geladen werden kann. Wie viele Schichten dauerhaft im RAM bleiben, bestimmst du selbst – daraus wird laut Autor aus einer festen Untergrenze ein „Regler“.

Zusätzlich gibt es einen LRU-Cache für Experten (die zuletzt benutzten bleiben im Speicher). Die Konsequenz laut README: Dasselbe Modell läuft mit 8 GB und mit 224 GB und liefert bei jedem Budget byte-identische Ausgaben. Mehr Speicher beschleunigt nur.

Zahlen: Wie langsam ist „langsam“?

Die Zeit pro Token hängt vom Arbeitsspeicher ab (gemessen auf einer Maschine mit 124 Kernen und schneller NVMe-SSD):

Die Demo-Läufe zeigen es konkret. Auf dem „laptop“-Preset erzeugte die Engine für „The capital of France is“ acht Token in 261,5 s (32,69 s/Token im Schnitt, auf einer langsameren Platte aufgenommen) bei 8,24 GB Spitzen-RAM. Auf dem „server“-Preset brauchten 28 Token für „def fibonacci(n):“ 299,3 s (10,69 s/Token) bei 127,92 GB. Im Vergleich zu Version 1.0.0 sei die Rechenarbeit pro Token etwa 8-mal leichter, eine Folgefrage im Chat 3,9-mal schneller und lange Prompts etwa halb so teuer.

Die Presets im Überblick (Trunk-/Expertencache-Budget in GB):

Funktionen und Prüfung

Neben Rohtext-Fortsetzung gibt es einen Chat-Modus mit dem offiziellen XTML-Format von Kimi K3, inklusive Denkblock und Gesprächsverlauf als JSONL-Datei. Version eins ist text-only, ohne Tools oder Bilder. Das Denken ist standardmäßig an (Aufwand „max“); --no-think ist laut Autor der größte Geschwindigkeitshebel – in einem Lauf bestanden 119 von 150 Token einer Fünf-Wort-Antwort aus dem Denkblock. Sampling (Temperatur, Top-p, Seed) ist möglich, Standard ist Greedy-Decoding.

Zur Absicherung gibt es eine Testleiter: make test läuft ohne Modell in unter einer Minute und vergleicht die Engine mit einem PyTorch-Referenzmodell an einem 13-Schichten-Testmodell mit gleichem Tensor-Graph. Auf dem echten Checkpoint wurden die Ergebnisse ebenfalls geprüft. Einen vollständigen Download prüft ein Skript Byte für Byte, da ein unvollständiger Download falsche Token statt Fehlermeldungen liefert. Beiträge für macOS-, Windows- und NEON-Ports, Chat-Modus und schnellere MXFP4-Kernel kamen von Mitwirkenden.

Was du zum Ausprobieren brauchst

Das Nadelöhr ist der Speicherplatz: etwa 1,7 TB frei (1,56 TB Checkpoint plus 109 GB gepackter Stamm), idealerweise auf einer schnellen lokalen NVMe-SSD – laut Autor ist „Storage the whole game“. RAM: ab 8 GB, jedes Preset läuft. CPU: AVX2 + FMA auf x86-64 oder NEON auf ARM. Compiler: GCC ≥ 9 oder Clang ≥ 10, dazu make oder CMake, Python 3.9+ für Download- und Packskripte. Der Download dauert Stunden und braucht einen Hugging-Face-Token. Eine Grafikkarte ist nicht nötig; Apple-Silicon-Macs werden unterstützt, Google Colab ist wegen des Speicherbedarfs unrealistisch. Mit make und make test kannst du die Engine zuvor ohne Download prüfen.

Hintergrund: Kimi K3 und K3.1

Laut TechRepublic hat Moonshot AI Kimi K3 mit 2,8 Billionen Parametern, 1 Mio. Token Kontext und Vision als „weltweit erstes offenes 3T-Modell“ vorgestellt. K3 landete dort im Frontend-Code-Arena-Ranking von Arena.AI auf Platz 1; insgesamt blieb es laut Moonshot hinter den stärksten proprietären Systemen. Die API kostet 3 $ pro Million Eingabe- und 15 $ pro Million Ausgabe-Token. Gewichte sollten dort am 27. Juli erscheinen.

Laut Unite.ai folgte am 24. Oktober 2026 Kimi K3.1 Pro, ein nachtrainiertes K3 mit größerem Post-Training-Aufwand und 1M-Kontext. Moonshot nennt unter anderem 65,7 % auf Terminal-Bench 4.0 (GPT-6 Astra 58,2 %, Claude Opus 5.5 66,4 %) und 92,7 % auf BenchCAD. Für die offenen Gewichte entfernte das Unternehmen nach eigener Aussage Cyber-Daten aus dem Training; die Gewichte sollen bis zum 4. November 2026 erscheinen. Geeky Gadgets (nach einem YouTube-Kanal) wiederholt diese Zahlen mit sehr werblichem Ton und nennt zudem Preise „pro Aufgabe“, die kaum nachvollziehbar sind – hier ist Vorsicht geboten. Ob die C-Engine K3.1 unterstützt, steht in der vorliegenden README nicht.

Einordnung

Das Projekt ist weniger eine Alltagslösung als ein Machbarkeitsnachweis: 26,5 Sekunden pro Token bedeuten, dass eine kurze Antwort Stunden braucht. Interessant ist es für Entwickler und Tüftler, die verstehen wollen, wie sich Riesenmodelle durch Streaming, 4-Bit-Experten und Caching auf kleine Maschinen bringen lassen, und für Fälle, in denen ein Modell sich überhaupt lokal auf unspektakulärer Hardware reproduzierbar ausführen lassen soll. Für interaktive Arbeit bräuchte man 128 GB+ RAM, und selbst dann sind 5,6 s pro Token noch weit von Cloud-Tempo entfernt. Alle Messwerte stammen vom Projekt selbst und sind nicht unabhängig bestätigt; die Geschwindigkeit hängt stark von der SSD ab. Dass byte-identische Ausgaben bei jedem Speicherbudget herauskommen, ist ein starkes Qualitätsversprechen, weil keine zusätzliche Quantisierung des Stamms eingesetzt wird – der Autor begründet im Abschnitt „Why the trunk is not quantised“ ausführlich, warum.