Kimi K3 vLLM OOM 2026: Justieren oder erweitern?

Lade-OOM → senken Sie nicht zuerst die Parallelität, sondern prüfen Sie Initialisierung, CUDA 13, Treiber und Topologie.
Laufzeit-OOM → reduzieren Sie Kontext, Sitzungen und Cache-Retention mit derselben Anfragefolge; bleibt unter Ziellast keine Reserve, erweitern oder migrieren Sie die Umgebung.

Dieser Leitfaden richtet sich an Forschende und POC-Teams, kleine Agent-Teams sowie Plattform- und Produktionsteams. Sie erhalten keine isolierte Parameterliste, sondern eine Entscheidungsmethode: Wann reicht kontrolliertes Tuning, wann ist die Umgebung inkompatibel und wann muss zusätzliche Rechenkapazität bereitgestellt werden?

Letzte Aktualisierung: 16.08.2026. Technische Angaben wurden gegen das offizielle Kimi-K3-Rezept von vLLM, den offiziellen vLLM-Beitrag zur Kimi-K3-Unterstützung und die CUDA-Kompatibilitätsdokumentation von NVIDIA geprüft.

Zwei OOM-Phasen, zwei unterschiedliche Entscheidungen

Ein „out of memory“ bei Kimi K3 ist noch keine konkrete Tuning-Anweisung. Entscheidend ist, wann der Fehler auftritt und ob die Engine bereits vollständig einsatzbereit war.

OOM während des Ladens

Typische Hinweise sind:

• Der Prozess scheitert beim Einlesen oder Verteilen der Gewichte.
• Die Modellinitialisierung wird nicht abgeschlossen.
• Im Log erscheint kein Bereitschaftszustand der Engine.
• Der erste API-Aufruf kann nicht erfolgreich beantwortet werden.
• Der Speicherfehler tritt bereits ohne echte Anfrage oder unter einer einzelnen Minimalanfrage auf.

In dieser Phase sind max-model-len, eine niedrigere Anfrageparallelität oder eine andere Cache-Retention normalerweise nicht die erste Lösung. Diese Einstellungen greifen vor allem bei laufenden Anfragen und deren zusätzlichen Speicherstrukturen. Wenn Gewichte und Grundstrukturen nicht initialisiert werden können, fehlt zunächst eine kompatible Basiskapazität.

Das offizielle Rezept beschreibt für Kimi K3 ein CUDA-13-Image, einen Host-Treiber ab R580 sowie eine unterstützte Hardwaretopologie. Als Einstieg werden acht B300-GPUs genannt; für reale Produktionslasten werden größere beziehungsweise mehrknotige Umgebungen empfohlen. Das Rezept nennt außerdem vLLM 0.27.1 oder neuer. Diese Angaben gelten für den beschriebenen Kimi-K3-Pfad und sind keine allgemeine GPU-Prognose für andere Hardware.

Die CUDA-Kompatibilität von NVIDIA bestätigt für CUDA 13.x einen Mindesttreiber ab R580. Die Mindestversion ist dabei eine technische Kompatibilitätsgrenze, keine Aussage darüber, dass jede Hardware mit diesem Treiber automatisch ausreichend Speicher oder eine passende Interconnect-Topologie besitzt. (NVIDIA: CUDA-Minor-Version-Kompatibilität)

Ein OOM beim Laden kann daher drei verschiedene Ursachen haben:

1. Umgebungsinkompatibilität: CUDA-Image, Treiber, Runtime oder Kernel passen nicht zusammen.
2. Falsche Topologie: Die GPUs sind einzeln ausreichend, aber nicht so verbunden oder parallelisiert, wie es der Kimi-K3-Pfad voraussetzt.
3. Tatsächliche Grundkapazität: Die gewählte Umgebung kann Modell, Initialisierung und Kommunikationsreserven nicht aufnehmen.

OOM während des Betriebs

Ein Laufzeit-OOM sieht anders aus:

• Die Engine wird vollständig initialisiert.
• Ein einfacher Testaufruf funktioniert.
• Der Fehler tritt erst bei langen Eingaben, mehreren Sitzungen, Toolaufrufen oder wiederholten Agent-Schritten auf.
• Die Speichernutzung steigt mit der Anfragefolge oder durch länger gehaltene Cache-Zustände.

