voicestudio 克隆声音 声音效果没有想象中的那么自然

当VoiceStudio感觉慢时，时间会怎么流逝，你可以调什么，你又能调什么 应该别管他。这里的内容适用于当前版本;人数 标注为“测量”的设备来自一台16GB的苹果设备 硅M2——你的硬件会不同，但比例是固定的。scripts/bench_pipeline.py

在操作任何旋钮之前，先检查这些——它们解释了大多数慢速报告：

1. 一个语音档案，但文字记录字段是空的。克隆需要 参考剪辑的文字记录。如果配置文件没有，应用会运行一个 完整Whisper转录了该片段——在v0.3.15之前，每个生成点都这样（“TTS更新后变慢了，CPU” “定位为100%”回归，#1032）。自v0.3.15起，自动转录 运行一次后保存到配置文件中，但配置文件仍然包含 空转录（例如导入或手工编辑数据）持续支付ASR 每代通过。解决办法：打开语音编辑器，检查一下 文字记录框——如果是空的，输入或粘贴参考片段中的内容 （或者在 v0.3.15+ 上生成一次，确认盒子是否自动填满）。
2. （重新）启动后的第一代总是最慢的。模型 权重加载延迟（~8秒），CUDA构建torch.compile内核，苹果硅芯片 金属核子会变暖。从第二代开始判断速度。
3. 记忆压力。在一台16GB统一内存的机器上，浏览器容量为40 配音旁边的制表符表示操作系统会分页模型——或者关闭 后端完全（“无法访问本地后端”）。检查设置→ 有常驻模型，以及性能设置→免费内存。参见“刷新缓存/卸载常驻模型”，了解如何在不重启的情况下释放内存。
4. 你是在无意识地在CPU上生成。驱动更新，一个 CUDA/喷灯不匹配，或者运行在没有支持GPU的硬件上 路径会悄无声息地把你丢给CPU——一切都能正常工作，只是多次出现 慢一点。有三个地方告诉你真相：
   • 设置→性能 →设备和计算显示实时计算 设备（ / / ），一个“GPU主动”徽章，以及内存/显存 读数。cudampscpu
   • 设置 → 关于 → 运行自检（端点） 明确警告：“CPU（未检测到GPU加速）”，并带有提示 关于司机。/system/diagnose
   • 模型目录显示每个发动机的路由徽章——“GPU active”， “CPU 备用”或称“CPU”——原因在下方以小文字显示 徽章（悬浮全文）。 注意：Windows上的PyTorch GPU加速仅支持NVIDIA/CUDA——AMD和 Intel GPU在那个CPU上运行PyTorch引擎（audio.cpp仍然可以使用 Radeon通过Vulkan;参见Windows安装说明）。设置 → 性能 → GPU 加速 （） 按引擎列出是否使用该机器的GPU，以及原因 否则——包括“你的Radeon被找到了，但这个PyTorch版本是 仅限NVIDIA支持。”GET /api/settings/gpu-report
5. 你之前中止过一次配音（在v0.3.23修复了）。配音会推动TTS的操作 模型转为CPU以释放显存用于ASR模型，然后在 转录结束。在v0.3.23之前，这个移动只能在完全运行 成功路径，比如取消 dub、触发 dub 错误或关闭 tab在转录中途使TTS模型被困在CPU上——之后每一代都运行在CPU上，CPU被挂钩时速度慢了10到50倍，直到 ~15分钟空闲卸载发生了火灾。重启后端后端清除了它， 这让它看起来像是随机的，或者与一天中的某个时间段有关（#1191）。自v0.3.23起 每条出口路径都运行回退，每一代都验证模型 在预期设备上，并自动将其移回去——因此没有未来的代码路径 可以再让它被困。如果你用的是旧版本，重启后端。

对于克隆声音，一代为：编码参考片段（~0.4秒， 测量;在你重复使用的声音第一次使用后被缓存——配音的 每行剪辑只用一次，所以缓存里没有东西可以保存 在那里）→合成（整体;随输出长度增长）→后处理 （母带处理，水印;分秒级）。长文本分为多个部分 区块按顺序合成——时间大致与文本线性排列 长度。

