deepseek v3.2 ollama本地部署

很多人下载完 Ollama 就直奔拉模型，结果卡在三件事上：显存不够反复重拉、拉到的版本和预期不一致、跑起来了但不确定输出是否正常。这篇按顺序把动作拆开——先量机器、再定量化档、再拉模型、最后用一组固定问题做验证，中间每一步都给出判断标准和失败后往哪查。

很多人装完 Ollama 的第一反应就是直接敲拉取命令，然后卡在三个地方：显存不够，拉一半崩了又得重来；拉完发现跟自己想的体量完全不是一回事；好不容易跑出字了，却不知道这算不算「跑通」。这篇不讲原理，只按顺序拆动作——先量机器、再定量化档、再拉模型、最后用一组固定问题验证，中间每一步都给判断标准和失败后往哪查。

需要先说清楚一个前提：本地部署解决的是「数据不出机器」和「不计次调用」这两件事，代价是显存、电费和你的时间。如果你只是偶尔问几句话，官方 API 或托管平台反而更划算。本地这条路的收益，只有在你长期高频使用、或者有明确的数据合规要求时才成立。具体到某张卡能跑什么、托管方案当时什么价，去站内按需核对，别凭印象决定。

先量机器：显存、内存、磁盘三件事

这三项各自管一件事，缺一项就会在半路卡住。显存决定模型能不能整体卸载到显卡上跑，内存决定卸载到 CPU 之后会不会疯狂读盘，磁盘决定这个模型文件你到底放不放得下。量的时候别用标称值，开机把浏览器和桌面环境都开着量当前可用量，那才是你真实能用的数字。

光看参数表不够，最靠谱的是拿你自己的硬件去部署测算页跑一遍，输入卡型、内存、目标体量，看它给出的档位建议和显存缺口。到 /models/deploy 用部署测算页按自己的卡算一遍，再决定要不要继续。这一步花五分钟，能省掉后面几十分钟的反复重拉。

装 Ollama 与确认服务真的起来了

安装包双击完不等于服务在跑。拉模型这个动作是客户端发给本地服务的请求，服务没起来的时候，请求会静默失败或者只报一句很含糊的错，很多人就在这里绕圈子。所以顺序必须是：先确认服务活着，再谈拉模型。

1. 确认版本命令能输出终端里跑一次版本查询命令，能打印出版本信息说明二进制装好了、环境变量也没问题。报「命令未找到」就是安装路径或 shell 配置的问题。
2. 确认服务端口能连上用浏览器或命令行请求本地服务的默认端口，返回一个正常响应而不是连接被拒绝，说明服务在监听。被拒绝就去查服务有没有启动、有没有被占用。
3. 确认 GPU 被识别看服务启动日志里有没有识别到显卡。日志里全是 CPU 字样，说明驱动或权限没过，这时候拉再大的模型也是纯 CPU 跑，速度会难看到你怀疑人生。

还有一个容易忽略的点：模型文件默认落在系统盘的用户目录下，体量大的模型能把系统盘吃干净。在拉第一个模型之前就把存储路径改到数据盘，改完记得重启服务。关于模型目录、权重、推理服务这些名词的准确含义，拿不准的时候到 /ai-dict/category/infra 的术语对照里过一遍，比在网上搜二手解释靠谱。

量化档位怎么选：先看显存再谈质量

同一个模型会有若干个量化档，本质是把权重压得更小。档位越低越省显存，但长链推理和代码类任务的退化越明显，没有既要又要的选项。所以正确的顺序不是「哪个质量最好」，而是先用显存定一个上限档位，再在这个上限里挑。

• 先按你自己量出来的显存，在部署测算页里找出能装下的最高档，这是你的天花板
• 拿两个相邻档位，用你真实会做的任务各跑一遍，差别肉眼看不出来就取省显存的那个
• 别用「你好，介绍一下你自己」这种问题比质量，那类问题任何档位都答得差不多
• 做长文档总结、多轮代码修改这类对一致性要求高的活，宁可降并发也别降档
• 拿不准 GGUF、量化位宽这些词到底指什么，先去术语页混个眼熟再回来看标签

量化名词本身不难，难的是它们和显存占用、输出质量的对应关系。到 /ai-dict/category/tech 先把基础概念过一遍，再回头看模型标签里的数字，就不会被一堆后缀搞晕。什么情况下不该省这个档位：你做的事情需要模型记住长上下文里的细节、需要多次改同一段代码不出矛盾，这类任务降档的代价会明显大于省下来的那点显存。

