Vertikale Mobilität: Inference vom MVP bis zu Trillionen-Parameter-Workloads — Sitanshu Gupta, CoreWeave
AAI Engineer
컴퓨터/소프트웨어AI/미래기술
스크립트
00:00:00Guten Tag zusammen. Ich bin Sitan Shu von Corvi. Ich werde heute über vertikale
00:00:19Mobilität sprechen. Das ist ein recht ausgefallenes Thema, der Titel, den wir uns ausgedacht haben, aber im Grunde geht es
00:00:26darum, über die Inferenzplattform zu sprechen, die wir bei Corvi aufbauen, um
00:00:30kleine bis große Modelle und verschiedene Arten von Workloads zu bedienen. Eine kurze Vorstellung zu meiner Person: Ich bin
00:00:38vor etwa vier Monaten zu Corvi gestoßen und leite dort den gesamten Bereich Inferenz. Und davor
00:00:44habe ich bei AWS Annapurna Labs alles rund ums Training geleitet, und davor Inferenz
00:00:49und Training bei Sambanova. Also eine ganze Menge Erfahrung auf diesem Gebiet. Wie
00:00:56ich Sie durch den Vortrag führen werde: Ich erkläre Ihnen die Nutzungsmodelle,
00:01:00die wir haben, und wie wir daraus abgeleitet haben, wie die Plattform aussehen sollte, damit
00:01:04wir sie nicht ständig ändern müssen, sondern die bestehende Plattform zur Bereitstellung
00:01:09von Inferenz kontinuierlich erweitern können. Und wie und warum Leistung dabei eine so wichtige Rolle
00:01:14spielt. Ich denke, ein Teil davon überschneidet sich vielleicht mit dem vorherigen Thema, das hier
00:01:20besprochen wurde. Nutzungsmodelle. Wir haben im Wesentlichen zwei Hauptnutzungsmodelle. Das eine ist Serverless,
00:01:29wo die Kunden und Verbraucher einsteigen können, ohne sich um die Verwaltung der
00:01:35Hardware, die Verwaltung von Clustern, Orchestrierung oder irgendetwas anderes kümmern zu müssen.
00:01:40Es gibt eine API, es gibt eine Benutzeroberfläche: Man kommt rein, zahlt pro Token und bekommt sein Modell bereitgestellt.
00:01:47Das Wichtigste dabei ist die Vielfalt der Modelle in unserem Katalog, also das Angebot,
00:01:54das dem Kunden zur Verfügung steht. Ich spreche erst über Dedicated und komme dann zu Serverless zurück,
00:02:01weil es auf der Serverless-Seite eine Besonderheit gibt. Der dedizierte Inferenz-Dienst, den wir anbieten,
00:02:05richtet sich eher an Kunden, die genau wissen wollen, welche Hardware sie verwenden und worauf sie arbeiten,
00:02:11aber auch die Bereitstellung der Modelle liegt bei ihnen. Sie nutzen also unseren Service, unsere Orchestrierungsschichten,
00:02:18aber die Modellbereitstellung liegt in ihrer Hand. Auch die Modellleistung liegt bei ihnen, solange wir
00:02:25auf der Plattform die Funktionen und Stellschrauben bereitstellen, um diese Features zu bedienen. Zurück zu Serverless:
00:02:30Ein interessanter Punkt hierbei ist, dass Serverless-Modelle typischerweise ein “Noisy-Neighbor”-Problem haben,
00:02:38wo, wenn etwa alle gleichzeitig auf genau dasselbe Modell zugreifen, es zu recht vielen
00:02:43Timeouts kommen kann – je nachdem, wie viel Kapazität ich dahinter habe. Ein weiteres Feature bei Serverless
00:02:48ist daher das, was wir “Provisioned Throughput” nennen. Wenn Sie als Kunde Ihr Traffic-Profil kennen
00:02:55und uns darüber informieren, können wir es hinter den Kulissen
00:03:00speziell für Sie reservieren. Sie müssen sich weiterhin keine Gedanken darüber machen, auf welcher Hardware es genau läuft,
00:03:04solange Ihr Durchsatz und Ihre SLAs eingehalten werden.
00:03:07Das ist also eine weitere Option auf der Serverless-Seite, die weiterhin pro Token abgerechnet wird,
00:03:12aber Sie wissen, dass Sie dort nicht in das “Noisy-Neighbor”-Problem geraten.
00:03:19Lassen Sie mich kurz auf einige verschiedene Arten von Workloads und Workload-Strukturen eingehen,
00:03:27die wir sehen. Das Verhältnis zwischen ihnen ändert sich ständig, obwohl agentenbasierte Workloads
00:03:32wirklich sehr weit oben liegen. Agentic und Chat sind sich sehr ähnlich: extrem hohe
00:03:39Eingabesequenzlängen und typischerweise sehr geringe Ausgabesequenzlängen. Der größte Unterschied zwischen Agentic und
00:03:43Chat liegt jedoch darin, dass die Mehrfachinteraktionen (Multi-Turns) bei Agentic eine extrem geringe Latenz erfordern, im Gegensatz zu Chats – denn wenn
00:03:50Sie die Antwort des Benutzers erhalten, müssen Sie diese erst lesen und antworten dann. Es gibt
00:03:56da also Unterschiede. Und dieser große Unterschied schlägt sich letztlich in etwas nieder,
00:04:01das mit dem KV-Cache-Management zusammenhängt. Beide sind jedoch Echtzeit-Workloads, und eine weitere Echtzeit-Kategorie sind
00:04:09Sprach- und Videoanwendungen, die kontinuierlich streamen und extrem latenzempfindlich sind. Bei Agentic und Chat
00:04:16liegen die Anforderungen hauptsächlich beim Durchsatz und weniger bei der Latenz, aber Echtzeit-Sprache
00:04:23und -Video sind absolut latenzkritisch. Nun zu Batch-Workloads: Hier sind die SLAs extrem
00:04:32entspannt. Sie bewegen sich im Bereich von Sekunden und Minuten, bei manchen Kunden sogar in Stunden.
00:04:37Sie sagen: Ich gebe euch einfach eine Aufgabe für 10 bis 12 Stunden und schicke alles hin,
00:04:44verarbeitet es einfach, wann immer ihr könnt. Diese Batch-Workloads spielen insofern eine Rolle,
00:04:52als sie Vorgaben für einige Architekturentscheidungen in unserem Stack machen. Stellen Sie sich
00:04:59diese vier verschiedenen Workload-Formen vor. In der Zeitdimension muss man geschickt
00:05:04mit den Eigenschaften umgehen, um die zugrunde liegende Infrastruktur optimal auszulasten.
00:05:12Ich gebe Ihnen einen Überblick darüber, wie unser Stack derzeit aufgebaut ist, und führe Sie kurz durch den
00:05:19Ablauf einer Anfrage. Sowohl für Serverless als auch für Dedicated gilt: Wenn Sie auf die rechte Seite
00:05:24des Bildschirms schauen, sehen Sie auf Plattformseite die Control Plane für
00:05:31Autorisierungen, Rate-Limiting und die Nachverfolgung der Nutzung, damit entsprechend abgerechnet werden kann.
00:05:37Hinzu kommt Observability, damit wir sicherstellen können, dass wir die vereinbarten SLAs nicht verletzen.
00:05:45Darunter habe ich auf sehr hoher Ebene dargestellt, dass wir diese verschiedenen
00:05:52Inferenz-Engines haben – vLLM, SGLang und TensorRT-LLM –, aber es gibt hier noch einige Details, auf die ich eingehen werde.
00:06:00Und darunter versuche ich in Grün die verschiedenen Hardware-Komponenten darzustellen.
00:06:09Die Plattform muss also in der Lage sein, den Workload über
00:06:15verschiedene Generationen dieser GPUs zu verteilen – konkret NVIDIA-GPUs,
00:06:21die wir einsetzen. Schauen wir uns dazu ein paar Beispiele an. Nehmen wir an, die Anfrage stammt von der
00:06:31Client-Seite über Apps, Notebooks oder Agenten. Sie trifft auf das Gateway.
00:06:36Sobald sie das Gateway erreicht, durchläuft sie, wie erwähnt, auf der Control Plane die Authentifizierung
00:06:42usw., und trifft dann entweder auf Serverless oder Dedicated. Im Falle von Serverless
00:06:48erfolgt die Abrechnung pro Token. Hier wird also die Token-Nutzung überwacht – nicht die genauen Inhalte,
00:06:53sondern nur die Anzahl, da wir strikte Zero-Data-Retention-Richtlinien (ZDR) einhalten.
00:06:59Je nachdem, ob es sich um Multi-Tenancy oder um eine bereitgestellte Kapazität handelt, weiß der
00:07:05Router dahinter, dass er gezielt die expliziten Deployments für Kunden mit
00:07:12“Provisioned Throughput” ansteuern muss. Für Multi-Tenant-Kunden gibt es separate Deployments.
00:07:17Der Router an dieser Stelle ist besonders wichtig, da er dafür zuständig ist,
00:07:26Routing-Entscheidungen unter Berücksichtigung des KV-Caches zu treffen. Warum ist das wichtig? Weil, wie ich bei den
00:07:31Workload-Profilen erwähnt habe, agentische Anwendungsfälle typischerweise sehr lange Eingabesequenzen
00:07:39haben. Und der Großteil dieser Eingabesequenzlänge – etwa 80 bis 90 Prozent, je nach Unternehmen
00:07:44und Kunden – ist bei verschiedenen Anfragen identisch.
00:07:51Es macht also keinen Sinn, den Pre-fill dafür jedes Mal neu zu berechnen.
00:07:57Der Pre-fill ist sehr rechenintensiv und teuer. Je mehr Sie also über den Cache abdecken können,
00:08:04desto mehr sparen Sie. Deshalb gibt es überall bei den Token-Preisen einen spezifischen Preis für
00:08:11Eingabe-Tokens und einen deutlich günstigeren Preis für gecachte Eingabe-Tokens. Caching wird hier also extrem wichtig.
00:08:18Wie Sie die Hardware im Hintergrund aufteilen möchten, hängt von den Optionen der
00:08:26Plattform ab. Wir bieten die Möglichkeit für beides: Entweder eine Entkopplung von Pre-fill und Decode,
00:08:31wenn der Anwendungsfall es erfordert, oder eben nicht – denn diese Entkopplung ist nicht für jeden Anwendungsfall günstig.
00:08:41Betrachten wir einen weiteren Anfrageablauf: Was passiert bei einem Dedicated-Kunden?
00:08:48Ein Dedicated-Kunde nutzt ebenfalls die für ihn eingerichteten Gateways mit entsprechender Isolierung.
00:08:55Die Abrechnung erfolgt nicht nach Tokens, sondern auf Basis der Nutzung pro GPU und Stunde.
00:09:03Es ist ein privates Gateway, sodass kein “Noisy-Neighbor”-Problem auftritt und niemand sonst Zugriff hat.
00:09:09Hier greift dieselbe Router-Logik: Ähnliche Anfragen nutzen den Cache optimal aus.
00:09:18Und je nach dem Deployment, das der Kunde auf seinen dedizierten GPUs vornimmt,
00:09:24kann er entscheiden, ob er Pre-fill und Decode entkoppeln möchte oder nicht. Er kann wählen, welche
00:09:29Engine verwendet werden soll – vLLM, SGLang oder TensorRT-LLM. Und angesichts der Gesamtkapazität, die der Kunde
00:09:35reserviert hat, kann er entscheiden, ob er nur ein einziges Deployment nutzt, das über
00:09:42den gesamten Cluster skaliert, oder ob er mehrere verschiedene Modelle und Deployments betreiben möchte.
00:09:47Einen Punkt zum Router möchte ich hier noch erwähnen: Die Unterstützung
00:09:54heterogener Kapazitäten über verschiedene Zonen und Regionen hinweg.
00:09:59Das Lastbalancing darüber ist eine recht komplexe Herausforderung.
00:10:04Unsere Priorisierung sieht typischerweise so aus: Zuerst KV-Cache-Lokalität und als Fallback die am wenigsten ausgelastete Instanz.
00:10:16So viel dazu. Einen weiteren Anfrageablauf, den ich durchgehen möchte und der
00:10:21im Diagramm vielleicht etwas schwer zu erkennen ist, ist der Batch-Workflow.
00:10:25Für den Batch-Workflow nutzen wir die vorhandene Kapazität des Kunden:
00:10:31Nehmen wir denselben Dedicated-Inferenz-Kunden. Tagsüber laufen dort seine Echtzeit-
00:10:37Workloads, und von abends bis nachts möchte er Batch-Workloads ausführen. Dieselbe Kapazität kann zeitlich
00:10:43so geplant werden, dass sie dann die Batch-Workloads verarbeitet. Wir bieten in der API die Möglichkeit festzulegen, wann hoch- und
00:10:51wann herunterskaliert werden soll. Wenn der Zeitplan vorsieht, dass herunterskaliert werden kann,
00:10:56skalieren wir herunter und geben die Kapazität für die Batch-Verarbeitung über Nacht frei.
00:11:05Ich habe bereits einiges über Optimierungen beim KV-Cache gesagt, möchte aber einiges
00:11:10wiederholen, da dies einer der interessantesten Punkte ist. Wenn wir den Cache besser ausnutzen,
00:11:19sparen Sie sich die Kosten für das Pre-Fill, was hier der teuerste Teil ist.
00:11:26Die Wiederverwendung des KV-Caches über mehrere Turns in Agentic Workloads – auch zwischen den Turns
00:11:31gibt es viel ähnliches Pre-Fill in der Input-Sequenzlänge.
00:11:38Denken Sie an Chat-Workloads, bei denen das Auslagern des KV-Caches ebenfalls extrem wichtig wird,
00:11:43weil wir bei Chat-Workloads eine hohe Latenz zwischen den verschiedenen Turns haben,
00:11:49die wir als Nutzer eingeben. Wenn wir aber alles verwerfen, was wir in unserer Unterhaltung hatten,
00:11:57dauert es beim nächsten Mal, wenn wir eine Frage im selben Chat stellen, etwas länger.
00:12:02Anstatt also alles komplett zu verwerfen und das Pre-Fill erneut durchzuführen,
00:12:08nutzt man Techniken – wir nutzen eigene, aber extern kennt man LM Cache und Mooncake.
00:12:17Wir lagern den KV-Cache auf einen Speicher mit hoher Bandbreite aus,
00:12:21um viele dieser Pre-Fills zu speichern, sodass bei einer dazugehörigen Anfrage
00:12:28für diesen Chat alles sofort wieder in den HBM geladen werden kann.
00:12:37Was die Stellschrauben für die Performance angeht, möchte ich noch einige erwähnen:
00:12:41Wir haben über PD/DSAG gesprochen, aber Quantisierung und Spekulatives Dekodieren sind weitere.
00:12:48Auch die sorgfältige Wahl der Parallelisierungsgrade und -strategien ist sehr wichtig.
00:12:54Zwei der größten Hebel, an denen wir gearbeitet haben, sind Quantisierung auf NVFP4 und SpecDec.
00:13:01Wir bieten die Möglichkeit, dass Kunden uns ihre Datensätze geben, damit wir Spekulatoren trainieren,
00:13:07um bessere Akzeptanzlängen zu erzielen, was letztlich den Output-Durchsatz
00:13:12deutlich erhöht. Auch das bieten wir an. Aber das passiert asynchron. Wir erhalten die Daten asynchron,
00:13:20trainieren die Spekulatoren asynchron und spielen sie dann in die Kunden-Deployments ein,
00:13:26falls gewünscht. Sie sehen hier drei Screenshots. Ich habe sie eingefügt aus
00:13:32der Arbeit des letzten Monats, die einige in meinem Team geleistet haben. Wie Sie sehen,
00:13:39landeten wir schnell an der Spitze des Leaderboards bei Kimi 2.6, 2.7. Das stammt von Artificial Analysis.
00:13:46Um auf die vorherige Session zurückzukommen: Kann man dem vertrauen? Deshalb habe ich für GLM die Ergebnisse
00:13:52von OpenRouter. Wenn Artificial Analysis Benchmarks fährt, nutzen sie sehr spezifische Workloads.
00:13:58OpenRouter ist tatsächlicher Nutzer-Traffic. Und auf der Seite von OpenRouter sieht man Weights & Biases.
00:14:05Das Branding unterscheidet sich, aber Weights & Biases ist im Grunde Kervi. Wir haben Weights & Biases
00:14:09vor etwa einem Jahr gekauft. Man sieht hier, dass die Geschwindigkeit unseres Deployments sehr nah
00:14:16an dem liegt, was Fireworks als Fireworks Fast anbietet, richtig? Aber die zugrunde liegenden Techniken
00:14:21zur Performance-Optimierung sind das, was ich hier am meisten betonen möchte. Das ist entscheidend,
00:14:27denn letztlich wollen wir dem Kunden ein optimales Preis-Leistungs-Verhältnis bieten.
00:14:36Kurze Zusammenfassung: Eine einzige Plattform ist das, worauf ich hinauswollte.
00:14:44Zwei verschiedene Nutzungsmodelle für Kunden: Serverless und Dedicated. Und innerhalb von Serverless
00:14:49habe ich ebenfalls zwei Modelle beschrieben: Pay-as-you-go und Provisioned Throughput, falls relevant.
00:14:53Und schließlich die Steigerung der Gewinne durch Performance-Optimierungen im Stack.
00:15:01Das ist alles. Vielen Dank!
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기