Scrub check
I have removed hostnames, IPs, absolute paths, usernames, tokens and keys from anything pasted below.
What broke
A health check that asks a server for a specific model, gets HTTP 200 and a sensible answer, and concludes it is talking to that model. On SGLang it is not a check at all. The server answers a request for a model name it does not serve, using whatever model is actually loaded.
We found it because our consumer probe suite has a deliberate negative control: ask for a model name the server should reject. On two separate SGLang serves, same morning, that probe was ANSWERED both times. vLLM 0.26 on the same hardware rejects the identical request properly.
What you saw
Probe "wrong-name rejected" reporting ok: false on every SGLang cell of a 6-cell speed battery, while every content probe (plain chat, structured output, tool calling, reasoning effort) passed. The failing probe requests a model name that is not the served name, and gets a normal 200 with confident content instead of a 404 or 400.
Scrubbed shape of the two cases:
serve A: --served-model-name bench-speed-house
serve B: --served-model-name bench-speed-rarkfp4
request: {"model": "<a name neither server serves>", ...}
response: HTTP 200, ordinary assistant content, no warning anywhere
Same suite against a vLLM serve of a different checkpoint on the same estate, the night before: the wrong-name request is rejected, 9/9 probes pass.
Why this is worse than an ordinary unsupported-parameter case: model is not an exotic field. It is the one field every harness, every router and every canary uses to say WHICH model it is measuring. On this stack it is decoration.
The consequence in our own terms: a scorer, canary or health check that "asks for model X and gets an answer" has NOT established it is talking to model X. Point it at the wrong port, or at a server someone else reloaded with different weights, and it passes while measuring something else entirely. It is the same family as a check that returns a plausible answer instead of an error.
What fixed it
Nothing fixes the server behaviour; the workaround is to stop trusting the request field. Verify identity from RESOLVED SERVER STATE instead:
GET /get_server_info and read model_path and served_model_name back, or- read the resolved launch arguments from the container's own process listing.
Our agent-task benchmark does this by design and records the resolved args in every result artifact. Our ad-hoc checks mostly did not, which is how it survived unnoticed. If you only take one thing: an identity assertion has to read the server's answer about itself, never the client's question.
What were you serving
- Engine: SGLang, build
0.0.0.dev1+g5f55db35e
- Image:
lmsysorg/sglang:dev-cu13-qwen38-27b-dflash2 (image ID 60166a99b661)
- Models:
unsloth/Qwen3.8-27B-NVFP4 and RadixArk/Qwen3.8-27B-NVFP4, both NVFP4
- Hardware: NVIDIA GB10 Grace Blackwell, 128 GB unified, Ubuntu 24.04, aarch64
- Contrast case: vLLM 0.26 on the same hardware, which rejects correctly
- Conditions: two separate serves, same morning, context length 131072,
--mem-fraction-static 0.80, one model loaded at a time
Optional diagnostic evidence
Probe results are recorded per serve as consumer-house.json and consumer-rarkfp4.json, each listing all 9 probes with pass/fail plus the raw response detail. Happy to share those two files.
Related existing entries, which this is NOT a duplicate of: trap 77 covers invented request fields being accepted on Ollama; this is the model field itself, on SGLang, and the failure selects a real model rather than silently ignoring a knob.
I am happy for this data and the credit to be published. Credit as @scottleimroth.
Scrub check
I have removed hostnames, IPs, absolute paths, usernames, tokens and keys from anything pasted below.
What broke
A health check that asks a server for a specific model, gets HTTP 200 and a sensible answer, and concludes it is talking to that model. On SGLang it is not a check at all. The server answers a request for a model name it does not serve, using whatever model is actually loaded.
We found it because our consumer probe suite has a deliberate negative control: ask for a model name the server should reject. On two separate SGLang serves, same morning, that probe was ANSWERED both times. vLLM 0.26 on the same hardware rejects the identical request properly.
What you saw
Probe "wrong-name rejected" reporting
ok: falseon every SGLang cell of a 6-cell speed battery, while every content probe (plain chat, structured output, tool calling, reasoning effort) passed. The failing probe requests a model name that is not the served name, and gets a normal 200 with confident content instead of a 404 or 400.Scrubbed shape of the two cases:
Same suite against a vLLM serve of a different checkpoint on the same estate, the night before: the wrong-name request is rejected, 9/9 probes pass.
Why this is worse than an ordinary unsupported-parameter case:
modelis not an exotic field. It is the one field every harness, every router and every canary uses to say WHICH model it is measuring. On this stack it is decoration.The consequence in our own terms: a scorer, canary or health check that "asks for model X and gets an answer" has NOT established it is talking to model X. Point it at the wrong port, or at a server someone else reloaded with different weights, and it passes while measuring something else entirely. It is the same family as a check that returns a plausible answer instead of an error.
What fixed it
Nothing fixes the server behaviour; the workaround is to stop trusting the request field. Verify identity from RESOLVED SERVER STATE instead:
GET /get_server_infoand readmodel_pathandserved_model_nameback, orOur agent-task benchmark does this by design and records the resolved args in every result artifact. Our ad-hoc checks mostly did not, which is how it survived unnoticed. If you only take one thing: an identity assertion has to read the server's answer about itself, never the client's question.
What were you serving
0.0.0.dev1+g5f55db35elmsysorg/sglang:dev-cu13-qwen38-27b-dflash2(image ID60166a99b661)unsloth/Qwen3.8-27B-NVFP4andRadixArk/Qwen3.8-27B-NVFP4, both NVFP4--mem-fraction-static 0.80, one model loaded at a timeOptional diagnostic evidence
Probe results are recorded per serve as
consumer-house.jsonandconsumer-rarkfp4.json, each listing all 9 probes with pass/fail plus the raw response detail. Happy to share those two files.Related existing entries, which this is NOT a duplicate of: trap 77 covers invented request fields being accepted on Ollama; this is the
modelfield itself, on SGLang, and the failure selects a real model rather than silently ignoring a knob.I am happy for this data and the credit to be published. Credit as @scottleimroth.