[Bug]: Batch runner misclassifies a successful diarized transcription as streaming

快速结论：当你在 vLLM 的离线 batch runner（如 vllm.entrypoints.llm）里对音频输入启用说话人分离（diarization）时，带说话人轮次元数据的成功转写结果会被误判为流式请求，从而抛出 Request must not be sent in stream mode。优先排查 batch runner 对 TranscriptionResponseDiarized 这类成功响应类型的分类逻辑，而不是模型或显存问题。

适用环境：Issue 中确认的环境为 Ubuntu 22.04.5 LTS、Python 3.12.14（Anaconda）、PyTorch 2.13.0+cu130、CUDA 13.0、4 张 NVIDIA L40S、Nvidia 驱动 595.71.05、cuDNN 8.9.7、AMD EPYC 9554。以上为报告者环境，非复现最低要求。

最快修复方案：升级到包含 #57948 修复的 vLLM 版本。该 PR 把规范的转写响应联合类型（TranscriptionResponseVariant）纳入 batch runner 的成功响应判断，使成功的 diarized transcription 被当作非流式成功处理，并覆盖了直接模型路径和 JSON 响应路径的回归测试。

注意事项：Issue 讨论中曾提出在 is_streaming_response 或 batch 完成屏障里检查 request_output.finished 的改法，但那只是讨论中的建议方向，并非最终合入的修复内容；不要据此手改本地源码。修复涉及响应分类，不涉及 kernel 或 scheduler 改动。

问题场景

用户通过 vLLM 的离线批量推理接口（vllm.entrypoints.llm）处理音频输入，并启用了说话人分离（diarization）。此时模型会成功产出带说话人轮次（speaker-turn）结构化元数据的转写结果，这些元数据以分块形式输出。但 batch runner 在判断输出类型时，把这种已完成的批量任务误识别为“未关闭的流式请求”，于是本应成功的请求被当成流式模式发送，触发报错。

报错原文

[Bug]: Batch runner misclassifies a successful diarized transcription as streaming

Request must not be sent in stream mode

原因分析

最可能的原因：batch runner 在 run_batch.py 中维护了一份“成功响应类型”的联合（AllResponse），但该联合没有包含 diarized transcription 的成功响应类型 TranscriptionResponseDiarized。当输出对象不在已知的成功响应集合内，同时又带有分块生成特征（例如被 isinstance(output, AsyncIterator) 之类的检查命中）时，runner 就会把已完成的批量任务归类为 streaming，最终报出 Request must not be sent in stream mode。讨论中建议的修复方向是复用规范的转写响应联合类型 TranscriptionResponseVariant，让 diarized 成功响应落入非流式成功分支。

环境排查

确认 vLLM 版本是否已包含 #57948 的修复；Issue 未给出具体受影响版本号。
确认调用路径是离线 batch runner（vllm.entrypoints.llm），而不是 Online Serving 或 streaming API。
确认请求确实启用了 diarization（说话人分离），因为报错只在 diarized transcription 成功返回时出现。
按 Issue 环境核对 Python 3.12、PyTorch 2.13.0+cu130、CUDA 13.0、cuDNN 8.9.7 等依赖；但这些只是报告者环境，并非触发条件本身。
确认输出是否被送入流式序列化路径，以及 batch 完成屏障是否已基于 request_output.finished 判断（后者为讨论建议，非合入修复）。

解决步骤

先确认当前是否处于“离线 batch + diarization + 成功转写”这一组合场景，排除网络、鉴权或模型加载类错误。
检查所装 vLLM 是否已包含 #57948；该 PR 已将 diarized transcription 的成功响应加入 batch runner 的响应联合，并补了回归测试。
如果版本较旧，升级到包含该 PR 的版本，而不是自行在 run_batch.py 或 llm.py 中打补丁。
如果暂时无法升级，可优先尝试：在业务侧确认输出确实为已完成的 RequestOutput（finished 为真）后再做后续处理，避免把成功的 diarized 结果重新送回流式接口；但这属于规避思路，Issue 未验证其有效性。
若升级后仍复现，在 Issue 或新 issue 中提供最小复现脚本、diarization 开关、输入音频特征与完整 traceback，便于定位是否还有未覆盖的转写响应类型。

验证方法

升级到包含 #57948 的版本后，用同一段音频、同一 diarization 配置重新跑离线 batch 推理：原本报 Request must not be sent in stream mode 的请求应正常返回带说话人轮次元数据的转写结果，不再被归类为 streaming。PR 中已覆盖直接模型路径和 JSON 响应路径两类回归测试，可通过运行对应测试确认修复生效。