ollama main 怎么使用

你大概是在 GitHub 上翻到 Ollama 仓库，发现默认分支叫 main，README 里的安装命令和源码里的入口对不上，于是犹豫该装发行版还是自己编一份。这篇按「先跑起来再改代码」的顺序，把 main 分支的入口关系、本地编译和常见报错捋一遍，顺手给出什么时候你其实不该碰 main 的判断。

你大概是在 GitHub 上翻到 Ollama 仓库，发现默认分支叫 main，README 里的安装命令和源码里的入口对不上，于是犹豫该装发行版还是自己编一份。这篇按「先跑起来再改代码」的顺序，把 main 分支的入口关系、本地编译和常见报错捋一遍，顺手给出什么时候你其实不该碰 main 的判断。

先说结论方向：读源码和跑推理是两件事。只想用模型，装发行版就够；想改服务端实现、加接口或换量化加载逻辑，才值得编 main。把这两条线分清楚，后面大部分坑都能绕开。

先搞清 main 分支和发行版的关系，别把入口搞混

main 是开发主线，发行版是打好的安装包，两者命令行名字一样但来源不同。同机装两套会互相盖路径，先用 which 和版本输出确认当前生效的是哪一份，再决定要不要动手编译。

main 上的构建产物默认落在仓库目录里，不会自动替换你可能已装的系统级命令。想同时留两套就得靠显式路径调用，别指望包管理器帮你分。这一条是后面所有排查的前提。

• 先跑 which 看当前生效的是哪份命令，再对一次版本输出，别凭印象。
• 只做推理、不改代码，就老实装发行版，去 /models/deploy 按显存挑模型。
• 只有要读服务端实现、加接口或改量化加载逻辑，才值得编译 main。
• 生产环境、需要长期稳定版本号的场景别用 main，一次拉取就可能引入未验证改动。

从 main 跑起来的最小动作

按仓库说明先装编译期依赖，一般是 Go 工具链，涉及 GPU 时还要对应的驱动与加速库。依赖装不齐时编译报错通常出现在链接阶段，而不是代码本身，别一看到报错就去翻源码。

1. 装依赖按仓库说明装 Go 工具链，涉及 GPU 时补上驱动与加速库；链接阶段报错多半是依赖没齐。
2. 构建并起服务在仓库根目录跑构建和启动命令，先把服务起在本地回环地址上，别急着对外暴露。
3. 验证链路先用最小请求确认服务能回一个模型列表，再对目标模型发一次提问，通了才算跑起来。
4. 确认磁盘看一眼默认模型存放位置的空间够不够，模型体积去 /models 里对应条目的规格处核对。

验证顺序建议固定成：服务进程起没起 → 本地接口能不能回一个模型列表 → 能不能对目标模型发一次请求。每一步失败都先看这一层，别跳步猜，跳步最容易把路径问题误判成代码问题。

main 和发行版混用时的冲突与回退

典型症状是命令找到了、模型也在，但调用报协议或字段不匹配。这多半不是模型的问题，而是客户端连到了另一套服务端，或者旧进程还占着端口没退干净。

排查顺序固定成三步：先看端口被谁占，再看进程的实际可执行文件路径，最后对一次两边版本号。三步走完基本能定位是路径问题还是协议问题。

• 停掉手编的那份，把 PATH 指回发行版安装位置，重启即可。
• 清理残留的临时目录，否则缓存文件会继续被新进程读到。
• 如果你已经在 main 上改了代码并依赖新字段，回退会让调用方报错，这时要同步改客户端，而不是只退服务端。

改代码前的几条自保习惯

开分支、隔端口、记提交点，这三件事做齐，出问题至少能定位到具体哪次拉取。术语写法与实际对应关系可以到 /ai-dict/category/tech 先把名词对一遍，省得跟同事说岔。

团队里如果有人只用安装包，约定好谁负责升级、升到哪个点，比事后排查便宜得多。这条不适用的情况是：只有你一个人维护、且没有其他人依赖这套服务，那按自己节奏来就行。