Skip to content
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

[Core] Make encoder-decoder inputs a nested structure to be more composable #9604

Merged
merged 29 commits into from
Nov 5, 2024

Conversation

DarkLight1337
Copy link
Member

@DarkLight1337 DarkLight1337 commented Oct 23, 2024

This PR updates encoder-decoder inputs: from a flat schema that inherits from decoder-only inputs with additional encoder-* fields, to a nested structure with separate encoder and decoder components.

With separated encoder and decoder components, it becomes easier to support input embeddings for decoder-only models first in #6869.

Copy link

👋 Hi! Thank you for contributing to the vLLM project.
Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run fastcheck CI which starts running only a small and essential subset of CI tests to quickly catch errors. You can run other CI tests on top of those by going to your fastcheck build on Buildkite UI (linked in the PR checks section) and unblock them. If you do not have permission to unblock, ping simon-mo or khluu to add you in our Buildkite org.

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 do one of these:

  • Add ready label to the PR
  • Enable auto-merge.

🚀

@DarkLight1337 DarkLight1337 added the ready ONLY add when PR is ready to merge/full CI is needed label Oct 23, 2024
@DarkLight1337
Copy link
Member Author

DarkLight1337 commented Oct 23, 2024

@heheda12345 PTAL at the changes to mllama processor to ensure that the semantics remain the same. I can successfully run the example script, so it's probably fine.

@heheda12345
Copy link
Collaborator

@DarkLight1337 I've verified that test_mllama.py is successful, and the input of MllamaForConditionalGeneration.forward does not changed, so I think this pr does not change the behavior of mllama.

@DarkLight1337
Copy link
Member Author

To unblock the next steps, @robertgshaw2-neuralmagic @njhill can you review this?

Copy link
Member

@njhill njhill left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @DarkLight1337, looks good

vllm/sequence.py Outdated
Comment on lines 437 to 440
if inputs["type"] == "token":
return inputs.get("prompt")

return cast(Optional[str], self.inputs.get(prompt_key))
assert_never(inputs)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason to not write these like this? (which is clearer imo)

    assert inputs["type"] == "token"
    return inputs.get("prompt")

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's to reduce diffs when introducing #6869 which adds a new inputs["type"] == "embed" branch.

vllm/model_executor/models/mllama.py Outdated Show resolved Hide resolved
vllm/model_executor/models/mllama.py Outdated Show resolved Hide resolved
vllm/inputs/preprocess.py Outdated Show resolved Hide resolved
Comment on lines +326 to +329
if encoder_inputs["type"] == "token":
pass
else:
assert_never(encoder_inputs)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Presumably this is needed for static type checking and this wouldn't suffice?

assert encoder_inputs["type"] == "token"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See my first comment.

Copy link

mergify bot commented Oct 30, 2024

This pull request has merge conflicts that must be resolved before it can be
merged. @DarkLight1337 please rebase it. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

@mergify mergify bot added the needs-rebase label Oct 30, 2024
@mergify mergify bot removed the needs-rebase label Oct 31, 2024
@DarkLight1337
Copy link
Member Author

@njhill I have finished addressing your comments.

Copy link
Member

@njhill njhill left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DarkLight1337 DarkLight1337 merged commit bbc3619 into main Nov 5, 2024
60 checks passed
@DarkLight1337 DarkLight1337 deleted the refactor-preprocessing branch November 5, 2024 02:07
DarkLight1337 added a commit that referenced this pull request Nov 5, 2024
JC1DA pushed a commit to JC1DA/vllm that referenced this pull request Nov 11, 2024
sumitd2 pushed a commit to sumitd2/vllm that referenced this pull request Nov 14, 2024
KuntaiDu pushed a commit to KuntaiDu/vllm that referenced this pull request Nov 20, 2024
mfournioux pushed a commit to mfournioux/vllm that referenced this pull request Nov 20, 2024
tlrmchlsmth pushed a commit to neuralmagic/vllm that referenced this pull request Nov 23, 2024
sleepwalker2017 pushed a commit to sleepwalker2017/vllm that referenced this pull request Dec 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready ONLY add when PR is ready to merge/full CI is needed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants