Kimi K3 vLLM-Abnahme für den Produktivbetrieb

Kimi K3 vLLM ist erst dann produktionsbereit, wenn die Kompatibilitätskette, die Ressourcenreserven, das tatsächlich wirksame prefix caching und die Agent-Schnittstellen unter realistischer Last nachgewiesen sind. Ein erfolgreicher Prozessstart oder eine einzelne korrekte Antwort reicht nicht aus; nur wenn alle vier Prüfbereiche bestanden sind, sollte die Umgebung freigegeben werden.

Für wen diese Abnahme gedacht ist: Für Ingenieure, die eine bereits laufende Kimi-K3-vLLM-Umgebung aus dem Test in den Produktivbetrieb überführen. Für SREs und Plattformverantwortliche, die eine belastbare Go-/No-Go-Entscheidung unterschreiben müssen. Und für technische Entscheider, die zwischen Neuaufbau, kurzfristiger Kapazitätserweiterung und einer extern bereitgestellten GPU-Umgebung wählen.

Letzte Aktualisierung: 13.08.2026. Die Angaben wurden gegen die offizielle Kimi-K3-Recipe, den vLLM-Releasebeitrag, die vLLM-Produktionsmetriken und die NVIDIA-CUDA-Kompatibilitätsdokumentation geprüft.

Die vier möglichen Abnahmeergebnisse

Die Kimi K3 vLLM-Abnahme sollte nicht mit einem einzigen grünen Status enden. Eine produktionsnahe Prüfung muss zeigen, welcher Teil bestanden wurde und welche Einschränkung noch besteht.

Ein laufender Prozess beweist nur, dass Initialisierung, Gewichte und ein Teil der CUDA-Kette funktioniert haben. Er beweist weder ausreichende Speichermargen noch korrektes Tool Calling. Gerade bei Agent-Anwendungen kann eine kurze Chat-Anfrage problemlos durchlaufen, während ein längerer System-Prompt mit Tool-Schema und mehreren Schleifen später scheitert.

Die Tests sollten deshalb mit einem festen Beispielsatz ausgeführt werden. Dazu gehören ein langer System-Prompt, wiederkehrende Tool-Definitionen, mindestens ein mehrstufiger Dialog, strukturierte Ausgabe und ein Fehlerfall. Ein kurzer Prompt erzeugt sonst eine zu optimistische Einschätzung.

Abnahmeregel: Jede Freigabe braucht einen Testfall, einen Messwert, einen Logauszug und einen benannten Prüfer. „Server antwortet“ ist ein Testresultat, aber kein Produktionsurteil.

Kompatibilität: CUDA 13 und NVIDIA R580 getrennt verifizieren

Die offizielle Kimi-K3-Recipe führt die Lösung derzeit als „Pre-release“. Sie verlangt das spezielle Docker-Image vllm/vllm-openai:kimi-k3. Dieses Image ist laut Recipe ausschließlich als CUDA-13-Build vorgesehen; ein CUDA-12.9-Tag wird dort nicht angeboten. Für den Host wird ein NVIDIA-Treiber der R580-Serie oder neuer genannt. Die Recipe nennt außerdem mindestens acht GB300-GPUs für den NVIDIA-Pfad; reale Produktionslast wird als Multi-Node-Szenario beschrieben. Maßgeblich ist die offizielle Kimi-K3-Recipe.

NVIDIA bestätigt unabhängig davon, dass CUDA 13.x mindestens einen R580-Treiber benötigt. Die CUDA-Kompatibilitätsmatrix von NVIDIA weist für CUDA 13.x „>= 580“ aus. Die CUDA-13-Release-Notes nennen für CUDA 13.0 GA unter Linux mindestens Version 580.65.06 und erklären die Kompatibilität innerhalb der 13.x-Reihe.

Eine einzelne nvidia-smi-Anzeige genügt nicht. Dieses Werkzeug zeigt die vom Treiber unterstützte maximale CUDA-Version; daraus lässt sich nicht automatisch ableiten, welche CUDA-Laufzeit im Container tatsächlich verwendet wird. Deshalb müssen Hostinformationen, Containerinformationen und Startlog gemeinsam gespeichert werden.

