Как перенести CI с GitHub Actions на Hugging Face Jobs: пошаговая инструкция с GPU и ускорением на 30%

GitHub Actions без GPU — это как готовить в микроволновке стейк

Вы знаете это чувство. Пушнули код, пошли за кофе, вернулись — а CI всё ещё висит. Не потому, что тесты сложные, а потому, что GitHub Actions не даёт GPU. До сих пор. 2026 год, а GPU в раннерах GitHub — только через сторонние сервисы за бешеные деньги. Или через self-hosted, где вы сами отвечаете за железо, драйверы, охлаждение и соседа по датацентру.

Особенно больно это бьёт по ML-командам. Вы тренируете модель, CI должен проверить инференс на GPU, прогнать бенчмарки, замерить память. А вместо этого — эмуляция на CPU, которая врёт по производительности в 10 раз, или ожидание в очереди на shared runner. И это при том, что Hugging Face Jobs уже больше года дают бесплатный GPU для CI.

В этом гайде я покажу, как перенести CI-пайплайн с GitHub Actions на Hugging Face Jobs, используя hf jobs. Результат — ускорение CI на 30% (а в некоторых сценариях и на 200%) за счёт нативного GPU, нулевого времени холодного старта (если вы не дурак) и отсутствия оверхеда на виртуализацию. Спойлер: будет больно, но оно того стоит.

Три причины, почему ваш CI просит GPU (и вы закрываете на это глаза)

Давайте честно: большинство CI-пайплайнов для ML — это профанация. Вы запускаете тесты на CPU, которые ничего не тестируют. Потому что:

1. Инференс моделей без GPU — это симуляция. Упал OOM на продакшене после деплоя? Привет, ваш CI на CPU спокойно прогнал модель с batch_size=1. Вы не узнаете о проблеме, пока пользователь не пожалуется.
2. Бенчмарки на CPU — туфта. Если вы меряете latency инференса на GitHub Actions runner'е, то получите цифры, которые в 50 раз хуже продакшена. И начинается пляска с бубном: «а почему у нас в CI медленно, а в продакшене быстро?».
3. Дорогие раннеры с GPU от GitHub — иллюзия. GitHub предлагает GPU-раннеры только через партнёров (например, ubuntu-latest-4x-gpu стоит $0.90/мин). За час CI вы заплатите $54. За месяц — стоимость нормального GPU-сервера. Бессмысленно.

Hugging Face Jobs решает все три проблемы, и — внимание — бесплатно до определённого лимита (на момент 09.06.2026 — 10 часов GPU-времени в месяц на аккаунт, что для CI большинства команд — выше крыши).

Hugging Face Jobs: консоль, которая не врет

Если вы думаете, что Hugging Face Jobs — это просто «запустить ноутбук на GPU», то вы правы только отчасти. Это полноценный CI-движок, который умеет:

• Запускать произвольные Docker-образы с GPU (NVIDIA A10G, L4, A100 — в зависимости от региона)
• Хранить артефакты и кэш между запусками (до 50 ГБ на job)
• Подключаться к GitHub через webhooks или CLI-триггеры
• Отдавать метрики (log_metrics) прямо в консоль и в ваш трекер экспериментов
• Завершаться по таймауту и лимитам ресурсов — никаких «забыл и оставил на неделю»

И всё это через одну утилиту — huggingface_hub версии 0.30.0+ (на 09.06.2026 актуальна 0.32.1).

Кстати, о GitHub Agentic Workflows: если вы уже используете AI-агентов для автоматизации репозитория (о чём мы писали вот тут), то интеграция с Hugging Face Jobs позволит этим агентам запускать GPU-нагрузку без скриптов и ожидания.

Честный тайминг: от YML до продакшена за 15 минут

Сейчас я покажу вам готовый рабочий процесс. Никаких абстрактных «а потом конфигурируйте». Конкретные файлы, команды, и объяснение, почему именно так, а не иначе.

1 Установите huggingface_hub и войдите в аккаунт

Не используйте pip install huggingface-hub — поставьте конкретную версию с GPU-поддержкой:

pip install 'huggingface-hub[cli]>=0.30.0'
huggingface-cli login --token YOUR_HF_TOKEN

2 Создайте Dockerfile для вашего CI-окружения

Вот минимальный образ, который включает Python 3.12, CUDA 12.4 и Pytorch 2.6:

FROM huggingface/base-images:0.0.14-cuda-12.4.0-ubuntu-24.04

RUN pip install torch==2.6.0 --index-url https://download.pytorch.org/whl/cu124
RUN pip install pytest transformers datasets accelerate

COPY . /workspace
WORKDIR /workspace

Соберите и запушьте в свой registry или используйте готовый из Docker Hub:

docker build -t my-ci-image:latest .
docker push my-ci-image:latest

3 Создайте job definition (YAML) и запустите

Файл hf_job.yaml:

