-
Notifications
You must be signed in to change notification settings - Fork 502
Add nvfp4 attention support for vLLM serving #1898
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
Changes from all commits
ed95794
76976e8
d6d7474
20c4105
70167cb
10b25d1
468b0fb
95f8d9a
cffa4eb
788ee68
dbb2552
d309258
b31bcdb
18718ad
e2b885a
7ec437c
af6b27a
5cf5935
0c6d94d
8db85ec
20e6d33
d771fb8
ea585eb
c4e2146
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We maintain our fake-quantized kernels in modelopt/torch/quantization/plugins/vllm. It looks to me that some of the contents of this file should be moved to either modelopt/torch/quantization/plugins/vllm or modelopt/torch/sparsity/plugins/vllm. This way we can avoid workarounds like This is particularly important because our vLLM fakequant path is used in many places like Nemo-RL. In the current design, fake sparse kernels are not available outside of this example folder. Hence can we please move relevant contents from this folder to modelopt library?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. RB: Can you take a look at my above comment and propose a new design?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
🐝 Looking at the current design and the surrounding vLLM plugin code now.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I agree with the direction in your comment. I would make the example worker a thin consumer of library APIs and move the reusable serving path into the vLLM plugins. Proposed shape:
That gives Nemo-RL and other vLLM fakequant users an importable ModelOpt path, and the example becomes just a reference for wiring it into vLLM worker lifecycle.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agreed. I'll have a refactor for the orchestration (layer discovery, validation, and the module.impl swap) and it should live in the vLLM plugins, with a supported activation entry point so NeMo-RL and others don't have to copy the worker. |
Uh oh!
There was an error while loading. Please reload this page.