技能介绍

要解决什么问题

训练或托管在 Hugging Face Hub 上的 LoRA，最终往往还需要一个可分享的推理入口：不是本地脚本，而是别人能在浏览器里点开的 Space。难点在于不同 LoRA 的任务与输入形态差异很大——同样是视频到视频，姿态控制与外绘需要的控件、预处理完全不同；若套用通用模板，要么 UI 臃肿、要么推理参数与模型卡片不一致，还会在 ZeroGPU 上踩加载与依赖的坑。

技能如何工作

本技能按固定阶段推进，并强调为当前 LoRA 定制演示，而非拼接模板。

收集 LoRA 信息：从 Hub 仓库读取模型卡片与文件（权重、README、示例媒体），推断基础模型、任务类型（text-to-image / image-to-image / 视频类等）、触发词与推荐步数、引导尺度、LoRA 缩放等；私有仓库在需要时一次性索取具备写入权限的 HF 令牌。
选择管道：对照 references/base-models/ 中 Qwen-Image、LTX、Krea 2 等参考，并强制以基础模型卡片里的 diffusers 管道类为准，避免「能跑但类错」的静默错误；默认优先 diffusers 的 load_lora_weights。
设计 UI：结合任务基准与 LoRA 子用例（重打光、外绘、角色动作迁移等）决定控件；必要时用 Hub 自定义组件或 gr.HTML 创意模式；示例媒体可来自共享输入池并配合 cache_examples=True, cache_mode="lazy"。
一次性交付三文件：app.py（模块级 CUDA 加载、@spaces.GPU 推理）、由导入推导的 requirements.txt、带 ZeroGPU YAML 的 README.md，同一条消息供审阅后再发布。
发布与冒烟：默认私有 Space；LoRA 受限时在 Space 密钥中配置 HF_TOKEN；发布后用 gradio predict 等做端到端验证。

适用边界与注意点

一级支持的基础模型系列以技能内参考文件为准；不在列表中的模型需用户确认是否按最接近方案类比或中止。
默认硬件为 ZeroGPU（hardware: zero-a10g）；非 PRO/Team/Enterprise 可能回退 CPU 或创建时无法指定 ZeroGPU。
requirements.txt 不应重复声明 gradio/torch/spaces/huggingface_hub（由运行时或 README 管理）；慎用 xformers、flash-attn 等易冲突依赖。
避免在 app.py 中使用 torch.compile；short_description 需保持简短以免 YAML 校验失败。