核心概念

GitHub Actions 是目前最普及的 CI/CD 平台，但它的 hosted runner 有三個結構性限制：執行速度偏慢、機器規格固定（通用 Ubuntu 映像，缺乏特定工具），以及幾乎無法為開源專案取得 GPU 資源。對於需要跑 GPU 測試、大型矩陣測試或高頻率整合測試的 ML 專案，這三個限制往往直接拖慢開發迭代速度。

Hugging Face 提出的解法是「保留 GitHub Actions 作為調度器，但把真正的計算工作移到 HF Jobs 執行」。這套架構稱為 Hugging Face Jobs，其核心概念是：

  • 無伺服器計算：按需啟動 Job，用完即銷毀，不需要維護自建伺服器
  • 硬體可配置：從 cpu-basic 到 h200 GPU 均可選，一行設定即可切換
  • GitHub Actions 相容：對 GitHub 而言，HF Jobs 啟動的容器就是一般的 ephemeral self-hosted runner，不需要修改既有 workflow 邏輯

整套橋接機制由 huggingface/jobs-actions 提供。使用者只需要將 runs-on: ubuntu-latest 改為 runs-on: hf-jobs-cpu-upgrade（或 hf-jobs-t4-small 等 GPU 規格），其餘 workflow 定義完全不變。

運作流程

PR 觸發 → GitHub 將 job 排入佇列（runs-on 標籤無可用 runner）
    ↓
GitHub App 送出 workflow_job.queued webhook
    ↓
Dispatcher Space 驗證簽名 → 辨識 hf-jobs-* 標籤
    ↓
Dispatcher 向 GitHub 申請短效 runner registration token
    ↓
HF Jobs 啟動 ephemeral 容器（含 GitHub Actions runner）
    ↓
runner 向 GitHub 登記 → GitHub 將 job 指派給此 runner
    ↓
執行完成 → runner 自動登出 → 容器銷毀

對 GitHub 而言，全程只看到一個正常運作的 self-hosted runner；對 HF 而言，就是一個有生命週期的 Job。

關鍵要點

  • 設定五步完成：

    1. 複製 huggingface/jobs-actions-dispatcher Space 到自己的 HF 帳號
    2. 在 Dispatcher Space 介面建立 GitHub App，安裝到目標 repo
    3. 提供有 Jobs 權限的 HF token（費用計算帳戶）
    4. 將 workflow 的 runs-on 改為 hf-jobs-{規格} 標籤
    5. 推送一個測試 workflow 驗證端對端流程

  • Docker 映像選擇影響效能：裸 ubuntu:22.04 缺乏常用開發工具，初次安裝耗時超過抵銷效能優勢。應直接選用包含所需工具的映像，例如：

    • CPU 測試需 Playwright/Node/ffmpeg：mcr.microsoft.com/playwright:v1.60.0-jammy
    • GPU 測試：nvidia/cuda:12.4.0-runtime-ubuntu22.04

  • 實測效能（以 Trackio 專案為例）：

    環境 執行時間 說明
    GitHub ubuntu-latest 1m40s 基準
    HF Jobs CPU（Playwright 映像） 1m10s 快約 30%
    HF Jobs GPU t4-small 45s 開源專案首次可跑 GPU 測試

  • GPU 測試成本極低：t4-small 跑一次 45 秒的完整 GPU test suite，成本不到一美分

  • 調試工具完整：

    hf jobs ps --namespace YOUR_NAMESPACE        # 查看運行中的 jobs
hf jobs logs <job_id> > logs.txt            # 抓取日誌
hf spaces logs YOUR_NAMESPACE/jobs-actions-dispatcher  # 查看 dispatcher 日誌

  • 進階功能：HF Jobs 支援 volume mounting，可直接掛載 HF Hub 上的資料集或模型，避免每次 CI 重複下載

實務應用

這套遷移方案最適合以下場景：

開源 ML 專案：GitHub 對開源專案不提供免費 GPU runner，HF Jobs 彌補了這個缺口，且成本可控（按秒計費）。

現有 CI 改造：因為架構上只是換掉 runner 的執行環境，既有的 workflow 邏輯、secrets、matrix build、artifact 上傳全部保持不變，遷移風險極低。

混合策略：不必全量遷移。可以只把需要 GPU 的 job 或執行時間最長的 job 移到 HF Jobs，其餘繼續用 GitHub hosted runner。runs-on 是 job 層級的設定，可以在同一個 workflow 中混用。

自動化部署管線：由於 HF Jobs 可以執行任意 Docker 映像，也可以用來跑部署腳本、模型評估、資料處理等非純測試任務，不限於 CI 場景。

相關頁面：HF CLI：為 AI 代理最佳化的 Hugging Face 命令列工具 · Hugging Face 推論供應商生態系：DeepInfra 整合實錄 · Hugging Face Spaces agents.md：AI Agent 組合多媒體服務的新標準

延伸觀點

開源 GPU 測試缺口是業界共識。GitHub 官方部落格與社群研究均確認：GitHub hosted runners 從設計上就不為開源專案提供 GPU 資源。這個缺口長期以來只能靠兩種方式填補——維護自己的 self-hosted runner 機器，或完全跳過 GPU 測試。前者帶來不可忽視的維護成本，後者讓 ML 專案的 CI 品質打折扣。HF Jobs 是第一個以低廉成本（按秒計費，T4 跑一次不到一美分）且對開源友善的解法。

自建 self-hosted runner 的代價常被低估。GitHub 官方文件明確指出，在 GitHub Actions 使用 self-hosted runner 需要自行承擔三個層面的複雜度：安全（網路隔離、映像管理、secrets 處理）、可靠性（高可用 on-demand 擴縮本身就是難題）、除錯（GitHub 技術支援只涵蓋 Actions 服務本身，不協助排查自建基礎設施）。對大多數沒有專職基礎設施團隊的開源專案而言，這些成本往往超過省下的費用。

混合 runner 策略是務實選擇。業界觀察一致指向同一個方向：把 CPU 密集測試保留在 GitHub 免費 runner（或較便宜的 hosted runner），只把真正需要 GPU 或執行時間最長的 job 路由到專門的計算資源。HF Jobs 的 runs-on 標籤機制恰好支援這個策略——不需要做全量遷移，可以 job 為單位漸進切換，降低風險也控制成本。

這三個觀點相互呼應：開源 GPU 測試缺口讓 HF Jobs 的出現時機恰當，self-hosted 的高複雜度讓「無伺服器 CI」成為更好的替代方案，而混合策略則讓遷移門檻降至可接受範圍。

來源：GitHub Blog（When to choose GitHub-Hosted vs. Self-Hosted runners） · devActivity（Testing GPU code on GitHub Actions）

反向連結

以下頁面引用了本頁：