[Frontend] Add sampling parameters to Responses API

[DanielMe]

Purpose

Port essential sampling parameters from /v1/chat/completions to /v1/responses API to provide basic generation control for users of the Responses API.

Added Parameters:

• presence_penalty, frequency_penalty, repetition_penalty - repetition control
• min_p, seed, stop, ignore_eos, min_tokens - sampling control
• prompt_logprobs, spaces_between_special_tokens - output control
• include_stop_str_in_output, truncate_prompt_tokens - formatting control
• logits_processors, allowed_token_ids, vllm_xargs - advanced control

Key Changes:

• Extended ResponsesRequest protocol with 5 core sampling parameters
• Added logits_processor_pattern parameter to to_sampling_params() method

Test Plan

Unit Tests:

Adding unit tests just to validate the API mapping:

pytest tests/entrypoints/openai/responses/test_sampling_params.py -v

Integration Test:

Adding an integration test to prove that the end-to-end call works with the new parameters.

pytest tests/entrypoints/openai/responses/test_simple.py::test_extra_sampling_params -v

Test Result

tests/entrypoints/openai/responses/test_sampling_params.py::TestResponsesRequestSamplingParams::test_basic_sampling_params PASSED                   [ 20%]
tests/entrypoints/openai/responses/test_sampling_params.py::TestResponsesRequestSamplingParams::test_extra_sampling_params PASSED                   [ 40%]
tests/entrypoints/openai/responses/test_sampling_params.py::TestResponsesRequestSamplingParams::test_stop_string_conversion PASSED                  [ 60%]
tests/entrypoints/openai/responses/test_sampling_params.py::TestResponsesRequestSamplingParams::test_default_values PASSED                          [ 80%]
tests/entrypoints/openai/responses/test_sampling_params.py::TestResponsesRequestSamplingParams::test_seed_bounds_validation PASSED                  [100%] 

tests/entrypoints/openai/responses/test_simple.py::test_basic[Qwen/Qwen3-8B] PASSED                                                                                                 [ 16%]
tests/entrypoints/openai/responses/test_simple.py::test_enable_response_messages[Qwen/Qwen3-8B] PASSED                                                                              [ 33%]
tests/entrypoints/openai/responses/test_simple.py::test_reasoning_item[Qwen/Qwen3-8B] PASSED                                                                                        [ 50%]
tests/entrypoints/openai/responses/test_simple.py::test_streaming_output_consistency[Qwen/Qwen3-8B] PASSED                                                                          [ 66%]
tests/entrypoints/openai/responses/test_simple.py::test_max_tokens[Qwen/Qwen3-8B] PASSED                                                                                            [ 83%]
tests/entrypoints/openai/responses/test_simple.py::test_extra_sampling_params[Qwen/Qwen3-8B] PASSED                                                                                 [100%]

---

Essential Elements of an Effective PR Description Checklist

• The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
• The test plan, such as providing test command.
• The test results, such as pasting the results comparison before and after, or e2e results
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.
• (Optional) Release notes update. If your change is user facing, please update the release notes draft in the Google Doc.

[mergify]

Hi @DanielMe, the pre-commit checks have failed. Please run:

uv pip install pre-commit
pre-commit install
pre-commit run --all-files

Then, commit the changes and push to your branch.

For future commits, pre-commit will run automatically on changed files before each commit.

Tip

Is mypy or markdownlint failing?

mypy and markdownlint are run differently in CI. If the failure is related to either of these checks, please use the following commands to run them locally:

# For mypy (substitute "3.10" with the failing version if needed)
pre-commit run --hook-stage manual mypy-3.10
# For markdownlint
pre-commit run --hook-stage manual markdownlint

[gemini-code-assist]

Code Review

This pull request adds several sampling parameters to the /v1/responses API to align it with the /v1/chat/completions endpoint, which is a great step towards feature parity. The changes are well-tested with new unit and integration tests. I've found one high-severity issue related to inconsistent handling of default sampling parameters, which could cause model-wide configurations to be ignored. My review includes a suggestion to address this.