Erste Stufe: Die Versionskette als reproduzierbaren Datensatz speichern

1. Image-Tag und Image-Digest exportieren.
2. Die vLLM-Version aus Image-Metadaten oder Startlog sichern.
3. Auf jedem Host den vollständigen NVIDIA-Treibereintrag speichern.
4. Aus dem Container die sichtbaren GPUs und die CUDA-Laufzeit auslesen.
5. Startparameter inklusive --tensor-parallel-size, Backend-Optionen und Cache-Flag archivieren.
6. Den ersten erfolgreichen Startlog zusammen mit Datum und Node-Zuordnung ablegen.

Wenn der Cluster auf CUDA 12.9, R575 oder einem eigenen K3-Build basiert, darf das Ergebnis nicht als gleichwertig zur offiziellen Docker-Recipe markiert werden. Ein selbst gebauter Pfad kann technisch sinnvoll sein, braucht aber einen eigenen Prüfstatus, eine gesperrte Abhängigkeitsliste und einen getesteten Rollback. Bei einem nicht passenden Treiber ist zuerst die Umgebung zu korrigieren. Weiteres Experimentieren mit einzelnen vLLM-Flags verschiebt das Problem nur.

Kapazität: OOM in eine belastbare Ressourcenentscheidung übersetzen

Kimi K3 ist laut vLLM ein multimodales MoE-Modell mit 2,8 Billionen Parametern, 16 aktiven Experten aus 896 Experten pro Token und einem möglichen Kontextfenster von bis zu 1 Million Token. Diese Werte beschreiben die Modellarchitektur, aber keine universelle GPU-Mindestgröße für jede Last. Der offizielle vLLM-Beitrag zu Kimi K3 beschreibt für den NVIDIA-Pfad acht B300-GPUs beziehungsweise eine passende GB300-NVL72-Umgebung; für Produktionsverkehr werden meist mehrere Nodes mit RDMA oder NVLink eingesetzt.

Deshalb sollte keine allgemeine Aussage wie „so viel Speicher braucht K3 immer“ in ein Abnahmeformular übernommen werden. Entscheidend sind Modellformat, Kontextlänge, Parallelismus, Bildanteile, gleichzeitige Requests, KV- beziehungsweise Hybrid-Cache-Nutzung und die Verbindung zwischen den Nodes.

Ein brauchbarer Belastungstest besteht aus vier Phasen:

1. Modellstart: Gewichte laden, Initialisierung abschließen und den stabilen Grundverbrauch aufzeichnen.
2. Langer Eingang: Einen realistischen System-Prompt, Tool-Schemas und längere Dialoghistorien senden.
3. Parallelbetrieb: Die erwartete Anzahl gleichzeitiger Agent-Anfragen schrittweise anlegen.
4. Dauerlauf: Den Test lange genug ausführen, um Queueing, Cache-Wachstum und wiederkehrende Speicherfreigaben zu beobachten.

Zu jedem OOM gehören mindestens:

• GPU-Speicherverlauf vor und nach dem Fehler,
• betroffene Node und GPU,
• Eingabelänge und Ausgabelimit,
• aktive Parallelität,
• max-model-len und relevante Cache-Einstellungen,
• vLLM- und CUDA-Log,
• Zeitpunkt des letzten erfolgreichen Requests,
• Warteschlangen- und Preemption-Metriken.

Die vLLM-Produktionsmetriken stellen dafür unter anderem kv_cache_usage_perc, num_requests_running, num_requests_waiting, num_preemptions und die End-to-End-Latenz bereit. Die aktuelle Metrikreferenz von vLLM sollte bei der Einrichtung des Dashboards als Namensquelle verwendet werden.

Die Diagnose lässt sich in drei Gruppen teilen:

• Start-OOM: Die Gewichte oder Initialisierungsstrukturen passen nicht in die vorgesehene Topologie. Das ist ein Umgebungs- oder Kapazitätsproblem vor dem Traffic.
• Last-OOM: Der Start gelingt, aber Kontext, Concurrency oder Cache verdrängen den verfügbaren Speicher. Hier müssen Lastgrenzen oder Ressourcen angepasst werden.
• Topologie-OOM: Einzelne GPUs oder Nodes werden ungleich belastet, Kommunikation und Cache-Transfer erzeugen zusätzlichen Druck. Dann ist eine andere Parallelismus- oder Interconnect-Strategie nötig.

Ein OOM unter dem vorgesehenen Produktionsprofil ist kein Grund für eine vorsichtige Freigabe. Wenn nur ein absichtlich überhöhter Testfall scheitert, muss diese Grenze dokumentiert und durch Rate-Limits oder Eingabebeschränkungen erzwungen werden. Wenn der Fehler bei der erwarteten Last auftritt, folgt keine Freigabe, sondern eine Anpassung von Kontext, Concurrency, Cache oder Topologie.

Cache-Nachweis: Aktivierung ist nicht gleich Wiederverwendung

Bei Kimi K3 muss prefix caching derzeit explizit mit --enable-prefix-caching aktiviert werden. Der offizielle vLLM-Beitrag erklärt, dass die Funktion bei Kimi K3 nicht standardmäßig eingeschaltet ist, obwohl sie bei vLLM typischerweise aktiviert sein kann. Der Beitrag beschreibt außerdem den hybriden Cache aus Full-Attention-KV und rekurrentem KDA-Zustand.

Ein Startlog mit dem Flag ist jedoch nur der erste Nachweis. Für die Abnahme braucht es einen kontrollierten Vergleich:

1. Cache deaktivieren oder eine frische Instanz verwenden.
2. Einen kalten Request mit festem System-Prompt und Tool-Schema senden.
3. Einen zweiten Request mit identischem Präfix und nur leicht verändertem Nutzerteil senden.
4. Mehrere warme Requests mit derselben Struktur wiederholen.
5. Einen Kontrollrequest mit verändertem System-Prompt ausführen.
6. Metriken und Latenz für kalte, warme und Kontrollrequests getrennt speichern.

Die relevanten vLLM-Metriken heißen vllm:prefix_cache_hits, vllm:prefix_cache_queries und vllm:prompt_tokens_cached. Zusätzlich sind vllm:prompt_tokens_recomputed, vllm:kv_cache_usage_perc und die Request-Latenzen relevant.

Als bestanden gilt der Cache-Test nicht wegen eines einzelnen positiven Counters. Er gilt als bestanden, wenn:

• die Cache-Abfragen ansteigen,
• Treffer in der passenden Größenordnung des wiederholten Präfixes erscheinen,
• prompt_tokens_cached zunimmt,
• warme Requests ein nachvollziehbar anderes Prefill-Verhalten zeigen,
• der Kontrollrequest mit verändertem Präfix nicht fälschlich als Treffer gezählt wird.

Erfahrung aus der Abnahme: Wechselnde Tool-Reihenfolge, dynamische Zeitstempel, zufällige Request-IDs und veränderte Systemtexte machen Cache-Tests unbrauchbar. Der gemeinsame Teil des Prompts muss byte- beziehungsweise tokenstabil bleiben.

Die Besonderheit von Kimi K3 liegt darin, dass vLLM sowohl Full-Attention-KV als auch rekurrente KDA-Zustände berücksichtigen muss. Ein niedriger Cache-Trefferwert ist daher nicht automatisch ein Softwarefehler; er kann durch abweichende Prompt-Strukturen, zu wenige Wiederholungen oder eine ungeeignete Cache-Auslastung entstehen. Genau deshalb gehören kalte und warme Resultate in dasselbe Prüfprotokoll.

Schnittstelle: Agent-Tools separat von GPU-Problemen prüfen

