So führen Sie Kimi K3 lokal aus: Hardware-, Speicher- und Bereitstellungsgrenzen

Running the full Kimi K3 locally is possible with released weights, but practical deployment still requires cluster-scale memory, accelerators, and interconnects.

After the July 27 open-weight release, the question is no longer whether a checkpoint exists, but whether your system can download, load, and serve it at useful speed. The public repository is about 1.56 TB across 96 safetensor shards, while the model contains 2.8 trillion total parameters and activates 104 billion per token. Those numbers keep a normal PC, Mac, home NAS, or single-GPU server outside the practical full-model range, so the sections below separate storage, memory, accelerator topology, runtime support, and realistic fallback paths.

What Is Available Now That Kimi K3 Weights Are Released?

Die Kimi K3 Open-Weight-Veröffentlichung enthält den vollständigen Modell-Checkpoint und den technischen Bericht. Das öffentliche Modell-Repository zeigt derzeit etwa 1,56 TB an Dateien und 96 nummerierte Safetensor-Shards. Diese Zahl ist nützlich zur Planung von Downloads und Festplattenkapazität, stellt aber keine Mindestanforderung an den VRAM dar.

Die veröffentlichte Modellzusammenfassung bestätigt 2,8 Billionen Gesamtparameter, 104 Milliarden aktivierte Parameter, 93 Schichten, 69 Kimi Delta Attention-Schichten und 24 Gated MLA-Schichten. Das Stable LatentMoE-Routing wählt pro Token 16 von 896 gerouteten Experten aus und verwendet außerdem zwei gemeinsame Experten. Die Gewichte sind MXFP4, die Aktivierungen MXFP8, und der angegebene maximale Kontext beträgt 1.048.576 Tokens.

Die Unterstützung für die Bereitstellung ist auch konkreter als vor der Veröffentlichung. vLLM, SGLang und TokenSpeed werden als empfohlene Inferenz-Engines aufgeführt, aber jede erfordert K3-kompatible Kernel, Modellcode, Sharding und Speichereinstellungen. Ein generischer Befehl, der von einer Client-Bibliothek angezeigt wird, verwandelt den Checkpoint nicht in ein lokal nutzbares Modell für Endverbraucher.

Warum benötigt Sparse MoE trotzdem enormen Speicher?

Kimi K3 führt Berechnungen mit 104 Milliarden aktivierten Parametern für jeden Token durch, aber alle MoE-Experten verbrauchen weiterhin Speicher und Servicememory. Der Router kann für den nächsten Token unterschiedliche Experten auswählen, daher muss der vollständige 2,8T-Gewichtssatz irgendwo in der Bereitstellung zugänglich bleiben.

Die Auswahl von 16 aus 896 gerouteten Experten reduziert die Expertenarbeit für einen Token. Das bedeutet nicht, dass eine Maschine nur 16 Experten behalten, den Rest verwerfen und das veröffentlichte Modell unverändert ausführen kann. Experten-Pruning, Distillation oder Streaming würden einen anderen Betriebskompromiss schaffen und dürfen nicht mit normaler sparsamer Aktivierung verwechselt werden.

Die Zahl von 104 Milliarden aktivierten Parametern ist daher eine Beschreibung des Berechnungsumfangs und keine Abkürzung zur Schätzung der Checkpoint-Größe. Die Multiplikation von 104 Milliarden mit vier Bits und die Behauptung, das Modell benötige nur etwa 52 GB, würde inaktive, aber dennoch erforderliche Expertengewichte, dichte Komponenten, geteilte Experten, Aufmerksamkeits-Schichten, Vision-Gewichte und Laufzeitzustände ignorieren.

Was ist die minimale Gewichtsspeicheruntergrenze?

Bei 2,8 Billionen Parametern ist die einfachste untere Schranke die Gesamtzahl der Parameter multipliziert mit den gespeicherten Bits pro Parameter. MXFP4 gibt eine Vier-Bit-Nutzlastuntergrenze vor: 2,8T × 4 Bits sind etwa 1,4 TB oder ungefähr 1,27 TiB nur für die rohe Gewichtsnutzlast.

Das veröffentlichte Repository ist etwa 1,56 TB groß, was zeigt, warum der Serving-Speicher über eine einfache Gewicht-Berechnung hinausgeht. Checkpoint-Verpackung, Blockskalen, Tensor-Ausrichtung, Konfigurationsdateien, Tokenizer-Assets, Vision-Komponenten und andere Modelldaten treiben den tatsächlichen Download über die theoretische Vier-Bit-Untergrenze hinaus.

Vier verschiedene Budgets müssen separat geplant werden: persistenter Download-Speicher, temporärer Staging-Speicher, Host-RAM und Accelerator-HBM oder VRAM. Ein laufender Dienst benötigt dann zusätzlichen Platz für KDA-Zustand, MLA-KV-Cache, Aktivierungen, Kommunikationspuffer, Kerne, Graph-Capture und Ausfallsicherheitsspielraum. Die 1,56 TB Repository-Größe ist daher weder eine vollständige RAM-Anforderung noch eine vollständige GPU-Speicheranforderung.

Welche Hardware kann Kimi K3 tatsächlich lokal ausführen?

Es gibt keine ehrliche Liste von minimalen GPU-Anforderungen für Verbraucher für das vollständige Modell. Ein System, das technisch den Checkpoint abbilden oder streamen kann, ist nicht automatisch in der Lage, stabil und interaktiv zu dienen. Praktische Kimi K3 Hardwareanforderungen hängen von Gewichtsspeicherung, unterstützten MXFP4-Kernen, Interconnect-Bandbreite, Cache-Kapazität, Kontextlänge, Parallelität und der Serving-Engine ab.

Veröffentlichte day-zero Kimi K3 Serving-Unterstützung setzt die realistische Startklasse bei einem Enterprise-Knoten mit acht Beschleunigern an. Aktuelle vLLM-Materialien beschreiben acht GB300-Klasse- oder MI350X/MI355X-Klasse-Beschleuniger als Ausgangspunkte, während SGLang topologie-bewusste Beispiele wie B300 1×8, GB300 2×4, B200 2×8, H200 2×8, H100 4×8 und MI350X/MI355X 1×8 veröffentlicht.

Dies sind veröffentlichte Laufzeitrezepte und Startkonfigurationen, nicht ein einzelnes zertifiziertes Minimum für jede Arbeitslast. Ältere oder kleinere Beschleuniger können mehr Knoten, andere Quantisierungskerne, reduzierten Kontext oder zusätzlichen Experten-Parallelismus erfordern. Produktionsverkehr benötigt außerdem Kapazität für gleichzeitige Anfragen, ausgefallene Worker und Leistungsspielraum, nicht nur das einmalige Laden des Checkpoints.

Warum ist ein einzelner Arbeitsplatz oder NAS immer noch die falsche Topologie?

Die reine Kapazitätsaufteilung unterschätzt das Problem. Selbst wenn genügend Gesamtspeicher vorhanden ist, verwandelt Expertenparallelismus das Routing in Netzwerkverkehr. Tokens müssen die Beschleuniger erreichen, die ihre ausgewählten Experten halten, und dann zurück zum Rest der Modellpipeline.

Enterprise-Beschleunigerknoten bieten mehr als nur Speicher. Sie kombinieren Hochgeschwindigkeits-GPU-Verbindungen, RDMA-fähiges Networking, kollektive Kommunikationsbibliotheken und Kernel, die für Tensor-, Experten-, Daten- oder Pipeline-Parallelismus ausgelegt sind. Eine Sammlung von Consumer-GPUs, die über gewöhnliches PCIe oder ein Heimnetzwerk verbunden sind, kann zwar nominal genug Kapazität zeigen, ist aber für nützlichen Betrieb oft zu langsam oder zu instabil.

Ein NAS ist wertvoll zum Speichern von Checkpoint-Shards, Protokollen, Datensätzen, Abrufindizes und Anwendungsdaten, aber Netzwerkspeicher ersetzt nicht die Speicherbandbreite des Beschleunigers. Die bessere Rolle eines Heimservers besteht meist darin, private Daten und Abrufe nahe beim Nutzer zu halten, während die Inferenz von Frontier-Modellen einem geeigneten Cluster oder gehosteten Endpunkt überlassen wird. In diesem Design trennt ein Heimserver die lokale Datenschicht von der Frontier-Inferenz.

Wie erhöhen KDA-Zustand, MLA-KV-Cache und Kontextlänge das Budget?

Kimi K3 verwendet keinen einheitlichen Vollaufmerksamkeits-Cache über alle 93 Schichten hinweg. Seine 69 KDA-Schichten und 24 Gated-MLA-Schichten erzeugen zwei unterschiedliche Anforderungen an den Servierspeicher: einen KDA-Zustandspool mit fester Modellgeometrie für zugelassene Anfragen und einen paginierten MLA-KV-Pool, der mit gespeicherten Tokens wächst.

Diese Aufteilung bedeutet, dass KDA das Wachstum des Langzeitkontexts, das bei herkömmlicher Aufmerksamkeit auftritt, reduzieren kann, aber sie macht eine Anfrage mit einer Million Tokens nicht kostenlos. Da KDA-Zustand und MLA-KV-Speicher um die Kapazität des Beschleunigers konkurrieren, kann die KDA-Seite die zugelassenen Anfragen begrenzen, während die MLA-Seite die insgesamt zwischengespeicherten Tokens limitiert.

Batch-Größe, Parallelität, durchschnittliche Prompt-Länge, generierte Begründungslänge, multimodale Eingaben, Cache-Präzision und Vorbefüll-/Decodierstrategie verändern alle die nutzbare Kapazität. Die 1-Million-Token-Zahl ist eine maximale Modellkapazität, kein empfohlener Standardwert. Eine erste Bereitstellung sollte mit einem kürzeren maximalen Kontext, Batch-Größe eins und niedriger Parallelität beginnen, bevor Out-of-Memory-Fehler, Vorbefüllzeit, Decodiergeschwindigkeit und Knoten-übergreifender Verkehr gemessen werden.

Wie können Sie Kimi K3 nach der Veröffentlichung der offenen Gewichte lokal ausführen?

Kimi K3 lokal auszuführen bedeutet jetzt, einen verteilten Inferenzdienst um den veröffentlichten Checkpoint herum aufzubauen, nicht eine normale Desktop-Anwendung zu installieren. Die sicherste Vorgehensweise ist, Speicher, Laufzeitunterstützung, Topologie und einen kleinen Betriebspunkt zu validieren, bevor Kontext oder Verkehr erhöht werden.

1. Bereiten Sie den Speicher vor. Reservieren Sie mindestens den etwa 1,56 TB großen Repository-Fußabdruck plus zusätzlichen Platz für Teildownloads, Caches, Container-Images, Protokolle und temporäre Dateien.
2. Wählen Sie eine unterstützte Engine. Verwenden Sie einen Kimi K3-spezifischen vLLM-, SGLang- oder TokenSpeed-Bereitstellungspfad mit dem erforderlichen Modellcode, den Kernen und der Container- oder Branch-Version.
3. Passen Sie die Topologie an. Wählen Sie ein Enterprise-Multi-GPU- oder Multi-Node-Layout mit ausreichend HBM und dem NVLink-, MNNVL- oder RDMA-Pfad, der von den Tensor- und Experten-Parallel-Einstellungen erwartet wird.
4. Starten Sie unterhalb der Überschriftenlimits. Reduzieren Sie maximale Modelllänge, Batch-Größe und Parallelität, und überprüfen Sie dann Laden, OOM-Verhalten, Ausgabe-Korrektheit, Vorbefüllgeschwindigkeit, Decodiergeschwindigkeit und All-to-All-Verkehr.
5. Skalieren Sie nur nach Messung. Fügen Sie Kontext, gleichzeitige Anfragen, Cache-Funktionen, multimodale Eingaben oder spekulatives Decoding jeweils eine Variable nach der anderen hinzu.

Ein Befehl wie vllm serve oder sglang serve beschreibt, wie man eine kompatible verteilte Laufzeit startet; es beseitigt nicht die Hardwareanforderung. Wenn die erforderliche Beschleunigerklasse nicht verfügbar ist, sind die realistischen Optionen eine gehostete API, eine hybride Architektur, die Dateien und Abruf lokal hält, oder ein kleineres lokales Modell, das in den tatsächlichen Speicher- und Zuverlässigkeitsrahmen des Heimservers passt.

FAQ

