Technische Analyse und Praxisaustausch: Benutzermodus und Kernelmodus bei der Dual-Engine-GPU-Containervirtualisierung

​Wie die Effizienz der Hardware-Rechenleistung maximiert werden kann, ist für alle Ressourcenbetreiber und -benutzer ein wichtiges Anliegen. Als führendes KI-Unternehmen verfügt Baidu über die vielleicht umfassendsten KI-Anwendungsszenarien der Branche.

In diesem Artikel werden wir GPU-Container-Virtualisierungslösungen in komplexen KI-Szenarien und Best Practices in der Fabrik teilen und diskutieren.

Der linke und der rechte Teil des Bildes unten wurden bei verschiedenen Gelegenheiten mehrfach gezeigt. Der Hauptzweck ihrer Platzierung besteht darin, den Bedarf an Rechenleistung hervorzuheben – das exponentielle Wachstum der Hardware-Rechenleistung und die geringe Ressourcenauslastung reale Anwendungsszenarien. Der Widerspruch zwischen Verschwendung.

Der linke Teil ist eine Statistik von OpenAI. Seit 2012 hat sich die für das Modelltraining erforderliche Rechenleistung um das 300.000-fache erhöht . Einerseits verdoppelt sich mit steigendem Bedarf an Rechenleistung auch die Rechenleistung gängiger KI-Beschleunigungseinheiten alle zwei Jahre. Andererseits schränkt die Effizienz der Ressourcennutzung die volle Nutzung der Hardwareleistung ein.

Der rechte Teil ist das Ergebnis der Facebook-Auslastungsanalyse für maschinelles Lernen im Rechenzentrum im Jahr 2021. Ein großer Teil der KI-Rechenleistung geht durch Verknüpfungen wie Ausfälle, Planung, Verschwendung von Zeitscheiben und Verschwendung von Raumeinheiten verloren. Die tatsächliche Rechenleistungsauslastung beträgt weniger als 30 %. Wir glauben, dass dies auch die aktuelle Situation großer inländischer Infrastrukturbetreiber ist.

Ich habe gerade erwähnt, dass die Auslastung des Online-Clusters weniger als 30 % beträgt, was möglicherweise nicht der Wahrnehmung vieler Studierender entspricht. Viele Online-Studenten sind möglicherweise Entwickler von Modellen und Algorithmen. Nach unserem allgemeinen Verständnis kann die Auslastung während des Trainings und Tests sehr hoch bleiben und sogar eine Auslastung von 100 % erreichen.

Aber wenn das Modell in der Produktionsumgebung eingeführt wird, unterliegt es vielen Einschränkungen. Diese Einschränkungen führen dazu, dass die Auslastungsrate weit hinter unseren Erwartungen zurückbleibt.

Lassen Sie uns den begrenzten Platz nutzen, um die wichtigsten Einschränkungen zusammenzufassen:

• Modelleigenschaften: Jedes Modellnetzwerk ist anders und die zugrunde liegenden aufgerufenen Operatorkombinationen sind unterschiedlich, was sich stark auf die GPU-Auslastung auswirkt.
• Dienst-SLA: Dienste in verschiedenen Szenarien erfordern unterschiedliche SLAs und müssen sogar innerhalb von 10 ms streng kontrolliert werden. Dann können diese Dienste die Auslastung nicht durch Erhöhung der Batchgröße verbessern, oder sogar die Batchgröße beträgt nur 1.
• Verkehrsmuster: Verschiedene Modellalgorithmen bedienen unterschiedliche Anwendungsszenarien, wie z. B. die OCR-Erkennung, die während der Arbeit häufig aufgerufen werden kann. Die Spracherkennung wird häufiger beim Pendeln oder bei Unterhaltung und Freizeit aufgerufen, was zu Spitzen- und Talschwankungen der GPU-Auslastung im Laufe des Tages führt.
• Optimierungseffekt: Abhängig von der Iterationsfrequenz des Modells und den Abdeckungsszenarien ist auch die Optimierungsgranularität des Modells unterschiedlich. Es ist denkbar, dass es für eine Modellauslastung, die nicht vollständig optimiert ist, schwierig ist, ein hohes Niveau zu erreichen.
• Kapazitätsredundanz: Bevor das Modell online geht, muss eine detaillierte Kapazitätsplanung durchgeführt werden und ob in diesem Prozess Kapazitätsredundanzen reserviert werden, die ebenfalls schwer zu ignorieren sind Probleme in normalen Zeiten. Eine Energieverschwendung.

Unter den oben genannten Einschränkungen möchten wir möglicherweise als Nächstes die Auslastung der realen Produktionsumgebung zeigen. Wir abstrahieren diese Nutzungsmuster aus der komplexen und sich verändernden Online-Produktionsumgebung.

• Niedriger Durchschnittstyp: Wie im Bild oben links gezeigt, handelt es sich um ein echtes Online-Inferenzgeschäft. Aufgrund der Einschränkungen der Modelleigenschaften und der Service-SLA beträgt die Spitzenauslastung der GPU nur 10 % und die durchschnittliche Auslastung wird noch niedriger sein.
• Peak-and-Tal-Schwankungstyp: Wie im Bild unten links gezeigt, handelt es sich um ein typisches Online-Inferenz-Geschäftsauslastungsmuster. Der Dienst erreicht tagsüber seinen Höhepunkt und ist von spät in die Nacht bis spät am niedrigsten Am nächsten Morgen beträgt die durchschnittliche Auslastung im Laufe des Tages nur etwa 10 %, die Talauslastung liegt unter 10 %.
• Kurzfristiger Anstiegstyp: Wie im Bild oben rechts gezeigt, ist die Auslastungskurve im Wesentlichen dieselbe wie im Bild unten links, es wird jedoch während der Hauptsendezeit in der Nacht zwei offensichtliche Auslastungsspitzen geben Um die Servicequalität in Spitzenzeiten zu erreichen, reserviert dieser Dienst während des Bereitstellungsprozesses einen großen Puffer, und die durchschnittliche Ressourcenauslastung liegt bei knapp über 30 %.
• Periodischer Typ: Wie im Bild rechts unten gezeigt, handelt es sich um den Nutzungsmodus eines typischen Online-Trainingsszenarios. Die Online-Trainingsaufgabe liegt zwischen Offline-Training und Online-Inferenz. Dies ist eine periodische Stapelverarbeitungsaufgabe. Beispielsweise kommt alle 15 Minuten ein Datenstapel an, aber das Training dieses Datenstapels dauert nur 2-3 Minuten und die GPU ist längere Zeit im Leerlauf.

KI-Anwendungsszenarien sind komplex und veränderlich. Oben sind nur vier typische Szenarien aufgeführt. Das Ausbalancieren von Geschäftsleistung und Ressourceneffizienz in komplexen Szenarien ist die erste Herausforderung, der wir bei der GPU-Virtualisierung begegnen.

Die zweite Herausforderung, vor der wir beim GPU-Virtualisierungsprozess stehen, ist das Fehlen einer vollständigen GPU-Isolierung und eines Mischmechanismus.

Wir nehmen als Beispiel die aktuelle Mainstream-NVIDIA-GPU. Das typische KI-Software- und Hardware-Ökosystem ist in mehrere Ebenen unterteilt: Anwendungs- und Framework-Schicht, Laufzeitschicht, Treiberschicht und Hardware-Schicht.

Die oberste Ebene ist zunächst die Anwendung des Benutzers, die verschiedene gängige Frameworks wie PaddlePaddle, TensorFlow, PyTorch usw. umfasst. Unter der Anwendungsschicht befindet sich die vom Hardwareanbieter gekapselte API-Schnittstellenschicht, einschließlich verschiedener häufig verwendeter Operatorbibliotheken und Hardware-Laufzeitzugriffsschnittstellen. Unter dieser Schicht der API-Schnittstelle befindet sich die Treiberschicht, die mit der Hardware kommuniziert. Diese Schicht befindet sich im Kernel-Status und ist die Software-Schnittstellenschicht, die direkt mit dem Gerät kommuniziert. Unten befindet sich die echte KI-Beschleunigungshardware, die für die Ausführung der Operatoren verantwortlich ist.

Traditionelle Virtualisierungslösungen werden durch die Kombination von Treiber-Kernel-Status und Hardware-Virtualisierungslogik implementiert. Diese beiden Ebenen sind die Kern-IP von Hardwareanbietern und im Allgemeinen geschlossene Quellen. Wie später erwähnt wird, kann der aktuelle GPU-native Isolationsmechanismus die Nutzungsanforderungen in Cloud-nativen Szenarien hinsichtlich Flexibilität und Zuordnungsstärke nicht erfüllen.

Zusätzlich zum Isolationsmechanismus ist es auch schwierig, die Anforderungen komplexer Szenarien mit dem vorhandenen Hybridverteilungsmechanismus zu erfüllen. Wir haben gesehen, dass es in der Branche viele Open-Source-Lösungen für die gemeinsame Planung gibt in eine von der Ressourcenkarte. In tatsächlichen Szenarien führt die einfache gemeinsame Nutzung zu gegenseitigen Auswirkungen zwischen Unternehmen, langfristigen Verzögerungen und sogar zu einer Verschlechterung des Durchsatzes, sodass die einfache gemeinsame Nutzung in Produktionsumgebungen nicht wirklich angewendet werden kann.

Im Abschnitt zur Nutzungsmusteranalyse oben haben wir gesehen, dass verschiedene Unternehmen und unterschiedliche Szenarien unterschiedliche Nutzungsmuster aufweisen. Der Schlüssel zur Implementierung der Produktionsumgebung liegt darin, Geschäftsszenarien zu abstrahieren und Hybridlösungen anzupassen.

Um allen ein umfassenderes Verständnis der Entwicklung der GPU und der Geschichte der Virtualisierung zu vermitteln, zeigen wir hier anhand eines Bildes die Entwicklungsgeschichte der GPU-Virtualisierung.

GPUs Anwendung im allgemeinen Computing lässt sich auf die Tesla-Architektur der G80-Ära zurückführen. Dabei handelt es sich um die Architektur der ersten Generation, die einheitliche Shader implementiert und einen Allzweckprozessor SM verwendet, um den ursprünglichen Grafikbildprozessor durch separate Vertex- und Pixel-Prozessoren zu ersetzen Pipelines.

Die früheste von Baidu eingeführte GPU geht auf die Fermi-Architektur zurück. Seit diesem Zeitpunkt sind in der Branche eine Reihe von Virtualisierungslösungen erschienen, die sich größtenteils auf API-Hijacking konzentrieren. Der typische Vertreter hier ist rCUDA, ein ursprünglich von akademischen Gruppen gepflegtes Projekt, das bis vor kurzem eine gewisse Häufigkeit von Aktualisierungen und Iterationen aufwies, sich jedoch offenbar auf die akademische Forschung konzentrierte und in Produktionsumgebungen nicht weit verbreitet war.

Baidus groß angelegte Einführung von GPUs basierte auf der Kepler-Architektur. Die Kepler-Architektur eröffnete die Ära von Baidus selbstentwickeltem Super-KI-Computer X-MAN. X-MAN 1.0 implementiert zum ersten Mal eine Einzelmaschinen-Konfiguration mit 16 Karten und kann eine dynamische Bindung und ein flexibles Verhältnis von CPU und GPU auf PCIe-Hardwareebene realisieren. Begrenzt durch die Leistung einer einzelnen Karte, wurde damals mehr Wert auf Erweiterung als auf Segmentierung gelegt.

Die Leistung der nachfolgenden Pascal-Architektur, Volta-Architektur und Turing-Architektur hat sich rapide verbessert und der Bedarf an Virtualisierung ist immer deutlicher geworden. Wir sehen, dass NV seit der frühesten Kepler-Architektur offiziell die GRID vGPU-Virtualisierungslösung bereitgestellt hat, die ursprünglich auf Grafik-Rendering und Remote-Desktop-Szenarien ausgerichtet war. Um das Jahr 2019 herum wurden auch Lösungen für KI- und High-Performance-Computing-Szenarien bereitgestellt. Allerdings basieren diese Lösungen auf virtuellen Maschinen und werden selten in KI-Szenarien eingesetzt.

In der Ampere-Generation brachte NV die MIG-Instanzsegmentierungslösung auf den Markt, die die Segmentierung mehrerer Hardwareressourcen wie SM, MEM und L2-Cache auf Hardwareebene realisiert und so eine gute Hardware-Isolationsleistung bietet. Allerdings wird diese Lösung ab der Ampere-Architektur unterstützt und es gibt bestimmte Einschränkungen bei den Kartenmodellen. Nur wenige Modelle, A100 und A30, können es unterstützen. Und selbst nach dem Slicing übersteigt die Leistung einer einzelnen Instanz die Rechenleistung von T4 und kann das Effizienzproblem der aktuellen Produktionsumgebung nicht gut lösen.

Nachdem jeder einige Eindrücke von der Geschichte der GPU-Architektur und -Virtualisierung gewonnen hat, wollen wir die wichtigsten Ebenen der GPU-Virtualisierung im Detail vorstellen ist eine technische Route.

Um eine Ressourcenvirtualisierung und -isolation zu erreichen, müssen Ressourcen zunächst in der Zeit- oder Raumdimension trennbar sein. Aus Benutzersicht können mehrere Aufgaben gleichzeitig oder parallel ausgeführt werden.

Hier besprechen wir den Parallel- oder Parallelitätsraum auf mehreren Ebenen des Benutzermodus, Kernelmodus und der Hardware.

Da es sich bei der Software- und Hardwareökologie von NV um Closed Source handelt, basiert das schematische Diagramm hier auf unserem umfassenden Architektur-Whitepaper, Reverse Papers und unserem eigenen Verständnis. Wir hoffen, dass jeder die Ungenauigkeiten rechtzeitig korrigieren kann.

Lösung im Benutzermodus

Schauen wir uns dieses Bild zunächst von oben nach unten an. Aus der Perspektive der GPU sind mehrere Prozesse natürlich gleichzeitig, also zeitlich unterteilt gemultiplext. Der Treiber und die Hardware sind dafür verantwortlich, Aufgaben in einer Zeitscheibenrotation zu wechseln. Mithilfe dieser Mechanismusebene können wir Einschränkungen der Rechenressourcen und Videospeicherressourcen auf API-Ebene implementieren, um Virtualisierungseffekte zu erzielen. Die API kann hier in zwei Schichten unterteilt werden. Diese API-Schicht liegt in der Nähe des Treibers und ist die einzige Möglichkeit für alle Aufrufe der oberen Schicht, auf die GPU zuzugreifen Der API entspricht die Steuerung des Ressourcenzugriffs des Benutzers. Lassen Sie mich hier erwähnen, dass die von NV bereitgestellte MPS-Technologie räumliches Multiplexing realisieren kann, was auch die Möglichkeit einer weiteren Optimierung der Geschäftsleistung bietet. Wir werden im anschließenden Implementierungspraxisteil ausführlicher darauf eingehen.

Kernel-Statuslösung

Die nächsttiefere Ebene ist der Kernel-Status, unabhängig davon, ob es sich um eine vollständige Virtualisierung oder Paravirtualisierung auf der Ebene der virtuellen Maschine oder um die großen Cloud-Anbieter in den letzten beiden handelt Jahre lang implementieren alle Containerlösungen das Abfangen von Systemaufrufen und MMIO-Hijacking auf der Kernel-Ebene. Die größte Schwierigkeit im Kernel-Status besteht darin, dass viele Register und MMIO-Verhaltensweisen nicht gut dokumentiert sind, was ein komplexes Reverse Engineering erfordert.

Hardware-Lösung

Unterhalb des Kernel-Status ist die Hardware-Schicht auf dieser Ebene garantiert, unabhängig davon, ob es sich um die MIG-Technologie von NV oder die SR-IOV-Technologie von Baidu Kunlun handelt die Rechenleistung in der Hardware-Logik, um echte Parallelität und Raummultiplex zu erreichen. Kunlun kann beispielsweise eine Hardwarepartitionierung von 1/3 und 1/2 erreichen, und A100 kann eine Ressourcenpartitionierung mit einer Mindestgranularität von 1/7 erreichen.

Wir haben viel Zeit damit verbracht, Ihnen die Herausforderungen und die aktuelle Situation der GPU-Virtualisierung vorzustellen. Sehen wir uns als Nächstes an, wie Baidu intern darauf reagiert. Herausfordernd.

Dieses Bild zeigt Baidu Smart Cloud – Dual-Engine-GPU-Container-Virtualisierungsarchitektur.

Wir legen hier den Schwerpunkt auf Container, weil wir glauben, dass KI-Full-Link-Anwendungen in Zukunft schrittweise zu Cloud-nativen Plattformen konvergieren werden, um eine vollständige Containerentwicklung, Schulung und Inferenz zu erreichen. Laut einer Studie von Gartner werden im Jahr 2023 70 % der KI-Aufgaben in Containern bereitgestellt. Die interne Containerisierung von Baidu begann im Jahr 2011 und verfügt nun über mehr als 10 Jahre Erfahrung in der Bereitstellung und Optimierung. Wir sind auch bestrebt, der Community und der Mehrheit der Benutzer diesen Teil der Produktfunktionen und Optimierungserfahrungen zur Verfügung zu stellen, die in der Praxis verfeinert wurden.

Dual Engines werden hier ebenfalls groß geschrieben. In der Gesamtarchitektur verwenden wir zwei Sätze von Isolations-Engines, den Benutzermodus und den Kernelmodus, um den unterschiedlichen Anforderungen der Benutzer an Isolation, Leistung, Effizienz und anderen Aspekten gerecht zu werden.

Auf der Isolations-Engine befindet sich die Ressourcen-Pooling-Schicht. Diese Schicht basiert auf unserem tiefen Verständnis des Software- und Hardware-Systems und implementiert schrittweise die Entkopplung, Entfernung und Bündelung von KI-beschleunigten Ressourcen. Es ist die Pooling-Abstraktion, die wir für die Zukunft aufbauen Infrastrukturschicht.

Oben auf der Ressourcen-Pooling-Schicht befindet sich die einheitliche Ressourcenplanungsschicht Matrix/k8s (Matrix ist hier das Container-Planungssystem in der Baidu-Fabrik. Zusätzlich zum Planungsmechanismus werden wir eine Vielzahl von Ressourcen basierend auf verschiedenen Geschäftsszenarien abstrahieren). Zu den Mischstrategien gehören gemeinsames Mischen, präventives Mischen, zeitgeteiltes Mischen, Gezeitenmischen usw. Diese gemischten Vertriebsstrategien werden im anschließenden Praxisteil ausführlich erläutert.

Das Verlassen auf Ressourcenisolation und Ressourcenplanung ist das umfassende Szenario des KI-Geschäfts, einschließlich Modellentwicklung, Modelltraining und Online-Argumentation.

Als nächstes werde ich Ihnen die Implementierung der Benutzermodus- bzw. Kernelmodus-Isolations-Engines vorstellen.

Die folgende Abbildung ist ein schematisches Diagramm der Kernarchitektur der User-Space-Isolation-Engine. Oben im Architekturdiagramm befindet sich die Benutzeranwendung, die verschiedene häufig verwendete Frameworks wie PaddlePaddle, TensorFlow, PyTorch usw. umfasst.

Unter der Benutzeranwendung befindet sich eine Reihe von API-Hook-Schnittstellen. Basierend auf diesem Satz von Schnittstellen können wir die lokale Nutzung und Remote-Montage von GPU-Ressourcen realisieren. Durch den Austausch der zugrunde liegenden dynamischen Bibliotheken, auf die das Framework angewiesen ist, werden Ressourcenkontrolle und -isolation erreicht. Es ist wichtig zu beachten, dass diese Lösung für die Anwendung völlig transparent ist und die erforderlichen Vorgänge zum Ersetzen der Bibliothek automatisch von der Container-Engine und dem Planungsteil durchgeführt wurden.

Die CUDA-API erreicht den Executor schließlich über zwei Pfade nach Hook. Hier führt die überwiegende Mehrheit der APIs, wie z. B. die Geräteverwaltungs-API, nach dem Durchlaufen des Hooks keine Vorgänge aus und leitet sie zur Ausführung direkt an den Executor weiter. Eine kleine Anzahl von APIs im Zusammenhang mit der Ressourcenanwendung durchlaufen eine Abfangschicht, über die eine Reihe von Funktionen der User-Space-Virtualisierung implementiert werden können. Die Logik dieser Schicht ist effizient genug implementiert und die Auswirkungen auf die Leistung sind nahezu vernachlässigbar.

Derzeit kann die Benutzermodus-Isolations-Engine umfangreiche Isolations- und Steuerungsfunktionen bereitstellen, einschließlich grundlegender Videospeicherisolation und Rechenleistungsisolation. Wir haben auch viele erweiterte Funktionen erweitert: Encoder-Isolation, hochwertige Preemption, Videospeicher-Überverteilung, Videospeicher-Pooling usw. ​

Die Vorteile der Benutzermoduslösung sind eine gute Leistung und eine geringe Long-Tail-Latenz. Sie eignet sich für Geschäftsszenarien, die auf Mechanismusleistung und extreme Effizienz abzielen, wie z. B. verzögerungsempfindliche Online-Inferenzgeschäfte. ​

Auf der Grundlage der Isolation stellen wir Remote-Funktionen bereit. Die Einführung von Remote wird die Flexibilität der Ressourcenkonfiguration und die Nutzungseffizienz erheblich verbessern, worauf wir am Ende dieses Artikels näher eingehen werden.

Dieser Austausch ist ein Technologieaustausch. Hier werde ich einen kleinen Raum nutzen, um auf die wichtigsten Punkte und Schwierigkeiten der Remote-Technologie einzugehen, in der Hoffnung, die Geschäftsideen und technischen Diskussionen aller anzuregen.

Gemäß dem Software- und Hardware-Technologie-Stack, den wir in der vorherigen Virtualisierungsherausforderung erwähnt haben, kann der Fernzugriff auf die GPU im Allgemeinen auf der Hardware-Link-Ebene, der Treiberebene, der Laufzeitebene und der Benutzerebene implementiert werden. Allerdings nach eingehender technischer Analyse In Kombination mit unserem Verständnis von Geschäftsszenarien glauben wir, dass derzeit die Laufzeitschicht am besten geeignet ist.

