Hugging Face Spaces 机器学习托管

要解决什么问题

机器学习演示和应用往往卡在「本地能跑、线上难维护」：环境不一致、GPU 成本、以及 Hugging Face Hub 上 Space 作为 git 仓库时的 SDK、硬件与构建细节。本技能面向工程师，把从登录 hf CLI 到推送、验证、排错的一条链路写清楚，避免把 README 里的 hardware: 当成有效配置、或误用 hf upload 默认上传到模型仓库。

技能如何组织工作流

• 选型：先搜已有 Space 读 app.py / requirements.txt；在 Gradio + ZeroGPU、cpu-basic、专用 GPU、Docker、Static 之间按模型栈与负载决策。
• 创建与配置：--space-sdk、--flavor、可见性；敏感项用 --secrets，非敏感用 --env；硬件仅在创建或 hf spaces settings 中设置。
• ZeroGPU Gradio 三规则：在触及 CUDA 前 import spaces；模块级加载并 .to("cuda")；对 Gradio 绑定函数使用 @spaces.GPU 并合理估计 duration。
• 依赖：requirements.txt 不 pin 平台预装的 gradio / spaces / huggingface_hub；ZeroGPU 对 torch 版本有白名单；Blackwell 扩展 wheel 有专门数据集路径。
• 迭代与验证：以线上 Space 为真环境；推送后区分热重载、上传与全量重建；除 RUNNING 外还要查构建/运行日志、API 响应与输出是否静默降级。
• 排错顺序：日志找第一个错误 → references/known-errors.md → references/debugging.md 中最廉价层级；持久化需 bucket（付费，看 canPay）。

适用边界

专用 GPU 需创建者 canPay；ZeroGPU 要求 PRO/Team/Enterprise 且以 Gradio、PyTorch 为主。非 PRO 仍可按 ZeroGPU 模式开发后走社区资助。模型装不下时可参考 Inference Providers 而非自托管。细节分散在 zerogpu、gradio、requirements、buckets 等 reference 文档，技能索引阅读时机而非替代官方 Hub 文档。