[Bugfix][Router] use model_type instead of model_label

[max-wittig]

As model_label is already used for
things related to the LMCache. It
makes more sense to use the type of
the model here.

Replaces #681

---

• Make sure the code changes pass the pre-commit checks.
• Sign-off your commit by using -s when doing git commit
• Try to classify PRs for easy understanding of the type of changes, such as [Bugfix], [Feat], and [CI].

Detailed Checklist (Click to Expand)

Thank you for your contribution to production-stack! Before submitting the pull request, please ensure the PR meets the following criteria. This helps us maintain the code quality and improve the efficiency of the review process.

PR Title and Classification

Please try to classify PRs for easy understanding of the type of changes. The PR title is prefixed appropriately to indicate the type of change. Please use one of the following:

• [Bugfix] for bug fixes.
• [CI/Build] for build or continuous integration improvements.
• [Doc] for documentation fixes and improvements.
• [Feat] for new features in the cluster (e.g., autoscaling, disaggregated prefill, etc.).
• [Router] for changes to the vllm_router (e.g., routing algorithm, router observability, etc.).
• [Misc] for PRs that do not fit the above categories. Please use this sparingly.

Note: If the PR spans more than one category, please include all relevant prefixes.

Code Quality

The PR need to meet the following code quality standards:

• Pass all linter checks. Please use pre-commit to format your code. See README.md for installation.
• The code need to be well-documented to ensure future contributors can easily understand the code.
• Please include sufficient tests to ensure the change is stay correct and robust. This includes both unit tests and integration tests.

DCO and Signed-off-by

When contributing changes to this project, you must agree to the DCO. Commits must include a Signed-off-by: header which certifies agreement with the terms of the DCO.

Using -s with git commit will automatically add this header.

What to Expect for the Reviews

We aim to address all PRs in a timely manner. If no one reviews your PR within 5 days, please @-mention one of YuhanLiu11
, Shaoting-Feng or ApostaC.

[max-wittig]

Let me know, what you think about this @zerofishnoodles

[zerofishnoodles]

Do we actually need model type here? Wouldn't model name itself be enough since we know which model is for transcription when querying.

[max-wittig]

@zerofishnoodles Not sure I can follow here. How do we know which model name is capable of transcription?

E.g. we're using whisper-large-v3-turbo, but there are others.

[zerofishnoodles]

I mean when we query we would specify the model name which means we have already known the model is capable of something. You wouldn't query llama for transcription. Unless we want one model to serve specific task, in that case If we really want to add another annotation for that, I would say model_task is more suitable since transcription is not a model type.

[max-wittig]

ahhh you're right. I made #712 so that we can focus on that. Do we still want the model types for the other Kubernetes based discovery modes?

We're not using it, but I guess it would be useful. Right now the real healthcheck just works for the static service discovery.

[zerofishnoodles]

Yeah I guess we can do that and it will be helpful. Currently we only use /health to inspect the health. If we want to do that, I think we need to add some readme or tutorials so that people know they need to have label on it. Speaking of that, we may also need to modify the helm chart since pod level label is not supported right now.