feat: add opt-in vLLM sampling validation - #683

The simulator has so far parsed only the fields that affect response generation.

In strict mode, we should validate the entire request against the OpenAI API specification, along with the vLLM-specific extension fields. This means verifying that all required fields are present and that every supplied field has a valid value and is consistent with related parameters.

The implementation in this PR validates only part of the request. For example:

• n has an upper limit configured by VLLM_MAX_N_SEQUENCES, but this limit is not currently validated.
• When max_tokens is omitted, vLLM applies a default value. However, min_tokens is not validated against that effective maximum.

Rather than incrementally adding validation for individual fields, I suggest using an existing library that validates OpenAI-compatible requests, if one is available. Alternatively, we could generate or obtain a JSON Schema from vLLM’s OpenAPI specification:

curl http://localhost:8000/openapi.json > openapi.json

Then we can apply standard JSON Schema validation for the common request structure and add explicit validation for constraints that depend on runtime configuration or relationships between fields, such as VLLM_MAX_N_SEQUENCES and the effective max_tokens value.

Thanks for the rework, and for moving to the full request schema. There are several issues in the proposed implementation that need to be resolved before this can land.

1. Strict mode should not depend on a user-supplied schema file

Requiring --strict-openapi puts the burden on the user to export and carry a snapshot, and it makes strict mode depend on an artifact the simulator cannot control. The important problem: a schema exported from a newer vLLM can be inconsistent with the validations implemented in the code here, and then strict mode silently mixes two different vLLM versions - a new field passes the schema and then hits a check written for an older release, or vice versa.

Please check a snapshot into the repository and load it from there (go:embed), so the schema version and the hand-written checks are versioned together and --strict works with no extra user setup.

2. The schema covers only a small part of the validation

Schema validation gives structure and types; most of what vLLM rejects is not expressible there. n is one example (both n < 1 and n > VLLM_MAX_N_SEQUENCES, whose default is 16384 in vllm/envs.py), but there are many more, for example:

• stream_options set while stream is false or absent
• top_logprobs set while logprobs is false
  ...

This needs a systematic pass over vLLM's request models and SamplingParams to cover all request fields, rather than a partial list. Please also keep the exact vLLM message text where you claim parity - for instance the n upper-bound message here drops vLLM's second sentence about setting VLLM_MAX_N_SEQUENCES.

3. Validation logic is spread across too many places

Right now a single request is validated in four different locations, with rules duplicated between them:

• pkg/communication/strict_schema.go: schema validation, n > VLLM_MAX_N_SEQUENCES, and min_tokens against the schema's max_tokens default
• pkg/communication/strict_validation.go: all sampling ranges, plus min_tokens against the explicit max_tokens
• pkg/endpoint/request.go (validateTokenizedRequest): min_tokens again, against the remaining context window
• pkg/api/request.go: strictMinTokens / strictDefaultMaxTokens fields and SetStrictTokenLimits / StrictTokenLimits, only to carry values from the first location to the third (please remove new fields from the request)

So min_tokens versus max_tokens is implemented three times with three different notions of the maximum. On top of that, pkg/endpoint/helpers.go (validateRequest) already validates n < 1 and max_tokens < 1, so those conditions now exist twice with two different messages depending on the flag. Please consolidate: one place per rule, one message per rule.

4. Align with the new engine structure

The project has been restructured recently and now has an explicit engine concept (pkg/engine, with pkg/engine/vllm supplying the vLLM-specific flags, config validation, and transport). Strict request validation should fit into that seam rather than sit beside it.

Suggested split, worth agreeing before you rework:

• Run strict validation when the request is received, in one place, so it is not interleaved with tokenization and generation.
• Keep generic OpenAI-level checks in the common path.
• Put vLLM-specific fields in a vLLM validator owned by the engine, next to the existing ValidateConfig - min_tokens is a good example, it is a vLLM SamplingParams extension, not an OpenAI field.

@0z5a PR looks good, please see some comments below

Great, thanks!
PR is ready for merge, just waiting for conflict resolution