Parallelität bei KI-APIs: Warteschlangen, Kontingente und Latenz steuern

Warum eine funktionierende Integration überlastet werden kann

Eine Integration mit einem Modell kann im üblichen Betrieb zuverlässig funktionieren und dennoch an Leistung verlieren, wenn viele Anfragen gleichzeitig eintreffen. Sendet die Anwendung jede Anfrage sofort, ohne zu kontrollieren, wie viele gerade verarbeitet werden und wie viele warten, kann eine Verkehrsspitze schneller Arbeit ansammeln, als der Dienst sie erledigt. Sichtbare Folgen können höhere Latenz, Anfragen sein, deren Ergebnisse bei Fertigstellung nicht mehr nützlich sind, Antworten wegen erreichter Limits oder eine unerwartet hohe Rechnung.

Parallelität ist wichtig, weil eine Anfrage Ressourcen nicht für eine feststehende kurze Zeit belegt. Die Generierung kann je nach Aufgabe, Eingabegröße und angeforderter Ausgabemenge kürzer oder länger dauern. Deshalb beschreibt die Zahl der Anfragen pro Sekunde allein nicht den gesamten Druck, den eine Integration ausübt. Zwei Lastprofile mit derselben Anfragerate können unterschiedliche Bearbeitungszeiten und unterschiedlichen Verbrauch verursachen.

Ziel der Laststeuerung ist nicht, um jeden Preis jede mögliche Kapazität auszunutzen. Sie soll die Ziele der Anwendung schützen: nützliche Arbeit abschließen, Prioritäten einhalten, Wartezeiten begrenzen und verhindern, dass eine vorübergehend hohe Nachfrage das System in eine endlose Warteschlange verwandelt. Die folgenden Gestaltungsentscheidungen sind allgemeine Empfehlungen. Sie beschreiben weder ein universelles Limit noch ersetzen sie die dokumentierten Bedingungen der jeweiligen API, des Modells oder des Zugangswegs.

Zwei Probleme, die oft vermischt werden, sollten getrennt betrachtet werden. Die Zulassungssteuerung entscheidet vor dem Versand einer Anfrage, ob die Anwendung die Arbeit annimmt, sie kurz zurückstellt oder ablehnt. Die Wiederholungsrichtlinie greift nach einem Fehler oder einem unklaren Ergebnis. Dieser Leitfaden behandelt vor allem die erste Entscheidung und das kontrollierte Warten: Automatische Wiederholungen beheben keine Zulassungssteuerung, die mehr Arbeit hereinlässt, als das System verarbeiten kann.

Was vor dem Festlegen von Limits gemessen werden sollte

Beginnen Sie mit der Beobachtung einer repräsentativen Last, statt eine Parallelitätsgrenze nach Gefühl festzulegen. Erfassen Sie die Ankunftsrate und die Zahl gleichzeitig laufender Anfragen, ergänzen Sie diese Angaben aber um die Größe der Eingabe und – sobald verfügbar – die erzeugte Ausgabe. Bei einer Zulassungsentscheidung vor dem Versand ist die Ausgabe noch unbekannt. Sie kann später gemessen werden, um Schätzungen zu verbessern, darf aber nicht als exakte Kenntnis der Zukunft behandelt werden.

Messen Sie die Ende-zu-Ende-Latenz. Wenn sich die Phasen getrennt instrumentieren lassen, unterscheiden Sie außerdem die Zeit in der Warteschlange von der Zeit zwischen Versand und Antwort. Bei fortlaufend ausgegebenen Antworten sollten Sie auch die Zeit bis zum ersten Abschnitt und die gesamte Generierungsdauer erfassen. Eine kurze Zeit bis zum ersten Abschnitt bedeutet nicht, dass die vollständige Aufgabe schnell abgeschlossen wurde. Umgekehrt beweist eine lange Gesamtdauer für sich genommen nicht, dass die Warteschlange die Ursache ist.

