Qwen3.8-27B is built on the Qwen3.5 architecture — the model version and the
architecture name are different numbers, and both our GGUFs and Qwen's own
config say qwen35 / qwen3_5. llama.cpp's qwen35 support was contributed without
vision and states it three times: #19435 "Qwen3.5 dense and MoE support (no
vision)", merged; #19456 "Qwen3.5 support w/o vision"; and #22954, open, which
says outright that the text-only qwen35.cpp does not load the vision encoder
tensors and whose fix merely relaxes the tensor-count check so multimodal GGUFs
can load as text-only.

That accounts for everything measured. The mmproj loads because clip loading is
architecture-independent, mtmd injects the image tokens, and the tokenizer
carries the three vision markers at the ids the base config names — so the model
notices whether an image was sent and says so when none is. There is simply no
code in qwen35.cpp to consume the embeddings, so the content contributes nothing
and the answer never varies.

Eight theories died to reach a conclusion that was in the title of a search
result seen at the start: dimensional mismatch, missing deepstack, a bad
artifact, our own image-token floor, a stale llama.cpp, CUDA flash attention, the
abliterated fine-tune, and finally the base model — which fails identically, so
it is the architecture and not the weights. Two of those were written into these
docs as settled before being tested, and the doc now records that as a method
failure: everything was argued from reading rather than running, and the upstream
tracker should have been the first stop rather than the eighth.

mmproj stays off the qwen38 cards; vision goes to gemma-4-31B-heretic, which
reads the same images exactly. The base Qwen3.8-27B download is kept as a
non-abliterated text model with no projector.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3rZozi1Ehk96NG1WesgC