对于配音，阶段分别是：音频提取 + 人声分离（一次性， 长视频的分钟数））→转录（使用最佳加速器—— 苹果硅片自v0.3.21起使用MLX，NVIDIA使用CUDA;仅支持CPU的安装会失败 返回处理器）→翻译（并行，6个并发LLM请求） 提供者）→逐段合成（大部分时间顺序合成）→ 混音和导出（大多是流复制，快速）。

所有这些都是后端在开始时读取的环境变量。设置 在（安装程序创建）或你的shell配置文件中。 这些并非必须——默认选择是针对常见情况。~/.config/omnivoice/env

torch.compile 是基于探测的，不是基于平台的：它只是尝试完成 运行时检查显示其可运行（带有 Triton 导入的 CUDA 设备） 并且支持GPU架构），其他部分则自动跳过—— MPS、CPU 以及典型的 Windows 安装（Triton 不附带 Windows 方向盘）。 唯一面向用户的控制是“性能设置”→→“禁用” “torch.compile”，在所有平台上都可以使用，用于探测器的设置 通过，但编译尝试本身表现异常——部分Triton安装， 或者是 GPU 编译后内核导致引擎崩溃。环境设置（或 ）会 同样的道理，并且受到正在处理的发动机和所有发动机的尊重 子进程。请参见Windows安装说明。TORCH_COMPILE_DISABLE=1TORCHDYNAMO_DISABLE=1

在CUDA中，编译模式是根据GPU选择的：Ampere （sm_80） 和更新的版本，用于捕获CUDA图;较旧的卡片（如图灵/伏打，例如 特斯拉 T4）回退到纯模式，因为图捕获是 观察到在那里中止整个后端进程 （#2135）。他们仍然会 编译后的电感核。 恢复 如果你想做基准测试，可以用Cudagraph模式。reduce-overheaddefaultOMNIVOICE_FORCE_CUDAGRAPH=1

300 的预算以前是吃亏才发现的：你按了生成， 等到预算用完，结果被告知工作太重了。二 现在检查会在请求离开应用之前执行，即每一次调用 合成路径共享（生成、语音预览、比较模态、故事 编辑、个人资料预览和直播）。

为什么要1200字符：这个建议门槛与免费允许相符 遗产加速/显式预算规则：前1200个字符获得 基础固定，预算每40个字符增加1秒。默认CPU预算 使用另一条规则：每个角色的4秒超过150以上的600秒。 因此，一篇400字符的文章即使没有长度，也会获得1600秒 警告出现。警告阈值本身保持不变。

适用哪种基础：

CPU主机的扩展速度远快于每40个字符的+1秒。CPU 渲染是 通常比GPU慢10-50倍，所以 默认情况下，预算会以每个输入字符（400字符）增长4秒 Passage大约27分钟），基础计算空间上限为2小时。 队列、模型加载以及现有的进度-扩展余额为 分开。每个流式片段的预算均来自其自身文本;一份无声、被楔入式的工作 耗尽其计算允许。设置CPU预算会明确实现这一点 按比例缩放，并用你的数值作为底线（加上标准的+1秒每40秒） 角色）——明确的设定总是权威的。OMNIVOICE_CPU_GENERATE_TIMEOUT_S

桌面后备系统考虑了本地自动CPU上限的报告 CPU路由的作业，默认预算。MCP工具保守地允许这样做 当CPU预算未明确设置时，天花板。这两种等待时间还包括 模型负载、队列、边车和进度扩展的权限。天花板避免了 从输入文本猜测计算预算，数字归一化或 发音规则可以在合成前扩展。

MCP生成还允许在之前进行单独的参考转录工作 无缓存转录本的克隆档案合成。那项工作使用 发电台基础预算、自己的队列和进度扩展;它不使用 独立转录超时。MCP保守地将该补贴纳入 因为它无法检查后端缓存的参考转录。

上述两行都可以被覆盖，且这两个变量是独立的：

• 显式 始终控制 CPU 家族 即使加速变速也被设置了，也会产生。OMNIVOICE_CPU_GENERATE_TIMEOUT_S
• 在每个字上都逐字使用显式的 加速主机——包括一个资源不足的主机，然后它会保留 你选择的价值，而不是被击倒。这是有意为之：就是 只需一个设置，就能降低看门狗，让所有地方快速失效。OMNIVOICE_GENERATE_TIMEOUT_S

