文本转语音 按字符 计费

做语音合成的开发者常常在第一次对账时卡住：明明只转了几段文字，账单里的字符数却比原文长一截。问题多半不在单价，而在「什么算一个字符」以及重复调用怎么算。这篇按字符计费的速查指南，帮你把计数口径、省钱动作和排查顺序理一遍。

做语音合成的开发者第一次对账时最容易懵：明明只转了几段文案，账单里的字符数却比原文长一截。问题往往不在单价，而在「什么算一个字符」和重复调用怎么算这两件事上。先把计数口径摸清楚，再谈省钱，顺序反了会白折腾。

这篇按字符计费的速查指南，按四个方向理一遍：一个字符怎么数、哪些调用路径会重复计费、怎么把字符量压下来、对账时按什么顺序排查。每节都给可执行动作，不讲空概念。

先搞清「一个字符」到底怎么数

不同平台对字符的定义差别很大：有的按 Unicode 码点算，有的按 UTF-8 字节算，有的把标点、空格、换行全计入。中文一个字和英文一个字母是否等价，必须在官方计费说明里逐条确认。具体某家当前的口径，到 /official-api 找到对应平台的规则页核对当时的说明。

• 控制语句算不算字符：SSML 标签、停顿标记、音色切换标记这类内容，各家口径不同，写脚本前先查清楚，否则标记会白白吃掉预算
• 数字和缩写会被展开：日期、金额、单位在合成前通常展开成完整读法，实际计费长度大于代码里的字符串长度
• 别用 len(text) 估算成本：不同语言的 len 结果和平台计费单位不是一回事，尤其混排文本差异更大
• 换行与空白保留策略：预处理阶段删掉的空白，如果没在计费前生效，照样计数

哪些调用路径会被重复计费

字符被算两遍，多数不是平台乱扣，而是调用路径本身触发了两次计费。搞清哪些路径会重复，比抠单价更有效。下面这几类要单独列进成本模型。

失败重发

同一次请求失败后重发，字符算一遍还是两遍，要看计费落在请求受理端还是合成成功端，属于要单独确认的条款

流式被打断

流式合成中途断开，已经播出的部分通常仍会计费，不能按没听完就不算来估

批量与实时

两种接口的字符计价口径可能不同，批量上线前先确认规则

平台侧缓存

有的平台对命中缓存的内容不计或减计，用之前先问清楚命中条件

缓存是省字符的关键一刀。同一段固定文案，比如欢迎语、报错提示、条款播报，做本地缓存或平台侧缓存，能直接砍掉重复计费的部分。判断标准很简单：这段文字会不会在短期内被反复请求，会就缓存，不会就别加复杂度。到 /official-api 对照当年的价格与规则说明时，把缓存是否计费这一条单独确认。

什么时候缓存策略不适用：文案本身带实时变量（用户名、余额、时间戳）时，缓存命中率会很低，强行做缓存反而增加维护成本，这时应该考虑拆分静态与动态部分分别处理。

把字符量压下来的几个动作

1. 拆静态与动态把可复用的固定文案抽出来单独生成音频，只对动态字段做实时合成，验证方式是统计动态字段占总字符的比例，比例低说明拆得值
2. 长文本分档不是所有内容都需要高保真合成，背景播报、辅助说明类内容可以走更省的方式，先给内容分级再决定合成路径
3. 文本预处理去掉多余空白、控制符号、重复标点，这些在计费上都是真金白银，预处理后长度要和原文长度对比一次
4. 多语种折算确认多语种场景先确认各语种的字符折算规则是否一致，混排文本容易被按最贵的口径计，拿一小段混排文本实测

• 固定文案全部走缓存，别每次重新合成
• 动态字段尽量短，能用 ID 就不用长名称
• 长文本先摘要再合成，别整篇直转
• 标点做规范化，重复标点合并
• 上线前用真实样本跑一遍计费长度，而不是靠估算

对账与排查顺序

对账最怕一上来就翻账单。按固定顺序排查，能把问题锁在具体环节，而不是对着差额猜。下面这个顺序从文本侧排到账单侧，依次往下走。

日志里要把重试单独标出来，别和正常调用混在一起统计。差额集中在哪个接口、哪个时间段，基本就能定位问题。需要追历史数字时，到 /price-watch 看当时的变动记录，比凭记忆复盘靠谱。

这套顺序不适用于用量极小的场景：如果一个月就几百次调用，人工逐条核对的成本比省下来的钱还高，直接看账单总额有没有异常跳变就够了。