[Bug] MOSS-Transcribe-Diarize 在配置 131K 上下文和 65K 最大输出后，40 分钟音频仍被提前截断

感谢开源！

[Bug] MOSS-Transcribe-Diarize 在配置 131K 上下文和 65K 最大输出后，40 分钟音频仍被提前截断

问题概述

使用 SGLang Omni 部署 OpenMOSS-Team/MOSS-Transcribe-Diarize 时，转写 40 分钟音频会在输入结束前数分钟停止。

服务返回 HTTP 200，响应中的输入时长也是完整的 2400 秒，但生成的转写内容在中途结束。使用两段互不相关且语音密集的音频都可以复现，因此问题不像是由某个特定音频的静音或文件损坏造成的。

从现象看，调用链路中可能仍有接近 16K 的输出 token 上限，但当前配置的 max_new_tokens 已经是 65536。这里的 16K 只是根据多次结果作出的推测，尚未通过服务返回的 token 用量直接确认。

运行环境

• 模型：OpenMOSS-Team/MOSS-Transcribe-Diarize
• SGLang：0.5.12.post1
• SGLang Omni commit：f916b86cb324f21d479e798ad36e2a992cfd010a
• Python：3.12
• GPU：单张 NVIDIA H20，显存约 96 GiB
• 启动日志显示的 KV Cache 容量：691777 tokens

启动命令

HF_HUB_OFFLINE=1 TRANSFORMERS_OFFLINE=1 \
/path/to/sgl-omni serve \
  --model-path /path/to/MOSS-Transcribe-Diarize \
  --port 8000 \
  --max-running-requests 8 \
  --cuda-graph-max-bs 8 \
  --mem-fraction-static 0.80 \
  --stages.asr.factory_args.context_length=131072 \
  --stages.asr.factory_args.max_new_tokens=65536 \
  --log-level debug

启动时打印的合并配置可以确认这两个参数已经被解析：

factory_args:
  context_length: 131072
  max_new_tokens: 65536
server_args_overrides:
  max_running_requests: 8
  cuda_graph_max_bs: 8

请求方式

curl http://127.0.0.1:8000/v1/audio/transcriptions \
  -F model="OpenMOSS-Team/MOSS-Transcribe-Diarize" \
  -F file="@40min_16k_mono.wav" \
  -F response_format="verbose_json" \
  -F temperature="0" \
  -F max_new_tokens="65536"

ASR stage 已经配置 max_new_tokens=65536，请求中也显式传入了相同的值，但转写仍然被截断。

复现结果

两段输入音频的时长都是 2400 秒，格式均为 16 kHz、单声道，并且在返回结果的截断点之后仍然包含语音。

输入	HTTP 状态	请求耗时	响应分段数	文本字符数	最后完整时间戳	未转写音频长度
录音 A	200	103.25 秒	526	39,526	2079.36 秒	320.64 秒
录音 B	200	94.92 秒	447	44,489	2133.63 秒	266.37 秒

录音 B 的最后一个完整分段结束于 2133.63s，原始响应的 text 字段停在一个未完成的时间戳标记中：

...[213

返回的 JSON 本身可以正常解析，但其中的转写内容不完整。

音频尾部验证

对录音 B 从 2133.63s 到 2400s 的未转写部分进行了独立检查：

• 平均音量：-26.5 dB
• 最大音量：-8.2 dB
• 参考转写在截断点之后覆盖约 251.14s 的语音
• 截断点之后的参考文本包含 4,842 个字符和 17 个源分段

因此，模型并不是因为剩余音频静音或缺失而停止生成。

预期行为

当 context_length=131072 且 max_new_tokens=65536 时，服务应当完成整段 2400 秒音频的转写。如果命中了其他长度限制，API 至少应该返回明确的长度限制结束原因或错误，而不是把不完整的结果作为正常响应返回。

实际行为

• 请求返回 HTTP 200。
• 响应报告的输入时长为 duration: 2400.0。
• 根据音频内容密度不同，转写在约 2080 至 2134 秒处停止。
• 原始文本可能在时间戳标记或句子中间结束。
• 转写响应没有提供生成 token 数或 finish_reason。

希望确认的问题

1. 音频转写路由、请求参数模型、pipeline stage 或 SGLang sampling parameters 中是否存在默认的 16384 生成上限？
2. /v1/audio/transcriptions 是否会把 max_new_tokens 传递到 MOSS 转写 stage 及最终的 SGLang sampling parameters？
3. 是否还需要其他参数，才能将实际输出上限提高到 16K 以上？
4. 转写响应是否可以增加 finish_reason 和生成 token 用量，以便区分长度截断与模型正常输出 EOS？

如有需要，我可以进一步提供 debug 日志或可公开复现的音频样本。

Start at the /v1/audio/transcriptions route and trace how its request parameters reach the MOSS transcription stage and final SGLang sampling parameters. Reproduce the 40-minute case with the supplied command, then inspect whether an unreported generation limit causes the cutoff. Done means identifying the effective limit and ensuring truncation is distinguishable from normal EOS, with tests or a reproducible verification.