[Defilan]

What

spec.vllmConfig gains toolCallParser and reasoningParser, the typed
equivalents of the fields spec.sglangConfig already had. Setting
toolCallParser emits --tool-call-parser together with
--enable-auto-tool-choice, which vLLM requires for a parser to do anything;
reasoningParser emits --reasoning-parser alone, since vLLM has no paired
flag for it. Both are free strings, and a flag already present in
spec.extraArgs wins, per flag.

The SGLang enums admit glm, glm45 and glm47 for tool calls and glm45
for reasoning.

Why

Fixes #2119

Without the fields, a vLLM service sets the parsers through extraArgs, where
leaving out --enable-auto-tool-choice makes the parser inert and any request
with tool_choice: auto fails:

"auto" tool choice requires --enable-auto-tool-choice and --tool-call-parser to be set

That is the common case for chat models serving agent clients, not an edge.
The SGLang enums rejected the GLM values, so GLM-5.3-Flash's documented
--reasoning-parser glm45 --tool-call-parser glm47 could not be expressed.

How

Commit	Files
ee0198ef6 feat(api): type the vLLM tool-call and reasoning parsers and admit the GLM ones on SGLang	api/v1alpha1/inferenceservice_types.go, inferenceservice_types_test.go, both CRD copies, internal/controller/runtime_vllm.go, runtime_vllm_args.go, runtime_vllm_test.go, runtime_test.go, runtime_parsers_envtest_test.go, docs/site/guides/multi-node-inference.md
c88d13999 docs(api): correct the vLLM parser counts in the field docs	inferenceservice_types.go, both CRD copies
0fb1e0885 fix(api): cite the vLLM parser registry instead of counting it	inferenceservice_types.go, both CRD copies, runtime_vllm_test.go
757892448 docs(api): state the SGLang glm parser mapping precisely	inferenceservice_types.go, both CRD copies
eaee88446 docs(api): pin the SGLang release in the glm parser comment	inferenceservice_types.go, both CRD copies
07b70fecb docs: point the measured vLLM parser configs at the typed fields	docs/site/guides/multi-node-inference.md, docs/site/labs/deepseek-v4-flash-two-sparks.md, docs/site/labs/deepseek-v41-flash-exl3-three-sparks-ring.md, both multinode samples
62d082a01 docs: keep both parser pairings and bound the SGLang enum's claim	inferenceservice_types.go, both CRD copies, multi-node-inference.md, both samples, runtime_vllm_test.go
51ceba642 fix(api): stop the SGLang enum comment promising vLLM's suppression	inferenceservice_types.go, both CRD copies, multi-node-inference.md, runtime_vllm_test.go

Design decisions, from the first commit's ledger:

• The pairing is automatic. vLLM's ParserManager.get_tool_parser returns
  None when auto tool choice is off, so a typed parser without
  --enable-auto-tool-choice would reproduce the reported failure.
• extraArgs guards are independent, per flag. A user-supplied
  --tool-call-parser suppresses only the typed parser, and auto tool choice is
  still emitted, because their parser is equally inert without it.
• Free strings, not enums, for vLLM. The parser registry grows with every
  model family, so an enum would gate each new parser behind an operator
  release. The field docs name the registry file to check rather than a count,
  after two attempts at a number were both wrong.
• SGLang reasoning stops at glm45. ReasoningParser.DetectorMap at
  v0.5.15.post1 has glm45 and no glm47, and --reasoning-parser validates
  choices at startup, so admitting glm47 would abort the server. The issue
  asked for glm47 in both enums; this is the part of it the pinned runtime
  cannot support, and an envtest spec pins the rejection.
• SGLang tool calls admit glm, glm45 and glm47, matching
  ToolCallParserEnum at the pinned image. Existing values stay, including
  qwen3 and functionary, which the pinned image no longer registers but
  which existing objects use.
• Measured samples and lab pages keep their extraArgs specs and gain a
  note pointing at the typed fields, so the published numbers still describe
  the run that produced them.

Behaviour changes only for specs that set spec.vllmConfig.toolCallParser or
spec.vllmConfig.reasoningParser, whose spec.sglangConfig.toolCallParser is
glm, glm45 or glm47, or whose spec.sglangConfig.reasoningParser is
glm45.

