A model listed as able to read images has to read them, or say it cannot.

`Qwen3.5-9B` was listed with `image_to_text` and answered every photograph
with "a blank white image with no visible content" — nine real pictures of
one video, indexed as blank. Two causes, one symptom:

  AutoModelForCausalLM        -> Qwen3_5ForCausalLM            (text only)
  AutoModelForImageTextToText -> Qwen3_5ForConditionalGeneration

The engine asked for the first, so the tower was never built, and with no
projector the chat path flattened the picture to the literal text
"[image_url content]". The model was answering the prompt it was given.

Now the class comes from the checkpoint's own config, every load path in the
CUDA backend goes through that resolver, a vision model also loads the
processor that makes a picture promptable, and an image request takes its own
generation path (no KV prefix reuse — image tokens come from the pixels).
Where a model genuinely cannot see, the request is a 400 rather than a
confident wrong answer, and a GGUF with no mmproj stops advertising the
capability it cannot serve.

Two things found while measuring the image path on a live fleet:

* every image load printed "Proactive eviction skipped: name 'request' is not
  defined". `_load_diffusers_pipeline` has no `request`; the NameError was
  swallowed as a skip, so the minimum-eviction block never ran and each load
  fell through to the blunt eviction that unloads models which would have
  fitted alongside.
* `Z-Image-Turbo`, distilled for 8 steps at CFG 1, was served at 30 steps and
  CFG 7.5 because its card carried no `defaults` — four times the work for an
  over-guided picture, ~72 s a still. A card that says nothing now falls back
  to what the model's own name says before the generic floor.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3rZozi1Ehk96NG1WesgC