Kimi K3 vLLM-Startfehler: Treiber oder Umgebung?

Symptom: Das offizielle Kimi-K3-Image ist nur als CUDA-13-Build verfügbar, während Ihr Host noch auf r575 läuft.
Schnellste Lösung: Bei bestätigter Inkompatibilität auf r580 oder neuer aktualisieren; wenn der gemeinsame Cluster nicht geändert werden darf, sofort auf eine isolierte kompatible Umgebung ausweichen. (offizielles Kimi-K3-Recipe)

Das offizielle vLLM-Recipe nennt für Kimi K3 drei harte Fakten: Das NVIDIA-Image ist als cu130 gebaut, der Host benötigt einen r580+-Treiber, und für NVIDIA wird eine Mindesttopologie von 8 × GB300 genannt. Das ist zunächst kein gewöhnlicher Speicherfehler. Wenn Image und Host diese Kombination nicht erfüllen, sollten Sie nicht zuerst max-model-len, Batch-Größe oder Cache-Parameter verändern.

Für wen dieser Artikel gedacht ist: Sie betreiben einen r575-GPU-Cluster und müssen einen Kimi-K3-vLLM-Startfehler noch am selben Tag für Validierung oder Agent-Integration beheben. Oder Sie verantworten die Freigabe eines Treiberwechsels und benötigen eine belastbare Rückfallentscheidung. Auch Agent-Teams, die nicht auf eine zentrale Clusteränderung warten können, finden hier eine isolierte Übergangsroute.

Zuletzt aktualisiert am 05.08.2026; geprüft anhand des offiziellen Kimi-K3-Recipes, des vLLM-Veröffentlichungsbeitrags und der NVIDIA-CUDA-Kompatibilitätsdokumentation.

Die ersten 15 Minuten: Beweise sichern statt Startparameter verändern

Ein typischer Fehlerfall sieht so aus: Der Container wird geladen, der Prozess beendet sich während der Initialisierung, und im Log erscheinen CUDA-, Treiber- oder Kernelmeldungen. Danach werden nacheinander Tensor-Parallelität, Arbeitsspeicher und Kontextlänge verändert. Das verlängert die Fehlersuche, weil jede neue Variable die ursprüngliche Beweislage verschlechtert.

Sichern Sie vor jeder Änderung mindestens:

• den vollständigen Image-Namen einschließlich Tag;
• die Quelle und den Commit der verwendeten vLLM-Version;
• die Ausgabe von nvidia-smi;
• Hostname und GPU-Topologie des Knotens;
• Container-Runtime und Runtime-Konfiguration;
• den kompletten Startbefehl;
• die ersten und letzten relevanten Logzeilen;
• die aktuelle Belegung durch andere Workloads.

Ein minimaler Beweissatz kann beispielsweise so aussehen:

nvidia-smi
docker image inspect vllm/vllm-openai:kimi-k3
docker info
env | sort

Verwenden Sie diese Befehle nur als Ausgangspunkt. Die genaue Prüfung von Container-Runtime, Orchestrator und Clusterzustand richtet sich nach Ihrer Plattformdokumentation. Wichtig ist nicht die konkrete Shell-Zeile, sondern dass Sie den Zustand vor dem Eingriff reproduzierbar dokumentieren.

Die erste Trennung lautet:

Das offizielle Recipe beschreibt cu130 und r580+ als Voraussetzung. NVIDIA ordnet CUDA 13.x ebenfalls der r580-Serie oder neuer zu; CUDA 12.9 liegt dagegen in der r575-Kompatibilitätsklasse. Dadurch entsteht die entscheidende Diagnose: Ein cu130-Container auf r575 ist zunächst ein Versionsproblem, kein Beweis für zu wenig Grafikspeicher. (NVIDIA-Dokumentation zur CUDA-Kompatibilität)

Die erste Entscheidung: Ist es wirklich die CUDA-Treiber-Grenze?

Prüfen Sie die drei Ebenen getrennt:

1. Container: Verwenden Sie tatsächlich vllm/vllm-openai:kimi-k3 oder ein davon abgeleitetes Image?
2. CUDA-Build: Ist das verwendete Image cu130 oder eine selbst erstellte cu129-Variante?
3. Host: Meldet nvidia-smi einen r575-Treiber oder eine andere Serie?

