openbmb/minicpm-v4.7:35b-a3b fails: “unknown projector type: minicpmv4_7” (Failed to load CLIP model) on Windows, 0.40.3

快速结论：当你在 Ollama 0.40.3/0.40.4 上加载 MiniCPM-V 4.7（含 35B-A3B、1B 等变体）时，Ollama 内置的 llama-server 无法识别该模型的投影器（projector）类型，报错 openbmb/minicpm-v4.7:35b-a3b fails: “unknown projector type: minicpmv4_7” (Failed to load CLIP model)。优先排查方向是 Ollama 捆绑的 llama.cpp 版本是否已包含 MiniCPM-V 4.7 支持，而不是模型文件本身损坏。

适用环境：已确认复现的环境包括 Windows 11 Pro + RTX 5080 16 GB（驱动 617.42，31 GB RAM）+ Ollama 0.40.3（0.40.4-rc1 未测）；以及 macOS 26.6.2（25G83）+ Apple M4 10 核 + 16 GB 统一内存，在 Ollama 0.40.3 与官方 0.40.4 版（ollama-darwin.tgz，隔离端口 11435）上均复现。

最快修复方案：暂无已发布版本中的一步修复方案。Issue 中验证过的修复是升级 Ollama 的 llama.cpp 捆绑版本：上游 llama.cpp PR #29416 已加入 MiniCPM-V 4.7 支持，需要让 Ollama 同步到 b11551 之后（当时 Ollama 的 LLAMA_CPP_VERSION 固定在 b11521）。对应的 PR #19024 已提交；在 macOS M4 + 1B 模型的源码构建上，文本与图像请求从 HTTP 500 变为 HTTP 200。在官方发布包含该修复之前，可优先尝试使用包含此补丁的 Ollama 构建，或等待官方版本更新。

注意事项：上述修复验证仅覆盖 macOS/M4 与 MiniCPM-V 4.7 1B 模型，Windows/CUDA 以及本 Issue 原始的 35B-A3B 变体尚未验证；PR #19024 仍在等待维护者审批，CI 也尚未跑完。不要误以为重新拉取模型或校验哈希能解决该问题——Issue 中已多次重新拉取并验证文件，仍然失败。

问题场景

用户在 Ollama 中运行 MiniCPM-V 4.7 系列模型时触发该问题。原始报告使用 ollama run openbmb/minicpm-v4.7:35b-a3b（22 GB，Q4_K_M），模型加载约 22 秒后失败，报 “Failed to load CLIP model”。由于投影器随模型一起加载，纯文本提示同样失败。后续复现使用官方 Hugging Face 的 MiniCPM-V-4.7-1B-gguf Q4_K_M 加 F16 投影器，通过本地 Modelfile 导入，文本与 base64 PNG 图像请求在两个 Ollama 版本上都返回 HTTP 500。同一批经过哈希校验的文件在独立 llama.cpp b11609 上可以正常处理文本与图像请求。

报错原文

clip_model_loader: model name:   35a3_hf_v47_0923
clip_model_loader: GGUF version: 3
clip_model_loader: n_tensors:    460
clip_model_loader: has vision encoder
clip_ctx: CLIP using CUDA0 backend
clip_init: failed to load model '...\blobs\sha256-bff3b688e14c300eca273092c37c50a0ddfcc2054e079af1a0480edeed5d20f1': load_hparams: unknown projector type: minicpmv4_7
mtmd_init_from_file: error: Failed to load CLIP model from ...\blobs\sha256-bff3b688...
srv  llama_server: exiting due to model loading error
level=ERROR source=llama_server.go:1029 msg="llama-server terminated" error="exit status 1"

0.40.4 上的对应日志：

clip_init: failed to load model '<MODEL_STORE>/sha256-fb9cc047a3cdad5317fd8433a4aeda2d22f00f02ca4bd93b34ad84165b25a900': load_hparams: unknown projector type: minicpmv4_7
mtmd_init_from_file: error: Failed to load CLIP model
srv  llama_server: exiting due to model loading error

原因分析

Issue 的 server.log 已给出明确根因：Ollama 捆绑的 llama-server 不认识该模型的投影器类型，抛出 load_hparams: unknown projector type: minicpmv4_7，随后 mtmd_init_from_file 报 “Failed to load CLIP model” 并导致进程退出。也就是说，这是一次加载器/推理可用性问题，不是模型权重损坏或下载不完整。上游 llama.cpp 在 PR #29416 中加入了 MiniCPM-V 4.7 支持；而 Ollama 当时（0.40.4 与 main）的 LLAMA_CPP_VERSION 都固定在 b11521，尚未包含该支持，因此需要同步到 b11551 之后。独立 llama.cpp b11609 能加载同一批文件，也侧面印证问题出在 Ollama 侧的捆绑版本，而非 GGUF 文件。

环境排查

确认 Ollama 版本：0.40.3 与 0.40.4 均已确认存在该问题。
确认 Ollama 捆绑的 llama.cpp 版本：检查仓库中的 LLAMA_CPP_VERSION，Issue 中 0.40.4 与 main 均固定为 b11521。
模型文件哈希是否与官方一致：Issue 中 1B 版 Q4_K_M 为 588c6c94c82f756b86dba35c42ed9ba9ec187d65824eb52f039c347df563e63d，mmproj F16 为 fb9cc047a3cdad5317fd8433a4aeda2d22f00f02ca4bd93b34ad84165b25a900，校验通过仍复现，可排除文件损坏。
操作系统与硬件：Windows 11 Pro / RTX 5080（驱动 617.42）；macOS 26.6.2 / Apple M4 / 16 GB。
可对照测试同一批文件在包含上游修复的 llama.cpp（如 b11609）上是否可加载，以确认问题在 Ollama 侧。

解决步骤

先确认这不是模型文件问题：重新拉取后核对 SHA256，若校验一致仍报 unknown projector type: minicpmv4_7，可直接跳到下一步。
确认当前 Ollama 版本及 LLAMA_CPP_VERSION。若仍固定在 b11521 或更早，说明尚未包含 MiniCPM-V 4.7 支持。
可优先尝试等待或升级到包含 llama.cpp b11551 之后版本（含上游 PR #29416）的 Ollama 发布版。当时对应的修复 PR 为 #19024，将 llama.cpp pin 从 b11521 更新到 b11551。
若必须立即验证，可在 macOS M4 环境按 PR #19024 的思路自行源码构建（该路径已在 Issue 中验证：1B 模型文本与图像请求均返回 HTTP 200）。Windows/CUDA 与 35B-A3B 未验证，不建议直接假定同样有效。
如使用本地导入方式（FROM ...gguf + FROM ...mmproj-model-f16.gguf），确保投影器文件与主模型来自同一官方发布版本，并使用 ollama create 重新创建。

验证方法

在包含修复的构建上，用同一批官方模型文件重新执行 ollama run 或 /api/generate：若原先返回 Failed to load CLIP model / HTTP 500 的请求变为正常回答（Issue 中文本检查返回 OK，纯红图像返回 Red），且 server.log 中不再出现 unknown projector type: minicpmv4_7，即视为已解决。注意该验证目前仅覆盖 macOS/M4 + 1B 模型。