拉模型：tag 怎么写、拉不动怎么办

拉取命令本身很短，容易出错的是 tag。标签决定了参数量和量化档，写错一个字，你拉到的就是完全不同的体量——要么装不下，要么小得跟预期不符。所以拉之前先想清楚要哪个 tag，写下完整名称再执行，别边敲边猜。

tag

跟在模型名后面的标识，决定参数量和量化档，写错就会拉到另一个体量

拉取中断

下载过程中断线，通常是网络问题，重新执行一般能续传

速度极慢

一直没动静但不是报错，多半是源的问题，换镜像比反复重试有效

体积对不上

拉完发现文件体量跟预期差很远，基本可以确定是 tag 选错了

国内网络环境下拉取失败，优先考虑镜像加速而不是反复重试同一个源，具体配置方式见站内 registry 相关页面。拉完先看一眼本地模型列表，确认已经落地，再把它的体积跟预期的档位对一下。体积对不上就别急着跑，先重新确认 tag 再说。

跑起来之前的几个参数

模型拉下来不等于马上能用得舒服，还有几个参数要先调。最容易踩坑的是上下文长度——它非常吃显存，而且默认值往往比你以为的大。正确做法是先按实际需要调小，确认跑顺了再一点点往上加，而不是一上来就拉满然后看它爆显存。

• 上下文长度：显存杀手，先调小再逐步加，别一步到位
• 并行请求数：决定同一时刻能接几个会话，本地单人用就压到最低，把显存留给上下文
• 指定显卡：多卡机器要明确用哪张，不指定可能被分到一张不合适的卡上
• 常驻内存：模型是否一直留在显存里，频繁冷启动的场景打开它会舒服很多
• 改完必须重启服务，环境变量类的参数不重启不生效

判断参数调好没有，有个很直观的标准：调完之后第一次提问不应该有明显停顿，如果每次提问都要干等很久，说明卸载策略和上下文设置不匹配，多半是显存不够导致部分层在 CPU 和 GPU 之间来回搬。这时候回去降上下文或者降档，而不是继续加参数。

验证跑通：别只看它回了一句话

「它回字了」和「它跑通了」是两回事。回一句寒暄说明不了任何问题，得过一组固定任务才算。做法是：准备一组固定问题，覆盖几个方向，每次都跑同一组、同一套参数，这样才能比出变化。

除了质量，速度也要有个基线，不然你没法判断后面是不是变慢了。测速的思路和口径可以参考 /tools/speed-test，本地用同样的方式量一次，记下首字延迟和生成速度，之后出问题就有参照物。验证不通过时，排查顺序是先怀疑量化和上下文设置，再怀疑模型文件本身，最后才怀疑硬件——硬件一般没问题，是配置把它拖住了。

常见故障的排查顺序

出问题的时候最忌讳一次改三个变量，改完也不知道是哪个起的作用。下面按「症状 → 排查顺序」列，每次只动一个变量，动完立刻复测。

1. 报内存不足按「降上下文 → 降量化档 → 减少并行」的顺序调，一次只调一项，调完复测，别三件事一起改。
2. 输出乱码或答非所问多半是拉到了不匹配的模型或对话模板，重新拉一次干净的文件再试，不要在原文件上反复折腾。
3. 服务能起但连不上先查端口占用，再看防火墙和监听地址，最后看客户端配置的地址是不是写成了本机之外的地址。
4. 速度突然掉下来先看后台有没有别的进程在占显存，再看是不是触发了 CPU 卸载，最后才考虑换档位。

跑通之后：什么时候该换路子

跑通不等于该一直用下去。Ollama 这套的定位是轻量、单人、快速起步，它在单人少量问答、模型常驻内存的场景下够用，也很省心。但一旦你的需求变成接多个客户端、要并发、要稳定的吞吐量，它的边界就露出来了，这时候该看更偏服务化的推理框架，而不是硬扛。

还有一层要提前想清楚：许可证和商用边界要在真正落地之前确认，权重开放不等于随便用，判断口径可以到 /ai-dict/category/safety 对照。本地跑只解决「能不能跑」，「好不好用」是另外的工程——要接知识库、要联网检索，是另一套东西，按需在 /stacks 里挑。顺手把每次调参和验证结果记一笔，下次换模型或换机器就不用从头试。