Bestimmen Sie die technische Route der Laufzeitschicht und wie wird sie implementiert? Was ist der Sinn der Technologie? Wir glauben, dass es vor allem eine Frage der semantischen Konsistenz ist. Basierend auf der Laufzeitentfernung muss der ursprüngliche lokale Prozess in zwei Prozesse aufgeteilt werden: Client und Server. Die CUDA-Laufzeit ist Closed Source und die interne Implementierungslogik kann nicht untersucht werden. Wie kann sichergestellt werden, dass die ursprüngliche Programmlogik und API-Semantik nach der Aufteilung des Prozesses erhalten bleibt? Hier verwenden wir ein Eins-zu-eins-Thread-Modell, um die Logik und semantische Ausrichtung innerhalb der API sicherzustellen.

Die Schwierigkeit der Remote-Implementierung ist das Problem zahlreicher APIs. Neben der dynamischen Bibliothek libcudart.so umfasst die Laufzeit auch eine Reihe dynamischer Bibliotheken und APIs wie cuDNN, cuBLAS und cuFFT, die Tausende verschiedener API-Schnittstellen umfassen . Wir verwenden Kompilierungstechnologie, um das automatische Parsen von Header-Dateien und die automatische Generierung von Code zu erreichen und die Analyse versteckter APIs durch Reverse Engineering abzuschließen.

Lösung zur Remote-Lösung 0-1 Nach der Anpassung ist die spätere Abwärtskompatibilität eigentlich relativ einfach zu lösen. Derzeit scheint die CUDA-API relativ stabil zu sein und neue Versionen erfordern nur geringe inkrementelle Anpassungen.

Raummultiplex und Zeitmultiplex wurden oben schon oft erwähnt. Hier eine ausführliche Erklärung:

• Zeitmultiplex: Wie der Name schon sagt, handelt es sich um Multiplexen auf Zeitscheibenebene. Dies ähnelt der CPU-Prozessplanung. In einem einzelnen Zeitabschnitt wird nur ein GPU-Prozess ausgeführt. Auf der Mikroebene laufen mehrere GPU-Prozesse abwechselnd ab und können nur gleichzeitig ablaufen. Dies führt auch dazu, dass innerhalb einer bestimmten Zeitspanne, wenn der Prozess die Rechenressourcen nicht sinnvoll nutzen kann, diese Rechenressourcen verschwendet werden.
• Raummultiplex: Anders als beim Zeitmultiplex können beim Raummultiplex zu einem bestimmten Mikrozeitpunkt mehrere Prozesse gleichzeitig auf einer GPU ausgeführt werden. Solange die Ressourcen dieser GPU nicht vollständig genutzt werden, können andere Prozesse ausgeführt werden Der Kernel kann gestartet werden. Die Kernel der beiden Prozesse werden verschachtelt und auf Mikroebene ausgeführt, wodurch echte Parallelität erreicht und GPU-Ressourcen weiter genutzt werden.

Wie im Übersichtsabschnitt vorgestellt, handelt es sich bei den derzeit gängigen Virtualisierungsmethoden, einschließlich Kernel-State-Virtualisierung und NVIDIA vGPU-Virtualisierung, tatsächlich um Zeitmultiplexlösungen, die auf der Zeitscheibenrotation auf der untersten Ebene basieren. ​

NV hat MPS auf den Markt gebracht – eine Multiprozess-Servicelösung für Multiprozess-Parallelitätsszenarien. Diese Lösung kann Space Division Multiplexing erreichen und ist derzeit die einzige Lösung, die sowohl Effizienz als auch Leistung berücksichtigt. ​

Hier ist eine kurze Einführung in MPS, die dem Zusammenführen der Kontexte zweier Prozesse zu einem Prozess entspricht. Der zusammengeführte Prozess verwebt die Kernel der beiden vorherigen Prozesse für den Start. Dies hat zwei Vorteile:

• Kein Kontextwechsel zwischen Prozessen erforderlich, wodurch der Aufwand für den Kontextwechsel reduziert wird.
• Gleichzeitig werden die Kernel verschiedener Prozesse verschachtelt, wodurch die Ressourcennutzung verbessert wird.

Wenn wir von MPS sprechen, müssen wir einen Kritikpunkt erwähnen – das Problem der Fehlerisolierung. ​

Wie kann dieses MPS-Stabilitätsproblem gelöst werden? Baidu Intelligent Cloud kombiniert Planung, Container-Engine und Business-Keep-Alive, um ein komplettes Set an Prozessintegrations- und Sharing-Lösungen anzubieten.

• Erzielen Sie ein ordnungsgemäßes Beenden von Geschäftsprozessen durch die Umleitung von Kill-Befehlen.
• Erzielen Sie eine Gesundheitsprüfung und eine Erkennung angehaltener Animationen durch den MPS-Statuserkennungsmechanismus.
• Verwenden Sie Service Keepalive, um einen automatischen Neustart von Benutzerprozessen zu realisieren. sensibles wichtiges Geschäft) 90 %+ Ressourcen und läuft seit mehr als zwei Jahren Obwohl es ultimative Leistung bietet, kann es meiner Meinung nach die Stabilitätsanforderungen der meisten Benutzer erfüllen.

Mit zunehmender Akzeptanz von MPS verbessert NV weiterhin die Stabilität von MPS. Hier sind gute Nachrichten im Voraus. NV wird die Stabilität von MPS in der zweiten Hälfte dieses Jahres erheblich verbessern, einschließlich der Erkennung des angehaltenen Animationsstatus und des ordnungsgemäßen Beendens des Prozesses. Diese Funktionen werden Teil des MPS-Produkts sowie der Stabilität und Benutzerfreundlichkeit von MPS wird weiter verbessert.

Bevor ich die High-Quality-Preemption-Funktion vorstelle, möchte ich Ihnen zunächst das Geschäftsszenario der High-Quality-Preemption vorstellen. Laut unseren Gesprächen mit verschiedenen Benutzern innerhalb und außerhalb der Fabrik können die meisten Produktionsumgebungen für KI-Anwendungen in drei Arten von Aufgaben unterteilt werden: Online, Nearline und Offline, basierend auf der Latenzempfindlichkeit.

Online-Aufgaben haben die höchste Latenz und sind im Allgemeinen Inferenzaufgaben, die in Echtzeit auf Benutzeranfragen reagieren.

Nearline-Aufgaben sind im Allgemeinen Stapelverarbeitungsaufgaben, bei denen keine Anforderungen an die Verzögerung eines einzelnen Protokolls gestellt werden, sondern an die Abschlusszeit von ein Datenstapel. Anforderungen im Bereich von Stunden bis Minuten;
• Offline-Aufgaben, die keine Anforderungen an die Latenz stellen und sich nur auf den Durchsatz konzentrieren, sind im Allgemeinen Modelltrainingsaufgaben.
• Wenn wir verzögerungsempfindliche Aufgaben als qualitativ hochwertige Aufgaben und verzögerungsunempfindliche Nearline- und Offline-Aufgaben als minderwertige Aufgaben definieren. Und wenn zwei Arten von Aufgaben gemischt werden, werden unterschiedliche Kernel-Startprioritäten entsprechend den unterschiedlichen Aufgabenprioritäten definiert. Dies ist die oben erwähnte hochwertige Vorkaufsfunktion. ​

Das Implementierungsprinzip ist in der folgenden Abbildung dargestellt. Die Benutzermodus-Isolations-Engine verwaltet eine logische Kernel-Warteschlange für Aufgaben hoher Qualität und Aufgaben niedriger Qualität. Wenn die Gesamtlast niedrig ist, können die beiden Warteschlangen Kernel gleichzeitig starten. Zu diesem Zeitpunkt werden die Kernel der beiden Warteschlangen verschachtelt und gemeinsam ausgeführt. Sobald die Last zunimmt, wartet das hierarchische Startmodul sofort auf den Start von Warteschlangen mit geringer Qualität, um die Ausführungsverzögerung von Aufgaben mit hoher Qualität sicherzustellen.