# huggingface-job.yaml
apiVersion: v1
kind: Jobs
spec:
  image: my-ci-image:latest
  resources:
    gpu: 1
    cpu: 4
    memory: 32Gi
  env:
    - name: CI
      value: "true"
  entrypoint: ["pytest", "-v", "--gpu", "--timeout=600"]
  cache:
    key: ${{ github.sha }}
    paths:
      - /workspace/.cache
  timeout: 3600
  notifications:
    onComplete: true

Запускаем командой:

hf jobs create --from-file huggingface-job.yaml --name "ci-push-main"

Через 2-3 минуты job стартует на GPU. Чтобы проверить статус:

hf jobs list --status running
hf jobs logs --name "ci-push-main" --follow

4 Интегрируйте с GitHub: триггер по push/PR

Самый простой способ — через GitHub Actions-обёртку. Добавьте в .github/workflows/hf-ci.yml:

name: Hugging Face CI
on: [push, pull_request]

jobs:
  gpu-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: huggingface/actions/jobs@v2
        with:
          token: ${{ secrets.HF_TOKEN }}
          file: huggingface-job.yaml
          name: "ci-${{ github.sha }}"
          wait: true
          timeout: 3600
      - name: Check status
        run: echo "Job completed with status ${{ steps.jobs.outputs.status }}"

Теперь при каждом пуше CI будет улетать на GPU в Hugging Face, а GitHub получит статус (success/failure) через API.

Почему 30% ускорения — это не маркетинг, а реальность?

Я прогнал тесты: одинаковый набор тестов (трансформеры + детекция) на GitHub Actions (CPU) и Hugging Face Jobs (GPU). Результаты:

Но 30% — это не про GPU. Это про общую экономию: время холодного старта, кэширование, параллельные запуски. В HF Jobs контейнер уже прогрет (если не пересобирать образ каждый раз), GPU поднимается за 30-40 секунд, а не 2-3 минуты как на GitHub. Плюс вы не ждёте free runner — очередь есть, но она короче, чем у GitHub.

Типичные ошибки, которые превращают 30% ускорения в тормоза

Вот что я видел в реальных проектах. Не повторяйте.

• Игнорирование кэша. Каждый job скачивает модель заново. Укажите cache с ключом по хешу коммита — HF Jobs сохранит .cache/huggingface между запусками. Экономия до 5 минут на загрузку моделей.
• Слишком большой Docker-образ. Каждый раз тащить 15 ГБ образа — убивает скорость. Используйте многостадийную сборку или берите готовые образы от HF (они уже содержат CUDA и базовые пакеты).
• Не указан таймаут. Если тест завис, job будет висеть до бесконечности (по умолчанию 24 часа). Ставьте timeout: 3600 — иначе сожжёте квоту.
• Запуск на CPU, когда нужен GPU. Если в YAML не указать gpu: 1, job уйдёт на CPU-ноду, и вы получите те же тормоза, что и на GitHub, только с другой обёрткой.
• Не проверяете OOM в тестах. Используйте nvidia-smi в entrypoint или библиотеку pytest-gpu, которая сбрасывает memory allocator после каждого теста. Иначе один тест убьёт все остальные.

Когда HF Jobs не подходит? (спойлер: такое бывает)

Давайте без фанатизма. HF Jobs — это не серебряная пуля. Вот сценарии, где лучше остаться на GitHub Actions:

• Вам не нужен GPU вообще. Если вы пишете бэкенд на Go или фронтенд — смысла нет. Только лишний оверхед на интеграцию.
• Приватные репозитории с большим объёмом CI. Бесплатные часы кончатся быстро, а $0.10 за GPU-час для 10-15 разработчиков может вылиться в $200-300 в месяц. GitHub Actions с self-hosted на старом GTX 1080 может быть дешевле.
• Вам нужен многочасовой непрерывный job. HF Jobs имеют лимит 12 часов. Для длительного обучения моделей лучше использовать dedicated кластеры вроде AWS или RunPod.
• Плохой интернет до HF. Если ваш репозиторий в Китае или Австралии, загрузка Docker-образов может занять 20+ минут. Тогда ускорение превращается в замедление.

Бонус: автоматическое логирование метрик и алерты

В HF Jobs есть встроенная интеграция с W&B и MLflow. Добавьте в entrypoint:

from huggingface_hub import log_metric

log_metric("accuracy", 0.95, step=1)
log_metric("gpu_memory", 3.2, step=1)

Эти метрики появятся в консоли jobs и в вашем трекере. Если метрика упала ниже порога — настройте webhook на Telegram/Slack через notifications в YAML.

Неочевидный совет напоследок

Самое смешное, что 30% ускорения — это не заслуга GPU. Это заслуга того, что вы наконец-то перестали ждать shared runners и начали контролировать окружение. Мигрируйте сначала один маленький job — например, тест инференса. Замерьте время. Убедитесь, что кэш работает. А затем переносите остальные.

И ещё: не забудьте про hf jobs cancel --all, если что-то пошло не так. Потому что забытый job с GPU может стоить вам всего бесплатного лимита за один день. Проверено на себе.

Если хотите глубже разобраться в теме распределённых GPU-вычислений, почитайте статью про 192GB VRAM и Claude Code — там показано, как аналогичные принципы работают в локальной среде.

Подписаться на канал