下面每个系数都来自我们 2026-11-11 真机合成的一批苏州话音频（110 条，85.08 秒），不是经验值。填你的词条数与平均字数，先算出这批活大概要多久、多大、要补录多少条。
单条时长按实测均值取值：1 字 0.99s（12 条）、2 字 0.72s（67 条）、3 字 0.75s（26 条）、4 字及以上 1.08s（5 条）。重录率按实测 10.4%（单字/双字取 16%，三字以上取 4%，因为失败样本全部落在 1–2 字）。
| 指标 | 实测值 | 说明 |
|---|---|---|
| 样本条数 | 110 条 | 苏州话高频词，覆盖 8 类（吃食 22、时间 18、人称 18、居家 16、问候 10、动作 10、数字 9、穿衣 7） |
| 音频总时长 | 85.08 秒 | 平均 0.773 秒/条 |
| 单条中位数 | 0.48 秒 | 均值被少数长词拉高，中位数才是「典型一条多长」 |
| P90 | 1.97 秒 | 10% 的条目超过这个长度 |
| 最短 / 最长 | 0.27 / 2.98 秒 | 最短是「阿爹」「白露」；最长是「衣裳店」2.98 秒 |
| 时长分布 | <1s 88 条（80%）、1–2s 12 条、2–3s 10 条 | 八成条目在 1 秒内，短词音频库不会有「一条好几秒」的浪费 |
| 文件体积 | 合计 759,510 B，均值 6,904 B | mp3 平均码率 71.4 kbps |
| 首轮失败率 | 12 / 115 = 10.4% | 失败形态是「时长 0.00–0.22 秒」的截断，不是报错 |
| zeroshot 合成速度 | 1.3–2.3 秒/条 | 同一台 GPU、同一参考音、串行 |
首轮 115 个请求，接口全部返回成功，但 12 条音频时长只有 0.00–0.22 秒——它们不是异常，是文本被截断。如果只按 HTTP 状态码验收，这批活会以「100% 成功率」交付，客户第一次点是听不出来的。验收判据必须是时长下限，不是状态码。我们最终是 110 条入册、12 条判废（其中 7 条用指令段加静音切点补回，4 条不硬凑）。
把线程开到 5，总耗时没有下降：请求在同一个模型实例上互相排队，反而增加了超时重试。最终整批是串行跑完的。任何按「并发数」折算工期的排期表，在单机单实例场景下都是假的。
1 字条目平均 0.99 秒，反而比 2 字（0.72 秒）长——模型会给单字补前后静音。同时 12 条失败样本几乎全落在 1–2 字。做方言单字表（很多方言词库就是单字条目）时，工期要按最坏情况估。
全部数据来自一套模型（CosyVoice2-Wu，wuzixu 参考音）、一台 GPU、一种语言（苏州话吴语）、一批短词（1–4 字）。换成普通话、长句、多说话人、或换成云端商用 API，系数会明显不同——长句的时长基本线性于字数，而这里的短词因为首尾静音，反而是「越短越不省」。估算器给的是量级，落地前请先用你自己的 50 条真实文本做一次小样，再乘系数。
本页所有系数与上表同源，可直接取用：dialect-tts-baseline.json。同批音频在苏州话词库页可逐条试听，词库商品本身 3,550 条，演示音频 110 条（音频仅作演示，不含在商品内）。
按实测 1.8 秒/条串行算，约 30 分钟墙钟，产出约 12 分钟音频、6.6 MB mp3；按 16% 补录率还要再跑约 160 条。真正拖时间的不是合成，是人工听验——110 条我们听了两轮。
因为 5 线程实测没有加速。单机单实例的模型推理是串行队列，加线程只是把等待挪到队列里，还多出重试与截断。
能用作量级参考，不能照抄系数。普通话商用 TTS 的短词单条通常在 0.6–1.2 秒，但音色一致性、多音字、儿化音的处理成本另算。方言的真正成本在参考音和字表覆盖，不在合成算力。