Kimi K3 im eigenen Rechenzentrum: 2,8 Billionen Parameter selbst hosten

Seit dem 27. Juli 2026 liegen die vollständigen Gewichte von Kimi K3 unter moonshotai/Kimi-K3 auf Hugging Face. Damit ist zum ersten Mal ein Modell mit rund 2,78 Billionen Parametern frei herunterladbar – und die erste Reaktion in den meisten IT-Abteilungen war ein sehr deutsches „Das nehmen wir ins eigene Rack." Diese Reaktion ist richtig motiviert und in der Umsetzung deutlich anspruchsvoller, als die meisten Zusammenfassungen suggerieren.

Denn im Netz kursieren seit dem Release zwei Zahlen, die beide falsch verstanden werden: „594 GB Download" und „8x H100 reichen". Beides führt in der Beschaffung zu teuren Fehlentscheidungen. Dieser Artikel räumt damit auf und liefert stattdessen belastbare Werte: den tatsächlichen Checkpoint-Umfang, die vLLM-Mindestspezifikation, gemessene KV-Cache-Zahlen aus einem 8x-MI355X-System und eine Break-even-Rechnung gegen die Moonshot-API.

Was Kimi K3 technisch ist

Moonshot AI hat Kimi K3 am 16. Juli 2026 angekündigt – zunächst nur als API. Elf Tage später, am 27. Juli 2026, folgten die offenen Gewichte, zusammen mit produktionsreifer Unterstützung für Kimi Delta Attention (KDA) in vLLM. Dass Anbieter und Inferenz-Framework gleichzeitig fertig sind, ist selten und ein starkes Signal: Moonshot hat die KDA-Implementierung selbst zu vLLM beigesteuert, inklusive Kompatibilität zum Prefix-Caching.

Die Architektur in Zahlen

Kimi K3 ist ein Mixture-of-Experts-Modell in der Variante „Stable LatentMoE". Von 2,78 Billionen Gesamtparametern sind pro Token nur rund 104 Milliarden aktiv – das entspricht 16 von 896 Experten. Das Modell ist nativ multimodal, verarbeitet also auch Bilder, und arbeitet mit einem Kontextfenster von 1.048.576 Token.

Der eigentlich interessante Teil steckt im Attention-Stack. Von 93 Layern sind 69 Kimi-Delta-Attention-Layer: lineare Attention mit einem per-channel Forget Gate und einem rekurrenten Zustand konstanter Größe (d_k×d_v). Nur die verbleibenden 24 Gated-MLA-Layer bauen einen mit der Sequenzlänge wachsenden KV-Cache auf. Genau das ist der Grund, warum K3 trotz Millionen-Token-Kontext einen ungewöhnlich kleinen Cache-Footprint hat und Moonshot bis zu 6,3-fach schnelleres Decoding bei sehr langen Kontexten meldet.

MXFP4: Warum 1,56 TB Checkpoint nicht 1,56 TB Betrieb sind

Kimi K3 wurde nativ in MXFP4 veröffentlicht – 4-Bit-Gewichte im Microscaling-Format, kombiniert mit MXFP8-Aktivierungen. Entscheidend ist das Wörtchen „nativ": Die Quantisierung ist nicht nachträglich aufgesetzt, sondern über Quantization-Aware Training ab der SFT-Stufe ins Modell eingebaut. Der Qualitätsabfall gegenüber einer nachträglich heruntergerechneten Variante ist damit erheblich geringer – das ist der wichtigste praktische Unterschied zu den GGUF-Quants, die man sonst aus der lokalen LLM-Szene kennt.

Die 594-GB-Verwechslung

In vielen Zusammenfassungen steht, der native Download sei 594 GB groß. Das ist falsch. 594 GB ist die Größe von Unsloths Community-Quantisierung UD-IQ1_S im GGUF-Format – ein aggressives 1-Bit-Derivat, nicht das offizielle Release. Der offizielle MXFP4-Checkpoint umfasst 1.561.018.243.668 Byte, verteilt auf 96 Safetensors-Dateien. Das sind rund 1,561 TB oder etwa 4,49 gespeicherte Bit pro Parameter – die 4 Bit der Gewichte plus Scales und Metadaten. In BF16 wären es rund 5,6 TB gewesen.

