OmniVoice（子进程隔离）引擎¶

omnivoice-subprocess 引擎与默认的 omnivoice 引擎运行相同的常驻 VoiceStudio 模型，但运行在崩溃隔离的子进程中，因此卡住的生成任务可以被强制终止，并回收其 VRAM/设备。

为什么存在这个引擎¶

进程内 omnivoice 引擎运行在 GPU 工作线程池上。在 VRAM 紧张机器上，一次重负载生成或模型加载可能超出其执行预算。此时该工作线程会被“弃置”但无法被终止（Python 无法中断原生 torch 调用），因此它会一直占用 GPU 设备直到自行完成，之后所有后续合成都在它后面排队并挂起（#730 / #1190）。

omnivoice-subprocess 通过与 IndexTTS、Supertonic-3 和 dots.tts 相同的 SubprocessBackend 原语，在子进程中运行模型。子进程可以被强制终止：超时后父进程会杀死它（proc.kill()），释放其 VRAM/设备，下一个请求会透明地重新生成一个全新的 sidecar。这正是进程内引擎在结构上无法做到的事情。

何时使用¶

• 无人值守 / 定时 / 事件触发的合成任务，卡住时必须自行恢复，而不是一直挂起直到手动重启。
• 遭遇被弃工作线程级联效应的 VRAM 匮乏的 MPS 主机。

在 Apple Silicon 上，默认的 omnivoice id 会自动使用这种隔离实现。CUDA、ROCm 和 CPU 则继续使用进程内实现及其更低的调用开销。

选择它¶

• CUDA、ROCm 或 CPU 上的 Model Catalogue，或
• OMNIVOICE_TTS_BACKEND=omnivoice-subprocess

在 CUDA、ROCm 和 CPU 上，显式选择该引擎是可选操作。Apple Silicon 只显示规范的 omnivoice 选项，因为它在那里会自动使用相同的过程隔离；其规范 id 仍会出现在 API、设置和已保存项目中。现有的 omnivoice-subprocess 配置仍然有效并被接受。

平台支持¶

• CUDA、Linux 上的 AMD ROCm、MPS 和 CPU（与进程内 VoiceStudio 引擎相同）。
• 无需额外安装。 与 IndexTTS / dots.tts / Supertonic-3 不同，这个 sidecar 运行在 VoiceStudio 自己的解释器下，因为这里的目标是崩溃隔离，而不是依赖隔离。如果默认的 omnivoice 引擎对你可用，那么这个引擎也随时可用。

与进程内 omnivoice 引擎的权衡¶

• 相同的模型和输出质量。
• 每次调用的延迟略高（每次合成一次 stdio 往返）。
• 卡住的生成会在 recv 超时截止时间（OMNIVOICE_SIDECAR_RECV_TIMEOUT_S，默认 300 秒，与生成预算对齐）被终止并恢复，而不是无限期挂起。
• 默认的 Apple Silicon 代理会跨进程边界保留原生高级参数、确定性随机种子和长文本质量设置。
• recv-timeout 截止时间是按调用计算的，并假设路由会进行文本分块：/generate 和 /v1/audio/speech 在调用引擎之前会把长文本切分为最多 max_chunk_chars 字符的片段，因此每次调用都保持较短。单个未分块的超长 generate() 可能超过截止时间并被终止；这正是看门狗按预期工作，而不是挂起。

调优¶