Kimi K3 zu Hause: die Wahrheit über die erforderliche Hardware (2,8 T Parameter)

#Kimi K3 lokal: genau das, was Moonshot tatsächlich veröffentlicht hat

Die Hugging-Face-Modellseite von Moonshot beschreibt Kimi K3 als ein multimodales Modell mit offenen Gewichten und 2,8 Billionen Parametern sowie einem Kontextfenster von einer Million Tokens. Es handelt sich um ein Mixture-of-Experts-Modell: 896 Experten, von denen für jedes Token 16 ausgewählt werden, wodurch 104 Milliarden Parameter aktiviert werden. Die Gewichte werden in MXFP4 (Gewichte) mit MXFP8-Aktivierungen bereitgestellt; quantisierungsbewusstes Training wurde bereits in der Phase des überwachten Fine-Tunings angewendet. Der Code und die Gewichte unterliegen der „Kimi K3 License“: Lesen Sie diesen Text vor jeder kommerziellen Nutzung, denn es handelt sich nicht um eine übliche MIT- oder Apache-Lizenz. Laut Fachpresse erschien das Modell um den 27. Juli 2026 auf Hugging Face.

Gesamte Parameter / aktive Parameter

2,8 T insgesamt, 104 Md aktive Token pro Token (Fiche Moonshot).

Experten

896 Experten, 16 pro Token ausgewählt, plus 2 gemeinsame Experten

Veröffentlichtes Format

MXFP4 für die Gewichte, MXFP8 für die Aktivierungen. Das ist kein GGUF.

Kontext

1.048.576 Tokens, mit einem KV-Cache, dessen Speicherbedarf zum Speicherbedarf der Modellgewichte hinzukommt.

Empfohlene Inferenz-Engines

vLLM, SGLang und TokenSpeed. llama.cpp nutzt die GGUF-Community-Dateien.

#Was die Gewichte wirklich wiegen

Zwei Zahlen kursieren, die man unterscheiden muss. Einige Artikel schätzen die Größe auf „etwa 1,4 TB“, indem sie 2,8 Billionen Parameter mit einem halben Byte multiplizieren. Die gemessene Dateigröße liegt höher: Unsloth und Runpod geben für die native Version 1,56 TB an, weil die Schichten außerhalb der Experten (Attention, Router, gemeinsam genutzte Experten) in höherer Präzision bleiben. Die nicht quantisierte BF16-Version würde laut Runpod etwa 5,6 TB erreichen. Die Version dieses Leitfadens, die 1,4 TB angab, lag somit um etwa 10 % zu niedrig.

Die Tabelle widerlegt eine verbreitete Annahme aus der vorherigen Version: Ein Q2 liegt nicht „immer in der Größenordnung eines Terabytes“. Unsloth bietet tatsächlich GGUF-Dateien unter 900 GB an. Doch 594 GB sind immer noch fast das Fünfzehnfache des Speichers einer RTX 5090 mit 32 GB, und der Qualitätsunterschied ist real: Die dynamische 1-Bit-Quantisierung reproduziert die Entscheidung des ursprünglichen Modells im Testdatensatz von Unsloth nur in 78,9 % der Fälle. Wie sich die Bits auf die Qualität auswirken, erfahren Sie in unserem Leitfaden zur Quantisierung.

#Die Hardware: Was empfohlen wird, was möglich ist

Moonshot veröffentlicht auf der Modellseite keine Mindestkonfiguration: Dort wird auf die Anleitungen für vLLM, SGLang und TokenSpeed sowie auf die eigene API verwiesen. Die dokumentierte Referenz für natives Self-Hosting stammt von Runpod: ein Knoten mit acht B300-GPUs mit jeweils 288 GB, also insgesamt etwa 2,3 TB, oder sechzehn B200-GPUs verteilt auf zwei Knoten. Die Angabe „64 Beschleuniger oder mehr“, die diese Seite zuvor übernommen hatte, findet sich in keiner der konsultierten Primärquellen: Sie wird entfernt.