Hier sind Anpassungen sinnvoll. Sie können zunächst den maximalen Kontext, die Zahl gleichzeitig laufender Sequenzen oder die Cache-Retention verändern. Das Ziel ist aber nicht, irgendeinen kurzen Test erfolgreich abzuschließen. Das Ziel ist eine stabile Reserve unter dem Anfrageprofil, das später tatsächlich betrieben werden soll.

Ein POC darf die Last reduzieren, um den Ablauf zu beweisen. Ein Produktionsteam darf die reduzierte Last nicht als Kapazitätsnachweis verwenden.

Achtung: Wenn das Modell nicht vollständig initialisiert wird, sparen Sie sich lange Experimente mit Parallelität. Prüfen Sie zuerst Image, CUDA 13, R580 oder neuer, vLLM-Version und die offizielle Hardwaretopologie.

Für Forschende und POC-Teams: Funktionsnachweis vor Kapazitätsversprechen

Ein persönlicher Test oder ein kleiner POC soll zunächst beantworten: Funktionieren API, Chat-Template, Toolaufrufe, strukturierte Ausgabe und die grundlegende Reasoning-Kette?

Dafür ist es vertretbar, den Test bewusst klein zu halten. Sie müssen in dieser Phase noch keinen Produktionsdurchsatz simulieren. Sie sollten jedoch dokumentieren, was der Test beweist und was nicht.

Ein erfolgreicher Minimaltest beweist:

• dass das Modell in der verwendeten Umgebung grundsätzlich initialisiert,
• dass der Endpunkt erreichbar ist,
• dass die erwartete Anfrageform akzeptiert wird,
• dass ein grundlegender Tool- oder Agent-Ablauf technisch möglich ist.

Er beweist nicht:

• dass lange Kontexte funktionieren,
• dass mehrere Sitzungen stabil bleiben,
• dass prefix caching unter echter Wiederverwendung ausreichend Nutzen bringt,
• dass die Umgebung für Produktionsspitzen ausreicht,
• dass eine bestimmte Antwortzeit eingehalten wird.

Sinnvolle Reduktion der Testlast

Beginnen Sie mit einer minimalen Anfrage:

• kurzer Systemprompt,
• keine unnötigen Dokumente,
• wenige oder keine Tooldefinitionen,
• begrenzte Ausgabelänge,
• eine Sitzung,
• keine parallelen Lasttests,
• reproduzierbare Sampling-Einstellungen.

Beim Kimi-K3-Pfad muss prefix caching ausdrücklich aktiviert werden. Die vLLM-Dokumentation beschreibt Automatic Prefix Caching als Funktion, die mit enable_prefix_caching=True eingeschaltet wird. Der Cache kann wiederverwendbare Präfixe erneut nutzen, beseitigt aber nicht automatisch den Speicherbedarf für gleichzeitig gehaltene Zustände. (vLLM: Automatic Prefix Caching)

Fünf Schritte für einen reproduzierbaren POC

1. Versionen einfrieren: Speichern Sie Docker-Image, Image-Digest, vLLM-Version, CUDA-Version, Host-Treiber und Startparameter.
2. Initialisierung separat prüfen: Erfassen Sie den Logabschnitt vom Prozessstart bis zur vollständigen Engine-Bereitschaft.
3. Einzelanfrage ausführen: Verwenden Sie eine feste Anfrage mit bekanntem Eingabe- und Ausgabeumfang.
4. Werkzeugaufrufe testen: Prüfen Sie, ob die Antwort korrekt geparst wird. Bei Agenten sind Schema-Prüfung und kontrollierte Wiederholung erforderlich.
5. Stop-Kriterium anwenden: Wenn die Initialisierung außerhalb der offiziellen Umgebung nicht gelingt, wechseln Sie zu einer konformen Testumgebung, statt immer weitere Einzelparameter zu verändern.

Die Frage, ob sich ein Lade-OOM durch Tuning lösen lässt, beantworten Sie damit präziser: Nur wenn die Initialisierung bereits grundsätzlich funktioniert und der Fehler erst durch zusätzliche Laufzeitressourcen entsteht. Ein Wechsel von Parallelität oder Kontextlänge ersetzt keine fehlende Grundkompatibilität.

Für den POC sollten Sie außerdem markieren, welche Parameter nur für den Funktionsnachweis reduziert wurden. Ein kurzer Kontext ist eine Testbedingung. Er ist keine Aussage über die spätere Anwendung.

