Betrieb verteilter Inferenzsysteme im großen Maßstab — Nishant Gupta & Naman Ahuja, Meta
AAI Engineer
Computing/SoftwareInternet Technology
Transcript
00:00:00Guten Morgen zusammen. Willkommen zum ersten Influence-Talk am letzten Tag der AI Engineering
00:00:17World Fair. Mein Name ist Nishan Gupta und neben mir steht heute mein Co-Referent Naman Ahuja.
00:00:23Wir arbeiten bei Meta an der Entwicklung der Infrastruktur für Effizienz, Training und Inferenz.
00:00:27Heute sprechen wir darüber, wie man verteilte Inferenzsysteme im großen Maßstab betreibt.
00:00:32Wie wir alle wissen, ist Inferenz längst nicht mehr nur ein Forschungsartefakt, das in ein Produkt gegossen wird.
00:00:37Es ist eine grundlegende Hyperscale-Infrastruktur-Workload, die extrem schnell wächst.
00:00:43Der Inferenz-Traffic übertrifft bereits die größten Microservices der Welt,
00:00:47und die Wachstumsrate ist höher als bei jeder anderen Workload bisher.
00:00:54Spulen wir mal zurück ins Jahr 2008 und vergleichen das KI-Zeitalter mit der Cloud-Ära.
00:01:00Um 2008 begann die Cloud mit Angeboten für virtuelle Maschinen.
00:01:05Die interessante Ingenieursleistung war damals die Virtualisierung.
00:01:07Mit der Zeit verlagerte sich der Wert im Stack nach oben, zu den Schedulern – Borg, Kubernetes, Mesos.
00:01:14Dann zu Service Meshes, Autoscalern und verschiedenen darauf aufgebauten Plattformen.
00:01:18Die Orchestrierungsschicht war es schließlich, die den eigentlichen Wert und die Komplexität ausmachte.
00:01:24KI befindet sich genau auf demselben Weg, nur komprimiert auf die letzten paar Jahre statt auf ein Jahrzehnt.
00:01:30Wir haben mit einfachen Modellen auf GPUs angefangen.
00:01:33Dann erlebten wir die Entwicklung von Model-Serving-Frameworks wie VLLM, TorchServe und Triton. Und jetzt sehen wir live das Entstehen der Orchestrierungsschicht für Routing, KV-Cache-Management, Prefill-Decode-Entkopplung und Multi-Modell-Multiplexing.
00:01:51In dieser nächsten Phase des KI-Zeitalters geht es nicht mehr nur um die besten Modelle, Kernel oder Optimierungen.
00:01:57Es geht um das gesamte Ökosystem.
00:01:58Es geht um die Control Plane und die Orchestrierung – und genau darauf konzentrieren wir uns in diesem Talk.
00:02:06Sprechen wir also ein wenig über die Bevölkerungsexplosion bei Agenten-Anfragen.
00:02:09Beim klassischen Web-Serving vor den KI-Inferenz-Workloads skalierte die Kapazität je nach Workload-Typ nahezu linear mit den Nutzern.
00:02:17Doppelte Nutzerzahl bedeutete meist doppelte QPS und doppelte Infrastruktur ohne Optimierungen. Kapazitätsplanung war hauptsächlich eine Tabellenkalkulation.
00:02:28Bei diesem neuen Agenten-Serving skaliert die Kapazität mit der Anzahl der Nutzer mal der Anzahl der Aufrufe pro Nutzer mal der Anzahl der Tokens – was je nach Modell, Optimierungen und Hardware-SKU variiert.
00:02:40Ein Chatbot hat vielleicht einen Modellaufruf pro Zug, was sich bei Copiloten auf 10 bis 20 und bei Forschungsagenten auf 50 erhöht. Bei autonomen Workloads ohne menschliches Eingreifen sind es heute Tausende solcher Aufrufe.
00:02:54Die wichtigste Erkenntnis ist: Man kann Kapazitäten für Agenten nicht wie für Microservices planen.
00:03:00Wir müssen elastisch denken und Workload-bewusstes Scheduling sowie Admission Control implementieren.
00:03:08Gehen wir nun etwas genauer auf die Unterschiede, Vor- und Nachteile von traditionellem Microservice-Serving im Vergleich zu modernem Inferenz-Serving in diesen Schlüsseldimensionen ein.
00:03:19Die Anfragenstruktur:
00:03:20Microservices gehen von kurzen, einheitlichen Anfragen aus. Bei den LLM-Anfragen in unseren Workloads sehen wir jedoch Schwankungen von 50 bis 100.000 Tokens mit völlig unterschiedlichen Rechenprofilen zwischen Prefill- und Decode-Phase.
00:03:33Zum Batching: Klassische Stacks für Microservices haben Stacking und Batching meist nur auf der Load-Balancer-Ebene gemacht, falls überhaupt.
00:03:40LLM-Serving erfordert jedoch kontinuierliches In-Flight-Batching, da der Durchsatz sonst um eine Größenordnung oder mehr einbricht.
00:03:48Zustand:
00:03:49Die meisten klassischen Microservices waren zustandslos, wenn man von der Speicherschicht absieht.
00:03:54LLM-Serving benötigt jedoch einen gewaltigen Zustand pro Anfrage, den KV-Cache, der sehr teuer im Aufbau und noch teurer beim Verwerfen ist.
00:04:02Skalierungseinheiten:
00:04:03Skalierungseinheiten:
00:04:05Bei traditionellen Microservices konnten wir diese auf günstigen CPUs in Pods ausführen.
00:04:11Für moderne Inferenz müssen wir jedoch auf GPUs laufen, die 100-mal teurer und 10-mal langsamer in der Beschaffung sind. Wir können sie nicht einfach beiläufig überprovisionieren.
00:04:20Andernfalls führt das zu enormer Verschwendung.
00:04:23Ausfallmuster:
00:04:25Bei traditionellen Microservices, wie die meisten von uns sie in den letzten Jahren gebaut haben, konnten wir einen Host oder Pod bei einem Absturz einfach neu starten.
00:04:34Wir konnten den Zustand bei Bedarf neu aufbauen.
00:04:36Bei der Modell-Inferenz dauert es jedoch extrem lange, von einem Kaltstart zu einem Warmstart zu gelangen.
00:04:42Wenn eine GPU mitten im Decode-Schritt ausfällt, kann sie Tausende aktiver Tokens verlieren, was zu Warteschlangenstaus führt.
00:04:50Fazit ist: Der Engpass ist nicht nur das Modell.
00:04:53Es ist die Orchestrierung selbst.
00:04:58Wie wir an diesen verborgenen Entscheidungen hinter einem Prompt sehen: Bei einer Agenten-Anwendung sind hinter den Kulissen etliche Schritte nötig.
00:05:06Wir müssen authentifizieren.
00:05:07Wir müssen je nach Anfragetyp ein Modell auswählen.
00:05:09Wir müssen die Region auswählen, wohin sie geht.
00:05:11Wir müssen Admission Control durchführen.
00:05:12Wir müssen einen Cache-Lookup machen.
00:05:14Wir müssen die Anfrage auf der GPU ausführen.
00:05:17Wir müssen Batching betreiben.
00:05:18Und es sind noch viele weitere Schritte beteiligt.
00:05:19Wie wir sehen, erfordert von all diesen Schritten nur ein einziger das Modell: der Prefill-Decode-Schritt.
00:05:25Egal ob es sich um entkoppelte Inferenz handelt oder nicht.
00:05:29Die anderen Schritte betreffen die Infrastruktur.
00:05:31Die Intelligenz mag im Modell liegen, aber Wirtschaftlichkeit, Zuverlässigkeit und Nutzererlebnis hängen von der Infrastruktur ab.
00:05:38Deshalb haben viele Plattformteams in zahlreichen Unternehmen einen viel größeren Einfluss auf Produktqualität und Erfolg als je zuvor.
00:05:50Die meisten von uns in diesem Raum verfügen über tiefes Fachwissen in ein, zwei oder drei Schichten.
00:05:54Wir sind vielleicht für Kernel oder Kernel-Optimierungen zuständig.
00:05:57Oder für das Routing oder das Produkt selbst.
00:05:59Oder wir betreiben die GPU-Infrastruktur oder den Cluster selbst.
00:06:03Aber die wenigsten von uns haben den gesamten Stack betrieben oder durchgängig durchdacht.
00:06:08Wie Sie an diesen Schichten sehen können, sind diese nicht neu.
00:06:11Es gibt sie schon seit 20 Jahren oder länger.
00:06:13Neu ist die Kombination und die Verkopplung untereinander.
00:06:18Eine Entscheidung auf Routing-Ebene kann die Cache-Hit-Rate auf Modellebene verändern, was die Batch-Zusammensetzung ändert, was die GPU-Auslastung beeinflusst, was wiederum die Autoscaling-Entscheidung verändern kann.
00:06:32Alles ist also miteinander verwoben.
00:06:33Wenn wir Leistungsabfälle bei Inferenz-Workloads haben, reicht es nicht zu verstehen, was auf der Cache-Ebene oder bei Admission Control passiert ist.
00:06:41Wir müssen den Stack von oben bis unten betrachten.
00:06:43Wenn wir einen Engpass sehen, ist es extrem wichtig zu verstehen, auf welcher Schicht er liegt, um gezielt zu investieren.
00:06:54Gehen wir nun genauer darauf ein, wie ein Prompt funktioniert. Wenn wir einen Prompt für eine Anwendung haben – egal ob zur Bildgenerierung, für eine Forschungsaufgabe oder eine komplexe Multi-Agenten-Orchestrierung –, umfasst das mehr oder weniger diese Schritte:
00:07:08Der Prompt geht an das Gateway.
00:07:10Dann geht er zum Router, der einen Cache-Lookup macht, falls die Anfrage bereits bekannt ist.
00:07:17Danach geht es an die Scheduler, die entscheiden, auf welchem GPU-Cluster und auf welcher Hardware die Ausführung erfolgt.
00:07:22Das kann NVIDIA, AMD oder ein eigener Chip sein. Von dort geht es zur passenden Serving-Runtime – VLLM, SGLang oder was auch immer verwendet wird.
00:07:30Anschließend streamen wir die Antwort gemäß den SLO-Profilen für Time-to-First-Token und Zeit zwischen den Tokens zurück zum Nutzer, während wir den gewünschten Durchsatz sicherstellen.
00:07:41Wie wir sehen, verhält sich diese Inferenz wie eine distributed Transaction.
00:07:45Jeder Pfeil in diesem Diagramm ist ein Network Hop.
00:07:47Jeder dieser Hops kann einen Retry ausführen.
00:07:50Er kann ins Timeout laufen.
00:07:51Er kann ein Fallback ausführen.
00:07:53Er kann sogar fehlschlagen.
00:07:54Jeder dieser Hops hat SLOs und streamt Daten an den Nutzer zurück.
00:08:00Bei Fehlern ist die Semantik von Teilausfällen daher viel schwieriger zu handhaben als bei einem normalen RPC-Aufruf.
00:08:06Stellen Sie sich vor, wir haben bereits 200 Tokens an den Nutzer gestreamt und plötzlich wird ein GPU-Host wegen einer geplanten oder ungeplanten
00:08:15Wartung verdrängt.
00:08:16Wir können nicht einfach neu versuchen.
00:08:17Wir müssen das ganzheitlich betrachten.
00:08:19Deshalb können wir Zuverlässigkeit nicht am Edge-Knoten aufbauen.
00:08:23Sie muss eine Eigenschaft der Control Plane sein, da nur sie den gesamten Workflow überblickt.
00:08:31Sprechen wir nun über Scheduler, einige Optimierungen und wie wir darüber nachdenken können.
00:08:37Bei traditionellen Microservices haben wir das Bin-Packing über drei oder vier Dimensionen betrachtet.
00:08:43Sei es CPU, Arbeitsspeicher oder über vier Domänen hinweg, je nachdem, ob man AWS oder eine eigene Cloud nutzt.
00:08:52Für die Inferenz muss der Scheduler beim Einplanen einer Anfrage jedoch mindestens sieben Achsen berücksichtigen.
00:08:59Er muss den GPU-Typ kennen.
00:09:00Es kann etliche heterogene Hardware-Typen im Cluster geben, H100 vs. A100 vs. B200, mit unterschiedlichen Netzwerk-Topologien.
00:09:09Er muss den HBM-Puffer und den Zustand des KV-Cache kennen.
00:09:13Die Modellgewichte: Ob sie bereits geladen sind, ob sie kalt sind oder ob wir einen Kaltstart durchführen müssen.
00:09:19Er muss die Priorität des Mandanten kennen.
00:09:21Auf einem Multi-Tenant-Cluster können viele Mandanten mit unterschiedlichen SLO-Profilen laufen.
00:09:27Wir müssen uns auch des Workflow-Kontexts bewusst sein.
00:09:30Befinden wir uns im dritten Denk-Schritt, der bereits X Dollar gekostet hat, oder stehen wir am Anfang und können den Workflow bei Überlastung abbrechen?
00:09:39Wir müssen auch über das Latenzbudget nachdenken, je nach Art der Agenten-Anwendung, die wir bauen.
00:09:44Das führt uns zu der Idee, dass wir agentenbewusstes Scheduling implementieren müssen.
00:09:49Wir müssen sicherstellen, dass wir eine Aufgabe dort platzieren, wo sie am schnellsten und günstigsten abgeschlossen wird, statt auf einer zufälligen GPU.
00:09:58Ein konkretes Beispiel: Der Scheduler muss wissen, dass sich Anfrage R in Schritt drei eines fünfstufigen Workflows befindet,
00:10:05und in Schritt ein und zwei bereits X plus Y Dollar verbraucht hat.
00:10:09Wenn Schritt drei fehlschlägt, wird der gesamte Workflow abgebrochen und all diese Rechenressourcen wurden verschwendet.
00:10:14Deshalb ist workflowbewusste Orchestrierung extrem wichtig,
00:10:18da sie die Zulassungsentscheidungen, die Priorität und die Retry-Logik verändert.
00:10:25Sprechen wir nun über Optimierungen.
00:10:27Ich werde nicht zu tief auf all die einzelnen Optimierungen eingehen.
00:10:29Es gibt bereits viel Forschung dazu, aber ich möchte ein Framework teilen,
00:10:34das ich gerne nutze und das sich in vier Quadranten unterteilen lässt.
00:10:40Erstens: Können wir die Arbeit vermeiden?
00:10:42Das heißt: Können wir sie durch Caching wie Prefix-Caching, Response-Caching oder semantisches Caching komplett überspringen?
00:10:48Zweitens: Können wir die Arbeit teilen?
00:10:51Können mehrere Anfragen Rechenleistung durch Batching gemeinsam nutzen?
00:10:54Denken Sie an Continuous Batching, Prefill-Decode, Chunked Prefill oder Speculative Decoding.
00:10:59Drittens: Können wir die Arbeit verlagern?
00:11:01Können wir sie an ein günstigeres Modell oder näher zum Nutzer senden?
00:11:05Können wir sie größtenteils durch Routing an ein kleineres Modell, eine günstigere Region oder mit anderen Techniken umleiten?
00:11:12Und schließlich: Können wir die Arbeit verzögern?
00:11:13Können wir durch Zugangssteuerung und Warteschlangen auf einen besseren Moment warten? Das erfordert, dass wir die Prioritätsklassen dieser Anfragen verstehen und fristbewusstes Scheduling implementieren.
00:11:25Dieses Framework ist sehr mächtig, da es sich auf verschiedene Stacks übertragen lässt.
00:11:29Sie nutzen vielleicht vLLM, SGLang oder TensorRT, aber jede Technik passt in einen dieser Quadranten.
00:11:35Wann immer wir also über eine Optimierung unseres Modells nachdenken, müssen wir einen Vergleich mit den bisherigen Techniken anstellen
00:11:41und sehen, wie all dies ineinandergreift.
00:11:47Wenn wir über Skalierung nachdenken, ist nicht nur die Leistung des Modells wichtig.
00:11:51Wir müssen auch an die Kosten, die Wirtschaftlichkeit denken.
00:11:54An dieser Stelle ist es wichtig zu verstehen, welche Metrik wir optimieren wollen.
00:11:58Denn die Kosten sind nicht nur die Kosten für die GPU oder das Modell.
00:12:02Es sind die Kosten all dieser Parameter: Wiederholungsversuche, Speicher, Ausfälle, Netzwerk und natürlich die Betriebskosten der Entwicklung.
00:12:09Wichtig ist zu verstehen, was der Schlüsselindikator (KPI) für Ihr Produkt ist, der den Nutzern einen Mehrwert bringt.
00:12:17Es geht also nicht darum, nur die Kosten pro Token oder Kosten pro Anfrage zu optimieren.
00:12:22Wir müssen die Kosten pro erfolgreicher Aufgabe optimieren, denn das ist es, was den Nutzern wirklich wichtig ist.
00:12:26Und wenn Sie das optimieren können, sinken die Gesamtkosten für das Produkt und die Nutzer sind viel zufriedener.
00:12:36Sprechen wir nun über Zuverlässigkeit – ein wenig darüber, wie man Kaskadenausfälle verhindert.
00:12:43Bei Ausfällen geht es nie nur darum, dass eine GPU belegt ist oder ausfällt.
00:12:46Das Interessante daran ist die Rückkopplungsschleife, die darauf folgt.
00:12:49Eine GPU kann an Leistung verlieren, die Latenz steigt, der Client versucht es erneut, die Warteschlange wächst, die gesunden GPUs geraten an ihre Grenzen – was zu noch mehr Wiederholungsversuchen und großflächigen regionalen Ausfällen führt.
00:13:02Das ist der klassische Kaskadenausfall, aber bei einer generativen Anwendung mit einer Besonderheit: dem KV-Cache.
00:13:09Wir können nicht einfach beiläufig neu starten oder auf einen anderen Cluster umleiten.
00:13:13Ein kalter Pool muss erst aufgewärmt werden, bevor er Datenverkehr aufnehmen kann. In dieser Zeit muss der heiße Pool all diese Anfragen abfangen.
00:13:20Deshalb ist es wichtig, die Unterbrechungsmechanismen sehr bewusst zu gestalten.
00:13:24Circuit Breaker auf Routing-Ebene, Zugangssteuerung statt bloßem Warten und Lastabwurf gekoppelt an die Warteschlangentiefe – nicht nur an die CPU- oder Speicherauslastung.
00:13:34Ebenso müssen wir über Budgets für Wiederholungsversuche nachdenken, denn ohne diese Überlegungen können die Kosten extrem schnell skalieren.
00:13:43Nun übergebe ich an meinen Co-Referenten Naman für den Rest des Vortrags.
00:13:50Vielen Dank.
00:14:20Ich übergebe an meinen Co-Referenten Naman.
00:14:22Ich übergebe an meinen Co-Referenten Naman.
00:14:25Ich übergebe an meinen Co-Referenten Naman.
00:14:26Ich übergebe an meinen Co-Referenten Naman.
00:14:27Ich übergebe an meinen Co-Referenten Naman.
00:14:28Ich übergebe an meinen Co-Referenten Naman.
00:14:29Ich übergebe an meinen Co-Referenten Naman.
00:14:30Ich übergebe an meinen Co-Referenten Naman.
00:14:31Ich übergebe an meinen Co-Referenten Naman.
00:14:32Ich übergebe an meinen Co-Referenten Naman.
00:14:33Ich übergebe an meinen Co-Referenten Naman.
00:14:34Ich übergebe an meinen Co-Referenten Naman.
00:14:35Ich übergebe an meinen Co-Referenten Naman.
00:14:36Ich übergebe an meinen Co-Referenten Naman.
00:14:54Okay, das funktioniert wohl.
00:14:57Entschuldigung für .
00:14:58Sobald die Inferenz einen Produktionsmaßstab erreicht,
00:15:00sieht sie viel mehr wie ein verteiltes System aus.
00:15:03Wir rufen nicht mehr einfach nur ein Modell auf.
00:15:06Es ähnelt eher einem klassischen Problem verteilter Systeme.
00:15:09In verteilten Systemen sprechen wir über Warteschlangen, Scheduling,
00:15:13Autoskalierung, Fehlersolierung.
00:15:14Das sind einige der Dimensionen.
00:15:16Bei der Inferenz gibt es all diese Probleme,
00:15:18aber jetzt kommen neue Rahmenbedingungen hinzu.
00:15:20Statt CPU und Speicher alleine haben wir CPU, HBM, KV-Cache
00:15:25und Kosten pro erfolgreicher Aufgabe.
00:15:27Die entscheidende Frage lautet also:
00:15:28Woher weiß die Plattform, was als Nächstes zu tun ist?
00:15:31Und hier kommt die Observability ins Spiel.
00:15:34Es geht nicht nur um Dashboards.
00:15:35Es geht darum, Eingangssignale für den Regelkreis zu liefern.
00:15:39Telemetrie, Daten, Analysen – Analysen treiben Entscheidungen an,
00:15:43führen zu Änderungen bei Scheduling sowie Routing,
00:15:45und am Ende wiederholen wir den Prozess einfach.
00:15:47Ich gebe einen Überblick über einige wichtige Metriken.
00:15:50Die erste ist die Time to First Token,
00:15:52die zeigt, wie viel Zeit es wirklich dauert,
00:15:56bis die erste Antwort eintrifft.
00:15:58Dann haben wir den Auslastungsgrad,
00:16:00der verrät, ob Speicher oder Rechenleistung der Engpass ist.
00:16:04Wir haben den Erfolg pro Dollar, der zeigt,
00:16:06ob die Plattform tatsächlich Ergebnisse liefert
00:16:08und effizient arbeitet.
00:16:10Und schließlich die Ende-zu-Ende-Latenz,
00:16:12die angibt, wie viel Zeit
00:16:15über den gesamten Anfragepfad hinweg verbraucht wird.
00:16:19Es gibt einen zentralen Zielkonflikt zwischen Latenz, Kosten und Durchsatz.
00:16:22Man kann nicht einfach alles davon haben.
00:16:24Das ist sehr analog zum CAP-Theorem.
00:16:26Wenn ich die Batch-Größe erhöhe,
00:16:28verbessere ich den Durchsatz und die Kosteneffizienz,
00:16:31aber ich verschlechtere womöglich die Tail-Latenz.
00:16:33Wenn ich Spekulatives Dekodieren nutze,
00:16:35kann ich die Latenz verbessern, aber es entsteht zusätzlicher Rechenaufwand.
00:16:38Letztendlich steigen dadurch die Kosten pro Token.
00:16:41Und schließlich kann ich ein einfaches, kleineres Modell nutzen.
00:16:44Damit kann ich Latenz und Kosten reduzieren,
00:16:45aber die Antwort wird eine geringere Qualität haben.
00:16:48Am Ende mache ich Fehleranalysen und Neuversuche,
00:16:50was die Kosten wieder nach oben treibt.
00:16:52Jede Serving-Entscheidung verschiebt
00:16:54das System an einen Punkt in diesem Dreieck.
00:16:56Und unsere Aufgabe ist es, die perfekte Einstellung zu finden.
00:16:58Es ist jetzt im Grunde reine Optimierungssache.
00:17:03Das ist die Richtung, in die sich die Branche gerade bewegt.
00:17:05Inferenz benötigt eine eigene Control Plane.
00:17:07Alles, was wir besprochen haben – Routing, Batching, Caching,
00:17:10Scheduling, Zuverlässigkeit –
00:17:12kann nicht mehr als getrennter Stellregler fungieren.
00:17:15Sie konvergieren in eine logische Schicht.
00:17:17Nennen wir sie eine Inferenz-Control-Plane.
00:17:19Früher haben wir VMs in verteilten Systemen verwaltet.
00:17:21Wir haben autoskalierende Scheduler.
00:17:23Und wir hatten Kubernetes, das all das in eine Control Plane verwandelt hat.
00:17:27Die Inferenz durchläuft jetzt denselben Wandel.
00:17:30Modelle werden zu Ressourcen.
00:17:32GPU, KV-Cache, Token, Latenz und Kosten werden nun zuteilungsgesteuert.
00:17:36Die Control Plane entscheidet, welche Modelle welche Anfrage bedienen
00:17:40und wie diese gebündelt werden.
00:17:42Ob wir diese Schicht intern bauen,
00:17:44Open Source nutzen oder von einem Anbieter beziehen –
00:17:46das wesentliche Design besteht darin, davon auszugehen, dass diese Schicht existieren wird.
00:17:50Diskutieren wir nun darüber, ob einige der betrieblichen Lektionen,
00:17:53die wir in der KI-Infrastruktur gelernt haben,
00:17:55hier anwendbar sind.
00:17:57Die erste Lektion lautet: Infrastruktur-Engpässe
00:18:00zeigen sich in der Regel vor Modell-Engpässen.
00:18:02In der Produktion können viele Ausfälle auftreten,
00:18:04aber sie liegen oft einfach an Scheduling und Routing
00:18:07oder an Kapazitätsengpässen.
00:18:08Diese stehen also nicht im Zusammenhang mit der Inferenz.
00:18:10Es handelt sich um Infrastrukturprobleme.
00:18:12Dann haben wir die Elastizität.
00:18:14Wir brauchen Elastizität im System.
00:18:15Wir können mehr GPUs einsetzen, aber das wird das Problem nicht wirklich lösen.
00:18:18Wir kaschieren das Problem nur.
00:18:20Dann unsere Lösung für Scheduling-Entscheidungen:
00:18:24Effizienz durch gezielte Steuerung.
00:18:26Dieselbe Flotte kann sehr optimal liefern,
00:18:28je nachdem, wie Sie die Aufgaben terminieren
00:18:30oder wie Sie sie bündeln.
00:18:31Dann haben wir Regelkreise, die manuelle Prozesse schlagen.
00:18:35Die Plattform muss erfassen, erkennen
00:18:37und sich automatisch an das System anpassen.
00:18:39Wichtigste Erkenntnis: Optimieren Sie nicht für Token.
00:18:43Optimieren Sie für erfolgreiche Aufgaben.
00:18:48Das ist der umfassendere Wandel, den ich Ihnen mitgeben möchte.
00:18:51In der ersten Phase der KI-Infrastruktur ging es um bessere Modelle.
00:18:54Wir haben viel Zeit in die Verbesserung unserer Modelle investiert,
00:18:56sie intelligenter gemacht
00:18:58und bessere Benchmarks entwickelt.
00:19:00Die aktuelle Phase dreht sich um schnellere Inferenz,
00:19:03geringere Latenz, besseres Batching
00:19:05und eine effizientere GPU-Auslastung.
00:19:08Aber die nächste Phase dreht sich um Orchestrierung.
00:19:10Das bedeutet: GPU, Speicher, Cache und alles andere
00:19:13sind nur noch Ressourcen,
00:19:14und sie müssen geplant und gesteuert werden.
00:19:17Die Teams, die das frühzeitig verstehen,
00:19:19werden die Infrastruktur für die Zukunft bauen.
00:19:21Der abschließende Gedanke lautet also:
00:19:23Infrastruktur ist kein bloßes Bereitstellungsproblem mehr.
00:19:25Es ist ein Orchestrierungsproblem.
00:19:27Vielen Dank.
00:19:29Vielen Dank.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video