DeepSeek zwingt vLLM zur Upgrade, die Chip-Industrie hat heftige Konkurrenz, und Mixture of Experts (MoE) erobert die Modelle auf breiter Front. Der Hauptbetreuer von vLLM gibt eine exklusive Antwort: Wie kann man mit PyTorch den "eisernen Thron" der Inferenz behaupten?
Die Geschichte von vLLM begann bei einer Gruppe begeisterter Studenten und Forscher im Sky Computing Lab der Universität Kalifornien, Berkeley. Im Jahr 2023 öffneten sie die Kerntechnologie PagedAttention als Open - Source. Innerhalb von nur etwas mehr als einem Jahr erreichte vLLM auf GitHub über 40.000 Sterne und wuchs rasch auf die heutigen 65.000. Heute ist es das bevorzugte Inference - Engine für Technologieunternehmen weltweit.
Hinter diesem Erfolg spielte Neural Magic eine Schlüsselrolle. Dieses von Forschern des MIT gegründete Unternehmen hat sich im wettbewerbsreichen Bereich der KI - Optimierung mit seiner einzigartigen Strategie von "kostenloser Plattform + Open - Source - Tools" hervorgetan. Durch seine tiefe Beteiligung an vLLM hat Neural Magic nicht nur einen reifen Unternehmens - Inference - Stack aufgebaut, sondern auch die Modelloptimierungsforschung vorangetrieben und eine vorkonfigurierte Modellbibliothek aufrechterhalten, die direkt in vLLM integriert werden kann.
Genau diese Erfahrungen und die technische Kompetenz in der Open - Source - Community von vLLM haben das Interesse von Red Hat geweckt. Im November 2024 hat Red Hat offiziell Neural Magic übernommen und das Kernteam, darunter auch Michael Goin, den Kernwart von vLLM, in seinen Besitz genommen. Michael hat mehr als zehn Jahre Erfahrung in der Optimierung der Inference - Leistung und der Maximierung der CPU/GPU - Effizienz. In der vLLM - Community konzentriert er sich auf die Kernoptimierung, die Modellkompression und die Systemoptimierung.
Nachdem Red Hat ein wichtiger Akteur geworden ist, hat sich das Feld der großen KI - Modelle stark verändert. Wie hat vLLM diese Veränderungen und Herausforderungen bewältigt? Wie hat Red Hat vLLM dabei geholfen, seine Wettbewerbsfähigkeit zu bewahren? Wir haben Michael Goin, Leitender Ingenieur von Red Hat und Kernmitarbeiter von vLLM, sowie Zhang Jiajü, Chefarchitekt des CTO - Büros von Red Hat in Asien - Pazifik und CTO für Großchina, interviewt. Sie haben uns die jüngsten Entwicklungen von vLLM und ihre Gedanken dazu ausführlich vorgestellt.
Michael Goin, Leitender Ingenieur von Red Hat und Kernmitarbeiter von vLLM
Von Llama zu DeepSeek
Das Team um Michael, als "Kernteam" des vLLM - Projekts, konzentriert sich immer auf die Integration und Entwicklung von Hochleistungs - Inference - Kernen, um das gesamte Projekt im schnellen Wandel an der Spitze zu halten.
Mit der Veröffentlichung verschiedener Modelle hat sich der Entwicklungstempo von vLLM beschleunigt. Insbesondere die Veröffentlichung von DeepSeek R1 hat das Team dazu gebracht, sich von der Effizienzoptimierung der Llama - Serie auf die Optimierung der Eigenschaften von DeepSeek zu konzentrieren.
Um auf die neuen Eigenschaften von DeepSeek schnell zu reagieren, war der Entwicklungszyklus der Version 0.7.2 sehr eng. Darüber hinaus hat es effizient Qwen 2.5 VL unterstützt und einen Transformers - Backend eingeführt, sodass Benutzer direkt beliebige Hugging Face - Modelle ausführen können. Die anschließende Version 0.7.3 war eine noch umfangreichere Aktualisierung. Innerhalb kurzer Zeit haben viele Mitwirkende teilgenommen, und der Entwicklungsprozess war effizient und intensiv.
Diese Version hat nicht nur Optimierungen wie die Multi - Token - Vorhersage (MTP) und die MLA - Attention für DeepSeek aktiviert, sondern auch die Unterstützung und Optimierung für AMD - Hardware erweitert. Darüber hinaus war die Expert - Parallelisierung vor DeepSeek nicht sehr verbreitet. Daher hat das Team die Entwicklung von vLLM von der Unterstützung der Tensor - Parallelisierung und der Pipeline - Parallelisierung zur Unterstützung der Expert - Parallelisierung vorangetrieben. Michael hat auch eine Reihe von Hochleistungs - Tools von DeepSeek, wie DeepGEMM, DeepEP und die Lastenausgleichung bei der Expert - Parallelisierung, systematisch in die vLLM - Ökosystem integriert.
Für Inference - Szenarien erweitert das Team ständig seine Bibliothek von Hochleistungs - Kernen, einschließlich angepassten Triton - Kernen, CUTLASS - Kernen, CUDA - Kernen, HIP - Kernen usw., sowie verschiedene Quantisierungsunterstützungen und viele benutzerdefinierte Kernimplementierungen.
Die Komplexität von DeepSeek hat das Team stattdessen die Möglichkeit gegeben, zu optimieren und zu verallgemeinern. Michael hat darauf hingewiesen, dass das Team die Technologien, die ursprünglich hauptsächlich für die private Umgebung von DeepSeek entwickelt wurden, in nachhaltige und allgemeingültige Lösungen umgewandelt hat, sodass sie für mehr Modelle auf Basis der MoE - Architektur genutzt werden können. Er betont, dass einige Entwicklungen von vLLM tatsächlich von DeepSeek angestoßen wurden, nicht weil das DeepSeek - Modell selbst schneller läuft, sondern weil die von DeepSeek veröffentlichten fortschrittlichen Technologien die gesamte Ökosystem verbessert haben.
In diesem Prozess hat DeepSeek einen praktikablen Weg für die effiziente Bereitstellung von großen Modellen aufgezeigt, und das vLLM - Team hat diese Erfahrungen reproduziert und verallgemeinert, um einen stärkeren Inference - Rahmen aufzubauen. "Durch die Zusammenarbeit mit DeepSeek haben wir ausgezeichnete Algorithmen mit der Implementierung der unteren Schicht kombiniert, um einen effizienteren Inference - Rahmen aufzubauen. Es ist wirklich eine starke Partnerschaft", so Michael.
Außer der Leitung der Integration von DeepSeek V3 hat Michael auch das Team bei der Anpassung und Optimierung von Modellen wie GPT - OSS, Qwen und Kimi geleitet.
Wie ein Framework verschiedene Hardware unterstützt
Eine weitere Kernaufgabe des vLLM - Teams ist die Schaffung einer offenen und effizienten Hardware - Inference - Ökosystem. Sie unterstützen nicht nur verschiedene gängige Chips breit, sondern sind auch tief in das Design und die Leistungsoberfläche von neuen Hardwarearchitekturen involviert, um die gesamte Community in Richtung der Kompatibilität mit verschiedenen Hardware zu entwickeln.
In den letzten Monaten hat Michael zusammen mit NVIDIA die Unterstützung für den Blackwell - Chip vorangetrieben und die Leistung von B200 optimiert. Die Teammitglieder haben auch eng mit dem AMD - Team zusammengearbeitet, um die Leistung von AMD in vLLM sicherzustellen. Michael hat auch mehr als ein Jahr lang eng mit dem Google TPU - Team zusammengearbeitet und mehrere Versionen veröffentlicht. Kürzlich hat Michael als oberster Entscheider auch am Design der gesamten Unterstützungsarchitektur für Moore Threads beteiligt.
Am Beispiel der Zusammenarbeit mit Moore Threads kann man die Tiefe der Beteiligung des Red - Hat - Teams sehen: In einem sehr frühen Stadium des Projekts hat Michael zusammen mit dem Moore - Threads - Team über die Designrichtung des Unterstützungsrahmens diskutiert. Er hat das hohe - Level - Design geleitet, während die Community - Mitwirkenden im Team sich auf die Details konzentriert haben und sogar nach Shanghai gereist sind, um eine persönliche technische Koordination durchzuführen. Beide Seiten haben auch einen speziellen Kanal auf Slack erstellt und eine "Online - Joint - Working - Group" zwischen den Unternehmen gegründet, um die Unterstützungseffizienz aufrechtzuerhalten.
Der gesamte Prozess zeigt die sorgfältige Einbindung des Teams in die Ökosystementwicklung: Sie weisen zunächst den Hardwarepartnern die Richtung auf; nachdem Moore Threads die entsprechenden Arbeiten abgeschlossen hat, führen sie gemeinsam einen Code - Review und eine iterative Optimierung durch. Beispielsweise haben sie Moore Threads geholfen, das ursprüngliche Unterstützungsmodell durch einen Plug - In - Mechanismus eleganter und wartbarer zu gestalten. Auf GitHub werden eine Vielzahl von Revisionen (RC) von dem Team sorgfältig überprüft. Jetzt hat Michael eine lange Liste von noch zu überprüfenden Änderungen.
Diese tiefe Zusammenarbeit hat schließlich zu einem Gewinn für beide Seiten geführt. Wie Zhang Jiajü sagte: "Für Moore Threads haben sie eine elegante Lösung gefunden, um ihre Hardware von der Community zu unterstützen, was bedeutet, dass die zukünftigen Wartungsarbeiten weniger sein werden als bisher. Für die Community haben wir auch die Entwicklung einer Ökosystem unterstützt, die verschiedene Hardware unterstützt."
Die Wichtigkeit von PyTorch
In der Zeit der heterogenen Berechnung kann vLLM verschiedene Chips von NVIDIA, AMD, Google TPU und sogar viele chinesische Chips unterstützen. Die Kernstrategie besteht darin, PyTorch tief zu integrieren und es als den "größten gemeinsamen Teiler" zwischen dem oberen Framework und der unteren Hardware zu nutzen.
Technologisch gesehen liegt PyTorch über der Hardware, und vLLM liegt über PyTorch. Das bedeutet, dass, wenn die Hardwarehersteller eine gute Unterstützung für PyTorch bieten, der größte Teil der Arbeit zur Anpassung an vLLM bereits erledigt ist. Die Modelldefinition in vLLM ist fast vollständig auf PyTorch basiert, und nur für wenige Schlüsselmodule wie die Attention - Mechanismen bleibt ein austauschbarer und benutzerdefinierter Raum.
PyTorch bietet bereits eine SDPA - Attention - Implementierung, und vLLM unterstützt darüber hinaus noch mehr als zehn andere Attention - Implementierungen für verschiedene Hardware - Backends, wie FlashAttention und FlashInfer von NVIDIA, ROCm Attention und Triton Attention von AMD, Pathways Attention von Google TPU und Attention von Ascend NPU.
Genau durch diese einheitliche PyTorch - Abstraktionsschicht kann vLLM die Beschleunigungsimplementierungen verschiedener Hardware integrieren. Solange die Hardwarehersteller eine PyTorch - kompatible Version anbieten, ist der größte Teil (etwa 90%) der Arbeit bereits erledigt. Die verbleibenden 10% betreffen hauptsächlich die Anpassung und Optimierung der weniger effizienten Teile von PyTorch, wie die Fusion von MoE, die Quantisierung von Matrixmultiplikationen und die spezifische Attention - Implementierung.
Michael erklärt, dass vLLM so stark auf PyTorch angewiesen ist, weil fast alle Hardwarehersteller gute Gründe haben, auf PyTorch zu setzen: Es wird sowohl für das Training als auch für die Inference verwendet und ist mit den meisten Open - Source - Software tief integriert.
Er sagt weiter, dass der Hauptkonkurrent von PyTorch JAX von Google ist. Aber JAX hat einen geringeren Grad der Open - Source - Verfügbarkeit, beispielsweise ist der XLA - Compiler - Backend von JAX nicht offen. Die tatsächliche Verbreitung seiner Ökosystem ist weit hinter PyTorch zurück. Da PyTorch als das beste Abstraktionsframework von der Maschinellem Lernen bis zur Hardwareebene angesehen wird, baut vLLM fest auf seiner Infrastruktur auf und erweitert seine Funktionen für die effiziente Inference von großen Sprachmodellen. Dies erklärt auch teilweise, warum vLLM sich der PyTorch - Stiftung angeschlossen hat.
Zhang Jiajü hat auch darauf hingewiesen, dass PyTorch so weit verbreitet ist, dass alle Hardwarehersteller es aktiv anpassen. Auch chinesische Chiphersteller integrieren und passen sich über PyTorch an.
Kurz gesagt, vLLM ist nicht direkt mit der komplizierten Hardwaretechnologie konfrontiert, sondern baut auf der reifen und offenen Zwischenschicht von PyTorch auf und arbeitet zusammen mit Hardwareherstellern und der Community. Dies verringert nicht nur die Komplexität der Unterstützung für verschiedene Hardware, sondern lässt auch die gesamte Ökosystem auf einer einheitlichen Grundlage weiterentwickeln und optimieren.
Ist die sogenannte Schutzmauer von NVIDIA noch so stark?
Daher müssen wir uns einer tieferen Frage stellen: Wenn CUDA der "Motor" für die GPU - Beschleunigung und PyTorch das "Framework" zum Aufrufen von CUDA ist, wie können neue Hardwarehersteller aufholen, um die gleiche Effizienz und Benutzerfreundlichkeit wie NVIDIA CUDA zu erreichen?
Nach Ansicht von Michael ist dies eine herausfordernde Aufgabe. Der Kern des Problems ist, dass selbst wenn man schließlich eine funktionelle Kompatibilität auf der PyTorch - Ebene erreichen kann, die Effizienz oft hinter der von NVIDIA CUDA zurückbleibt, das über Jahrzehnte hinweg stark optimiert wurde. "CUDA ist für andere Hardware keine direkt übertragbare Sprache", so er, "es ist im Wesentlichen ein langfristiger Unterschied zwischen der Hardwareabstraktion und der Softwareökosystem."
Aber es gibt immer noch Wege.
Michael hat darauf hingewiesen, dass die Verwendung einer domänenspezifischen Sprache wie Triton auf der Hardwareabstraktionsschicht eine Lösung ist: Man muss den Algorithmus nur einmal in Triton schreiben, um ihn auf verschiedenen Hardwareplattformen auszuführen. Aber auch dieses Modell hat seine Grenzen: Selbst wenn die Software schließlich alle Hardware - Backends unterstützen kann, müssen die Kernentwickler immer noch viel manuelle Feineinstellung und Kernentwicklung leisten, um die Effizienz auf der spezifischen Hardware zu erreichen.
Zhang Jiajü hat analysiert, dass es verschiedene technische Wege gibt, um die gleiche Leistung wie CUDA zu erreichen. Beispielsweise hat Moore Threads die Route gewählt, die CUDA - API vollständig zu kompatibilisieren. Man kann auch eine domänenspezifische Sprache verwenden, um über verschiedene Backends auf verschiedenen Hardware auszuführen, wie Triton, eine neue Sprache zum Schreiben von GPU - Operatoren. Aber im Wesentlichen ist dies immer noch ein Modell, das viel manuelle Optimierung und Anpassung erfordert.
Aber es kommt auch ein Wendepunkt. Michael hat scharf bemerkt, dass neue Attention - Algorithmen ständig auftauchen. Für diese neuen Technologien besteht die Möglichkeit, dass andere Hardwarehersteller NVIDIA übertreffen können.
"Sie sind sehr neu, und die Hersteller können möglicherweise eine schnellere und ursprünglichere Unterstützung bieten als CUDA. Beispielsweise wurde der KDA - Algorithmus von Kimi zuerst über Triton unterstützt. In der neuen Algorithmen - Welt können andere Hersteller manchmal schneller reagieren", so Michael.
Mit der kontinuierlichen Erforschung von effizienteren Architekturen als der Standard - Transformer von den Modellherstellern haben die Hardwarehersteller mehr Flexibilität und Raum für schnelle Reaktionen. Wie Michael sagt: "Es ist wie ein Sportwettkampf, und alles fängt wieder von vorne an."
Multimodale Unterstützung
Angesichts der kontinuierlichen Integration von Software und Hardwareökosystem hat vLLM nicht bei der Optimierung der Inference für eine einzelne Modalität stehen geblieben. Als die Welle der multimodalen KI hereinbrach, hat das Team vLLM von einer reinen Text - Inference - Engine zu einer einheitlichen Service - Plattform für die Generierung und das Verständnis aller Modalitäten entwickelt. Man kann sagen, dass die multimodale Modellarchitektur die Architektur von vLLM verändert hat.
"Ob es sich um Text - zu - Bild - Generierung, Dokumentenverständnis oder andere Generierungsaufgaben handelt, alle basieren auf der Inference von großen Modellen und können daher durch vLLM verarbeitet werden", so Michael.
Dafür hat das Team die Version v1 von vLLM komplett neu strukturiert. Eine der Schlüsselinnovationen ist der multimodale Präfix - Cache (Multimodal Prefix Caching). Traditionell hat vLLM die Key - Value - Caches von Text - Tokens über die Page Attention wiederverwendet. Jetzt ist dieses Konzept auf Eingaben aller Modalitäten wie Bilder und Audio erweitert worden. Jetzt verwaltet das Team einen multimodalen Cache, wodurch die Effizienz bei wiederholten Anfragen stark verbessert wurde.
Um die Bereitstellung von großen Inference - Szenarien zu unterstützen, hat das Team die Entkopplungstechnologie der Encoder implementiert, um die visuellen und audio - Encoder von der Sprachmodell - Backbone zu trennen. Dies entspricht der Struktur von