DeepSeek本地部署与Ollama调优：显存、量化与上下文实战

简介：面向技术爱好者、企业IT管理人员与开发者的本地化大模型部署指南，聚焦在私有环境中运行DeepSeek，解决敏感数据不上云、模型权限自主可控以及垂直业务场景定制等需求。内容从DeepSeek的架构特点与语言生成能力讲起，依次梳理显卡显存、内存与CPU的选型建议，Ollama运行框架和CUDA Toolkit的安装配置，再到模型拉取、服务验证与常见故障排查，并延伸到医疗辅助诊断、金融风控、教育资源推荐等场景的落地思路。资源包共1个PDF文件，约586KB，篇幅紧凑，适合作为部署前的流程速查与配置对照手册。已有701人学习。读者可从中获得硬件匹配与软件环境搭建的完整路径、显存不足与安装失败等问题的排错参考，以及结合业务做微调与性能优化的思路，便于搭建稳定、可定制的私有AI服务。

1. 本地部署 DeepSeek：它解决的从来不是“能不能跑”

上个月一个做医疗信息化的朋友找我，说他们想把病历摘要功能接进内网系统，测试了几家在线接口，法务一句话把方案毙了——数据出不了机房。这类需求最后基本都落到同一个解法上：本地部署 DeepSeek 这类开源大语言模型，让推理全程在自己机器的显存里跑完，输入输出都不出网卡。它适合两类人：手里攥着敏感数据、又确实需要自然语言处理能力的团队；以及想把大语言模型当基础设施、要自己锁版本、控参数的开发者。但装完不等于能用，显存账、量化档位、上下文长度这几笔算不清，跑起来照样卡成幻灯片。下面按我实际踩坑的顺序，从选型一路拆到参数调优。

2. 选型与显存账本：1.5B 到 32B 的分水岭在哪

2.1 显存不是“装得下”，是“装得下还能喘气”

很多人挑模型的逻辑是看磁盘占用：7B 的包 4.7GB，我显卡 8GB，那不绰绰有余？跑起来就翻车。磁盘上的体积是压缩后的权重，加载进显存后还要额外吃三块：一是 KV Cache，跟你设的上下文长度成正比；二是推理中间激活值，跟批大小成正比；三是驱动和桌面本身要占的几百 MB 到 1GB 多。

一个我常用的粗算公式是这样的：显存占用 ≈ 参数量 × 每参数字节数 + KV Cache + 预留。量化到 4bit 时，每参数字节数按 0.6～0.7 估（含 embedding、norm 层这些不量化的部分），8bit 按 1.05 估，FP16 就是 2。KV Cache 这块不好精算，经验值是 4K 上下文下 7B 模型大约吃 0.5～1GB，上下文翻倍它基本也翻倍，长上下文场景里它经常是压垮显存的最后一根稻草。

所以我的习惯是：先把卡上可用的显存查清楚，减掉 1.5GB 的系统预留，剩下的才是模型预算。查询用一条命令就够，比开任务管理器看来得准：

# 查询显卡型号、总显存、已用显存、驱动版本，CSV 格式便于复制 nvidia-smi --query-gpu=name,memory.total,memory.used,driver_version --format=csv

这条命令输出的memory.total是物理显存，memory.used里已经包含了桌面、浏览器、IDE 的占用。血泪经验是：别在开着三个浏览器标签页和 Docker Desktop 的机器上测模型能跑多大，测出来的数字会明显偏悲观，回头单独跑又对不上。测之前把能关的都关掉，测出来的余量才是真实可用余量。

只有核显或者纯 CPU 的机器也不是不能跑，只是要换思路。CPU 推理的速度基本由内存带宽决定，7B Q4 在双通道 DDR 上大概每秒几个 token，能读能写但没法交互式对话。真要这么用，就得把num_thread设成物理核心数（不是超线程数），并且接受首 token 要等十几秒。

2.2 四个档位的实际占用与适用场景

同一系列模型的不同参数量版本，差距不是线性的。1.5B 和 7B 之间是“能不能用”的差别，7B 和 14B 之间是“够不够好”的差别，14B 到 32B 更多是“值不值这个硬件成本”的问题。下面这张表是我在不同机器上反复试下来的一组经验值，量化档位统一按 Q4 系列算：

