coli: --auto-tier applies the plan's VRAM tier on sibling engines, and says why when it cannot (#1581)

[JustVugg]

Closes #1581.

What the report found

coli plan and coli doctor print a VRAM tier. --auto-tier is documented as applying the plan they print ("automatically apply the RAM/VRAM placement plan", docs/SETTINGS.md). On the sibling-engine path it then dropped the tier whenever COLI_CUDA was not already 1, which --auto-tier on its own never sets, and dropped it in silence: no [PLAN] line, no [CUDA] banner, VRAM flat during decode. On the reporter's RTX 4060 Ti that was 11.8 tok/s against 21.0 once --gpu auto was added, and they only found it by watching nvidia-smi.

What changed since the first version of this PR

The first version kept the drop and only announced it. That was the weaker half of the report's own suggestion, and it leaves the user where they started: half the throughput, now with a message about it.

The drop was right when it was written. cuda_binary() could inspect only the GLM binary, so a working qwen36 CUDA build looked CPU-only to it, and requiring an explicit flag was safer than risking a CPU-only sibling launched as a CUDA one. Since #1533 the check takes the engine that will actually run, so the risk that contract was written against can be tested rather than assumed, and assuming it costs the user the tier they were just shown.

plan_cuda_enabled() now asks the question the GLM path has always asked (has_cuda=cuda_binary()), of the right binary:

state	decision	why
COLI_CUDA=1	apply	--gpu/--vram already validated the build and exited if it was not capable
COLI_CUDA=0	do not	--gpu none is still the off switch
unset	ask the family's engine	cuda_binary(engine_for_gpu_check(a)), and dsv4_cuda_available for DeepSeek V4, because cuda_binary() rejects valid V4 CUDA builds (#1219)

A CPU-only build still never gets a CUDA launch. That is now what the check says, rather than what the flag assumed.

The notice stays, and says which of the two happened

There are two ways a real tier can still go unused, and the advice for them is not interchangeable:

  [PLAN] the plan's VRAM tier is not being applied
  5.2 GB on 0:NVIDIA GeForce RTX 4060 Ti stays unused: the engine binary has no
  GPU backend, so there is nothing to apply it with. Rebuild the engine with
  CUDA=1 to use it.

and for --gpu none, "drop it to use the plan as printed" instead. Telling someone to rebuild an engine when they asked for no GPU sends them to fix something that is not broken.

It stays quiet when the tier was not real: no device qualified to drive placement (plans_placement, the planner's own test) or a zero budget. Neither was going to be applied with the GPU on either, and a warning that fires on every CPU-only launch is one people learn to scroll past.

The call sits outside the try that wraps plan construction. It only prints, and a display helper that stumbled inside it would be reported as invalid resource plan and take the launch down with it.

Verification

tests/test_auto_tier_vram_notice.py covers the decision in both directions, not just the message:

• a GPU build gets the tier with no flag (the defect: this used to be False), and the family's own binary is the one inspected;
• a CPU-only build still does not;
• --gpu none beats a GPU build, and needs no probe to decide;
• an explicit --gpu is taken at its word without a second probe that could only disagree with a decision already made;
• V4 uses its own probe and the generic one is never called for it;
• both notice messages, and the three silences.

Full suite on this branch rebased onto dev: python3 -m pytest tests/ -q — 939 passed, 161 skipped, 585 subtests passed.

Not verified here: no GPU on the machine this was written on. @troturier offered to test a patch on the reporting box (single 8 GB card, qwen36 and deepseek_v4 CUDA builds) — that is the measurement that would close this properly, since the claim is that --auto-tier alone now reaches the 21 tok/s that --auto-tier --gpu auto reached.