Ein Entwickler hat das Open-Weights-Flaggschiffmodell Kimi K3 von Moonshot AI in nur 29 GB Arbeitsspeicher gequetscht – was ungefähr dem RAM eines handelsüblichen PCs entspricht. Das Modell lief zwar, aber auf die Frage „Was ist die Hauptstadt von Italien?“ dachte es erst 31 Sekunden nach, bevor es eine 16 Wörter lange Antwort ausgab.
Abbildung: Kimi K3, das Ende Juli von Moonshot AI veröffentlichte Flaggschiff-Modell. Quelle: github.com/MoonshotAI
Das Projekt sorgte in den letzten Tagen in Entwicklerkreisen für viel Aufsehen. Auf Hacker News sammelte es über 130 Upvotes und mehr als 50 Kommentare. Die Reaktionen reichten von Staunen bis zu fundierter Skepsis. Wir haben die Hintergründe und Argumente beider Seiten für technisch Interessierte zusammengefasst.
Warum verbrauchen KI-Modelle so viel Arbeitsspeicher?
Um dieses Experiment zu verstehen, muss man sich zunächst die Ausmaße von Kimi K3 verdeutlichen.
Kimi K3 ist das neueste Flaggschiff-Modell von Moonshot AI, das Ende Juli 2026 veröffentlicht wurde. Es umfasst gigantische 2,78 Billionen Parameter (2,78T).
Parameter kann man sich wie Zahlenwerte im neuronalen Netz des Modells vorstellen. Die Leistungsfähigkeit einer KI beruht auf mathematischen Berechnungen über diese riesigen Zahlenmengen: Je mehr Parameter ein Modell besitzt, desto intelligenter ist es in der Regel – aber desto mehr Speicherplatz belegt es auch. In der offiziellen Release-Version (FP4-komprimiert) belegt K3 rund 1,42 TB. Das passt nicht einmal auf eine gewöhnliche 1-TB-SSD.
Bei der Inferenz muss das Modell all diese Parameter in den Arbeitsspeicher (RAM) laden, um Berechnungen durchzuführen. Ein 1,42 TB großes Modell in einen 29 GB großen Arbeitsspeicher zu zwängen, entspricht einer Kapazitätslücke von fast dem 50-Fachen.
Normalerweise laufen Modelle dieser Größenordnung ausschließlich in Cloud-Rechenzentren mit hunderten Spezialservern, großen GPU-Clustern und Terabytes an Arbeitsspeicher. Wenn Sie eine Anfrage per App stellen, findet die Berechnung dort statt und das Ergebnis wird gestreamt zurückgesendet.
Warum sollte man Flaggschiff-Modelle überhaupt lokal ausführen?
Wenn Cloud-Dienste schnell, bequem und zuverlässig sind, warum nehmen Entwickler dann solche Strapazen auf sich, um Modelle lokal auszuführen? Die Gründe sind durchaus pragmatisch.
Der erste Grund ist der Datenschutz. Jede Promp-Eingabe an Cloud-APIs verlässt das eigene Gerät und wird an externe Server übertragen. Bei alltäglichen Unterhaltungen mag das unbedenklich sein, aber Verträge, Quellcode, Patientenakten oder Finanzberichte dürfen in vielen Unternehmen das Haus nicht verlassen. Lokale Datensouveränität ist das stärkste Argument für lokale KI.
Der zweite Grund sind die Kosten. Cloud-Anbieter rechnen nach Tokens ab. Was bei gelegentlicher Nutzung kaum auffällt, kann bei automatisierten Workflows oder Massenverarbeitungen schnell teuer werden. Lokale Inferenz erfordert lediglich eine einmalige Hardware-Investition – sobald die Festplatte gekauft ist und der Strom fließt, entstehen keine weiteren Nutzungskosten.
Der dritte Grund ist die Offline-Verfügbarkeit. Lokale Modelle funktionieren ohne Internetverbindung und sind unabhängig von Ausfällen, Preiserhöhungen oder Richtlinienänderungen der Anbieter.
Hinzu kommt die reine Begeisterung der Entwickler-Community. In der „Local Inference“-Szene stellen sich Entwickler sportlich der Herausforderung, eigentlich unschaffbare Modelle auf gewöhnlicher Hardware zum Laufen zu bringen. Das Open-Source-Projekt namens WASTE veröffentlichte seine gesamte Architektur und Logbücher auf GitHub.
Wie Kimi K3 in 29 GB RAM passt
Die erste Schlüsseltechnik ist die Quantisierung – die Reduzierung der numerischen Präzision der Modellgewichte.
Ursprünglich werden Modellparameter als hochpräzise Fließkommazahlen gespeichert. Bei der Quantisierung werden Nachkommastellen gekürzt und die Werte beispielsweise in 4-Bit- oder 3-Bit-Formaten abgespeichert. Die offizielle Version von K3 war bereits auf 4-Bit (1,42 TB) komprimiert. Das WASTE-Projekt reduzierte die Gewichte der Experten im Mixture-of-Experts-Netzwerk weiter auf 3-Bit, wodurch die Modelldatei auf 982 GB schrumpfte.
Eine reine Komprimierung reicht jedoch nicht aus, um 982 GB in 29 GB RAM unterzubringen. Der eigentliche Kniff liegt im intelligenten Arbeitsspeicher-Management.
Kimi K3 basiert auf einer Mixture of Experts (MoE)-Architektur mit 896 Experten-Subnetzwerken. Bei der Generierung eines einzelnen Tokens werden jedoch nur 16 Experten aktiviert, während die restlichen 880 inaktiv bleiben. Man kann sich das wie ein großes Krankenhaus vorstellen, bei dem zu einer Konsultation nur die Fachärzte der relevanten Abteilungen hinzugezogen werden, während die anderen in Bereitschaft bleiben.
Das WASTE-Projekt behält daher nur den häufig genutzten Backbone-Teil (27 GB) dauerhaft im RAM. Die verbleibenden 880 Experten liegen auf der SSD und werden erst bei Bedarf dynamisch in den Arbeitsspeicher gestreamt.
Abbildung: K3-Architektur im Überblick – Mixture of Experts mit neuen Attention-Mechanismen und 2,8 Billionen Parametern. Quelle: sebastianraschka.com
Der Preis für diesen Ansatz ist die Geschwindigkeit. Für jedes generierte Token müssen 17 GB an Expertendaten von der SSD gelesen werden. Selbst extrem schnelle interne PCIe-NVMe-SSDs (mit bis zu 12,78 GB/s) geraten dabei an ihre Grenzen; bei Nutzung einer externen USB-Festplatte (0,94 GB/s) dauert die Ausgabe eines einzelnen Wortes 13 Sekunden.
Auch die Vorbereitung ist aufwendig. Die Umwandlung der 1,42 TB großen FP4-Release-Dateien in das 982-GB-Format dauert knapp 5 Stunden und erfordert hochperformanten Speicher.
Die Angabe „29 GB RAM“ beschreibt somit die Mindestanforderung an den Arbeitsspeicher des Rechners, nicht die Modellgröße. Im Arbeitsspeicher befindet sich nicht das gesamte Modell, sondern nur dessen aktiver Kern. Ein PC mit 32 GB RAM kann das Modell zwar starten, für eine flüssigere Ausführung werden jedoch 64 GB empfohlen. Wenn der Arbeitsspeicher voll ist und das Betriebssystem beginnt, die SSD als virtuellen Arbeitsspeicher zu nutzen, bricht die Leistung um das Achtfache ein.
Die Kehrseite der starken Komprimierung
Quantisierung gibt es nicht umsonst. Wird die Präzision der Zahlen zu stark beschnitten, leidet die Antwortqualität. Benchmarks des Unsloth-Teams zeigen, dass eine 2-Bit-Quantisierung etwa 90 % der ursprünglichen Genauigkeit bewahrt, während eine 1-Bit-Quantisierung auf etwa 80 % abfällt.
Abbildung: Je kleiner ein Modell quantisiert wird, desto höher ist die Wahrscheinlichkeit von Abweichungen gegenüber dem Original. Quelle: unsloth.ai
Hinzu kommt, dass die Qualität stark von der technischen Umsetzung abhängt. Zwei verschiedene 1-Bit-Quantisierungen desselben Modells durch unterschiedliche Teams können sich in der Ausgabequalität um das Bis zu 20-Fache unterscheiden. Quantisierung ist präzise Handwerkskunst.
0,5 Tokens/Sekunde: Die Lücke zwischen „Es läuft“ und „Es ist nutzbar“
Bei einer Geschwindigkeit von 0,5 Tokens pro Sekunde dauert eine kurze Antwort mit 16 Wörtern etwa 31 Sekunden, während ein Text mit 128 Wörtern sechs Minuten benötigt. Da K3 ein Modell ist, das vor der Ausgabe einer Antwort interne Denkprozesse (Chain of Thought) durchläuft, verlängert sich die Wartezeit auf lokalen Systemen zusätzlich.
Die Entwickler des Projekts bleiben dabei erfrischend ehrlich: Sie behaupten nicht, eine praxistaugliche Geschwindigkeit erreicht zu haben, sondern wollten die technische Machbarkeit beweisen. Schicht-für-Schicht-Vergleiche mit der offiziellen Referenzimplementierung zeigten Abweichungen von lediglich wenigen Millionsteln. Nach ihrem Kenntnisstand ist dies der erste öffentliche Nachweis, dass ein Modell mit über 1 Trillion Parametern per SSD-Streaming auf einem gewöhnlichen PC ausgeführt werden kann.
Führt man hingegen kleinere Modelle mit dieser Methode aus, sieht die Welt völlig anders aus: Das 48-Milliarden-Parameter-Modell Kimi-Linear benötigt 19 GB Speicherplatz, startet mit einer RAM-Belegung von nur 1,87 GB und erreicht auf Standard-Hardware 10,7 Tokens pro Sekunde. Auf modernen Server-GPUs im Rechenzentrum generiert K3 hingegen über 100 Tokens pro Sekunde.
Zwischen „Es läuft“ und „Es ist alltagstauglich“ liegt ein tiefer Graben. Auf der einen Seite steht eine beeindruckende Ingenieursleistung, auf der anderen ein flüssiges Werkzeug für den Alltag.
Die Debatte: Lokale Ausführung vs. Cloud
Das Projekt hat die langjährige Debatte zwischen Verfechtern lokaler KI und Cloud-Anhängern neu entfacht.
- Die Lokal-Fraktion betont Datenschutz, fehlende laufende Gebühren, Offline-Verfügbarkeit und die vollständige Kontrolle über die eigene Infrastruktur.
- Die Cloud-Fraktion verweist auf hohe Geschwindigkeiten (dutzende bis hunderte Tokens/s), den ständigen Zugriff auf die neuesten Modelle und den wegfallenden Wartungsaufwand.
In den Diskussionen auf Hacker News bezweifelten einige Ingenieure, ob die Angabe von 29 GB RAM für ein 2,78T-Modell haltbar sei, da allein die dichten Backbone-Parameter bei nativer Präzision rund 115 GB benötigen. Das Projektteam entgegnete, dass die Kombination aus 3-Bit-MoE-Quantisierung und NVMe-Streaming diese Zahlen rechnerisch ermöglicht.
Solche Diskussionen treiben die Community voran. Die lokale Inferenz hat sich in den letzten Jahren immer wieder gegen Skepsis durchgesetzt – genau durch solche Debatten und Experimente.
Fazit
29 GB RAM bei 0.5 Tokens pro Sekunde bieten noch keinen Ersatz für alltägliche KI-Anwendungen. Betrachtet man die Entwicklung jedoch im historischen Kontext, ist der Fortschritt erstaunlich: Vor zwei Jahren war es eine Sensation, ein Modell mit einigen Milliarden Parametern auf einem PC auszuführen; heute rücken Modelle der Trillionen-Klasse in Reichweite. Mit schnelleren NVMe-SSDs, verfeinerter Quantisierung und effizienteren Architekturen wird sich diese Grenze weiter verschieben.
Für die meisten Anwender bleibt die Kimi-App derzeit der schnellste Weg zu Antworten. Wenn die App das nächste Mal anzeigt „Antwort von der Cloud generiert“, lohnt es sich jedoch kurz innezuhalten und an die gewaltige technische Infrastruktur dahinter zu denken.
Weiterführende Links:
- GitHub: sqliteai/waste Repository
- HN-Diskussion (item?id=49123386)
- Hugging Face: moonshotai/Kimi-K3 Diskussions-Thread #148
- Sebastian Raschka: Kimi K3 Architektur-Notizen
- Unsloth: Kimi K3 Dokumentation zur lokalen Ausführung
- Apidog Blog: Wie man Kimi K3 lokal ausführt