Für kleine Agent-Teams: Präfix-Wiederverwendung behalten und Last kontrolliert senken

Bei Agent-Diensten entstehen zwei gegensätzliche Effekte. Lange Systemprompts, Tooldefinitionen und Gesprächsverläufe erhöhen den Speicherbedarf. Gleichzeitig können genau diese wiederkehrenden Präfixe durch prefix caching wertvoll sein.

Kimi K3 verwendet eine hybride Architektur aus vollständigem Attention-Cache und rekurrentem KDA-Zustand. vLLM muss deshalb nicht nur Tokenblöcke, sondern auch geeignete Zustandsgrenzen verwalten. Die offizielle Beschreibung weist darauf hin, dass KDA-Zustände nicht an jeder beliebigen Tokenposition dauerhaft gespeichert werden sollten, weil dies den Cache vergrößern kann. (vLLM: Kimi-K3-Architektur und Serving-Hinweise)

Ein OOM nach dem Einschalten von prefix caching bedeutet deshalb nicht automatisch, dass der Cache fehlerhaft ist. Mögliche Ursachen sind:

• zu viele gleichzeitig gehaltene Präfixzustände,
• eine Retention-Strategie, die für Ihre Anfrageverteilung zu großzügig ist,
• lange, kaum wiederverwendete Eingaben,
• parallele Agent-Schritte mit hoher Kontextüberschneidung,
• eine Kombination aus langen Präfixen und hoher Parallelität.

Kontrollierter Vergleich mit derselben Anfragefolge

Senken Sie nicht alle Variablen gleichzeitig. Verwenden Sie dieselbe Anfragefolge und führen Sie kontrollierte Varianten aus:

1. Baseline ohne Änderung.
2. Niedrigere Parallelität bei unverändertem Kontext.
3. Kürzerer Kontext bei unveränderter Parallelität.
4. Aktiviertes prefix caching mit beobachteter Trefferquote.
5. Angepasste Cache-Retention bei unverändertem Anfrageprofil.

Für jede Variante protokollieren Sie:

• Spitzenverbrauch des GPU-Speichers,
• Zeitpunkt und Ort des OOM,
• Zahl gleichzeitig laufender Sequenzen,
• Präfix-Treffer und Präfix-Fehltreffer,
• Antwortzeit und Abbruchrate,
• korrekte oder fehlerhafte Tool-Call-Ausgaben,
• Zahl der Wiederholungen innerhalb einer Agent-Anfrage.

Das offizielle vLLM-Material beschreibt unter anderem periodische Checkpoints und eine selektive Aufbewahrung erst nach wiederholter Nutzung. Für mehrstufige Agenten kann es daher sinnvoller sein, wiederkehrende Promptbereiche zu bewahren, statt sämtliche Zwischenzustände möglichst lange zu halten.

Erfahrung aus der Betriebsplanung: Ein einzelner kurzer Prompt, der nach dem Einschalten des Caches funktioniert, beweist nicht, dass Ihr Agent-Dienst stabil ist. Entscheidend ist die gleiche Anfrageverteilung vor und nach der Änderung.

Wann Parallelität senken, wann zusätzliche GPUs prüfen?

Für einen kleinen Agent-Dienst ist eine niedrigere Parallelität der bessere erste Test, wenn:

• die Engine bereits stabil läuft,
• der OOM erst bei mehreren Sitzungen entsteht,
• die Zielanforderung eine begrenzte Zahl aktiver Benutzer erlaubt,
• der Kontext zwar lang, aber nicht dauerhaft maximal ist,
• die Anfragefolge durch Backpressure kontrolliert werden kann.

Eine Erweiterung wird wahrscheinlicher, wenn:

• die geschäftlich erforderliche Sitzungszahl nicht erreicht wird,
• der Kontext fachlich nicht sinnvoll gekürzt werden kann,
• Tooldefinitionen und Systemprompts notwendig sind,
• der Cache einen nachweisbaren Nutzen bringt, aber selbst die Reserve verbraucht,
• die Speicherreserve nach jeder vertretbaren Reduktion verschwindet.

„Vertretbar“ bedeutet: Sie dürfen nicht die Geschäftslogik entfernen, nur um einen grünen Test zu erzeugen. Ein Agent, der ohne Werkzeuge und mit künstlich kurzem Kontext läuft, ist nicht derselbe Dienst wie Ihr geplanter Produktionsagent.

