[None][feat] Add per-request priority support to OpenAI chat/completions

[sopwg612]

Summary

Expose the executor's per-request scheduling priority through the OpenAI frontend, so deepapi's service_tier: "priority" can reach the TRT-LLM scheduler on pytrtllm models (vLLM models already have this path; pytrtllm was the gap).

• serve/openai_protocol.py: add priority: Optional[float] (pydantic-validated, ge=0.0, le=1.0) to ChatCompletionRequest and CompletionRequest. Absent field → None → engine default 0.5, so existing traffic is byte-for-byte unaffected.
• serve/openai_server.py: forward it to generate_async(...) in openai_chat and openai_completion (the two endpoints deepapi routes pytrtllm traffic to, per get_llm_url).

Everything below generate_async already exists upstream (Request.priority → PriorityWaitingQueue); this PR is only the missing frontend plumbing — same shape as the earlier per-request stream_interval_ms (#5).

Engine semantics (operators read this)

• Convention: float in [0, 1], higher = served first, default 0.5 (note: opposite sign of vLLM's priority).
• Only honored with scheduler_config.waiting_queue_policy: "priority" in --extra_llm_api_options. The default FCFS waiting queue ignores the field (logs a warning). Do not tag a model PRIORITY in deepapi until its deployment carries both this build and that config.
• Out-of-range values are rejected at the schema (400), not clamped.

Intentionally not wired

openai_mm_encoder, /v1/responses, and the gpt-oss harmony path keep their current behavior — deepapi routes pytrtllm LLM traffic exclusively to /v1/chat/completions and /v1/completions. Can be added later if those paths ever need it.

Validation

Patched canary image (pytrtllm:rc16-priority-canary) on a manual 4xB300 deployment of Kimi-K2.5-Turbo (di-atl1-44, reserved GPUs), waiting_queue_policy=priority:

• Schema: "priority": 5 → 400 (le=1.0 validation); 1.0 → 200; absent → 200.
• Behavioral probe, 160-way saturation (queue confirmed: loaded p50 ~1.9s vs 0.29s uncontended floor), 60s, ~1200 samples/bucket:
  • HIGH (1.0) TTFT p50 0.947s vs LOW (0.0) 2.857s → high-priority served ~3x sooner.
  • Equal-priority control with random labels: gap −0.025s (~0) → no harness bias.
• py_compile clean on both files.

Rebase notes

Both files are in the high-conflict set (openai_protocol.py / openai_server.py). The hunks are small and context-anchored next to stream_interval_ms; on the next upstream bump re-fit is mechanical (rc11↔rc16 drift only required re-fitting the openai_chat call site, which gained scheduling_params in rc16).

🤖 Generated with Claude Code