Die häufigste Fehlannahme lautet: „nvidia-smi zeigt eine CUDA-Version an, also kann der Host jedes neuere CUDA-Image ausführen.“ Diese Anzeige beschreibt jedoch nicht automatisch die konkrete Kompatibilität des gestarteten Binaries. NVIDIA weist darauf hin, dass jede CUDA-Toolkit-Version eine Mindesttreiberversion benötigt. Für CUDA 13.x ist r580 oder neuer die relevante Grenze; CUDA 12.x folgt einer anderen Kompatibilitätslogik.

Der vLLM-Beitrag nennt für den Start außerdem Parameter wie --enable-prefix-caching, --trust-remote-code und den Kimi-K3-Parser. Diese Parameter sind erst dann sinnvoll zu bewerten, wenn die Engine überhaupt initialisiert. Ein fehlender Cache-Schalter erklärt keinen CUDA-Fehler während des Containerstarts. (vLLM-Beitrag zu Kimi K3)

Die drei Wiederherstellungspfade für denselben Arbeitstag

Nach der Beweissicherung müssen Sie nicht drei Varianten parallel bauen. Entscheiden Sie anhand von Wartungsfenster, Änderungsfreigabe und langfristiger Pflege.

Pfad A: Upgrade auf r580 oder neuer

Das ist der bevorzugte Weg, wenn Ihre Plattform die Änderung kontrolliert zulässt. Sie behalten den offiziellen cu130-Container und reduzieren die Zahl selbst gepflegter Komponenten.

Vor dem Upgrade müssen Sie jedoch prüfen:

• Können bestehende CUDA-12-Workloads mit dem neuen Treiber betrieben werden?
• Sind Kernelmodule, Container-Runtime und Orchestrator für den neuen Treiber freigegeben?
• Ist die NCCL- und RDMA-Konfiguration dokumentiert?
• Gibt es einen Knoten, der aus dem Scheduler genommen werden kann?
• Können Sie den alten Treiber und die vorherige Node-Konfiguration wiederherstellen?

Der Vorteil ist nicht nur „neuere Software“. Der eigentliche Vorteil ist eine klarere Support-Grenze. NVIDIA führt r580 als Long-Term-Support-Zweig und ordnet ihm CUDA 13 ohne Forward-Compatibility-Paket zu. (NVIDIA-Übersicht zu Treiber- und CUDA-Versionen)

Der Pfad ist ungeeignet, wenn ein gemeinsam genutzter Cluster keine kontrollierte Drain-Phase erlaubt oder andere Teams ihre Workloads nicht gegen den neuen Treiber geprüft haben. In diesem Fall ist ein lokaler Eingriff kein schneller Fix, sondern ein ungeplanter Clusterumbau.

Pfad B: cu129 selbst bauen

Das offizielle Kimi-K3-Recipe nennt als Alternative den Eigenbau aus dem K3-Branch gegen cu129-PyTorch, wenn der Host auf CUDA 12.9 beziehungsweise r575 verbleiben muss. Das ist keine gleichwertige Komfortoption zum offiziellen Container. Sie übernehmen damit die Verantwortung für Build-Reproduzierbarkeit, Wheel-Versionen, Compiler, FlashInfer-nahe Abhängigkeiten und spätere Regressionen. (Alternative Build-Route im Kimi-K3-Recipe)

Dieser Weg passt nur, wenn Sie bereits:

• reproduzierbare Build-Pipelines besitzen;
• Container-Artefakte intern signieren und archivieren;
• Abhängigkeiten mit festen Versionen testen;
• einen Rollback auf das vorherige vLLM-Image beherrschen;
• Fehler in CUDA- und Python-Komponenten selbst analysieren können.

Beenden Sie den Eigenbau als Übergangslösung, wenn der Build nur auf einem Einzelknoten funktioniert, keine zweite Person ihn reproduzieren kann oder Agent-Tests mit jedem neuen Abhängigkeitsstand anders ausfallen. Ein cu129-Eigenbau ist dann kein stabiler Produktionspfad, sondern ein zusätzlicher Betriebsdienst.

Pfad C: isolierte kompatible Umgebung

Wenn der Cluster nicht geändert werden darf, ist eine isolierte Umgebung die schnellste Möglichkeit, die Anwendungsarbeit fortzusetzen. Sie trennen dabei den Kimi-K3-Test von den bestehenden Treiberverträgen des Clusters.

Die Umgebung sollte mindestens getrennt verwalten:

• Treiber- und Container-Lebenszyklus;
• Zugangsdaten und Testdaten;
• Netzwerkfreigaben;
• API-Endpunkt;
• Logs und Audit-Aufzeichnungen;
• Lösch- und Rückfallplan.

Für sensible Agent-Daten müssen Sie DSGVO-Anforderungen, Datenminimierung und Aufbewahrungsfristen prüfen. Übernehmen Sie nicht automatisch Produktionsprompts oder personenbezogene Dokumente in eine temporäre Umgebung. Für die erste Validierung reichen synthetische Testfälle, feste Systemprompts und anonymisierte Tool-Schemata.

Wenn Sie die Bereitstellung über MacHTML organisieren, können Sie die verfügbare Umgebung und den Zugang zunächst über die MacHTML-Konsole prüfen. Für technische Voraussetzungen und Rückfragen sollte die MacHTML-Hilfe die maßgebliche Anlaufstelle bleiben. Konkrete Konfigurationen oder Lieferzeiten sollten Sie erst nach der tatsächlichen Verfügbarkeitsprüfung festhalten.

Die Änderungsnacht: Upgrade, Test und Rückfall in kontrollierter Reihenfolge

Führen Sie die Migration nicht als einen einzigen Clusterwechsel aus. Verwenden Sie eine gestaffelte Reihenfolge:

1. Baseline erstellen: Erfassen Sie Treiberversion, GPU-Zustand, Runtime, laufende Jobs, NCCL-Umgebung und aktuelle Fehlermeldung.
2. Knoten isolieren: Nehmen Sie zunächst einen einzelnen Testknoten aus dem Scheduler. Stoppen Sie keine fremden Workloads ohne Freigabe.
3. Treiber ändern: Installieren Sie den freigegebenen Treiber nach der Dokumentation Ihrer Distribution und Plattform.
4. Container prüfen: Starten Sie zunächst nur den Kimi-K3-Container und bestätigen Sie GPU-Sichtbarkeit, CUDA-Initialisierung und Modellzugriff.
5. Minimalen Dienst starten: Verwenden Sie den dokumentierten vLLM-Befehl ohne zusätzliche Optimierungen, die nicht für die erste Prüfung erforderlich sind.
6. Kurzen API-Test ausführen: Prüfen Sie eine einfache Textanfrage und die erwartete OpenAI-kompatible Schnittstelle.
7. Cross-Node-Funktionen testen: Erst danach prüfen Sie NCCL, RDMA und die im Recipe genannte All-to-All-Konfiguration.
8. Arbeitslast schrittweise erweitern: Erhöhen Sie Kontext, Parallelität und Agentenfunktionen einzeln.
9. Rollback-Entscheidung dokumentieren: Halten Sie fest, welcher Test bei welchem Logstatus zum Abbruch führt.

Die Dokumentation des Kimi-K3-Recipes nennt für Cross-Node-Kommunikation unter anderem deepep_v2 für RDMA und flashinfer_nvlink_one_sided für NVLink. Diese Auswahl darf nicht pauschal übernommen werden. Sie muss zu Ihrer tatsächlichen Topologie passen.

Wenn die erste isolierte Prüfung scheitert, stoppen Sie die Ausweitung. Ein Rollback ist dann günstiger als ein zweiter, gleichzeitiger Fehlerpfad.

Nach dem Start: prefix caching separat beweisen

Ein laufender Prozess bedeutet nicht, dass die Migration vollständig erfolgreich war. Beim Kimi-K3-Start wird prefix caching laut offiziellem vLLM-Beitrag explizit mit --enable-prefix-caching aktiviert. Der Beitrag beschreibt außerdem eine hybride Cache-Architektur, weil Kimi K3 sowohl wiederkehrende Zustände als auch klassische Attention-Cache-Blöcke verwaltet. (Dokumentation zum Prefix-Caching bei Kimi K3)

Prüfen Sie die Funktion in dieser Reihenfolge:

1. Starten Sie den Dienst mit dem expliziten Cache-Parameter.
2. Verwenden Sie einen langen, unveränderten Systemprompt.
3. Senden Sie dieselbe Anfrage mindestens ein zweites Mal.
4. Wiederholen Sie den Test mit einer bewusst geänderten Präfixzeile.
5. Vergleichen Sie Logs, Cache-Metriken und Laufzeitindikatoren.
6. Dokumentieren Sie, ob nur der Attention-Anteil oder auch der hybride Zustand wiederverwendet wurde.

Wenn kein Vorteil sichtbar ist, unterscheiden Sie drei Ursachen:

• Parameter fehlt: Der Dienst läuft, aber der Cache wurde nicht aktiviert.
• Präfix ist nicht identisch: Schon eine abweichende Systemnachricht, Tooldefinition oder Reihenfolge kann die Wiederverwendung verhindern.
• Aufbewahrung ist ungeeignet: Der Zustand wird nicht lange genug behalten oder die Retention-Strategie passt nicht zum Agentenverkehr.

Der vLLM-Beitrag beschreibt promptbasierte Grenzen, Intervall-Aufbewahrung und selektive Aufbewahrung. Daraus folgt für Ihre Diagnose: Ein Cache-Miss nach einem Treiberwechsel ist nicht automatisch ein Treiberproblem. Prüfen Sie zuerst Identität, Aktivierung und Aufbewahrung des Präfixes.

Die erste Belastung: Kapazität und Kommunikation nicht vermischen

Nach dem Einzeltest erhöhen Sie die Belastung stufenweise. Beginnen Sie mit Modellladung, danach einer kurzen Anfrage, anschließend dem für Ihr Produkt vorgesehenen Kontext und erst danach mit parallelen Agentenaufrufen.

Behalten Sie pro Stufe im Log:

• Startzeit und Endzeit;
• Container- und Treiberversion;
• GPU-Speicherbelegung;
• Request-Kontext;
• Cache-Status;
• NCCL- und Netzwerkfehler;
• Antwortfehler und Tool-Parsing;
• Knoten- und Rank-Zuordnung.

Das offizielle Recipe nennt für NVIDIA mindestens 8 × GB300 und weist auf Multi-Node-Betrieb für realen Produktionsverkehr hin. Das ist eine Plattformvoraussetzung des Recipes, aber kein allgemeiner Leistungsnachweis für jede Topologie. Community-Schätzungen zu einer angeblichen Mindestmenge an Gesamtspeicher sollten Sie deshalb nicht als Ersatz für das offizielle Hardware- und Deployment-Recipe verwenden.

Ein OOM während der Belastung kann auf Kontextlänge, Cache-Aufbewahrung, Parallelität oder tatsächliche Modellkapazität zurückgehen. Ein NCCL-Fehler kann dagegen auf Treiber, Kernel, RDMA, Topologie oder All-to-All-Backend hindeuten. Führen Sie diese Fehlerketten getrennt. Sonst verwerfen Sie möglicherweise ein korrektes Treiber-Upgrade, nur weil ein nachgelagerter Kommunikationsparameter noch nicht zur Infrastruktur passt.

Ihre Abnahme-Checkliste für die Entscheidung

Verwenden Sie die folgende Liste als Abnahme vor einer dauerhaften Entscheidung:

• [ ] Image-Tag und vLLM-Quelle sind archiviert.
• [ ] Host-Treiber und CUDA-Build sind eindeutig dokumentiert.
• [ ] Der cu130-auf-r575-Konflikt wurde von einem späteren OOM- oder NCCL-Fehler getrennt.
• [ ] Ein isolierter Knoten wurde erfolgreich getestet.
• [ ] Der minimale API-Aufruf liefert eine korrekte Antwort.
• [ ] Der Zielkontext wurde ohne unerwarteten Abbruch geprüft.
• [ ] prefix caching wurde explizit aktiviert.
• [ ] Identische und absichtlich unterschiedliche Präfixe wurden verglichen.
• [ ] Tool-Calling und strukturierte Ausgaben wurden erneut getestet.
• [ ] Cross-Node-Kommunikation wurde separat validiert.
• [ ] Ein dokumentierter Rückfall auf den vorherigen Dienst ist möglich.
• [ ] Die Entscheidung ist mit Datum, Verantwortlichem und Logreferenz festgehalten.

Nach einer Beobachtungsphase vergleichen Sie vier Kriterien: reproduzierbare Fehler, Cache-Wiederverwendung, Agentenantworten und Pflegeaufwand. Behalten Sie r580 im Cluster, wenn alle vier Kriterien stabil sind und die Änderung für weitere Workloads freigegeben wurde. Lassen Sie die isolierte Umgebung weiterlaufen, wenn sie die Entwicklungsarbeit zuverlässig trägt, der gemeinsame Cluster aber noch nicht freigegeben ist. Kehren Sie zurück, wenn die neue Umgebung zwar startet, aber Kommunikations- oder Anwendungsfehler nicht beherrschbar sind.