Ein Kimi-K3-Produktionsdienst kann technisch gesund sein und trotzdem für einen Agent-Client unbrauchbar antworten. Die offizielle Recipe weist darauf hin, dass K3 gelegentlich ein Tool-Call-Format erzeugen kann, das der eigene Parser nicht erwartet. Die empfohlene Kimi-K3-Dokumentation im vLLM-Recipe sollte deshalb neben dem Modelltest auch für die Parser- und Fallback-Prüfung herangezogen werden.

Der Schnittstellentest sollte mindestens diese Fälle enthalten:

• einfacher Text-Request,
• Tool-Call mit einem Pflichtargument,
• mehrere verfügbare Tools,
• mehrstufiger Dialog nach einem Tool-Ergebnis,
• strukturierte Ausgabe mit ungültigem und gültigem Schema,
• leerer oder unvollständiger tool_calls-Block,
• Timeout und Wiederholungsfall,
• Streaming, falls der Produktivclient Streaming verwendet.

Zu prüfen sind nicht nur der HTTP-Status und der Antworttext. Das Abnahmeformular sollte auch tool_calls, Argumenttypen, Reasoning-Felder, Finish-Reason, strukturierte Ausgabe und die Reaktion des Gateways erfassen. Ein Parserfehler im Gateway ist anders zu behandeln als ein Modell, das einen formal falschen Tool-Call erzeugt.

Die Tests sollten wiederholt werden. Ein einmal korrekt erzeugter Tool-Call beweist keine stabile Agent-Funktion. Wenn ein Fehler nur bei bestimmten Prompts auftritt, wird der betreffende Prompt als reproduzierbarer Regressionstest gespeichert. Für kritische Werkzeuge braucht es zusätzlich eine serverseitige Schema-Prüfung und einen definierten Rückfall, etwa eine erneute Anfrage mit strengerem Format oder eine kontrollierte Fehlermeldung an den Agenten.

Für datenschutzrelevante Agent-Daten gehören außerdem Protokollierungsumfang, Aufbewahrung und Zugriffskontrolle in die Abnahme. ProxyMac-Kunden sollten die Datenschutzinformationen von ProxyMac mit der eigenen Logging- und Weiterleitungsarchitektur abgleichen. Die technische Korrektheit eines Tool-Calls ersetzt keine Prüfung der Datenflüsse.

Abnahmeprotokoll zum Abhaken

Die folgende Liste ist als unterschriftsfähiges Arbeitsblatt gedacht. Jede Markierung braucht einen Beleg im Ticket, Dashboard oder Artefakt-Repository.

• [ ] Offizielle Kimi-K3-Recipe und ihr Aktualisierungsdatum wurden geprüft.
• [ ] Verwendetes Docker-Image, Digest und vLLM-Version sind gespeichert.
• [ ] CUDA-13-Laufzeit im Container wurde separat vom Host geprüft.
• [ ] Jeder Host stellt mindestens die geforderte R580-Treiberfamilie bereit.
• [ ] Container sehen die vorgesehenen GPUs und keine unerwarteten Fallback-Geräte.
• [ ] Startlogs zeigen keine relevanten CUDA-, NCCL- oder Runtime-Fehler.
• [ ] Modellstart wurde ohne Traffic und mit dokumentiertem Grundverbrauch abgeschlossen.
• [ ] Langer System-Prompt, Tool-Schema und Mehrfachdialog wurden getestet.
• [ ] Erwartete Parallelität wurde schrittweise und nicht nur mit einem Einzelrequest geprüft.
• [ ] OOM-Vorfälle wurden mit Speicherverlauf, Requestparametern und Node-Zuordnung dokumentiert.
• [ ] --enable-prefix-caching ist im tatsächlich verwendeten Startbefehl enthalten.
• [ ] Kalte, warme und absichtlich veränderte Präfixe wurden verglichen.
• [ ] Prefix-Cache-Zähler und gecachte Prompt-Tokens wurden ausgelesen.
• [ ] Tool-Calls wurden gegen das produktive Schema validiert.
• [ ] Leere, ungültige oder verspätete Tool-Calls haben einen getesteten Fallback.
• [ ] Rückfallbedingungen, Rate-Limits und Rollback-Verantwortliche sind benannt.
• [ ] Eine zweite Person hat die Messwerte und Logs geprüft.
• [ ] Das Ergebnis lautet eindeutig: Freigabe, Beobachtung, Neuaufbau oder Erweiterung.

