工程版本日志 · 2026.08
从尾延迟问题到实时转写路径
长录音暴露了停止后尾延迟：单独压缩 GPU 推理不会自动带来实时体验。这篇报告定义目标 SLO 和分阶段交付路径；它是生产设计与阶段实验记录，不是已完成的全量生产验收。
01 · THE SYMPTOM
批量路径把主要工作留到“停止之后”
当完整音频在停止时才上传，ASR、最终校正和 AI 整理就会串行堆叠。这条路仍适合旧客户端、长文件和流式会话失败时的显式降级，但不能继续作为主体验。
Electron microphone→Streaming gateway→Warm ASR→Incremental polish02 · LATENCY BUDGET
先定义用户感知，再优化局部跑分
目标是首个 partial p50 250ms、更新节奏 p50 200ms、停止后 final ASR p95 500ms、Fast Polish p95 700ms，以及停止到文字交付 p95 1.5s。
这些是发布预算，必须由真实请求的 p50/p95/p99 与浸泡测试证明，不能用单次 GPU 耗时替代。
03 · PROGRESSIVE ASR
分段识别负责及时，停止时只修正不稳定尾部
当前生产路径统一使用停顿感知的 SenseVoice 分段识别。录音期间持续生成 partial 和 stable 片段，停止时只收口未稳定尾段，而不是重新解码整段录音。Paraformer 已因英文和中英混说质量问题退出生产路由。
稳定分句在录音期间已送入 Fast Polish；最终请求只携带不稳定尾部与少量不可变上下文。
04 · FALLBACK
降级必须显式、幂等且有上限
- 旧客户端和流式会话失败可回退到 POST /api/transcribe。
- 降级原因必须进入遥测，整段重试不超过一次。
- 可疑短文本保留并标记，不触发无上限的再推理。
- AI 超过 700ms 截止时间时，立即交付可靠 ASR 文本。
05 · RELEASE GATE
还需要生产控制面和 1,000 次浸泡测试
发布前需要常驻网关、Redis/Postgres、至少两个 ASR replica，并通过 1,000 请求浸泡测试。验收不仅看延迟，还必须没有重复文字、语言翻转和 final 片段丢失。
证据 · 诊断
现有证据能说明什么，不能说明什么
根因不是某一个模型慢，而是旧路径把上传、ASR、AI 和粘贴全部放在停止之后串行执行。新路径把录音期与停止后的工作拆开：录音期间生成稳定片段，停止时只收尾，AI 失败时优先交付可靠 ASR。
运维 · 开放工作
失败时如何退化，以及下一道验证门槛
仍需证明并发下的排队时间、网关背压、会话恢复和副本摘除。当前单节点可以验证体验，但不能代表已经完成多副本、高可用生产验收；报告中的 250ms、500ms 与 1.5s 是预算线，只有持续遥测达到后才转为已验证结果。
- 失败可见性
- 每次降级都必须记录原因码和阶段计时。最终拿到文字，不能抹掉实时、AI 或粘贴此前失败的事实。
- 发布证据
- request ID、实际模型、节点、排队、上传、ASR、AI 和交付时间必须保存在同一条可追踪链路中，才能完整复盘回归。