Kann ich Kimi K3 lokal auf einem normalen PC, Mac oder Heim-NAS ausführen?

Nicht mit praktischer Vollmodellgeschwindigkeit. Das Repository umfasst etwa 1,56 TB vor Overhead für den Dienst, während ein normales lokales System auch nicht über den Beschleunigerspeicher und die Hochgeschwindigkeits-Topologie verfügt, die von aktuellen Laufzeitumgebungen erwartet werden. Experimentelles Experten-Streaming oder starke Auslagerung könnten technisch einen Start ermöglichen, sind aber nicht gleichbedeutend mit reaktionsschnellem oder produktionsreifem Betrieb.

Wie viel Speicher und Arbeitsspeicher benötigt Kimi K3?

Die transparente MXFP4-Gewichtslast-Untergrenze liegt bei etwa 1,4 TB, während das öffentliche Repository etwa 1,56 TB umfasst. Zusätzlich benötigen Sie extra Festplattenspeicher, Host-RAM, Accelerator-HBM oder VRAM, KDA-Zustand, MLA-KV-Cache, Aktivierungen, Kommunikationsarbeitsbereich und Betriebsspielraum. Es gibt keine einzelne Zahl, die all diese Schichten repräsentiert.

Was ist die minimal veröffentlichte GPU-Konfiguration für Kimi K3?

Die kleinsten veröffentlichten Day-Zero-Konfigurationen sind Enterprise-Beschleunigerknoten mit acht Karten, wobei die aktuellen vLLM- und SGLang-Pfade auf Hardware der Klassen B300, GB300 oder MI350X/MI355X ausgerichtet sind. Betrachten Sie diese als Startpunkte für die Laufzeit, nicht als universelle garantierte Mindestanforderung; Kontext, Parallelität, Engine-Version und Produktionsziele können mehr Ressourcen erfordern.

Kann Kimi K3 von SSD- oder NAS-Auslagerung laufen?

SSD- oder NAS-Speicher können Checkpoint-Segmente halten, und experimentelle Laufzeiten können Gewichte über den Host-Speicher streamen. Das begrenzende Problem ist die wiederholte Bewegung von Expertengewichten und Zuständen durch Speicher, Netzwerk, RAM und PCIe-Verbindungen. Diese Pfade sind viel langsamer als Accelerator-HBM und Hochgeschwindigkeits-GPU-Netzwerke, sodass ein experimenteller Start unbrauchbare Latenzzeiten liefern kann.

Läuft das vollständige Kimi K3-Modell lokal bei Ollama?

Der aktuelle Ollama Kimi K3-Eintrag verwendet das kimi-k3:cloud-Tag. Das Ausführen eines lokalen Ollama-Clients bedeutet nicht, dass der 1,56 TB große Checkpoint auf der lokalen Maschine geladen ist; der angegebene Pfad ist cloud-gestützt.

Fazit

Kimi K3 ist jetzt tatsächlich als Open-Weight-Modell verfügbar, sodass Clusterbetreiber den kompletten Checkpoint herunterladen und bereitstellen können, anstatt sich auf Vorab-Schätzungen zu verlassen. Die Veröffentlichung ändert die Verifizierungs- und Tool-Verfügbarkeit, aber nicht die physische Größe eines 2,8T-Parameter-Modells.

Die nützlichsten Speicherzahlen von Kimi K3 beantworten unterschiedliche Fragen: Etwa 1,4 TB sind die transparente Vier-Bit-Gewichtsuntergrenze, etwa 1,56 TB ist der aktuelle Repository-Fußabdruck, und 104B ist die aktivierte Rechenkapazität pro Token. Keine dieser Zahlen allein beschreibt den gesamten Speicherbedarf für einen laufenden Dienst.

Für die meisten Einzelpersonen und Heimserver-Nutzer ist die Grenze klar: Ohne einen Enterprise-Knoten mit acht Beschleunigern oder einen verteilten Cluster sollte man gehostete Inferenz verwenden, die privaten Daten und die Abrufschicht lokal halten oder ein kleineres Modell wählen. Das ist der praktische Weg, um von Kimi K3 zu profitieren, ohne ein NAS, eine Workstation oder eine einzelne GPU als Superknoten für Grenzmodelle zu behandeln.