Wer über GGUF-Derivate nachdenkt, sollte die Staffelung kennen:

Variante	Größe auf Disk	Einordnung
Offiziell MXFP4 (Safetensors)	1.561 GB	Referenz, QAT-trainiert
Unsloth UD-Q8_K_XL	1.560 GB	kein Vorteil gegenüber Original
Unsloth UD-Q4_K_XL	1.510 GB	marginale Ersparnis
Unsloth UD-Q2_K_XL	861 GB	spürbarer Qualitätsverlust
Unsloth UD-IQ1_M	649 GB	Experimentierbereich
Unsloth UD-IQ1_S	594 GB	die oft falsch zitierte Zahl

Die Lehre daraus: Zwischen dem offiziellen Checkpoint und einer nennenswerten Ersparnis liegt ein Qualitätssprung nach unten, den man in einer Produktivumgebung nicht leichtfertig eingeht. Wer K3 wegen seiner Leistungsfähigkeit will, betreibt ihn in MXFP4 – alles andere ist ein anderes Modell mit demselben Namen.

Disk-Größe ist nicht Betriebsgröße

Northflank rechnet mit rund 1,4 TB reinen Gewichtsbytes im Betrieb – das ist die theoretische Rechnung mit 0,5 Byte pro Parameter, ohne Scales. Der Checkpoint auf der Platte ist mit 1,561 TB größer, der residente VRAM-Bedarf der Gewichte liegt dazwischen. Auf beides kommen Aktivierungen, Paging-Reserve, CUDA-Graph-Puffer und der KV-Cache. Wer nur die Gewichte plant, plant zu knapp.

GPU-Sizing: Von 8x B300 bis zum Supernode

Hier liegt der zweite verbreitete Irrtum. Die Aussage „8x H100 80 GB sind die praktische Untergrenze" ist physikalisch nicht haltbar: 8x 80 GB ergeben 640 GB aggregiertes HBM, die Gewichte allein brauchen 1,4 bis 1,56 TB. Das Modell passt schlicht nicht hinein. vLLM nennt als Mindestspezifikation rund 1.680 GB VRAM – das ist die Zahl, die in die Beschaffungsunterlage gehört.

Konfiguration	HBM gesamt	Nodes	Bewertung
8x H100 80 GB	640 GB	1	läuft nicht
8x GB300 / B300 / MI355X (288 GB)	2.304 GB	1	kleinste sinnvolle Config
16x H200 (141 GB)	2.256 GB	2	funktioniert, Interconnect kritisch
16x B200 (192 GB)	3.072 GB	2	komfortable Reserve
32x H100 80 GB	2.560 GB	4	Kompatibilitätspfad für Bestandsflotten
Supernode, 64+ Beschleuniger	> 9 TB	mehrere	Moonshot-Empfehlung

Moonshot empfiehlt für Produktionsdeployments explizit Supernode-Konfigurationen mit 64 oder mehr Beschleunigern; die eigene Evaluation lief auf H20-GPUs. Für den deutschen Mittelstand ist das keine realistische Zielgröße – die relevante Frage lautet, ob 8x B300 oder 8x MI355X in einem einzelnen Node ausreichen. Die Antwort ist: ja, für einen definierten Nutzerkreis mit begrenzten Kontextlängen.

Der Interconnect entscheidet über die Praxistauglichkeit

Bei einem MoE-Modell dieser Größe wird über Tensor-Parallelism und Expert-Parallelism verteilt. Beide erzeugen bei jedem Forward-Pass Kollektivoperationen über alle beteiligten GPUs. Innerhalb eines Node übernimmt das NVLink beziehungsweise Infinity Fabric. Sobald eine Node-Grenze überschritten wird, braucht es InfiniBand (NDR/XDR) oder RoCE mit vergleichbaren Latenzen. Ein normales 100-GbE-Ethernet-Fabric ist hier kein Sparpotenzial, sondern ein Betriebsausfall in Zeitlupe: Die GPUs warten, die Auslastung fällt, die Token-Rate bricht ein.

Praktische Konsequenz: Jede zusätzliche Node-Grenze kostet Durchsatz. 32x H100 über vier Nodes funktioniert technisch, ist aber deutlich langsamer als 8x B300 in einem Gehäuse – trotz nominell mehr aggregiertem HBM. Wer neu beschafft, kauft weniger, aber größere Beschleuniger.

KV-Cache bei 1M Kontext richtig budgetieren

Zum KV-Cache von Kimi K3 kursiert eine Zahl von rund 210 GB bei vollem 1M-Kontext. Diese Zahl ist nicht belastbar und widerspricht der Architektur: Nur 24 der 93 Layer bauen überhaupt einen wachsenden Cache auf, die 69 KDA-Layer halten einen Zustand konstanter Größe. Wer mit 210 GB plant, überdimensioniert massiv und trifft womöglich eine falsche Kaufentscheidung.

Belastbar ist stattdessen eine Messung von AMD auf einem 8x-MI355X-System: Dort werden rund 205,4 GiB pro GPU für Gewichte, Zustand und Overhead belegt, wenn eine einzelne Sequenz mit 1 Million Token läuft. Davon entfallen rund 14,4 GiB pro GPU auf den „known state" dieser einen Sequenz. Das ist der Wert, mit dem man rechnen sollte.

Was das für die Nutzerzahl bedeutet

Der KV-Cache wächst linear mit Kontextlänge und Parallelität. Deshalb ist nicht die Nutzerzahl die Planungsgröße, sondern das Produkt aus beidem. Gemessene Werte pro Node:

Kontextlänge	Parallele Requests / Node	Typischer Einsatz
8.000 Token	ca. 600	Chat, Kurzrecherche, Klassifikation
32.000 Token	mittlerer dreistelliger Bereich	RAG mit vielen Chunks, Vertragsprüfung
256.000 Token	niedriger dreistelliger Bereich	Codebase-Analyse, große Aktenbestände
1.048.576 Token	ca. 40	Sonderfall, gezielt freigeben

Der Sprung von 600 auf 40 gleichzeitige Requests bei gleicher Hardware ist die wichtigste Betriebszahl dieses Artikels. Sie bedeutet: Wenn Sie das volle Kontextfenster für alle Nutzer freigeben, sinkt die Kapazität Ihres Node um den Faktor 15. Drei Gegenmaßnahmen haben sich bewährt:

• Kontextlimits pro Rolle: Standardnutzer bekommen 32k, Entwickler 256k, das volle 1M-Fenster wird für benannte Anwendungsfälle freigeschaltet. Das lässt sich im Gateway vor vLLM durchsetzen.
• Prefix-Caching aktivieren: Wiederkehrende System-Prompts, Richtlinientexte und RAG-Präambeln werden nur einmal berechnet. Bei standardisierten Assistenten spart das im Betrieb zweistellige Prozentwerte an Prefill-Zeit.
• Offloading-Tier definieren: Kalte Sessions in Host-RAM oder NVMe auslagern statt HBM zu blockieren. Das kostet Latenz beim Wiederaufwärmen, aber deutlich weniger als ein zusätzlicher Node.

vLLM-Deployment: Kimi Delta Attention in Produktion

Seit dem 27. Juli 2026 ist der Softwarepfad produktionsreif. Moonshot liefert ein dediziertes Container-Image vllm/vllm-openai:kimi-k3 aus. Der typische Start auf einem Single-Node-System mit acht Beschleunigern nutzt --tensor-parallel-size 8 und --enable-prefix-caching. Über mehrere Nodes kommt zusätzlich Expert-Parallelism ins Spiel, dessen Konfiguration eng am Interconnect-Layout hängt.

