Was verursacht Fehler beim LLM Serving, und wie behebt man sie?
Automatische Übersetzung
Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.
Fehler beim LLM Serving entstehen oft durch unzureichenden Speicher, mehr gleichzeitige Arbeit, als der Dienst bewältigen kann, oder Wiederholungen aufwendiger Anfragen. Ermittle, welche Ressource oder Phase versagt, bevor du die Runtime änderst. Dass ein Model erfolgreich geladen wird, beweist nicht, dass es den vorgesehenen Datenverkehr bewältigen kann.
Ordne dem Symptom die passenden Messdaten zu
| Symptom | Zuerst zu prüfende Daten | Zu testende Änderung |
|---|---|---|
| GPU-Speichermangel | Weights, KV-Zuweisung, Activations, Anfragelängen | Kleinerer aktiver Batch, kürzere Limits oder unterstützte Quantization |
| Latency steigt ohne Fehler | KV-Nutzung, Preemptions, wartende Anfragen | Weniger gleichzeitig zugelassene Anfragen oder mehr durch Messungen bestätigte Kapazität |
| Langsames erstes Token | Warteschlange, Tokenization, Prefill, Netzwerkzeiten | Die langsame Phase beheben; chunked prefill testen, wenn sich die Phasen gegenseitig beeinträchtigen |
| Last steigt nach Zeitüberschreitungen | Anzahl der Wiederholungen und noch laufende Arbeit | Begrenzte Wiederholungen und Abbruch nicht mehr benötigter Arbeit |
Der Speicher für Weights und der KV-Speicher sind getrennt. Ein 70B-FP16-Model benötigt ungefähr 140 GB für die reinen Weight-Werte. Bei einem herkömmlichen Cache-Layout mit vollständiger Attention kommen für eine Llama-3.1-70B-Sequenz mit 128K Tokens 40 GiB FP16-KV-Daten hinzu, noch ohne Runtime-Overhead. Keine der beiden Zahlen allein beschreibt den gesamten Speicherbedarf.
Prüfe Preemption, bevor du die Warteschlange vergrößerst
Wenn der KV-Speicher nicht ausreicht, kann eine Serving-Engine Anfragen unterbrechen. vLLM V1 berechnet unterbrochene Arbeit normalerweise erneut, was die Latency erhöht, selbst wenn die API am Ende erfolgreich antwortet. Setze die Anzahl der Preemptions mit Prompt-Längen, aktiven Sequenzen und KV-Nutzung in Beziehung.
Reduziere die zugelassene Arbeit oder ändere die getestete Speicherzuweisung. Bevor du die GPU-Speicherauslastung erhöhst, musst du bestätigen, dass die übrigen Speicherzuweisungen weiterhin Platz haben. Wiederverwendbare KV-Daten auf CPU oder Festplatte zu verschieben, verursacht ebenfalls Übertragungen; es garantiert nicht, dass eine zu große aktive Anfrage in den Speicher passt.
Begrenze Wiederholungen
Wiederhole vorübergehend fehlgeschlagene Anfragen nur innerhalb einer Frist und eines Wiederholungsbudgets. Nutze Backoff mit Jitter und ordne Wiederholungen einer einzigen Schicht zu, damit sich Gateway- und Client-Wiederholungen nicht vervielfachen. Googles SRE-Leitfaden erklärt, wie Wiederholungen eine Überlastung verschärfen können.
Leite den Abbruch weiter, wenn der Aufrufer nicht mehr wartet, prüfe, dass die Generierung stoppt, und teste dieses Verhalten unter Last. Mehr Warteschlangenkapazität verzögert die Ablehnung, schafft aber keine Verarbeitungskapazität.
Lies den Abschnitt Fehlermodi beim LLM Serving im Leitfaden für die dazugehörigen Speicher- und Scheduling-Konzepte.