Die Arbeitsgruppe bündelt Beiträge aus der PyTorch-Community, um die Integration unterschiedlicher Hardware in das Framework zu vereinheitlichen. Für H1 2026 nennt sie unter anderem überarbeitete Testsuiten, Profiling-Unterstützung für Backends auf Basis von PrivateUse1, Fortschritte bei OpenReg als Referenz-Backend sowie Arbeiten an verteilten Funktionen und Compiler-Backends. Auch die CI-Infrastruktur und die Sichtbarkeit ihrer Ergebnisse wurden weiterentwickelt.
Eine zentrale Neuerung ist Cross-Repository CI Relay (CRCR). Wird in pytorch/pytorch ein Pull Request eröffnet oder ein Commit eingespielt, löst ein Webhook parallel Prüfungen in registrierten Downstream-Repositories aus. Diese führen ihre eigenen CI-Workflows aus und übermitteln den Status über einen authentifizierten Rückkanal. Dafür kommt ein GitHub-OIDC-Token zum Einsatz, das die Identität des aufrufenden Repositorys bestätigt. Die Ergebnisse erscheinen im PyTorch CI HUD unter hud.pytorch.org/crcr.
CRCR sieht vier Teilnahme-Stufen von L1 bis L4 vor. Projekte können zunächst Benachrichtigungen erhalten und später Ergebnisse im Dashboard melden; höhere Stufen ermöglichen nicht blockierende und schließlich blockierende Prüfungen für PyTorch-Pull-Requests. PyTorch beschreibt außerdem fünf Schutzmechanismen: Identitätsprüfung per OIDC, eine Zulassungsliste, Begrenzung der Anfragerate, Zustandsprüfungen und eine Trennung zwischen vertrauenswürdigen und selbst gemeldeten Daten. Selbst ein kompromittiertes Downstream-Projekt soll dadurch nur seinen eigenen angezeigten CI-Status beeinflussen können, nicht die PyTorch-Build-Infrastruktur oder Merge-Entscheidungen.
Für die Backend-Validierung verweist die Arbeitsgruppe auf PyTorchs Testsuite mit mehr als 600.000 Testfällen zu Operatoren, Autograd, Profiling und verteiltem Training. Viele Tests seien bisher auf bestimmte Beschleuniger zugeschnitten gewesen; die Gruppe arbeitet laut ihrem Beitrag daran, Tests breiter über Backends hinweg wiederverwendbar zu machen. Zum CRCR-Onboarding sind ein Eintrag in der Zulassungsliste und eine schlanke Workflow-Datei nötig. Als weitere Arbeitsfelder nennt die Gruppe gemeinsame Testabläufe und den Ausbau von OpenReg als Referenz-Backend.