test: run the optional tier's payload cases against vLLM CPU servers

[Bslabe123]

Part of #606 (Testing, Test infrastructure and gating) and #748. Moves the tests/optional payload cases off GPU capacity onto real vLLM CPU servers in CI, keeping one cluster-backed case for the Kubernetes deploy path.

Why

The optional tier held nine cases (eight multimodal, one text chat) that ran only by hand against Qwen3-VL-8B / Qwen2-Audio-7B on H100 and had never run in CI. Their single assertion is that a real vLLM accepts the image, video, audio and shared-prefix payloads inference-perf builds and every request completes. That oracle does not depend on model size or speed, so a plain runner can host it. The sim cannot: it recognises image_url / input_audio / video_url blocks by type string and never decodes bytes, checks a media format, or knows what a model supports (that shape check is test_multimodal_sim.py).

What

• e2e/tests/test_vllm_cpu_multimodal.py: one case per file under e2e/configs/vllm_cpu_multimodal/ (images, video, mixed, mixed_frames, shared_image_prefix, shared_mixed_prefix, visionarena, chat, audio), payload shapes unchanged, sized for a 4-vCPU runner. The test overrides server/tokenizer with what the server serves and asserts the optional tier's oracle: clean exit, exactly the dispatched request count succeeded, zero errors. Servers: OpenGVLab/InternVL3-1B-hf (image + video) and ibm-granite/granite-4.0-1b-speech (audio), the smallest ungated models vLLM lists for those modality sets.
• A multimodal-e2e job in E2E Test on change, not a workflow of its own: v0.7.0 Release #606 puts cpu-vllm in the at-merge lane, and the merge gate keys on workflow name, so a tier in a separate workflow would report a rejected payload the morning after it merged. Per release in e2e/vllm_multimodal_releases.txt the job starts each server, runs its slice, and fails a pass that skips anything. A second job rather than more steps in e2e-tests, because the two halves need different models, context lengths, chat templates and release pins, and two jobs finish in the wall clock of the slower one.
• e2e/vllm_cpu_server.sh: VLLM_CHAT_TEMPLATE (empty = model's own), VLLM_MAX_MODEL_LEN, VLLM_HEALTH_TIMEOUT_SEC, VLLM_CPU_OMP_THREADS_BIND, VLLM_EXTRA_ARGS, VLLM_CONTAINER_NAME; default invocation unchanged. utils.vllm_server.served_modalities() added.
• tests/optional: multimodal cases removed; text/chat stays as the deploy-path smoke (manifests, published image, ConfigMap, Job), which nothing else exercises. Its config was invalid on main (synthetic datagen is completion-only, so api.type: chat could not start); now shared_prefix.

Findings from running it

• vLLM 0.26.0's CPU backend pins host memory when batching more than one multimodal item and kills the engine on the first multi-image request; fixed upstream, green on 0.27.1. The tier's release table therefore starts at v0.27.1, separate from e2e/vllm_releases.txt.
• x86 runners cannot serve this slice, for the reason ci: run the e2e job on ARM runners so the live oracle stops failing on a runner draw #743 documents. In one run, the only job whose server did not log Failed to create oneDNN linear started its engine in 49 s and passed; all three that logged it failed: one at 623 s, one killed in encoder profiling, one still profiling when the health budget expired.
• These models profile one max-size encoder item before serving, so the script gained VLLM_HEALTH_TIMEOUT_SEC (default 300, 600 here). ARM startups measured 93-132 s, so that budget is headroom for a slow Hugging Face, not for the profiling pass.

Status

Green on ARM: four passes (two releases x two servers), 18 case runs, zero skipped, 25 min wall clock against 17 for e2e-tests. Locally: pdm run validate clean, unit suite 865 passed, pytest tests/optional 1 skipped without --kubeconfigs.

Still WIP for one decision: the job gates from its first run, and puts ~8 min on the merge gate's wall clock for every PR.

[SachinVarghese]

/lgtm

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Bslabe123, SachinVarghese

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [Bslabe123,SachinVarghese]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment