Amazon möchte den Eindruck erwecken, dass das Schwierigste am Abschied von Nvidia eine einzige Konfigurationszeile ist. Das könnte sogar stimmen, und genau das macht die Ankündigung interessant. AWS hat TorchNeuron veröffentlicht, ein PyTorch-Plugin, das seinen Trainium-Chip zu einem gewöhnlichen PyTorch-Gerät macht. Hugging Face erklärt, dass seine wichtigsten Bibliotheken nun direkt darauf laufen. Das Versprechen lautet: einfache Migration. Die Botschaft zwischen den Zeilen: Nvidias eigentlicher Schutzwall war nie das Silizium, sondern die Gewohnheiten beim Softwareeinsatz.
Was TorchNeuron tatsächlich ist
TorchNeuron ist ein PyTorch-Plugin, das ein neues Backend für Trainium hinzufügt. Es unterstützt den Eager-Modus, torch.compile und die nativen APIs von PyTorch für verteilte Verarbeitung, einschließlich FSDP und Tensorparallelität. Neuron erscheint als Gerät, ganz so, wie es bei einer GPU der Fall wäre.
Das Tool geht am 20. Oktober 2026 in die öffentliche Beta. Forschende und Entwickler können es mit pip install torch-neuronx installieren.
Amazons Behauptung, wie sie in der Presseberichterstattung wiedergegeben wird, lautet: PyTorch-Anwendungen können auf Trainium laufen, indem man eine einzige Konfigurationszeile ändert, ohne den Code neu zu schreiben. Die Beispiele von Hugging Face sind bei den Details offener, und darauf kommen wir noch zurück. Die Behauptung mit der einen Zeile gibt eine gute Schlagzeile ab. Die eigentliche Arbeit steckt in den Fußnoten.
Warum Nvidia im Visier steht
PyTorch ist ein kostenloses Open-Source-Toolkit zum Entwickeln, Trainieren und Ausführen von KI-Modellen. Facebook hat es entwickelt, und seit 2022 ist es unter dem Dach der Linux Foundation angesiedelt. Amazon zufolge werden rund 85 % der KI-Anwendungen damit geschrieben.
Nvidia hat jahrelang dafür gesorgt, dass PyTorch mit seiner CUDA-Software gut läuft. Das Ergebnis ist, dass Nvidia-Hardware die Standardeinstellung ist – eine ausgesprochen angenehme Position für einen Hardwareanbieter. Niemand entscheidet sich für eine Standardeinstellung. Man ändert sie einfach nie.
Amazon ist nicht das erste Unternehmen, das versucht, Nvidia aus dieser Position zu verdrängen. PyTorch-Nutzer können Anwendungen bereits mit einer Konfigurationsänderung auf AMD-GPUs oder Chips von Apple umstellen. Neu ist hier also nicht die Idee. Neu ist, wer sie umsetzt und was damit verbunden wird.
Das Versprechen: Es geht nicht nur um einen Chip
Amazon argumentiert, dass die Portierung auf Trainium KI-Start-ups Zugang zur gesamten AWS-Cloud verschafft, nicht nur zu einem günstigeren Beschleuniger. Dabei teilt das Unternehmen auch gegen Neocloud-Anbieter aus, von denen viele an Nvidia-Hardware gebunden sind. Als Beispiele wurden Coreweave, Nebius und Firmus genannt.
Colin Brace, Vice President für Technologie-Software bei AWS Annapurna Labs (der Sparte, die Amazons eigene Chips entwickelt), formulierte es so: „Sie entwickeln auf AWS. Sie setzen nicht auf einen reinen Compute-Anbieter, um dann hektisch alles andere darum herum aufbauen zu müssen.“ Die Infrastruktur für den Weg vom Prototyp zum Produktivbetrieb sei bereits vorhanden, fügte er hinzu.
Das wirtschaftliche Argument besteht aus zwei Teilen:
- Ein Chip, zwei Aufgaben. Trainium übernimmt sowohl das Training (dem Modell etwas beibringen) als auch die Inferenz (das fertige Modell einsetzen, etwa wenn es die Frage eines Nutzers beantwortet). Laut AWS verbessert eine gemeinsame Plattform die Wirtschaftlichkeit über den gesamten Workload hinweg.
- Preis-Leistungs-Verhältnis statt Listenpreis. AWS räumt ein, möglicherweise nicht den niedrigsten Preis pro Token anzubieten. Das Argument lautet, dass die Integration in die umgebende Cloud die Gesamtrechnung trotzdem senkt.
Als Beleg dient Deepgram, ein Anbieter von KI-Sprachtechnologie und Konkurrent von ElevenLabs. Brace zufolge ist Deepgram mit nativem PyTorch auf Trainium umgestiegen und verarbeitet nun pro Dollar 70 % mehr Audiomaterial bei einer für den Produktivbetrieb geeigneten Genauigkeit. Das ist ein einzelnes Kundenbeispiel aus dem Mund des Anbietersprechers selbst – also ein Datenpunkt, kein Benchmark.
Die Upstream-Strategie
Der ehrgeizigere Teil hat mit Trainium überhaupt nichts zu tun. Amazon erklärt, Änderungen zum Hauptprojekt von PyTorch beizusteuern und mit der Community daran zu arbeiten, Code zu entfernen, der das Framework an bestimmte Chips bindet. In Amazons Worten geht es darum, PyTorch für die gesamte Entwickler-Community hardwareunabhängiger zu machen, nicht nur für Trainium-Nutzer.
Das sind gute Nachrichten für alle, die Hardware oder Cloud-Dienste in Konkurrenz zu Nvidia verkaufen. Zugleich passt es nicht ganz reibungslos zu dem, wofür PyTorch da ist. Ein großer Teil des Werts des Frameworks besteht darin, die unangenehmen Details zu verbergen, die nötig sind, um KI-Code auf Hardware zum Laufen zu bringen. Ob die Entkopplung von Nvidia wie von Amazon versprochen mehr Auswahl und günstigere Optionen bringt oder nur mehr Kopfzerbrechen bei der Konfiguration, bleibt abzuwarten.
Brace fasst es selbst so zusammen: „Im Kern geht es darum, den Lock-in zu beseitigen, der Entwicklern überhaupt keine echte Wahl ließ.“ Wenn diese Änderungen ins Hauptprojekt einfließen, ist das für Nvidia ein größeres Problem als jeder einzelne konkurrierende Chip.
Was sich für Hugging Face-Nutzer ändert
Bislang lief Hugging Face auf Trainium und Inferentia über eine Bibliothek namens optimum-neuron. Sie nutzte das Paket torch-neuronx, das auf PyTorch XLA basierte. Das war damals eine vernünftige Entscheidung, bedeutete aber, wie ein Compiler denken zu müssen. Man bekam Lazy-Tensoren statt Eager-Ausführung, ausschließlich statische Shapes und bei jedem Graph-Break eine Neukompilierung. Optimum Neuron verbarg diese Komplexität und pflegte dafür eigenen Spezialcode, darunter Modellklassen und Trainer.
TorchNeuron macht diese Schicht überflüssig. Neuron wird zu einem nativen Gerät mit Eager-Ausführung, DTensor, FSDP2 und torch.compile. Laut Hugging Face laufen Transformers, Diffusers, Accelerate, PEFT und TRL nun darauf – mit denselben Klassen und Skripten, die man auf jedem anderen Beschleuniger verwenden würde. Die Empfehlung für Neuron-Nutzer lautet, diese Bibliotheken direkt zu verwenden, statt den Umweg über Optimum Neuron zu nehmen.
Es hat eine schöne Ironie, wenn eine Bibliothek, deren Aufgabe es war, Komplexität zu verbergen, ausgemustert wird, weil diese Komplexität verschwunden ist.
Inferenz
Die Textgenerierung wird in Transformers nun für eine breite Palette von Modellen nativ unterstützt. Die zentrale Zahl: Mit TorchNeuron funktionieren 89 % der 100 meistgenutzten Modellarchitekturen zur Textgenerierung ohne Anpassungen, verglichen mit 46 % unter Optimum Neuron v0.4.5.
Um ein Modell auf Neuron-Geräte zu verschieben, übergibt man device_map=neuron. Das Beispiel von Hugging Face geht weiter und zeigt Textgenerierung mit Tensorparallelität, mit der sich laut Hugging Face eine Neuron-Instanz voll ausschöpfen lässt. Das Rezept besteht aus mehreren Bausteinen:
- Prozessgruppe. Die verteilte Prozessgruppe mit dem Backend
neuroninitialisieren. - Tensorparallelität. Eine
DistributedConfigmit einer TP-Größe entsprechend der Gesamtzahl der Prozesse sowie einDeviceMeshüber die Neuron-Geräte übergeben. - Statischer Cache. Für die Generierung einen statischen Cache verwenden, was Hugging Face auf Neuron dringend empfiehlt, um häufige Neukompilierungen zu vermeiden.
- Padding und Chunking. Den Prompt links so auffüllen, dass seine Länge ein Vielfaches der Prefill-Chunk-Größe ist (im Beispiel 512), und eine maximale Cache-Länge festlegen (1024).
- Kompilierungskonfiguration.
CompileConfigmit dem Backendneuron,fullgraph=Falseunddynamic=Falseverwenden.
Als Beispielmodell ist Qwen/Qwen3.8-27B angegeben, geladen in bfloat16.
Beachtenswert ist, was die Empfehlung zum statischen Cache impliziert. Die Vorlieben des Compilers sind nicht verschwunden, sie sind lediglich aus einer eigens dafür entwickelten Bibliothek in Konfigurations-Flags gewandert. Das ist ein Fortschritt, aber keine Zauberei.
Training
Beim Training lautet das Versprechen von Hugging Face, dass man keinen speziellen Trainer und keinen Neuron-spezifischen Fork des Modellcodes mehr braucht. Ein gewöhnliches TRL-Skript zum Fine-Tuning läuft mit einigen Neuron-spezifischen Einstellungen auf einer Trainium-Instanz.
Das Beispiel ist ein Skript für überwachtes Fine-Tuning auf Basis von SFTTrainer aus TRL. Die Parallelisierung wird nativ von Transformers übernommen. Man legt eine DistributedConfig mit den Größen für Tensorparallelität und FSDP in model_init_kwargs ab, SFTTrainer reicht sie an from_pretrained weiter, und das Modell wird beim Laden seiner Gewichte in Shards aufgeteilt. Der Trainer erkennt, dass das Modell bereits verteilt ist, und legt keinen weiteren Wrapper darum. Daher gibt es weder ein --fsdp-Flag noch eine Accelerate-Konfiguration für FSDP.
Der Start erfolgt mit torchrun und einem Prozess pro NeuronCore. Im Beispiel ergeben TP_SIZE=4 und FSDP_SIZE=8 32 Prozesse, angeordnet in einem 4-mal-8-Raster. Tensorparallelität teilt jede Schicht auf die 4 Kerne einer TP-Gruppe auf, und FSDP verteilt Parameter, Gradienten und Optimizer-Zustand in Shards auf die 8 TP-Gruppen.
In diesem Lauf wird Qwen/Qwen3-8B auf dem Datensatz HuggingFaceH4/ultrachat_200k (dem Split train_sft) in bfloat16 feinabgestimmt. Zu den Einstellungen gehören eine maximale Länge von 2048, Wrapped Packing, eine Lernrate von 2e-5, eine Epoche, eine Batch-Größe von 4 pro Gerät und 4 Schritte zur Gradientenakkumulation. Hugging Face führte den Lauf auf 8 Trainium2-Chips (32 NeuronCores) aus, was einer halben trn2.48xlarge-Instanz entspricht.
Der Lauf wird abgeschlossen, und trainer.save_model schreibt einen standardmäßigen Transformers-Checkpoint. Darin ist nichts an Neuron gebunden, sodass man ihn unverändert auf den Hub hochladen und auf anderer Hardware laden kann. Ausstiegsmöglichkeiten sind, wie sich zeigt, ein Feature.
Die Fußnoten
Das Skript selbst ist nicht an Trainium gebunden, aber Hugging Face nennt einige Dinge, die bei der Ausführung dort zu beachten sind:
| Thema | Vorgehen |
|---|---|
| Statische Shapes | Automatische dynamische Shapes in torch.compile deaktivieren und Wrapped Packing für Sequenzen mit bis zu 2048 Tokens verwenden. Mit TRL 1.16 oder neuer werden Batches auf Neuron auf ein Vielfaches von 128 Tokens aufgefüllt, wodurch die Zahl der Eingabe-Shapes begrenzt wird. Kompilierte Graphen werden in späteren Schritten mit denselben Shapes wiederverwendet. |
| Kompilierung | --torch_compile true übergeben. Auf einer Trainium-Instanz erkennt torch.compile das Gerät und wählt automatisch das Neuron-Backend. |
| Laden der Gewichte | Das integrierte asynchrone Laden von Gewichten in Transformers wird auf Neuron nicht unterstützt. Daher vorerst HF_DEACTIVATE_ASYNC_LOAD=1 setzen. |
Das Skript enthält außerdem einen Kommentar, dem zufolge das Neuron-Backend die automatischen dynamischen Shapes von Dynamo noch nicht kompilieren kann, und verweist auf ein offenes TRL-Issue. Die „eine Zeile“ hat also Gesellschaft bekommen.
Diffusers
Viele Diffusers-Pipelines sind sowohl im Eager-Modus als auch im kompilierten Modus mit TorchNeuron kompatibel. FLUX.1-dev, FLUX.2, Qwen-Image, Qwen-Image-2.1 und H3 funktionieren außerdem mit Tensorparallelität und können damit eine Neuron-Instanz besser ausnutzen.
Das Beispiel erzeugt mit Qwen-Image-2.1 in 40 Inferenzschritten ein Bild mit 1024 mal 1024 Pixeln, bei einem TP-Grad von 8. Einige Details:
- Der Textencoder bleibt auf der CPU, und die erzeugten Embeddings werden auf das Neuron-Gerät verschoben.
- Die sich wiederholenden Blöcke des Transformers werden mit dem Backend
neuron,fullgraph=Trueunddynamic=Falsekompiliert. - Der Generator wird auf der CPU mit einem Seed initialisiert, damit jeder Rank dasselbe Rauschen erhält.
- Der Lauf wird mit
NEURON_LOGICAL_NC_CONFIG=2 torchrun --nproc_per_node=8 run.pygestartet.
Hugging Face zufolge werden weitere Pipelines Unterstützung für Tensorparallelität erhalten. Das Unternehmen verweist auf eine Anleitung, wie man diese Unterstützung für eine gewünschte Pipeline ergänzt, falls sie noch fehlt.
Kernel
Hugging Face weist auch auf Kernel des Neuron-Teams hin, die fortlaufend auf dem Hub veröffentlicht werden, um Modelle zu beschleunigen. Sie lassen sich mit dem Neuron Kernel Interface (NKI) schreiben, das eine Steuerung der Operationen auf einer niedrigeren Abstraktionsebene ermöglicht. Nutzer können auch eigene, angepasste Operationen schreiben und auf dem Hub teilen.
Ein bereits veröffentlichter Kernel soll Vision-Transformer auf Trainium um bis zum Faktor 2,4 beschleunigen. Hugging Face dankte dem AWS-Team für seine Arbeit an TorchNeuron und dafür, während der Integration schnell auf Feedback reagiert zu haben.
Wo die Darstellungen voneinander abweichen
Zwei kleine Unstimmigkeiten verdienen Erwähnung.
- Zeitpunkt. Einer Darstellung zufolge hat AWS das Tool am Montag, dem 19. Oktober, veröffentlicht. Hugging Face sagt, TorchNeuron sei ab dem 20. Oktober als öffentliche Beta verfügbar. Am plausibelsten ist, dass an einem Tag die Ankündigung erfolgte und am nächsten die Beta startete. Die Quellen sagen das aber nicht ausdrücklich.
- Aufwand. Amazon beschreibt den Umstieg als Änderung einer einzigen Konfigurationszeile, ohne den Code neu schreiben zu müssen. Die Beispiele von Hugging Face selbst umfassen eine Prozessgruppe, ein Device-Mesh, Konfigurationen für die verteilte Ausführung, statische Caches, Shape-Einstellungen und eine Umgebungsvariable. Beides kann stimmen, wenn die eine Zeile der Ausgangspunkt ist und der Rest der Optimierung für den Betrieb in größerem Maßstab dient. Entwickler sollten bei allem, was verteilt läuft, aber mit mehr als einer Zeile rechnen.
Das Fazit, soweit eines möglich ist
Die Veröffentlichung hat drei Ebenen. Da ist das Plugin, das existiert und sich installieren lässt. Da ist die Integration mit Hugging Face, die konkret umgesetzt und dokumentiert ist und eine messbare Abdeckung bietet (89 % gegenüber 46 %). Und da ist die Upstream-Initiative, PyTorch weniger auf Nvidia zuzuschneiden – ein Versprechen.
Die ersten beiden machen es leichter, Trainium auszuprobieren. Die dritte könnte den entscheidenden Unterschied machen. Amazons Konkurrenten im Neocloud-Geschäft haben ein handfestes Interesse am gegenteiligen Ergebnis, und Nvidia hat einen großen Vorsprung dabei, als Standard zu gelten. Standardeinstellungen halten sich hartnäckig, weil niemand sie bemerkt, und Amazon fordert Entwickler nun auf, hinzusehen.
Wenn es funktioniert, ist das beste Ergebnis ein device_map-Argument, über das niemand nachdenkt. Wenn nicht, ist das zweitbeste Ergebnis eine sehr gut dokumentierte Liste von Umgebungsvariablen.