-
-
Couldn't load subscription status.
- Fork 10.8k
[Refactor][Frontend] Keep all logic about reasoning into one class #14428
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
👋 Hi! Thank you for contributing to the vLLM project. 💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels. Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging. To run CI, PR reviewers can either: Add 🚀 |
|
/cc @alex-jw-brooks |
|
I hope this can be merged after PR #14202 is finalized, as there might be some conflicts. I’m happy to resolve those conflicts directly in this PR. I’ll wait for @alex-jw-brooks to confirm if this approach works. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that this is strictly frontend, I think we should keep it under entrypoint.
Thanks for your review. It’s used in |
hmm, thinking more about this, it is probably ok to add a |
|
This pull request has merge conflicts that must be resolved before it can be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some small comments, and a rename preference to vllm.reasoning, otherwise LGTM.
examples/online_serving/openai_chat_completion_with_reasoning.py
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, final round of review. just final few thoughts
| force: bool = True) -> None: | ||
| def _register_module( | ||
| cls, | ||
| module: type, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| module: type, | |
| module: type[Any], |
? or does it take in a type variable ? iirc we can also pass in a generic type here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is copied from the tool parser https://github.com/vllm-project/vllm/blob/main/vllm/entrypoints/openai/tool_parsers/abstract_tool_parser.py#L99
Should we change it too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's do it in a separate PR then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I created an issue to keep track. #15658
| cls, | ||
| module: type, | ||
| module_name: Optional[Union[str, list[str]]] = None, | ||
| force: bool = True, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: This seems to be the strict behaviour. I would prefer renaming this variable to strict here.
also iiuc this is internal anyways, should we just make it strict by default?
I dont' really see the reason for user overriding this any time soon (given that we are maintaining this anw)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: for register_module I think would be nice if we can transform the target class into a dataclass, so that we can enforce start_token and end_token string
And setup start_token_id and end_token_id accordingly based on the vocab
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto. This is copied from the tool parser, maybe we could have another PR to change both of them?
| start_token_id: int | ||
| end_token_id: int | ||
|
|
||
| start_token: str = "<think>" | ||
| end_token: str = "</think>" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
above for logics.
Signed-off-by: Ce Gao <cegao@tensorchord.ai>
|
@DarkLight1337 @mgoin @simon-mo Could you please help merge this? |
|
The entrypoints test timed out. Could we merge it manually? |
…llm-project#14428) Signed-off-by: Ce Gao <cegao@tensorchord.ai> Signed-off-by: xinyuxiao <xinyuxiao2024@gmail.com>
…llm-project#14428) Signed-off-by: Ce Gao <cegao@tensorchord.ai> Signed-off-by: Louis Ulmer <ulmerlouis@gmail.com>
…llm-project#14428) Signed-off-by: Ce Gao <cegao@tensorchord.ai>
…llm-project#14428) Signed-off-by: Ce Gao <cegao@tensorchord.ai>
…llm-project#14428) Signed-off-by: Ce Gao <cegao@tensorchord.ai> Signed-off-by: Mu Huai <tianbowen.tbw@antgroup.com>
…llm-project#14428) Signed-off-by: Ce Gao <cegao@tensorchord.ai>
This is a quick refactor to get us ready to tackle a few issues like #14399, #14170, #14335, #14511, #14429 and #14490
Right now, we’ve got two separate abstractions of handling reasoning—one for OpenAI chat and another for structured outputs.
But if we want to fix #14399, which involves adding checks for reasoning tokens in the stopChecker, we’d probably end up with even more abstractions.
To keep things clean and avoid a mess, we’re merging these into one unified approach.