Für Plattformteams: Kontrollierbare Umgebung gegen teuren Eigenbau

Wenn Sie bereits ein GPU-Cluster betreiben, ist die wichtigste Frage nicht „Welcher zusätzliche Parameter fehlt?“, sondern „Welche Schicht kann ich überhaupt kontrollieren?“

Prüfen Sie getrennt:

• Können Sie den Host-Treiber auf R580 oder neuer aktualisieren?
• Können Sie das offizielle CUDA-13-Image verwenden?
• Haben Sie Zugriff auf die Netzwerkschicht und die Interconnect-Konfiguration?
• Können Sie Tensor-, Experten- oder Datenparallelität passend zur Topologie ändern?
• Können Sie RDMA, NVLink oder die erforderlichen Kommunikationspfade administrieren?
• Dürfen Sie Kernel, Container-Runtime und GPU-Operator gemeinsam ändern?
• Können Sie einen fehlerhaften Rollout vollständig zurücknehmen?

Das Kimi-K3-Rezept unterscheidet zwischen Kommunikationspfaden. Für NVLink wird ein anderer All-to-All-Backend empfohlen als für RDMA. Für bestimmte Multi-Knoten-Szenarien werden zusätzliche Einstellungen für Kommunikation und KV-Cache-Transfer genannt.

Die vLLM-Dokumentation beschreibt verteiltes Serving mit Tensor- und Pipeline-Parallelität. Bei Multi-Knoten-Betrieb sind die Kommunikationspfade zwischen den Knoten daher Teil der Kapazitätsentscheidung; zusätzliche GPUs ohne passende Kommunikation lösen nicht automatisch einen Lade- oder Laufzeitfehler. (vLLM: Distributed Inference and Serving)

Ein selbst gebautes vLLM-Umfeld kann sinnvoll sein, wenn Sie die gesamte Kette kontrollieren und die laufenden Wartungskosten akzeptieren. Es ist riskant, wenn Sie nur das Container-Image verändern dürfen, während Treiber, Kernel, Netzwerk und Knotenverteilung unverändert bleiben.

Eigenbau ist vertretbar, wenn

• die Treiberaktualisierung organisatorisch abgesichert ist,
• Sie reproduzierbare Images bauen können,
• Ihre Plattform ein Rollback unterstützt,
• Kommunikationsfehler diagnostiziert werden können,
• ein Team für vLLM- und CUDA-Updates zuständig ist,
• Test- und Produktionsumgebung getrennt werden können.

Eine konforme Übergangsumgebung ist meist besser, wenn

• der Host nicht aktualisiert werden darf,
• das Cluster keine passende Interconnect-Struktur besitzt,
• Sie mehrere experimentelle Abhängigkeiten selbst pflegen müssten,
• die Validierung dringend benötigt wird,
• die Kosten eines Fehlversuchs höher sind als eine zeitlich begrenzte Vergleichsumgebung.

Weitere betriebliche Hinweise zu Zugang, Abrechnung und Umgebungsverwaltung finden Sie im MacHTML-Hilfebereich. Für eine kontrollierte Gegenprobe mit einer getrennt bereitgestellten Umgebung können Sie außerdem die MacHTML-Konsole verwenden, sofern die benötigte Kimi-K3-Hardware- und Topologieanforderung dort tatsächlich verfügbar ist.

Für Produktionsteams: Zielverkehr statt Startmeldung als Maßstab

Ein produktiver Kimi-K3-Dienst ist nicht erfolgreich, nur weil die Engine startet. Sie benötigen eine Kapazitätsaussage für:

• erwartete Kontextlängen,
• Zahl gleichzeitiger Sitzungen,
• Agent-Schritte pro Anfrage,
• Wiederverwendung von Systemprompts und Tooldefinitionen,
• Spitzenlast,
• Wiederanlauf nach Fehlern,
• akzeptable Antwortzeit,
• erforderliche Cache-Treffer,
• Datenschutz- und DSGVO-Anforderungen bei temporären oder ausgelagerten Umgebungen.

Die offiziellen vLLM-Angaben nennen eine Kontextgröße von bis zu 1.048.576 Token und beschreiben Kimi K3 als MoE-Modell mit 2,8 Billionen Parametern, von denen pro Token 16 von 896 Experten aktiv sind. Diese Werte sind Architekturangaben, keine automatische Empfehlung für Ihre Produktionsdimensionierung. Sie beschreiben weder Ihre tatsächliche Speicherreserve noch Ihre Zielkosten. (Offizielles Kimi-K3-Rezept von vLLM)

