Verteilte KI-Inferenz: Was Führungskräfte von Telekommunikationsanbietern wissen sollten

Die meisten Telekommunikationsanbieter operationalisieren derzeit KI. Zu den Use Cases gehören Customer Care Bots, Co-Piloten für den Netzwerkbetrieb und gemanagter AI as a Service (AIaaS) für externe Unternehmenskunden und andere Kunden. 

Herausfordernd ist die Korrelation zwischen Use Case und Business Case. Ein entscheidender Faktor sind dabei die Kosten des KI-Beschleunigers, unabhängig davon, ob es sich um eine Graphics Processing Unit (GPU), eine Tensor Processing Unit (TPU) oder eine Neural Processing Unit (NPU) handelt. Die Kosten pro Inferenz entscheiden darüber, ob diese KI-Beschleuniger die Gewinnspannen verbessern oder schmälern. Um die Kosten niedrig zu halten, ist das gewählte KI-Modell ebenso wichtig wie die Art und Weise, wie Sie das Modell bereitstellen und in einer verteilten Geo-Skala betreiben.

In einem aktuellen Artikel befassten sich Mitarbeitende von Red Hat mit den Herausforderungen bei der Inferenzbereitstellung. Sie betrachteten dies als ein Architekturproblem, das durch Datenverkehr und Skalierung und nicht nur durch die Modellgröße bestimmt wird. Dieser Blog-Beitrag fasst die Ergebnisse zusammen.

Wie sich die Kosten pro Inferenz auf Gewinn und Verlust auswirken

Jede KI-Anfrage umfasst zwei verschiedene Aufgaben auf derselben Hardware: 

• Zuerst liest das System den Prompt oder die Eingabe. Dabei kann es sich um einen Abrechnungsverlauf, ein Trouble-Ticket, ein Netzwerkprotokoll oder andere zu verarbeitende Daten handeln. 
• Anschließend generiert es die Antwort auf diese Eingabe, jeweils Token für Token.

Die Lesephase bestimmt, wie lange Nutzende auf das erste Wort warten. Die Schreibphase entscheidet darüber, ob sich das Gespräch flüssig anfühlt oder ob es häufige Unterbrechungen gibt. Die beiden Phasen erfordern unterschiedliche Ressourcenprofile und Optimierungen. Wenn sie die Ressourcen des KI-Beschleunigers gemeinsam nutzen, konkurrieren sie miteinander.

Dieser Zielkonflikt wirkt sich je nach KI-Use Case und Workload-Typ unterschiedlich auf Gewinn und Verlust aus. Beispielsweise steigen bei Customer Care Chatbots die Kosten pro Kontakt, wenn Bots stocken und Sitzungen an Mitarbeitende eskaliert werden. Bei KI-Angeboten für Unternehmen fallen SLA-Strafen (Service-Level Agreements) an, wenn Latenzzusagen nicht eingehalten werden. Zudem sinkt die Gewinnspanne bei KI-Produkten im B2B-Bereich (Business-to-Business), wenn die Kosten pro Abfrage die vertraglich vereinbarten Preise übersteigen. 

Die meisten Deployment-Fehler sind Abwägungsfehler. Sie entstehen, wenn ein Team eine Metrik optimiert, die für den Verkauf des Produkts nicht relevant ist. Die Untersuchung spezifischer Methoden zur Umsatzgenerierung durch KI kann das richtige Deployment für den jeweiligen Workload-Typ veranschaulichen.

Kundenbetreuung

Die Kundenbetreuung ist das deutlichste Beispiel. Der Datenverkehr in der Kundenbetreuung besteht aus Tausenden von kurzen, gleichzeitigen Chat-Sitzungen. Diese verwenden bei jedem Aufruf denselben Tarif und dieselbe Richtlinienpräambel wieder. Mitarbeitende von Red Hat konnten anhand der vLLM-Benchmarks von Red Hat Folgendes ermitteln:

• Durch das Aufteilen und die korrekte Größenbestimmung der Lese- und Schreibpools lassen sich die Kosten bei dieser Form des Datenverkehrs um 25 bis 40 % senken.
• Cache-bewusstes Routing ist der Planungsansatz des Open Source-Projekts llm-d. Es lieferte 2 bis 3 Mal mehr Token pro GPU und 3 bis 5 Mal niedrigere Kosten pro Token bei häufiger Wiederverwendung von Prompts.

