always use embed&token_classify for bge-m3

[staugust]

Purpose

As discussed in #35829 (comment) , model serving instance only serves one pooling task set at starting point. Hence, for bge-m3 with dense, sparse, dense&sparse mode, this plugin use embed&token_classify for all pooling requests, and return dense, sparse, dense&sparse according to embed_task configured in the request.

This is part of deprecate support for multi-task.

Test Plan

plugins_tests/test_bge_m3_sparse_io_processor_plugins.py

Test Result

All tests are passed.

---

Essential Elements of an Effective PR Description Checklist

• The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
• The test plan, such as providing test command.
• The test results, such as pasting the results comparison before and after, or e2e results
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.
• (Optional) Release notes update. If your change is user facing, please update the release notes draft in the Google Doc.

[gemini-code-assist]

Code Review

This pull request refactors the bge-m3 sparse embedding processor to consistently use the embed&token_classify task for all pooling requests. This simplifies the logic in merge_pooling_params by removing conditional task assignments. Correspondingly, the post_process method has been updated to always calculate embed_dimensions, ensuring correct slicing of the model's output to extract dense and/or sparse embeddings as requested. The changes align with the stated purpose of supporting a fixed model serving configuration and appear to be implemented correctly.

[staugust]

@noooop PTAL, thanks.

[DarkLight1337]

If the user only wants to use one type of embeddings, is it necessary for them to use the plugin? If it's necessary, then this would result in some unnecessary tensor transfer since you always return both dense and sparse embeddings.

[staugust]

@DarkLight1337 Not only unnecessary tensor transfer, but also unnecessary gpu computation for both dense&sparse if user only want dense or sparse embeddings. v2 runner only support one pooling task at starting point. Thus, for dense embedding, user shall call v1/embeddings for dense embedding with another vllm instance where pooling task set to embed. And for sparse embedding, call /token_classify with a vllm instance where pooling task set to token_classify. For dense&sparse, vllm instance must set pooling task to embed&token_classify, I do not think those unnecessary tensor transfer and gpu computation can be avoid by this plugin, it's all inside vllm core engine.

[noooop]

In previous versions, users could request dense, sparse, or dense & sparse. Now, suppose only the ‘dense & sparse pooler’ is used to implement these features. I assume there should be some filtering code, but I couldn’t find it. Could you please explain how these features are currently implemented?

[noooop]

Thanks!