Verwenden Sie neben Durchschnittswerten Perzentile wie p95 und p99. Der Durchschnitt fasst einen Trend zusammen, kann aber verbergen, dass eine Minderheit der Anfragen deutlich länger wartet. Ergänzen Sie diese Messwerte um abgeschlossene, abgebrochene, abgelaufene und abgelehnte Anfragen, vom Anbieter zurückgegebene Fehler, die verfügbaren Token-Verbrauchswerte und – sofern zuverlässig berechenbar – die Kosten je abgeschlossener Aufgabe.

Die Little’sche Gesetzmäßigkeit bietet eine Möglichkeit, die mittlere Zahl der Aufträge in einem System, die mittlere Ankunftsrate und die mittlere Verweildauer in Beziehung zu setzen: L = λW. Sorgfältig angewendet, hilft sie zu verstehen, warum bei gleichbleibender Ankunftsrate auch die durchschnittliche Zahl der vorhandenen Aufträge wachsen kann, wenn ihre Verweildauer zunimmt. Sie ist keine Formel, mit der sich allein Perzentile, Spitzen, Kosten oder das Limit einer API vorhersagen lassen. Sie beschreibt eine Beziehung zwischen Durchschnittswerten unter den jeweils geltenden Bedingungen.

Schlüsseln Sie Messwerte nach Modell, Endpunkt, Anbieter, Region oder Projekt auf, wenn diese Unterschiede für Ihre Konfiguration relevant sind. Fassen Sie kurze und lange Aufgaben nicht in einer einzigen Zeitreihe zusammen, wenn dadurch Probleme einer Kategorie verdeckt werden. Trennen Sie außerdem Produktionslast von Tests und halten Sie Konfigurationsänderungen fest, damit sich Latenzänderungen mit plausiblen Ursachen in Verbindung bringen lassen.

Anfragerate, Parallelität, Tokens und eigene Kapazität nicht verwechseln

Ein Ratenlimit begrenzt, wie viele Anfragen oder abgerechnete Einheiten innerhalb eines Zeitraums eingereicht werden dürfen. Ein Parallelitätslimit beschränkt, wie viele Vorgänge die Anwendung gleichzeitig aktiv hält. Ein tokenbasiertes Limit bezieht sich auf das Volumen des verarbeiteten oder angeforderten Texts gemäß den Regeln des jeweiligen Dienstes. Ein anwendungseigenes Limit ist eine zusätzliche Festlegung, zum Beispiel die Zahl der Aufträge in der lokalen Warteschlange oder die maximal erlaubte Wartezeit.

Diese Einschränkungen lösen unterschiedliche Probleme. Ein System kann eine durchschnittliche Rate einhalten und trotzdem eine kurze Verkehrsspitze ansammeln. Es kann nur wenige, dafür aber lang laufende parallele Anfragen haben. Oder es können nur wenige Anfragen eintreffen, die sehr umfangreiche Eingaben enthalten. Die Anwendung muss die veröffentlichten Einschränkungen für den verwendeten Zugangsweg kennen und zusätzlich lokale Steuerungen festlegen, die das Nutzungserlebnis schützen.

Kontingente sollten nicht aufgrund bloßer Ähnlichkeit von einem Produkt auf ein anderes übertragen werden. Die Dokumentation zu Vertex AI beschreibt Kontingente und Limits, deren Geltungsbereich vom Dienst, Projekt und der Region abhängen kann. Die API-Referenz von OpenAI enthält Antwort-Header zu Anfragen- und Tokenlimits. Diese Beispiele zeigen, weshalb die für das konkrete Konto und die jeweilige Konfiguration geltende Dokumentation geprüft werden muss. Sie legen weder gemeinsame Zahlen noch eine einheitliche Regel für alle Endpunkte fest.

Auch eine 429-Antwort hat nicht immer nur eine Ursache oder Lösung. Die Vertex-AI-Dokumentation unterscheidet Situationen im Zusammenhang mit gemeinsamer Kapazität und bereitgestellter Kapazität. Erfassen Sie daher den Antworttyp und schlagen Sie in der passenden Dokumentation nach, bevor Sie seine Bedeutung festlegen. Machen Sie insbesondere nicht aus jeder 429-Antwort die Aufforderung, sofort erneut zu versuchen. Dieses Verhalten gehört zur Fehlerbehandlung nach einem Fehlschlag und kann den Druck erhöhen, solange die Zulassungssteuerung weiterhin zu viel Arbeit hereinlässt.

