lora-tts-studio · in-house model factory

4 张 desktop app surface (train / lab / queue / sort) 静态展示. 架构示意见 architecture/p4.svg.

整个体系上层 — 不论是 Interaction 层的 PWA 生图、虚拟人的自用音色, 还是 Cognition 层的虚拟人 persona 视觉锚 — 都依赖一份"自己的"基本模型. 现成 ckpt 拼凑可以走到 demo, 但走不到一个有人格、有视觉一致性、有专属声音的虚拟人. 训练 (视觉 LoRA + TTS 声音克隆) 就是这条路上不可外包的地基.

lora-tts-studio 在体系里是训练场地 — Civitai 抓素材进、Hugging Face 全开源底模 (SDXL / Flux 等) 进、TTS 声音克隆素材进、pod GPU 跑、训完的 LoRA 与自用音色回流到上层. 它是 Foundation 层里唯一一个面向 "我们自己要长期迭代的模型" 而不是 "拿来就用" 的组件.

没有它, 体系会陷入 "永远拼 OSS ckpt" 的状态, 虚拟人就停留在通用脸通用风格, 走不到 persona 持久化.

全开源底模 (SDXL / Flux 等) 的 LoRA 训练与 TTS 声音克隆的 OSS 工具链是分散的 — Civitai 抓素材是一套, kohya 训 LoRA 是一套, 声音克隆又是一套, ComfyUI 测再是一套. 桌面端没有把它们捏在一起的人. 每开一炉训练都要手工切环境、改 config、登 pod、看日志, 中断了还要从头判断进度.

如果虚拟人的视觉身份与专属声音要做到可控、可迭代、可复现, 训练就不能是手工活. 必须有一个 desktop app + LLM confirm-gate 工具循环, 让训练这件事可以无人值守 + 可审计 + 出问题能回放.

lora-tts-studio 想解决的不是 "训得更快", 而是 "训这件事 (无论是视觉 LoRA 还是声音克隆) 不再依赖单个人坐在电脑前". 这条路通了, 上层 (PWA / Cognition persona) 才有持续供给.

当前是 mvp 状态 — 桌面端可以走通一次完整训练, 但故障自愈和参数自适应还没做完.

• 已落地: 3 层架构 (frontend pywebview frameless + Mica 半透明 · backend FastAPI · pod 远端训练 paramiko SSH); 7 个 backend module (server / agent / pipeline_runner / pod_trainer / hf_transfer / param_engine / comfyui_manager); 5 个 UI surface (train / lab / queue / tts / sort); SSE 实时日志推送; Win32 Job Object 桌面关窗自动清子进程, 不留孤儿; frontend ~3,200 LOC.
• 探索中: 训练参数自动推荐 (LLM-driven config — 让模型根据素材特征拟一份 hyperparameter, 而不是人去查文档); queue 故障自愈 (pod 掉线 / OOM 后自动重排).
• 待解决: 失败重试还是人工 — 跑断了要人手动判断重启还是放弃; 跨 base model 的 hyperparameter 自适应没做 — SDXL 一套参数, Flux 一套, 切换全靠记忆; 训出的 LoRA 还没闭环回流到 PWA 生图的自动测试.

• pod 端故障自愈 — pod 掉线 / OOM / 网络抖动后, queue 自动重排不需要人介入
• LLM-driven config — 素材进来后, agent 拟一份 hyperparameter 候选, 用户在 confirm-gate 拍板, 不再手工查文档
• multi-base 适配 — SDXL 与 Flux 的 hyperparameter 差异内置成 profile, 切 base model 不靠记忆
• 训出第一个真实场景化 LoRA 回流到 PWA 生图, 闭环 Foundation → Interaction 数据流
• 训完自动出对照评估 (baseline ckpt vs trained LoRA), 不再靠肉眼看 5 张图判断收没收敛