In den letzten zehn Jahren hat sich die Landschaft der Softwareentwicklung für maschinelles Lernen erheblich verändert. Viele Frameworks sind entstanden, aber die meisten verlassen sich stark auf NVIDIAs CUDA und erzielen die beste Leistung auf NVIDIAs GPUs. Mit der Einführung von PyTorch 2.0 und OpenAI Triton wird jedoch Nvidias Dominanz in diesem Bereich gebrochen.
Google hatte in den Anfängen große Vorteile bei der Modellarchitektur, dem Training und der Modelloptimierung für maschinelles Lernen, aber jetzt ist es schwierig, diese Vorteile voll auszuschöpfen. Auf der Hardwareseite wird es für andere KI-Hardwareunternehmen schwierig sein, die Dominanz von Nvidia zu schwächen. Bis PyTorch 2.0 und OpenAI Triton auf den Markt kommen, wird der Standard-Software-Stack für Modelle des maschinellen Lernens nicht mehr Nvidias Closed-Source-CUDA sein.
Ähnlicher Wettbewerb findet in Frameworks für maschinelles Lernen statt. Vor einigen Jahren war das Framework-Ökosystem recht fragmentiert, aber TensorFlow war der Spitzenreiter. Oberflächlich betrachtet scheint Google fest in der Branche der Machine-Learning-Frameworks verankert zu sein. Sie haben den KI-anwendungsspezifischen Beschleuniger TPU mit TensorFlow entwickelt und sich so einen First-Mover-Vorteil verschafft.
Allerdings scheint es nun, dass PyTorch gewonnen hat und Google es nicht geschafft hat, seinen First-Mover-Vorteil in eine Dominanz in der aufstrebenden ML-Branche umzuwandeln. Google scheint heutzutage in der Machine-Learning-Community etwas isoliert zu sein, da es weder PyTorch noch GPUs verwendet, sondern seinen eigenen Software-Stack und seine eigene Hardware verwendet. Tatsächlich hat Google ein zweites Framework für maschinelles Lernen entwickelt – JAX, das direkt mit TensorFlow konkurriert. Dies ist ein typisches „Google-Verhalten“.
Einige glauben, dass Googles Dominanz bei der Suche und der Verarbeitung natürlicher Sprache aufgrund des Aufstiegs großer Sprachmodelle, insbesondere der großen Sprachmodelle von OpenAI und verschiedener Sprachmodelle, die mit der OpenAI-API erstellt wurden, schwindet. Vielleicht ist diese Sichtweise zu pessimistisch, schließlich handelt es sich bei der Infrastruktur der meisten aktuellen Modelle immer noch um den von Google entwickelten Transformator.
Warum ist PyTorch ein großer Gewinner? Der Hauptgrund ist, dass PyTorch im Vergleich zu TensorFlow eine höhere Flexibilität und Benutzerfreundlichkeit aufweist. Der Hauptunterschied zwischen PyTorch und TensorFlow besteht in der Verwendung des Eager-Modus anstelle des Graph-Modus.
Der Eager-Modus kann als Standardmethode zur Skriptausführung bezeichnet werden, die sich nicht von gewöhnlichem Python-Code unterscheidet. Dies erleichtert das Debuggen und Verstehen des Codes, da Benutzer die Ergebnisse von Zwischenoperationen und die Ausführung des Modells sehen können.
Im Gegensatz dazu ist der Grafikmodus in zwei Stufen unterteilt. Die erste Stufe stellt den Rechengraphen dar, auf dem Operationen ausgeführt werden sollen, wobei die Knoten Operationen oder Variablen darstellen und die Kanten zwischen Knoten den Datenfluss zwischen ihnen darstellen. Die zweite Stufe ist eine verzögerte Ausführung einer optimierten Version des Rechengraphen.
Dieser zweistufige Ansatz macht das Verstehen und Debuggen des Codes schwieriger, da der Benutzer nicht sehen kann, was passiert, bis die Diagrammausführung beendet ist. Dies ähnelt „interpretierten“ und „kompilierten“ Sprachen wie Python und C++. Das Debuggen von Python ist einfacher, da es sich um eine interpretierte Sprache handelt.
Während TensorFlow jetzt standardmäßig auch den Eager-Modus verwendet, entscheiden sich die Forschungsgemeinschaft und die meisten großen Technologieunternehmen für die Verwendung von PyTorch.
Wenn das Modelltraining für maschinelles Lernen auf die einfachste Form vereinfacht wird, gibt es zwei Hauptfaktoren, die sich auf das Modelltraining für maschinelles Lernen auswirken:
Früher war der Hauptfaktor, der die Trainingszeit für maschinelles Lernen beeinflusste, die Berechnungszeit, die darauf wartete, dass das System eine Matrixmultiplikation durchführte. Da sich Nvidia-GPUs weiterentwickeln, wird dies bald kein großes Problem mehr sein.
NVIDIA nutzte das Mooresche Gesetz, um FLOPS um Größenordnungen zu verbessern, aber die wichtigsten architektonischen Änderungen betrafen Tensorkerne und Gleitkommaformate mit geringerer Genauigkeit. Im Vergleich dazu hat sich an der Speicherfront nicht viel geändert.
Im Jahr 2018 war BERT das fortschrittlichste Modell und NVIDIA V100 war die fortschrittlichste GPU. Zu diesem Zeitpunkt war die Matrixmultiplikation nicht mehr der Hauptfaktor für die Verbesserung der Modellleistung. Danach wuchs die Anzahl der Parameter der Modelle um drei bis vier Größenordnungen, während die FLOPS der schnellsten GPUs um eine Größenordnung zunahmen.
Selbst im Jahr 2018 machten reine rechenintensive Workloads 99,8 % der FLOPS aus, aber nur 61 % der Laufzeit. Im Vergleich zur Matrixmultiplikation nutzen Normalisierung und punktweise Operationen nur 1/250 und 1/700 der FLOPS der Matrixmultiplikation, verbrauchen aber fast 40 % der Modelllaufzeit.
Da die Modellgrößen weiter steigen, benötigen große Sprachmodelle (LLM) mehr als 100 GB Speicher allein für die Modellgewichte. Die von Baidu und Meta eingesetzten Produktempfehlungsnetzwerke benötigen Dutzende Terabyte Speicher, um ihre riesigen Einbettungstabellen zu speichern. Beim Training/Inferenz großer Modelle wird die meiste Zeit nicht mit der Berechnung von Matrixmultiplikationen verbracht, sondern mit dem Warten auf die Übertragung von Daten. Offensichtlich stellt sich die Frage, warum Architekten nicht mehr Speicher näher an die Rechenleistung verlegen, und die Antwort liegt auf der Hand: Kosten.
Der nächstgelegene gemeinsame Speicherpool ist normalerweise SRAM auf demselben Chip. Einige ASICs für maschinelles Lernen versuchen, riesige SRAM-Pools zu nutzen, um Modellgewichte zu halten. Aber selbst der rund 5.000.000 US-Dollar teure Wafer-Chip von Cerebras verfügt nur über 40 GB SRAM. Die Speicherkapazität reicht nicht aus, um die Gewichte eines parametrischen Modells mit mehr als 100 Milliarden Byte aufzunehmen.
Nvidia hat die Chips mit viel weniger On-Chip-Speicher entwickelt – der A100 hat 40 MB und der H100 hat 50 MB. Ein 1-GB-SRAM auf einem TSMC-5-nm-Chip benötigt etwa 200 Quadratmillimeter Silizium, und die Implementierung der zugehörigen Steuerlogik/-struktur würde über 400 Quadratmillimeter Silizium erfordern. Angesichts der Tatsache, dass die A100-GPU über 10.000 US-Dollar kostet und die H100 eher bei 20.000 US-Dollar liegt, ist dieser Ansatz aus finanzieller Sicht nicht machbar. Selbst wenn man Nvidias Gewinnspanne von etwa 75 % bei Rechenzentrums-GPUs außer Acht lässt, kostet SRAM-Speicher für ein vollständig in Produktion befindliches Produkt immer noch etwa 100 US-Dollar/GB.
Darüber hinaus werden die Kosten für On-Chip-SRAM-Speicher nicht wesentlich sinken, da die traditionelle Mooresche Prozesstechnologie schrumpft. Derselbe 1-GB-Speicher nutzt die 3-nm-Prozesstechnologie der nächsten Generation von TSMC, die Kosten sind jedoch höher. 3D-SRAM wird zwar dazu beitragen, die SRAM-Kosten bis zu einem gewissen Grad zu senken, dies ist jedoch nur vorübergehend.
Der nächste Schritt in der Speicherhierarchie ist der eng gekoppelte Off-Chip-Speicher-DRAM. DRAM hat eine um eine Größenordnung höhere Latenz als SRAM (~100 ns gegenüber 10 ns), ist aber auch viel billiger. DRAM folgt seit Jahrzehnten dem Mooreschen Gesetz. Als Gordon Moore den Begriff prägte, war Intels Hauptgeschäft DRAM. Seine Vorhersagen zur Transistordichte und -kosten trafen im Allgemeinen für DRAM vor 2009 zu. Doch die DRAM-Kosten haben sich seit 2012 kaum verbessert.
Allerdings ist die Nachfrage der Menschen nach Gedächtnis nur gestiegen. DRAM macht mittlerweile 50 % der Gesamtkosten von Servern aus und bildet nach und nach die sogenannte „Speicherwand“. Beim Vergleich der 2016 P100-GPU von Nvidia mit der neuesten H100-GPU sehen wir, dass sich die Speicherkapazität auf das Fünffache (16 GB → 80 GB) und die FP16-Leistung auf das 46-fache (21,2 TFLOPS → 989,5 TFLOPS) erhöht hat.
Obwohl die Speicherkapazität ein wichtiger Engpass ist, ist ein weiterer Engpass – die Speicherbandbreite – ebenfalls sehr kritisch. Eine Erhöhung der Speicherbandbreite wird häufig durch Parallelität erreicht. Während Standard-DRAM heute nur wenige Dollar/GB kostet, verwendet Nvidia HBM-Speicher, um die enorme Bandbreite zu erhalten, die für maschinelles Lernen erforderlich ist – ein Gerät, das aus 3D-gestapelten DRAM-Schichten besteht und ein teureres Paket erfordert. HBM kostet etwa 10–20 US-Dollar/GB, einschließlich Verpackungs- und Volumenkosten.
Das Problem der Kostenbeschränkungen bei Speicherbandbreite und -kapazität zeigt sich besonders deutlich bei der A100-GPU von Nvidia. Ohne umfassende Optimierung kann der A100 nur eine sehr geringe FLOPS-Auslastung erreichen.
Selbst wenn Forscher viele Optimierungen vorgenommen haben, kann die FLOPS-Nutzungsrate großer Sprachmodelle nur etwa 60 % erreichen. Ein großer Teil der Zeit wird damit verbracht, auf Daten von einem anderen Rechner/Speicher zu warten oder Ergebnisse zeitnah neu zu berechnen, um Speicherengpässe zu reduzieren.
Von A100 bis H100 erhöhen sich die FLOPS auf mehr als das Sechsfache, die Speicherbandbreite erhöht sich jedoch nur auf das 1,65-fache. Dies hat bei vielen zu der Sorge geführt, dass die Auslastung des H100 gering sein wird. Der A100 erforderte viele Tricks, um die Speichermauer zu umgehen, und der H100 erfordert noch mehr Tricks, um dies zu erreichen.
H100 bringt verteilten Shared Memory und L2-Multicast in die Hopper-Architektur. Die Idee besteht darin, zu ermöglichen, dass Daten in einem SM direkt in den SRAM (gemeinsam genutzter Speicher/L1-Cache) eines anderen SM geschrieben werden. Dies erhöht effektiv die Cache-Größe und reduziert die für DRAM-Lese-/Schreibvorgänge erforderliche Bandbreite. Zukünftige Architekturen werden die Anzahl der an den Speicher gesendeten Vorgänge reduzieren, um die Auswirkungen von Speicherwänden zu minimieren. Es ist erwähnenswert, dass größere Modelle tendenziell eine höhere Auslastung erreichen, da FLOPS als Potenz der Anzahl der Parameter skaliert werden muss, während Speicherbandbreite und Kapazitätsanforderungen eher quadratisch skalieren.
Wenn die ganze Zeit für Speicherübertragungen aufgewendet wird (d. h. die Speicherbandbreite begrenzt ist), hilft es nicht, die FLOPS der GPU zu erhöhen. Wenn Sie andererseits Ihre ganze Zeit mit der Ausführung großer Mathe-Matmuls verbringen, hilft es nicht, die Modelllogik in C++ umzuschreiben, um den Overhead zu reduzieren.
Der Grund, warum PyTorch TensorFlow übertreffen kann, liegt darin, dass der Eager-Modus die Flexibilität und Benutzerfreundlichkeit verbessert, aber der Wechsel in den Eager-Modus ist nicht der einzige Vorteil. Bei der Ausführung im Eager-Modus wird jede Operation aus dem Speicher gelesen, berechnet und dann an den Speicher gesendet, bevor die nächste Operation verarbeitet wird. Ohne umfassende Optimierung kann dies den Bedarf an Speicherbandbreite erheblich erhöhen.
Für Modelle, die im Eager-Modus ausgeführt werden, ist die Operatorfusion eine der Hauptoptimierungsmethoden. Fusionsoperationen berechnen mehrere Funktionen in einem einzigen Durchgang, um Lese-/Schreibvorgänge im Speicher zu minimieren, anstatt jedes Zwischenergebnis in den Speicher zu schreiben. Die Operatorfusion verbessert die Operatorplanung, die Speicherbandbreite und die Kosten für die Speichergröße.
Diese Art der Optimierung erfordert normalerweise das Schreiben eines benutzerdefinierten CUDA-Kernels, aber das ist viel schwieriger als die Verwendung eines einfachen Python-Skripts. Im Laufe der Zeit wurden in PyTorch immer mehr Operatoren implementiert, von denen viele einfach mehrere gemeinsame Operationen zu einer komplexeren Funktion kombinieren.
Das Hinzufügen von Operatoren erleichtert das Erstellen von Modellen in PyTorch und der Eager-Modus ist aufgrund weniger Lese-/Schreibvorgänge im Speicher schneller. Der Nachteil ist, dass PyTorch innerhalb weniger Jahre auf über 2000 Betreiber angewachsen ist.
Wir können sagen, dass Softwareentwickler zu faul sind, aber um ehrlich zu sein, wer war nicht faul? Sobald sie sich an einen neuen Operator in PyTorch gewöhnt haben, verwenden sie ihn weiterhin. Der Entwickler erkennt möglicherweise nicht einmal, dass sich die Leistung verbessert, verwendet den Operator jedoch weiterhin, da dadurch kein weiterer Code mehr geschrieben werden muss.
Außerdem können nicht alle Betreiber fusioniert werden. Die Entscheidung, welche Vorgänge kombiniert und welche bestimmten Rechenressourcen auf Chip- und Clusterebene zugewiesen werden sollen, nimmt viel Zeit in Anspruch. Obwohl die Strategien zur Integration von Betreibern im Allgemeinen ähnlich sind, können sie aufgrund unterschiedlicher Architekturen stark variieren.
Das Wachstum und der Standardstatus der Betreiber sind für NVIDIA von Vorteil, da jeder Betreiber schnell für seine Architektur optimiert wird, jedoch nicht für andere Hardware. Wenn ein KI-Hardware-Startup PyTorch vollständig implementieren wollte, würde das bedeuten, eine wachsende Liste von 2.000 Betreibern mit hoher Leistung zu unterstützen.
Da das Extrahieren maximaler Leistung viel Geschick erfordert, erfordert das Training großer Modelle mit hoher FLOPS-Auslastung auf GPUs ein immer höheres Maß an Talent. Die eifrige Ausführung der additiven Operatorfusion bedeutet, dass die entwickelte Software, Techniken und Modelle ständig weiterentwickelt werden, um den Rechen- und Speicherverhältnissen der GPUs der aktuellen Generation gerecht zu werden.
Jeder, der Chips für maschinelles Lernen entwickelt, ist durch dieselbe Speichermauer eingeschränkt. ASICs sind durch die Unterstützung der am häufigsten verwendeten Frameworks, standardmäßige Entwicklungsmethoden, GPU-optimierten PyTorch-Code und eine Mischung aus NVIDIA und externen Bibliotheken eingeschränkt. In diesem Fall macht es wenig Sinn, über eine Architektur zu verfügen, die den verschiedenen nicht-rechentechnischen Ballast der GPU zugunsten von mehr FLOPS und einem strengeren Programmiermodell umgeht.
Allerdings steht die Benutzerfreundlichkeit an erster Stelle. Die einzige Möglichkeit, den Teufelskreis zu durchbrechen, besteht darin, die Software, die Modelle auf Nvidias GPUs ausführt, so einfach und nahtlos wie möglich auf andere Hardware übertragbar zu machen. Da sich Modellarchitekturen stabilisieren und Abstraktionen von PyTorch 2.0, OpenAI Triton und MLOps-Unternehmen wie MosaicML zum Standard werden, beginnen die Architektur und die Wirtschaftlichkeit von Chiplösungen die größten Kauftreiber zu sein, und nicht die Benutzerfreundlichkeit, die Nvidias fortschrittliche Software bietet .
Vor einigen Monaten wurde die PyTorch Foundation gegründet und von Meta getrennt. Zusätzlich zu Änderungen am offenen Entwicklungs- und Governance-Modell wurde Version 2.0 in der frühen Betaversion veröffentlicht und war im März allgemein verfügbar. PyTorch 2.0 bringt viele Änderungen mit sich, der Hauptunterschied besteht jedoch darin, dass es eine Kompilierungslösung hinzufügt, die ein grafisches Ausführungsmodell unterstützt. Diese Verschiebung wird es einfacher machen, verschiedene Hardwareressourcen richtig zu nutzen.
PyTorch 2.0 verbessert die Trainingsleistung auf NVIDIA A100 um 86 % und die Inferenzleistung auf der CPU um 26 %. Dies reduziert die Rechenzeit und die Kosten, die zum Trainieren des Modells erforderlich sind, erheblich. Diese Vorteile erstrecken sich auch auf andere GPUs und Beschleuniger von AMD, Intel, Tenstorrent, Luminous Computing, Tesla, Google, Amazon, Microsoft, Marvell, Meta, Graphcore, Cerebras, SambaNova und mehr.
PyTorch 2.0 bietet mehr Raum für Leistungsverbesserungen auf derzeit nicht optimierter Hardware. Meta und andere Unternehmen leisten so große Beiträge zu PyTorch, weil sie bei ihren milliardenschweren GPU-Trainingsclustern eine höhere FLOPS-Auslastung mit weniger Aufwand erreichen wollen. Auf diese Weise haben sie auch einen Anreiz, ihre Software-Stacks besser auf andere Hardware portierbar zu machen, was für Konkurrenz im Bereich des maschinellen Lernens sorgt.
Mit Hilfe besserer APIs kann PyTorch 2.0 auch Datenparallelität, Sharding, Pipeline-Parallelität und Tensor-Parallelität unterstützen und so Fortschritte beim verteilten Training bringen. Darüber hinaus unterstützt es nativ dynamische Formen im gesamten Stapel, was neben vielen anderen Beispielen die Unterstützung unterschiedlicher Sequenzlängen für LLMs erleichtert. Nachfolgend finden Sie die erste große Compiler-Unterstützung für dynamische Formen vom Training bis zur Inferenz:
Geschrieben für PyTorch für jeden ASIC für maschinelles Lernen außer NVIDIA-GPUs. Ein leistungsstarkes Backend, das vollständig unterstützt Es ist keine leichte Aufgabe, alle mehr als 2000 Betreiber zu erreichen. PrimTorch reduziert die Anzahl der Operatoren auf etwa 250 ursprüngliche Operatoren und behält gleichzeitig die gleiche Benutzerfreundlichkeit für PyTorch-Endbenutzer bei. PrimTorch macht die Implementierung verschiedener Nicht-NVIDIA-Backends von PyTorch einfacher und zugänglicher. Anbieter individueller Hardware und Systeme können ihre Software-Stacks einfacher einführen.
Die Umstellung auf Diagrammmuster erfordert eine zuverlässige Diagrammdefinition. Meta und PyTorch versuchen seit etwa fünf Jahren, diesen Wandel herbeizuführen, aber jede Lösung, die sie entwickelten, wies erhebliche Mängel auf. Schließlich lösten sie das Problem mit TorchDynamo. TorchDynamo nimmt jedes PyTorch-Benutzerskript auf, einschließlich Skripten, die externe Bibliotheken von Drittanbietern aufrufen, und generiert FX-Diagramme.
Dynamo reduziert alle komplexen Operatoren in PrimTorch auf ~250 primitive Operatoren. Sobald der Graph erstellt ist, werden nicht verwendete Operatoren verworfen und der Graph bestimmt, welche Zwischenoperatoren gespeichert oder in den Speicher geschrieben werden müssen und welche zusammengeführt werden können. Dies reduziert den Overhead innerhalb des Modells erheblich und ist gleichzeitig „nahtlos“ für den Benutzer.
TorchDynamo funktioniert bereits auf über 99 % der 7000 getesteten PyTorch-Modelle, darunter Modelle von OpenAI, HuggingFace, Meta, NVIDIA, Stability.AI und mehr, ohne Änderungen am Originalcode. Die 7000 getesteten Modelle wurden zufällig aus den beliebtesten Projekten mit PyTorch auf GitHub ausgewählt.
Googles TensorFlow/Jax und andere Ausführungspipelines im Diagrammmodus erfordern häufig, dass Benutzer sicherstellen, dass ihre Modelle zur Compiler-Architektur passen, damit Diagramme erfasst werden können. Dynamo ändert dies, indem es die Erfassung teilweiser Diagramme, die Erfassung geschützter Diagramme und die sofortige erneute Erfassung ermöglicht.
Die partielle Diagrammerfassung ermöglicht es Modellen, nicht unterstützte/Nicht-Python-Konstrukte zu enthalten. Wenn für ein Modellteil kein Diagramm erstellt werden kann, wird eine Diagrammunterbrechung eingefügt und die nicht unterstützte Konstruktion wird im Eager-Modus zwischen Teildiagrammen durchgeführt.
Die geschützte Diagrammerfassung prüft, ob das erfasste Diagramm für die Ausführung gültig ist. „Schutz“ bezeichnet eine Änderung, die eine Neukompilierung erfordert. Dies ist wichtig, da die mehrfache Ausführung desselben Codes nicht zu einer mehrfachen Neukompilierung führt. Durch die spontane Neuerfassung kann das Diagramm erneut erfasst werden, wenn das erfasste Diagramm nicht für die Ausführung gültig ist.
Das Ziel von PyTorch ist es, ein einheitliches Frontend mit einer reibungslosen UX zu erstellen, das Dynamo für die Diagrammerstellung nutzt. Das Benutzererlebnis der Lösung ändert sich nicht, die Leistung kann jedoch deutlich verbessert werden. Capture-Graphen können auf großen Mengen an Rechenressourcen effizienter parallel ausgeführt werden.
Dynamo und AOT Autograd übergeben dann das optimierte FX-Diagramm an den nativen PyTorch-Compiler-Level TorchInductor. Hardware-Unternehmen können dieses Diagramm auch in ihre eigenen Backend-Compiler einspeisen.
TorchInductor ist ein Python-nativer Deep-Learning-Compiler, der schnellen Code für mehrere Beschleuniger und Backends generieren kann. Inductor nimmt FX-Diagramme mit etwa 250 Operatoren und reduziert sie auf etwa 50 Operatoren. Als nächstes tritt der Induktor in die Planungsphase ein, in der die Operatoren zusammengeführt werden und die Speicherplanung festgelegt wird.
Dann gibt der Induktor „Wrapper Codegen“ ein, der Code generiert, der auf einer CPU, GPU oder einem anderen KI-Beschleuniger ausgeführt wird. Der Wrapper Codegen ersetzt den Interpreter-Teil des Compiler-Stacks und kann den Kernel aufrufen und Speicher zuweisen. Der Backend-Codegenerierungsteil nutzt OpenAI Triton für GPUs und gibt PTX-Code aus. Für CPUs generiert der Intel-Compiler C++ (funktioniert auch auf Nicht-Intel-CPUs).
Sie werden in Zukunft mehr Hardware unterstützen, aber der Punkt ist, dass Inductor den Arbeitsaufwand, den Compiler-Teams bei der Erstellung von Compilern für ihre KI-Hardwarebeschleuniger leisten müssen, erheblich reduziert. Darüber hinaus ist der Code leistungsoptimierter und die Anforderungen an Speicherbandbreite und -kapazität werden deutlich reduziert.
Was Forscher brauchen, ist nicht nur ein Compiler, der nur GPUs unterstützt, sondern ein Compiler, der verschiedene Hardware-Backends unterstützt.
OpenAI Triton ist eine bahnbrechende Präsenz für NVIDIAs Closed-Source-Software für maschinelles Lernen. Triton übernimmt Daten direkt von Python oder über den PyTorch-Inductor-Stack, wobei letzterer am häufigsten verwendet wird. Triton ist für die Konvertierung der Eingabe in eine LLVM-Zwischendarstellung und die Generierung von Code verantwortlich. NVIDIA-GPUs generieren PTX-Code direkt, überspringen die Closed-Source-CUDA-Bibliotheken von NVIDIA (wie cuBLAS) und verwenden stattdessen Open-Source-Bibliotheken (wie Cutlass).
CUDA ist in der Welt des beschleunigten Rechnens beliebt, aber unter Forschern des maschinellen Lernens und Datenwissenschaftlern wenig bekannt. Die Verwendung von CUDA kann Herausforderungen mit sich bringen und ein tiefes Verständnis der Hardwarearchitektur erfordern, was den Entwicklungsprozess verlangsamen kann. Daher können sich Experten für maschinelles Lernen auf CUDA-Experten verlassen, um ihren Code zu ändern, zu optimieren und zu parallelisieren.
Triton gleicht diesen Mangel aus und ermöglicht es Hochsprachen, eine vergleichbare Leistung wie Niedersprachen zu erzielen. Der Triton-Kernel selbst ist für den typischen ML-Forscher sehr klar, was für die Benutzerfreundlichkeit sehr wichtig ist. Triton automatisiert die Speicherzusammenführung, die gemeinsame Speicherverwaltung und die Planung in SM. Triton ist für die elementweise Matrixmultiplikation nicht besonders nützlich, aber die Matrixmultiplikation kann bereits sehr effizient durchgeführt werden. Triton eignet sich für teure Punkt-für-Punkt-Operationen und reduziert den Overhead komplexer Operationen.
OpenAI Triton unterstützt derzeit offiziell nur NVIDIA-GPUs, dies wird sich jedoch in naher Zukunft ändern, um mehrere andere Hardwareanbieter zu unterstützen. Andere Hardwarebeschleuniger können direkt in Tritons LLVM IR integriert werden, was die Zeit zum Aufbau eines KI-Compiler-Stacks für neue Hardware erheblich verkürzt.
Dem riesigen Softwaresystem von Nvidia mangelt es an Weitsicht und es ist nicht in der Lage, seine enormen Vorteile bei ML-Hardware und -Software zu nutzen, und wird daher nicht zum Standard-Compiler für maschinelles Lernen. Ihnen fehlt der Fokus auf Benutzerfreundlichkeit, der es OpenAI und Meta ermöglicht, Software-Stacks zu erstellen, die auf andere Hardware portierbar sind.
Originallink: https://www.semianalysis.com/p/nvidiaopenaitritonpytorch
Das obige ist der detaillierte Inhalt vonWird wie bei TensorFlow das CUDA-Monopol von NVIDIA gebrochen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