Ein Detail, das die Latenz spürbar verbessert: K3 bringt Speculative Decoding über ein EAGLE-3-artiges Single-Layer-Draft-Modell mit, das direkt auf Akzeptanzrate trainiert wurde. Wer es abschaltet, verschenkt Durchsatz ohne Gegenwert. Neben vLLM existieren ein SGLang-Cookbook sowie Rezepte von Modal und TokenSpeed – für den Eigenbetrieb im Rack ist vLLM aber der Pfad mit der breitesten Erprobung.

Betriebsdisziplin: Health, Warmup, Rollback

Ein Modell dieser Größe verhält sich betrieblich anders als ein 70B-Modell. Drei Punkte gehören in jedes Runbook:

1. Warmup als Pflichtschritt: Das Laden von 96 Safetensors-Dateien und der Aufbau der CUDA-Graphs dauern Minuten, nicht Sekunden. Ein Node, der als „up" gemeldet wird, bevor der erste synthetische Request durchgelaufen ist, produziert Timeouts beim ersten echten Nutzer.
2. Health-Checks auf Token-Ebene: Ein HTTP-200 auf /health sagt wenig aus. Prüfen Sie zyklisch einen kurzen Generierungsrequest mit fester Erwartung und messen Sie Time-to-First-Token mit.
3. Rollback ohne Downtime: Halten Sie die vorherige Modellversion auf dem lokalen Storage vor. Bei 1,56 TB pro Checkpoint heißt das: mindestens 4 TB schnelles NVMe nur für Modellstände, und einen Rollout, der den alten Node erst abschaltet, wenn der neue Traffic annimmt.

Benchmarks nüchtern gelesen

Kimi K3 erreicht im Artificial Analysis Intelligence Index (v4.1) einen Score von 57. Beim Rang wird es unsauber: Northflank nannte am 17. Juli 2026 „Platz 4 von 189", Artificial Analysis und Wikipedia führten K3 beim Debüt auf Platz 3 hinter Anthropic Claude Fable 5 und OpenAI GPT-5.6 Sol. Ehrlich formuliert heißt das: Top 3 bis 4, je nach Zählweise und Stichtag im Juli 2026. Der Score ist unstrittig, die Platzziffer nicht.

Weitere Werte mit Datumsstempel 17.07.2026: Vals Index 74,70 % (Platz 2 von 38), Vals Terminal-Bench 2.1 80,90 % (Platz 2), Arena WebDev vorläufig 1.679 Elo (Platz 1). Das ist unbestritten Spitzenniveau für ein offen verfügbares Modell.

Wo die Zahlen inzwischen anders aussehen

Bei der Geschwindigkeit hat sich das Bild gedreht. Die vielzitierten 62 Token/s Output und 1,99 Sekunden Time-to-First-Token stammen vom Juli-Snapshot. Im August 2026 misst Artificial Analysis nur noch rund 37,6 Token/s bei 2,78 Sekunden TTFT – K3 wird dort inzwischen explizit als „notably slow" geführt. Wer heute Latenz-SLAs auf den Juli-Werten aufbaut, verspricht etwas, das die aktuelle Messung nicht deckt.

Zwei weitere Eigenheiten gehören in die Bewertung. Erstens ist K3 auffällig geschwätzig: Artificial Analysis maß über die gesamte Evaluation 130 Millionen Token gegenüber einem Median von rund 100 Millionen. Das verteuert die reale Nutzung gegenüber dem nominalen Output-Preis um grob ein Drittel. Zweitens erfordern Multi-Turn-Sessions das Mitführen der Reasoning-History, und mehrere Reviews beschreiben das Modell als „excessively proactive" – es tut mehr, als man verlangt hat. In agentischen Setups ist das ein Risiko, das man mit engen Tool-Berechtigungen einfangen muss.

Lizenz und Herkunft prüfen, bevor Sie kaufen

