执行摘要

本PR将多模态处理器返回的原始字典重构为类型化的MultimodalProcessorOutput数据类，通过在AsyncMMDataProcessor.process()中集中转换，保持30+处理器实现不变，提升代码类型安全和可维护性。基准测试显示性能无影响（Δ<0.02%），变更对用户透明，是SGLang多模态模块的重要内部改进。

功能与动机

动机源于改善代码类型安全，替代无类型的字典接口。PR body中明确指出：“Introduce MultimodalProcessorOutput dataclass in schedule_batch.py as a typed replacement for the raw dict returned by multimodal processors”，旨在减少潜在运行时错误、增强代码可读性，并为未来多模态功能演进提供坚实基础。

实现拆解

• 核心数据类定义：在python/sglang/srt/managers/schedule_batch.py中新增MultimodalProcessorOutput数据类，包含mm_items、input_ids、im_token_id等字段，并提供了from_dict静态方法用于向后兼容。
• 集中转换策略：在异步多模态数据处理器（如AsyncMMDataProcessor.process()）中添加从字典到数据类的转换逻辑，作为单一漏斗点，确保所有处理器输出统一类型化。
• 消费者代码更新：更新40个文件中的多模态输入访问方式，例如在scheduler.py中将MultimodalInputs.from_dict(raw_mm_inputs)改为MultimodalInputs.from_processor_output(raw_mm_inputs)，在tokenizer_manager.py中将mm_inputs["input_ids"]改为mm_inputs.input_ids。

评论区精华

Review讨论为空，但Issue评论中yhyang201提到：“python/sglang/srt/managers/async_mm_data_processor.py will be removed.”，这暗示了未来可能的相关文件清理，但未在PR中引发争议。整体变更无重大设计辩论，顺利合并。

风险与影响

• 风险：主要风险集中在第三方处理器兼容性，若返回字典格式不匹配可能导致转换失败；但PR通过from_dict方法保持了向后兼容性。核心路径变更虽经基准测试验证无性能回归，但仍需确保测试覆盖以防止遗漏更新。
• 影响：性能影响极小（基准测试显示req/s和tok/s变化在0.02%以内），用户无感知；系统内部类型安全显著提升，减少潜在bug；开发团队需适应新接口，但变更集中且文档清晰，维护成本降低。

关联脉络

与此前多模态相关PR如#21230（LFM2-VL支持）和#22038（VLM优化）一脉相承，共同推进SGLang多模态处理的类型化和性能优化。这些PR显示团队正逐步将松散的多模态数据管理统一为类型化系统，为未来功能扩展（如DeepSeek集成）奠定基础。