[WoosukKwon]

Overview

Draft / preview. This PR removes Model Runner V1 (MRV1). MRV2 is already the default. MRV1 was only reached through an explicit VLLM_USE_V2_MODEL_RUNNER=0 or by falling back for features MRV2 lacks. This PR deletes MRV1 together with the code that existed only for it. Features that only worked on MRV1 are dropped rather than ported. Dual Batch Overlap is kept and now runs on MRV2 by default.

Test cleanup is still in progress and will follow in a separate commit on this branch.

Claims

• Runner deleted: gpu_model_runner.py (7.2K lines), gpu_input_batch.py, gpu_ubatch_wrapper.py, cpu_model_runner.py, the KV/EC connector runner mixins, and the V1 BlockTable.
• V1-only code deleted:
  • The V1 spec-decode proposers (vllm/v1/spec_decode/{eagle,dflash,draft_model,ngram*,suffix_decoding,custom_class_proposer,...}.py) and their Triton kernels.
  • The V1 sampler and rejection sampler.
  • The V1 custom logits-processor API (vllm/v1/sample/logits_processor/). vllm.v1.worker.gpu.sample.logits_processor is now the only interface.
  • cpu_triton_utils and the CPU kernel overrides.
• VLLM_USE_V2_MODEL_RUNNER and VllmConfig.use_v2_model_runner removed. Every V1/V2 branch in config, worker, scheduler, warmups, models and connectors now takes the V2 path. The scheduler no longer emits prev_step_scheduled_req_ids, all_token_ids or resumed requests for V1.
• Dropped features. These now raise, or the option is gone:
  • suffix and custom_class speculative methods, plus the suffix_decoding_* fields
  • use_heterogeneous_vocab (TLI)
  • disable_padded_drafter_batch
  • parallel_drafting outside dflash/dspark (P-EAGLE, PARD)
  • pipeline parallelism with external_launcher
  • Triton ReplaySSM
  • pooling tasks outside the MRV2 set
  • NGramPerReqLogitsProcessor (DeepSeek-OCR)
  • vLLM on CPU without Triton: only x86 has triton-cpu, so this covers Arm, POWER and s390x
• DBO: the env gate that pushed --enable-dbo onto MRV1 is removed. Combinations DBO still doesn't support raise an error.
• Docs, examples and requirements: the suffix and PARD docs, the V1 logits-processor design doc, and the V1 logits-processor examples are removed. arctic-inference is dropped from the test requirements.

Validation

• Import smoke test of the touched core modules (config, workers, scheduler, engine, elastic EP, warmups, models): OK.
• End-to-end with Qwen/Qwen3-0.6B on 1x GB200, with and without ngram spec decode: greedy outputs are identical and sensible.
• ruff check / ruff format on all touched files: pass. pre-commit passes, except that pip-compile-xpu was skipped for the commit. Run on its own, that hook is clean with no changes.
• Not run yet: the test suite, model evals, and CI. This is a preview.

Details

Open questions for reviewers:

1. CPU without Triton. Removing MRV1 removes the only runner that worked without Triton. Is it acceptable to drop non-x86 CPU support, or does it need a Triton-free path in MRV2 first?
2. Dropped speculative-decoding features (suffix, custom proposer class, TLI, P-EAGLE/PARD). Do we land this before any of them are ported to MRV2, or wait?
3. Deprecation. Should VLLM_USE_V2_MODEL_RUNNER=0 give a targeted error for a release? Today it is just an unknown env var.

Follow-ups not included here:

• Removing CachedRequestData.resumed_req_ids / all_token_ids, which are now always empty, and the connector branches that read them.
• Further pruning of shared modules (vllm/v1/spec_decode/utils.py, mamba_utils.py, kda_metadata._mamba_get_block_table_tensor).
• Dropping "V2" naming (GPUModelRunner lives under vllm/v1/worker/gpu/).

---

Pull Request Checklist

• I used vLLM's /pr-checklist skill. (Mandatory for agents, optional for humans).

• AI assistance was used during the creation of this PR.

• Design Fit: Minimizes impact on core components, reuses existing functionality, and justifies added complexity.

• Testing and Validation: Validates the change and ensures any added tests are meaningful and reliable, with CI coverage or documented CI resource constraints and validation performed outside CI.

• Code Quality and Style: Keeps code and comments clear and concise, and updates relevant documentation and examples.

• Pull Request Contents: Includes a brief summary and relevant links, supports claims with evidence, explains root causes and implementation trade-offs, and follows the contributing guide.

🤖 Generated with Claude Code

[mergify]

Documentation preview: https://vllm--63373.org.readthedocs.build/en/63373/

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @WoosukKwon.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[belonghim]

Thanks for the preview. A question from an out-of-tree platform before this lands.

vllm-openvino ships its own worker and model runner (OpenVINO executes the model). It cannot use Triton, which is incompatible with OpenVINO, so it runs on MRV1. Of what it imports from vllm.v1, this PR removes InputBatch/CachedRequestState, the V1 Sampler/SamplingMetadata, NgramProposer and apply_grammar_bitmask (WorkerBase, bind_kv_cache, outputs and the scheduler/KV-cache types stay). Their MRV2 counterparts (worker/gpu/input_batch.py, block_table.py, sample/gumbel.py, sample/penalties.py, ...) are Triton kernels, so we cannot move to MRV2 either.

#61995 lets CPU backends without Triton override MRV2 components with PyTorch implementations, but this PR drops "vLLM on CPU without Triton".

1. Are non-Triton implementations of the MRV2 input batch and sampler still planned (via [CPU][MRv2] Enable MRv2 for non-triton CPU backends #61995 or a similar override)? Or is Triton a hard requirement for vllm.v1.worker.gpu?
2. If it is, should out-of-tree platforms keep their own copies of the input batch and sampler, and will there be a stable interface for them?

Context: #57684 (same question, still open), #58703 (parked until this removal plan).