Bei einer GGUF-Datei von Unsloth ist die in deren Dokumentation genannte Regel einfach: RAM und VRAM müssen zusammen ungefähr der Größe der quantisierten Datei entsprechen. Andernfalls läuft das Modell zwar, weicht aber auf den Datenträger aus und wird deutlich langsamer. Unsloth nennt außerdem etwa 20 Tokens pro Sekunde bei der Generierung, wenn das Modell in den Speicher von B200-Beschleunigern passt. Das ist eine vom Anbieter genannte Generierungsrate auf Rechenzentrumshardware, keine auf einen Heimrechner übertragbare Messung.

#Und auf einem Mac? Berechnungen statt Gerüchte

Für die Angabe „16 Sekunden pro Token auf einem MacBook Pro M1 Max“, über die diese Seite berichtete, ließ sich keine überprüfbare Quelle finden: Wir geben sie daher nicht als Tatsache wieder. Was die Quellen belegen, ist klarer. Kingy AI weist darauf hin, dass bereits der Ausgangspunkt (ein Checkpoint von 1,56 TB) die Speicherkapazität eines Mac Studio mit 512 GB überstieg und dass selbst die 553,2 GiB große Datei der 1-Bit-Version die Kapazität dieses Rechners schon ohne zusätzlichen Speicherbedarf übersteigt. Ein Mac mit 128 GB verfügt über ungefähr ein Fünftel der empfohlenen 610 GB.

Die Größenordnung lässt sich hingegen selbst abschätzen. Wenn der Arbeitsspeicher nicht ausreicht, werden für jeden Token die Experten, die er aktiviert, erneut von der SSD gelesen: 104 Milliarden Parameter mit etwa 4 Bit, also ungefähr 50 GB, die pro Token gelesen werden. Mit einer SSD, die 3 GB/s liefert, ergibt das etwa 17 Sekunden pro Token; bei 7 GB/s etwa 7 Sekunden. Das ist eine theoretische Berechnung einer Obergrenze, keine Messung, erklärt aber, warum Erfahrungsberichte zur Ausführung „von der Festplatte“ Zeiten in Sekunden pro Token nennen und nicht in Tokens pro Sekunde.

#Ollama, LM Studio, llama.cpp: Was jedes Tool ermöglicht

Ollama

Die offizielle Bibliothek führt nur eine Variante auf, kimi-k3:cloud: Das Modell läuft auf den Servern von Ollama, nicht auf Ihrem Rechner. Mit dem Befehl ollama run kimi-k3:cloud können Sie das Modell über die gewohnte Oberfläche ausprobieren, wobei die Einschränkungen eines entfernten Dienstes hinsichtlich Datenschutz und Abrechnung gelten.

LM Studio

Es lädt lokale GGUF-Dateien. Für K3 setzt das voraus, mehrere Hundert GB an Unsloth-Dateien herunterzuladen und über die entsprechende Speicherkapazität zu verfügen. Auf einem Rechner für Endkunden lautet die Antwort nein.

llama.cpp

Dies ist die Engine, für die die GGUF-Dateien von Unsloth vorgesehen sind. Diese setzen auf einen Fork von llama.cpp mit Unterstützung für Bildverarbeitung. Die Engine unterstützt das Auslagern der Experten auf die CPU und mehrteilige Dateien: Das ist der realistische Weg für eine Workstation mit mehreren Hundert GB RAM.

vLLM und SGLang

Die beiden von Moonshot empfohlenen Engines für einen Multi-GPU-Dienst mit dem nativen Format.

#Realistische Optionen zum Testen von Kimi K3

1. 01
   1. Die offizielle Moonshot-API

   Auf platform.kimi.ai heißt das Modell kimi-k3 und bietet eine mit OpenAI und Anthropic kompatible API. Das ist der schnellste Weg, die Qualität zu beurteilen. Der Parameter reasoning_effort lässt sich auf low, high oder max einstellen.
2. 02
   2. Ollama Cloud

   ollama run kimi-k3:cloud utilise vos habitudes Ollama avec l'inférence déportée. La page de la bibliothèque affiche les tarifs par million de tokens : vérifiez-les avant d'automatiser. Notre guide sur Ollama Cloud détaille les limites.