Die Zulassung gestalten: annehmen, warten lassen oder ablehnen

Eine Zulassungsrichtlinie sollte drei eindeutige Ergebnisse vorsehen. Annehmen bedeutet, dass die Anfrage im Rahmen der lokalen Limits und bekannten Kontingente starten kann. Warten lassen bedeutet, dass sie vorübergehend in einer Warteschlange mit festgelegter Kapazität und Frist gehalten wird. Ablehnen bedeutet, dass das System zu diesem Zeitpunkt keine Verarbeitung zusagt und eine Antwort zurückgibt, anhand derer die aufrufende Anwendung entscheiden kann, was als Nächstes geschieht.

Eine unbegrenzte Warteschlange ist keine sichere Lösung. Sie kann eine sichtbare Überlastung in immer längere Wartezeiten und gespeicherte Arbeit verwandeln, die erst fertig wird, wenn sie nicht mehr nützlich ist. Legen Sie eine maximale Anzahl von Einträgen, ein Wartezeitbudget und eine Ablaufbedingung fest. Ist die Warteschlange voll, lehnen Sie neue Arbeit ab oder verwenden Sie eine durch das Produkt begründete Ersetzungsregel. Verbergen Sie das Problem nicht, indem Sie ohne betriebliches Limit mehr Speicher bereitstellen.

Die Ablehnungsantwort muss zur Schnittstelle Ihres Dienstes passen. Erklären Sie, dass die Aufgabe nicht angenommen wurde, oder weisen Sie darauf hin, dass die Kapazität vorübergehend ausgelastet ist, ohne zu behaupten, das Modell habe die Aufgabe verarbeitet. Wenn die Anwendung es später erneut versuchen kann, geben Sie ein klares, dokumentiertes Signal, damit der Client selbst entscheiden kann. Versprechen Sie keine genaue Wartezeit, wenn Ihre Messungen diese nicht zuverlässig stützen.

Die Zulassung kann mehrere Bedingungen kombinieren: verfügbare Parallelität, Warteschlange unterhalb ihrer Obergrenze, Kontingent pro Nutzer und verbleibendes Wartezeitbudget. Prüfen Sie die Bedingungen, bevor Sie Ressourcen reservieren, und geben Sie die Reservierung frei, sobald die Aufgabe abgeschlossen, abgebrochen oder abgelaufen ist. Wird eine Anfrage auf Client-Seite abgebrochen, belegt aber weiterhin einen lokalen Platz, bildet die Parallelitätsmessung nicht mehr die tatsächlich aktive Arbeit ab.

Legen Sie die Prioritätsreihenfolge ausdrücklich fest. Sie können beispielsweise einen Teil der Kapazität für interaktive Aufgaben reservieren und Stapelaufgaben begrenzen, sofern diese Kategorien in Ihrem Produkt vorkommen und die Richtlinie Aufgaben niedrigerer Priorität nicht unbegrenzt ohne Bearbeitung lässt. Es geht nicht darum, eine universelle Priorität zu erfinden, sondern den Wert und die Frist der jeweiligen Arbeitsklasse abzubilden.

Arbeit gewichten, ohne die exakten Kosten vorzutäuschen

Anfragen zu zählen ist eine einfache Regel, behandelt aber Aufgaben gleich, die sich deutlich unterscheiden können. Eine Alternative ist, jeder Anfrage anhand von Signalen, die vor dem Versand verfügbar sind, ein geschätztes Gewicht zuzuweisen: etwa anhand geschätzter Eingabetokens, der erwarteten Ausgabelänge, der Aufgabenkategorie oder historischer Bearbeitungszeiten für diesen Vorgangstyp. Das Gewicht kann für die Priorisierung, für Budgets oder für die Entscheidung dienen, ob eine Aufgabe noch in die Warteschlange passt.