Der Vorteil dieser Funktion besteht darin, den Offline-Durchsatz sicherzustellen und gleichzeitig die Auswirkungen von Online-Aufgaben zu reduzieren oder sogar zu vermeiden.

In ähnlicher Weise stellen wir zunächst die Definition und die Szenarien des Time-Sharing-Mischens vor.

Time-Sharing-Mischen ist ein bisschen wie ein gemeinsames Mischen mit Zeitscheibenrotation im Mischmodus. Der Unterschied besteht darin, dass die Time-Sharing-Hybridverteilung keine Videospeicher-Swap-Lösung für den Videospeicher vorschlägt, was in Situationen nützlich ist, in denen der Videospeicher über einen längeren Zeitraum belegt ist, die Rechenleistung jedoch zeitweise genutzt oder gelegentlich ausgelöst wird. Wenn der Prozess Rechenleistung benötigt, erhält er Zugriffsrechte auf den Videospeicher. Wenn der Prozess die Berechnung abschließt, gibt er die Zugriffsrechte auf den Videospeicher frei, sodass andere Prozesse, die auf die Erlaubnis warten, ausgeführt werden können Zeitweise ungenutzte GPU-Ressourcen können vollständig genutzt werden.

Die Kerntechnologie des Time-Sharing-Mixings ist der Videospeicher-Swap. Wir können es mit dem CPU-Speicheraustausch vergleichen. Wenn der Speicher eines bestimmten Prozesses nicht ausreicht, lagert das System gemäß einer bestimmten Strategie einen Teil der Systemspeicherressourcen auf die Festplatte aus und gibt so Speicherplatz für den laufenden Prozess frei.

Das Implementierungsprinzip des Videospeicheraustauschs ist in der folgenden Abbildung dargestellt. Wir verwalten einen Videospeicherpool an der physischen Adresse des Videospeichers, und die obere Schicht verwendet Ressourcensperren, um zu bestimmen, welcher Prozess die Berechtigung zur Verwendung der GPU hat. Wenn der Prozess die Sperre erhält, wird der Videospeicher vom Speicher oder der Festplatte in den physischen Videospeicherpool verschoben und weiter dem virtuellen Adressraum zur Verwendung durch den Prozess zugeordnet. Wenn der Prozess die Sperre aufhebt, wird der virtuelle Speicherplatz des Prozesses reserviert und der physische Speicher wird in den Arbeitsspeicher oder auf die Festplatte verschoben. Die Sperre schließt sich gegenseitig aus. Nur ein Prozess kann die Sperre erhalten. Andere Prozesse stehen in der Warteschlange und erhalten Ressourcensperren auf FIFO-Weise.

Das Obige stellt die funktionale Implementierung der Benutzermodus-Isolations-Engine vor. Wie ist die Leistung und welche Auswirkungen hat sie auf Benutzer? Hier geht es direkt zu den Testdaten.

Das Bild unten zeigt den Datenvergleich in dem Szenario, in dem wir das typische Modell ResNet-50 Server auf dem öffentlichen Testset MLPerf ausgewählt haben. Die Spalten in der Abbildung stellen die Leistung unter exklusiver, nackter gemischter Isolierung, Benutzermodus-Isolation und Kernel-Modus-Isolation von links nach rechts dar.

Das Bild links ist ein Vergleich des durchschnittlichen Durchsatzes. Im Inferenzszenario werden Anfragen zeitweise ausgelöst, unabhängig davon, welche Lösung den Druckwert unter Durchsatz erreichen kann. Ich möchte hier erklären, dass der Durchsatz in Inferenzszenarien die Virtualisierungsleistung nicht sehr gut demonstrieren kann und Sie bei der Implementierung in einer Produktionsumgebung mehr auf die Latenz achten sollten.

Das Bild rechts ist ein Vergleich der P99-Quantilverzögerung. Es ist ersichtlich, dass im Benutzermodus unter niedrigem Druck (QPS = 40) der Einfluss des nackten Mischens auf die Long-Tail-Verzögerung grundsätzlich gleich ist, während der Kernel-Modus einen etwas größeren Einfluss auf die Long-Tail-Verzögerung hat bis hin zum Einsatz von Zeitmultiplex. Wir erhöhen den Druck weiter, wenn QPS = 60, die Vorteile des Raummultiplexings deutlich werden und die Auswirkungen auf die Long-Tail-Verzögerung deutlich reduziert werden. Da der Druck weiter zunimmt, ist die User-Space-Prozessfusionslösung sogar um Größenordnungen besser als andere hybride Verteilungsmethoden.

Obwohl die Steuerung der Long-Tail-Verzögerung nicht so gut ist wie der Benutzermodus, bietet der Kernel-Modus Vorteile in Bezug auf die Isolation und konzentriert sich eher auf Szenarien mit starken Isolationsanforderungen.

Werfen wir einen Blick auf die technische Implementierung der Kernel-Mode-Isolation-Engine.

Schauen wir uns zunächst die Merkmale der Kernel-Zustandsvirtualisierung an, einschließlich der folgenden:

Kernel-Zustandsimplementierung: Unterstützt Videospeicher, Rechenleistung und Fehlerisolation von 1 %; Rechenleistung; unterstützt P4, V100, T4, A100/A30 und andere Mainstream-GPUs; es sind keine Änderungen an der Benutzermodus-Ausführungsumgebung erforderlich;

Anders als bei der Implementierung im Benutzermodus ist die GPU-Isolationsfunktion der Kernel-Modus-Virtualisierung im Kernel-Modus implementiert. Die linke Hälfte der Abbildung unten ist ein Architekturdiagramm unserer Implementierung der Kernel-Status-Virtualisierung. Von der unteren bis zur oberen Ebene handelt es sich um GPU-Hardware, Kernel-Ebene und Benutzerebene.

Die Hardwareebene ist unsere GPU. Diese GPU kann eine Bare-Metal-GPU oder eine transparente GPU sein.

Unterhalb der Kernelschicht befindet sich der ursprüngliche Treiber der GPU, der tatsächlich die Funktionen der GPU steuert. Über dem GPU-Treiber befindet sich dann ein Kernelmodul für die GPU-Virtualisierung GPU-Abfangen Der Treiber, der gelbe Teil, enthält drei Funktionen, einschließlich Speicherabfangen, Abfangen der Rechenleistung und Planung der Rechenleistung. Videospeicherisolierung und Rechenleistungsisolierung werden separat implementiert.

Benutzerebene ist zunächst die Abfangschnittstelle. Diese Schnittstelle wird vom Abfangmodul bereitgestellt und ist in zwei Teile unterteilt: Der eine ist die Gerätedateischnittstelle und der andere ist die Schnittstelle zum Konfigurieren des Abfangmoduls. Gerätedateien werden Containern bereitgestellt. Die Oberseite des Containers ist die Anwendung, die Unterseite ist die Cuda-Laufzeit und die Unterseite ist die zugrunde liegende Cuda-Bibliothek, einschließlich Treiber-API/NVML-API usw. Indem wir unsere Gerätedatei als gefälschte Gerätedatei für den Container bereitstellen, greift der CUDA der oberen Ebene auf unsere Gerätedatei zu. Damit ist das Abfangen des Zugriffs auf den GPU-Treiber durch die zugrunde liegende CUDA-Bibliothek abgeschlossen.