选型时最容易犯的错是“一步到位”。有人 8GB 显存的笔记本直接上 14B，跑是能跑起来——Ollama 会自动把一部分层卸载到内存里做 CPU+GPU 混合推理，但速度会掉到每秒两三个 token，用起来比等外卖还煎熬。判断有没有发生卸载，看ollama ps的PROCESSOR列就行，显示100% GPU才是全量在卡上；如果写着xx%/xx% CPU/GPU，说明已经有层被挤到内存里了。

2.3 量化档位：Q4_K_M 是默认答案，但不是唯一答案

同一份权重可以压成不同精度，精度越低越省显存、质量越差。这里有个反直觉的点：从 FP16 压到 Q4，质量损失远比大多数人想象的小；但从 Q4 再往下压到 Q3、Q2，质量是断崖式下跌，尤其在中文长句和代码生成上，会出现重复、漏字、逻辑断裂。

我一般的做法是：先按 Q4_K_M 估算显存能不能装下，装得下就用它；装不下先降上下文长度，还不行再降到 Q5 但换更小参数量的模型，而不是把量化压到 Q3。宁可让小模型跑满精度，也别让大模型半残着跑。

2.4 用两条命令校验选型是否成立

模型拉下来之后，别急着开聊，先看一眼它的元信息。ollama show会打印出参数量、量化方式、上下文窗口这些关键字段：

# 查看模型元信息，重点看 parameters / context length / quantization ollama show deepseek-r1:7b # 查看当前已加载到内存/显存的模型，以及它跑在 GPU 还是 CPU 上 ollama ps

ollama show的输出里，parameters告诉你参数量，context length是模型支持的最大上下文（这个值决定了你能把num_ctx调到多高），quantization就是量化档位。如果这里显示的量化档位跟你预期的不一致，说明拉错了 tag，得重新拉。

ollama ps更实用，它反映的是“此刻正在跑的那个实例”的真实状态。有一次我在一台 16GB 显存的机器上坚持用 14B 模型，ollama ps显示100% GPU，但响应速度就是上不去，后来才发现是上下文设到了 32K，KV Cache 把显存吃到只剩几百 MB 余量，每次分配都在边缘试探。把num_ctx降到 8K 之后，速度立刻正常。这类问题不会报错，只会让你觉得“这模型怎么这么慢”，只能靠ollama ps加上任务管理器一起看。

3. Ollama 实操：三条命令跑通第一次推理

3.1 安装：三个平台各自的坑

Ollama 的价值在于把模型下载、量化加载、显存分配、API 暴露这几件事打包成一个后台服务，你不用碰 Python 环境、不用装推理框架、不用手写加载脚本。代价是它对安装位置和端口有一套自己的默认约定，这个后面避坑章会细说。

Linux 上最省事，一条脚本搞定，安装完会自动注册成 systemd 服务并设为开机自启：

# Linux 一键安装，会自动创建 ollama 用户并注册 systemd 服务 curl -fsSL https://ollama.com/install.sh | sh # 验证版本号 ollama -v # 验证服务是否在监听，返回 "Ollama is running" 即为正常 curl http://127.0.0.1:11434

这里第二条命令ollama -v验证的是客户端，第三条curl验证的是服务端。这两件事是分开的：客户端装好了但服务没起来，你依然没法跑模型。判断服务状态，curl比ollama -v靠谱得多，因为它真的发了一次 HTTP 请求。

Windows 是双击 exe 走安装向导，需要注意两点：默认装到系统盘且不让你改路径，装之前先确认系统盘有 5GB 以上余量；装完必须重新开一个终端窗口，因为 PATH 是在安装时写进注册表的，已经开着的终端读不到新值。macOS 是拖 dmg 到应用程序目录，装完同样重开终端。

三个平台装完，验证动作完全一致，跑一句ollama -v看有没有版本号，再curl http://127.0.0.1:11434看服务活没活。这一步别省，后面所有问题都能追溯到这两条命令的某一条没通过。

3.2 拉模型：pull 和 run 是两件事

新手最容易混淆的是ollama pull和ollama run。前者只下载不运行，后者下载完直接进交互。如果你只是想先把模型备好、后面用 API 调，用pull；想立刻试一句，用run。

