docs: SGLang's launcher now takes --servicer-impl; the docs say the environment variable is the only selector

[github-actions]

What this PR does

How do I select the SGLang gRPC worker's servicer implementation on the launcher command line (--servicer-impl on sglang serve / python -m sglang.launch_server), and how does the flag interact with SMG_SGLANG_SERVICER_IMPL?

Why we need it

Source change: smg-project/smg@d46e993

Re-verified pending concern, slugs preserved; its earlier plan's branch codex/nightly-docs-797c4ee4d75d70d0 appears in no existing PR. Commit 141 (#2998, d46e9935, 2026-10-09) added --servicer-impl to SGLang's launcher; the supplied diff was read this run (its grpc_servicer/README.md hunk documents the contract: 'sglang serve --help prints SGLang's help before it loads plugins, so the flag is missing from that listing but accepted', while python -m sglang.launch_server --help lists it) and every claim re-verified on the current default-branch snapshot. Current main: grpc_servicer/pyproject.toml:64-68 declares the sglang.srt.plugins entry point smg-servicer = smg_grpc_servicer.sglang.plugin:register beside the existing smg-zmq entry; smg_grpc_servicer/sglang/plugin.py:1-16 (module doc) hooks sglang.srt.server_args.ServerArgs.add_cli_args (ADD_CLI_ARGS :30, after_add_cli_args :93-101) so every parser SGLang's launchers build grows --servicer-impl {python,rust} (SERVICER_IMPL_FLAG/CHOICES :27-28, add_servicer_impl_argument :68-90); the parsed value travels as this process's launcher flag and is written to SMG_SGLANG_SERVICER_IMPL (_ServicerImplAction :63-65), and 'A SGLANG_PLUGINS setting that leaves this plugin out only removes the flag; the environment variable works regardless' (:14-15). smg_grpc_servicer/sglang/rust.py servicer_impl_source (:83-108) resolves flag > SMG_SGLANG_SERVICER_IMPL > default python, raises on values outside {python, rust} (:104-105), writes a flag decision back to the env (:106-107) so --servicer-impl python also overrides an inherited rust — the same flag-wins/write-back behavior grpc-workers.md:127 already documents for vLLM — and the startup log names which source decided (SOURCE_FLAG/ENV/DEFAULT :70-72). What stays true and must not be disturbed: smg serve's own --servicer-impl remains vLLM-only (bindings/python/src/smg/serve.py:957-962 rejects it for any backend but vllm with connection-mode grpc; help :846-855), so grpc-workers.md:162's smg-serve sentences (already rescoped by merged PR #143) and getting-started/index.md:172/:323 stay accurate. Stale claim, re-read this run: getting-started/grpc-workers.md:152 — 'One environment variable selects it on the unchanged entrypoint — every SGLang server flag stays the same' — false on main, and the section's only start commands (:154-160) show the env form, so the flag is undocumented on the one page that states SGLang's selection surface. One independent concern: one commit added one selection flag on one engine's launcher, corrected in the one section that states that engine's selection surface. Version framing: #2998 postdates the v1.12.0 bump (commit 219, #2888, 2026-10-08); the section already frames the Rust SGLang servicer as newer than v1.11.0 (:152), and the TokenSpeed section's 'Unreleased:' note (:194) is the page's style for post-bump additions — present the flag as current-main behavior with the environment variable as the documented fallback, naming no release. Scope limits: leave :172's KV-events sentence alone (SGLang Rust-mode KV-events default-on, #2939, and the SGLang startup/tuning env vars of #3117 are separate deferred concerns on this same file, recorded in remaining_work). Dedup: merged #126 documented the env-var selection before the flag existed; merged #143 (the TokenSpeed twin flag #2999) explicitly deferred this SGLang-flag concern on this file and only rescoped :162's smg-serve sentence; no open or closed PR mentions #2998 or an SGLang --servicer-impl; there are no open PRs at all, so no file is blocked. Edit well under 1,000 lines.

Scope: worker-launchers / sglang-servicer-impl-flag. Other concerns are deferred.

How to test

• Passed the documentation path and size guard (under 1000 added plus deleted lines; no file-count limit).
• Passed an independent accuracy and single-concern review.
• Passed git diff --check and pnpm check and the production pnpm build.

Checklist

• Tests added/updated (if applicable)
• Docs updated (if applicable)
• Commit includes a DCO sign-off

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: c93b9ca3-1ce8-4ff7-8dee-8b1afe544fe7

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Documentation maintenance: ready. Unsuccessful content rounds: 0/3. Operational attempts: 0/3.

Head: 4262b8f132d3e2b5984323035bbef9c20545a8be; reviewed main: 8df4f5b4b0429633d2a22f92c67a2c93640477d5.
Reviewed SMG source: a29c64d4323dbf21950e2822cb099af04f6fd901.

All hunks serve the allowlisted SGLang --servicer-impl flag concern (commit d46e9935, attribution confirmed via the supplied source patch whose pre-image shows the prior env-only resolver) on the one canonical page grpc-workers.md (~25 lines, no new page). Verified at the checkout HEAD a29c64d4 (= context.code_sha): sglang.srt.plugins entry point smg-servicer (grpc_servicer/pyproject.toml:68); plugin.py:93-109 hooks ServerArgs.add_cli_args so every SGLang parser grows --servicer-impl {python,rust} (:27-28, :68-90); precedence flag > SMG_SGLANG_SERVICER_IMPL > python with invalid values raising ServicerConfigError (rust.py:104-116) and a configuration exit before scheduler work (server.py:134-137), argparse choices rejecting bad flag values; the documented log line matches server.py:125 verbatim; flag decisions written back to the env at parse (plugin.py:63-65) and resolution (rust.py:117-118) so --servicer-impl python overrides an inherited rust. Retained claims verified: serve.py:957-962 rejects rust outside --backend vllm --connection-mode grpc; worker env from os.environ.copy() (serve.py:166); SglangWorkerLauncher supports --backend sglang --connection-mode grpc (serve.py:244-267); no SMG_SGLANG_SERVICER_IMPL handling in bindings. Placement: the stale env-only exclusivity sentence corrected in place; precedence, help asymmetry, smg-serve scoping and the version-free standalone Unreleased note (backed by the source-patch pre-image) are separate focused paragraphs in the page's established style; no PR/commit/code references in prose. Related docs: repo-wide grep shows the SGLang selection surface stated exclusively only here; index.md:323 states the env form non-exclusively and links to the corrected section (same accepted pattern as the vLLM tab at :300); index.md:172 and multimodal.md:152 stay vLLM-scoped. Limitations: the sglang serve --help omission/acceptance and SGLANG_PLUGINS behavior rest on the package README contract (README.md:490-491, 504-506, added by the attributed commit) since SGLang is external, though the env variable working regardless is directly verified in server.py; the retained "newer than v1.11.0" sentence is verbatim pre-existing framing about the switch (not the flag), uniform with the untouched vLLM/TokenSpeed sections — tags v1.11.0/v1.12.0 confirmed in packed-refs but tag trees not walkable read-only. feedback.threads is empty, so there are no threads to address.

Workflow evidence

Human review threads and CODEOWNER approval remain under repository policy.

[XinyueZhang369]

This source change is not included in the latest stable release, v1.12.0. Public documentation will now target published stable releases only, without unreleased/current-main sections. Closing at the maintainer’s request. The docs-awaiting-release label marks this as deferred rather than declined, so the nightly workflow can rediscover the gap against a stable release and propose a focused, release-correct update.