​Unser Abfangmodul im Kernel fängt alle Systemaufrufe ab, auf die zugegriffen wird, fängt sie ab, analysiert sie und leitet dann den tatsächlichen Zugriff auf den zugrunde liegenden Treiber der echten GPU um. Nachdem der zugrunde liegende GPU-Treiber die Verarbeitung abgeschlossen hat, gibt er das Ergebnis an unser Abfangmodul zurück, das es erneut verarbeitet und schließlich das Ergebnis an die zugrunde liegende Bibliothek im Container zurückgibt.

Einfach ausgedrückt: Es fängt den Zugriff der zugrunde liegenden Bibliothek auf den GPU-Treiber ab, indem es Gerätedateien simuliert, und vervollständigt das Abfangen von Videospeicher und Rechenleistung durch Vorgänge wie Abfangen, Parsen und Injektion.

Derzeit wird die Isolierung des Videospeichers durch das Abfangen aller Videospeicher-bezogenen Systemaufrufe erreicht, zu denen hauptsächlich Videospeicherinformationen, Videospeicherzuweisung und Videospeicherfreigabe gehören. Darüber hinaus kann die aktuelle Speicherisolation nur statisch eingestellt und nicht dynamisch geändert werden. Während der Benutzermodus eine Überentwicklung des Videospeichers unterstützen kann, kann der Kernelmodus eine Überentwicklung des Videospeichers noch nicht unterstützen.

Im Hinblick auf die Isolation der Rechenleistung erhalten Sie relevante Informationen, indem Sie den CUDA-Kontext des Prozesses abfangen. Das Planungsobjekt ist der prozessbezogene CUDA-Kontext. Zu den dem CUDA-Kontext entsprechenden Rechenressourcen gehören Rechenressourcen (Ausführung) und Speicherkopierressourcen (Kopieren). Jede GPU verfügt über einen Kernel-Thread, der alle CUDA-Kontexte auf dieser GPU plant.

Wir haben 4 Kernel-Modus-Rechenleistungsplanungsalgorithmen implementiert:

• Fester Anteil: Jedem POD wird eine feste Rechenleistungsressource zugewiesen, d. h. die Rechenleistung der gesamten GPU ist fest in n Anteile aufgeteilt. und jeder POD ist in 1 /n Rechenleistung unterteilt.
• Gleicher Anteil: Alle aktiven PODs teilen sich die Rechenleistungsressourcen gleichmäßig, d. h. die Anzahl der aktiven PODs beträgt n und jeder POD teilt sich 1/n der Rechenleistung.
• Gewichtungsanteil: Jeder POD weist Rechenleistungsressourcen entsprechend dem Gewicht zu, d. h. die Rechenleistung der gesamten GPU wird jedem POD entsprechend dem Gewichtswert zugewiesen. Unabhängig davon, ob der POD geschäftlich ausgelastet ist, wird die Rechenleistung entsprechend der Gewichtung zugewiesen.
• Burst-Gewichtsanteil: Aktive PODs weisen Rechenleistungsressourcen entsprechend der Gewichtung zu, d. h. jedem POD wird ein Gewichtungswert zugewiesen, und aktiven PODs wird Rechenleistung entsprechend dem Gewichtungsverhältnis zugewiesen.

Da der Kernel-Modus die Rechenleistung in Zeitscheiben plant, ist er für verzögerungsempfindliche Unternehmen nicht sehr geeignet. Wir haben speziell eine Offline-Colocation-Technologie entwickelt. Durch die Co-Location von Online- und Offline-Geschäften können wir die Reaktionsgeschwindigkeit von Online-Geschäften erheblich verbessern und es Offline-Unternehmen ermöglichen, GPU-Rechenressourcen gemeinsam zu nutzen, um das Ziel einer höheren GPU-Ressourcenauslastung zu erreichen . . Die Merkmale unserer gemischten Offline-Bereitstellung sind:

• Online-POD: Argumentationsaufgaben, die normalerweise nur wenig Rechenleistung beanspruchen.
• Offline-POD: Trainingsaufgaben, die normalerweise den größten Teil der Rechenleistung beanspruchen.

Wenn der Online-POD eine Aufgabenlast hat, übernimmt er sofort den Offline-POD und nutzt die gesamte Rechenleistung, um Inferenzdienste bereitzustellen. Wenn die Aufgabenlast endet, wird die Rechenleistung an den Offline-POD freigegeben. ​

Das Folgende sind die Bewertungsergebnisse der Kernel-Modus-Rechenleistungsisolierung:

Die Testumgebung ist eine einzelne Karte V100 SXM2 16G. Der Test verwendet das Horovod-Framework und das Modell ist resnet50.

Das Gewichtsverhältnis von POD 1 und POD 2 beträgt 1:2.

Aus den Ergebnissen der obigen Abbildung ist ersichtlich, dass das Durchsatzverhältnis von POD 1 und POD 2 45–50 % beträgt, was etwa 1/2 entspricht, was unserem voreingestellten Wert entspricht. Gleichzeitig weist POD SUM im Vergleich zu Native einen Verlust von 2 bis 4 % auf. Da die Rechenleistungsisolation Schaltvorgänge im Cuda-Kontext erfordert, liegt unser Verlust jedoch innerhalb von 5 % innerhalb des Toleranzbereichs liegen.

Vergleichen wir die Eigenschaften des Kernelmodus und des Benutzermodus.

In Bezug auf die Fehlerisolierung hat der Kernelmodus Vorteile gegenüber dem Benutzermodus, und der Kernelmodus muss die zugrunde liegende Bibliothek nicht ersetzen. Die Rechenleistungsplanung im Benutzermodus verwendet Zeitmultiplex plus Raummultiplex und der Kernelmodus verwendet Zeitmultiplex. Zu den erweiterten Funktionen im Benutzermodus gehören Offline-Colocation, Überverteilung von Videospeicher zu Speicher, Codierungs- und Decodierungsinstanzen (unabhängige Zuweisung von Codierungs- und Decodierungsressourcen der AI-Beschleunigerkarte) und wir unterstützen auch Offline-Colocation in Kernel-Modus.

Wie man Virtualisierungstechnologie nutzt, um die GPU-Nutzungseffizienz in KI-Szenarien zu verbessern, basierend auf tatsächlichen Fällen in die Praxis.

Schauen wir uns zunächst ein typisches Szenario in einem Inferenzdienst an. Aufgrund der modelleigenen Architektur oder der hohen Anforderungen an die Servicelatenz können einige Aufgaben nur in einer Konfiguration ausgeführt werden, in der die Batchgröße sehr klein ist, oder selbst wenn die Batchgröße 1 beträgt. Dies führt direkt zu einer langfristig niedrigen GPU-Auslastung, und selbst die Spitzenauslastung beträgt nur 10 %.

In diesem Szenario sollte als Erstes daran gedacht werden, mehrere Aufgaben mit geringer Auslastung zu mischen.

Wir fassen diese Mixing-Strategie als Shared Mixing zusammen. Ob in Entwicklungs-, Schulungs- oder Inferenzszenarien, wir können die gemeinsame Mischung zwischen mehreren Aufgaben mit geringer Auslastung nutzen.

In Kombination mit der oben erwähnten Prozessfusionstechnologie ist es möglich, eine gemeinsame Vermischung von 2 Instanzen oder sogar mehreren Instanzen auf der Grundlage der Gewährleistung einer Serviceverzögerung zu erreichen und die Ressourcenauslastung um mehr als das Zweifache zu erhöhen. ​

Gleichzeitig verfügen die meisten GPUs über unabhängige Kodierungs- und Dekodierungsressourcen. In den meisten Szenarien bleibt die Ressource, wie in der Abbildung unten links dargestellt, lange Zeit im Leerlauf. Auf der Grundlage gemeinsam genutzter Rechenressourcen können wir eine Kodierungs- oder Dekodierungsinstanz mischen, um die Ressourcenleistung weiter zu verbessern und ungenutzte Ressourcen zu aktivieren.

