执行摘要
- 一句话：bge-m3 插件统一使用
embed&token_classify 任务处理所有 pooling 请求，简化代码并弃用多任务支持。
- 推荐动作：此 PR 值得精读，展示了如何在服务限制下重构插件逻辑，学习设计权衡和简化策略，对于工程师理解多任务弃用背景有价值。
功能与动机
根据 PR #35829 中的讨论，模型服务实例在启动时仅支持一个 pooling 任务配置。因此，为支持 bge-m3 模型的 dense、sparse 和 dense&sparse 模式，插件需统一使用 embed&token_classify 处理所有请求，并根据请求中的 embed_task 返回相应嵌入，这是弃用多任务支持的一部分。
实现拆解
修改了 sparse_embeddings_processor.py 文件中的 merge_pooling_params 和 post_process 函数。在 merge_pooling_params 中，删除了根据 embed_task 设置不同任务的逻辑，统一设置为 embed&token_classify；在 post_process 中，简化了 embed_dimensions 的计算，移除条件判断，确保始终计算嵌入维度。
关键文件：
tests/plugins/bge_m3_sparse_plugin/bge_m3_sparse_processor/sparse_embeddings_processor.py（模块 plugins/bge-m3）: 核心变更文件，修改了任务分配和后处理逻辑，直接影响 bge-m3 插件的行为。
关键符号：merge_pooling_params, post_process
评论区精华
讨论集中在插件必要性、性能开销和过滤逻辑。DarkLight1337 提问如果用户只需求单一嵌入类型，插件是否必要并导致不必要的 tensor transfer；staugust 解释 v2 runner 限制，用户需通过不同实例请求。noooop 评论过滤逻辑已存在，暗示变更合理。最终结论是设计权衡以简化服务架构。
- 插件必要性和性能开销 (design): 设计权衡以简化服务架构，变更合理，用户需适应新工作流。
- 过滤逻辑验证 (correctness): 确认变更正确性，后处理逻辑能正确处理 dense、sparse 和混合请求。
风险与影响
- 风险：主要风险是性能开销：插件总是计算两种嵌入并可能进行不必要的数据传输，尽管后处理会过滤。兼容性风险较低，但用户工作流改变（需通过多个实例）可能引起混淆，测试已通过未发现回归。
- 影响：对用户，需调整使用方式，通过多个 vllm 实例请求不同嵌入类型，增加了部署复杂度但简化了单个实例配置。对系统，减少了插件逻辑复杂性，降低了潜在 bug 风险。
- 风险标记：性能开销, 兼容性风险
关联脉络
- PR #35829 未知（从讨论中提及）: 在 PR #35829 中讨论了模型服务实例只支持一个 pooling 任务，这是本 PR 的动机来源。
参与讨论