Auch veröffentlichte Leistungswerte dürfen nicht verallgemeinert werden. vLLM berichtet beispielsweise 118 Token pro Sekunde ohne speculative decoding und 370 Token pro Sekunde mit DSpark auf 16 GB300-GPUs in einer bestimmten Messumgebung. Solche Zahlen hängen von Hardware, Topologie, Anfrageform, Parallelität und Softwarestand ab. Sie sind kein Erwartungswert für jedes Cluster. (vLLM: veröffentlichte Kimi-K3-Messung)

Für größere Produktionsumgebungen beschreibt vLLM Expertenparallelität, Datenparallelität sowie Prefill-/Decode-Disaggregation. Die Dokumentation zur Skalierung weist darauf hin, dass MoE-Modelle unterschiedliche Parallelisierungsstrategien für Attention- und Expertenschichten nutzen können. (vLLM: Parallelism and Scaling)

Diese Verfahren können unterschiedliche Engpässe getrennt adressieren, erhöhen aber die Anforderungen an Netzwerk, Synchronisation, Überwachung und Fehlerbehandlung. Eine Verdopplung der GPU-Anzahl führt daher nicht automatisch zu einer Verdopplung von Durchsatz oder stabiler Kontextkapazität.

Messablauf für die Produktionsentscheidung

1. Erstellen Sie ein anonymisiertes Anfrage-Set mit typischen und maximalen Kontexten.
2. Mischen Sie Einzelanfragen, parallele Sitzungen und echte Agent-Schleifen.
3. Erfassen Sie Speicher-Spitzenwerte pro Prozess und pro GPU.
4. Messen Sie Cache-Treffer, Cache-Größe und Wiederholungsrate.
5. Testen Sie mindestens einen kontrollierten Fehler- und Wiederanlauf.
6. Wiederholen Sie den Test nach jeder Änderung mit demselben Anfrage-Set.
7. Legen Sie eine Mindestreserve fest, die auch während Spitzenlast bestehen muss.
8. Prüfen Sie, ob der Dienst nach einer Wiederherstellung denselben Cache- und Kontextpfad erneut stabil aufbauen kann.

Sie sollten erst dann erweitern, wenn eine sinnvolle Lastreduktion die Zielanforderung nicht mehr erfüllt. Wenn die Zielkontextlänge unveränderbar ist und die Sitzungszahl geschäftlich feststeht, ist weiteres Kürzen keine neutrale Optimierung, sondern eine Funktionsänderung.

Entscheidungshilfe für die nächste Änderung

Die folgende Übersicht trennt den Zweck der Maßnahme. Sie ersetzt keine Messung, verhindert aber, dass Sie einen Ladefehler mit einem Cache-Problem verwechseln.

Ausführbare Prüfliste

• [ ] Ist im Log eindeutig erkennbar, ob der OOM vor oder nach der Engine-Bereitschaft auftritt?
• [ ] Sind Image, vLLM-Version, CUDA-Version und Host-Treiber vollständig dokumentiert?
• [ ] Entspricht die Hardwaretopologie dem offiziellen Kimi-K3-Pfad?
• [ ] Lädt das Modell ohne produktionsähnliche Agent-Anfragen vollständig?
• [ ] Wurde die Zielanfrage mit identischem Anfrage-Set vor und nach dem Tuning getestet?
• [ ] Wurde nur eine Hauptvariable pro Testlauf verändert?
• [ ] Sind Kontextlänge und Parallelität fachlich noch repräsentativ?
• [ ] Wurde prefix caching mit realistischen Präfixen und nicht nur mit einem kurzen Prompt bewertet?
• [ ] Sind Speicher-Spitzenwert, Cache-Treffer, Antwortzeit und Abbruchrate gespeichert?
• [ ] Gibt es nach der Änderung noch eine dokumentierte Speicherreserve?
• [ ] Ist klar, ob Host, Netzwerk und Container-Runtime tatsächlich verändert werden dürfen?
• [ ] Wurde ein Rollback- und Wiederanlauftest durchgeführt?
• [ ] Ist die Entscheidung zwischen Anpassung, Migration und Erweiterung schriftlich begründet?

