C7.15.1Per-request duration and token limits设计研究
单次语音识别请求通常存在时长或字数上限
别名: 识别上限 · max utterance length · 请求超时
概念解释
一次识别请求不是无限长的音频管道。服务和端上模型都给时长或字数上限：常见是几十秒到一两分钟，或一段最大 token 数。超过上限就不在这次请求的合同里。听写和会议录制若当无限流来设计，会撞上这条硬边界。
机制
流式解码器的状态、注意力窗、计费和滥用防护都按请求计。长音频的内存和延迟线性或超线性涨，云端还要防止开着麦克风挂机。端点检测不能替代上限：用户可以一直说、一直有声，检测器不封口，计时器仍会到。唤醒后的聆听窗是交互超时；这里是识别引擎对单段音频的容量。两者可以同时存在：窗先到就停采，容量先到就拒收或切断。上限对用户往往不可见，直到被切断才发现。
怎么研究
用递增时长的口述测量：在宣布的上限附近和超过处，请求是成功、切断还是报错。记录是否提前警告。比较不同 API 和端上模型的实际上限与文档是否一致。不要只用短命令语料，那永远碰不到上限。
边界
真正的流式会议转录会切成重叠的滑动窗，表面上没有“一次请求”的墙，但每一窗仍有长度。本地永不上传的引擎上限可以更宽，仍受内存限制。按键说话的按住时间若短于引擎上限，用户先碰到的是手指疲劳。把所有长语音失败都叫网络问题，会漏掉 60 秒封顶这种产品决策。
怎么落地
- 在听写开始前或接近上限时提示剩余时长，不要静默切断。
- 产品文档写出秒数或字数，开发接口与界面使用同一上限。
- 用超过上限的音频做验收，确认行为是可理解的失败而不是无声丢数据。