fix(build-vllm): let a dispatch raise the QA selection floors

[wbrennan899]

Problem

external/vllm/templates/vllm-qa/template.yml declares the generic vLLM selection floor:

extra_filters:
  compute_cap:
    gte: 800        # sm_80 — matches the production vLLM floor (vLLM kernels)

That is correct for almost every vLLM build. It is wrong for one whose kernels are compiled for a newer architecture, because offers are searched cheapest-first: the gate rents an Ampere card, and the engine dies before serving.

torch.AcceleratorError: CUDA error: no kernel image is available for execution on the device
RuntimeError: Engine core initialization failed.

The redraw then makes it worse rather than better. It excludes the failed machine and draws again from the same pool, so it lands on another card the image has no kernels for and fails identically. Per ADR 0029 the discriminator between an image defect and a bad host is reproducibility — "an image defect fails every draw" — and this failure is reproducible for a reason that has nothing to do with the image. The gate reports the build broken without ever having run it on hardware it supports.

Measured

hy4-preview, run 33509520098 — a Blackwell-targeted model:

Draw	Offer	GPU	Compute cap	Price
1	47574078	A10	860	$0.243/hr
2	49411012	RTX 3080	860	$0.123/hr
3	31921484	RTX 4000 Ada	890	$0.164/hr

Same error on every draw, on both CUDA variants. The rest of the suite was green — 24 passed, 2 failed, 3 skipped, and the only failures were vllm.d/10-vllm-serving and vllm.d/12-vllm-contract. base/60-gpu-cuda, base/61-cuda-compute and base/62-gpu-libraries all passed, because the driver and CUDA userland were fine; it was only ever the kernels.

Change

qa-gate.yml already has the input for this — set_filters, raise-only, rejected by create.py if an override would widen selection. promote-base-image.yml, promote-pytorch.yml and build-llama-cpp.yml all use it for their per-config driver floors. It was just never plumbed through build-vllm.yml, so a vLLM dispatch had no way to say "this build needs Blackwell".

Two new workflow_dispatch inputs, passed to both QA cells:

QA_SET_FILTERS:   # e.g. compute_cap.gte=1000
QA_MAX_PRICE:     # e.g. 12.00

Both cells, not one. A floor the standard cell honours and the serverless cell ignores would leave every run of such an image carrying one red cell that says nothing about the image — the same misreading this PR exists to remove, just narrower.

max_price is not an independent knob. Raising compute_cap can empty the offer pool, and the gate's response to an empty pool is to wait and redraw. Without a matching ceiling the override trades a wrong-GPU red for a run that spends its retries on no offers matched the floors and reports no verdict at all.

Blast radius

None by default. Scheduled runs, and dispatches that set neither input, pass an empty set_filters and the same 2.00 ceiling qa-gate.yml already defaulted to. set_filters is raise-only, so a dispatch cannot loosen the linted floors even deliberately.

imagegen lint --all: 27 images | 0 errors, baseline clean.

Using it

build-vllm.yml
  VLLM_VERSION=nightly
  CUSTOM_IMAGE_TAG=hy4-preview
  QA_SET_FILTERS=compute_cap.gte=1000
  QA_MAX_PRICE=<ceiling that reaches a Blackwell card>

Two things this PR deliberately does not decide:

• The right floor for hy4. 1000 is sm_100; if its kernels are sm_120-only then an RTX 5090 is required and 1200 is the floor. Worth confirming against the upstream build before the re-run.
• The right ceiling. A 5090 fits comfortably under $2/hr; a B200 does not. If hy4 turns out to need sm_100 specifically, the ceiling has to clear datacentre Blackwell pricing or the pool is empty.

Neither is knowable from the failed run, since it never reached a card in that class.

Not addressed here

vastai/vllm:hy4-preview-cuda-13.0 and -cuda-12.9 are published and currently unverified — the manifests merged from a run whose QA never tested them meaningfully. They are not known-bad; they are untested. Re-running the gate with a real floor is what settles that, and that is a dispatch rather than a code change.

[robballantyne]

Thanks, Will. The need here is real, so we've taken this over in #297 rather than bounce review rounds. Your commit is the first of two there, authorship kept. The second scopes the override to custom-tag builds and compute_cap only, bounds and validates max_price (it was spliced into a run: script, and 0 removed the cap), and makes a narrowed QA pass visible in the summary and Slack headline. The reasoning is in ADR 0047, and a new lint rule (L099) enforces the wiring. Closing in favour of #297.