新手按教程装完 Ollama，一到「加载本地模型」就卡住：到底该 pull 官方库里现成的，还是把下载的 GGUF 和 Safetensors 文件导进去？加载完显存爆了、模型不回答、重启就没了，这些坑该怎么排？这篇按场景把三条加载路径、选模型前的算账、以及故障排查顺序讲清楚，看完能自己判断用哪条路。
很多人装完 Ollama，打开终端就开始搜「怎么加载模型」，结果第一步就卡住：到底该让它自己去官方库拉，还是把自己下载的文件导进去？其实这两件事对应的是完全不同的路径，选错了后面全是坑。这篇按场景把三条加载路径讲清楚，再讲加载前怎么算账、加载后怎么验证，以及卡住时按什么顺序排查。
先说明一点：下面所有涉及型号、参数量档位、硬件配置的具体数字，都不写死，因为不同卡、不同量化档位差得很多。需要对照数字时，直接去站内的部署测算页面按自己的硬件跑一遍，比看任何文章都准。
先分清三条加载路径，别一上来就导文件
Ollama 加载本地模型一共就三条路，判断标准很简单：看你手上有什么。只有模型名字、没有文件，走第一条；手上是一个 GGUF 文件，走第二条；手上是 Safetensors 全套权重，走第三条。三条路的命令和踩坑点完全不同，混着做最容易出问题。
- 路径一：从官方模型库按名字拉取，最省事，适合先把跑通流程这件事做完；模型名和标签的具体写法，到 /models 的部署测算页面对照确认，别凭记忆敲
- 路径二：手上有 GGUF 单文件时，写一个 Modelfile 指向文件路径，再执行 create 把它注册成本地模型；适合断网环境、自己量化过的权重、或者想固定用一个文件
- 路径三：手上是 Safetensors 全套权重时，Ollama 不直接吃，必须先转成 GGUF，这一步不能跳过，转了之后再按路径二走
- 判断标准补充：能联网且只是试用就走路径一；要离线、要省磁盘、要定制量化走路径二；拿到的是自己微调的产物，基本只能走路径三
这里有个容易忽略的点：路径二的 Modelfile 里写的是文件路径，不是模型名。路径写错了报错会很难懂，建议一律写绝对路径，先排除这个变量再谈别的。
加载前先算两笔账：显存放不放得下、磁盘够不够
新手最常见的失败不是命令写错，是模型根本放不进显存。粗算方法是用参数量乘每参数字节数，再留出上下文和运行缓存的余量。量化档位不同，这个结果能差出一倍，所以别用一个固定数字去套所有模型。具体换算直接到 /models/deploy 按你的卡算一遍，那里的数字是按当前模型库同步的。
| 要算的账 | 怎么估 | 什么情况下可以不算 |
|---|---|---|
| 显存占用 | 参数量 × 每参数字节数，再留上下文余量 | 纯 CPU 跑、内存远大于显存时可不看这条，但要留意内存带宽会成为瓶颈 |
| 磁盘空间 | 下载包和解包后的权重分开算，两者不是一回事 | 空间充裕时可以跳过，空间紧就先清旧模型再下新的 |
| 加载时间 | 看权重是不是被切成多份分片，分片越多加载越慢 | 在固态盘上、只偶尔加载一次时，这点差异可以忽略 |
加载完之后，怎么确认它真的在跑本地那一个
很多人加载完就直接接到应用里，出了问题分不清是模型的事还是客户端的事。稳妥的做法是先在命令行跑一句短提示，有正常输出再接应用。另外要养成看模型列表的习惯：列表里出现的名字如果和你以为的不一致，多半是你敲标签时敲错了，系统会悄悄去线上拉一个同名的回来，你以为在跑本地，其实在跑别的。
- 先命令行跑一句短提示，确认有输出，再接到应用里，不要在客户端里反复试错
- 核对模型列表里的名字和标签，名字带错就会去拉线上的同名模型
- 观察首次回答的等待时间，明显比后面几次长是正常的，说明正在从磁盘加载权重
- 多个工具共用一个实例时，先核对端口和地址，避免连到别处已经跑着的服务
加载失败或跑不动时，按这个顺序排查
排查最忌讳东试一下西试一下。下面这个顺序是从「最容易错、成本最低」排到「最麻烦」，按顺序走，基本不会绕远路。每一步都留下你敲的命令和报错原文，否则来回猜很浪费时间。
- 第一步：看文件路径Modelfile 里的路径写错、用了相对路径、文件名大小写不一致，都会报找不到文件。改成绝对路径再试一次。
- 第二步：看文件格式把 Safetensors 当 GGUF 传进去，模型能建成功，但一跑就崩。这是最常见的假成功，务必确认文件后缀和来源。
- 第三步：看显存加载到一半直接退出，或者回答慢得离谱，基本是显存不够。退回更低的量化档位重试，别硬扛。
- 第四步：看后台服务命令找不到模型时，先确认后台进程在不在。服务没起来的情况下，再好的模型也加载不了。
这套做法适合谁、成本怎么算、什么时候别用
本地跑模型不是零成本的。成本主要三块：硬件折旧、电费、以及你自己折腾的时间。前两块相对固定好估，第三块最容易被低估，尤其是第一次搭环境那几天。要算总账，可以把硬件投入加上几年电费摊平到每月，再和同任务走 API 的实际用量对比，测算方法见 /compute/tco，那里的数字按当前行情维护。
适用边界也要说清楚：本地部署适合离线可用、数据不出内网、需要反复调试提示词这几种场景；如果是多人高并发、需要长上下文大吞吐，单机基本顶不住，这类需求更适合走托管推理，成本对比到 /inference 看当时的数字。判断之前先想清楚你的真实并发是多少，不要拿单机试用的体验去推生产环境。
下一步如果你还没确定选哪个模型、或者手上这台机器到底能跑多大，先去部署测算页按硬件算一遍，再决定走哪条加载路径，比先下载再试快得多。→常见问题
下载好的 GGUF 文件直接放进模型目录，Ollama 能认出来吗？
不能。Ollama 只认自己登记过的模型，手动丢文件不会被识别。要用 Modelfile 写明文件路径，再执行 create 生成一个本地模型条目，之后才能按名字跑。目录结构也别自己猜，先确认模型存放位置再放文件。
加载时提示显存不足，是不是只能换小模型？
先别急着换模型。优先降量化档位，同样参数量下显存占用能砍掉一大截；其次缩短上下文长度，上下文也会吃显存；还可以把部分层放到 CPU 上跑，代价是速度变慢。这三招都试过还不够，才考虑换更小的模型。
同一台机器上多个人或多工具要用，需要各装一份吗？
不需要。本地服务起一个就够，其他工具通过地址连过来共用。要注意的是并发一高，排队会很明显，本地单机的吞吐有限。多人长期用的场景，比起在单机上硬撑，更值得评估托管推理的账。