FAQ zur Wiederherstellung

Kann das cu130-Image von Kimi K3 auf einem r575-Treiber laufen?

Nach dem derzeit geprüften offiziellen Recipe ist das cu130-Image für CUDA 13 gebaut und benötigt einen NVIDIA-Treiber der r580-Serie oder neuer. Ein r575-Host erfüllt diese Voraussetzung nicht. Prüfen Sie deshalb zuerst Image-Tag und Host-Treiber, bevor Sie Speicherparameter oder Parallelismus verändern.

Sollten Sie für Kimi K3 den Treiber aktualisieren oder vLLM neu kompilieren?

Ein Treiber-Upgrade ist der bevorzugte Weg, wenn ein Wartungsfenster, ein isolierter Validierungsknoten und ein getesteter Rückfall vorhanden sind. Ein cu129-Eigenbau bleibt eine Übergangslösung für Teams, die CUDA-, PyTorch- und vLLM-Abhängigkeiten selbst pflegen können. Für Produktionsumgebungen sollte er nicht die automatische Standardentscheidung sein.

Wie testen Sie Kimi K3 ohne Änderung am gemeinsam genutzten GPU-Cluster?

Nutzen Sie einen isolierten, kompatiblen Knoten oder eine temporär bereitgestellte Umgebung mit eigener Treiberschicht. Übernehmen Sie nicht ungeprüft Produktionsdaten. Testen Sie Modellladung, kurze Textanfragen, identische Agentenpräfixe, Tool-Aufrufe und Rückfall auf den bisherigen Dienst. Erst danach sollte ein Clusterwechsel beantragt werden.

Welche Funktionen müssen Sie nach dem Wechsel der Kimi-K3-Umgebung erneut prüfen?

Prüfen Sie nicht nur, ob der Prozess startet. Wiederholen Sie Modellladung, API-Erreichbarkeit, Zielkontext, Parallelität, multimodale Eingaben, Tool-Calling, strukturierte Ausgaben, Agentenfehler, Cross-Node-Kommunikation und Rückfall. Halten Sie pro Test die Container-Version, den Treiber, die vLLM-Quelle und den vollständigen Logauszug fest.

Warum bleibt prefix caching bei Kimi K3 nach dem Start wirkungslos?

Bei Kimi K3 ist prefix caching laut offiziellem vLLM-Beitrag nicht automatisch aktiviert. Zusätzlich müssen die wiederholten Anfragen tatsächlich denselben Präfix bis zu einer wiederverwendbaren Grenze enthalten. Aktivieren Sie die Funktion explizit und unterscheiden Sie anschließend zwischen fehlendem Parameter, unterschiedlichen Präfixen und zu geringer Cache-Aufbewahrung.

Wann eine temporäre MacHTML-Umgebung sinnvoller ist

Wenn Ihr gemeinsamer GPU-Cluster auf r575 bleiben muss, blockiert Sie der Infrastrukturkonflikt sonst an zwei Stellen: Sie können das offizielle cu130-Image nicht direkt verwenden, und ein eigener cu129-Build erzeugt zusätzlichen Pflege- und Rückfallaufwand. Dazu kommen Freigaben für Kernelmodule, NCCL, RDMA und bestehende Workloads. Für kurze Validierungsfenster ist das häufig mehr Betriebsrisiko als eigentliche Modellarbeit.

In dieser Situation ist eine isolierte Umgebung von MacHTML eine sinnvolle Zwischenentscheidung: Sie können Kimi K3 und Ihre Agentenabläufe zunächst reproduzierbar testen, ohne den gemeinsam genutzten Cluster sofort umzubauen. Prüfen Sie vorab Zugriff, Datenschutz, Datenlöschung und Rückfallweg über die MacHTML-Hilfe. Wenn die Tests stabil sind, entscheiden Sie anschließend mit echten Logs, ob der r580-Wechsel dauerhaft in Ihren Cluster gehört oder die isolierte Route vorerst genügt.

FAQ

Weiterführende Links: Kimi K3 lokal bereitstellen: Hardwareanforderungen und Praxisempfehlungen Kimi K3, Qwen 3.8 Max und DeepSeek V4 im direkten Vergleich Kimi-K3-API mit Haupt- und Backup-Anbieter ausfallsicher betreiben