同一个朗读功能，有时几百毫秒返回，有时要等好几秒，先不要急着换模型、调参数或加缓存。更有效的做法是：先在客户端把一次调用拆成几个明确的时间点记录下来，再用固定文本、固定并发做对照，看波动到底跟着谁走。TTS 类接口的耗时通常由三部分叠加：网络建连与传输、服务端排队等待、以及真正按文本生成音频的处理时间。这三段混在一个“总耗时”里时，任何调整都只能靠猜；拆开之后，多数情况下能直接看到某一段占了绝大部分波动。
合成延迟忽高忽低时，先量化再归因：在请求前、收到响应头、收到首个音频字节、结束四个点打点，按小时统计分位值而不是平均值；用固定文本、固定并发各跑若干次做对照，只改一个条件。若服务端未返回排队或处理耗时字段，这一段只能标为未知，不能摊派到网络或文本长度上。
在请求前后打点记录完整耗时分布
没有分段数据时，“有时快有时慢”只是主观感受，改方案也验证不了效果。建议在发起合成请求的代码里固定打点，至少记录：发起时间、收到响应头的时间、首个音频字节时间、结束时间，以及服务端返回体或响应头里自带的耗时字段（若接口有）。同时带上请求 ID、文本字数、模型名、并发批次，方便和服务端日志对齐。
import json, time, uuid, logging
def tts_call(session, url, headers, payload, text):
rid = uuid.uuid4().hex[:12]
t0 = time.perf_counter()
r = session.post(url, headers=headers, json=payload, stream=True, timeout=60)
t_head = time.perf_counter() # 收到响应头
first = None
for chunk in r.iter_content(4096):
if first is None:
first = time.perf_counter() # 首个音频字节
t_end = time.perf_counter()
logging.info(json.dumps({
"rid": rid,
"chars": len(text),
"model": payload.get("model"),
"status": r.status_code,
"head_ms": round((t_head - t0) * 1000, 1),
"ttfb_ms": round(((first or t_head) - t0) * 1000, 1),
"total_ms": round((t_end - t0) * 1000, 1),
"server_timing": r.headers.get("server-timing", ""),
"body_meta": r.headers.get("x-request-id", "")
}, ensure_ascii=False))示例里的 URL、请求头、payload 字段和响应头名称都是占位，需要替换成你实际接入的参数；如果接口没有流式输出，首字节时间就约等于整包返回时间，此时 ttfb 与 total 的差值没有意义，应在日志里标注。
汇总时不要只看平均值。建议按小时分组，算出每组的 p50、p90、p99 和最大值，平均耗时会被少量慢请求掩盖，而 p90 抬升往往才是用户能感知到的“卡”。按小时看还能对照业务侧的访问高峰，判断波动是否与时段相关。
把总耗时拆成网络、排队和服务处理三段
打点数据有了之后，下一步是给每一段找到可测量的证据，剩下测不出来的部分明确写“未知”，不要凭经验摊派。
| 分段 | 测量方式 | 判断标准 |
|---|---|---|
| 网络段 | DNS、TCP、TLS 建连耗时（HTTP 客户端钩子，或先用 curl -w 在同类机器上测一次作参照） | 建连稳定但收到响应头很晚，说明时间不在链路上；建连本身就抖，先查本地出口、DNS 解析和连接复用 |
| 排队段 | 优先用服务端返回的排队或等待字段；没有该字段时，只能用“收到响应头时间减去建连耗时”做近似，并在日志中标记为 approx | 同等文本下，收到响应头的时间随并发数上升而明显变长，通常指向排队或限流 |
| 服务处理段 | 服务端返回的处理耗时、音频时长字段；没有字段时看首字节到结束的增量 | 文本变长时这一段近似线性增长属于预期；文本不变却大幅波动，才是异常 |
| 未知部分 | 以上都拿不到的差值 | 单独记一列 unknown_ms，不要并入任何一段 |
需要提醒的是，客户端打点只能证明“时间花在哪一段的外部表现上”，不能直接等价于服务端内部原因。比如排队段变长，可能是你这一侧的并发太高被限流，也可能是服务整体负载变化，需要结合返回码（是否出现 429 之类的限流响应）和请求 ID 去服务端日志里确认。
固定文本长度和并发数做对照实验
对照实验的关键是每次只改一个条件，否则结果无法归因。建议准备两段文本：一句短句（十来个字）和一段中等长度段落（几百字），在同一台机器、同一时段、同一网络环境下分别跑若干次，建议每档不少于 10 次，记录每一次而不是只记一个平均。
| 组别 | 文本 | 并发 | 次数 | p50_ms | p90_ms | 最大_ms | 备注 |
|------|------|------|------|--------|--------|---------|------|
| A1 | 短句 | 1 | 10 | | | | |
| A2 | 长段 | 1 | 10 | | | | |
| B1 | 短句 | 4 | 10 | | | | |
| B2 | 长段 | 4 | 10 | | | | |执行顺序建议是：先做 A1，确认单请求本身是否稳定；再做 A2，看文本长度带来的增量是否符合预期；然后做 B1、B2，观察并发上升后 p90 是否明显抬高。对比 A1 与 A2 时并发必须相同，对比 A1 与 B1 时文本必须相同，中间不要顺手改超时时间、连接池大小或重试策略，否则测出来的差异说不清来源。
如果 A1 的 p50 与 p90 差距很小，而 B1 明显变大，通常是并发导致排队；A1 稳定但 A2 的绝对耗时上升且波动比例接近，多半是文本长度本身；A1 自己就忽高忽低，则要先回到第一小节的日志，确认是不是建连或 DNS 在抖。
按排查顺序表逐项排除并给出结论
下面的顺序是从外部到内部、从便宜到费时，按列逐项走完再下结论，避免同时改多处。
| 步骤 | 动作 | 判断依据 | 下一步 |
|---|---|---|---|
| 1 网络出口 | 在同地域的另一台机器上重跑 A1 组；用 curl -w 看建连与首字节 | 建连稳定、首字节也稳定，说明链路不是主因 | 进入第 2 步；若建连抖动明显，先查 DNS、连接复用和本机负载 |
| 2 并发数 | 固定文本，从 1 并发升到你线上实际并发，逐档记录 p50 与 p90 | 单请求稳定、并发升高后 p90 抬升，通常指向排队或限流 | 看返回码是否出现限流；考虑在客户端做并发上限与短暂退避 |
| 3 文本长度 | 固定并发，用短句和长段落各跑若干次 | 耗时随字数增长但波动比例小，属于预期范围 | 对长文本做分段合成或提前生成，属于产品侧取舍 |
| 4 服务返回信息 | 收集请求 ID、返回码、响应头里的耗时字段，与服务端日志对齐 | 排队字段偏高或出现限流返回，说明瓶颈在服务侧调度 | 调整调用节奏或与接口方确认配额，不要靠客户端重试硬扛 |
走完这四步，通常会落到三种情形之一：波动主要集中在网络段，需要处理连接复用和出口稳定性；主要集中在排队段，需要控制并发与重试节奏；与文本长度近似线性相关，则属于正常预期，只需在产品上对长文本给出更长的等待提示。任何一段如果拿不到服务端字段，就在日志和结论里明确标注为未知，并说明后续需要服务端配合补充哪些信息，而不要用一个推测值把表格填满。