Eine Schätzung ist keine Garantie. Die erzeugte Antwort kann kürzer oder länger ausfallen als erwartet. Auch bei ähnlich großen Eingaben kann die Dauer variieren. Kalibrieren Sie die Schätzung deshalb anhand beobachteter Ergebnisse, halten Sie Sicherheitsmargen vor und überprüfen Sie Vorhersagefehler. Wenn die tatsächliche Ausgabe protokolliert wird, können Sie damit künftige Richtlinien verbessern. Stellen Sie aber keinen Wert als bekannt dar, der bei der Zulassung noch nicht verfügbar war.

Eine praktikable Möglichkeit besteht darin, getrennte Limits je Klasse festzulegen oder pro Zeitfenster ein vorhergesagtes Arbeitsbudget zu reservieren. Eine andere Möglichkeit ist ein internes Kreditsystem, bei dem jede Anfrage ein geschätztes Gewicht verbraucht und die Kapazität gemäß der lokalen Richtlinie wieder aufgefüllt wird. Dokumentieren Sie in beiden Fällen, wie das Gewicht berechnet und korrigiert wird und was geschieht, wenn eine Anfrage die Schätzung überschreitet. Stellen Sie eine lokale Token-Abrechnung nicht so dar, als sei sie mit dem Kontingent des Anbieters identisch.

Vergleichen Sie Richtlinien anhand desselben Anfragebestands und derselben Last. Wenn eine gewichtete Richtlinie die Wartezeitspitzen für kleine Aufgaben reduziert, prüfen Sie auch, was mit großen Aufgaben geschieht: Sie könnten wiederholt zurückgestellt werden. Der Erfolg sollte anhand des Gesamtdurchsatzes, der Latenz je Klasse und des Anteils der Aufgaben, die innerhalb ihrer Frist abgeschlossen werden, bewertet werden – nicht nur anhand einer Kennzahl, die kurze Anfragen begünstigt.

Priorität, Fairness und Schutz vor Blockierung

Eine einzelne Warteschlange kann für ein Produkt mit gleichartigen Aufgaben ausreichen. Werden jedoch dringende und lang laufende Arbeiten vermischt, entstehen Risiken. Eine lang dauernde Aufgabe am Anfang kann andere warten lassen, selbst wenn diese kurz sind. Außerdem kann ein Kunde, der einen überproportionalen Teil der Nachfrage erzeugt, die gemeinsame Kapazität verbrauchen und andere beeinträchtigen.

Sie können Warteschlangen nach Serviceklasse trennen, Kontingente pro Nutzer festlegen oder die Zahl der gleichzeitig laufenden Aufgaben pro Client begrenzen. Ebenso können Sie Kapazität für interaktiven Datenverkehr reservieren und Stapelverarbeitung mit der verbleibenden Kapazität ausführen. Diese Möglichkeiten sind Gestaltungsoptionen, keine Fairnessgarantie. Prioritäten, Reservierungsgrößen und Auswahlregeln müssen anhand der tatsächlichen Nutzungsmuster getestet werden.

Legen Sie fest, was Fairness in Ihrem Fall bedeutet. Es könnte darum gehen, jedem Kunden Fortschritt zu ermöglichen, für interaktive Aufgaben eine Frist einzuhalten oder zu verhindern, dass ein Nutzer das gesamte lokale Budget verbraucht. Ein sehr strenges Kontingent pro Nutzer kann vor Vereinnahmung schützen, aber auch Kapazität ungenutzt lassen, wenn andere Nutzer gerade nicht aktiv sind. Ein zu großzügiges Kontingent schützt kleinere Kunden bei einer Verkehrsspitze möglicherweise nicht ausreichend.

Damit Aufgaben niedriger Priorität nicht unbegrenzt zurückgestellt werden, sollten Sie maximale Wartezeiten, eine mit der Wartezeit steigende Priorität oder Mindestanteile am Service erwägen. Messen Sie die Wartezeit je Klasse und Kunde, nicht nur den globalen Durchschnitt. Haben Kategorien unterschiedliche Fristen, erfassen Sie, wie viele davon rechtzeitig abgeschlossen werden und wie viele ablaufen. Eine Richtlinie, die die Latenz einer Klasse verbessert und eine andere dadurch nutzlos macht, sollte als bewusste Produktentscheidung kenntlich sein.

