I wrote into the docs that our llama.cpp predating b4aa7dd47 ("mtmd : use
align_corners for qwen3vl vision position embedding interpolation") was "the
actual cause" of Qwen3.8-27B describing every image identically. The argument was
a plausible commit plus date arithmetic — 0.3.30 vendors llama.cpp from
2026-06-16, the fix landed 2026-07-21, 0.3.36 vendors 2026-10-01 — and every
observation fitted it. I had not run it.

Tested now: 0.3.36 built from source with the full
-DGGML_CUDA=ON -DGGML_VULKAN=ON -DGGML_RPC=ON set and put into service. The same
two images still return byte-identical answers. The fourth theory joins the other
three, and the doc says so.

What the test buys is that the last candidate is eliminated by experiment rather
than argument. The remaining reading is that the qwen3vl graph does not fit this
model at all — the base is qwen3_5 while the projector declares qwen3vl_merger —
and no version bump addresses that. mmproj stays off the qwen38 cards; vision
goes to gemma-4-31B-heretic, which reads the same images correctly.

The rebuild was worth doing for everything else, and it needed three fixes to
complete at all:

  * build-rpc-server.sh asked for the `rpc-server` CMake target, renamed
    upstream to `ggml-rpc-server`. It now asks the generator which exists, so it
    spans both.
  * my first version of that detection used `grep -q` under `set -euo pipefail`:
    grep exits on first match, closing the pipe, cmake dies on SIGPIPE, and
    pipefail reports the pipeline as failed — a SUCCESSFUL match tested as a
    failure. Matched in pure bash now. It passes in a toy test because printf
    finishes before the pipe closes, so the race only appears with a slow
    producer.
  * Dockerfile.update-llama EXECUTED `rpc-server --help` at build time, which
    needs libcuda.so.1 — the driver, absent from any build by definition. The
    file's own comment eleven lines above states the rule ("the check is ldd,
    not import"); the wheel check obeyed it and this one did not. It had never
    been reachable before, so the first build to get that far could not pass.
    Now checks linkage and tolerates only libcuda being unresolved.

And Dockerfile.update now carries vosk and g++, because the incremental overlay
never touches the venv: an updated image shipped without vosk while /v1/models
advertised vosk-en and vosk-it, and without any C++ compiler at all, which is
what XTTS's Japanese phonemiser needs to build.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3rZozi1Ehk96NG1WesgC