3. 03
   3. Eine GPU-Miete

   Für die Dauer eines Tests einen Multi-GPU-Knoten mit vLLM stundenweise mieten. Berechnen Sie zunächst die Wirtschaftlichkeit (Stundenkosten geteilt durch die dauerhaft erreichten Tokens pro Sekunde), wie Runpod es in seiner FAQ beschreibt.
4. 04
   4. Eine Workstation mit viel RAM

   Nur wenn Sie bereits 700 GB Arbeitsspeicher haben: GGUF UD-IQ1_S und llama.cpp, wobei Sie eine geringere Qualität und einen niedrigen Durchsatz in Kauf nehmen müssen.

#Offene Gewichte bedeuten nicht, dass man das Modell lokal ausführen kann

Offene Modellgewichte garantieren das Recht, sie herunterzuladen, zu prüfen, feinzujustieren und, je nach Lizenz, weiterzuverbreiten. Sie garantieren nicht, dass jemand die Modelle auch ausführen kann. Ein Modell mit 30 Milliarden Parametern auf einer Grafikkarte mit 24 GB gehört Ihnen tatsächlich; ein 2,8T-Modell, das nur ein Cluster laden kann, bleibt in der Praxis ein Dienst. Kimi K3 ist eine gute Nachricht für die Prüfbarkeit und für Organisationen, die bereits einen Cluster haben, ohne zu verändern, was eine Privatperson zu Hause tun kann.

#Alternativen, die Ihre Hardware tatsächlich laden kann

Der QuelLLM-Katalog schätzt den Speicherbedarf in Q4, ohne Kontext: DeepSeek V4 Flash 284B etwa 170 GB, GLM 5.2 753B-A40B etwa 437 GB, Kimi K3 etwa 1.624 GB. Für den täglichen Gebrauch bleibt ein Modell mit 30 bis 70 Milliarden Parametern in Q4 der beste Kompromiss zwischen Qualität und Machbarkeit.

DeepSeek V4 Flash 284B

Etwa 170 GB in Q4 laut Katalog: möglich auf einem Mac Studio mit viel Arbeitsspeicher oder einer Workstation. Siehe den entsprechenden Leitfaden.

GLM 5.2 753B-A40B

Etwa 437 GB in Q4: Das ist das Modell, das K3 in seiner Größenordnung am nächsten kommt und noch auf einer gut ausgestatteten Workstation betrieben werden kann.

Kimi K2.5 und K2.7

Etwa 600 GB in Q4: kleiner als K3, aber weiterhin auf Infrastruktur einer Workstation angewiesen.

Modelle mit 30 bis 70 Milliarden Parametern

Auf einer Karte mit 24 bis 32 GB oder einem Mac mit 64 GB: sinnvoller Ansatz für realen Einsatz. Der VRAM-Rechner liefert die genaue Zahl.

#Urteil: Kimi K3 lokal, fast nie

Modellgewichte im Originalformat von 1,56 TB, Quantisierungen von 594 bis 861 GB, 610 GB Speicher für die kleinste Variante: Kimi K3 ist ein Servermodell. Um es zu evaluieren, verwenden Sie die API oder kimi-k3:cloud. Für den tatsächlichen Einsatz zu Hause wählen Sie ein Modell, das in Ihren verfügbaren Speicher passt und noch Spielraum für den Kontext lässt.

#Weiterführende Informationen

• DeepSeek V4 Flash 284B: das erste Frontier-Modell auf dem Mac Studio
• GLM-5.2 lokal: Ollama und LM Studio
• Quantisierung wählen (Q4, Q5, Q8, FP16)
• MoE erklärt: Warum ein 30B-A3B wie ein kleines Modell läuft
• Ollama Cloud: Preise, Bewertungen und Beschränkungen
• VRAM-Rechner

• Quelle: Hugging-Face-Modellkarte von Kimi K3
• Quelle: Unsloth, Kimi K3 lokal
• Quelle: technische FAQ von Runpod
• Quelle: Ollama-Bibliothek, kimi-k3