Ein typisches Auslastungsmuster des Inferenzdienstes besteht darin, dass es im Laufe des Tages offensichtliche Spitzen- und Talschwankungen gibt und es zu unvorhersehbarem kurzfristigem Verkehr kommt Spannungsspitzen. Dies zeigt, dass der Spitzenwert zwar hoch ist, die durchschnittliche Auslastung jedoch sehr schlecht ist, wobei der Durchschnittswert häufig unter 30 % oder sogar 20 % liegt.

Solche Schwankungen sind offensichtlich. Wie lässt sich die Effizienz von Diensten optimieren, die in kurzer Zeit ansteigen? Wir schlagen eine präventive gemischte Vertriebsstrategie vor.

Beim Preemption-Mixing wird eine verzögerungsunempfindliche Aufgabe mit geringer Qualität mit einem qualitativ hochwertigen Geschäft mit hohem Spitzenwert und hoher Verzögerungsempfindlichkeit gemischt. Dabei wird die hohe und die niedrige Qualität vom Benutzer definiert und bei der Beantragung von Ressourcen explizit angegeben. In der internen Praxis von Baidu definieren wir Nearline- und Offline-Datenbank-Brushing- oder Trainingsaufgaben als minderwertig. Diese Art von Geschäft stellt bestimmte Anforderungen an den Durchsatz und grundsätzlich keine Anforderungen an die Latenz. ​

Durch die Verwendung des hochwertigen Vorkaufsmechanismus in der Virtualisierungsfunktion haben hochwertige Aufgaben immer die Initiative, Ressourcen zu belegen. Wenn der Datenverkehr am Tiefpunkt angelangt ist, ist die Belastung der gesamten Karte nicht hoch, und niedrig-optimale Aufgaben können normal ausgeführt werden. Sobald der Datenverkehr seinen Höhepunkt erreicht hat oder ein kurzfristiger Anstieg auftritt, kann der Hoch-optimal-Präemptionsmechanismus dies tun Erkennen Sie in Echtzeit und nutzen Sie die Rechenleistung bei der Kernel-Granularität. Zu diesem Zeitpunkt sind Aufgaben mit geringer Qualität flussbegrenzt oder sogar vollständig ausstehend, um die Servicequalität von Aufgaben mit hoher Qualität sicherzustellen.

In diesem Hybridmodus ist möglicherweise nicht genügend Videospeicher vorhanden und die Rechenleistung ist möglicherweise stark redundant. Für diese Art von Szenario stellen wir einen impliziten Mechanismus zum Übersenden des Videospeichers bereit. Benutzer können Umgebungsvariablen verwenden, um den Videospeicher für Aufgaben mit geringer Qualität übermäßig zu verteilen und mehr Instanzen bereitzustellen, um sicherzustellen, dass immer Rechenleistung zur Verfügung steht, um Auslastungsdefizite zu füllen und die Gesamtauslastungseffizienz zu maximieren.

Die dritte Art von Geschäftsszenario dürfte jedem bekannt sein, nämlich das Szenario des permanenten Grafikspeichers und der intermittierenden Auslösung der Rechenleistung. Typische repräsentative Unternehmen sind Entwicklungsaufgaben und Online-Schulungen.

Hier ist ein Online-Training als Beispiel. Wir wissen, dass viele Modelle online auf der Grundlage täglicher oder sogar stündlicher Benutzerdaten aktualisiert werden müssen, beispielsweise Empfehlungsmodelle, was eine Online-Schulung erfordert. Anders als beim Offline-Training, bei dem der Durchsatz in Echtzeit erreicht wird, muss beim Online-Training ein Datenstapel gesammelt und eine Trainingssitzung ausgelöst werden. Innerhalb von Baidu kann das typische Modell so aussehen, dass ein Datenstapel in 15 Minuten eintrifft, die tatsächliche Trainingszeit jedoch nur 2 bis 3 Minuten beträgt. In der verbleibenden Zeit verbleibt der Trainingsprozess im Videospeicher und wartet dort bis zum nächsten Stapel der Daten kommen vom Upstream. In diesem Zeitraum lag die Auslastung lange Zeit bei 0, was zu einer großen Ressourcenverschwendung führte.

Diese Art von Aufgabe kann das oben erwähnte gemeinsame Mischen oder präventive Mischen nicht verwenden, da der Videospeicher grundsätzlich voll ist. In Kombination mit dem zuvor erwähnten Videospeicher-Austauschmechanismus haben wir eine Time-Sharing-Mischstrategie vorgeschlagen.

Time-Sharing-Mixing ähnelt dem Shared-Mixing der Zeitscheibenrotation, allerdings wird zu diesem Zeitpunkt auch der Videospeicher zusammen mit dem Computerkontext ein- und ausgelagert. Da die zugrunde liegende Virtualisierungsschicht nicht erkennen kann, wann das Unternehmen Berechnungen benötigt, pflegen wir eine globale Ressourcensperre für jede GPU-Karte. Und kapselt die entsprechenden C++- und Python-Schnittstellen, die Benutzer aufrufen können. Benutzer müssen diese Sperre nur dann beantragen, wenn sie eine Berechnung durchführen müssen. Nach Abschluss der Berechnung wird der Videospeicher automatisch aus anderen Bereichen in den Videospeicherbereich verlagert in den Arbeitsspeicher oder Festplattenspeicher ausgelagert werden. Mithilfe dieser einfachen Schnittstelle können Benutzer die GPU zeitlich gemeinsam nutzen und exklusiv für mehrere Aufgaben nutzen. In Online-Schulungsszenarien kann die Verwendung von Time-Sharing-Mixing bis zu 4/5 der Ressourcen einsparen und gleichzeitig die Gesamtauslastung erhöhen.

Die Best Practices der drei oben genannten Szenarien wurden verifiziert und in großem Umfang im internen Geschäft von Baidu implementiert. Verwandte Funktionen wurden auch auf der heterogenen Computerplattform Baidu Baige·AI eingeführt, die Sie sofort anwenden und ausprobieren können.

Hier werde ich etwa drei Minuten damit verbringen, über die Funktionen zu sprechen, die sich noch in der internen Überprüfung befinden. Diese Funktionen werden in naher Zukunft auf der Baidu Baige-Plattform fertiggestellt, um die häufige ungleichmäßige Verteilung und Verteilung in großen KI-Szenarien weiter zu lösen. Probleme wie Angebots- und Nachfrageungleichgewicht und Ressourcenfragmentierung.

Studenten, die im Bereich Infrastruktur arbeiten, werden häufig Konzepte wie Ressourcenentkopplung und -pooling hören. Wie wir das Konzept des Poolings umsetzen und in tatsächliche Produktivität umwandeln können, ist das, was wir aktiv erforscht und gefördert haben. Bereits 2015 haben wir die branchenweit erste Hardware-Pooling-Lösung basierend auf der PCIe Fabric-Lösung implementiert und diese in großem Umfang innerhalb von Baidu implementiert. Dies ist der gerade erwähnte X-MAN 1.0 (der sich jetzt zu 4.0 weiterentwickelt hat). Konfigurieren Sie die Verbindung zwischen CPU und GPU über das PCIe Fabric-Netzwerk, um eine dynamische Zuweisung von Ressourcen zu realisieren und das Verhältnisproblem in verschiedenen Szenarien zu lösen. Diese Lösung ist durch Hardwareverbindungen und Protokolle eingeschränkt und kann nur Pooling innerhalb des Schranks lösen.

