Repository navigation
Add support for vLLM 0.27.0 and 0.27.1 - #6742
Merged
Merged
Conversation
|
The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update. |
albertvillanova
approved these changes
Aug 14, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Checked the v0.27.0 release notes against the vLLM surface TRL actually uses: No breaking changes for TRL. (v0.27.1 is a patch release with a single change, irrelevant to TRL.)
Relevant
vllm.distributed.weight_transfer, which the experimental async GRPO weight transfer imports β the[2/N]step of the migration tracked in Migrate async GRPO weight transfer to vLLM's stateful engine APIΒ #6732. Nothing breaks: 0.27.1 ships the new statefulfactory.pyalongside the static functions TRL uses, which still resolve unchanged. The deletion step ([4/N]) is unwritten upstream, so this bump doesn't force the migration.vllm configset during weight reload ([Bugfix][RL] Set vLLM config during weight reloadΒ vllm-project/vllm#45989): internal to the reload path, no API change.trl[vllm]at 0.27.x pulls torch 2.13.max_num_partial_prefills/max_long_partial_prefills([Misc] Remove old now unsupportedmax_num_partial_prefillsandmax_long_partial_prefillsΒ vllm-project/vllm#49244): TRL never sets either;trl vllm-servedoesn't expose them./generateendpoint andextract_logprobsare unaffected.also:
transformers>=4.56.2).LLM(...)kwargstrl vllm-servepasses are still valid engine args.Support window
vLLM 0.27.0 was released on 10 Aug 2026 and 0.27.1 on 11 Aug 2026, so on the rolling 5-month window they age out around 10 and 11 Jan 2027. Next scheduled drop is 0.18.0 (released 20 Mar 2026 β out on 20 Aug 2026).
Test results
Run against vLLM 0.27.1 (torch 2.13.0, transformers 5.15.0.dev0), 4ΓH100:
No warnings: the version-range check passes on 0.27.1 with this change applied.
Note
Low Risk
Version-cap and documentation-only changes; no logic changes to vLLM training or serving beyond allowing 0.27.x installs.
Overview
Extends the supported vLLM range from
0.26.0to0.27.1so TRL users can install and run recent vLLM releases without compatibility warnings.The upper bound is updated consistently in
docs/source/vllm_integration.md, thetrl[vllm]extra inpyproject.toml(vllm>=0.18.0,<=0.27.1), andis_vllm_available()intrl/import_utils.py, including the warning text when an installed version falls outside the window. No TRL integration code paths change beyond these version gates.Reviewed by Cursor Bugbot for commit 0b9a0c9. Bugbot is set up for automated code reviews on this repo. Configure here.