ollama本地部署千问3.5

多数人第一次在本地跑千问，卡的不是「装没装上」，而是拉不到模型、跑起来慢得离谱、或者不知道该用哪个量化档、调用接口时连不上。这篇按从零到跑通的顺序走一遍：先确认环境，再拉模型，再跑对话，最后接到自己的脚本或应用里；每一段都给出判断标准和出错时的对照动作，参数与显存的具体数字去站内测算页看当时的版本。

多数人第一次在本地跑千问，卡住的地方其实不在「装没装上」。装 Ollama 本身很快，真正让人抓头的是三件事：模型名字拼不对拉不下来、跑起来慢得没法用、想接到自己脚本里时连不上接口。这篇就按从零到跑通的顺序走一遍，先确认环境，再拉模型，再跑对话，最后接到应用里。

每一段我都给出判断标准和出错时的对照动作，你照着做就行。至于参数、显存、量化档的具体数字，本文一律不写死——那些会随版本变，去站内测算页看当时的版本更靠谱。别凭感觉挑最大档，那样大概率跑不动还怪电脑差。

动手前先确认四件事

很多人一上来就敲拉取命令，结果报错信息指向网络、指向模型名，其实是底层服务根本没起来。先花两分钟把下面四件事确认掉，后面能少绕一半弯路。这四件事里任何一件没落实，你后面遇到的报错都会指向错误方向，白白浪费时间。

服务在不在

命令行能查到版本号、能列出已下载的模型，再去拉新模型，否则先解决服务起没起

显存够不够

按参数量和量化档粗算，对照去 /compute/sizing 看当时的测算口径

用途是什么

只做对话、还是给脚本或知识库当后端，两者选的档位与上下文设置不一样

模型存哪

本地盘还是挂载盘、要不要跨机器访问，先定下来，别等跑通再搬家

• 确认能查到版本：命令返回正常，说明主程序装好了
• 确认能列出模型：返回空列表也算通过，说明存储路径可用
• 确认服务在监听：本地端口有响应，说明后台进程活着
• 确认盘上有空间：模型体积不小，先看一眼剩余容量再拉

拉取模型：名字、档位与网络

拉取失败九成出在模型名上。仓库里的名字和你想的可能不一样，标签写法也要跟仓库一致，少一个字母、多一个后缀都会直接失败。建议先在浏览器里确认这个名字确实存在，再回命令行敲。拉取命令本身很简单，难的是挑对档位。

1. 先确认名字存在用浏览器或一条最简请求确认模型名有效，别凭记忆敲；名字错会报找不到清单，好在这个错很好认
2. 挑一个保守档位从你机器大概率能跑的小档起步，跑通再往上换；各档差别和适用边界到 /models 的模型资料对照
3. 处理拉取太慢国内网络拉取慢或中断是常见现象，先看站内镜像与加速思路，再考虑手动下载离线文件导入
4. 拉完做落盘确认用列表命令确认大小和路径，路径不对的话下次还会重下，白费流量

关于档位选择，我给你一个朴素的判断：宁可先跑一个能出字的小档，也不要一上来就赌大档。跑通的体验能帮你确认环境没问题，之后再逐步加码，出问题也更容易定位是哪一步引入的。至于每个档位具体多大、要多少显存，去 /models 看当时的数据，别信记忆里的旧数字。

跑起来：命令行对话与参数

第一次加载模型慢是正常的，别急着重装。让它在命令行里做一次短问答，确认能加载、能出字，再去谈性能。这一步的关键是控制变量：先确定它能干活，再逐项调整影响速度的参数。很多人把加载慢当成性能差，其实只是首次把权重换进显存。

• 先做一次短问答，确认模型能加载并正常出字
• 首次加载慢属正常，别在这一步就判定性能不行
• 需要复现结果时把采样参数固定，别用默认值比对两个模型
• 上下文长度别给太大，一口气塞长文档最容易把显存吃满
• 输出慢要区分首次加载、显存不足、还是算力上限，三种处理方式不同

# 交互式对话，先跑一句短问答确认能出字
ollama run <模型名>

# 非交互一次性提问，适合放进脚本
ollama run <模型名> "用一句话解释什么是量化"

参数上最影响体验的是上下文长度和并发。上下文给得越大，占用的显存越多，长对话或长文档一来就容易溢出变慢甚至崩。判断标准很简单：如果你的交互式写作等半天才出字，先把上下文调小一档再试，多数情况立竿见影。