Verification: two envtest reproductions fail on base and pass here (the typed
fields prune at admission on a vLLM service; the GLM values are rejected on an
SGLang service), a differential probe over 11 input classes the ledger calls
unchanged is byte-identical between base and branch, and every new assertion
was falsified by reverting the production line it covers. Not a runtime-arg
parity case: no pkg/agent code reads VLLMConfig, and the vllm-swift wrapper
auto-detects the parser.

Open items recorded in the commit ledger and not fixed here:

• hasMatchingExtraArg does not match the negative form
  --no-enable-auto-tool-choice, so a spec that sets the typed parser and opts
  out that way gets last-wins from extraArgs. Same limitation as every other
  boolean guard in the repo.
• The SGLang parser appenders have no extraArgs guard, so keeping the typed
  field set while also passing the flag in extraArgs emits it twice. The
  field comment now says to clear the field instead.
• Not introduced here: the SGLang tool enum still admits qwen3 and
  functionary, which the pinned image does not register, so a spec using
  either one crash-loops today because --tool-call-parser validates choices
  at startup. Dropping them would break stored objects, so an admission
  warning is the likely fix. Follow-up issue not yet filed.

AI assistance

Assisted-by: DeepSeek-V4.1-Flash (deepseek-ai/DeepSeek-V4.1-Flash, vllm runtime, self-hosted with LLMKube on 3x NVIDIA GB10; roles: planning, code, tests and commit messages, executing review: base-vs-head probes and mutation checks)
Assisted-by: qwen38-flash-next (unsloth/Qwen3.8-Flash-Next-GGUF UD-Q3_K_XL, generic (llmkube-gufo-rocm-gfx1151) runtime, self-hosted with LLMKube on AMD Strix Halo (Ryzen AI Max, Radeon iGPU); roles: read-only review)
Verified by the author: read the diff

Checklist

• Tests added/updated
• make test passes locally
• make lint passes locally
• Commit messages follow conventional commits
• All commits are signed off (git commit -s) per DCO
• AI assistance (if any) is disclosed above, per CONTRIBUTING.md
• Documentation updated (if user-facing change)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[Defilan]

Reviewed against the pinned engine sources. Good to merge after one doc fix.

Checked against upstream

• vLLM v0.25.1 (the default image): ParserManager.get_tool_parser returns None unless auto tool choice is on (vllm/parser/parser_manager.py:35), so pairing --enable-auto-tool-choice with toolCallParser is the right default. deepseek_v4, glm45, glm47 and hermes are in both the tool and reasoning registries.
• SGLang v0.5.15.post1 (CUDA image): ToolCallParserEnum has glm, glm45 and glm47; _handle_deprecated_args rewrites glm45 to glm with a warning (server_args.py:2960); ReasoningParser.DetectorMap has glm45 and no glm47, and --reasoning-parser validates choices at startup, so stopping the reasoning enum at glm45 is correct.
• SGLang v0.5.15 (ROCm image): same GLM entries in both maps.

Checked in the code

• Both fields are optional and omitted when empty, so existing InferenceServices render identical args and nothing rolls on upgrade.
• Multi-node renders every rank through BuildArgs, headless workers included. The lab specs already pass the same flags to every rank through extraArgs, so behavior matches what was measured.
• Unit tests and the three new envtest specs pass locally. Deleting the auto-tool-choice append fails TestVLLMBuildArgs. make manifests generate chart-crds leaves no drift.

One fix

docs/site/guides/multi-node-inference.md uses toolCallParser: deepseek_v4 with reasoningParser: glm45 to show that the two names are chosen independently. It is accepted, but it pairs a GLM reasoning parser with a DeepSeek model, and someone will copy it. Suggest:

The two names come from separate registries and often differ: DeepSeek V4 uses deepseek_v4 for both, GLM uses toolCallParser: glm47 with reasoningParser: glm45.

Fine to leave for later

• The two open items in the description. The --no-enable-auto-tool-choice gap matches every other boolean guard. The duplicated SGLang flag is harmless in practice: both values pass argparse choices, the last one wins, and extraArgs lands last.
• Not from this PR, but worth a follow-up issue: the SGLang tool enum still admits qwen3 and functionary, which the pinned image does not register. Because --tool-call-parser validates choices at startup, a spec using either one crash-loops today. Dropping them from the enum would break stored objects, so an admission warning is probably the fix.