GitHub Actions auf Hugging Face Jobs: Flexible CPU- und GPU-Runner fĂĽr CI
đź’ˇ Quellen-Hinweis: Dieser Beitrag ist eine redaktionelle Zusammenfassung basierend auf einem Originalbericht von Hugging Face Blog.
Hugging Face zeigt am Beispiel des Trackio-Projekts, wie sich GitHub Actions weiterhin als Steuerzentrale nutzen lässt, während die eigentlichen CI-Läufe auf Hugging Face Jobs ausgeführt werden. Das Ziel: frei wählbare Container und Hardware, insbesondere GPU-Ressourcen, ohne einen dauerhaft betriebenen eigenen Runner. Im beschriebenen Test sank die Laufzeit eines CPU-Jobs von 1:40 auf 1:10 Minuten.
GitHub bleibt Orchestrator
Die BrĂĽcke bildet das Projekt huggingface/jobs-actions. Ein Pull Request erzeugt wie gewohnt einen Workflow. FĂĽr Labels wie hf-jobs-cpu-upgrade oder hf-jobs-t4-small wartet GitHub auf einen passenden Self-hosted Runner. Ein als Hugging Face Space betriebener Dispatcher prĂĽft den signierten Webhook, erzeugt ein kurzlebiges Registrierungstoken und startet einen HF Job auf der angeforderten Hardware. Der darin hochgefahrene Runner registriert sich einmalig, ĂĽbernimmt den Job und beendet sich anschlieĂźend.
FĂĽr GitHub sieht dieser Ablauf wie ein normaler selbst gehosteter Runner aus. Hugging Face wiederum fĂĽhrt lediglich einen Container mit dem Workflow aus. Das reduziert die notwendige Ă„nderung in bestehenden YAML-Dateien im Kern auf das runs-on-Label. Vorher mĂĽssen allerdings ein Dispatcher-Space und eine GitHub App eingerichtet sowie Token und Webhook-Geheimnis sicher als Secrets hinterlegt werden.
Containerwahl entscheidet ĂĽber die Geschwindigkeit
Ein generisches Ubuntu-Image erwies sich im Versuch als unnötig langsam, weil Browser, Node, ffmpeg und Build-Werkzeuge bei jedem Lauf nachinstalliert wurden. Mit einem passenden Playwright-Image war der CPU-Test rund 30 Prozent schneller als der GitHub-Durchschnitt. Ein GPU-Test auf einer kleinen T4-Instanz benötigte 45 Sekunden und kostete laut Beitrag weniger als einen Cent. Auch CUDA-Images, persistente Volumes und per CLI abrufbare Logs stehen zur Verfügung.
Einordnung fĂĽr ML-Projekte
Der Ansatz ist vor allem interessant, wenn Tests spezielle Beschleuniger, große Modelle oder maßgeschneiderte Images benötigen. Teams gewinnen flexible Hardware, übernehmen aber zusätzliche Verantwortung für Dispatcher, App-Berechtigungen, Secrets und Kostenkontrolle. Für klassische kleine CI-Pipelines bleibt GitHubs Standard bequem. Bei Machine-Learning-Repositories kann die Kombination hingegen eine pragmatische Alternative zu dauerhaft laufenden GPU-Runnern sein. Entscheidend sind reproduzierbare Images und ein Dispatcher, der nicht wegen Inaktivität schläft, damit Webhooks zuverlässig verarbeitet werden.
Originalquelle: Hugging Face Blog – Migrating Your GitHub CI to Hugging Face Jobs
