AMD ROCm 10.1: Datenpfade und GPU-Monitoring ändern sich
AMD hat ROCm 10.1 am 5. Oktober veröffentlicht. Das Release verbessert GPU-Datenpfade, ersetzt rocm-smi durch AMD SMI und wechselt auf LLVM 24. Für lokale KI-Dienste steht eine geplante Migration statt eines Sofortupgrades an.
Für Betreiber lokaler KI-Dienste auf AMD-GPUs bringt ROCm 10.1 vor allem zwei Prüfaufgaben: Monitoring mit rocm-smi auf AMD SMI umstellen und eigene Builds auf LLVM 24 vorbereiten. AMD hat die Version am 5. Oktober 2026 vorgestellt. Für funktionierende Produktionssysteme ist ein geplantes Wartungsfenster sinnvoll, kein ungeprüftes Sofortupgrade.
Relevant sind AMD-Umgebungen mit HIP, PyTorch, vLLM oder eigenen GPU-Anwendungen. Reine CPU-Dienste und ausschließlich mit CUDA betriebene NVIDIA-Systeme benötigen wegen dieser Veröffentlichung keine ROCm-Migration. Ob eine konkrete Radeon-, Ryzen- oder Instinct-Konfiguration unterstützt wird, entscheidet weiterhin die jeweilige Kompatibilitätsmatrix, nicht allein die Versionsnummer.
Daten schneller zur GPU bringen
AMD richtet das Release auf einen Engpass großer Modelle aus: Gewichte, Checkpoints und der KV-Cache müssen rechtzeitig beim Beschleuniger ankommen. Mehr Rechenleistung hilft wenig, wenn Speicherzugriffe die GPU ausbremsen. Die Speicherbibliothek hipFILE erhält einen asynchronen Fast Path, bei dem Lese- und Schreibaufträge auf einem HIP-Stream laufen und den Zwischenschritt über Host-Speicher überspringen.
Eine neue Batch-I/O-API bündelt mehrere Dateianfragen und verteilt sie über interne Arbeitsthreads. Zusätzliche I/O-Statistiken sollen sichtbar machen, ob Rechenleistung, Speicher oder Datenzufuhr begrenzen. Das sind laut AMD Verbesserungen für Checkpoint-Verarbeitung und datenintensive Inferenz. Eine pauschale Beschleunigung sämtlicher lokaler Sprachmodelle lässt sich daraus nicht ableiten; eigene Messwerte liegen für diese Meldung nicht vor.
HIP berücksichtigt die NUMA-Topologie
HIP erweitert die virtuelle Speicherverwaltung um Host-Speicherzuweisungen auf einem bestimmten CPU-NUMA-Knoten. Anwendungen können Speicher damit näher an den verwendeten Rechenressourcen platzieren. Auf Mehrsockelsystemen kann das unnötigen Verkehr zwischen Prozessoren vermeiden. AMD nennt Kommunikationsbibliotheken wie RCCL als mögliche Nutzer für lokale Zero-Copy-Datenpfade.
- Server mit mehreren CPU-Sockeln sollten Speicherplatzierung und GPU-Zuordnung gemeinsam bewerten.
- Für Checkpoint- und Cache-Auslagerung sind Datenträgerdurchsatz und Datenpfad ebenso relevant wie GPU-Auslastung.
- Neue APIs verbessern bestehende Anwendungen nicht automatisch; die Software muss entsprechende Möglichkeiten tatsächlich nutzen.
Monitoring wechselt zu AMD SMI
Nach Ende der Abkündigungsphase übernimmt amd-smi die Nachfolge von rocm-smi. AMD beschreibt eine CLI mit Unterbefehlen, eine native C-Bibliothek sowie Anbindungen für Python, Rust und Go. Für Admins ist das eine Schnittstellenänderung: Skripte, die bisherige Befehle aufrufen oder deren Textausgabe auswerten, brauchen eine gezielte Überprüfung.
AMD SMI erweitert zudem die Zuordnung von GPU-Prozessen zu Containern, unter anderem für containerd, CRI-O, Podman, LXC und LXD sowie Kubernetes-Pods. Vollständige Container-IDs erleichtern die Verbindung zwischen GPU-Telemetrie und dem tatsächlich laufenden Dienst. Bestehende Dashboards sollten dennoch gegen ihre bisherigen Messgrößen geprüft werden, bevor alte Abfragen entfallen.
LLVM 24 verlangt einen Blick auf den Build
Der Compiler amdclang++ wechselt von LLVM 23 auf LLVM 24. AMD weist ausdrücklich auf Code und Buildskripte mit Annahmen über die Compiler-Hauptversion sowie Werkzeuge mit direkter libLLVM-Anbindung hin. Der Versionsmakro clang_major meldet jetzt 24. Zwischengespeicherte Partitionen bei Link-Time Optimization sollen außerdem inkrementelle HIP-Builds verkürzen.
- Installierte ROCm-Version, GPU-Modell, Betriebssystem und Treiberstand zuerst inventarisieren.
- Aufrufe von
rocm-smiin Überwachung, Alarmierung und Automatisierung erfassen. - Compilerprüfungen und direkte LLVM-Abhängigkeiten in CI-Images kontrollieren.
- Repräsentative Modelle und eigene HIP-Anwendungen vor einer Migration separat validieren.
- Den bisherigen Softwarestand für einen kontrollierten Rückweg dokumentieren.
Preview und Beta bleiben getrennte Entscheidungen
Die WSL2-Unterstützung hat in ROCm 10.1 den Status Tech Preview. Linux-Pakete werden im Gast installiert, während die GPU über den Windows-Hosttreiber angesprochen wird. Das ist keine allgemeine Produktionsfreigabe für beliebige Windows-Rechner. Auch Kernel Replay im ROCprofiler-SDK bleibt Beta: Kernel-Ausführungen werden wiederholt, um zusätzliche Leistungszähler innerhalb eines Anwendungslaufs zu erfassen.
Für Unternehmen liegt der kurzfristige Nutzen deshalb weniger in einem Versionsrennen als in einer kontrollierten Migration. Datenpfade können sich verbessern, zugleich ändern sich Compiler und Betriebswerkzeuge. Gesichert sind die angekündigten Funktionen und ihre Statusangaben. Der konkrete Leistungsgewinn, die Eignung vorhandener Anwendungen und die Unterstützung einzelner Hardwarekombinationen müssen je Umgebung überprüft werden.
Passende Anleitungen auf S-EDV
- GPU für lokale KI auswählen: Hintergrund zu VRAM und Hardwareplanung, unabhängig von einer ROCm-Freigabe.
- GPU-Passthrough mit Proxmox: Ergänzende Grundlagen für die Zuordnung von Beschleunigern zu virtuellen Maschinen.
