你可能已经在本地装了 Ollama，敲了命令也能对话，但想把它接进自己的程序、想让局域网里别的机器也能用、想换个大点的模型时就开始犯迷糊：端口在哪改、模型下到哪个目录、显存不够会怎样。这篇按「装—拉—用—接」的顺序把流程走一遍，每一步给判断依据和排查动作，并说明哪些情况下 Ollama 不是好选择。
本地跑大模型这件事，很多人第一步就装好了 Ollama，敲个命令能对话，觉得成了。但真正开始想把它接进自己的脚本、想让局域网里另一台机器也能调、想换个大一点的模型时，问题就冒出来了：端口在哪改、模型下到哪个目录、显存不够会怎样。这篇按「装—拉—用—接」的顺序把流程走一遍，每一步给判断依据和排查动作。
先说清楚 Ollama 的定位：它是个本地模型运行器，本质是启动一个常驻服务，再通过 HTTP 接口对外提供推理能力。理解这一点，后面所有配置问题都变成了「服务有没有起来、监听在哪、参数怎么传」这三个问题。
第一步：装完先确认它真的在跑
别急着拉模型。装好客户端后，先确认后台服务是否已经启动。命令行交互模式和常驻服务模式是两回事：前者关掉窗口就结束，后者才是你接应用时要依赖的东西。最省事的验证方式是发一次最简对话请求，确认「能出字」这条链路是通的。
- 确认服务进程用系统自带的进程查看命令，看有没有对应的服务进程在跑；没有就先手动启动，或者看安装时是否配置了开机自启。
- 确认监听端口用端口查看命令确认服务监听的地址和端口。默认只监听本机回环地址，这是后面局域网访问不到的根本原因。
- 发一次最简请求用命令行发一条最短的对话请求，看到有流式文字返回，就说明服务、模型加载、推理这条链路是通的。
- 报连接失败时按顺序排查先看服务进程在不在，再看端口有没有被别的程序占用，最后看本机防火墙有没有拦本地回环以外的访问。按这个顺序走，不要跳步。
拉模型：下到哪、占多少、怎么不重复下
拉取命令背后是「按层下载加本地缓存」的机制。同一系列不同规格会复用公共层，所以看着体积大，实际增量下载往往没有想象中夸张。模型默认存在用户目录下的隐藏文件夹里，这是后面换盘、迁移、清理空间的关键位置。
- 默认存储位置
- 用户主目录下的隐藏文件夹，删前先确认里面还有没有别的模型在用。
- 改存储路径
- 通过环境变量指定新的目录，改之前先把已有模型迁过去，否则等于全要重下。
- 量化档位
- 同一个模型的不同量化档位是各自独立的条目，拉过一档不等于有了全部。
- 断点续传
- 拉取中断不用清缓存，重新执行同一条命令会接着下。
- 想清楚自己机器的显存上限，再决定拉多大的参数量，别先下后愁
- 换盘或清理前，先确认哪些模型还在被脚本引用，避免删完发现任务跑不起来
- 同一系列只想试效果时，先拉小档位验证流程，通了再换大的
- 磁盘空间紧张时，优先清理长期没用过的模型条目，而不是整个缓存目录
| 现象 | 可能原因 | 先做什么 |
|---|---|---|
| 拉取很慢或卡住 | 网络波动或镜像源问题 | 重跑同一条命令，看是否能续传 |
| 提示空间不足 | 默认目录所在盘满了 | 改存储路径并迁移已有模型 |
| 拉完发现效果不对 | 档位或规格选错 | 确认条目名称，换档位重新拉 |
| 同一模型有两份 | 不同档位各存一份 | 保留在用的，清掉闲置的 |
日常使用：几个真正影响体验的设置
很多人改了参数发现没生效，问题出在参数分两层：一层是服务启动时的默认值，一层是单次请求里的覆盖值。搞混这两层，就会觉得配置「不听话」。日常最值得调的是上下文长度和并发数这两个。
输出慢通常卡在两个地方：模型本身太大装不下显存，被切到内存里跑；或者上下文开得过大，挤占了本可用于推理的缓存。排查思路是先看显存占用，再往下调上下文，不要一上来就换模型。
- 临时换参数用会话级设置试，别直接改全局配置
- 确认稳定后再固化到启动参数里，免得影响其它正在跑的脚本
- 上下文长度不是越大越好，够用就行，开太大反而拖慢响应
- 并发数要结合显存余量给，给太高会让每个请求都变慢
接进应用：把它当成一个本地接口来用
接应用的关键是记住三件事：地址、端口、以及它对外提供的是兼容常见接口规范的 HTTP 接口。绝大多数现成的 SDK 只要改个地址就能连上，不需要额外适配层。这一步的坑基本都在网络和超时上。
- 先在本机接通用你熟悉的语言或 SDK，把请求地址指向本机端口，跑通一次最简单的调用，确认接口形态没问题。
- 再考虑局域网要让别的机器访问，需要在启动配置里放开监听地址。放开之前先想清楚这台机器所在网络里都有谁，有没有必要加一层访问控制。
- 设置超时和重试本地推理首次加载模型可能明显偏慢，超时设太短会把正常加载误判成服务挂了。重试要区分「连接失败」和「推理超时」，前者重试有用，后者重试只会更堵。
- 量一遍延迟基线到 /tools/speed-test 记下这台机器上的实际响应水平，作为后续判断性能变化的参照。
| 接入环节 | 容易踩的坑 | 判断标准 |
|---|---|---|
| 地址与端口 | 只监听本机，外部连不上 | 先本机通，再放开监听 |
| 超时设置 | 太短，把加载误判为故障 | 首包慢但能出字，就说明是正常的 |
| 并发调用 | 多个脚本同时打，互相拖慢 | 观察显存余量，宁少勿多 |
| 长任务 | 单次请求跑很久无反馈 | 确认是流式还是等完整结果 |
什么情况下别用 Ollama
Ollama 的定位偏轻量，适合个人开发、本地验证和小规模自用。一旦进入多人共用或高吞吐场景，它的可调项就不够了，这时候硬扛不如换方案。判断标准很简单：看你的模型单卡放不放得下，看你是不是需要稳定的并发吞吐。
- 要服务多人、追求高并发吞吐时，先看 /vllm-vs-ollama-selection 里的选型思路，别硬扛
- 需要多卡张量并行跑超大模型、或要精细控制显存分配比例时，它的可调项不够，属于能用但不好用那一类
- 团队协作场景下，每个人本地各拉一份模型会重复消耗磁盘和带宽，更适合一台机器集中部署、其他人走接口
- 对推理延迟有硬性要求的生产场景，先评估清楚再决定是否用它顶在前面
反过来说，如果你的需求是本地快速验证想法、给个人工具接一个不依赖外网的模型能力，那 Ollama 的安装和接入成本都很低，是合适的起点。判断自己属于哪一类，比纠结工具本身更重要。
下一步把你机器上的实际响应水平和显存占用测一遍，再对照选型页面确认当前方案是否够用，心里就有数了。→常见问题
拉下来的模型到底存在哪个文件夹，能挪到别的盘吗？
默认放在用户目录下的隐藏文件夹里，可以通过环境变量指定新的存储位置。重点是把已有模型一起迁过去再改配置，改完重启服务确认还能正常加载，不然会出现「模型明明下过却找不到」的情况。
局域网里别的电脑连不上我本机的 Ollama，先查哪里？
按顺序：一是服务有没有配置成监听所有网卡，默认只监听本机；二是对方访问的 IP 和端口有没有写对；三是本机防火墙有没有放行该端口。三项都对还连不上，就在本机用同一地址自测一次，能通说明问题在对端网络。
本地跑起来输出很慢，是模型选大了还是设置问题？
先看显存占用，模型放不进显存被切到内存是最常见原因，这种情况下换个更小的参数量或更低量化档位最直接。如果显存有富余还慢，就往上下文长度和并发数上找，把它们调小再测一遍，到 /local-inference-speed-tuning 有更细的排查顺序。
