Kimi-K2-Thinking: Wie viel VRAM wird benötigt?

Diese Seite wurde automatisch von einer KI geschrieben und übersetzt und von Software anhand ihrer Quellen geprüft, ohne menschliche Bearbeitung. Die Spezifikationen stammen aus den angegebenen Quellen; Speicherbedarf und Geschwindigkeiten sind Schätzungen, die mit veröffentlichten Formeln berechnet wurden. Wie wir KI nutzen

Kimi-K2-Thinking ist ein Mixture-of-Experts-Modell mit 1,03T Parametern, von denen etwa 31,7B pro Token aktiv sind (das Nachschlagen der Eingabe-Embeddings nicht mitgezählt). Bei Q4_K_M und einem Kontext von 8.192 Tokens benötigt eine einzelne GPU 610,3 GiB verfügbaren Speicher, damit das Ergebnis „passt“ lautet.

Werte aktualisiert am 19. Okt. 2026

Wichtige Fakten

GGUF-Dateien und benötigter Speicher

Alle Quantisierungen stammen aus einem GGUF-Repository in einer festgelegten Revision: unsloth/Kimi-K2-Thinking-GGUF@7e4f5d4

Kleinste GPU für jede Quantisierung

GPUs, die Kimi-K2-Thinking ausführen können

„Passt“ bedeutet: Die standardmäßige --fit-Ladeprüfung von llama.cpp würde alle Layer auf der GPU platzieren. Unsere Schätzung der Puffer von llama.cpp, plus deren Fehlermarge, plus die Reserve von 1 GiB pro Karte bei llama.cpp liegt innerhalb des als verfügbar gezählten Speichers. Es ist keine Zusage, dass der Spitzenspeicherbedarf während der Generierung passt. Wie Ergebnisse bestimmt werden

Das Modell passt auf keine einzelne GPU-Karte in der Datenbank.

GPUs, auf die es nicht auf eine Karte passt

• CUDA (NVIDIA): llama.cpp, CUDA-Backend (dedizierte NVIDIA-GPU), alle Layer auf der GPU, Flash Attention an, Micro-Batch (-ub) 512, F16-KV-cache, Kontextlänge (-c) wie angezeigt; „Passt“ wird mit den 4 parallelen Sequenzen beurteilt, die llama-server standardmäßig nutzt (-np auto, einheitlicher KV-Cache), „Passt nicht“ mit 1 Sequenz; unbelastete GPU, ohne andere Programme, die ihren Speicher nutzen.
• ROCm unter Linux (AMD): llama.cpp, ROCm-Backend unter Linux (dedizierte AMD-GPU), alle Layer auf der GPU, Flash Attention an, Micro-Batch (-ub) 512, F16-KV-cache, Kontextlänge (-c) wie angezeigt; „Passt“ wird mit den 4 parallelen Sequenzen beurteilt, die llama-server standardmäßig nutzt (-np auto, einheitlicher KV-Cache), „Passt nicht“ mit 1 Sequenz; unbelastete GPU, ohne andere Programme, die ihren Speicher nutzen.

Die Geschwindigkeitsobergrenze ergibt sich aus der Speicherbandbreite geteilt durch die pro erzeugtem Token gelesenen Bytes. Sie ist eine theoretische Obergrenze; öffentliche llama.cpp-Benchmarks erreichen typischerweise etwa die Hälfte bis vier Fünftel davon, kleine Modelle und Mixture-of-Experts-Modelle oft weniger. Öffentliche Benchmarks

Originalgewichte

Die originalen Gewichtsdateien des Modells (safetensors, gezählt wie in der Methodik beschrieben) umfassen insgesamt 553,4 GiB. Sie werden nur zur Referenz aufgeführt; jede Schätzung auf dieser Seite bezieht sich auf die oben genannten GGUF-Dateien, ausgeführt mit llama.cpp. moonshotai/Kimi-K2-Thinking · Methodik

Quellen

• Hugging Face: moonshotai/Kimi-K2-Thinking@a51ccc0
• Hugging Face (GGUF): unsloth/Kimi-K2-Thinking-GGUF@7e4f5d4
• Methodik (llama.cpp 5aeac37a)