这两项警告均为建议性——没有任何被阻挡的内容。驱动程序可以分页到系统 内存和短输入可以装进去，而长输入不行，所以发动机还能运转 如果你愿意的话。每台发动机每次会话点火一次，基于 所以确实有不同的问题依然存在，但问题是一样的 句子并非每次合成都重复。切换发动机会重新激活它。

如果你已经用的是CPU调优的引擎（OmniVoice GGUF、Supertonic-3），那 警告会放弃“试试CPU调校发动机”的建议——这是建议 换成你已经用的设备。

这就是 VRAM 缺乏超时错误（“TTS generate run for more” 比300多岁……“刷新缓存 / 卸载常驻模型”）指向 。它释放了 内存/显存无需重启应用，且数据永远不会丢失—— 卸载模型在下一代中会懒散地（~8秒）重新装填。

Flush无法解脱的一件事：刚刚超时的工作。一艘被遗弃的 生成不能从Python中终止——其线程运行到完成且 保持显存直到 超时是和设备上还在的作业竞争。等它 排水，或者重启后端，然后冲洗。

有声书和故事章节是例外：被遗弃的章节会 不要再开始一个区块。渲染块结束后，它就停止使用显卡了 退货。一个本身被卡住的区块仍然会保留设备，直到它返回。 每行（跨）在所有区块完成后会被缓存，因此需要重试或恢复 重复使用所有已完成的台词。它只重新渲染被中断的那行。

一个不断完成片段的渲染（长篇生成文本或有声书） 章节）在达到预算时并未被放弃。这会有额外的时间 片段不断涌现，最多是预算的三倍或30分钟，以后为准 更长（#2287）。渲染结果在5分钟内完成任何块，但5分钟内没有完成任何片段 预算依然被放弃。

子工艺发动机卸载在操作保持锁定期间跳过一个侧车，包括发动机开关卸载。一辆待机侧车会立即释放，并在下一次请求时重生。显式关闭仍然是应用退出和失败操作的终止路径。

它分布在哪里：

• 顶部工具栏→“Flush”（型号状态徽章旁边的按钮）。该 下拉菜单列出当前内存中的每个模型——包括TTS模型、其 共载的ASR、降料管道以及任何常驻发动机或 侧车——配备设备和显存功能，以及按型号推出的卸载按钮 其中可以卸载（WhisperX 与 TTS 一起发布 所以它没有自己的按钮）。一台机车在你之后留下了 切换到该轨道时，标注为“非激活——安全卸载”。以下 以下是两种大批量动作：
  • 冲洗缓存——运行多遍垃圾回收并释放 加速器的缓存内存（CUDA/MPS/XPU/NPU）。型号继续存在 已装填，因此没有重新装弹成本;这会恢复缓存/分片 仅限记忆。empty_cache
  • 卸下全部+冲洗——上述加以完全卸载住户 TTS模型。释放最多内存;下一代支付 ~8 S 重新装填。
• 模型目录中的机车权重列表——目前常驻的行显示为 “内存”徽章，带有相同的型号卸载按钮。

从脚本（端口3900的本地API）出发，操作相同：

curl -X POST "http://127.0.0.1:3900/system/flush-memory"                    # flush caches
curl -X POST "http://127.0.0.1:3900/system/flush-memory?unload_model=true"  # + unload TTS model
curl "http://127.0.0.1:3900/model/loaded"                                   # what's resident
# unload one model — ids: tts | diarization | sidecar:<id> | sidecars
curl -X POST "http://127.0.0.1:3900/model/unload/tts"

使用时间：

• 在VRAM不足的503超时后——一个常驻型号和你的生成 争夺GPU内存。卸下所有+冲洗，然后重试。
• 在紧密记忆机上进行配音之前——转录需要空间 驻留TTS模型还在（在Apple Silicon上应用就是这样 自动，见上文）。OMNIVOICE_UNIFIED_OFFLOAD_HEADROOM_GB
• 切换引擎后—— ， 对于侧车发动机，可以保留之前的发动机在内存中;该 下拉菜单显示并标记安全可卸载。OMNIVOICE_SINGLE_ENGINE_RESIDENT=0
• 在小型GPU上进行中期批处理——偶尔在作业间隙中，可以防止缓存增长 让后代挨饿。POST /system/flush-memory

