Kimi K2 lokal: 1 Trillion Parameter MoE bei soi

#Warum Kimi K2 lokal nutzen?

Kimi K2 ist das Flaggschiffmodell von Moonshot AI. Es wurde mit offenen Gewichten unter der Lizenz Modified MIT veröffentlicht und nutzt eine MoE-Architektur (Mixture of Experts) mit insgesamt 1 Billion Parametern, von denen pro Token etwa 32B aktiv sind. In Reasoning- und Code-Benchmarks spielt es in der Liga der leistungsführenden geschlossenen Modelle. Sein langer Kontext von angekündigten 128k Tokens macht es zu einem ernst zu nehmenden Kandidaten für die Analyse großer Dokumentmengen.

Ein Modell dieser Größe lokal auszuführen, war vor 18 Monaten noch eine Wunschvorstellung. Drei Entwicklungen haben die Lage verändert: die breite Verfügbarkeit von DDR5-Speicher mit hoher Kapazität (192–384 GB für einige Hundert Euro), NVMe-Gen-4-SSDs mit einer sequenziellen Lesegeschwindigkeit von 7 GB/s und die Arbeit des llama.cpp-Teams an sehr aggressiven Quantisierungen wie Q2_K_S und IQ1_M.

#MoE mit 1T Parametern / 32B aktiven Parametern verstehen

Die MoE-Architektur ersetzt die dichten FFN-Schichten durch eine Schicht von Experten (häufig 256+), aus denen ein Router pro Token 8 bis 12 auswählt. Bei der Berechnung werden nur die Parameter der ausgewählten Experten verarbeitet — daher die ~32B « aktiven » Parameter. Im Gegensatz dazu müssen alle Experten im Speicher adressierbar sein, sonst verliert der Router den Zugriff auf 95 % des Modells.

Gesamtparameter

≈ 1.000 Milliarden (1T). So viele sind im RAM oder auf dem Datenträger gespeichert.

Aktive Parameter pro Token

Etwa 32 Milliarden. Dies bestimmt den Rechenaufwand und die Geschwindigkeit.

Experten pro Schicht

Hunderte, wobei eine feste Anzahl pro Token (top-k Routing) routiert wird.

Gemeinsam genutzte Schichten (Attention)

Immer aktiv. Bei kurzen Kontexten machen sie den größten Teil des Speicherbedarfs aus.

KV-Cache

Wächst linear mit dem Kontext. Bei 128k kann der KV-Cache selbst quantisiert mehr als 30 GB belegen.

#Einzuplanender Speicherbedarf

Die Berechnung des Speicherbedarfs für ein MoE-Modell mit 1T Parametern gliedert sich in drei getrennte Posten. Diese Aufteilung zu verstehen, ist entscheidend, bevor Sie in RAM oder eine SSD investieren.

Modellgewichte (quantisiert)

Q2_K_S ≈ 245 GB, Q3_K_S ≈ 320 GB, Q4_K_M ≈ 480 GB, Q8_0 ≈ 1 TB. Dies ist der größte und am stärksten komprimierbare Anteil des Speicherbedarfs.

KV-Cache (Kontext)

Mit etwa 0,25 MB pro Token in FP16 und etwa 0,12 MB in Q8 rechnen. Das entspricht 32 GB für 128k Tokens in Q8. Über --cache-type-k/-v konfigurierbar.

Aktivierungspuffer

Einige GB pro GPU für Zwischenergebnisse. Klein, aber nicht zu vernachlässigen bei GPUs mit 24 GB.

#Hardware-Voraussetzungen

Drei Maschinenkonfigurationen ermöglichen es, Kimi K2 lokal zu betreiben, jeweils mit sehr unterschiedlichen Kompromissen bei der Geschwindigkeit.

Profil A — leistungsstarke DDR5-Konfiguration (192–384 GB RAM)

Workstation mit Threadripper/Xeon W oder EPYC-Plattform. 256 GB DDR5 ECC, keine GPU erforderlich. Das Modell passt in Q2_K_S vollständig in den RAM. Erwartete Geschwindigkeit: 4–8 tok/s bei reinem CPU-Betrieb.

Profil B — DDR5 + 1 GPU mit 24 GB

96–128 GB RAM + RTX 4090/3090. Die gemeinsam genutzten Schichten werden auf die GPU ausgelagert, die Experten bleiben im RAM. Erwartete Geschwindigkeit: 6–12 Tokens/s, abhängig davon, wie viele Experten in den VRAM passen.

Profil C — wenig RAM + NVMe-SSD

64–96 GB RAM + NVMe Gen 4 (7 GB/s Lesegeschwindigkeit, ≥ 1 TB frei). Die Gewichte werden per mmap von der SSD eingebunden. Erwartete Geschwindigkeit: 1–3 tok/s, stark abhängig vom tatsächlichen SSD-Durchsatz.

#1. llama.cpp mit dem richtigen Backend kompilieren

Kimi K2 benötigt eine aktuelle Version von llama.cpp (einen aktuellen Build aus der Zeit nach Dezember 2025), die seine MoE-Architektur und IQ-Quantisierungen unterstützt. Wir kompilieren aus dem offiziellen Repository.

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON -DGGML_CUDA_FA_ALL_QUANTS=ON
cmake --build build --config Release -j

Auf einem Mac mit Apple Silicon GGML_CUDA durch GGML_METAL ersetzen. Auf AMD mit ROCm GGML_HIP verwenden. Das Flag GGML_CUDA_FA_ALL_QUANTS aktiviert Flash Attention für alle Quantisierungen – unverzichtbar, damit 128k Kontext in den VRAM passen, ohne dessen Kapazität zu überschreiten.

#2. Die GGUF-Quantisierung wählen

Für ein Modell dieser Größe können Sie Q4_K_M und höhere Quantisierungen vergessen, es sei denn, Sie haben 512 GB RAM. Extreme Quantisierung — Q2_K_S, IQ2_XXS oder sogar IQ1_M — macht den lokalen Betrieb praktikabel, allerdings mit einem messbaren Qualitätsverlust, der bei einem MoE oft akzeptabel ist.

Q2_K_S (~245 GB)

Der optimale Kompromiss. Etwa 5 % Leistungseinbuße bei Code-Benchmarks, etwa 3 % beim logischen Schlussfolgern. Empfohlen, wenn Sie 256 GB RAM oder eine schnelle SSD haben.

IQ2_XXS (~210 GB)

Noch aggressiver mithilfe einer Importance-Matrix. Passt in 192 GB RAM, wenn ein kleiner Teil ausgelagert wird. Die Qualität liegt eine Stufe darunter.

IQ1_M (~155 GB)

Hybride 1-Bit-Quantisierung. Für Konfigurationen mit sehr knappen Ressourcen. Spürbarer Qualitätsverlust, aber das Modell bleibt kohärent.

Q3_K_S (~320 GB)

Qualität fast auf Q4-Niveau, benötigt aber 384 GB RAM. Für gut ausgestattete EPYC-Workstations.

pip install -U "huggingface_hub[cli]"
huggingface-cli download \
  unsloth/Kimi-K2-Instruct-GGUF \
  --include "*Q2_K_S*" \
  --local-dir ./models/kimi-k2-q2ks

Die GGUF-Dateien dieser Größe werden in mehrere Dateien aufgeteilt (z. B. split-00001-of-00007.gguf usw.). llama.cpp erkennt automatisch die Aufteilungen, wenn Sie auf die erste Datei verweisen.

#3. Kimi K2 mit mmap und Offload starten

Der grundlegende Befehl verwendet llama-server, den von llama.cpp bereitgestellten HTTP-Server. Er bietet standardmäßig einen OpenAI-kompatiblen Endpoint auf dem Port 8080 an.

./build/bin/llama-server \
  --model ./models/kimi-k2-q2ks/kimi-k2-Q2_K_S-00001-of-00007.gguf \
  --ctx-size 32768 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --threads 16 \
  --no-mmap=false \
  --host 0.0.0.0 --port 8080

Mit einer GPU mit 24 GB werden die gemeinsam genutzten Schichten (Attention) auf die GPU ausgelagert, während die MoE-Experten im RAM oder auf einer SSD bleiben. Mit dem Flag -ot lässt sich gezielt festlegen, was auf der GPU und was auf der CPU liegt.

./build/bin/llama-server \
  --model ./models/kimi-k2-q2ks/kimi-k2-Q2_K_S-00001-of-00007.gguf \
  --ctx-size 65536 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --n-gpu-layers 999 \
  -ot "\.ffn_.*_exps\.=CPU" \
  --threads 12 \
  --host 0.0.0.0 --port 8080

Der an -ot übergebene reguläre Ausdruck bedeutet: „Alle FFN-Schichten der Experten (der Großteil des MoE-Modells) bleiben auf der CPU bzw. im RAM, der Rest kommt auf die GPU.“ Dieser Kniff macht den hybriden Betrieb praktikabel: Man nutzt die GPU für die Attention-Berechnungen, ohne das gesamte Modell darauf laden zu müssen.

#4. Tatsächlich gemessene Tokens pro Sekunde

Hier sind einige in der Praxis beobachtete Durchsatzwerte zur Orientierung. Die Zahlen variieren je nach Prompt (das Prefill ist langsam, die Generierung ist stabiler) und dem Zustand des Seitencaches des Betriebssystems.

EPYC 9354P, 384 GB DDR5, Q2_K_S, vollständig im RAM

Prefill ~80 Tok/s, Generierung ~6–8 Tok/s. Referenzkonfiguration für Reasoning im Batchbetrieb.

Threadripper 7960X, 256 GB DDR5, Q2_K_S

Prefill ~50 Tok/s, Generierung ~4-6 Tok/s. Die Speicherlatenz von DDR5 dominiert.

