V1 embeddings

[maxdebayser]

Description

This PR enables embedding models on vllm V1. In contrast with the V1 GPU implementation, here I added a separate model runner because for most of the embedding models there is no need for continuous batching. To avoid code repetition, I refactored the input batch and model runner classes into a class hierarchy with common base classes.

@gmarinho2 contributed a test that verifies that the returned embeddings don't change with batch size.

[github-actions]

👋 Hi! Thank you for contributing to vLLM support on Spyre.
Just a reminder: Make sure that your code passes all the linting checks, otherwise your PR won't be able to be merged. To do so, first install the linting requirements, then run format.sh and commit the changes. This can be done with uv directly:

uv sync --frozen --group lint --active --inexact

Or this can be done with pip:

uv pip compile --group lint > requirements-lint.txt
pip install -r requirements-lint.txt
bash format.sh

Now you are good to go 🚀

[maxdebayser]

All tests are passing now after the changes from the first round of reviews.

[yannicks1]

From my side this looks good! I have one small things apart from the tiny merge conflicts @maxdebayser will solve in within seconds:)

IMO we have 1 or 2 files too many in vllm_spyre/v1/worker. It looks cluttered with the three input batch related .py files. Upstream they only have one file for input batches per accelerator (e.g. GPU, TPU). Looking at the number of lines in e.g. the gpu_input_batch.py (760 lines) we could put all the content of vllm_spyre/v1/worker/spyre_base_input_batch.py, vllm_spyre/v1/worker/spyre_input_batch.py and vllm_spyre/v1/worker/spyre_pooling_input_batch.py into one file (called spyre_input_batch.py) and have around 800 lines. Another option would be to put the base class vllm_spyre/v1/worker/spyre_base_input_batch.py into vllm_spyre/v1/worker/spyre_input_batch.py, similar as we have the model runner base class in vllm_spyre/v1/worker/spyre_model_runner.py and not a separate file for this.

[yannicks1]

Also hoping for @joerunde to give this a final pass (as it is a really big refactoring) and merge once he is back:)

[wallashss]

I think it should be nice to update docs/supported_features.md

[wallashss]

I'm pretty sure that this method is not being used and, I was wondering if the tensors related to that like token_type_ids_cpu_tensor are being used as well. I mean, I could find it being populated, but not being read if I did the reading correctly.

[maxdebayser]

Yes, this is to prepare for changes that haven't been merged upstream yet. I can remove these to simplify the PR for now.

[wallashss]

LGTM! Thanks for the refactoring of input batch, it makes sense to me.

Just a friendly reminder: update docs/supported_features.md