Ubuntu-Kernel bremst AMD-GPU-Compute massiv aus: Stand, Ursache, Fix – und was Teams jetzt tun sollten

Warum das Thema jetzt wichtig ist

Das Ubuntu Kernel Team warnt vor einer Performance‑Regression für AMD‑GPUs im kommenden Kernel 7.0.0‑28.28. Betroffen sind insbesondere compute‑lastige ROCm‑Workloads (z. B. KI‑Inference); Ubuntu nennt in seinem Post Beispiele wie Stable Diffusion XL via ComfyUI und berichtet von stark verlängerten Laufzeiten. Für Dev‑ und Data‑Teams, die produktionsnah mit AMD‑GPUs arbeiten, kann das Update daher ein operatives Risiko bedeuten. Dieser Artikel fasst den Stand, die technische Einordnung und konkrete Schritte für Tests, Canary‑Rollouts und sichere Rückrolls zusammen.

Kurzstatus (Stand: 20.07.2026)

Betroffene Kernel‑Version: Ubuntu kündigt eine Regression im amdgpu‑Pfad für den kommenden Kernel 7.0.0‑28.28 an. Quelle: offizieller Hinweis des Ubuntu Kernel Teams (Ubuntu Discourse).
Betroffene Workloads: Vor allem compute‑lastige ROCm‑Jobs; Ubuntu nennt SDXL/ComfyUI als konkretes Beispiel. Die Meldung bezieht sich auf Durchsatz‑Einbußen, nicht auf System‑Freezes.
Auswirkung: Berichte über stark verlängerte Laufzeiten (Ubuntu nennt „bis zu 42×“ in seinem Thread). Unabhängige Berichterstattung (z. B. Phoronix) bietet zusätzliche technische Kontext‑Hypothesen und Hinweise auf einen Upstream‑Fix; diese Analyse ist jedoch als Drittbericht zu lesen (Phoronix).

Hinweis: Ubuntu bestätigt die Regression und empfiehlt betroffenen Nutzern, vorerst beim aktuellen Kernel zu bleiben; detaillierte Upstream‑Commit‑IDs oder eine explizite Upstream‑Release‑Nummer werden im Discourse‑Post nicht genannt.

Wer ist besonders gefährdet?

Betreiber von ROCm‑basierten Compute‑Stacks unter Ubuntu 26.04 oder 24.04 LTS mit HWE‑Kernel.
Workloads mit hohem Device‑/Host‑Speicher‑Traffic und intensivem Compute (Inference/Training, numerische Bibliotheken, HPC‑Jobs).
Klassische Desktop‑Gaming‑Lasten sind nicht der primäre Schwerpunkt der Warnung; Ubuntu adressiert explizit ROCm/Compute‑Pfade.

Für Details zur Kompatibilität von ROCm‑Stacks empfehlen sich AMDs Dokumentation und die Kompatibilitätsmatrix als Referenz für unterstützte Kernel‑ und OS‑Kombinationen (ROCm Install Guide, ROCm Compatibility Matrix).

Technische Einordnung: Ursache und Fix (Quellenlage)

Was Ubuntu bestätigt: die Existenz einer Performance‑Regression im amdgpu‑Kontext für den genannten Kernel‑Build und die empfohlene temporäre Zurückhaltung beim Upgrade (Ubuntu Discourse).
Externe Analyse: Fachberichterstattung (Phoronix) berichtet, dass die Regression von einem Problem im HMM (Heterogeneous Memory Management)-Pfad herrühren könnte und dass upstream ein Patch vorhanden sei; diese Darstellung ist als Drittberichterstattung zu verstehen und nicht als offizielle Bestätigung durch Ubuntu. Die von Drittreportern genannte Upstream‑Punkt‑Release‑Nummer wird im offiziellen Ubuntu‑Post nicht genannt; entsprechend sind präzise Upstream‑Versionsangaben in diesem Artikel entweder als Fremdbericht gekennzeichnet oder neutraler formuliert (Phoronix).
Verwandte Fixes: Separat existieren GPU‑spezifische Korrekturen (z. B. GFX1151 Context‑Save/Restore‑Sizing), die Ubuntu über seinen SRU/HWE‑Prozess zurückportet; Mailinglisteneinträge des Kernel‑Teams dokumentieren solche Abläufe (Ubuntu Kernel Team Mailinglist: GFX1151 fixes).

Kurzfazit zur Technik: Die Regression ist bestätigt. Für tiefergehende Aussagen zur genauen Root‑Cause‑Commit‑ID oder zu exakten Upstream‑Versionsnummern stützen wir uns auf Drittanalysen und kennzeichnen diese entsprechend; Ubuntu selbst empfiehlt bis zur Nachlieferung des Fixes, beim bestehenden Kernel zu bleiben.

Praxis für DevOps/Developer: Risikomanagement vor Kernel‑Updates

Eine sichere Update‑Praxis für GPU‑Compute umfasst reproduzierbare Benchmarks, Canary‑Rollouts und klar definierte Rückroll‑Prozesse.

Vor dem Update: Prüfaufbau und Reproduktions‑Checks

Referenz‑Benchmarks definieren: Kurze, reproduzierbare Jobs (z. B. ein festes SDXL‑Prompt‑Szenario, ein kleines ROCm‑Microbenchmark). Messgrößen: Zeit pro Inferenz, Images/min oder Samples/s, GPU‑Utilization, relevante Durchsatzmetriken.

Umgebung einfrieren:

Versionskontrolle für Images/Conda/Container; feste Model‑Weights und Seeds.
ROCm‑Stack dokumentieren (ROCm‑Version, amdgpu‑User‑Space, Kernel). AMDs Installationsdokumentation hilft bei der Zuordnung von unterstützten Kombinationen (ROCm Install Guide).

Kernel‑Pinning vorbereiten: Sorge tragen, dass ältere Kernel parallel installiert bleiben; prüfe uname -r vor dem Reboot und halte einen planbaren Rollback‑Weg bereit.

Teststrategie im Staging: Canary‑Rollouts, Benchmarks und Metriken

Canary‑Rollout‑Größe: Zuerst eine kleine, repräsentative Kohorte (z. B. 5–10 % der Nodes) mit dem neuen Kernel testen.

Metriken und Vergleich: Messt Benchmarks gegen eure Baseline. Nutzt identische Container/Seeds und sammelt System‑ und Workload‑Metriken.

Einheitliche Entscheidungsgrenzen (Konsistenzregel für alle Erwähnungen im Artikel):

≤5 % Abweichung gegenüber Baseline: OK für breiteren Rollout.
>5–20 % Abweichung: Investigation, Rollout pausieren; Logs und Traces sammeln.
>20 % Abweichung: Rollback auf vorherigen Kernel.

Beobachtbarkeit:

System: dmesg/journalctl, GPU‑Telemetry (amdsmi/rocm‑tools), PCIe/NUMA‑Metriken.
Workload: Per‑Batch‑Latenzen, End‑to‑End‑Durchlaufzeit, mögliche Retry‑Muster in Anwendung-Logs.

(Die oben genannten Schwellenwerte sind operationelle Richtwerte; Teams sollten sie an ihre SLAs und Toleranzen anpassen, die hier vorgeschlagene Skala ist jedoch durchgängig im Artikel konsistent verwendet.)

Entscheidungsregeln: Wann updaten, wann zurückhalten

Update freigeben, wenn Canary‑Metriken stabil bleiben (≤5 % Abweichung), Logs unauffällig sind und keine sicherheitskritischen Gründe für ein sofortiges Update gegen die Performance‑Risiken sprechen.
Update aufschieben, wenn Canary‑Tests Abweichungen im Bereich >5–20 % zeigen; in diesem Fall pausieren, Ursache untersuchen und bis zur Klärung beim vorherigen Kernel bleiben.
Sofortiges Zurückhalten (Rollback), wenn die Abweichung >20 % beträgt oder kritische Jobs intolerable Ausfälle zeigen.

Diese Entscheidungsregeln greifen direkt auf die zuvor genannten, konsistent gehaltenen Canary‑Schwellenwerte zurück.

Handhabung bei Performance‑Einbruch: schnelle Gegenmaßnahmen

Kurzfristige Mitigation (Rollback)

