简介：《DeepSeek 极简部署手册》面向希望避开云端依赖、在本地试验大语言模型的研究者、开发者与入门用户，适合个人设备上的低成本试跑与技能入门。它以单份 PDF 形式呈现，围绕 Ollama 这一开源工具梳理 DeepSeek R1 的本地运行路径，并补充 Cherry-Studio 图形界面与本地知识库的衔接思路，让缺少部署经验的人也能建立清晰的操作框架。压缩包内共 1 个 PDF 文件，约 819KB，体量轻巧，便于随查随用。文档涵盖模型版本与内存配置的对应参考、安装完成后的校验提示以及对话入口说明，可帮助读者判断设备适合的模型规模并快速进入实践。目前已有 533 人学习或下载。对于想以较低成本接触前沿模型、又担心配置繁琐的读者，这份手册提供了较完整的入门指引与排错参照。
1. 从一份 DeepSeek 极简部署手册说起：为什么“极简”不等于“阉割”
很多团队第一次认真对待大模型部署，都是从一份叫《DeepSeek 极简部署手册.pdf》的文档开始的。PDF 这种载体有它的好处：版本固定、内网可传、离线可读；麻烦也在这里——命令没法直接复制，参数表散在十几页截图中，真上手才发现“极简”两个字描述的是文档体积，不是部署难度。这篇内容按一线落地的顺序走一遍：先定部署路线，再用 Ollama 和 Docker 把 DeepSeek 跑成常驻服务，接着把 DeepSeek API 接进 VS Code、Codex 和 Dify 这类已有工作流，最后绕回 PDF 本身，把手册解析成可检索的知识库。适合手里只有一张消费级显卡、但想把本地部署 AI 这件事做扎实的读者。
2. DeepSeek 本地部署选型：Ollama、vLLM、llama.cpp 怎么选
2.1 三条路线的显存占用与并发吞吐对照
部署工具的选择先看两件事：你手上有多少显存，以及同一时间会有几个人请求。DeepSeek 官方开源的主力是 MoE 架构的 V3 系列，以及基于 Qwen、Llama 蒸馏出来的 R1 系列。前者全量权重动辄数百 GB，普通单机基本没戏；真正能在消费级硬件上跑的，是 1.5B 到 70B 的 R1 蒸馏版。围绕这些尺寸，常见做法就三条路：
| 推理工具 | 底层实现 | 典型显存需求 | 并发能力 | 量化支持 | 适用场景 |
|---|---|---|---|---|---|
| Ollama | llama.cpp 封装 | 7B Q4 约 5–6 GB | 低，单机串行为主 | GGUF，开箱即用 | 个人开发机、内网小团队 |
| vLLM | PagedAttention | 7B FP16 约 16 GB 起 | 高，批量吞吐强 | AWQ、GPTQ | 多卡服务器、对外 API |
| llama.cpp | 原生 C++ | CPU + 部分显存卸载 | 低 | GGUF，量化粒度细 | 无独显、边缘设备 |
选型上不需要纠结太久：一台带独显的开发机，Ollama 是最短路径；真要在公司内网做七八个人共用的接口，再考虑 vLLM。llama.cpp 适合那种只有 CPU、又想跑 1.5B 或 7B 量化版的场景，速度慢但能出结果。
2.2 按硬件分档的 DeepSeek 蒸馏版选型表
模型尺寸不是越大越好，显存不够时 Ollama 会退到内存和 CPU，速度会掉一个数量级。下面这张表是实际部署时比较稳的对应关系，量化统一按 Q4_K_M 估算：
| 硬件配置 | 推荐模型标签 | 量化 | 显存占用 | 预期体验 |
|---|---|---|---|---|
| 8 GB 显存 | deepseek-r1:7b | Q4 | 约 5–6 GB | 日常问答、代码补全可用 |
| 12 GB 显存 | deepseek-r1:14b | Q4 | 约 9–10 GB | 推理链条更完整 |
| 24 GB 显存 | deepseek-r1:32b | Q4 | 约 20–22 GB | 接近可用生产水平 |
| 48 GB 及以上 | deepseek-r1:70b | Q4 | 约 40 GB+ | 单机上限，速度取决于带宽 |
| 仅 CPU、16 GB 内存 | deepseek-r1:1.5b | Q4 | 纯内存 | 验证流程，不适合干活 |
注意：模型标签会随上游更新变化，拉取前用
ollama list看一眼本地已有的，别重复下几百 GB。
2.3 极简手册里最容易写错的两个前置条件
第一个是驱动版本。Ollama 自带 CUDA runtime，但它依赖宿主机 NVIDIA 驱动。驱动太旧时ollama run不报错，只是静默走 CPU，速度慢得让人以为模型不行。部署前先确认：
nvidia-smi # 看驱动版本和显存占用 nvcc --version # 看 CUDA 编译器版本，两者不需要完全一致 docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi最后一条是验证 Docker 能不能拿到 GPU。没有输出 GPU 信息，说明 nvidia-container-toolkit 没装好，后面 Docker 部署 Ollama 会直接失败。第二个坑是磁盘和共享显存。Linux 下模型默认落在~/.ollama/models，7B Q4 大约 4–5 GB，70B 超过 40 GB，装之前先看空间：
df -h ~/.ollama du -sh ~/.ollama/modelsWindows 上还有共享显存的问题：任务管理器里显示显存没满，实际上部分层被放到内存，token 速度会从几十掉到个位数。判断方法是在推理时看任务管理器的“共享 GPU 内存”有没有明显上涨。
3. 用 Ollama 跑通 DeepSeek 本地部署的最小命令
3.1 安装 Ollama 与拉取 DeepSeek-R1 蒸馏模型
Linux 上一行脚本装完，Windows 和 macOS 直接下安装包。装完先确认服务在监听 11434：
curl -fsSL https://ollama.com/install.sh | sh systemctl status ollama ollama pull deepseek-r1:7b ollama run deepseek-r1:7bpull只下载权重，run会进入交互式对话。第一次跑建议先用 7B 验证链路，确认 GPU 被调用、token 速度正常，再换更大的模型。判断是否走 GPU，另开一个终端跑nvidia-smi，看显存有没有被 Ollama 占住，以及 GPU 利用率是否在推理期间跳起来。
3.2 用 Modelfile 固定推理参数
每次对话都手敲 temperature 不现实，常见做法是写一个 Modelfile 派生新模型：
FROM deepseek-r1:7b PARAMETER temperature 0.6 PARAMETER top_p 0.95 PARAMETER num_ctx 8192 PARAMETER repeat_penalty 1.1 SYSTEM """ 你是一名严谨的后端工程师助手。回答先给结论，再给可执行命令， 命令必须标注语言，参数给出取值范围。 """保存为Modelfile，执行ollama create my-deepseek -f Modelfile，之后用ollama run my-deepseek。参数上，R1 系列官方推荐的 temperature 在 0.5–0.7 之间，0.6 是推理任务的稳妥值；num_ctx决定上下文窗口，调大直接吃显存，8K 对大多数代码问答够用；repeat_penalty用来压重复输出，设太高会让模型不敢复用术语，1.1 是比较温和的起点。
3.3 用 Docker 把 Ollama 部署成常驻服务
开发机上ollama serve就够了，但内网要给同事共用，Docker Compose 更省心：
services: ollama: image: ollama/ollama:latest container_name: ollama restart: unless-stopped ports: - "11434:11434" volumes: - ./ollama:/root/.ollama environment: - OLLAMA_KEEP_ALIVE=24h - OLLAMA_NUM_PARALLEL=2 deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu]docker compose up -d之后，模型数据落在当前目录的ollama文件夹，容器重建不丢。OLLAMA_KEEP_ALIVE=24h让模型常驻显存，避免每次请求重新加载；OLLAMA_NUM_PARALLEL=2控制并发路数，设太大会互相抢显存。没有 GPU 的机器把整个deploy段删掉即可，Ollama 会退到 CPU。
3.4 curl 验证 DeepSeek 生成与 OpenAI 兼容接口
服务起来后别急着接插件，先用 curl 确认两个端点。原生生成接口：
curl http://localhost:11434/api/generate -d '{ "model": "my-deepseek", "prompt": "用三行说明 OLLAMA_KEEP_ALIVE 的作用", "stream": false, "options": { "num_ctx": 4096, "temperature": 0.6 } }'stream设 false 是为了拿到完整 JSON，方便脚本断言；options里的参数会覆盖 Modelfile 中的默认值。再验证 OpenAI 兼容端点：
curl http://localhost:11434/v1/models curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"my-deepseek","messages":[{"role":"user","content":"hi"}]}'/v1/models能列出模型，说明兼容层正常。这两个端点通了，后面的 VS Code、Codex、Dify 接入基本不会有结构性障碍，剩下的都是配置路径问题。
4. DeepSeek API 调用与 VS Code、Codex 接入：把本地模型塞进工作流
4.1 DeepSeek API 的 OpenAI 兼容格式与必调参数
本地 Ollama 暴露的/v1和 DeepSeek 官方 API 都是 OpenAI 兼容格式，代码可以一套写两处跑，只换base_url和api_key：
from openai import OpenAI client = OpenAI( api_key="ollama", # 本地服务不校验，但不能留空 base_url="http://localhost:11434/v1", # 换成官方地址即走云端 ) resp = client.chat.completions.create( model="my-deepseek", messages=[{"role": "user", "content": "给出一个 Docker 健康检查的写法"}], temperature=0.6, max_tokens=1024, stream=False, ) print(resp.choices[0].message.content)max_tokens要和 Ollama 的num_ctx对齐，请求的上下文加输出超过窗口会被截断；stream=True时记得遍历 chunk，不要直接取choices[0]。如果返回 404，优先检查模型名是否和ollama list里的完全一致，大小写和标签都不能少。
4.2 VS Code 接入 DeepSeek 的配置片段
VS Code 里接本地模型，Continue 和 Cline 是两个常见选择。以 Continue 为例，在配置里加一段模型定义：
models: - title: DeepSeek Local provider: openai model: my-deepseek apiBase: http://localhost:11434/v1 apiKey: ollama contextLength: 8192contextLength要和 Modelfile 的num_ctx一致，填大了插件会发超长请求，模型侧截断后表现成“答非所问”。如果 VS Code 跑在容器或远程开发环境里，localhost指向的是那台远程机，需要把apiBase换成宿主机的内网地址，并确认 11434 端口没有只绑在回环地址上。
4.3 Codex 接入 DeepSeek 的本地端点写法
Codex 这类命令行编码代理，通常走 OpenAI 兼容环境变量。把端点指向本地即可：
export OPENAI_BASE_URL=http://localhost:11434/v1 export OPENAI_API_KEY=ollama codex --model my-deepseek提示：部分工具会先调用
/v1/models做能力探测，本地模型不在白名单里时可能被拒绝，这时需要看工具是否支持自定义模型名。
如果 Codex 提示模型不存在，先用curl http://localhost:11434/v1/models确认返回值，再检查工具配置文件里有没有硬编码的模型列表。另一个高频问题是超时：本地 7B 模型生成一段长代码可能超过工具默认的 30 秒，把超时调到 120 秒以上再试。
4.4 Dify 本地部署后接 DeepSeek 做知识库
Dify 用 Docker Compose 部署后，在模型供应商里选“OpenAI-API-compatible”，base_url填 Ollama 的地址。这里有个容器网络坑：Dify 容器里的localhost指向容器自己，不是宿主机。要么用host.docker.internal，要么直接填宿主机在 Docker 网桥上的地址：
ip addr show docker0 | grep inet # 输出类似 inet 172.17.0.1/16，那 base_url 就是 http://172.17.0.1:11434/v1Dify 里建知识库时，嵌入模型也要单独配一个，本地可以用 Ollama 拉一个小的 embedding 模型，或者接一个兼容的嵌入服务。配完之后先用一篇短文档做召回测试，确认检索命中的片段确实包含答案，再去接对话应用，否则后面调试会分不清是检索错还是生成错。
5. 把 DeepSeek 极简部署手册 PDF 变成可检索知识库的 3 个技巧
5.1 用 pdfplumber 抽取手册里的参数表
部署手册里最有价值的是参数表和命令示例，但 PDF 里的表格直接复制会串行。先用 pdfplumber 把表格和文本分开抽：
import pdfplumber with pdfplumber.open("DeepSeek极简部署手册.pdf") as pdf: for i, page in enumerate(pdf.pages): for t in page.extract_tables(): print(f"page {i} table:", t) # 表格按行返回 text = page.extract_text() or "" print(f"page {i} text len:", len(text))extract_tables依赖页面里的线框，扫描件或无线框表格拿不到结果，这种情况改用extract_words按坐标聚类。抽完先人工核对两页，确认参数没有错位，再批量跑全本。
5.2 PDF 转 Markdown 与切片策略
命令类内容更适合先转 Markdown 再切。marker 这类工具能保留代码块和标题层级：
pip install marker-pdf marker_single DeepSeek极简部署手册.pdf --output_dir ./md切片时按标题层级切，chunk 控制在 512 token 左右、overlap 留 64，代码块单独成段，不要和正文混在一个 chunk 里。手册里“显存不够怎么改参数”这类问题，答案往往跨两三个段落，overlap 太小会切掉关键上下文。
5.3 检索验证与常见坑
建完知识库别只看“能回答”，准备 20 个真实部署问题做回归，比如“7B 在 8 GB 显存上要调什么参数”“Docker 里 GPU 不生效怎么排查”，逐条看召回片段是否命中对应章节。最常见的坑是 PDF 截图里的命令无法检索，只能上 OCR；另一个是pdf转word后再切分有时比直接解析更干净，尤其是双栏排版的手册。验证通过后，把本地 DeepSeek 和这份知识库接进 Dify，一个能查手册、能跑命令的内网助手就成型了。
本文还有配套的精品资源，点击获取