# 只下载，不进交互，适合提前把模型准备好 ollama pull deepseek-r1:7b # 下载并直接进入交互式对话，首次执行等同于 pull + run ollama run deepseek-r1:7b # 列出本地已有的模型，注意：这是本地清单，不是在线搜索 ollama list

提示：ollama list只显示已经下载到本地的模型，它不具备搜索远端仓库的能力。想拉某个 tag，直接ollama pull 模型名:tag就行，拉不到会明确报错，比猜测有什么版本高效。

下载过程会显示分层进度，模型越大层数越多。中途断了不用慌，重新执行同一条pull命令会续传已完成的分层，不会从头再来。这一点比很多人想象中友好，尤其是几十 GB 的大模型。

3.3 交互式对话：几个必须记住的斜杠命令

进入>>>提示符之后，你面对的是一个 REPL。除了直接打字提问，还有几个斜杠命令值得记住：

# 进入交互 ollama run deepseek-r1:7b # 会话内临时调整温度，只对当前会话生效 /set parameter temperature 0.3 # 查看当前会话的所有参数 /show parameters # 清空上下文，开始新话题（避免上一轮内容干扰） /clear # 退出 /bye

/clear这个命令看着不起眼，实际很关键。多轮对话里上下文是累积的，聊到十几轮之后，历史 token 会吃掉大量上下文预算，模型开始“忘事”，响应也变慢。业务场景里我一般会在切换任务时手动/clear，或者在程序侧每轮都重新构造 messages 数组，不依赖服务端的会话状态。

3.4 HTTP API：两个端点覆盖绝大多数场景

真正要把模型用起来，靠的还是 HTTP 接口。Ollama 默认在 11434 端口暴露服务，提供了原生接口和 OpenAI 兼容接口两套。原生接口里最常用的是/api/generate（单轮补全）和/api/chat（多轮对话）。

# 单轮生成，stream=false 表示等全部生成完一次性返回 curl http://127.0.0.1:11434/api/generate -d '{ "model": "deepseek-r1:7b", "prompt": "用三句话解释什么是向量检索", "stream": false, "options": { "temperature": 0.6, "num_ctx": 4096, "num_predict": 512 } }'

stream设成false时，服务端会把整段回答生成完再返回，适合后台批处理；设成true会一行一行吐 JSON，适合做打字机效果的前端。options里的三个参数分别是采样温度、上下文窗口大小、最大生成 token 数，这三个是最影响体验的，第 6 章会细讲。

Python 侧我一般不直接拼 JSON，而是封一个薄薄的函数，把超时和异常处理带上：

