[Bugfix][RL] Set vLLM config during weight reload

[aoshen02]

Summary

RL weight updates re-run layer post-processing after model initialization.
Those paths may call get_current_vllm_config(), but the worker reload APIs did
not establish the config context, causing an assertion failure on the FP8 MoE +
DeepEP path.

This PR wraps the stable worker-level reload boundaries with
set_current_vllm_config():

• regular reload_weights
• RL start_weight_update, update_weights, and finish_weight_update
• draft-model weight updates

V1 and the default V2 runner both use these worker entry points. The context is
scoped to each synchronous operation and restored afterward.

Lifecycle investigation

We audited when VllmConfig is first consumed, when it can change, and why the
same config-dependent code is reached again during reload.

Initial model load

1. VllmConfig.__post_init__ validates the configuration and derives startup
   settings.

2. GPUWorker.load_model enters set_current_vllm_config(self.vllm_config).
   initialize_model also scopes the model constructor, so modules can read the
   current config without threading it through every constructor.

3. Initial weight post-processing builds quantized kernels. For the affected
   MoE/EP path, V2 then calls:

   prepare_communication_buffer_for_model(model)
     -> EP communicator.prepare_communication_buffer_for_model
     -> MoE.maybe_init_modular_kernel
     -> maybe_make_prepare_finalize
   

   Some quantization paths create the modular kernel directly from
   process_weights_after_loading; both initial paths are still inside the
   outer GPUWorker.load_model config scope.

4. Startup may subsequently update the live config: auto-fit writes
   model_config.max_model_len, KV-cache initialization writes
   cache_config.num_gpu_blocks, and compilation/CUDA-graph settings are
   finalized during startup. By engine-ready time, these values are available
   on the same VllmConfig instance.

After initialization

Normal inference mostly consumes the finalized config. The explicit exceptions
we found are:

• update_config, which can replace model_config or load_config; V2 keeps
  self.vllm_config synchronized. There is no default internal production
  caller—the interface is triggered explicitly by an integration/RPC or tests.
• Elastic EP / dynamic DP reconfiguration, which updates parallel configuration.
• Reloading from an explicit weights_path, which updates
  model_config.model to that path.

The RL paths covered by this PR—weights_iterator and the weight-transfer
engines—do not modify VllmConfig.

Why reload still needs the context

Although RL reload does not change the config, it deliberately re-enters code
normally associated with initialization:

Worker.update_weights
  -> weight transfer engine.receive_weights
  -> model.load_weights
  -> layerwise _layerwise_process
  -> quant_method.process_weights_after_loading
  -> rebuild MoE kernel / maybe_make_prepare_finalize
  -> get_current_vllm_config

Regular reload_weights similarly runs initialize_layerwise_reload,
model.load_weights, and finalize_layerwise_reload. Any current or future
quantization/layer post-processing reached from those hooks may legitimately
need the worker's live config.

This is why fixing individual get_current_vllm_config() call sites is fragile:
the repository has many constructor and post-load consumers, and new consumers
can be added later. Establishing the context once at the reload boundaries makes
the already-finalized, live worker config available to the entire operation
without copying fields into every subsystem or keeping a process-global context
active permanently.

Tests

• .venv/bin/python -m pytest tests/v1/worker/test_gpu_worker_weight_transfer.py -q
  (7 passed)
• pre-commit run --files vllm/v1/worker/gpu_worker.py tests/v1/worker/test_gpu_worker_weight_transfer.py
  (all hooks passed, including ruff and mypy)

Duplicate-work check

This updates the existing fix in #45989 rather than opening another PR. Searches
for open PRs covering the same config-context failure found no duplicate; the
other weight-reload PRs address different problems.

AI assistance

OpenAI Codex was used to help investigate, implement, and test this change. The
human submitter is responsible for reviewing every changed line and defending
the change end-to-end.

[aoshen02]

[mergify]

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

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

[aoshen02]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. 👍

Reviewed commit: cf606d5a2b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".