你会发现：本地部署大模型真正的门槛，从来不是“装不装得上”，而是三件事——模型选型、运行稳定性、以及后续的知识库与权限边界。

这篇我按“工程交付”的方式重写：不追求花哨工具链，而是给你一条最短路径，把 DeepSeek-R1 做成可离线、可对话、可接知识库、可长期维护的私人 AI 助手；同时补齐截至 2025-12 / 2026-01 的关键更新（DeepSeek-R1-0528、Open WebUI 的离线/RAG、vLLM 的 FP8/FP4 部署路线等）。(Ollama)

---

1. 引言：本地化的价值，不是“省钱”，而是“可控”

把模型放到本地，带来的不是“替代云端”那么简单，而是三种能力的回归：

• 数据边界回归：敏感文档不出内网（尤其是单位资料、合同、论文、馆藏业务数据）
• 控制权回归：模型版本、提示词、知识库、日志都在你手里
• 可复用回归：一次搭好，后续可以把“助手”变成一套可迁移的环境（新电脑/新服务器照搬）

我的经验是：本地部署要从第一天就按“项目”来做，而不是“装完能聊就算完”。

---

2. DeepSeek R1 最新版本与模型家族：你部署的不是一个模型，而是一套梯度

2.1 你现在应该知道的“新变化”

• DeepSeek-R1 已升级到 DeepSeek-R1-0528（在推理深度与推理能力上做了增强，且在 Ollama 模型库中有明确说明）。(Ollama)
• Ollama 的 deepseek-r1 系列提供多尺寸（1.5B/7B/8B/14B/32B/70B/671B），并且多数版本提供 128K 上下文窗口（671B 为 160K）。(Ollama)
• 许可层面：Ollama 页面明确提到 DeepSeek-R1 权重为 MIT License，并支持商业用途与衍生（同时提示蒸馏来源模型可能有各自许可）。(Ollama)

2.2 关键一句话（选型原则）

本地部署选模型，不是“越大越好”，而是“在你的硬件上长期稳定、可复现、可更新”。

---

3. 安装准备：先把“运行形态”定下来

我把本地部署分成两条路线：

• 路线 A（个人电脑/工作站）：Ollama + Open WebUI（最快形成可用助手）
• 路线 B（团队/服务器/高吞吐）：vLLM（FP8/FP4、并行、服务化更强）

Open WebUI 明确支持 Ollama 与 OpenAI-compatible API，并强调可离线与内置 RAG 能力。(Open WebUI)
vLLM 的官方 Recipes 已给出 DeepSeek-R1-0528 的 FP8/FP4 服务方式与关键环境变量。(vLLM)

---

4. 路线 A：Ollama 本地部署（推荐给 90% 的人）

4.1 安装 Ollama

• 到 Ollama 官网按系统安装即可（Windows/macOS/Linux）。安装后验证：

ollama --version

4.2 拉取并运行 DeepSeek-R1（注意：不是 deepseek-coder）

Ollama 官方库里，默认 deepseek-r1 指向 8B（Qwen3-8B 蒸馏版本）：(Ollama)

ollama run deepseek-r1

按尺寸显式运行（更可控）：(Ollama)

ollama run deepseek-r1:1.5b
ollama run deepseek-r1:7b
ollama run deepseek-r1:8b
ollama run deepseek-r1:14b
ollama run deepseek-r1:32b
ollama run deepseek-r1:70b

更新模型（避免你还在旧版本上折腾）：(Ollama)

ollama pull deepseek-r1

4.3 一个现实提醒：671B 不是给“正常人本地跑”的

Ollama 库里确实有 deepseek-r1:671b，体积 404GB，且标注 160K context。(Ollama)
社区有人基于 Unsloth 做了“动态量化到 1.58bit / 2.51bit”的 GGUF 合并版本，并声称可在单张 4090 上尝试运行（是否可用取决于驱动、实现与边界条件，你要把它当作“实验项目”，而不是生产方案）。(Ollama)

---

5. 路线 A 增强：Open WebUI（把“能跑”升级为“可用助手”）

Open WebUI 的定位已经不是“一个聊天 UI”，而是一个可离线的自托管 AI 平台：支持 Ollama / OpenAI-compatible API，并内置 RAG 等能力。(Open WebUI)

5.1 Docker 一键部署 Open WebUI

（保持你原来的命令思路，我补一句“为什么要这样写”）

docker run -d \
  --add-host=host.docker.internal:host-gateway \
  -v openwebui:/app/backend/data \
  -p 3000:8080 \
  --name openwebui \
  --restart always \
  ghcr.io/open-webui/openwebui:main

• host.docker.internal 让容器能访问宿主机的 Ollama（典型场景：Ollama 装在宿主机，WebUI 在容器里）

访问：

• http://localhost:3000

5.2 “私人助手”的最低可用闭环（建议你照这个做）

1. 用 Open WebUI 连接 Ollama

2. 选择 deepseek-r1:8b 或 deepseek-r1:14b 做主模型

3. 开一套“个人知识库”（只喂你允许的数据）

4. 固化三份资产：

   • 系统提示词（System Prompt）
   • 知识库范围（哪些文件夹/哪些文档）
   • 操作规程（怎么更新模型、怎么备份、怎么迁移）

---

6. 路线 B：vLLM 部署（给“要服务化 / 要吞吐 / 要并行”的人）

如果你做的是团队内部 API、或者要高吞吐推理，vLLM 是主流选择之一。vLLM Recipes 明确给出了 DeepSeek-R1-0528 的 FP8/FP4 路线、并行策略（TP/DP + EP）与关键环境变量。(vLLM)

6.1 安装 vLLM（官方示例）

uv venv
source .venv/bin/activate
uv pip install -U vllm --torch-backend auto

(vLLM)

6.2 FP8（示例：8xH200）

export VLLM_ATTENTION_BACKEND=CUTLASS_MLA
export VLLM_USE_FLASHINFER_MOE_FP8=1
vllm serve deepseek-ai/DeepSeek-R1-0528 \
  --trust-remote-code \
  --tensor-parallel-size 8 \
  --enable-expert-parallel

(vLLM)

6.3 FP4（示例：4xB200）

export VLLM_ATTENTION_BACKEND=CUTLASS_MLA
export VLLM_USE_FLASHINFER_MOE_FP4=1
CUDA_VISIBLE_DEVICES=0,1,2,3 vllm serve nvidia/DeepSeek-R1-FP4 \
  --trust-remote-code \
  --tensor-parallel-size 4 \
  --enable-expert-parallel

(vLLM)

6.4 你最该关注的两个“工程参数”

• --max-model-len：控制最大上下文长度（降它可以显著省显存/内存）(vLLM)
• --max-num-batched-tokens：吞吐与延迟的平衡点（并发/批量越大，吞吐越高但延迟更高）(vLLM)

---

7. 模型选择与优化：我给你一个“工程局”的决策表（不玄学）

7.1 按目标选模型（现实主义版本）

• 日常私人助手：优先 8B（默认 deepseek-r1）(Ollama)
• 更强推理 + 还能在单机玩得转：14B / 32B（看你的 GPU/内存）(Ollama)
• 对外服务、并发吞吐：走 vLLM（FP8/FP4）路线，不要用“桌面跑法”硬撑(vLLM)
• “我就想挑战极限”：671B 及其极限量化版本，按实验项目对待(Ollama)

7.2 一条底层规律（你越早接受越省时间）

本地推理的瓶颈不是“算力”，而是“显存/内存 + KV Cache + 上下文长度”。你不控制上下文，就会被动掉进性能坑。

---

8. 实际应用场景：把它真正变成“你的私人 AI 助手”

这里我建议你直接按“模块化能力”搭：

8.1 离线文档助手（强烈推荐）

• 会议纪要、项目方案、合规文档、论文笔记：本地总结、提取要点、生成对外版本
• 关键在于：文档进入知识库前先做“分级”（可公开/内部/敏感）

8.2 本地研发/代码助手

• 解释代码、生成脚手架、写测试、生成 README
• 你要做的是：给它一个“你的工程规范”（目录结构、日志格式、commit 规范）

8.3 内部知识库问答（RAG）

Open WebUI 已强调具备内置 RAG/离线平台能力，你可以把它当作“最快的本地知识库入口”。(Open WebUI)

---

9. 故障排除：工程问题一律按“定位链路”处理

9.1 典型问题 1：模型能跑但很慢

定位顺序：

1. 你是不是把上下文拉到 50K+ 还不自知（先控长度）
2. 你是不是并发开太多（先降并发/关多会话）
3. 你是不是模型选大了（先换小一档验证稳定性，再谈性能）

9.2 典型问题 2：Docker/Open WebUI 连不上 Ollama

先确认两点：

• Ollama 服务是否在跑
• Docker 容器是否能访问宿主机（host.docker.internal 这类桥接是否配置正确）(Open WebUI)

---

10. 安全与隐私：本地化不是“自动安全”，你还得做边界

本地部署解决的是“数据不出门”，但不自动解决：

• 误把敏感资料喂给知识库
• 提示词注入导致的“越权回答”（尤其接工具/接文件系统时）
• 共享设备导致的会话泄露

我建议你至少做三条制度化约束：

1. 知识库分级（可公开/内部/敏感三层）
2. 默认不接外部工具（先把“对话 + 知识库”跑稳）
3. 定期备份与清理（尤其是聊天记录、索引文件）

---

11. 总结：你要交付的不是“模型”，而是“可持续的私人助手系统”

把 DeepSeek-R1 跑起来只需要 10 分钟；
把它做成可维护、可迁移、可升级、可控边界的私人助手，需要你用工程思维补齐三件资产：

• 模型资产：版本、选型、更新策略（R1-0528 起步）(Ollama)
• 平台资产：Ollama / Open WebUI（离线、可控、可扩展）(Open WebUI)
• 运维资产：日志、备份、知识库分级、上下文与性能策略（尤其是 max len 与批量策略）(vLLM)