执行摘要

本PR修复了Nemotron-Nano-VL多模态模型中因音频预提取导致的崩溃问题，允许在vllm serve时传递use_audio_in_video参数。通过静态解析参数和优雅处理无音频视频，提升了模型稳定性和性能，但review中指出的异步I/O性能问题仍需后续优化。

功能与动机

根据Issue #39124，当音频在chat completions endpoint预提取时，use_audio_in_video参数未正确注入音频占位符，导致AssertionError。PR旨在修复此崩溃，并扩展参数传递能力以优化初始化流程，避免每请求实例化HF处理器的开销。

实现拆解

• 模型层（vllm/model_executor/models/nano_nemotron_vl.py）：
  • _extract_audio_from_videos方法现在返回(mm_items, audio_items, has_audio)三元组，其中has_audio掩码标识视频是否有音频流，并捕获异常优雅处理无音频情况。
  • apply方法使用mm_config.merge_mm_processor_kwargs静态解析use_audio_in_video参数，选择性执行音频提取和占位符注入。
• 处理器层（vllm/transformers_utils/processors/nano_nemotron_vl.py）：添加use_audio_in_video参数到__init__，支持在初始化时配置。

评论区精华

• 性能设计：gemini-code-assist[bot]指出同步fetch_audio在异步上下文中可能导致事件循环饥饿，建议使用asyncio.to_thread，但此问题在PR中未解决。
• 减少开销：netanel-haber强调应减少get_hf_processor使用以避免竞争和性能开销，PR通过静态解析参数采纳了此建议。
• 代码优化：netanel-haber提供简化提示重建的代码建议，如使用zip(..., strict=True)，作者可能已部分采纳。

风险与影响

• 风险：同步I/O在异步上下文可能引发性能瓶颈；修改核心音频提取路径增加回归风险；参数传递方式改变可能影响现有集成配置。
• 影响：用户端修复崩溃提升体验；系统端优化参数解析减少开销，但异步问题未解可能限制高并发性能；团队需关注后续测试和性能优化。

关联脉络

本PR与Issue #39124直接相关，修复相同bug。从历史PR看，#38388（多模态张量相等性修复）和#39268（多模态内存泄漏测试）表明vLLM在多模态模块持续改进，本PR是这一趋势的一部分，专注于音频视频处理的稳定性和性能优化。