Ryzen 9 7950X, 128 GB DDR5 + SSD NVMe Gen 4

Prefill ~15 tok/s, Generierung ~1,5–3 tok/s. Die SSD wird zum begrenzenden Faktor, sobald die Datenmenge nicht mehr vollständig im RAM gehalten werden kann.

Mac Studio M2 Ultra 192 GB

Generierung mit ~4–7 Tokens/s in IQ2_XXS. Die Bandbreite des Unified Memory (800 GB/s) hilft bei MoE-Modellen enorm.

Workstation mit 256 GB + RTX 4090 (hybrid)

Prefill ~60 tok/s, Generierung ~7-10 tok/s. Der GPU-basierte Attention-Mechanismus halbiert die Prefill-Zeit.

#5. Anwendungsfälle mit 128k Kontext

Die große Stärke von Kimi K2 gegenüber lokalen 7B- bis 70B-Modellen ist das Kontextfenster von 128k Tokens. Konkret können Sie ihm einen vollständigen Jahresbericht, eine mittelgroße Codebasis oder rund hundert PDF-Seiten geben und eine umfassende Zusammenfassung anfordern, die das Ganze berücksichtigt – statt RAG mit einzelnen Chunks.

Zusammenfassung langer Dokumente

Ein 300-seitiger Bericht kommt mit weniger als 120.000 Tokens aus. Kimi K2 erstellt in einem einzigen Durchlauf eine strukturierte Zusammenfassung, während ein RAG einzelne Teile mosaikartig zusammensetzen würde.

Refactoring einer Codebasis

50 Python-Dateien (~80.000 Tokens) laden und eine konsistente Architekturprüfung anfordern. Sehr nützlich bei technischen Schulden, die mehrere Bereiche betreffen.

Korrelierte Loganalyse

50 MB Logs (nach dem Filtern) einfügen und eine Chronologie des Vorfalls anfordern. Das Modell sieht alle Korrelationen, nicht nur gleitende Fenster.

Übersetzung großer Dokumente

Bewahrt die terminologische Konsistenz über ein ganzes Buch hinweg, während eine Übersetzung in einzelnen Abschnitten den roten Faden verliert.

#Fehlerbehebung

„failed to load model“ oder Fehler bei der Magic Number

Ihr llama.cpp ist für dieses GGUF zu alt. Aktualisieren Sie auf einen Build von nach Dezember 2025 und überprüfen Sie die vom GGUF-Repackager angegebene Architekturversion.

Generierung mit 0,2 tok/s, obwohl der RAM ausreichen würde

Der Kernel lädt Speicherseiten aus der GGUF-Datei nach, solange er noch nicht auf alle Seiten zugegriffen hat. Ein erster „Aufwärmlauf“ mit einem kurzen Prompt lädt die häufig genutzten Seiten vor. Andernfalls erhöhen Sie --threads, um die Bandbreite früher vollständig auszunutzen.

Plötzlicher OOM-Fehler bei einem langen Prompt

Der KV-Cache ist enorm angewachsen. Reduzieren Sie --ctx-size auf 32768 oder aktivieren Sie die Q8-Quantisierung des Caches. Der KV-Cache wächst linear mit dem Kontext, nicht mit der Modellgröße.

Inkohärente Ausgabe oder fehlerhafte Sprache

Häufig liegt es an einer falschen Chat-Vorlage. Prüfen Sie --chat-template oder stellen Sie sicher, dass die GGUF-Datei die offizielle Moonshot-Vorlage (jinja) enthält. Ein falsches Endtoken führt dazu, dass die Ausgabe in einer Schleife entgleist.

SSD bei 80 °C, Durchsatz bricht ein

High-End-NVMe-SSDs drosseln ihre Leistung ohne Kühlkörper. Bringen Sie bei längeren Sitzungen einen Kühlkörper an oder reduzieren Sie die Last, indem Sie zu einer kleineren quantisierten Version wechseln, die in den RAM passt.

#Weiterführende Informationen

Kimi K2 im lokalen Betrieb ist eine Spielwiese für sehr große Modelle. Drei Ansätze, um noch weiterzugehen:

Den Build von llama.cpp beherrschen

Die Anleitung „llama.cpp mit CUDA kompilieren“ erläutert die weniger offensichtlichen Flags (Tensor-Offload, MMQ, Flash Attention), die die Leistung bei diesem Modelltyp beeinflussen.

Quantisierungen verstehen

Der Leitfaden „Die Wahl der Quantisierung“ vermittelt die konzeptionellen Grundlagen, die vor einer eingehenden Beschäftigung mit IQ2_XXS oder Q3_K_S hilfreich sind, und erklärt, was sich tatsächlich verschlechtert.

Die Kompression weiter erhöhen

Der TurboQuant-Leitfaden erläutert eine neuere Methode als K-quants, mit der sich Frontier-Modelle auf handelsüblicher Hardware unterbringen lassen, allerdings mit anderen Kompromissen.