Summary

Loading a multimodal model whose mmproj.gguf declares a projector type the bundled llama.cpp build doesn't support crashes the entire llama-server process (SIGABRT) during mmproj warmup. The UI surfaces only a generic "Failed to load the model — The model process encountered an unexpected error." There is no graceful fallback and no actionable message.

Reproduced with unsloth/gemma-4-E4B-it-IQ4_XS on macOS arm64, app 1.1.97, backend b9495/macos-arm64 (bundled).

Root cause

Gemma 4 (the new gemma4_unified, encoder-free + native-audio line, 12B released 2026-06-02) ships an mmproj that carries two projector types. Read directly from the model's mmproj.gguf metadata on disk:

clip.vision.projector_type = gemma4v
clip.audio.projector_type  = gemma4a     (+ clip.has_audio_encoder)

The libmtmd in b9495 has no graph builder for (at least) the brand-new audio projector gemma4a, so it aborts:

tools/mtmd/clip.cpp:4391: Unknown projector type
ggml_abort
  → clip_graph::clip_graph
  → clip_image_build_graph
  → clip_model_loader::reserve_compute_meta / warmup
  → clip_init → mtmd_context → mtmd_init_from_file
  → server_context_impl::load_model
llama.cpp exited with error code ExitStatus(unix_wait_status(6))   # SIGABRT

This happens before the server reports ready, so the model never starts — not even text-only.

Evidence it's projector-specific (not a general backend/hardware fault)

In the same session, the same b9495 backend successfully loads a different multimodal model (unsloth/Qwen3_5-9B + its mmproj): srv load_model: loaded multimodal model, server listening, inference runs. So mtmd works in general — b9495 just doesn't know the Gemma 4 projectors.

Additionally, b9495 is the newest backend the app offers for macos-arm64 (list_supported_backends: b9495, b9493, b9482, b9479, b9453, …), so the user cannot switch to a newer in-app build that would support gemma4a.

Why this matters / what's wrong on our side

1. No graceful handling. A projector the runtime can't parse takes down the whole llama-server with SIGABRT, and the user sees only "unexpected error" — no hint that it's a model/backend multimodal-compat issue.
2. No text-only path. The provider always appends --mmproj when an mmproj.gguf is present (validate_mmproj_path / arg builder), so a model with an unsupported projector can't even be run text-only from the UI.
3. No compat gate. We don't check whether the active backend's mtmd supports the model's projector type before launching.

Proposed fixes (pick/triage)

• Detect mmproj/projector failure and fall back to text-only: on a load crash whose stderr contains Unknown projector type (or mtmd abort), retry once without --mmproj and surface a non-fatal notice ("vision/audio disabled: this model's projector isn't supported by the current llama.cpp backend").
• Or add a "disable vision/audio (text-only)" toggle to the Llama.cpp provider so multimodal models can run text-only on purpose.
• Surface a real error message instead of the generic one — parse the clip.cpp … Unknown projector type line and tell the user the backend is too old for this model's projector.
• Backend currency / gate: track upstream gemma4v/gemma4a mtmd support and bump the bundled macOS build once it lands; optionally gate the recommendation so we don't offer to run a gemma4a mmproj on a backend that can't parse it.

Environment

• App: Atomic Chat 1.1.97 (macOS arm64, Apple M3 Pro)
• Provider/backend: llamacpp-upstream, b9495/macos-arm64 (bundled)
• Model: unsloth/gemma-4-E4B-it-IQ4_XS (Gemma 4, vision gemma4v + audio gemma4a)
• Working comparison in same session: unsloth/Qwen3_5-9B multimodal loads fine on the same backend.

Note: separate from #42 / #43 (Windows CUDA-13 download). This is a macOS multimodal-projector compat + error-handling issue.