快速决策
先按交付目标选模型，再调参数。
| 目标 | 优先候选 | 为什么 | 需要接受的代价 |
|---|---|---|---|
| 中文长篇稳定配音 | IndexTTS 2.5 | 工作台默认路径，MLX 8-bit，本地缓存音色条件 | 复杂情绪需要用文本表达或改走其他引擎 |
| 指定八类情绪 | IndexTTS 2.0 | 情绪类型与强度分开控制 | 旧一代引擎，速度与资源要按设备实测 |
| 用文字描述新音色 | OmniVoice MLX | 克隆、音色设计、自动音色三种模式 | 克隆依赖准确参考转写，许可需单独核对 |
| 多角色与表达标签 | Fish Audio S2 Pro | 多说话人、内联表达、44.1 kHz 输出 | 内存压力与长段截断风险更高，商用需相应许可 |
| 验证原生 OmniVoice | VoiceStudio | 保留 PyTorch/MPS 原生能力与兼容路径 | 运行时更重，子进程和 CPU 音频 tokenizer 增加复杂度 |
模型 01
IndexTTS 2.5 / MLX 8-bit
工作台默认主引擎，输入目标文本、参考音频和可选参数，输出 22,050 Hz 音频。参考音频先转成模型可用的音色条件并按模型命名空间缓存，重复使用同一音色时跳过重复编码。
text + reference_audio → voice_condition → waveform输出：WAV / MP3 / FLAC优点
- MLX 8-bit 更适合 Apple Silicon 的统一内存环境。
- 默认路径短，适合稳定、连续的中文口播与长篇项目。
- 音色条件缓存能降低批量生成时的重复计算。
- 已经接入分段、进度、预计时间、停止和部分结果保留。
缺点与边界
- 当前适配层不提供 IndexTTS 2.0 那套原生八类情绪向量。
- 超长文本仍须切段，不能把“项目不限字数”理解为一次推理无限长度。
- 音色缓存与模型版本绑定，切换引擎后不能盲目复用。
- 极端输入可能需要降低段长并进行保护性重试。
最适合：长篇中文解说、批量口播、同一音色多稿件。不优先：需要精确情绪向量或多人对话标签的任务。
模型 02
IndexTTS 2.0 / MLX
保留上一代引擎作为明确情绪控制路径。调用时把参考音色与八类情绪之一、情绪强度和目标文本共同送入生成器；每个模型拥有独立参数档案与缓存。
text + reference_audio + emotion + strength → waveform情绪：happy / sad / angry / afraid / disgusted / melancholic / surprised / calm优点
- 情绪类型与强度有明确字段，容易复现和批量化。
- 八类情绪适合广告口播、剧情片段和强调语气。
- 与工作台的音色库、任务控制和导出功能共用。
缺点与边界
- 作为旧版本路径，质量与速度不应只凭版本号推断，需以样稿验收。
- 情绪强度过高可能损伤自然度或音色相似度。
- 输出仍需分段合成；段间响度和停顿要在后处理中统一。
最适合：需要可记录、可复现情绪参数的内容。不优先：仅追求最短调用链的普通旁白。
模型 03
OmniVoice / MLX
一个入口支持参考音频克隆、文字描述音色和自动音色。克隆时参考音频与逐字转写需要对齐；没有转写时先调用本地 ASR 补全，再把音频与文本共同编码。
clone: text + audio + transcriptdesign: text + voice_description输出：24,000 Hz优点
- 同一引擎覆盖克隆、设计和自动三种使用方式。
- 不必总有参考音频，可用自然语言描述想要的音色。
- 表达预设可以覆盖耳语等特定风格。
- 本地 ASR 缓解用户没有参考文本的问题。
缺点与边界
- 克隆质量依赖参考文本与音频逐字一致，错字和漏字会传导到结果。
- 自然语言情绪描述不是固定标签，复现度低于数值向量。
- 本地 ASR 增加预处理时间，并可能产生识别误差。
- 上游权重许可需按实际使用场景核对，不能默认可商用。
最适合：文字设计音色、快速探索、耳语等表达预设。不优先：无法提供清晰参考音频且又要求高度还原的克隆。
模型 04
Fish Audio S2 Pro / MLX 8-bit
面向更丰富表达和多说话人内容的路径。工作台会缓存参考编码，把长文本优先按安全标点切成约 60 字片段，再逐段生成 44,100 Hz 音频并合并。
text/tags + optional_reference + speaker_map → chunks → waveform输出：44,100 Hz优点
- 较高输出采样率，适合后续音频制作链。
- 支持自动音色、参考克隆、多说话人和表达标签。
- 角色映射能把对话稿直接路由到不同说话人。
- 参考编码缓存适合系列化、多集内容。
缺点与边界
- 运行内存压力更大，生成速度更依赖设备与参数。
- 过长单段有 token 截断风险，因此必须主动缩短分段。
- 多说话人文本需要严格的角色标记和一致命名。
- Fish Research License 下的商业使用需要取得相应许可。
最适合：多角色播客、剧情内容、表达标签驱动的语音。不优先：资源紧张设备上的超长单音色批处理。
模型 05
VoiceStudio 原生 OmniVoice / PyTorch MPS
这条路径保留原生实现，由独立子进程加载 PyTorch/MPS 模型。主工作台负责输入、状态与结果，子进程负责模型生命周期，切换模型时显式释放资源。
job.json → subprocess → progress/result.json → audio模式：clone / design / auto优点
- 便于验证原生引擎能力与 MLX 适配结果的差异。
- 进程隔离降低不同依赖栈互相污染的概率。
- 保留三种 OmniVoice 工作模式。
- 子进程异常不会直接破坏主 WebUI 状态。
缺点与边界
- PyTorch/MPS 运行时更重，冷启动和内存成本更高。
- 音频 tokenizer 可能落在 CPU，整体链路并非完全 GPU 加速。
- 进度、取消、错误和临时文件需要跨进程同步。
- 仍要单独审查上游模型和权重许可。
最适合：原生兼容测试、结果对照、需要隔离依赖的部署。不优先：只追求轻量、快速启动的日常批量任务。
规模说明
十万字、二十万字是项目编排问题，不是一条无限长度推理。
- 按书、章、节建立内容清单，为每批分配稳定 ID。
- 在批次内按模型安全长度和自然标点切段，避免截断半句。
- 每段记录文本哈希、模型、音色、参数、输出路径与状态。
- 失败仅重跑对应片段；重启后从检查点继续，不重复已完成工作。
- 统一响度、采样率、段间静音和文件命名，再按章或整书合并。
- 交付前做缺段、重段、顺序、时长、峰值和试听抽检。
真实边界：当前 WebUI 单次任务有 100,000 字符保护上限。项目总量不设固定业务上限，20 万字及更大内容使用章节批次和任务队列交付。
继续查询
人和 Agent 都能沿着同一套证据继续查。
资料状态
内容依据现有工作台适配层、调用脚本、运行记录与产品约束整理。最后核对：。商务咨询：wangdexin2008@126.com。