Die ProxyMac-Hilfe ist für die organisatorische Abstimmung nützlich, wenn die technische Abnahme auf eine temporär benötigte GPU-Umgebung oder eine andere Bereitstellungsform verschoben werden muss. Für laufende Umgebungen sollten Zuständigkeiten, Zugriff und Zugangsdaten außerdem über die ProxyMac-Konsole getrennt verwaltet werden.

Nach dem Go-live: Überwachung und Rückfall

Nach der Freigabe sollten zunächst nicht nur Fehlerraten, sondern auch die Ursachenketten beobachtet werden. Relevant sind laufende und wartende Requests, End-to-End-Latenz, Inter-Token-Latenz, KV-Cache-Auslastung, Preemptions, Prefix-Cache-Treffer, gecachte Prompt-Tokens und erfolgreiche Requests.

Ein Rollback wird ausgelöst, wenn mindestens eines dieser Ereignisse eintritt:

• wiederholter OOM unter der freigegebenen Last,
• anhaltendes Queue-Wachstum trotz unveränderter Request-Rate,
• Treiber- oder NCCL-Fehler nach einem Node- oder Image-Update,
• Cache-Treffer fallen unter die dokumentierte Testbasis und Prefill-Latenz steigt,
• Tool-Call-Fehler erreichen kritische Agent-Flows,
• Antworten erfüllen das vereinbarte Struktur- oder Schemaformat nicht mehr.

Die Änderungshistorie muss Image-Digest, Treiber, Startparameter, Topologie und Cache-Flag gemeinsam erfassen. Ein Rollback nur auf Anwendungsebene kann wirkungslos bleiben, wenn die eigentliche Änderung aus dem Host-Treiber oder dem Container stammt.

ProxyMac als Option für temporäre Kapazität

Die Entscheidung nach der Abnahme ist nicht immer „selbst betreiben oder aufgeben“. Ein eigener Cluster ist sinnvoll, wenn die Last dauerhaft planbar ist, die GPU-Topologie bereits vorhanden ist und das Team Treiber, Container, Monitoring und Ersatzkapazität selbst verantwortet. Für kurze Validierungsfenster, Release-Spitzen oder eine kontrollierte Produktionsprobe kann diese Bindung jedoch unnötig teuer und langsam sein: Hardware muss verfügbar sein, Treiber müssen zur CUDA-Kette passen und ein Fehler in der Umgebung blockiert den gesamten Zeitplan.

Wenn der aktuelle Ansatz auf einem zu kleinen Einzelknoten, einer alten Treiberfamilie oder einer nicht passenden Interconnect-Struktur beruht, sollte nicht weiter an zufälligen Parametern gearbeitet werden. Nach Abschluss der Checkliste kann der technische Verantwortliche Treiberversion, Containerinformationen, Lastprofil und OOM-Verlauf an ProxyMac übergeben und prüfen, ob ein temporärer Rebuild, zusätzliche Kapazität oder eine andere Topologie besser passt. ProxyMac sollte dabei nicht als pauschale Performance-Garantie betrachtet werden; entscheidend bleiben die dokumentierten Testbedingungen und die eigene Agent-Last.

Für eine kurzfristige Abnahmeumgebung ist die bessere Wahl daher diejenige, die dieselbe Kompatibilitätskette reproduzierbar bereitstellt und den späteren Rollback nicht erschwert. Erst wenn CUDA 13, NVIDIA R580, Ressourcenverhalten, prefix caching und Tool-Schnittstelle gemeinsam belegt sind, gehört Kimi K3 vLLM in den Produktivbetrieb.

FAQ