import requests def ask(prompt: str, model: str = "deepseek-r1:7b", temperature: float = 0.6, num_ctx: int = 4096) -> str: """调用本地 Ollama 做单轮问答，返回纯文本回答""" payload = { "model": model, "prompt": prompt, "stream": False, "options": { "temperature": temperature, # 越低越稳定，业务问答建议 0.2~0.5 "num_ctx": num_ctx, # 上下文窗口，直接决定 KV Cache 大小 "num_predict": 512 # 单次最多生成多少 token，防止无限输出 } } # 超时给足，冷启动加载模型可能要几十秒 resp = requests.post("http://127.0.0.1:11434/api/generate", json=payload, timeout=300) resp.raise_for_status() return resp.json()["response"]

这段代码里timeout=300不是随手写的。模型首次加载、或者机器上同时跑了别的任务时，冷启动可能超过一分钟，超时设短了会频繁抛异常，而异常信息看起来像是“服务挂了”，实际只是慢。raise_for_status()则是为了把 4xx、5xx 明确暴露出来，不然你会拿到一个空字符串，还得回头猜是模型没返回还是请求根本没发出去。

多轮对话用/api/chat，把 messages 数组传进去，格式跟主流接口一致：

payload = { "model": "deepseek-r1:7b", "messages": [ {"role": "system", "content": "你是内网知识库助手，只根据给定资料回答，不确定就直说不知道。"}, {"role": "user", "content": "上季度报销流程改了什么？"} ], "stream": False, "options": {"temperature": 0.2, "num_ctx": 8192} }

system 这一条是业务落地的关键。本地部署的最大优势之一就是你可以把企业内部的回答规范、术语表、拒答策略写死在 system 里，不受任何外部服务商的政策变动影响。写得好不好，直接决定模型是“能用”还是“胡说八道”。

4. 避坑与排查：六个高频翻车现场

这一章是按“现象 → 原因 → 解决”整理的，基本都是我在不同机器上真实遇到过的。装完之后如果哪一步不对，先来这里对照一遍，比漫无目的地搜要快。

4.1 现象：终端提示“ollama 不是内部或外部命令”

原因基本只有一个：安装时 PATH 没写进去，或者你用的是装之前就开着的那个终端窗口。Windows 上装完不重开终端，百分百复现这个问题；macOS 上如果你用的是第三方终端且没重启，也会出现。

解决分两步。先关掉所有终端窗口重新开一个，再试ollama -v。还不行就手动查 PATH：Windows 下在“环境变量”里看用户变量有没有指向 Ollama 安装目录的条目，macOS/Linux 下执行echo $PATH看有没有/usr/local/bin。Linux 用脚本安装的话，服务是以 systemd 方式注册的，客户端二进制在/usr/local/bin/ollama，如果这个路径不在 PATH 里，做个软链比改 PATH 更快。

4.2 现象：拉模型卡在pulling manifest一动不动

pulling manifest是第一步，它要先去远端取模型的清单文件。卡在这里说明连不上或者解析不了，跟模型大小无关。这时候最容易误判成“模型太大下载慢”，然后傻等半小时。

原因通常是本地网络到远端的链路不稳定，或者 DNS 解析有问题。解决顺序建议这样：先 Ctrl+C 中断，重新执行ollama pull，多数情况下第二次就通了；连续几次都卡在同一个地方，就换个时间段或者换网络环境再试；如果目标机器本身就在内网、完全不能出网，那就走离线路径——在能出网的机器上把模型拉好，把~/.ollama/models目录整体拷过去，或者直接用 GGUF 文件配合 Modelfile 导入：

# 用本地 GGUF 文件构建模型，完全不走网络 cat > Modelfile <<'EOF' FROM ./deepseek-r1-7b-q4_k_m.gguf PARAMETER temperature 0.5 PARAMETER num_ctx 4096 EOF ollama create deepseek-local -f Modelfile

FROM后面跟本地文件路径时，Ollama 会跳过下载直接读取文件并做格式转换。这条路在内网环境里非常实用，也是我认为每个要做离线部署的人都该掌握的。ollama create成功后，ollama list里会出现deepseek-local这个名字，后面所有调用都用这个名字。

4.3 现象：报CUDA out of memory，或者进程直接被系统杀掉

看到 OOM 先别急着怀疑显卡坏了。显存不够有三种典型来源：模型本身就超出预算、上下文设太大把 KV Cache 撑爆、并发请求太多导致多份 KV Cache 同时存在。还有一种隐蔽情况是，你以为模型卸载了，其实上一个实例还挂在显存里。

排查顺序我一般这样走：先ollama ps看当前有没有残留实例，有就ollama stop 模型名卸掉；再看请求里num_ctx设了多少，把它从 32768 降到 8192 试试；还不行就换更小的模型档位。如果业务上必须跑大模型，可以限制同时加载的模型数量，避免几个模型抢显存：

# 限制同一时刻只加载一个模型，避免多模型争抢显存 export OLLAMA_MAX_LOADED_MODELS=1 # 限制单个模型最多用几张卡（多卡机器上防止它铺得太开） export OLLAMA_NUM_PARALLEL=1

这两个环境变量在 Linux 上要写进 systemd 的 service 配置才持久，临时 export 只对当前 shell 生效。踩过一次坑：改了环境变量但忘了systemctl daemon-reload和重启服务，折腾半天以为变量没生效，其实是服务根本没读新配置。

4.4 现象：中文输出变成一串乱码或者方块

这个在 Windows 命令行里特别常见。原因不在模型，在终端代码页——GBK 和 UTF-8 对不上，模型返回的 UTF-8 字节被按 GBK 解释，就成了乱码。判断方法很简单：同样的请求换成 HTTP API 调，如果返回的 JSON 里中文正常，那就百分百是终端的问题。

解决就是切代码页：

# 把当前命令行窗口切到 UTF-8 chcp 65001 # 切回默认代码页（需要时） chcp 936

chcp 65001只对当前窗口生效，关掉就没了。想一劳永逸，可以在终端软件的设置里把默认编码改成 UTF-8，或者干脆用 Windows Terminal 替代老式 cmd。另外提醒一句：如果你是在 Python 脚本里读返回值，也遇到过乱码，那要检查的是脚本里resp.encoding有没有被错误设置，跟终端无关。

4.5 现象：ollama list里看不到想要的 DeepSeek 版本

新手常干的事是敲ollama list | grep deepseek想“搜一下有哪些版本”，结果空空如也，然后以为模型仓库里没有。ollama list永远只列本地已经下载的，它不是一个远端查询命令。

正确做法是直接用ollama pull加具体 tag。tag 写错时它会明确告诉你 manifest 拉不到，这本身就是一种校验。至于有哪些 tag，最可靠的方式是看模型在仓库页面上给出的版本列表，或者先用最常用的默认 tag 试。不要在版本号上纠结太久，7B 和 14B 这种大档位之间的差异，远比同档位内的细微版本差异重要。

4.6 现象：本机能用，同事的机器访问不到 11434

默认情况下 Ollama 只监听127.0.0.1，这是刻意的安全设计。你想让局域网内其他机器访问，就得显式改监听地址：

# 让服务监听所有网卡（仅限可信内网！） export OLLAMA_HOST=0.0.0.0:11434 # 验证监听状态 curl http://<本机内网IP>:11434

注意：把 11434 暴露到0.0.0.0意味着同一网段内任何机器都能无认证调用你的模型，等于给内网开了一个免费算力接口。只在隔离的可信内网里这么做，绝对不要把它映射到公网，也不要在办公网段随便开。真要做多人共用，正确做法是在前面套一层带鉴权的反向代理。

5. 接前端与业务：从命令行走到能交付的形态

5.1 OpenWebUI：十分钟把命令行换成网页

命令行验证通之后，下一步通常是给非技术同事一个能点的界面。OpenWebUI 是这类需求里最省事的选择——完全本地运行、不依赖任何外部服务、原生支持对接 Ollama，装完就是一个带会话管理、模型切换、多用户的内网版聊天界面。

安装走 Python 包，建议先建虚拟环境，避免把它的一堆依赖装进系统 Python 里：

# 建并激活虚拟环境（Windows 用 openwebui_env\Scripts\activate） python -m venv openwebui_env source openwebui_env/bin/activate # 安装并启动，默认监听 8080 pip install open-webui open-webui serve

启动后在浏览器打开http://localhost:8080，首次进入会让你注册一个管理员账号，账号信息存在本地数据库里，不联外网。接着进设置里的模型配置，把运行器选成 Ollama，API 地址填http://localhost:11434，保存之后模型列表会自动拉过来。

这里有个细节值得说：如果 OpenWebUI 是跑在容器里的，localhost指的是容器自己，必须换成宿主机的内网 IP 或者host.docker.internal。我见过不止一个人卡在这一步，界面显示连接失败但 Ollama 明明活得好好的，问题就出在这个地址上。

5.2 用 Python 封一层业务接口

给同事用 OpenWebUI 够了，但要把模型能力嵌进现有系统，还是得自己封一层。核心思路是把模型调用藏在业务接口后面，对外只暴露“输入问题、返回答案”这一件事，同时把日志、超时、重试、限流这些工程问题在这一层解决掉。

from fastapi import FastAPI, HTTPException from pydantic import BaseModel import requests app = FastAPI() OLLAMA_URL = "http://127.0.0.1:11434/api/chat" class Query(BaseModel): question: str session_id: str | None = None @app.post("/qa") def qa(q: Query): payload = { "model": "deepseek-r1:7b", "messages": [ # system 里锁定回答边界，这是本地部署最值钱的部分 {"role": "system", "content": "你是内部制度查询助手。只依据提供的制度文本回答，" "资料中没有的内容必须回复“暂未收录”，不得推测。"}, {"role": "user", "content": q.question} ], "stream": False, "options": {"temperature": 0.2, "num_ctx": 8192, "num_predict": 800} } try: r = requests.post(OLLAMA_URL, json=payload, timeout=180) r.raise_for_status() except requests.Timeout: raise HTTPException(504, "模型响应超时") except requests.RequestException as e: raise HTTPException(502, f"模型服务异常: {e}") return {"answer": r.json()["message"]["content"]}

这层封装里最容易被忽略的是温度。业务问答场景我基本固定在 0.2 左右，宁可回答得干巴一点，也不要它自由发挥。创意写作类才需要往 0.8 以上调。另一个是num_predict，不设上限的话，模型偶尔会陷入复读，把上下文窗口耗光才停，表现出来就是“卡住不动”，实际它还在吐字。

接口有了，鉴权和审计在网关层做，别塞进模型调用里。职责分开之后，模型换版本、换参数量，上层业务代码基本不用动。

5.3 把提示词和参数固化进模型

每次请求都带一长串 system 和 options，时间长了必然有人漏改。更稳的做法是用 Modelfile 把配置固化成一个新模型，业务侧只管调用名字：

cat > Modelfile <<'EOF' FROM deepseek-r1:7b # 采样温度压低，业务问答要稳不要飘 PARAMETER temperature 0.2 PARAMETER num_ctx 8192 PARAMETER num_predict 800 SYSTEM """ 你是某内部知识库的问答助手。 规则： 1. 只依据检索到的资料回答，资料没有就说“暂未收录”； 2. 涉及金额、日期、责任人时必须原样引用，不得改写； 3. 回答控制在 300 字以内。 """ EOF # 构建成新模型，之后调用 deepseek-kb 即可 ollama create deepseek-kb -f Modelfile

FROM指定基础模型，PARAMETER覆盖默认参数，SYSTEM写入系统提示词。构建完成后，ollama list里会多出deepseek-kb，调用方式和普通模型完全一样。这样做的好处是可版本化——把 Modelfile 提交进代码仓库，谁改了什么提示词一目了然，出问题能回滚。

需要提醒的是，改完 Modelfile 必须重新执行ollama create才会生效，改文件本身不会触发任何重建。另外基础模型更新后，固化出来的模型不会自动跟着更新，得重新构建一次。

6. 参数调优与效果验证：把“能跑”变成“能用”

调参这件事，我见过太多人一上来就翻文档找几十个参数，其实真正影响体感的就三个。

温度控制随机性。业务问答 0.2～0.4，摘要改写 0.5～0.6，头脑风暴才上 0.8。低于 0.1 会出现明显的机械重复，高于 1.0 中文场景就容易跑偏。有个反直觉的观察：同一份提示词下，温度从 0.7 降到 0.2，回答质量的提升比换大一个参数档位还明显。

num_ctx控制上下文窗口，它直接决定显存占用和首 token 延迟。设成 32K 而实际对话只有几百字，等于白占显存。我的习惯是按业务实际长度设，文档问答给 8K，短对话 4K 足够。

num_predict是生成上限，不设的话遇到复读就停不下来。摘要类给 500，长文给 1500，宁可截断也不要让它无限输出。

至于怎么调，我得说个踩过的坑：网上流传的ollama run 模型名 --options='{"temperature":0.7}'这种写法，在我试过的多个版本里根本不生效，参数会被静默忽略，你还以为调成功了。真正可靠的三个入口是：交互式里用/set parameter temperature 0.3、API 请求体里的options字段、以及 Modelfile 里的PARAMETER。判断有没有生效，用/show parameters看当前会话的实际值，别凭感觉。

验证这块我有一套十分钟能跑完的清单，每次换模型或改参数都走一遍：第一，用三个固定问题各问两遍，看回答是否稳定，temperature 设低时两遍应该高度相似；第二，故意问一个资料里没有的问题，看它会不会老实说“暂未收录”，这一步能筛掉大部分幻觉；第三，发一个接近上下文上限的长输入，观察响应时间有没有断崖式下跌；第四，ollama ps确认仍是100% GPU；第五，连续发 10 个请求，看显存有没有一路涨上去不回落。

从那以后我每次上线前都强制走一遍这套清单，尤其是第二条——拒答测试。模型答得漂亮不稀奇，肯承认自己不知道才是能交付的前提。希望帮到你。

本文还有配套的精品资源，点击获取