Beim Booten unter "Erweiterte Optionen für Ubuntu" den vorherigen Kernel wählen und prüfen, ob die Performance wiederhergestellt ist.
Überprüfen: uname -r (aktuell), dpkg -l | grep linux-image (installierte Kernel). Temporär betroffene Kernel‑Pakete mit einem Hold versehen, bis ein getesteter Fix verfügbar ist.
Wichtig: Paket‑Metapakete und HWE‑Bezeichnungen unterscheiden sich je Release; automatisierte Skripte für Hold/Unhold sollten im Runbook getestet sein.

Mittelfristig: Backports und SRU‑Pfad verstehen

Ubuntu nutzt SRU/Backport‑Prozesse, um Upstream‑Fixes in LTS/HWE‑Zweige zu übernehmen. Betreiber sollten die Ubuntu‑Discourse‑Ankündigungen und Kernel‑Mailinglisten beobachten, um zu erkennen, wann ein Fix in die eigene HWE‑Linie einfließt (Ubuntu Kernel Team Mailinglist).
Sobald ein gefixtes Ubuntu‑Kernel‑Paket verfügbar ist, erneut Canary‑Tests durchführen, bevor breit ausgerollt wird.

Was Teams konkret prüfen sollten (Konfigurationen und Messpunkte)

ROCm‑spezifische Prüfpunktliste

Stack‑Abgleich: Stimmen GPU‑Generation, ROCm‑Version und Kernel‑Stand mit der AMD‑Kompatibilitätsmatrix überein? (siehe ROCm Compatibility Matrix).
Treiber‑Pfad: Erkennen, ob Inbox‑Kernel‑Treiber oder separate amdgpu‑Pakete genutzt werden; Mischformen vermeiden.
Tools: rocminfo/amdsmi zur Verifikation, ROCm‑Validation‑Tools für schnelle Health‑Checks (ROCm Doku legt solche Prüfpfade nahe).

Benchmarks und Reproduktions‑Workflows (Beispiel SDXL/ComfyUI)

Smoke‑Test: Ein festes SDXL‑Prompt/Seed‑Set als kurzes E2E‑Szenario; Messgröße: Zeit pro Bild bzw. Bilder/Minute.
Microbenchmarks: Kurze GEMM‑/hipBLAS‑Runs zur Überprüfung reinen Compute‑Throughputs.
Warm‑ vs. Cold‑Runs vergleichen, um Caching‑Effekte zu isolieren; Logs auf ungewöhnliche HMM‑/Speichermuster prüfen.

Einordnung und Trade‑offs

Stabilität vs. Aktualität: Kernel‑Point‑Releases bringen oft Security‑Fixes. Ein Canary‑Ansatz ermöglicht, Sicherheitsupdates zu testen, ohne sofort die gesamte Flotte zu riskieren.
Eigene Backports vs. Abwarten: Backporting erhöht Wartungsaufwand und Testing‑Aufwand. Wenn möglich ist es oft praktikabler, das Ubuntu‑Fix‑Release abzuwarten und es dann gezielt zu testen.

Fazit: Handlungsempfehlung für deutsche Dev‑Teams

Kurzfristig: Flächendeckendes Update auf Ubuntu‑Kernel 7.0.0‑28.28 für ROCm‑Compute‑Nodes aussetzen; stattdessen Canary‑Tests mit klaren Schwellen (≤5 % OK, >5–20 % Investigation, >20 % Rollback).
Technisch: Ubuntu bestätigt die Regression und hat einen Fix‑Plan angekündigt; tiefergehende Root‑Cause‑Details und konkrete Upstream‑Release‑Nummern sind derzeit primär in Drittanalysen (z. B. Phoronix) zu finden und werden hier als solche gekennzeichnet.
Operativ: Baselines pflegen, Benchmarks automatisieren, Kernel‑Pins/Rollback‑Schritte im Runbook proben und ROCm‑Doku für Stack‑Kompatibilität zurate ziehen (ROCm Install Guide, ROCm Compatibility Matrix).

Mit klaren Canary‑Regeln, reproduzierbaren Benchmarks und einem getesteten Rollback‑Pfad lassen sich Security‑Updates zeitnah übernehmen, ohne GPU‑Compute‑SLAs unnötig zu gefährden.