Produktionssysteme werden dieses Ausmaß an Verbesserungen voraussichtlich nicht erreichen. Die Tendenz bestätigte sich jedoch bei den meisten von uns gemessenen Workloads. Bei Millionen von Interaktionen pro Monat kann bereits eine geringfügige Senkung der Inferenzkosten genug Kapital für den nächsten Produktzyklus freisetzen. Neue Investitionsausgaben (CapEx) für Beschleuniger sind dann nicht erforderlich.

Netzwerkabläufe

Netzwerkabläufe stellen ein entgegengesetztes Szenario dar: Es gibt nur wenige Nutzende, und die zu verarbeitenden Dokumente sind sehr lang. Bei der Analyse von Vorfällen werden dieselben Runbooks, Topologiedatensätze und Handbücher ständig neu gelesen. Der entscheidende Kostenfaktor ist daher das Caching bereits verarbeiteter Daten. Dies führt zu kürzeren Diagnosezeiten und selteneren Eskalationen an erfahrene Ingenieurteams.

Gemanagte KI für Unternehmen

Der Verkauf von KI an Unternehmenskunden fügt eine dritte Struktur hinzu: viele Mandanten, gestaffelte SLAs und Nachfragespitzen. Zwei Mechanismen können die Gewinnspanne in diesen Szenarien schützen:

• Bei der Modell-Kaskadierung werden Routineabfragen an ein kleines Modell gesendet und nur komplexe Anfragen eskaliert. Dies senkt die Cluster-Kosten um 40 bis 60 %, wenn einfache Abfragen überwiegen.
• Eine an Service Level Objectives (SLOs) gebundene Zugangskontrolle lehnt Anfragen ab, die gegen ein SLA verstoßen würden, anstatt sie in eine fehleranfällige Warteschlange zu stellen. Dies schützt die vertragliche Verlässlichkeit auch unter Hochlast.

Wie in Tabelle 1 gezeigt, können diese 3 Use Cases als Modell für die Preisstufen Gold, Silber und Bronze dienen. So müssen Kunden nicht auf einen einzigen gemeinsamen Pool von KI-Beschleunigern setzen. Zwei weitere Faktoren vervollständigen das Bild für Serviceanbieter. Sie zeigen, wie KI-Services auf spezifische Kunden zugeschnitten werden können. 

Souveräne KI mit Cloudbursting-Kapazität

Souveränitätsregeln erfordern, dass Subskriptionsdaten im Ursprungsland verbleiben. Der Ansatz, der diese Anforderung am besten erfüllt, ist eine regulierte On-Premise-Baseline mit Cloudbursting, das zwischen Spitzenzeiten inaktiv bleibt. Eine zentrale Control Plane wie Red Hat OpenShift AI sorgt für die Abstimmung der beiden Umgebungen. So hängt die Compliance nicht allein von der Konfigurationsdisziplin ab.

Edge Computing

Am Netzwerkrand mit etwa 100 gleichzeitigen Sitzungen ist ein Modell pro Beschleuniger ohne komplexes Pooling die richtige Lösung.  Komplexe Abfragen sollten über den Backhaul eskaliert werden. So folgen die Transportausgaben der Komplexität und nicht dem Volumen.

Tabelle 1. Wie Workload-Typen zu konkreten Geschäftsergebnissen führen

Diese Fragen sollten sich Anbieter stellen, wenn sie die folgenden Use Cases in Betracht ziehen:

• Kundenbetreuung: Was kostet ein vollautomatisiertes Betreuungsgespräch heute und welche einzelne Änderung beeinflusst diesen Wert am stärksten? Eine fundierte Antwort nennt die Kosten pro abgeschlossenem Kontakt, gemessen am Live-Datenverkehr. Dabei werden 1 getesteter Faktor sowie die entsprechenden Vorher-Nachher-Zahlen aufgeführt.
• Netzwerkabläufe: Wie lange warten Mitarbeitende im Engineering auf eine nützliche Antwort aus den Fehler-Logs? Werden jedes Mal dieselben Dokumente erneut verarbeitet? Eine gute Antwort zeigt auf, wie oft Runbooks und Standortprotokolle aus dem Cache bereitgestellt statt neu gelesen werden. Zudem wird der Trend bei der Zeit bis zur ersten Antwort deutlich.
• B2B-Services: Welches SLA für Unternehmen wird bei Spitzenlast zuerst verletzt? Lässt sich dies durch zusätzliche Hardware oder durch ein besseres Routing beheben? Eine fundierte Antwort benennt die betroffene Stufe aus einem Lasttest. Sie zeigt auf, dass vor einer Kaufanfrage eine Korrektur des Routings oder der Zugangskontrolle versucht wurde.
• Souveränität und Spitzenlasten: Wie viel Kapazität bleibt zwischen Spitzenereignissen ungenutzt, nur um die Regeln zur Datenresidenz zu erfüllen? Eine fundierte Antwort geben die Basisnutzung und ein Burst-Design an, das im Wartezustand keine Kosten verursacht.
• Edge und Außendienst: Welcher Anteil der Abfragen aus dem Außendienst wird an einen zentralen Cluster zurückgesendet und welche Transportkosten entstehen dabei? Eine gute Antwort gibt die lokale Lösungsrate pro Standort an. Dabei bleibt die Eskalation für Abfragen reserviert, die das Modell vor Ort nicht verarbeiten kann.

Investitionspfad

Sobald ein KI-Use Case etabliert ist, besteht der nächste Schritt darin, diesen effizient und kostengünstig zu entwickeln. Die Reihenfolge ist wichtiger als das Ziel. Jede Phase wird durch eine Messung ausgelöst, nicht durch ein Datum in der Roadmap. Jede Phase amortisiert sich, bevor die nächste beginnt:

1. Beginnen Sie mit 1 Knoten: Betreiben Sie eine Woche lang eine einzelne Serving-Instanz mit echtem Datenverkehr aus der Kundenbetreuung oder dem Netzwerk. Diese Baseline ist der Maßstab für jede spätere Entscheidung. Synthetischer Labordatenverkehr ist hierbei irreführend.
2. Fügen Sie intelligentes Routing hinzu: Ein 2. Replikat liefert weniger als das 1,8-fache des Durchsatzes von einem Replikat. Diese Lücke bedeutet, dass Anfragen auf Servern landen, die den Kontext neu lesen müssen, obwohl ein anderer Server diesen bereits bereithält. Es handelt sich um Ineffizienzen beim Routing, nicht um fehlende Kapazität. Beheben Sie diese, bevor Sie Hardware kaufen.
3. Trennen Sie die Lese- und Schreibpools: Führen Sie diesen Schritt nur aus, wenn Messungen zeigen, dass eine Phase die andere so stark einschränkt, dass die zusätzliche operative Komplexität gerechtfertigt ist.
4. Führen Sie das mandantenfähige Grid ein: Wenn mehrere Produkte und B2B-Kunden die Plattform gemeinsam nutzen, rechtfertigen die Mechanismen zum Schutz gestaffelter SLAs ihre Komplexität. Bei einer geringeren Skalierung wäre der Aufwand nicht gerechtfertigt.

Jeder Schritt setzt die Baseline zurück. Eine Strategie für die KI-Inferenz besteht aus einer Reihe von fundierten Entscheidungen und nicht aus einer einmaligen Architekturfreigabe. Serviceanbieter wenden dieses Prinzip bereits bei Funkfrequenzen an: Sie weisen Produkten mit einem Return on Investment (ROI) Kapazitäten zu, messen kontinuierlich und geben ungenutzte Ressourcen wieder frei. KI-Beschleuniger verdienen dieselbe Disziplin.

Fazit

Verteilte KI-Inferenz entscheidet darüber, ob KI-Produkte von Serviceanbietern ihre Gewinnspanne halten. Die in diesem Blog-Beitrag beschriebenen Ansätze erfordern keine riskanten Budgetzusagen. Jeder Mechanismus ist ein kalkulierter Schritt, der sich im Datenverkehr des Serviceanbieters bewähren muss, bevor der nächste folgt. Tabelle 1 zeigt, wo Sie beginnen sollten.

Wenn Sie bereit sind, dies für Ihr Portfolio in den Bereichen Kundenbetreuung, Netzwerk oder B2B umzusetzen, wenden Sie sich mit Ihren Daten an Ihr Red Hat Account Team. Mit vLLM, llm-d und Red Hat OpenShift AI setzen wir dieses Modell bereits heute bei Serviceanbietern um. Das Gespräch ist am effektivsten, wenn es von Ihren Anforderungen ausgeht und nicht von einem allgemeinen Blueprint.