[DanielMe]

This is a user-facing change. Happy to provide a snippet for the the release notes draft in the Google Doc. As it stands I do not have access to that doc to see what the structure is like and what it already contains for the Responses API.

[chaunceyjiang]

https://www.openresponses.org/reference

Actually, the Responses API has a public specification now. Many of the parameters in this PR come from ChatCompletion, so I’d suggest using the ChatCompletion interface directly instead.

My main concern is that introducing these parameters could lead to conflicts with the public Responses API specification in the future.

[DanielMe]

Thanks, that spec is a good pointer. I’m actually leaning on that public spec as a justification for this PR, not an argument against it.

The Open Responses spec explicitly allows implementations to extend existing schemas with additional, implementation-specific fields, as long as core semantics stay intact, fields are optional, and extensions are documented (and treated as vendor-specific). That’s exactly what this PR is doing: it adds optional request fields to expose vLLM-specific capabilities without changing the required behavior of the Responses API.

Also, vLLM in general and the Responses API in particular already has an established pattern of supporting “extra parameters” beyond the vanilla OpenAI surface (documented in the OpenAI-compatible server docs), and /v1/responses already supports extra request fields today (e.g., request_id, priority, cache_salt, top_k etc.). So extending /responses is consistent with existing vLLM behavior rather than a new precedent. On the “just use ChatCompletions instead” point: the main goal here is parity so users who adopt /v1/responses (and the Open Responses ecosystem built around it) don’t have to fall back to /chat/completions just to access basic sampling controls. This PR is narrowly scoped to port sampling knobs that already exist in vLLM’s ChatCompletions surface over to Responses.

Re: future conflicts with the spec - since these are optional extensions, the blast radius is low:

• If the spec later standardizes some of these fields with the same semantics, we’re already aligned.
• If the spec standardizes something different, we can alias/deprecate with a compatibility window.

If you’d prefer to minimize collision risk up front, we could also rename/namespace the fields (e.g., vllm_* or push them under vllm_xargs) while keeping the same functionality.

If the maintainers’ preference is “keep /responses minimal and push advanced control to /chat/completions”, I get the trade-off - but I think it undercuts the intent of adopting /responses as the forward-looking surface when those controls already exist and are safe to expose as vendor extensions.

[qandrew]

hi @DanielMe thanks for putting this together! i'm curious is someone asking for all these extra params to reach parity with chat completions?

In general I am happy to add more features to responsesAPI, if there is a need for it, as maintenance of these extra params will need to happen

[DanielMe]

Thanks @qandrew ! This PR comes out of a concrete need for stop and vllm_xargs primarily and then, a bit less important for our use case, seed, repetition_penalty, prompt_logprobs and ignore_eos for running a custom model. We have a preference for using the Responses API over Chat Completions because of the better structured output and the momentum behind this API.

While working on this proposal I figured that other people may find use for the other sampling params already supported by Chat Completions and they turned out easy to port.

That being said, I can see the case for going on a case-by-case basis depending on concrete need to avoid committing to future maintenance of an attribute nobody asked for.

I could reduce the PR to only the six fields for which we have concrete use cases or only the two fields which are the most important ones?

[DanielMe]

@qandrew , I have reduced the PR to only those fields for which we have a validated immediate need. Does this look better?

[chaunceyjiang]

Compared to the previous version, these additions make it much more reasonable.

Let's invite others to review this.

/cc @qandrew @yeqcharlotte @DarkLight1337

[qandrew]

lgtm, thanks!

[qandrew]

cc @chaunceyjiang we can merge in?

[chaunceyjiang]

@qandrew ok

[DanielMe]

Thanks. If I understand the merge policy correctly, this will also require review from @NickLucche, @aarnphm , @DarkLight1337 and @robertgshaw2-redhat .