当它无济于事时：许多错误生成的错误并非内存问题， 他们的信息中明确表示（“冲水按钮在这里没用”）—— 缺少环境变量，模型下载过程中网络故障，原生用户损坏 组件。相信这个信息;刷新只会修复内存争用。还有 注意，应用在空闲时已经会自动释放内存 （） — 同花是当你现在需要记忆时用的， 在工作间隙。OMNIVOICE_IDLE_TIMEOUT_S

对于那些和需要大量显存的其他设备共享GPU的机器， 例如本地大型语言模型、游戏或图像模型。设置 → 性能 & 设备→内存管理→ 将语音模型迁移到系统内存 生成（默认关闭; 是否 同样，而且胜过开关）。OMNIVOICE_OFFLOAD_AFTER_GENERATION=1

• 当一代结束且GPU闲置了3秒时，内置的OmniVoice 模型从 GPU 迁移到系统内存。下一代会把它往后移 首先。这需要几秒钟，远比卸载后8秒的装填时间短得多。OMNIVOICE_OFFLOAD_AFTER_GENERATION_GRACE_S
• 当另一代人运行或排队时，任何东西都不会移动，或者在 配音、批量或有声书工作正在进行;在此类工作中，该检查会重复 每10秒，所以模型在工作完成后仍然会移动。一连串 连续世代支付一次搬家费用，而不是每代一次 世代。
• 在 on 时，其融合权重和捕获的 CUDA 图 随移动发布，等模型重新装配GPU时重新组装。 配音版的转录卸载也是同样的效果。OMNIVOICE_FLASHINFER
• 支持NVIDIA（CUDA）、AMD（ROCm）、Intel XPU和Apple Silicon（MPS）。 在 Apple Silicon 上，内存是统一的：此举释放了 GPU 的工作集 其他GPU应用，不是总内存。在CPU上，模型已经存在于RAM中，所以 设置没有任何作用。
• 如果下一代应用开始时，显存已被其他应用取代，那么迁移 背部不灵。该代主机运行在CPU上（较慢，但不是错误），并且 下一个又试了一次。
• 运行在自身进程中的引擎（如IndexTTS）则不然 感动。它们在自己的闲置暂停时释放了记忆 ().OMNIVOICE_SIDECAR_IDLE_TIMEOUT_S

如果超时错误在卸载后仍然持续出现，请参见故障排除第14条——同一饥饿类在该类有更多补救（较小的ASR模型， CPU ASR，即碰撞隔离的ASR引擎）。

• 苹果硅片：所有设备都通过MPS/MLX运行在GPU上。一代人 设计上的时间——统一内存意味着TTS和ASR会争夺相同的资源 而应用会主动卸载其中一个，以腾出空间给另一个，16 GB 机器。更多的内存直接提升了 dub 吞吐量（减少卸载/重载 周期）。
• NVIDIA：fp16 + torch.compile 默认开启。≥16GB 显存并行化 可实现3-4代并发（API/批处理工作负载）;≤10 GB 是故意的 连载。
• 仅用CPU：预计比MPS慢约2倍，对CUDA的表现更差。更倾向于 更小/更快的发动机（参见模型目录）和简短的参考片段。

scripts/bench_pipeline.py（仓库检查） 每个阶段在 a 处进行分析 时间，内存安全——它拒绝在没有足够空闲内存的情况下启动阶段， 并在各阶段之间卸载模型：

# stop the app first — a running backend holds a model and skews numbers
uv run python scripts/bench_pipeline.py            # everything
uv run python scripts/bench_pipeline.py tts clone  # just these stages

如果你报告了性能问题，粘贴它的表格（加上你的平台和 RAM/VRAM）将猜谜游戏变成了一线生平。

每个发动机/设备测量的结果——以及如何贡献你的成果——都存在于 benchmarks.md 中。

CI保护上方的热路径防止回归——而不是靠墙上时钟 预算（CI硬件变化太大，难以稳定地达到“慢5%”的阈值≤）， 但当操作次数预算属于 ，且在任何回归中都失败：tests/test_perf_operation_budgets.py

