Unternehmensweite Bereitstellung von LLM-Reasoning-Gateways: Wir haben die Fehlerrate von 429 auf 0 Prozent reduziert und dabei 28 Prozent der Kosten eingespart.

Im letzten Monat, während des Black Friday-Sales, haben drei Mitglieder unseres Cross-Border-E-Commerce-Technikteams in Singapur 36 Stunden lang in der Überwachungsstelle gearbeitet. Sie verfolgten die Kurve der Erfolgsrate der Anfragen – und waren fast davon überwältigt. Letztes Jahr, zu derselben Zeit des großen Sales, waren wir aufgrund der Bandbreitenbeschränkungen eines einzelnen LLM-Dienstanbieters in Schwierigkeiten.13 Prozent der Anfragen zur Generierung von Produktbeschreibungen führen direkt zu einem Fehlercode 429.Der Hintergrund des Geschäfts ist seit fast 4 Stunden down, und allein die Kundenbeschwerden belaufen sich auf über 2000.

Zuerst müssen wir verstehen: Was genau ist ein Enterprise-Level-Deployment-Inference-Gateway?

Es handelt sich nicht um ein hochentwickeltes neues Framework, sondern im Grunde genommen um eine Schicht zur Verkehrssteuerung, die zwischen Ihren Geschäftsdiensten und den APIs der verschiedenen LLMs (Large Language Models) liegt. Die Kernparameter sind sehr einfach zu verstehen:Unter normaler Belastung darf die Scheduling-Zeitverzögerung nicht mehr als 10 ms betragen.Wenn man die Grenzen überschreitet, bedeutet das, dass man dem Geschäft nur im Weg steht.

Drei tatsächliche Vorteile, die wir aus unseren Fehlern gezogen haben

• Zuerst haben wir das Risiko der Bandbreitendrosselung direkt beseitigt: Wir verbinden uns jetzt gleichzeitig mit drei führenden LLM-Anbietern, und das Gateway verteilt die Anfragen automatisch an den Knoten mit der aktuellen ausreichenden Quota und der schnellsten Antwortzeit. Die Spitzenwerte des QPS am Black Friday dieses Jahres waren 2,3-mal höher als im letzten Jahr, und es ist kein einziges Mal zu einem massiven Ausfall (429) gekommen.
• Zweitens ist der Kostenverfall deutlich sichtbar: Wir leiten Anfragen für Produktetiketten mit niedriger Priorität automatisch an kleinere Modelle mit besserem Kosten-Nutzen-Verhältnis weiter, ohne dass der Geschäftscode geändert werden muss. In sieben Tagen konnten die Token-Kosten direkt um 28% eingespart werden.
• Zuletzt wurde die Arbeit am Backend reduziert: Früher musste man bei jedem Wechsel des Modells oder der Hinzufügung eines neuen Dienstanbieters die Schnittstellen in drei Geschäftsmodulen einzeln anpassen. Jetzt wird alles auf der Gateway-Ebene konfiguriert, und das erledigt man in kürzester Zeit.

Schauen Sie nicht nur auf die Vorteile – diese 3 Fallstricke haben wir wirklich festgetreten.

In der ersten Woche nach der Veröffentlichung gab es bereits einen Unfall: Nachdem die automatische Fallback-Funktion aktiviert wurde, leitete der Gateway eine Reihe von hochprioritären, personalisierten Textanfragen, die eigentlich GPT-4 nutzen sollten, an einen weniger leistungsfähigen kleinen Modell um. Dadurch wurden über 200 Werbetexte der Händler als unqualifiziert eingestuft, was zu einem Schaden von etwas weniger als 10.000 Werbe-Gutscheinen führte. Erst später stellten wir fest, dass nicht alle Anfragen für eine automatische Herabstufung geeignet sind und dass in hochsensiblen Szenarien zusätzliche Überprüfungsregeln erforderlich sind.

Es gibt noch viele Kostenaspekte, die nicht erwähnt wurden: Wenn Ihre QPS-Werte über einen längeren Zeitraum unter 10 liegen, sind die Kosten für den Server und die Wartung des Gateways selbst höher als die Kosten für hochwertige LLM-Dienstleistungen bei Anbietern. In diesem Fall macht es keinen Sinn, das Gateway unbedingt einzusetzen.

Außerdem glauben Sie nicht an diesen Unsinn von „voll funktionsfähig und sofort einsatzbereit“. Wir haben drei Open-Source-Gateways ausprobiert, und die Standardverteilungsregeln für den Datenverkehr passten überhaupt nicht zu den Anforderungen des E-Commerce-Szenarios. Allein die Anpassung der Gewichtsregeln hat ganze zwei Tage in Anspruch genommen.

Wer sollte es sein? Wer braucht wirklich keine Zeit zu verschwenden?

Geben Sie einfach die Bewertungskriterien an, ohne sich zu zieren:

• Eines der Kriterien, die berücksichtigt werden können, ist, wenn die tägliche Anzahl der LLM-Anfragen mehr als 10.000 beträgt, wenn mehr als zwei Modelle gleichzeitig verwendet werden, oder wenn die Anforderungen an die Verfügbarkeit des Services über 99,9 % liegen.
• Wenn Ihr Team eine kleine Start-up-Unternehmen mit weniger als 5 Mitarbeitern ist, Ihre Kerngeschäfte nicht stark an die Nutzung großer Modelle gebunden sind und die monatlichen Kosten für LLMs nicht höher sind als das Monatsgehalt eines Backend-Entwicklers, dann sollten Sie auf eine enterprise-level Deployment-Lösung verzichten. Es ist am kostengünstigsten, direkt die nativen APIs der Dienstanbieter zu verwenden.

Zwei praktische Tipps für den ersten Einsatz

Bitte fangen Sie nicht mit einer sofortigen Umstellung des gesamten Datenverkehrs an. Starten Sie zunächst mit 10 Prozent des Datenverkehrs mit niedriger Priorität und führen Sie eine Woche lang eine Graustufen-Testphase durch. Konzentrieren Sie sich dabei auf zwei wichtige Indikatoren: Ob es zu wiederholten Anfragen kommt und ob die durch die Scheduling-Prozesse verursachten Verzögerungen tatsächlich im akzeptablen Bereich liegen. Wir haben damals zuerst den Datenverkehr für die automatischen Nachverkaufsrückmeldungen getestet und erst nach drei Tagen, als wir sicher waren, dass es keine Probleme gab, die Kerngeschäftsprozesse umgestellt.

Frage: Soll man selbst einen Gateway von Grund auf entwickeln? Antwort: Es sei denn, Ihr Team hat jemanden, der gerade nichts zu tun hat, ist es besser, eine fertige Open-Source-Version zu nehmen und anzupassen. Das spart mindestens zwei Monate Zeit und die Stabilität ist auch höher.