场景与需求
要把一批敏感对话记录做本地摘要打标——数据不能出门，这是硬约束。同时希望断网也能干活，也不再为每一次调用付费。这就把方案逼到了本地部署上。
但”本地跑 DeepSeek”有个必须先澄清的点：DeepSeek 满血版是 671B 参数的 MoE 大模型（激活参数量级为几十 B），消费级设备不用考虑；官方开源的 R1 蒸馏系列（1.5B 到 70B）才是个人显卡的现实选项。蒸馏版的底座有两支：Qwen 系和 Llama 系，R1 的推理能力被蒸馏进这些稠密小模型里。所以真正的问题是：蒸馏版里选哪一档，我的显卡扛得住吗。
候选方案
| 方案 | 形态 | 成本 | 数据隐私 | 能力 |
|---|---|---|---|---|
| DeepSeek 官方 API | 云端调用 | 按 token 计费 | 数据出本地 | 满血模型，能力天花板 |
| 蒸馏版本地部署（Ollama / llama.cpp） | 自己的 GPU/CPU | 一次性硬件 + 电费 | 数据不出门 | 蒸馏后能力下降，档位越小越明显 |
| 蒸馏版 + API 混合 | 本地预处理 + 云端精算 | 混合 | 敏感部分不出门 | 兼顾隐私与质量 |
方案三是我的实际形态：本地做脱敏、初筛、草稿，云端做重活。接入方式的整体选择逻辑见DeepSeek 怎么用：网页版/App/API/本地部署怎么选。
测算模型与假设
显存占用由三部分组成：
显存 ≈ 模型权重 + KV cache（随上下文长度增长）+ 框架运行开销
权重体积 ≈ 参数量 × 每参数字节数量化档位决定每参数占几个字节，以 7B 为例换算（位宽换算是通用算术，体积为量级估算）：
| 精度 | 每参数字节 | 7B 权重体积（约） | 说明 |
|---|---|---|---|
| FP16 | 2 字节 | 约 14 GB | 无量化，消费级装不下 |
| Q8 | 约 1 字节 | 约 7 GB | 质量接近无损 |
| Q4 | 约 0.5~0.6 字节 | 约 4 GB | 消费级主流选择 |
4bit 量化是消费级主流：质量损失可接受、显存砍到 FP16 的四分之一。Ollama 拉下来的 deepseek-r1 各档默认就是 4bit 量级（精确量化格式【待补：ollama show 输出】），GGUF 格式的 Q4_K_M 是 llama.cpp 生态的常用档。上下文开得越长 KV cache 吃得越多，具体增量与上下文长度、档位都相关【待补：实测 KV cache 增量】，小显存卡别把上下文拉满。还有一条容易忽略的默认值：Ollama 默认上下文长度只有 2048 tokens（num_ctx 参数），中文长文很容易顶满，跑长文任务前要显式调大，同时留意显存余量。
测算结果表
按 4bit 口径估各档位（精确文件体积【待补：模型发布页数据】）：
| 档位 | 底座 | Q4 权重体积（约） | 建议显存（约） | 适配硬件参考 |
|---|---|---|---|---|
| 1.5B | Qwen | 1 GB 上下 | 2~4 GB | 核显 / 纯 CPU |
| 7B / 8B | Qwen / Llama | 4~5 GB | 6~8 GB | RTX 3060 12G、4060 级 |
| 14B | Qwen | 约 9 GB | 10~12 GB | RTX 3060 12G、4070 |
| 32B | Qwen | 约 20 GB | 24 GB | RTX 3090 / 4090 |
| 70B | Llama | 40 GB 上下 | 48 GB 级 | 双卡工作站 / 云 GPU |
三档分界线很清楚：12 GB 显存是个人玩家最舒服的位置（14B 及以下都装得下）；8 GB 显存的卡选 7B/8B 档；32B 以上开始要 24 GB 的卡或者多卡。Mac 用户看统一内存，16 GB 的机器跑 7B/8B 没有压力。70B 档对个人过于奢侈，本文不再展开。
显存装不下也可以跑：纯 CPU 走内存，或显存内存分层 offload。代价是速度——GPU 全量加载时 7B 档生成速度可达每秒几十 tokens，交互流畅【待补：本机实测 tokens/s】；offload 或纯 CPU 会掉一个数量级，只适合离线跑批，不适合对话。硬件预算参考【待补：显卡与内存当前市场价格】。
决策框架
按顺序过四个问题：
- 数据能不能出门？ 能出门就直接用官方 API，单价低到大多数个人场景不必自建（账见DeepSeek API 价格与计费详解）；不能出门才继续往下。
- 显存多大？ 拿不准就按”Q4 权重体积 + 2~3 GB 余量”估，从上表挑能装下的最大档位。
- 质量要求多高？ 蒸馏版与满血版差距明显，档位越小差距越大。摘要、分类、脱敏这类活 7B/14B 足够；复杂推理别指望本地小模型，宁可交给云端。
- 速度要求多高？ 交互式应用必须全量进显存；离线跑批可以接受慢速，甚至 CPU。
我的最终选择
我的主力机是 12 GB 显存的卡，最终配置如下：
- 日常主力：14B 档，Q4 量化全量进显存，摘要/打标质量比 7B 档好一截，速度可接受【待补：实测数据】；
- 兜底与老旧设备：7B/8B 档，速度优先的批量任务用它；
- 重任务走 API：本地只做脱敏预处理，硬任务交给云端的 deepseek-reasoner（两类模型怎么分工见DeepSeek V3 与 R1 怎么选）。
Ollama 五条命令完成拉取、检查、运行（安装与镜像加速见Ollama 安装部署教程）：
ollama pull deepseek-r1:14b
ollama list # 看已下载的模型和体积
ollama show deepseek-r1:14b # 看量化格式与参数量
ollama run deepseek-r1:14b # 进对话，/bye 退出
ollama ps # 看加载状态：100% GPU 还是部分 CPUOllama 自带 OpenAI 兼容接口，监听在 http://localhost:11434/v1，所以前面写的 openai SDK 代码换个 base_url 就能打到本地模型：
from openai import OpenAI
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
resp = client.chat.completions.create(
model="deepseek-r1:14b",
messages=[{"role": "user", "content": "把这段话脱敏：张三 13800000000 欠款 5000 元"}],
)
print(resp.choices[0].message.content)本地一套跑通之后，“数据不出门”这条硬约束就落地了，剩下的就是按实测速度与质量微调档位。模型下载慢的问题单独有解法，见Ollama 下载慢：国内镜像与代理加速。