• 流式TTS（/ws/tts）：每句话只用一个引擎 每个请求恰好一次文本规范化通行（绝不会每请求一次） 句子）。generate
• Dub remix：仅适配的缓存片段 （） 完全没有TTS通话。零解码/零重写预算启动 采用自然速率缓存快速路径（每个缓存被精确解码） 一次，最终组装时）。regen_only=[]
• 配音合成（原生批次）：N个可渲染的段，宽度为W。 在启用本地批处理时，每个段调用成本正好⌈N/W⌉次，且每段调用为零，无论是交互式还是队列作业。generate_batchgenerate
• NLLB配音翻译：目标语言渲染中的行 而是按有界限批量代替一个模型前进一个字幕。混合目标 保留请求顺序，且每行批次重试失败。

更新预算是一种有意为之：如果一项变更合法地增加了 操作到受保护路径，将期望计数在同一PR中更改为 为新地板辩护的评论。绝不要为了让CI通过而放松预算 ——这就是预算存在的目的。

交互式和批量配音在 Select引擎支持。宽度来源于主机，而非 固定，因为更宽的前向通道需要相应数量的设备内存： CPU主机和显卡中，发动机之上剩余空间少于~2 GB的 单一任务要求保持在一个段，宽度则提升到2、4， 以及根据头部空间允许的8个。 覆盖该机制（1 禁用） 批量处理，16是上限）。没有本地批处理的引擎继承了 兼容的备份，保持单段行为。OMNIVOICE_DUB_BATCH_WIDTH

NLLB同样按目标语言分组字幕，并翻译四行 默认情况下，CPU/MPS的前向传递或CUDA上的八个。设置为禁用或明确选择最多32个。OMNIVOICE_NLLB_BATCH_SIZE=1

流式客户端还会在终端帧中接收测量延迟：是请求至第一音频， 端到端的墙钟，包括交付时间，以及合成时间 除以生成音频时长——仅以渲染调用为单位， 所以慢速客户端无法充气。后端日志记录的数值相同，因此慢的第一块是 这与快速的第一段渲染和长渲染区分开来。/ws/ttsdonettfa_msgen_time_srtf

• 删除并重新添加语音并不会加快任何速度;参考文献 编码是按文件缓存的，用于重复使用的语音。（配音的每行引用 剪辑是有意的例外——每个剪辑都是一次性使用的独立剪辑，所以 缓存没有什么可以保存的。）
• 代际间关闭后端会让一切变慢——你 每次都要支付模型负载。闲置超时已经在 它真的是空闲的。
• OMNIVOICE_PRELOAD_TTS_ASR存在于一个遗留的Whisper进程中 后备方案;启用它每次启动都会消耗内存，且不会加速任何速度 默认安装。

对于Studio、Stories或有声书渲染较慢，建议在重启后端前，先从设置→ 关于→保存诊断包中保存诊断包。 包含最近32个已完成或中断的渲染 请求在此后台进程中。同样的紧凑记录也出现在后端 日志。没有任何内容是自动上传的;你可以选择是否共享这个捆绑包。render_traces.json

每条记录都有随机相关的ID、渲染表面、总经过秒数， 传输结果、每级经过秒数、呼叫次数和失败计数：、以及使用时。 脚本、语音名称、文件路径、音频和异常消息从不被记录。 录音机是内存内的，有边界的，并且在所有支持的操作系统上表现相同。synthesisjoineffectssavewatermarkcachemux

时序涵盖完整的 HTTP 响应，包括流式工作和 GPU 池作业。 它们是包容性的壁钟时长：舞台不能重叠或嵌套 加在一起。模型加载、队列、网络等待及其他未安装的程序 工作仍属于总数。 表示HTTP流已完成;溪流可以 仍然包含已处理的生成错误，所以请检查阶段故障和错误 日志也一样。断开连接保持部分时序。后端崩溃会丢失未完成的内存 追踪，所以也附上坠机日志。complete

tests/test_render_trace.py保护100块和400块的Studio/长格式渲染 硬件预算无关：每个区块一个合成，一个组装体， 最后一次录音室效果处理，线性复制采样体积。没有模型下载 或者涉及墙壁时钟速度阈值。这些是对流媒体/配音的补充 预算。tests/test_perf_operation_budgets.py