Skip to content

feat(server): per-request ignore_eos via extra_body (vendor extension) - #252

Open
Andrewxu313 wants to merge 2 commits into
mainfrom
feature/openai-extra-body-ignore-eos
Open

feat(server): per-request ignore_eos via extra_body (vendor extension)#252
Andrewxu313 wants to merge 2 commits into
mainfrom
feature/openai-extra-body-ignore-eos

Conversation

@Andrewxu313

Copy link
Copy Markdown
Contributor

Description

Make ignore_eos a per-request vendor extension — passed via the OpenAI SDK's
extra_body (or a top-level key in a Batch JSONL body), the same convention vLLM/SGLang
use — and honor it per-sequence.

File Change
server/io_struct.py Add ignore_eos: Optional[bool] to ChatCompletionRequest + CompletionRequest
server/batch_scheduler.py Pool mode: per-request req.body.ignore_eos with batch-level fallback, threaded via raw_request → admit entry; un-hardcode the legacy infer() path
batchgen_worker.py Set seq.ignore_eos on admission; honor it per-sequence at the decode EOS boundary (eos_flags), OR'd with the global flag
worker/completion.py is_sequence_completed / get_finish_reason OR in seq.ignore_eos (the completion gates)
sequence.py Add ignore_eos to SequenceEntry.__slots__ + init (default False)
tests/worker/test_completion.py Unit tests: per-sequence ignore_eos overrides EOS completion / finish_reason

Motivation

ignore_eos was only a batch-level CreateBatchRequest field, and pool mode (the
production path) never threaded it to the worker — the pool init message and
IntakeEntry.raw_request both omitted it, and the pool init handler never called
set_ignore_eos. So ignore_eos silently never held: sequences stopped at their real
EOS even when requested (observed: throughput_test.pyignore_eos held: False, 707k of
8.39M expected tokens on a 2k→8k / 1024-seq run). It was also not a per-request field
and not an env var (BATCHGEN_IGNORE_EOS has zero readers).

The per-request extra_body form is the clean, extensible home for this and future vendor
flags (min_p, repetition_penalty, …). Backward compatible: the per-request value
falls back to the batch-level field, so this also fixes the previously-dropped batch-level
ignore_eos in pool mode — existing clients (incl. throughput_test.py) work unchanged.

Type of Change

  • Bug fix
  • New feature
  • Breaking change
  • Documentation update

Checklist

  • I have read the CONTRIBUTION guide.
  • I have updated the tests (if applicable).
  • I have updated the documentation (if applicable).

Validation

  • tests/worker/test_completion.py: per-sequence ignore_eos unit tests (CPU-only).
  • Pending on H20: deploy + re-run the 2k→8k / 1024-seq throughput test → expect
    ignore_eos held: True and sum_completion_tokens == n*out_tokens.

TairanXU added 2 commits June 6, 2026 14:10
ignore_eos was only a batch-level CreateBatchRequest field, and pool mode (the
production path) never threaded it to the worker — the init message and
IntakeEntry.raw_request both omitted it and the pool init handler never called
set_ignore_eos — so ignore_eos silently never held (sequences stopped at real EOS
even when the client requested ignore_eos). It was also not a per-request field and
not an env var.

Make ignore_eos a per-request vendor extension (OpenAI SDK extra_body / a top-level
key in a Batch JSONL body), honored per-sequence:
- io_struct: add ignore_eos to ChatCompletionRequest + CompletionRequest.
- batch_scheduler: extract per-request ignore_eos in pool mode (req.body) with
  batch-level CreateBatchRequest.ignore_eos as fallback; thread through raw_request
  -> admit entry. (Also un-hardcode the legacy infer() path's ignore_eos.)
- worker: set seq.ignore_eos on admission; honor it per-sequence at the decode EOS
  boundary (eos_flags) OR'd with the global flag.
- completion: is_sequence_completed / get_finish_reason OR in seq.ignore_eos.

Because the per-request value falls back to the batch-level field, this also fixes
the previously-dropped batch-level ignore_eos in pool mode (backward compatible).
@github-actions github-actions Bot added the ci:run Trigger build + GPU regression on H20 label Jun 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ci:run Trigger build + GPU regression on H20

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant