Whisper API 价格与计费（2026）：时长、并发与成本控制

语音转写的账单看起来只和“音频有多长”有关，实际总成本往往由更多因素叠加：无效静音、高码率文件、失败重试、切分重叠、重复提交、存储保留，以及转写后的人工校对。

本文不写固定单价，因为价格会调整，不同模型和不同网关的口径也不一样。更重要的是理解计费结构和成本动因，具体单价请以站内模型价格为准。

说明：OpenAI、Whisper 是其权利人的商标，本文仅作技术说明，与 OpenAI 无隶属关系。各模型的计费单位、可用地域和限制可能变化，请以官方文档和站内价格页为准。本文不含具体报价。

一、计费的基本单位是音频时长

传统 whisper-1 按提交音频的分钟数计费。较新的 gpt-4o-transcribe 系列按音频输入、输出 token 计费，价格页通常同时给出等效的每分钟估算；gpt-transcribe 等新模型的计价方式也在演进。

无论按分钟还是按 token，计费依据都是“提交上去的音频长度”，不是“其中有效说话的长度”。片头片尾、长时间静音、会议中场休息，都可能进入计费。控制成本的第一条原则是：上传前先裁掉不必要的声音。

二、文件大小与格式如何影响账单

官方接口的单文件上限是 25 MB，支持 mp3、mp4、mpeg、mpga、m4a、wav、webm。大小限制会间接影响成本：

高码率 wav 体积大，长音频更容易超限，切分次数更多。
文件越大，上传越慢，超时和重试概率越高。
格式不兼容会直接失败，白白消耗请求和排查时间。
转码本身通常不计入 API 账单，但会消耗服务器和存储资源。

统一转成 16 kHz 单声道 mp3 或 wav，通常能在可接受的质量下显著缩小体积。压缩前先确认业务能接受音质损失，涉及方言、专有名词时保留更高码率。

三、哪些操作会悄悄放大成本

成本项	是否进入 API 账单	控制方法
音频时长	是	去静音、裁片头片尾、只提交有效段落
失败重试	可能重复计费	限制重试次数，记录请求结果
切分重叠	是，重叠部分会被重复转写	重叠控制在 0.5–1 秒，合并时去重
转码与存储	通常不计入 API 账单	设置生命周期规则，及时清理
出网流量	视服务商与架构而定	同区域处理，避免反复下载
人工校对	不计入 API 账单	抽样校对、词表替换、分级审核

最常见的浪费不是单价，而是重复劳动：同一段音频因为超时被提交三次，或者为了拿时间戳把整段重新转写一遍。

四、重试、超时与重复计费

网络超时不代表服务端没有处理。请求已经计费但客户端没收到结果，重试就会产生第二次费用。工程上要做三件事：

用文件哈希或业务单号做幂等键，成功结果落库复用。
限制最大重试次数，例如三次，并使用指数退避。
只对 429、5xx 和超时重试；400、401、413 这类错误重试没有意义。

批量任务还要设置合理的连接超时和读取超时。超时太短会把正常的长音频判死，超时太长会拖住队列。

五、长音频切分与并发策略

超过 25 MB 的音频必须切分。切得越碎，请求数越多；切得越粗，失败重试的代价越大。可以按下面的顺序处理：

用 ffprobe 统计每个文件的时长和码率，先估算总分钟数。
统一转码为 16 kHz 单声道，控制单段体积。
优先按静音切分，其次按 10 分钟固定切分。
记录每段偏移量，合并时回填时间轴。
并发控制在账户限流以内，观察 429 比例再调整。
合并后去重，并对切点做抽样校对。
把实际提交分钟数与账单核对，找出异常。

并发本身不会改变按量单价，但会影响重试率和总时长。并发拉满导致大量 429，再叠加退避重试，通常比稳一点更贵。

六、存储与出网容易被忽略

音频文件、转写结果、日志和备份都会产生存储成本，其中音频体积最大。建议按业务分级：

原始音频：转写完成后保留一段可回溯期，到期删除或转冷存储。
转写文本：按项目保存，敏感内容加密并限制访问。
请求日志：不记录完整音频 URL 和密钥，保留必要的请求 ID。
备份：只备份结果，不重复备份原始音频。

如果音频和转写服务不在同一区域，上传和下载会产生出网流量。把处理流程放在离存储更近的区域，能减少这部分开销。

七、怎么做预算估算

不要用一个拍脑袋的单价乘总时长。更稳的估算公式是：

月成本 ≈ 有效音频分钟 × 单价 × 重试系数 + 存储与流量 + 人工校对

其中重试系数可以用实际监控数据估算，例如请求成功率是 97%，就要为失败部分留出余量。下面这段脚本只读取时长和单价，不写死价格：

import os, subprocess, json

UNIT_PRICE = float(os.environ["AUDIO_UNIT_PRICE"])  # 从价格页获取，元/分钟
files = ["meeting-01.mp3", "meeting-02.mp3"]
total_minutes = 0.0

for path in files:
    out = subprocess.check_output([
        "ffprobe", "-v", "error", "-show_entries", "format=duration",
        "-of", "json", path,
    ])
    total_minutes += float(json.loads(out)["format"]["duration"]) / 60

estimate = total_minutes * UNIT_PRICE * 1.1  # 预留重试与重叠
print(f"音频 {total_minutes:.1f} 分钟，预估 {estimate:.2f}")

预算还要加上存储、转码服务器、人工校对和开发维护。只比较 API 单价，容易低估总拥有成本。

八、上线后的对账与价格跟踪

按项目或 Key 拆分用量，避免所有业务混在一个账单里。
每周导出一次用量，和内部提交的音频分钟数对比。
对差异超过阈值的项目排查：重复提交、异常重试、切分参数错误。
设置预算告警，用量接近上限时提前处理。
关注模型和价格更新，切换前先用真实样本比较效果与成本。

价格会变，模型也会变。把单价配置化，不要写死在代码里；每次调价只需要更新配置并重跑一次估算。

常见问题

Whisper API 是按分钟还是按 token 计费？

whisper-1 按音频分钟计费；较新的 gpt-4o-transcribe 系列按音频输入、输出 token 计费，价格页会给出等效分钟估算。以站内模型价格和官方文档为准。

静音部分也会计费吗？

通常按提交的音频长度计费，静音也可能算进去。上传前做静音裁剪是最直接的成本控制手段。

失败重试会不会重复收费？

如果服务端已经处理了请求，只是客户端超时，重试可能产生第二次费用。用幂等键复用成功结果，并限制重试次数。

并发越高越省钱吗？

不会改变单价，也不一定缩短总成本。并发过高会触发 429，重试和排队反而增加时间与费用。

为什么文章不写具体价格？

音频模型价格调整频繁，不同网关的计价口径也不同。写死数字容易过期，按站内价格页估算更可靠。

下一步

先注册中商起航 AI 网关，用短音频跑通转写，统计真实分钟数后再做预算。模型与最新价格以模型价格为准。