Reproduzierbare Nachprüfung statt einmaliger Erfolg

Bevor Sie eine Plattformentscheidung treffen, speichern Sie mindestens:

• Docker-Image und Digest,
• vLLM-Version,
• CUDA- und Treiberversion,
• GPU-Typ und Knotenaufteilung,
• Parallelisierungsparameter,
• Cache-Schalter und Retention-Einstellungen,
• Anfrageproben ohne personenbezogene Daten,
• maximale Eingabe- und Ausgabelänge,
• Speicher-Spitzenwerte,
• Cache-Treffer und Fehlversuche,
• Start-, Abbruch- und Wiederanlaufprotokolle.

Nutzen Sie eine feste Änderungsreihenfolge. Erst die Umgebung korrigieren, dann die Initialisierung beweisen, danach Kontext und Parallelität einzeln variieren und erst anschließend Cache-Retention oder eine komplexere Topologie testen.

Wann Anpassung, Migration oder Erweiterung sinnvoll ist

Die Entscheidung lässt sich in drei Ergebnisse übersetzen.

Anpassung

Wählen Sie Anpassung, wenn das Modell lädt, die Zielanfrage grundsätzlich funktioniert und der OOM erst durch eine vermeidbare Kombination aus Kontext, Parallelität oder Retention entsteht. Halten Sie die Änderung klein und messen Sie mit identischem Verkehr nach.

Migration

Wählen Sie Migration, wenn Ihre bestehende Umgebung die offiziellen Voraussetzungen nicht kontrollierbar erfüllt. Das betrifft vor allem veraltete Treiber, fehlende CUDA-13-Unterstützung, nicht passende Kommunikationspfade oder ein Cluster, dessen Netzwerkebene nicht für die geplante Parallelisierung ausgelegt ist.

Erweiterung

Wählen Sie Erweiterung, wenn die Umgebung kompatibel ist, aber die fachlich notwendige Last keine stabile Speicherreserve zulässt. Bei Kimi K3 bedeutet das häufig nicht nur zusätzliche GPUs, sondern eine passende Multi-Knoten-, Expertenparallel- oder Prefill-/Decode-Architektur mit geeigneter Kommunikation.

Gegenprobe mit temporärer Rechenkapazität

Wenn Ihr Cluster nicht eindeutig zwischen Inkompatibilität und Kapazitätsmangel unterscheidet, ist eine zeitlich begrenzte Gegenprobe oft belastbarer als ein riskanter Umbau im laufenden System. Verwenden Sie dieselbe Container-Version, dieselbe Anfragefolge und dieselben Messpunkte. So sehen Sie, ob der Fehler mit der Umgebung verschwindet oder mit der Last reproduzierbar bleibt.

Das bestehende Cluster hat in dieser Situation meist drei Nachteile: Sie können Treiber und Netzwerk nicht schnell genug ändern, Tests konkurrieren mit anderen Diensten und ein fehlgeschlagener Umbau gefährdet den laufenden Betrieb. Eine temporär bereitgestellte MacHTML-Umgebung kann deshalb für die Verifikation sinnvoller sein, sofern MacHTML die erforderliche Kimi-K3-Hardware- und Topologieanforderung tatsächlich anbietet. Prüfen Sie Verfügbarkeit, Mietdauer, Datenschutz und Datenlöschung vor der Übergabe.

Für einen kurzfristigen POC oder einen Vergleichstest ist Mieten besonders dann sinnvoll, wenn Sie noch nicht wissen, ob Sie dauerhaft erweitern müssen. Für langfristige, kontinuierliche Hochlast, eigene physische Schnittstellen oder vollständig interne Datenhaltung kann ein eigener Cluster die bessere Lösung bleiben. Entscheidend ist, dass Sie die Mietumgebung nicht als Ersatz für eine Messung, sondern als kontrolliertes Vergleichsexperiment einsetzen.

Kurzentscheidung: Lädt Kimi K3 nicht, prüfen Sie zuerst die offizielle Umgebung. Lädt es, scheitert aber unter echtem Agent-Verkehr, reduzieren Sie Kontext, Parallelität und Cache-Retention in getrennten Tests. Bleibt die Zielanforderung danach ohne Reserve, ist eine passende Erweiterung oder Migration die technisch sauberere Entscheidung als weiteres Wegkürzen.