Software Layer Pooling ist eine technische Lösung, die wir für flexibler halten. Da die Netzwerke von Rechenzentren weiter modernisiert werden, werden 100G- oder sogar 200G-Netzwerke in Zukunft zur Standardkonfiguration der Infrastruktur werden, und Hochgeschwindigkeitsnetzwerke bieten eine Kommunikationsautobahn für die Bündelung von Ressourcen.

Die Entkopplung und Bündelung von Ressourcen verschafft dem Unternehmen mehr Flexibilität und schafft mehr Spielraum für die Leistungsoptimierung. Zum Beispiel das Verhältnisproblem zwischen CPU und GPU, das Problem des langfristigen Ungleichgewichts zwischen Angebot und Nachfrage bei der Ressourcenbelegung in Entwicklungsszenarien und geringer Effizienz, das Problem der Blockierung von Ressourcenfragmentierungsaufgaben in Trainingsszenarien und das Problem eines abnormalen Trainingsneustarts der Ausrüstung. Solche Szenarien können alle in Pooling- und derivativen Lösungen gelöst werden.

Schließlich wurden alle oben genannten Virtualisierungstechnologien und Best Practices auf der heterogenen Computerplattform Baidu Baige AI eingeführt. Suchen Sie auf der offiziellen Website von Baidu Intelligent Cloud nach „Baidu Baige“, um KI-Aufgaben sofort zu beschleunigen und die geschäftliche Fantasie anzuregen!

Fragen und Antworten zur Auswahl

F: Allgemeine Ressourcen werden über Namespace und cgroup in Containern zusammengefasst. Darf ich fragen, welche Technologie die GPU verwendet, um die Ressourcenkontrolle zu erreichen?

A: Namespace und cgroup sind beide vom Kernel bereitgestellte Mechanismen und basieren im Wesentlichen auf verwandten Funktionen, die von der Hardware bereitgestellt werden. Dies ist auf der aktuellen GPU nicht vorhanden. Die GPU ist derzeit Closed Source und wird es auch für längere Zeit sein. Nur Hardwareanbieter können diese Funktionen bereitstellen, die auf die Kernel-Hauptlinie übertragen werden können. Bei den aktuellen Lösungen von Drittanbietern handelt es sich allesamt um nicht standardmäßige Implementierungen im Benutzermodus oder Kernelmodus, und es gibt derzeit keine Möglichkeit, sie in Namespace- und Cgroup-Kategorien aufzunehmen. Es kann jedoch davon ausgegangen werden, dass die GPU-Virtualisierung den entsprechenden Mechanismus unter diesen Schnittstellen implementieren möchte. Ob er standardisiert werden kann, ist eine weitere größere Frage.

F: Haben wir zusätzlich zur GPGPU-Virtualisierungstechnologie eine NPU-bezogene Virtualisierungstechnologie entwickelt? Ob vom NV-Technologie-Stack abgekoppelt werden soll. Danke!

A: Ich verstehe, dass die hier erwähnte NPU eine Network Processing Unit sein sollte, was sich im Allgemeinen auf alle aktuellen KI-Beschleunigungshardware bezieht. Wir arbeiten an der Virtualisierungsanpassung anderer KI-Beschleunigungshardware. Der erste ist der Kunlun-Kern. Wir haben die oben genannten Virtualisierungsfunktionen bereits auf den Kunlun-Kern angepasst. Da sich die Szene ausdehnt, wird auch weiterhin andere Mainstream-Beschleunigungshardware angepasst.

F: Sind Benutzermodus und Kernelmodus zwei verschiedene Produkte?

A: Es handelt sich um dasselbe Produkt mit unterschiedlichen zugrunde liegenden Implementierungsmethoden, aber die Ebene der Benutzeroberfläche ist einheitlich.

F: Welche Granularität kann durch Virtualisierung im Benutzermodus erreicht werden?

A: Die Rechenleistung kann in 1 % Granularität unterteilt werden, und der Videospeicher kann in 1 MB unterteilt werden.

F: Verursacht die Kernel-Modus-Virtualisierung einen größeren Kontrollaufwand?

A: Die Kernel-Zustandsvirtualisierung basiert auf Time-Slicing. Der Overhead wird hier durch Time-Slicing verursacht. Eine genaue Isolierung führt zwangsläufig zu einem Verlust an Rechenleistung. Wenn es sich um den Mehraufwand für die Anwendungsleistung handelt, ist es wahr, dass der Kernel-Modus größer ist als der Benutzermodus.

F: Gemäß dem Time-Division-Implementierungsplan hat die Online-Inferenz den Eindruck, dass die durchschnittliche Zeit des freien Wettbewerbs schneller ist.

A: Gemäß unseren Testergebnissen ist die Leistungsreihenfolge von gut bis schlecht: Prozessfusion, nacktes Mischen (freie Konkurrenz) und Isolierung mit harten Grenzwerten.

F: Können die beiden Virtualisierungsmethoden der GPU in einem k8s-Cluster nebeneinander existieren?

A: Mechanisch und prinzipiell ist eine Koexistenz möglich. Aber derzeit wollen wir das Design aus Produktsicht nicht so kompliziert machen, deshalb trennen wir sie trotzdem. Wenn es umfassende Anforderungen von nachfolgenden Unternehmen gibt, werden wir die Einführung einer ähnlichen Koexistenzlösung in Betracht ziehen.

F: Können Sie bitte im Detail erläutern, wie der k8s-Planer erweitert werden kann? Muss der Agent auf dem Knoten die GPU-Topologie und die Gesamtmenge melden?

A: Ja, hierfür ist ein eigenständiger Agent erforderlich, um Ressourcen (einschließlich Videospeicherressourcen und Rechenleistungsressourcen) und Topologieinformationen hochzuladen.

F: Haben Sie Vorschläge zur Wahl der Zeit- und Raumminuten?

A: Für verzögerungsempfindliche Online-Argumentationsaufgaben wird empfohlen, eine auf Prozessfusion basierende Raumteilungslösung zu wählen. Für Szenarien, die eine strikte Isolierung erfordern, wird empfohlen, eine Time-Sharing-Lösung zu wählen. Bei anderen Szenenauswahlen gibt es keinen Unterschied zwischen den beiden.

F: Welche CUDA-Version kann der Kernel-Modus unterstützen? Wenn NV aktualisiert wird, wie lange dauert der Aktualisierungszyklus der Baidu Smart Cloud?

A: Da der Kernelmodus im Kernel virtualisiert ist, gibt es keine besonderen Anforderungen für die CUDA-Version. Derzeit werden alle CUDA-Versionen unterstützt. Wenn NV CUDA aktualisiert, sind keine besonderen Supportarbeiten zu erwarten.

F: Muss ich zur Verwendung des Kernel-Modus ein spezielles Betriebssystem-Image verwenden, das von Baidu Smart Cloud bereitgestellt wird? Eigener Fahrer?

A: Der Kernel-Modus erfordert nicht, dass Baidu Smart Cloud speziell ein Betriebssystem-Image bereitstellt. Derzeit unterstützen wir Centos7 und Ubuntu. Um es nutzen zu können, müssen wir jedoch unser eigenes Bereitstellungsframework verwenden. Für Container-Images gelten keine besonderen Anforderungen und alle können transparent unterstützt werden.

F: Ist es nur in der öffentlichen Cloud verfügbar? Kann es privat bereitgestellt werden?

A: Sowohl die Public Cloud als auch die Private Cloud können bereitgestellt und genutzt werden.

Das obige ist der detaillierte Inhalt vonTechnische Analyse und Praxisaustausch: Benutzermodus und Kernelmodus bei der Dual-Engine-GPU-Containervirtualisierung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!