Wartezeitbudgets, Abbruch und Ablauf

Jede Aufgabe sollte eine vom Produkt festgelegte Nutzungsfrist haben, auch wenn diese Frist den Nutzern nicht direkt angezeigt wird. Bleibt eine Anfrage länger in der Warteschlange, als sie noch Wert liefern kann, sammelt sich dadurch nur überholte Arbeit an. Weisen Sie ein maximales Wartezeitbudget zu und prüfen Sie es erneut, bevor Sie die Aufgabe an den Anbieter senden.

Ablauf in der Warteschlange und Abbruch nach dem Versand sind nicht dasselbe. Vor dem Versand kann das Entfernen einer Aufgabe verhindern, dass nicht mehr benötigte Arbeit überhaupt beginnt. Nach dem Versand hängt die Wirkung eines Abbruchs von den Fähigkeiten der Integration und dem dokumentierten Verhalten des Endpunkts ab. Gehen Sie nicht davon aus, dass das Schließen einer Verbindung die Verarbeitung auf der Gegenseite beendet oder den Verbrauch rückgängig macht. Instrumentieren Sie, was das System tatsächlich beobachten kann, und beschreiben Sie die Einschränkungen.

Erfassen Sie, wie viele Anfragen vor dem Start ablaufen und wie viele während der Verarbeitung abgebrochen werden. Laufen viele bereits in der Warteschlange ab, überprüfen Sie deren Größe, die Zulassungsrate und das Wartezeitbudget. Werden viele nach dem Versand abgebrochen, untersuchen Sie, ob eine frühere Ablaufentscheidung oder eine Benutzeroberfläche, über die Nutzer die Arbeit zurückziehen können, nutzlose Aufgaben vermeiden würde. Leiten Sie Kosteneinsparungen nicht ohne entsprechende Messungen ab.

Der Ablauf hilft auch bei der Priorisierung: Eine dringende Aufgabe, deren Frist bereits verstrichen ist, sollte nicht allein deshalb weiterhin ganz oben stehen, weil sie zuerst eingetroffen ist. Das automatische Verwerfen von Arbeit kann jedoch funktionale Folgen haben. Legen Sie fest, ob der Ablauf gemeldet, die Aufgabe für eine spätere Ausführung aufbewahrt oder sie gelöscht wird. Das Verhalten muss für alle, die den Dienst integrieren, vorhersehbar sein.

Reproduzierbare Lasttests und Betrieb

Testen Sie die Richtlinie, bevor Sie sie breit ausrollen. Erstellen Sie einen repräsentativen Satz von Aufgaben mit unterschiedlich langen Ein- und Ausgaben und den Prioritätsklassen, die das Produkt tatsächlich verwenden wird. Führen Sie zunächst eine Basislast aus, erhöhen Sie danach schrittweise die Parallelität und ergänzen Sie kontrollierte Verkehrsspitzen. Halten Sie den Anfragebestand beim Vergleich von Varianten konstant, damit Unterschiede nicht darauf zurückzuführen sind, dass jeweils andere Aufgaben getestet wurden.

Legen Sie die Abbruch- und Rücknahmekriterien vorab fest. Sie können den Anstieg beispielsweise stoppen, wenn p99 das vereinbarte Ziel überschreitet, Ablaufzeiten oder Fehler zunehmen oder die Wartezeit das Produktbudget übersteigt. Die konkreten Werte sollten sich aus Ihren Zielen, Messungen und den Bedingungen der API ergeben, nicht aus einem universellen Richtwert. Halten Sie Konfiguration, Datum, Client-Version und Testparameter fest, damit sich der Test wiederholen lässt.

Schlüsseln Sie die Latenz auf: lokale Wartezeit, gegebenenfalls Zeit bis zur ersten Antwort und vollständige Dauer. Vergleichen Sie auch abgeschlossene Anfragen, Antworten wegen erreichter Limits, Abbrüche, Perzentile je Klasse und Kosten je abgeschlossener Aufgabe. Wer nur den Gesamtdurchsatz betrachtet, übersieht möglicherweise, dass eine Klasse scheitert. Wer nur eine Fehlerantwort betrachtet, erkennt womöglich nicht, dass die lokale Warteschlange schon vor dem Aufruf des Anbieters zu wachsen begann.

