T3PO 同传延迟忽高忽低，通常不是单一原因，而是两段链路各自贡献了一部分：一段是音频被切成多大的分片、以什么节奏送进去，这一段决定「送入前排队」和「分片边界」带来的抖动；另一段是推理侧的并发数、批处理窗口、排队策略，这一段决定「模型拿到请求后多久返回」。可行的做法是把一次完整链路按时间戳拆开，用同一段音频固定住内容变量，先只改分片，再只改并发，最后才讨论资源或机器。下面给的是能在日志和配置里直接落地的验证动作，字段名都用占位名，实际名称以你环境里的配置为准。
T3PO 同传延迟忽高忽低时，建议先把「延迟」拆成送入前排队耗时与模型推理耗时两段，靠日志时间戳确认抖动落在哪一侧。通常按固定同一段音频、只改分片长度做对照，再确认并发与批处理是否让请求排队，最后连续多跑几次看耗时分布。若单请求、固定分片下仍然抖动，才需要怀疑资源或硬件层面。配置字段名以实际环境为准。
在运行日志里给每个音频分片的送入时刻和返回时刻各打一条时间戳
打点位置要选在「分片已经准备好、但还没进入待处理队列」的地方，记一条送入时刻；在「拿到该分片对应结果」的地方，记一条返回时刻。中间耗时是这两者之差。如果代码结构允许，再补一条「worker 真正取出该分片开始处理」的时刻，这样就能把总耗时切成两段：送入到开始处理是排队时间，开始处理到返回是推理时间。两条时间戳必须带同一个分片标识和分段序号，否则并发下会串片。
下面是一段日志格式示意，字段名和数值只表示结构，不代表你环境里的真实表现：
[frag] frag_id=0031 seg=1 in_ts=1630.412 len_ms=200
[work] frag_id=0031 seg=1 start_ts=1630.455 worker=w2
[done] frag_id=0031 seg=1 out_ts=1630.874 cost_ms=462 queue_ms=43 infer_ms=419看日志时优先比较 queue_ms 和 infer_ms：queue_ms 忽大忽小，说明瓶颈偏向送入节奏、队列堆积或并发抢占；infer_ms 忽大忽小，说明偏向推理侧的批处理、解码长度或资源竞争。这一步不做调整，只做归因。
固定同一段音频，只改分片长度，重复运行做对照
把音频文件固定下来，内容变量就锁住了，剩下能变的就是分片长度和运行时的并发。先只改分片长度，其他配置保持不动，改动前跑一轮，改动后再跑一轮，每轮都用同一段音频、同样的送入节奏。分片长度配置通常是类似下面这样的占位字段，请以实际配置为准：
# 改动前（占位字段名，以实际配置为准）
audio.chunk_ms = 200
# 改动后
# audio.chunk_ms = 400如果分片太短，单位时间内请求条数变多，排队和批处理窗口的影响会被放大；分片太长，单次推理的内容变多，infer_ms 的尾部可能变长。两种方向都可能让延迟看起来「忽高忽低」，所以必须用对照数据判断，而不是凭感觉换一个值。
每轮运行的耗时记录建议按这个表格式填写，一轮至少记 3 次：
run chunk_ms queue_ms infer_ms total_ms 备注
#1 200 ... ... ... 单请求
#2 200 ... ... ... 单请求
#3 400 ... ... ... 单请求检查推理侧的并发与批处理设置是否让请求排队
如果 queue_ms 在日志里明显占大头，或者分片长度对 total_ms 的影响解释不通，下一步就看推理侧。需要确认的配置项通常包括这些，名称以实际配置为准：分片长度或最大分片时长（如 chunk_ms / max_segment_ms）、并发上限（如 max_concurrency / num_workers）、批处理大小与批处理等待窗口（如 max_batch_size / batch_timeout_ms）、队列长度与排队策略、单请求超时与重试设置，以及与解码相关的 beam 或长度上限一类的参数。这些项里任何一项变化，都可能让 batch_timeout_ms 等待时间被算进返回延迟。
判断方法是把并发压到 1：只送一路音频，其他配置不动，跑同一段音频，把 queue_ms 和 infer_ms 记下来，和之前多路并发时的日志对照。单请求下 queue_ms 应该趋近于没有排队意义的量级；如果单请求仍然抖动很大，问题更可能在分片边界不整齐、解码长尾或运行时资源竞争，而不是并发配置本身。注意这一轮只改并发，不要再同时动分片长度，否则两组结果会互相污染。
同一段音频连续跑多次，记录耗时分布而不是只看一次
偶尔一次卡住和稳定劣化，处理方向完全不同。建议在配置固定之后，用同一段音频连续跑 5 到 10 次，每次记录 total_ms，并单独记下最大值和最小值。表格格式可以这样：
run total_ms queue_ms infer_ms
#1 ... ... ...
#2 ... ... ...
...
#N ... ... ...
min/max/差 ... ... ...判断规则可以先用最保守的版本：如果最大值和最小值差距很大，但中位数附近稳定，通常指向偶发抖动，优先查队列堆积和批处理等待；如果多次都整体偏慢，说明是稳定劣化，优先查分片长度、解码长度上限和并发设置是否长期超标。若删掉并发、固定分片后抖动仍在，再考虑资源层面的因素。
根据上面三组结果给出调整顺序：先分片，再并发，最后才谈换机器
一上来就归因硬件，容易把可变配置的问题掩盖掉。建议按下面的顺序走，每一步都有验证方式和停止条件：
- 先调分片。做法是固定音频，只改 chunk_ms 一类的分片长度字段，重复上一节的对照表。验证方式看 total_ms 的分布是否收窄；如果分片长度变化后 queue_ms 和 infer_ms 的抖动都跟着改善，就停在这一步，不再往下改。
- 再调并发与批处理。做法是只改 max_concurrency / num_workers / max_batch_size / batch_timeout_ms 这类字段中的一项，其余不动，再做单请求与多请求的对照运行。验证方式看 queue_ms 是否随并发上升而线性堆积；如果单请求稳定、多请求开始排队，就说明是并发侧扩展问题，优先在并发配置里解决。
- 最后才谈资源或机器。只有当分片固定、并发压到 1、连续多跑仍然整体偏慢或抖动明显时，才值得去查 CPU/GPU 占用、内存换页、容器限额一类的运行时因素。验证方式是保持前面所有配置不变，只换运行环境或资源规格，用同一段音频和同一张记录表对比。
每一步只动一个变量，动完必须能回到上一组记录对照，否则拿到的差异无法归因到具体配置。字段名和默认值都以你实际使用的配置为准，不要照搬示例中的名称。