`build_draft_tp_worker` built a `ServerArgs` variant whose only job was to make
four config reads answer with the draft's backend instead of the target's, and
published it for the duration of the build so the bags agreed. The backend is a
per-runner fact — target and draft coexist in one process — so it moves onto the
runner, and the variant and the construction-time publish both go away.
`ModelRunner` takes `draft_attention_backend` and resolves the runner's effective
value once (`resolve_draft_attention_backend`: the algorithm's resolved backend,
else `--speculative-draft-attention-backend`, else None for a target runner);
`TpModelWorker` threads it to both runner constructions.
`resolve_attention_backend_strs` reads it off the runner, and `ModelRunner`
stamps the resolved pair *before* building backends so a backend can read it
while it constructs — which is what the FlashInfer KV-access check needs now that
it no longer asks the config. `configure_kv_cache_dtype` and the draft backend
factory read the runner too.
One latent bug falls out: the non-hybrid branch of the backend build ignored the
resolved pair and re-read `server_args.attention_backend`, which is why the
variant had to set that field as well as the split pair. It now uses the value
that was resolved for the runner.
`draft_server_args_overrides` and the `preserve_config()` publish switch are
deleted; with them goes the last production `ServerArgs.derive` outside
pre-publish config building, and the last construction-time publish. The
chunked-prefix gate the target resolved simply stays in the bags, since nothing
re-projects them.
The v2 spec workers got a published `ServerArgs` copy carrying two values: the
target's context length and `--speculative-draft-load-format`. Neither is a
process-wide config change — each is consumed by exactly one constructor — so
the copy, the publish switch around the draft build, and the replay of the
target's resolved overrides onto it all go away, and the values travel to the
runner that owns them:
- **Context length.** `TpModelWorker` already takes it (`context_length=None`
keeps `server_args.context_length`); the four v2 draft workers and
`build_draft_tp_worker` pass the target's, which every one of them has in
scope as `target_worker` / `target_model_config`.
- **Load format.** `ModelRunner._draft_load_format()` resolves it for a draft
runner and `build_load_config` takes it, so the `LoadConfig` is per-runner.
Model code also reads it off the bag while it builds — Inkling replaces
per-element noise in its shared-expert scales under dummy loading — so the
load is wrapped in a scoped bag override that puts the target's value back.
- `skip_tokenizer_init` was on the copy for nobody: `TpModelWorker` already
short-circuits the tokenizer for a draft worker (`or self.is_draft_worker`).
`PrefillCudaGraphRunner._max_addressable_prefix_len` capped the prefix by
`server_args.context_length`, which the copy used to carry for the draft; it now
reads the runner's own `model_config.context_len`. That is also more accurate for
the target, whose `--context-length` may be unset while the resolved context is
shorter than the token table.
What stays a variant is the dflash/dspark path's attention backend: backend
selection reads it off the config object the draft runner holds, and the
resolved gate has to survive the variant's publish. `draft_server_args_overrides`
now carries only those fields and says why.
`ServerArgs.override(source, **fields)` was the last way to change a resolved
`ServerArgs` in place. Every remaining call-site was one of two things, and
neither wanted an in-place write:
- **A config for someone else.** A draft worker's context length, an encode
worker's device, the compile script's watchdog, the client's port pick, a test
fixture's backends. These already deepcopied first — the write was on the copy.
- **A launcher-stage resolution.** `resolve_auto_parsers` detected the chat
template's parsers and wrote them back, to be inherited by the schedulers it
spawns.
Both are "one config becomes another", so `derive(source, **fields)` returns the
variant and leaves the receiver — and any bags projected from it — untouched. It
deliberately is not `dataclasses.replace`: resolution does not re-run, because
the values being set are decided after it, from inputs it never had. Provenance
and the resolvable-field stash work as before, on the copy.
`resolve_auto_parsers` now computes the parsers and returns the config to launch
with; the detection helpers stop taking a config to mutate. `HiMambaRadixCache`
re-applied a HiCache layout normalization `__post_init__` already performs (the
same duplicate removed from `UnifiedRadixCache` in ebb1c88d23) and just goes.
With no in-place mutation left, `ServerArgs.__setattr__` raising after
resolution *is* the guarantee, so the textual writer ratchet retires and
`test_server_args_derive.py` pins the contract instead: the receiver survives
deriving, the published instance still refuses assignment, and deriving does not
publish. `SGLANG_STRICT_CONFIG_MUTATION` was already unused — the guard has been
unconditional since the mutation sweep — and goes with it.
The detection tests drop their `SimpleNamespace` stand-in for a real
`ServerArgs`; the test kit and the MLA chunk-metadata fixture publish a derived
variant instead of writing the runner's published config.
`init_tokenizer_manager` wrote the chat-template-detected `reasoning_parser` /
`tool_call_parser` onto the published `ServerArgs`, after
`TokenizerManager.__init__` had already projected the config bags — so the
namespace readers and the resolved-config readback disagreed with the instance,
and a second `Engine` in the same process would inherit the first one's
detection through the shared bags.
Detection is per-engine control-plane state, which the manager already models:
`record_config_updates` records it, the readback endpoints overlay it, and
`config_value` reports what is in effect. `OpenAIServingChat` — the only reader
of these two fields in the tokenizer process — follows the overlay. The
architecture pass (`resolve_auto_parsers`, before the schedulers fork) is
unchanged: the scheduler resolves its own bags from the instance it receives.
`sa = get_server_args()` followed by `sa.field` reads the same startup record as
the direct form; the read ratchet added in the previous slice pinned twelve of
them as the remaining surface. Eleven now read the accessor for what they
actually want:
- `is_enable_moe_cp_allgather` compares the attention-CP and MoE-DP sizes to
decide whether a forward needs an allgather, so it reads the live topology
through `get_parallel()` — the same source `get_moe_cp_size()` right above it
already uses. Both groups exist once model-parallel init has run, which is
before any forward.
- The DeepSeek MLA decode-backend gate and Inkling's attention paths read
`get_exec().kernel`; Inkling's KV-dtype checks read `get_model()`. These are
per-runner fields, and the value they get is the config published for the
runner being built — unchanged from what the alias returned.
- The int8 mamba checkpoint pool reads `get_exec().mamba`. It keeps its guard
for callers that construct the pool with no published config; that guard now
catches the namespace accessor instead of the slot.
`model_loader`'s `moe_dp_size` stays on the instance and is exempt: the dict it
belongs to already reports the live size under `"dp"`, so that entry is the
configured intent, and `get_parallel()` shadows the name with the live value.
Alias-form baseline 12 -> 0. What remains on `get_server_args()` in the package
is the derived API (properties and methods computed from several fields plus the
HF config) and four config-intent reads of live-shadowed sizes, each exempt by
name with its reason.
`RayEngine.__init__` set the caller's `PlacementGroup` on `ServerArgs` as an
undeclared attribute, and every consumer read it back off the config object:
the non-DP launch path took `pg` and `is_custom_pg` from it, the DP path had to
re-attach the handle after `dataclasses.replace` dropped it, the DP controller
asked the config whether the group was the caller's, and the Ray HTTP launcher
had to clear the field so a stale handle could not leak in.
A live cluster object is not config. It now travels as a `placement_group`
argument on the two launch hooks — `Engine._launch_subprocesses` and
`Engine._launch_scheduler_processes` — defaulting to `None`, with `RayEngine`
holding the caller's group in `_placement_group` and the DP path passing
`is_custom_pg` down to the controller. The public API is unchanged:
`RayEngine(placement_group=pg, ...)` still works, `pg` still falls back to the
ambient group, and the HTTP launcher gets `None` from the default.
Writer ratchet 18 -> 15.
Xinyuan Tong