12B 延迟验收结论(暂定)

网关全链路实测 · 延迟分解 · 修复与调优 · 暂定新目标

2026-07-10 工具:server/cmd/latencyprobe 分支:feat/12b-latency-probe provider:gummy-realtime-v1(真实)

一、暂定结论(TL;DR)

指标原目标 P95实测(预连接后)暂定新目标
first_partial(按键→首字) <500ms P50 942ms · P95 950ms(极稳定) P95 < 1.2s
release_to_commit(松键→上屏) <300ms 短句 ~170ms · 8s 会话 350~500ms ≤3s 会话 <300ms;长会话 <600ms
为什么 500ms 结构性不可达:first_partial = max(握手, DashScope 音频块阈值 ~850ms) + 推理 ~90ms。 地板是 DashScope 的音频块阈值,与网关代码无关(直连同样 ~1s)。要破地板只能换模型(见第四节)。
体感修正:前导静音实验证明阈值按「音频量」而非「语音量」计——400ms 静音只使 first_partial 推迟 ~100ms。 用户按键后自然停顿 ~300ms 再开口时,从开口算的首字延迟仅 ~640ms,体感优于指标数字。

二、延迟分解(实测)

环节耗时处置
网关预检(限流 / 配额 / 设备槽)~10ms无需优化
DashScope dial + task-started 握手暖 ~130ms · 抖动 60ms~3.7s已消除 spare 预连接(#24)
DashScope 音频块阈值~850ms(地板)换模型才能降(paraformer ~520ms)
推理 + 回传~90ms无手段
final flush(松键后)短句 ~170ms · 8s 会话 350~540ms随内容量增长,属 provider 物理时间

测量口径(对齐桌面端 dictation.rs)

三、本轮落地的修复与优化

#23 stop 后周期 usage 帧抢跑尾部 final(已修,服务端根治)

#24 gummy spare 预连接(已实现)

顺手修复

四、待决策:要不要换 paraformer

gummy-realtime-v1(现用)paraformer-realtime-v2
音频块阈值(首字地板)~850ms~520ms
partial 刷新节奏~1s / 次~500ms / 次(更跟手)
识别质量(单样本 TTS 实测)全对「各自模块的进度汇报」→「各字文案者进入汇报」
partial 时间戳(计量交叉校验用)每条带 end_time仅 final 带
决策前置条件:用 eval 框架(eval/)跑真实数据集对比两模型 WER,再决定是否为 ~300ms 首字收益换质量。 切换成本低:GummyProvider.Model 一行配置。

五、复测方法

# 起服务端(pg/redis 容器已在跑)
cd server && ./run-dev.sh

# 全链路延迟实测(另开终端)
go run ./cmd/latencyprobe -wav /path/to/16k-mono.wav -n 12

# 直连模型对比 / 闲置存活实验
rbw get dashscope-api-key | go run ./cmd/gummycheck -wav xx.wav -pace 100 -model paraformer-realtime-v2
rbw get dashscope-api-key | go run ./cmd/gummycheck -wav xx.wav -pace 100 -idle 60