Die Lizenz heißt offiziell „Kimi K3 License" (Moonshot AI, 2026). Sie ist MIT-abgeleitet, aber ein eigener Text – die verbreitete Bezeichnung „Modified MIT" ist eine Verkürzung, und eine OSI-anerkannte Open-Source-Lizenz ist es nicht. Zwei skalenabhängige Schwellen sind relevant:

• Model-as-a-Service über 20 Mio. USD Umsatz in beliebigen zwölf aufeinanderfolgenden Monaten erfordert eine separate kommerzielle Vereinbarung mit Moonshot.
• Kommerzielle Produkte mit über 100 Mio. monatlich aktiven Nutzern oder über 20 Mio. USD Monatsumsatz müssen „Kimi K3" prominent im User Interface ausweisen.

Interne Nutzung sowie der Zugriff über offizielle Moonshot-Produkte und zertifizierte Partner sind ausgenommen. Für den deutschen Mittelstand heißt das praktisch: uneingeschränkt nutzbar. Trotzdem gehört der Lizenztext einmal vor den Rollout auf den Tisch der Rechtsabteilung – schon weil „nicht OSI-Open-Source" in Ausschreibungen und Lieferantenfragebögen eine Rolle spielen kann.

Governance jenseits der Lizenz

Kimi K3 kommt aus China. Beim Eigenbetrieb ist das datenschutzrechtlich unkritisch – die Gewichte sind eine statische Datei, es fließt kein Byte zurück. Genau das ist der zentrale Vorteil von Open-Weight-Modellen gegenüber einer API: Der Betrieb auf eigener Hardware macht die Herkunft der Gewichte weitgehend zur Nebensache, weil keine Verarbeitung in einem Drittland stattfindet. Zwei Vorsichtsmaßnahmen bleiben:

• Lokale Gewichtskopie mit Prüfsumme. Ziehen Sie den Checkpoint einmal, sichern Sie ihn intern und dokumentieren Sie die Hashes. Sollte das Repository verschwinden, die Lizenz sich ändern oder eine Exportkontrolle greifen, bleibt Ihre Installation lauffähig.
• Eigene Sicherheitsevaluation. Prüfen Sie das Modellverhalten auf Ihren Anwendungsfällen selbst, insbesondere bei politisch oder regulatorisch sensiblen Themen. Die Trainingsdaten kennen Sie nicht – das Verhalten können Sie messen.

Rechnet sich das gegen die API?

Die Moonshot-API kostet 3,00 USD je 1 Mio. Input-Token bei Cache-Miss, 0,30 USD je 1 Mio. Input-Token bei Cache-Hit und 15,00 USD je 1 Mio. Output-Token. Artificial Analysis rechnet daraus einen Blended-Preis von 2,31 USD je 1 Mio. Token, unter der Annahme eines Verhältnisses von 7:2:1 zwischen Cache-Hit, frischem Input und Output.

Dem stehen Hardwarekosten gegenüber. Am Mietmarkt lagen die Preise im Juli 2026 bei rund 59 bis 142 USD pro Stunde für einen 8x-B300/GB300-Node, 64 bis 160 USD für 16x H200 und rund 38 USD pro Stunde beziehungsweise etwa 27.800 USD monatlich für einen reservierten 8x-MI350X-Node.

Die Formel, die den Vergleich fair macht

Listenpreise sind nicht vergleichbar, solange die Auslastung fehlt. Rechnen Sie stattdessen so:

DigitalOcean schätzt den Break-even auf rund 40 dauerhaft aktive Heavy-User mit je 50 Mio. Token pro Monat aufwärts. Für einen einzelnen Nutzer ist die API etwa 40-mal günstiger als eine gemietete GPU. Diese Spanne beschreibt das eigentliche Entscheidungsproblem: Self-Hosting von K3 lohnt sich rechnerisch erst bei erheblichem, gleichmäßigem Volumen.