Prüfen Sie im Betrieb die veröffentlichten Kontingente für den konkret verwendeten Zugangsweg und überwachen Sie die von diesem Dienst dokumentierten Antwort-Header oder -Felder. Solche Signale können dabei helfen, Limits zu erkennen und in die Beobachtbarkeit einzubeziehen. Ihre Verfügbarkeit und Bedeutung hängen jedoch von der API ab. Nehmen Sie weder an, dass jeder Antwort ein bestimmter Header beigefügt ist, noch dass dieser dauerhaft unverändert bleibt. Halten Sie fest, wann Sie die Dokumentation zuletzt geprüft haben, und kontrollieren Sie sie erneut, bevor Sie Steuerungen aktualisieren.

Eine vorsichtige Einführung beginnt mit konservativen lokalen Limits, guter Beobachtbarkeit und einer Möglichkeit, zur vorherigen Konfiguration zurückzukehren. Anschließend kann die Zulassung schrittweise erhöht werden, wenn die Ergebnisse dafür sprechen. Verschlechtern sich die Messwerte, reduzieren Sie die zugelassene Last, verkürzen Sie die Warteschlange oder passen Sie die Arbeitsklassen an. Reagieren Sie auf steigende Latenz nicht automatisch mit einer größeren Warteschlange: Das kann die Überlastung verdecken und die Wartezeiten verlängern.

Grenzen des Ansatzes und praktische Kriterien

Es gibt keine Parallelitätszahl, die sich sicher auf alle Integrationen übertragen lässt. Kontingente und Bedingungen können je nach Dienst, Modell, Projekt, Region und Zugangsweg variieren. Außerdem können sich Kontingente ändern. Eine in einem Test beobachtete Kapazität beweist nicht, dass dieselbe Kapazität zu einem anderen Zeitpunkt oder in einer anderen Konfiguration verfügbar ist. Schlagen Sie die jeweils geltenden offiziellen Quellen nach und überprüfen Sie die Limits, bevor Sie sie als dauerhafte Regeln festlegen.

Es gibt auch keine einzelne Formel, die Tokens oder Anfragen pro Sekunde in eine garantierte Latenz übersetzt. Die Beziehung zwischen Ankunft, Verweildauer und mittlerer Zahl der Aufträge hilft, das Wachstum einer Warteschlange zu durchdenken, ersetzt aber weder einen repräsentativen Test noch sagt sie jede einzelne Antwort voraus. Beobachtete Ausgabegrößen und Bearbeitungszeiten liefern Informationen. Vorab-Schätzungen helfen bei einer vorsichtigen Zulassung, garantieren aber kein exaktes Ergebnis.

Bevor Sie eine Richtlinie freigeben, sollten Sie wissen, wie viele Anfragen laufen und warten, ob die Warteschlange eine Obergrenze und einen Ablauf hat, ob die Zulassung relevante Unterschiede in der Arbeitsgröße berücksichtigt und ob es eine klare Antwort gibt, wenn eine Aufgabe nicht angenommen wird. Stellen Sie außerdem sicher, dass Prioritäten keine Klasse ohne Service lassen, Abbrüche im richtigen Zustand gemessen werden und die Messwerte lokale Wartezeit und Verarbeitung auf Anbieterseite getrennt erfassen.

Bewahren Sie schließlich die Unterscheidung zwischen Laststeuerung und Fehlerbehandlung. Die Zulassungssteuerung legt fest, wie viel Nachfrage hereinkommt und wie viel Arbeit wartet. Wiederholungen legen fest, wie nach einem Fehler oder einem unklaren Ergebnis reagiert wird. Ein robustes System braucht miteinander vereinbare Richtlinien für beide Phasen, aber eine ersetzt nicht die andere: Nehmen Sie zunächst nicht mehr Arbeit an, als Sie bewältigen können, und legen Sie anschließend separat fest, wie auf Fehler reagiert wird.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.