接到接口：本地调用与脚本接入

跑通对话之后，接下来通常是把它接到自己的脚本或应用里。这一步最容易踩的坑是地址：默认的监听地址只允许跑服务的那台机器访问，你在容器里、或者从另一台机器调，就会连不上。这不是模型问题，是网络配置问题。

1. 先用最短请求验证连通用一条 curl 打到本地接口，确认有返回；不要一上来就套框架，把问题范围压到最小
2. 确认监听地址如果调用方不是本机，需要显式指定监听地址，让服务对外可达；改完重启再验证
3. 跑通官方客户端示例Python、Node 等都有现成封装，先照着官方最短示例跑通，再加自己的业务逻辑
4. 对外暴露前收口要给别人用或接 Web 界面，注意别把端口直接开到公网，加一层访问控制更稳妥

判断标准是：本机 curl 通、但脚本里连不上，八成是监听地址或容器网络的问题，而不是接口坏了。反过来，脚本通了但换台机器不通，那就去看服务监听的地址范围。这一节其实就一句话：先用最短路径验证连通性，再往里加复杂度。

档位与硬件怎么对：不只看能不能跑

这是最容易被忽略的一节。很多人以「能不能加载」作为选档标准，结果发现跑起来卡顿、长上下文一上来就崩。能不能加载和跑不跑得快是两件事：刚好塞进显存，往往只剩很少余量，稍微长一点的对话就掉链子。

• 把「能加载」和「跑得快」分开看，前者不代表后者
• 给上下文和并发留出余量，具体留多少按 /compute/sizing 的口径算
• 纯 CPU 适合短问答和离线批处理，别指望它做流畅的交互写作
• 同一台机器优先试不同量化档，这比换卡便宜得多
• 换档不行再考虑加显存或换硬件，顺序别反

关于「留多少余量」这种问题，我给不出一个固定数字，因为它取决于你的上下文设置和并发数。正确做法是到 /compute/sizing 按当时的测算口径算一遍，再决定上不上更大参数。凡是跟你说「留固定多少」的说法，都要结合你的实际用法打折扣。

出问题时的排查顺序

本地部署的报错经常指错方向，所以排查顺序很重要。别一看到红字就怀疑模型不行，按下面这个从易到难的顺序走，绝大多数问题在头两步就能定位。我把顺序排成清单，你照着从上往下试。

1. 一查模型有没有下完列表里看得到、名字对得上，才算真的下好；名字错或没下完，后面全免谈
2. 二查服务在不在跑版本能查到、端口能通，说明主进程活着；不通就先解决服务
3. 三查显存占用被占满或碎片化会导致加载失败或中途报错，先把常驻模型清掉再试
4. 四查版本与驱动驱动、容器与主程序版本不匹配，报错常和模型本身无关，对齐版本再试
5. 五换小档验证同一段提示词换个小档模型跑一遍，能跑就说明是配置问题，不是模型问题

这套顺序的核心逻辑是：先排除「东西有没有」，再排除「服务活不活」，最后才怀疑「模型行不行」。把顺序颠倒过来，你会在配置问题上浪费大量时间，还误判模型能力。记住一点：本地报错的第一嫌疑对象永远不是模型本身。

什么时候这套方案不适用

Ollama 这类工具的优势是单机、省心、上手快，但它不是万能方案。以下几种场景，我建议你先评估别的路子，别为了本地而本地，最后维护成本高还不讨好。提前想清楚边界，比事后返工划算。

• 要多人同时用、要稳定吞吐，单机友好型工具不是首选，应评估面向服务的推理框架
• 需要超长文档批处理的任务，本地小档容易丢信息，先小规模验证再决定
• 对输出质量和时效性要求高、又不想维护硬件，直接走在线接口更省事
• 有数据不出网或合规要求时，本地是加分项，但要把存储、日志、权限一起管住
• 只是临时试玩一个小功能，本地部署的维护成本可能超过收益

判断标准是：如果核心诉求是「数据可控、离线可用」，本地值得投入；如果核心诉求是「质量高、省心」，那在线方案往往更划算。两个诉求都想要，那就本地做敏感部分、在线做非敏感部分，混合着来。

本地部署的收益是可控，代价是维护；先想清楚你要的是哪一个，再决定跑不跑。