huggingface-zerogpu

Hugging Face ZeroGPU — это навык для Gradio SDK Spaces, которым нужно пользоваться, когда приложение запускает ML-демо на виртуализированном GPU через пакет spaces и декоратор @spaces.GPU. Источник отдельно ограничивает область применения: ZeroGPU относится к Gradio Spaces; Docker и Static Spaces не могут планировать задачи на ZeroGPU, а Streamlit работает как Docker Space. Для общих компонентов Gradio нужен другой специализированный навык, поэтому эту карточку не следует воспринимать как универсальную инструкцию по интерфейсам Gradio. Главный рабочий паттерн — загрузить модель и pipeline на уровне модуля, выбрать устройство через стандартную проверку CUDA и поместить фактический inference внутрь функции, отмеченной @spaces.GPU. Платформа сама регистрирует веса, переносит их в GPU-воркер и может повторно использовать прогретый воркер. При этом torch.cuda.is_available() в ZeroGPU пропатчен и возвращает True даже вне реального GPU-вызова, поэтому эту проверку нельзя использовать как доказательство того, что вычисление уже выполняется на видеокарте. Модель можно подготовить на уровне модуля, но CUDA-ядра и inference там запускать нельзя. Пакет spaces вне ZeroGPU является безопасным no-op, поэтому не нужен самодельный try/except-фолбэк и не стоит скрывать зависимость от requirements или конфигурации проекта. Особое внимание навык уделяет duration и квоте. Для каждого вызова проверяются предел тарифа, оставшаяся квота пользователя и место в общей очереди; при size=xlarge запрошенное время учитывается с двойным коэффициентом. Поэтому duration нужно задавать как наименьшее реалистичное худшее время, а для переменной нагрузки допустима функция, вычисляющая его по входным параметрам. Слишком большое значение может дать ошибку illegal duration или quota exceeded ещё до фактического запуска, а короткое корректное значение повышает приоритет в очереди. Размер xlarge следует применять только когда половины доступного среза недостаточно: он расходует больше квоты и обычно дольше ожидает слот. Вызовы @spaces.GPU выполняются в отдельном процессе и передают аргументы и результаты через pickle. Нельзя передавать открытые файлы, соединения, блокировки, lambda и другие непиклируемые объекты; CUDA-тензоры нужно переводить на CPU перед возвратом, иначе распаковка в основном процессе может вызвать инициализацию CUDA вне разрешённого контекста. Значения gr.State также копируются при каждом yield, а изменения объекта на месте не становятся видимыми другим обработчикам без явной передачи состояния обратно. Поскольку обработчики по умолчанию работают конкурентно, нельзя хранить в изменяемых глобальных переменных состояние запроса или писать результаты в фиксированный путь; для файлов нужны уникальные временные пути, а глобальными безопасно оставлять только неизменяемые модели, токенизаторы и конфигурации. Для производительности и сборки навык рекомендует загружать модели заранее, объединять цикл в один GPU-вызов вместо множества входов в декоратор и не использовать torch.compile: для совместимого сценария упоминается AoTI. Сборка ZeroGPU выполняется без nvcc, поэтому CUDA-зависимые пакеты должны поставляться готовыми wheel-файлами; дополнительно нужно согласовать версию torch с тегом wheel. python_version следует явно закрепить в frontmatter README, а пакет spaces не следует вручную фиксировать в requirements.txt. Эти ограничения делают карточку полезной для отладки PicklingError, illegal duration, quota exceeded и проблем сборки flash-attn, но не отменяют необходимость сверяться с актуальной документацией ZeroGPU для меняющихся аппаратных, тарифных и runtime-порогов.