LLM-Gateways in die Produktion bringen: Architektur, Kompromisse und harte Lektionen — Kanish Manuja, Twilio
AAI Engineer
Computing/SoftwareManagementInternet Technology
Transcript
00:00:00Ich bin Ganesh Manuja. Ich bin Principal Engineer bei Twilio. Fangen wir mit einer kurzen Handzeichen-Abfrage an.
00:00:20Wer von Ihnen hat schon mal die Nachricht gesehen: Etwas ist schiefgelaufen, bitte versuchen Sie es noch einmal?
00:00:27Nun, wir haben ein paar Glückliche und ein paar, die ein gutes Mittagessen hatten.
00:00:33Hinter dieser einfachen Nachricht verbirgt sich eigentlich ein sehr komplexes System, das Ihnen diese Nachricht trotz ausgefallener Modellanbieter bereitstellt.
00:00:45Und genau das wollen wir heute produktionstauglich machen oder heute besprechen.
00:00:50Was ist also ein LLM-Gateway?
00:00:52Ein LLM-Gateway ist ein Einstiegspunkt oder eine Middleware zwischen Ihren Apps und den dahinterliegenden Modellanbietern.
00:00:58Es erledigt eine Reihe von Aufgaben: Routing, Authentifizierung, Fallbacks, Ratenlimits und alle möglichen Governance-Funktionen, die Sie sich vorstellen können.
00:01:08Genau im Herzen des Gateways herrscht ein Kampf zwischen vier Dingen.
00:01:13Das sind Verfügbarkeit, Latenz, Schutzmechanismen und Kosten.
00:01:18Im Falle einer Leistungsbeeinträchtigung können Sie nicht alle vier maximieren.
00:01:22Sie müssen auswählen, was Sie wollen.
00:01:25Wenn Sie also ein LLM-Gateway nutzen, möchte ich Ihnen mit diesem Vortrag helfen, diesen Kompromiss für Ihren Anwendungsfall zu treffen.
00:01:35Und wenn Sie ein Gateway entwerfen, möchte ich, dass Sie Ihren Aufrufern und Kunden diese Hebel an die Hand geben, damit Ihre Kunden zufrieden sind.
00:01:46Beginnen wir mit der Verfügbarkeit.
00:01:50Wenn Sie nur einen einzigen Modellanbieter haben, ist dessen Obergrenze auch Ihre Obergrenze.
00:01:56Dessen Ausfall ist Ihr Ausfall.
00:02:03In der typischen Softwareentwicklung geht man mit unzuverlässigen Abhängigkeiten normalerweise durch Wiederholungsversuche um.
00:02:11Wiederholungsversuche mit exponentiellem Backoff und Jitters.
00:02:15Und wenn das alles fehlschlägt, gibt es einen Schutzschalter, der auslöst, wenn man genügend Fehler gesehen hat, und man hört auf, das verdammte Ding aufzurufen.
00:02:24Das reicht für LLMs nicht aus.
00:02:26LLMs unterscheiden sich stark von Ihren schnellen, günstigen APIs, bei denen man einfach Wiederholungen ausführt.
00:02:32Das Wiederholen einer LLM-API verbraucht Ihr Latenzbudget extrem schnell.
00:02:38Außerdem macht es keinen Sinn, einen Circuit Breaker auszulösen, wenn Sie einen anderen, völlig intakten Modellanbieter haben, zu dem Sie Daten routen können.
00:02:47Sie sollten den zweiten Modellanbieter nutzen.
00:02:48Und drittens, wie ich sagte, sind die Aufrufe langsam und teuer.
00:02:53Daher multiplizieren blinde Wiederholungsversuche nur Ihre Kosten und Ihre Tail-Latenzen.
00:02:58Was ist also eine bessere Idee hierbei?
00:03:02Es ist tatsächlich ein Fallback pro Anfrage.
00:03:05Das bedeutet, Sie können Modellanbieter A versuchen und dann nacheinander Modellanbieter B, falls Ihre Anfrage an Modellanbieter A fehlschlägt.
00:03:14Eine weitere Option, die hier in Betracht gezogen werden kann, ist das parallele Senden von Anfragen an beide Anbieter, aber das nur, wenn Sie extrem auf geringe Latenzen fixiert sind, da dies Ihre Kosten einfach verdoppelt.
00:03:26Einige der ähnlichen Circuit-Breaking-Muster gelten hier auch für LLMs.
00:03:32Wenn Sie wissen, dass Ihr Primäranbieter seit einiger Zeit ausfällt, macht es keinen Sinn, es erneut bei ihm zu versuchen.
00:03:40Sie nehmen ihn aus dem Load Balancer oder Ihrem Anfrageweg heraus, setzen ihn in eine Abkühlphase und versuchen nach einigen Minuten, ihn wieder einzubinden.
00:03:51Eine interessante Entscheidung, die Sie hier treffen müssen, ist, wo Ihre Fehlerzähler gespeichert werden.
00:03:59Sie können entscheiden, dass die Fehlerzähler im Arbeitsspeicher auf den Instanzen liegen, die Ihren Traffic bedienen, oder Sie nutzen gemeinsame Informationen, bei denen Ihre Fehlerzähler im gesamten Cluster geteilt werden.
00:04:12Es gibt Vor- und Nachteile.
00:04:14Wenn Sie schnelle Failovers wünschen, hilft ein clusterweiter Ansatz.
00:04:19Und bei instanzbasierten, lokalen Statuszählern besteht das Problem darin, dass sich Ihre Konfiguration und Ihre Erwartungen jedes Mal ändern, wenn Sie Ihre Bereitstellungsgröße anpassen.
00:04:30Das ist also etwas, das man berücksichtigen sollte.
00:04:34Was dieses saubere Diagramm nicht wirklich gezeigt hat, sind einige der anderen Stolperfallen, die ich besprechen werde.
00:04:39Fallbacks sind also nicht transparent.
00:04:41Obwohl sich die Branche auf ein OpenAI-API-kompatibles Format zubewegt, würde ich sagen, dass es immer noch Nuancen gibt.
00:04:49Sie müssen Ihre Fallbacks also wirklich gut testen.
00:04:52Sie können Unterschiede in Ihren Tool-Aufruf-Schemas, Token-Limits, Abbruchgründen und vielem mehr aufweisen.
00:04:58Mit LLM-Gateways können Sie also eine Normalisierungsschicht einrichten, die sicherstellt, dass Sie auch anbieterübergreifende Fallbacks durchführen können.
00:05:08Ein weiterer Punkt ist das Streaming.
00:05:15Im Grunde möchte niemand 30 Sekunden lang warten, bis eine Textwand vor ihm erscheint.
00:05:22Es gibt also Anwendungsfälle, in denen Streaming absolut erforderlich ist.
00:05:26Aber das hat seinen Preis.
00:05:27Sie opfern dafür Ihre Hebel.
00:05:29Sie können nicht – sobald Sie sich für Anbieter A entschieden haben, müssen Sie weiterhin bei Anbieter A bleiben.
00:05:36Sie können die Anbieter nicht mitten im Stream wechseln.
00:05:39Was auch immer an den Client gesendet wurde, ist geschehen.
00:05:42Und da kommt die Nachricht auf, dass etwas schiefgelaufen ist.
00:05:46Das ist diejenige, die Sie sehen.
00:05:48Das liegt nicht an Faulheit.
00:05:49Es ist Absicht, dass Sie das sehen.
00:05:52Und es ist einer dieser Kompromisse.
00:05:54Ich möchte noch eine andere Sache erwähnen, bei der ich erlebt habe, dass Teams immer wieder stolpern.
00:06:00Sie dimensionieren und testen ihre Primäranbieter wirklich hervorragend.
00:06:05Aber der zweite Anbieter, der Fallback-Anbieter, erhält nicht unbedingt dieselbe Aufmerksamkeit.
00:06:11Und ich würde argumentieren, dass Ihr Durchsatz, Ihre Kapazität oder Ihr Spielraum für den zweiten Anbieter oder Fallback-Anbieter sogar noch höher sein sollte.
00:06:21Denn das ist Ihre letzte Verteidigungslinie.
00:06:23Wenn dieser ausfällt, fällt Ihre Anwendung aus.
00:06:29Lassen Sie uns über Latenzen sprechen.
00:06:31Verfügbarkeitsfehler sind unübersehbar.
00:06:34Sie schlagen fehl.
00:06:36Sie erhalten einen Alarm.
00:06:37Sie werden angepiept.
00:06:38Hohe Latenzen können jedoch die stillen Übeltäter sein.
00:06:42Und sie müssen mehr Aufmerksamkeit erhalten als, wie ich sagen würde, das reine Optimieren Ihrer Dienste auf Verfügbarkeit.
00:06:49Ein wichtiger Punkt dazu.
00:06:54Ein Gateway verarbeitet möglicherweise gemischte Workloads.
00:06:58Sie können Einbettungsanfragen haben, die gerade mal weniger als eine Sekunde dauern.
00:07:04Sie können Klassifizierungsanfragen haben, die weniger als eine Sekunde dauern.
00:07:07Sie haben Chat-Anfragen, die drei Sekunden dauern.
00:07:10Und Reasoning-Anfragen, die viel Zeit in Anspruch nehmen.
00:07:13Kurzes Handzeichen.
00:07:15Kurzes Handzeichen, wenn Sie Ihre Gesamtlatenz für Ihren gesamten Dienst messen.
00:07:20Nun, das war eine Fangfrage.
00:07:23Tut mir leid.
00:07:24Das sollten Sie nicht tun.
00:07:25Das ergibt keinen Sinn.
00:07:26Es ist eine Illusion.
00:07:27Sie sollten die P99-Latenz pro Modell und Route verfolgen, nicht einen gatewayweiten Wert.
00:07:32Ein gatewayweiter Wert macht keinen Sinn, insbesondere wenn Sie gemischte Workloads ausführen.
00:07:36Und ich hoffe, für diejenigen, die die Hand gehoben haben, Sie tun das nicht.
00:07:40Eine weitere Sache, die wirklich – ich kann das nicht oft genug betonen –, ist das Festlegen von Timeouts pro Modellklasse und Route.
00:07:49Das ist die Hauptursache für stille Ausfälle.
00:07:54Wenn Sie kein Timeout haben, denkt Ihr Gateway, Ihre Anfrage wird fröhlich bearbeitet, während dem nicht so ist.
00:08:00Und ich gebe Ihnen diese Botschaft speziell im Hinblick auf Latenzen mit auf den Weg.
00:08:05Die Normalität eines Reasoning-Modells ist eigentlich der Ausfall eines Chat-Modells.
00:08:09Sie müssen die Latenz also unbedingt pro Route verfolgen.
00:08:13Okay, dies ist der schmerzhafteste Teil oder die Folie, die mir die meiste Angst eingejagt hat, nämlich Reasoning- und Router-Modelle.
00:08:24Hier ist die Latenz wirklich unvorhersehbar.
00:08:29Und Reasoning-Modelle geben Ihnen – sie sind hochgradig unbestimmt, noch unbestimmter als Ihre normalen Modelle.
00:08:40In vielen Fällen können Sie die Temperatur nicht auf Null stellen.
00:08:43Und derselbe Prompt kann zwischen zwei und 60 Sekunden dauern.
00:08:48Und wir haben in der Produktion erlebt, dass P99 plötzlich ohne ersichtlichen Grund auf 60 Sekunden anstieg.
00:08:53Auch wenn es dafür keine magische Lösung gibt, empfehle ich Ihnen, zumindest damit zu beginnen, das Reasoning-Level pro Route festzulegen.
00:09:03Router-Modelle verbergen diese Abstraktion vor Ihnen.
00:09:08Sie wählen zum Beispiel aus, welche Modelle ausgeführt werden sollen.
00:09:11Und ich kann Ihnen nur wärmstens empfehlen, Anfragen in einem unbestimmten System so weit wie möglich zu deterministischen Anfragen zu machen.
00:09:23Eine andere Idee ist das Absichern des Tail-Endes (Hedging the tail).
00:09:26Sie können eine weitere Anfrage abschicken, wenn Ihre primäre Anfrage bereits sagen wir P90 Ihres Latenzbudgets verbraucht hat.
00:09:37Dadurch lässt sich das P99-Tail-End für Ihre Dienste wirklich gut absichern.
00:09:44In Ordnung, das ist einer meiner Favoriten.
00:09:47Um Ihre Modelle sicher zu halten, müssen Sie Schutzmechanismen (Guardrails) einsetzen.
00:09:53Dazu sind Schutzmechanismen erforderlich, um Ihre Dienste vor Prompt-Injection-Angriffen zu schützen, PII-Filter einzurichten, Toxizitätsfilter zu nutzen und zu verhindern, dass die LLMs Ihre Kunden beschimpfen.
00:10:08All diese schönen Dinge.
00:10:11Aber genau wie bei Modellanbietern gibt es auch hier Kompromisse.
00:10:15Guardrails sind im Grunde wie ein weiterer Dienst.
00:10:18Der ausfallen kann.
00:10:19Der unzuverlässig sein kann.
00:10:21Und hier müssen Sie eine Entscheidung treffen.
00:10:24Wählen Sie Fail-Open oder Fail-Close?
00:10:27Wenn ich Fail-Open sage, können Sie die Anfrage auch dann noch bedienen, wenn Ihre Guardrails ausfallen.
00:10:32Bei Fail-Close blockieren Sie die Anfrage und sagen: Hey, ich bin nicht verfügbar.
00:10:36Das ist bis zu einem gewissen Grad der Kompromiss zwischen Verfügbarkeit und Sicherheit.
00:10:41Es gibt keine universelle Antwort, es hängt wirklich von Ihrem Anwendungsfall ab.
00:10:45Sie können zum Beispiel entscheiden: Wenn ein Toxizitätsfilter nicht läuft, können Sie die Anfrage trotzdem bedienen.
00:10:53Die Standardwahl sollte also der Worst-Case sein, mit dem Sie leben können.
00:11:02Es gibt einige Dinge, die Sie tun können, um das Verhalten Ihrer Systeme zu verbessern, wenn Guardrails ausfallen und die Unzuverlässigkeit der Guardrails selbst gemanagt werden muss.
00:11:17Das Erste ist das Zeitbudget.
00:11:20Ihre Anfrage sollte niemals an das Timing der Guardrails gebunden sein.
00:11:25Es sollte immer das LLM sein, das den geschwindigkeitsbestimmenden Schritt darstellt.
00:11:29Stellen Sie also sicher, dass Sie Timeouts eingerichtet haben und diese Guardrails mit einem spezifischen Zeitbudget laufen.
00:11:38Eine weitere wichtige Sache ist das Fallback.
00:11:40Sie haben es gehört – Sie wissen es wahrscheinlich, und ich habe darüber gesprochen: Wir diskutieren immer über Fallbacks in Bezug auf Modell-Anbieter.
00:11:47Aber Guardrails sind ebenfalls kritische Dienste, bei denen Sie Fallbacks in Betracht ziehen, sekundäre Anbieter und Prüfungen nutzen sowie Entscheidungen cachen können, um Ihren Dienst verfügbar zu halten, wenn ein Guardrail-Anbieter ausfällt.
00:12:03Eine weitere interessante Entscheidung, die in Bezug auf Guardrails auftaucht, ist die Platzierung der Guardrails.
00:12:10Typischerweise können Sie Guardrails auf drei Arten platzieren.
00:12:15Sie können einen Pre-Hook verwenden, bei dem die Guardrail tatsächlich auf der Eingabe läuft.
00:12:19Das ist wahrscheinlich am sichersten, fügt Ihren Anfragen jedoch serielle Latenz hinzu.
00:12:26Eine andere Möglichkeit ist parallel.
00:12:29Das ist einer meiner Favoriten, aber beachten Sie, dass Streaming hierbei nicht gut funktioniert.
00:12:35Wenn Sie also speziell strukturierte Ausgaben erzeugen, streamen Sie diese bitte nicht.
00:12:40Versuchen Sie, Latenzen einzusparen und diese Guardrails für Ihre strukturierten Ausgaben nebenläufig auszuführen.
00:12:46Eine andere Option sind Post-Hooks.
00:12:48Diese eignen sich am besten für Ausgabewischnutzung, die Überwachung Ihrer Ausgaben und so weiter.
00:12:58Bisher habe ich also all die Dinge besprochen, die in Bezug auf unsere Abhängigkeiten schiefgehen können.
00:13:06Wir haben noch nicht besprochen, dass wir tatsächlich eine weitere Abhängigkeit in den Anfragepfad selbst einbauen, nämlich das zentrale – oder eben das LLM-Gateway selbst.
00:13:15Es gibt einige Dinge, bei denen wir uns die Finger verbrannt haben und aus denen wir gelernt haben, was ich mit Ihnen teilen möchte, falls Sie an einem LLM-Gateway arbeiten oder eines nutzen.
00:13:25Das eine sind geteilte Limits.
00:13:28Stellen Sie sicher, dass Ihre API-Schlüssel pro Route und pro Anwendungsfall so granular wie möglich getrennt sind – bis hin zum feinsten denkbaren Grad.
00:13:40Ein „Noisy Tenant“ (lauter Mandant) zu haben, kann hier eines der größten Probleme sein.
00:13:47Eine weitere Sache ist Load Shedding (Lastabwurf).
00:13:50Das ist eine Funktion, bei der Sie im Rahmen Ihrer Runbooks und Game Days sicherstellen sollten, dass das genutzte Gateway Load Shedding unterstützt.
00:13:59Denn wenn Sie einen Wiederholungssturm (Retry Storm) haben, wird es wirklich schwierig, einfach zu skalieren.
00:14:03Dienste, die sich in einem Wiederholungssturm befinden, lassen sich nicht einfach hochskalieren.
00:14:07Und all diese Webserver verfügen über eine interne Warteschlange, die konfigurierbar ist.
00:14:13Stellen Sie sicher, dass sie begrenzt sind und keine unbegrenzten Anfragen annehmen können.
00:14:19Und wenn Sie eine benutzerdefinierte Logik wünschen, können Sie hier sogar eine Datenpriorisierung vornehmen, um sicherzustellen, dass unter Last Ihre wichtigsten Anwendungsfälle gut bedient werden.
00:14:29Das Letzte, was ich besprechen möchte, ist die gesamte Idee eines zentralen Gateways an sich.
00:14:38Es ist ein Single Point of Failure.
00:14:40Wenn Sie also darüber nachdenken, ein zentrales Gateway für Ihr gesamtes Unternehmen für alle LLMs zu haben, würde ich empfehlen, das zu überdenken und zu prüfen, aus welchen Gründen Sie es wollen.
00:14:52Mir ist aufgefallen, dass es in den meisten Szenarien gar nicht das zentrale Gateway ist, das sie wollen.
00:14:57Sie wollen eine zentralisierte Governance.
00:15:00Und es gibt einen Weg, das Gateway tatsächlich zu dezentralisieren und dennoch die Governance zentralisiert zu halten.
00:15:07Versuchen Sie also nicht, Ihren Traffic zu zentralisieren, aber Sie können Plugins und benutzerdefinierten Code nutzen, um Ihre Governance zu zentralisieren.
00:15:17Governance kann in Form von Kostenverfolgung und Ratelimit-Management erfolgen, und es gibt noch andere mögliche Lösungen.
00:15:24Erkunden Sie diese also, bevor Sie sich darauf einlassen, ein einziges zentrales Gateway für Ihr gesamtes Unternehmen zu errichten.
00:15:30Es kann von einem einzigen Team verwaltet werden, aber ich würde nicht empfehlen, es als eine einzige Bereitstellung für das gesamte Unternehmen auszurollen, auch wenn es verteilt ist.
00:15:43Aus diesem Grund möchte ich diesen Vortrag mit einer persönlichen Note beenden.
00:15:47Heute hat mein Sohn Geburtstag und ich stehe hier und spreche mit Fremden über Circuit Breaking.
00:15:54Das Mindeste, was Sie also für mich tun können, ist, bitte einen Vorfall für mich und für Ihre Kunden zu verhindern.
00:16:02Vielen Dank.
00:16:03Falls Sie Fragen haben, ja.
00:16:06.