HuggingFace to Ollama

快速结论：此报错通常发生在尝试用 ollama run hf.co/<owner>/<repo>:<quant> 直接拉取 HuggingFace 上分片（sharded）GGUF 模型的场景。优先排查该仓库是否只包含分片文件，因为 Ollama 注册表拉取尚不支持分片 GGUF，需改为下载到本地目录后用 ollama create 合并。

适用环境：Ollama（版本未在 Issue 中明确）；HuggingFace 分片 GGUF 仓库（示例：unsloth/Qwen3.8-Flash-Next-GGUF，量化 UD-IQ4_XS，含 mmproj-BF16.gguf 视觉投影文件）；下载工具 hf（huggingface-cli 新命令）；操作系统、Python、CUDA、显卡型号在 Issue 中未确认。

最快修复方案：下载分片到本地目录，创建引用该目录（及 mmproj）的 Modelfile，执行 ollama create：
hf download --local-dir . unsloth/Qwen3.8-Flash-Next-GGUF --include "UD-IQ4_XS/*" --include mmproj-BF16.gguf
ollama create unsloth/Qwen3.8-Flash-Next-GGUF:UD-IQ4_XS -f <(echo FROM `pwd`/UD-IQ4_XS ; echo FROM `pwd`/mmproj-BF16.gguf)

注意事项：此方案已在 Issue 中实际验证成功，但依赖 bash 进程替换（<(...)），在非 bash 环境需改为先写实际 Modelfile 文件。Ollama 不会像 llama-gguf-split 那样合并出单一文件，而是将分片作为独立 blob 存入 blobs 目录并生成 manifest；因此不能等到“合并完成”再验证，应直接看 ollama create 是否 success。仓库若为 gated，仍需先配置 HF token。

问题场景

用户想从 HuggingFace 导入 GGUF 模型到 Ollama。其脚本原本计划借助 llama-gguf-split 把分片合并成单一文件再导入。实际尝试用 ollama run hf.co/unsloth/Qwen3.8-Flash-Next-GGUF:UD-IQ4_XS 直接从注册表拉取带视觉投影（mmproj）的分片仓库时触发报错。该 Issue 标签为 feature request，讨论中确认了现有替代做法。

报错原文

$ ollama run hf.co/unsloth/Qwen3.8-Flash-Next-GGUF:UD-IQ4_XS
pulling manifest
Error: pull model manifest: 400: {"error":"This repository only contains sharded GGUF files. Ollama does not yet support pulling sharded GGUF via the registry; please download the shards and merge them locally with ollama create (workaround detailed at https://github.com/ollama/ollama/issues/5245), or use a repository with single-file quantizations."}

原因分析

直接原因：目标仓库只包含分片 GGUF 文件，而 Ollama 注册表拉取路径（hf.co/... 方式）尚不支持分片 GGUF，因此返回 400 并拒绝拉取。

讨论中澄清了一个容易误解的点：llama-gguf-split 合并并非必需。把包含分片的目录传给 ollama create 即可，Ollama 服务端会自行组装统一模型。但它并不是像 llama-gguf-split 那样生成一个单一文件，而是把原始分片作为独立 blob 存入 Ollama 的 blobs 目录，并生成 manifest 告知 llama-server 加载哪些 blob。视觉模型还需把 mmproj 文件作为第二个 FROM 加入。

环境排查

确认 Ollama 已安装且命令可用（版本未在 Issue 中给出，建议使用较新版本）。
确认 hf 下载命令可用，且已登录或配置 token（gated 仓库必需）。
确认目标仓库的量化目录名与文件名（示例为 UD-IQ4_XS/ 与 mmproj-BF16.gguf）。
确认分片文件（如 *-00001-of-0000N.gguf 系列）全部下载完整、无缺失。
确认 shell 为 bash，以支持 <(...) 进程替换。
Python、CUDA、PyTorch、显卡型号与显存情况在 Issue 中未涉及，不在本次排查范围。

解决步骤

将分片和 mmproj 下载到本地目录：

hf download --local-dir . unsloth/Qwen3.8-Flash-Next-GGUF --include "UD-IQ4_XS/*" --include mmproj-BF16.gguf

创建引用分片目录和 mmproj 的 Modelfile 并执行 ollama create：

ollama create unsloth/Qwen3.8-Flash-Next-GGUF:UD-IQ4_XS -f <(echo FROM `pwd`/UD-IQ4_XS ; echo FROM `pwd`/mmproj-BF16.gguf)

若进程替换不可用，可先手写 Modelfile，内容为两行 FROM（绝对路径指向分片目录和 mmproj 文件），再用 ollama create ... -f Modelfile。
无需再用 llama-gguf-split 合并文件；脚本中的合并步骤可以去掉，仅保留下载和（如有需要的）元数据处理（可优先尝试）。

验证方法

运行 ollama create 后应看到 success，日志中列出多个 using existing layer sha256:...。随后执行 ollama run unsloth/Qwen3.8-Flash-Next-GGUF:UD-IQ4_XS，能正常对话即文本部分正常；再输入类似 describe ./image1.jpg，若模型能读取并描述本地图片，说明 mmproj 视觉部分也加载成功。Issue 中正是以此方式确认修复。