Was in dieser Rechnung fehlt, ist genau das, was für viele Mittelständler den Ausschlag gibt: Kein Datenabfluss an einen Drittstaat, keine Abhängigkeit von der Verfügbarkeit und Preisgestaltung eines ausländischen Anbieters, volle Kontrolle über Modellversionen und keine Vertragsanpassung, wenn der Anbieter seine Nutzungsbedingungen ändert. Diese Faktoren tauchen in keiner USD-pro-Token-Formel auf, entscheiden aber regelmäßig über die Genehmigungsfähigkeit eines Projekts. Wer beide Seiten strukturiert gegeneinanderstellen will, findet im TCO-Rechner Cloud vs. On-Premise das passende Werkzeug.

Die pragmatische Empfehlung

Für die allermeisten mittelständischen Anwendungsfälle ist Kimi K3 im Eigenbetrieb überdimensioniert. Ein Modell im Bereich 100 bis 400 Mrd. Parameter läuft auf zwei bis acht Beschleunigern, deckt RAG, Dokumentenanalyse und Assistenzfunktionen sauber ab und kostet einen Bruchteil. K3 wird dort interessant, wo Sie tatsächlich das Spitzenniveau brauchen – agentische Softwareentwicklung, sehr lange Kontexte, multimodale Aufgaben – und wo das Volumen die Hardware auslastet. Der ehrlichste erste Schritt ist deshalb: über die API evaluieren, mit eigenen Aufgaben messen, und erst danach über ein Rack entscheiden. Unsere On-Premise-KI-Server lassen sich passend zum tatsächlich gemessenen Bedarf auslegen – nicht zum Datenblatt.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primaerquellen geprüft.

1. Hugging Face Kimi K3
2. Hugging Face LICENSE
3. Hugging Face Kimi K3 GGUF
4. marktechpost.com moonshot ai releases kimi k3 a 2 8 trillion parameter open moe model with kimi d
5. northflank.com what is kimi k3 self hosting
6. runpod.io kimi k3 technical faq
7. digitalocean.com self hosting kimi k3
8. kingy.ai run kimi k3 locally hardware vram cost
9. artificialanalysis.ai kimi k3
10. en.wikipedia.org Kimi (chatbot
11. openmodelmap.com hardware

Häufig gestellte Fragen zu Kimi K3

Kann ich Kimi K3 auf einer einzelnen GPU betreiben?

Nein. Selbst im nativen MXFP4-Format belegen allein die Gewichte rund 1,4 bis 1,56 TB; vLLM nennt als Mindestspezifikation etwa 1.680 GB VRAM. Die kleinste sinnvolle Konfiguration sind acht Beschleuniger mit je 288 GB HBM, also 8x GB300, B300 oder MI355X. Moonshot selbst empfiehlt Supernodes mit 64 oder mehr Beschleunigern.

Was bedeutet MXFP4 für die Qualität?

Kimi K3 wurde nativ in MXFP4 mit MXFP8-Aktivierungen veröffentlicht, ist also nicht nachträglich heruntergerechnet. Der Qualitätsverlust gegenüber einer höheren Präzision ist deutlich geringer als bei nachträglicher Quantisierung.

Darf ich Kimi K3 kommerziell einsetzen?

Ja. Die offizielle „Kimi K3 License" ist MIT-abgeleitet, aber ein eigener Text mit skalenabhängigen Schwellen: Model-as-a-Service über 20 Mio. USD Umsatz in zwölf Monaten erfordert eine separate Vereinbarung mit Moonshot, Produkte über 100 Mio. monatlich aktive Nutzer oder 20 Mio. USD Monatsumsatz müssen „Kimi K3" im UI ausweisen. Für den Mittelstand ist das praktisch unkritisch – eine OSI-Open-Source-Lizenz ist es aber nicht.

Lohnt sich Self-Hosting gegenüber der API?

Bei hoher, gleichmäßiger Auslastung ja, bei sporadischer Nutzung nicht. Entscheidend sind Token-Volumen und GPU-Auslastung – dazu kommen nicht bepreisbare Faktoren wie Datenschutz und Jurisdiktion.