把已经下载好的 gguf 交给 Ollama 使用，实际动作只有三步：写一个 Modelfile 指向 gguf 文件、用 ollama create 注册成模型名、再用 ollama run 或 HTTP 接口验证输出。命令本身很短，容易卡住的地方通常不在命令，而在 gguf 的模型架构是否被当前 Ollama 版本支持、chat template 和 stop token 是否和模型匹配、以及上下文长度是否超出机器能承受的范围。
Ollama 部署自定义 gguf 的前提是：gguf 已经量化完成、架构被当前 Ollama 支持、Modelfile 里的模板和停止符与模型训练时一致。处理路径是「确认架构与硬件 → 写 Modelfile → ollama create → 命令行与 API 双向验证」。如果加载时报 unknown architecture 或输出不停、模板标签外泄，先怀疑版本兼容和 TEMPLATE 缺失，而不是改参数硬调。多模态 gguf、需要微调、需要非 GGUF 格式的场景不适用这套流程。
先确认当前场景和目标
这套流程适用于「手上有现成 gguf 权重，希望在本机或内网用 Ollama 提供命令行和 HTTP 推理」的情况。gguf 已经是打包好的推理格式，不需要再做转换；如果手上的还是 safetensors 原始权重，需要先用 llama.cpp 的转换脚本导出 gguf，那属于另一步工作。
- 确认 Ollama 版本与模型架构：先执行
ollama --version，再看 gguf 来源说明里的架构名（llama、qwen2、gemma、phi3 等）。GGUF 格式本身在演进，用较新工具链量化出的文件，旧版 Ollama 可能直接报不支持。 - 确认模型自带的对话格式：指令微调模型通常有固定的 chat template 和结束符（如
<|im_end|>、</s>）。这一项缺失时，模型往往表现为答非所问或一直续写。 - 确认硬件余量：参数量乘量化位数大致决定显存或内存占用，上下文长度会在此基础上继续增加。先按保守的上下文跑通，再往上调。
- 确认交付形态：只在本地命令行试跑，还是要给应用通过
http://127.0.0.1:11434调用；是否需要改模型存放目录、是否需要局域网访问。这些决定后面要不要动环境变量。
按这个顺序处理
建议把 gguf 放在一个独立目录里，不要直接塞进 Ollama 自己的模型仓库目录，避免后续清理时误删。ollama create 会把 gguf 复制进 Ollama 的 blobs，所以创建完成后磁盘上会同时存在两份，需要预留空间。
- 在 gguf 同级目录新建
Modelfile，内容按下面的骨架改。路径、模型名、停止符、系统提示都要替换成自己的值。
# 相对路径以 Modelfile 所在目录为基准，也可以写绝对路径
FROM ./models/your-model.Q4_K_M.gguf
PARAMETER num_ctx 4096
PARAMETER temperature 0.7
PARAMETER top_p 0.9
PARAMETER stop "<|im_end|>"
SYSTEM """你是一个简洁的中文助手。"""
# 下面这段是 ChatML 风格示例，务必按模型自带的模板替换
TEMPLATE """{{ if .System }}<|im_start|>system
{{ .System }}<|im_end|>
{{ end }}{{ if .Prompt }}<|im_start|>user
{{ .Prompt }}<|im_end|>
{{ end }}<|im_start|>assistant
"""- 在 Modelfile 所在目录执行创建命令，模型名自己定，建议带上参数量和量化等级便于区分：
ollama create your-model-q4 -f ./Modelfile- 创建完成后立刻用
ollama list确认条目存在、大小与源文件量级相符；再用ollama show your-model-q4 --modelfile回看注册进去的参数和模板，确认没有被漏写。 - 命令行跑一轮：
ollama run your-model-q4，先问一个短问题，再带 system 提示问一次，观察格式是否正常。 - 如果应用要调用，直接打 HTTP 接口验证，请求体按下面替换模型名：
curl -s http://127.0.0.1:11434/api/tags
curl -s http://127.0.0.1:11434/api/chat -d '{"model":"your-model-q4","messages":[{"role":"user","content":"用三句话说明什么是 GGUF"}],"stream":false}'改完后怎么验证
验证不要只看「有没有报错」，要看输出形态是否符合预期。下面几项可以逐条过一遍：
- 模型注册成功：
ollama list能看到模型名，/api/tags返回的模型列表里也有同名条目。预期信号是名称、大小稳定，不会每次查询都变化。 - 模板生效：回答里不应出现
<|im_start|>、<|im_end|>这类原始标签。出现标签说明 TEMPLATE 与实际模型不匹配，或者模板里漏了 assistant 起始段。 - 停止符生效：回答结束后不再继续自问自答或输出无关文本。如果停不下来，补
PARAMETER stop，并确认停止符字符串与模型一致。 - 系统提示生效：同一条用户提问，分别带和不带 SYSTEM 各问一次，回复风格应有可感知差异；若无差异，检查 TEMPLATE 里是否真的引用了
.System。 - 上下文长度可用：喂一段接近
num_ctx的长文本让模型复述要点，观察是否被截断、是否变慢到不可接受。同时看ollama serve的前台日志，确认模型加载时有卸载到 GPU 的记录，而不是全程跑在 CPU 上。
容易忽略的边界
- 版本兼容是首要变量：较新工具链量化出的 gguf、或 Ollama 尚未收录的新架构，加载时可能报 unknown model architecture。处理顺序是先升级 Ollama 再重试；仍不行就用同模型更常见的量化版本重新导出。不要靠改文件名绕过。
- 模型目录变更需要重启服务：调整
OLLAMA_MODELS指向新目录后，要重启 Ollama 服务才生效；已创建的模型不会自动迁移，需要在新目录下重新 create。以 systemd 方式运行时，服务用户通常是ollama，新目录的读权限要单独确认。 - 默认只监听本机：Ollama 默认绑定
127.0.0.1:11434，局域网内其他机器访问不到。改成对外监听前要先想清楚认证与访问控制，Ollama 自身不带账号体系，不建议直接把端口暴露到不受控网络。 - 上下文长度不是越大越好：
num_ctx调大会直接抬高显存占用，超出显存后会回落到 CPU 参与计算，速度下降明显。稳妥做法是从较小值跑通，再按实际业务需要的长度逐步加。 - 多模态与适配器需要额外文件：带视觉能力的 gguf 通常还要配套的投影文件，LoRA 适配器需要用
ADAPTER单独声明。这两类能否直接接入，需要结合当前 Ollama 版本确认，不能按纯文本模型的经验照搬。 - 回退方式：保留原始 gguf 和 Modelfile，模型跑不通时执行
ollama rm 模型名删掉注册项即可，源文件不受影响。整套流程不适用于需要微调训练、或必须使用非 GGUF 格式权重的场景。