huggingface-spaces

Этот навык посвящён созданию, публикации и сопровождению приложений в Hugging Face Spaces. В исходном SKILL.md Space описан как git-репозиторий, а не как безымянный хостинг: код, конфигурация SDK и README с frontmatter образуют развёртываемый проект. Поддерживаются три основных варианта — Gradio, Docker и Static. Gradio подходит для большинства интерактивных ML-демо и может использовать ZeroGPU, Docker предназначен для произвольного контейнера, но ZeroGPU для него не поддерживается, а Static подходит для HTML/SPA и браузерного ML на WebGPU, WebAssembly или onnxruntime-web. Перед началом нужно проверить наличие hf CLI и состояние входа в Hugging Face. Права и тариф влияют на выбор оборудования: Static доступен без оборудования, Gradio и Docker используют вычислительные ресурсы, а ZeroGPU — путь для Gradio с динамическим вызовом GPU. В исходной инструкции отдельно предупреждается, что cpu-basic требует платного плана, поэтому его нельзя считать бесплатным запасным вариантом. Для подходящего проекта сначала следует поискать существующий Space с похожей задачей, прочитать его приложение и зависимости, а затем выбрать SDK по фактической потребности: браузерная демонстрация, Python/Gradio, произвольный контейнер или статическая страница. Для ZeroGPU навык задаёт несколько важных технических условий. import spaces должен идти до импортов, которые могут затронуть CUDA; модель рекомендуется загружать на уровне модуля, чтобы не повторять тяжёлую загрузку при каждом запросе; декоратор @spaces.GPU нужно ставить на функцию, которую действительно вызывает Gradio, и оценивать её длительность реалистично. В Gradio-приложении полезны небольшие официальные примеры, типы и docstring у API-функций, а запуск с mcp_server=true позволяет представить API-функции как MCP-инструменты. Эти правила уменьшают вероятность того, что Space формально запустится, но будет каждый раз заново инициализировать модель или не покажет понятную схему API. README обязателен для конфигурации проекта: в frontmatter указываются SDK, файл приложения и параметры сборки; версию Gradio нельзя копировать вслепую, её следует сверять с актуальной средой. В requirements.txt не нужно повторно фиксировать управляемые платформой gradio, spaces и huggingface_hub; остальные реальные зависимости, включая torchvision или torchaudio при необходимости, должны быть перечислены. Для Static SPA команда сборки и итоговый файл также задаются в конфигурации Space. Проверка должна идти дальше статуса RUNNING. Навык предлагает последовательно посмотреть состояние runtime и hardware, проверить логи после загрузки, вызвать реальный API через gradio_client, а затем проверить содержимое результата и логи этого вызова. Это важно для выявления тихого перехода на CPU, неправильного dtype, отсутствующей зависимости или другой модели. Spaces не следует считать постоянным диском: если нужны долгоживущие пользовательские файлы, логи или результаты, описан отдельный bucket. Навык помогает пройти путь от выбора SDK до живого smoke test, но не отменяет проверки лицензий моделей, секретов, стоимости платного железа, лимитов квот и безопасности публичного приложения.