ollama使用本地模型

很多人手上已经有一份下载好的模型权重，想用 ollama 直接跑，结果一执行就报格式不支持或找不到模型。这篇不重复「怎么选模型」「要不要自建」，只解决一件事：从你硬盘里那份文件出发，判断它能不能被 ollama 吃下、该放到哪、用什么指令挂上去、怎么确认真的跑起来了。

手里已经有一份下载好的模型权重，想直接丢给 ollama 跑起来，结果第一条命令就报格式不支持、或者拉起来说找不到模型——这几乎是每个人都会踩一次的坑。问题通常不在 ollama 本身，而在于它读模型的方式和你的直觉不一样：它不认「你给的路径」，只认自己模型存储目录里已经登记过的东西。

这篇只解决一件事：从你硬盘上那份现有文件出发，判断它能不能被 ollama 吃下、该放到哪、用什么指令挂上去、怎么确认真的跑起来了。至于该不该自建、选哪个模型，站内别的地方讲得更细，这里不绕。

先确认你手里的文件 ollama 到底认不认

ollama 直接吃的是 GGUF 这一路的单文件权重。换句话说，扩展名和目录结构决定了你要不要先做一步转换，而不是命令写错。动手前先看清楚：是一整个目录配一堆分片，还是单独一个权重文件，两者的后续路径完全不同。

• 看扩展名：是不是 gguf，不是就先规划转换这一步；
• 看目录结构：权重文件是否齐全，config 有没有配对的权重；
• 看来源：Hugging Face 原始权重一般要先做量化转换，转换工具和量化档位的取舍可以对照 /tools 里的本地工具与 /ai-dict/category/tech 的量化名词；
• 看依赖：模型有没有带自定义代码、特殊算子，这类基本要改代码才能转；
• 拿不准格式归类的时候，先去 /stacks/atlas 顺一遍名词，别靠猜。

文件放哪、怎么挂进 ollama 的模型列表

很多人卡在这一步，是因为以为执行命令时传个本地路径就行。实际上 ollama 是「把模型存进自己的模型目录」，再从目录里按名字加载。所以核心动作是两件事：先搞清楚当前模型目录在哪，再决定是移文件进去，还是改环境变量把目录指到你放权重的地方。

1. 查当前模型目录先确认服务当前实际读的是哪个目录，别凭记忆。用环境变量或启动参数查看，不确定就重启服务后观察新文件落在哪，以此反推真实路径。
2. 选落地方式一次性导入：写一份 Modelfile，用 FROM 指向你的本地 GGUF 文件，再 create 成 ollama 里的模型名；批量迁移：直接把文件放进模型存储目录，重启服务让它自行识别。
3. 改路径前先备份改存储位置前把原目录内容备份出来，改完重启服务，再验证模型列表里能不能看到新条目。路径相关的排查顺序可以参考站内 /models/deploy 的思路。
4. 验证登记成功列出模型清单，确认名字和体量对得上；名字对不上说明 create 那步的名字和调用时写的不一致，这是最高频的低级错误。

跑通验证：从命令行到接口一条链走完

模型列出来了不代表能用。验证要分三层：命令行单轮对话确认权重真的加载成功；接口发一条请求确认服务层正常；最后看一眼输出速度是否可接受。三层都过了，才算这条链真的通了。

接口层最容易出问题的是地址和端口对不上。ollama 服务默认对外暴露一个本地 API 地址，别的应用要接它，走的就是这个地址，具体地址形态在 /ai-dict/category/infra 有名词对照，别自己拼。输出慢也别急着怪模型，先排除是不是跑在 CPU 上、有没有分到显存，接口延迟基线可以用 /tools/speed-test 先量一遍再对比。

• 命令行能答，接口不通：先看服务是否在监听、地址端口是否写对；
• 接口通但很慢：查是否落到了 CPU、有没有吃满显存；
• 命令行直接报错：回到上一节查模型目录和名字；
• 只能一次性试跑的场合：并发和常驻显存配置可以先跳过。

导入失败时的排查顺序

报错别乱试，按固定顺序过一遍，能省掉大量来回折腾。顺序本身比具体命令重要：先排除格式，再排除完整性，然后才是路径和服务，最后才怀疑硬件。

1. 查格式文件是不是 ollama 认的形态，不是就回到转换这一步，别在导入命令上死磕。
2. 查完整性中途断掉的下载很常见，权重分片缺失会导致加载到一半崩掉，重新核对文件清单。
3. 查路径模型目录对不对、名字写没写错，报错里出现找不到模型基本都在这。
4. 查服务改完配置有没有重启，很多「没生效」只是进程还跑着旧配置。
5. 查显存前面都对还崩，才轮到看显存和量化档位是否匹配。需要核对具体模型体量与显存的关系，去 /models 看当时的模型资料，不要去背死数字。

导入 ollama 的失败，十次里有八次是格式没认、路径没对，剩下两次才是硬件和算子。