第 6 章　本地部署：把 AI 装进自己电脑

预计阅读 17 分钟 · 全文约 4,968 字

本章产出：一份"我的硬件能跑什么模型"对照表，以及一次真实的本地模型评测记录。

---

开场：花八千块买的教训

有个哥们，看到网上说"本地部署大模型，隐私安全还免费"，热血上头，花八千配了台机器：RTX 4060 8G 显卡，32G 内存。

他兴冲冲下载了一个 70B 的模型，双击加载。

屏幕卡了十五分钟，然后弹出一行字：显存不足。

他不信邪，换了个 32B 的，还是显存不足。又换 14B，勉强能跑，但速度慢得像幻灯片，问一句等半分钟。

最后他跑了个 7B，能用，但他很失望："这 7B 怎么这么笨？还不如网页版。"

他犯了两个错：

1. 没算硬件账：8G 显存，跑 70B 是物理上不可能
2. 对本地模型的预期错了：他以为本地模型 = 云端旗舰，实际是"同价位下的妥协版"

这一章，人家把硬件账给你算清楚，把本地模型的真实边界给你划清楚。看完你就知道：你的机器能跑什么、该跑什么、值不值得跑。

---

6.1 硬件账：显存、内存、量化档位

先记住一个核心公式

模型能不能跑，主要看显存（VRAM）
显存够不够，取决于：模型参数量 × 量化位数

粗略估算（每 10 亿参数）：

量化精度	每 1B 参数占用	8B 模型	14B 模型	32B 模型	70B 模型
FP16（16 位）	2 GB	16 GB	28 GB	64 GB	140 GB
8 位（Q8）	1 GB	8 GB	14 GB	32 GB	70 GB
4 位（Q4）	0.5-0.6 GB	4-5 GB	7-8 GB	16-19 GB	35-42 GB
2 位（Q2）	0.3 GB	2.4 GB	4.2 GB	10 GB	21 GB

还要加上"上下文开销"：上下文越长，KV 缓存占用越大。开 8K 上下文，可能再加 1-2 GB；开 32K，可能加 4-8 GB。

图 6-1：显存决定模型规模

按显存选模型（实用对照）

你的显存	能跑（Q4 量化）	跑得舒服	建议
4 GB	1B-2B	1B	只能玩玩
6 GB	3B-4B	3B	简单任务
8 GB	7B-8B	7B	入门主力
12 GB	14B	7B-8B	平衡之选
16 GB	14B-20B	14B	性价比甜点
24 GB	32B	14B-24B	高端消费级
48 GB	70B（Q4）	32B	专业级
80 GB+	70B+	70B	企业级

内存（RAM）的作用

显存不够的时候，模型可以"部分加载到内存"，用 CPU 跑剩下的层。

这叫"CPU offload"。

代价：速度暴跌。CPU 跑模型比 GPU 慢几十倍。你可能从"每秒 30 字"变成"每秒 1 字"。

经验值：模型大小超过显存 20% 以上，速度就会明显受影响；超过一倍，基本没法用。

一个真实案例

你的配置：RTX 5060 8G + 32G 内存。

能跑的：

• 7B/8B 模型（Q4/Q5 量化）——流畅，速度 20-40 token/s
• 14B 模型（Q3/Q4 量化）——能跑，但上下文不能开太大，速度 10-15 token/s
• 32B 模型——理论上能"部分 offload"跑，但速度会慢到怀疑人生

不能跑的：

• 70B——显存差太远
• 未量化的 14B 以上——显存不够

结论：8G 显存的现实定位是"7B-8B 主力 + 14B 尝鲜"。想要 32B 以上，得上 24G 或更高。

---

6.2 量化原理：精度换体积

什么是量化

量化 = 把模型里的数字，用更少的位数表示。

原始模型用的是 16 位浮点数（FP16），每个参数占 2 字节。量化就是把它压成 8 位、4 位、甚至 2 位。

类比：把无损音乐（WAV）压成 MP3。文件小了十倍，大部分人听不出区别，但发烧友能听出来。

常见量化档位

档位	位数	体积	质量损失	建议
FP16	16	100%	无	显存足够时用
Q8	8	50%	极小	几乎无损
Q6	6	38%	很小	推荐
Q5	5	32%	小	推荐
Q4	4	25%	可接受	最常用
Q3	3	19%	明显	显存紧张时用
Q2	2	13%	严重	能跑就行
IQ 系列	2-4	类似	优化过的低比特	同体积下质量更好

一般规律：Q4 是"质量/体积"的最佳平衡点。Q5、Q6 质量更好但更占显存。Q3 以下质量下降明显。

什么是 IQ 量化

IQ（Importance-aware Quantization）= 重要性感知量化。

它的思路：不是所有参数都一样重要。重要的参数用更高精度，不重要的用更低精度。

效果：同样体积下，IQ 系列比传统 Q 系列质量更好。比如 IQ3 可能接近 Q4 的质量，但体积只有 Q3。

这就是为什么有些玩家追 IQ3_S、IQ4_XS 这类档位——在同显存下榨出更好的质量。

量化的质量损失体现在哪

• 知识召回：记得没那么准（问细节容易错）
• 推理链：复杂推理容易断
• 长文生成：容易跑题、重复
• 代码能力：小错误变多

Q4 以上的损失通常可以接受；Q3 以下，你能明显感觉到"变笨"。

一个反直觉的事实

小模型高量化，不如大模型低量化。

比如：一个 8B 模型用 Q8（8G 显存），和一个 14B 模型用 Q4（8G 显存）——通常 14B Q4 更强。

原因：参数量带来的"知识容量"提升，比量化精度带来的"精度损失"更重要。

选型原则：在显存允许的范围内，选最大的模型，用能接受的量化档位。

---

6.3 LM Studio / Ollama 实操

LM Studio：图形界面，适合新手

下载安装：官网下载对应系统版本，一路下一步。

使用流程：

1. 打开软件，搜索模型（比如搜 "qwen"）
2. 看每个模型的标注：参数量、量化档位、文件大小
3. 选一个显存放得下的，点下载
4. 下载完，在聊天界面选这个模型，开始聊
5. 右侧可以调参数：温度、上下文长度、GPU 层数

关键设置：

• GPU Offload：把多少层放到 GPU。全放（拉满）最快，显存不够就少放几层
• Context Length：上下文长度。开太大吃显存，一般 4K-8K 够用
• Temperature：温度，按任务调

Ollama：命令行，适合自动化和开发者

安装：官网下载或用包管理器。

基本命令：

# 拉取模型
ollama pull qwen3:8b

# 运行（进入对话）
ollama run qwen3:8b

# 查看已下载的模型
ollama list

# 删除模型
ollama rm qwen3:8b

# 启动 API 服务（默认 11434 端口）
ollama serve

调用 API：

curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "prompt": "你好，介绍一下你自己",
  "stream": false
}'

Ollama 的优势：接口简单，容易被其他程序调用。很多客户端（Cherry Studio 等）支持直接接 Ollama。

两个工具的对比

	LM Studio	Ollama
界面	图形化	命令行
上手难度	低	中
模型管理	点选	命令
API	有（OpenAI 兼容）	有（自有格式 + OpenAI 兼容）
适合	新手、桌面使用	开发者、自动化

建议：新手先用 LM Studio 摸清概念，需要接程序时再用 Ollama。

---

6.4 本地模型能干啥、不能干啥

能干的（7B-8B 级别）

• 文本分类：情感分析、主题分类、垃圾内容识别
• 信息提取：从文本里抽人名、日期、金额、地址
• 格式转换：JSON 转表格、文本转结构化
• 简单翻译：日常短句翻译
• 文本润色：改错别字、调整语气
• 简单问答：基于给定材料的问答
• 代码补全：简单的函数补全

共同特点：任务明确、输入输出格式固定、不需要复杂推理。

干不好的

• 复杂推理：多步数学、逻辑推理、长篇分析
• 长文写作：写几千字的文章，容易跑题、重复
• 专业领域：法律、医学、金融的深度问题
• 多轮复杂对话：聊几轮就开始犯迷糊
• 代码架构设计：能写函数，设计不了系统

一个判断标准

问自己：这个任务，一个刚毕业的实习生能不能干？

• 能 → 7B 模型大概率能干
• 要经验 → 得上大模型
• 要专家 → 上旗舰模型 + 人工复核

本地模型的真正价值

不是"替代云端"，是**"处理那些不该上云的任务"**：

• 敏感数据（合同、病历、内部文档）
• 高频简单任务（省钱）
• 离线环境
• 学习研究

别指望 8G 显存的本地模型能替代 GPT-5。 它是"够用的小工具"，不是"万能的大脑"。

---

6.5 本地 vs 云端：什么时候用哪个

对比表

维度	本地模型	云端模型
能力上限	中低（受硬件限制）	高
隐私	数据不出门	数据发给厂商
成本	硬件一次性 + 电费	按 token 付费
速度	取决于硬件	通常更快
离线	支持	不支持
维护	自己折腾	厂商维护
可定制	能微调	只能用

决策树

这个任务的数据敏感吗？
├─ 敏感 → 本地模型
└─ 不敏感
    ├─ 任务简单/重复/高频 → 本地模型（省钱）
    ├─ 任务复杂/要求高 → 云端大模型
    └─ 需要实时信息 → 云端（带联网）

混合用法（推荐）

日常大部分任务用云端便宜模型，敏感任务用本地，硬任务用云端旗舰。

举例：

• 写周报 → 云端中端模型
• 处理客户合同 → 本地模型
• 设计系统架构 → 云端旗舰
• 批量打标签 → 本地 7B

这样既省钱，又安全，能力也不缺。

---

6.6 实战：把本地模型接进客户端

为什么要接

本地模型自带界面通常很简陋。接进 Cherry Studio 这类客户端，你才能用上知识库、多模型切换、提示词管理。

Ollama 接 Cherry Studio

第一步：让 Ollama 常驻

ollama serve
# 默认监听 http://localhost:11434

第二步：在 Cherry Studio 里加提供方

1. 设置 → 模型服务 → 添加
2. 类型选 "Ollama"
3. 地址填 http://localhost:11434
4. 保存，然后拉取模型列表，勾选你要用的模型

第三步：测试

新建对话，选本地模型，问一句"你好"，能回就通了。

LM Studio 接 Cherry Studio

LM Studio 自带 OpenAI 兼容接口：

1. LM Studio → 开发者/Server 面板 → Start Server（默认 1234 端口）
2. Cherry Studio 添加提供方，类型选 "OpenAI 兼容"
3. base_url 填 http://localhost:1234/v1
4. API key 随便填（本地服务不校验）
5. 拉模型列表，选你下载的模型

接不上的三个常见原因

现象	原因	解法
连接被拒绝	服务没启动	先启动 Ollama/LM Studio 的 server
能连上但没模型	模型名不匹配	在客户端手动填模型名
回复很慢	跑在 CPU 上	检查 GPU 层数设置

---

6.7 性能调优：让本地模型跑得更快

影响速度的四个因素

1. GPU 层数：放 GPU 的层越多越快，显存不够就只能放 CPU
2. 上下文长度：开得越大越慢，因为每生成一个 token 都要看全部上下文
3. 量化档位：低量化更快，但质量下降
4. 批大小 / 并发：单用户场景影响不大，多请求时明显

实测对比（8G 显存，7B Q4 模型）

配置	速度	体验
全部 GPU 层，上下文 4K	30-40 token/s	流畅
全部 GPU 层，上下文 16K	15-20 token/s	可用
部分 CPU，上下文 4K	3-5 token/s	明显卡顿
部分 CPU，上下文 16K	1-2 token/s	基本没法用

结论：上下文长度对速度的影响，比大多数人想的大。

三个提速技巧

技巧一：按需开上下文

大部分对话用 4K 就够。只有处理长文档时才开大。

技巧二：用更小的模型干简单活

分类、提取这类任务，3B-4B 模型足够，速度快一倍。

技巧三：减少重复加载

模型加载要几十秒。用 server 模式常驻，别每次都重启。

一个真实的取舍

有人非要 8G 显存跑 14B Q5（约 10G），结果一半层跑 CPU，速度 2 token/s。

换成 7B Q4（4.5G）全放 GPU，速度 35 token/s。

虽然模型小了一半，但"能用的 7B"远胜"卡死的 14B"。

这就是量化/选型的核心取舍：不是越大越好，是"跑得动"才好。

---

6.8 本地模型选型清单

按用途选

用途	推荐规模	推荐量化	说明
文本分类/提取	3B-4B	Q4	快，够用
日常问答	7B-8B	Q4/Q5	主力
中文写作	14B	Q4	7B 写长文容易跑题
代码补全	7B-14B	Q4	选代码专用模型
长文总结	14B+	Q4	上下文要够
翻译	7B-8B	Q5	质量优先

按显存选（再确认一遍）

显存	稳妥选择	激进选择
6G	3B Q4	7B Q3
8G	7B Q4	8B Q5
12G	8B Q5	14B Q3
16G	14B Q4	20B Q3
24G	14B Q6	32B Q4

"稳妥"= 上下文能开 8K 且速度可接受；"激进"= 能加载，但可能卡。

三个不要

不要迷信参数量。 一个训练数据差的 32B，可能不如训练好的 7B。

不要用 Q2/Q3 跑重要任务。 质量损失明显，尤其是推理和代码。

不要拿本地模型干旗舰模型的活。 它会让你误以为"AI 不行"，其实是"你的模型不行"。

什么时候该升级硬件

信号一：你每天都在用本地模型，且经常因为"显存不够"放弃任务。

信号二：你需要处理的数据敏感，但又需要较强能力（比如读合同）。

信号三：你有稳定的本地任务量，算下来比 API 便宜。

否则：先用 API，别急着买卡。

---

6.9 本地部署 FAQ

Q：我只有核显/没有独显，能跑吗？

能，但只能跑 1B-3B 的小模型，速度慢。体验接近"能对话，但不太聪明"。

Q：模型下载太慢怎么办？

换国内镜像源；或者先下小模型（3B）熟悉流程，再下大模型。

Q：跑起来风扇狂转，正常吗？

正常。GPU 满载会发热。笔记本注意散热，别放床上。

Q：本地模型能联网吗？

不能，除非你给它接工具（第 7 章）。本地模型本身是"离线大脑"。

Q：本地模型能替代 API 吗？

不能。它是"补充"：处理敏感数据、离线场景、高频简单任务。复杂任务还是得云端旗舰。

Q：微调值得做吗？

大多数人不值得。微调要数据、要算力、要调参，效果还不一定比"提示词 + RAG"好。先用提示词和知识库，真不够再考虑微调。

Q：量化会不会把模型弄坏？

Q4 以上基本无损（体感）。Q3 以下明显变笨。宁可选小一号的高量化，也别选大一号的低量化。

Q：为什么同一个模型，别人跑得比我快？

看 GPU 层数、上下文长度、量化档位、驱动版本。先检查是不是有一部分层跑在 CPU 上。

---

6.10 本地模型跑批量任务：省钱的正确姿势

场景

你有 3000 条用户评论，要做情感分类（好评/差评/中性），还要提取关键词。

用 API：3000 条 × 每条 200 token ≈ 60 万 token，中端模型约 3 元。不算贵。

用本地模型：0 元，但你要写脚本、等它跑完（3000 条 × 1 秒 ≈ 50 分钟）。

什么时候值得本地跑？

• 数据敏感（不能外传）
• 量特别大（几万条以上）
• 长期高频（每天都要跑）

脚本示例（Ollama + Python）

import json, requests

def classify(text):
    prompt = f"""判断下面这条评论的情感，只输出一个词：好评/差评/中性。

评论：{text}
情感："""
    r = requests.post("http://localhost:11434/api/generate", json={
        "model": "qwen3:8b",
        "prompt": prompt,
        "stream": False,
        "options": {"temperature": 0}
    })
    return r.json()["response"].strip()

results = []
for i, text in enumerate(open("reviews.txt", encoding="utf-8")):
    text = text.strip()
    if not text:
        continue
    try:
        label = classify(text)
    except Exception as e:
        label = f"错误:{e}"
    results.append({"text": text, "label": label})
    if i % 50 == 0:
        print(f"进度 {i}，当前：{label}")

json.dump(results, open("labeled.json", "w", encoding="utf-8"),
          ensure_ascii=False, indent=2)

让批量任务更稳的五个技巧

技巧一：温度设 0。 分类任务要稳定，不要创意。

技巧二：强制输出格式。 让它只输出几个候选词，不要句子。

技巧三：加进度和断点。 每 50 条存一次，跑崩了能续。

技巧四：抽检。 随机抽 50 条人工核对，算准确率。

技巧五：失败重试一次。 本地模型偶尔会输出奇怪内容，重试一次通常就好了。

一个真实数据对比

有人用 7B 本地模型跑了 3000 条评论分类，结果：

指标	数值
总耗时	52 分钟
准确率（抽检 100 条）	87%
成本	0 元
同任务用 API 中端模型	3 元，准确率 91%

结论：差 4 个百分点，省 3 块钱。值不值，看你的时间值多少钱。

---

6.11 本地模型的"幻觉"比云端更严重

为什么

小模型参数少，知识装不下，遇到不知道的事更容易硬编。

典型表现：

• 问它一个冷门人物，它编一个生平
• 问它某个 API 的参数，它编一个不存在的
• 问它具体数字，它给一个"看起来合理"的

三个应对

① 明确告诉它"不知道就说不知道"

如果资料里没有，或者你不确定，直接回答"我不确定"。
编造答案会被视为错误。

② 给它资料，别靠它记忆

用 RAG（第 4 章），把答案放在上下文里，它就不需要"猜"。

③ 事实类任务加校验

数字、日期、人名，跑完用规则或第二个模型核对。

一句话总结

本地模型适合"有明确输入、有明确输出格式"的任务（分类、提取、改写），不适合"靠记忆回答事实"的任务。

---

行业观察：为什么医院和律所必须本地部署

一家律所买了 AI 工具，IT 负责人提了三个硬要求：

1. 数据不出内网：案件材料涉及当事人隐私，任何云端调用都要过合规审查
2. 可审计：谁在什么时候问了什么，要有日志
3. 断网可用：法院内网环境没有外网

结果：他们买了双卡工作站（约 6 万），本地跑 32B 模型，配套一个内部知识库。

算账：6 万一次性投入 vs 每年云端 API 费约 3 万 + 合规风险。两年回本，且风险可控。

行业细节：在医疗、法律、金融、军工这些行业，"能不能用"的第一道门槛不是效果，是数据能不能出这个房间。

---

踩坑实录

坑一：显存算错，模型加载失败

场景：有人 8G 显存，下载了 14B 的 Q5 模型（约 10G），加载报错"out of memory"。

为什么：只算了模型体积，没算上下文开销。14B Q5 模型 10G + 上下文 2G = 12G，超了。

怎么爬出来：按"模型体积 + 2-4G 上下文"估算；用 Q4 或更低的量化；减少 GPU 层数（部分跑 CPU）。

坑二：以为量化无损

场景：有人用 Q2 量化的 32B 模型，觉得"32B 肯定比 8B 强"，结果发现它连简单问题都答错。

为什么：Q2 量化损失严重，32B 被压成 Q2 后，实际能力可能不如 8B 的 Q5。

怎么爬出来：至少用 Q4；对比不同量化档位的实际表现，别只看参数量。

坑三：上下文开太大

场景：有人把上下文拉到 32K，结果模型变慢、显存爆、还开始胡说。

为什么：长上下文吃显存，而且很多模型对超长上下文处理不好（"lost in the middle"）。

怎么爬出来：按需开上下文，4K-8K 够大多数场景；真要长上下文，用支持长上下文的模型。

坑四：拿本地模型干它干不了的活

场景：有人用 7B 本地模型写商业方案，写出来全是套话，改了半天还不如自己写。

为什么：7B 模型的长文写作能力有限，容易重复、跑题。

怎么爬出来：认清边界——本地 7B 干"明确的小任务"，长文和复杂任务交给云端。

---

Lab 6-1｜跑起来，并测出它的边界

难度：⭐⭐⭐☆☆　预计耗时：90 分钟（含下载）

目标：本地跑通一个模型，并测出它到底能干什么

步骤：

1. 装 LM Studio 或 Ollama
2. 下载一个 7B-8B 的 Q4 量化模型（比如 Qwen3 8B）
3. 跑起来，确认能正常对话
4. 做五组测试，记录结果：
   • 分类测试：给它 10 条评论，让它分"好评/差评/中性"
   • 提取测试：给它一段新闻，让它提取"时间、地点、人物、事件"
   • 翻译测试：中译英一段 100 字的文字
   • 推理测试：一道需要两步计算的应用题
   • 长文测试：让它写一篇 500 字的短文
5. 每个测试打分（1-5 分），记录"能干什么、干不好什么"
6. 对比：同样任务，用云端大模型做一遍，看差距

验收标准：

• [ ] 本地模型跑起来了
• [ ] 五组测试都完成，有分数记录
• [ ] 能说出"我的机器 + 这个模型"的能力边界
• [ ] 有一份自己的评测表

卡住了怎么办：

• 下载太慢 → 换镜像源，或下载更小的模型先试
• 显存不足 → 换 Q4 或更低量化，减少 GPU 层数
• 速度太慢 → 检查是不是 CPU 在跑（GPU 层数设少了）

---

本章自检清单

• [ ] 显存和模型大小的换算公式是什么？
• [ ] Q4 量化的 7B 模型大约占多少显存？
• [ ] 量化档位怎么选？为什么说"大模型低量化 > 小模型高量化"？
• [ ] LM Studio 和 Ollama 各适合谁？
• [ ] 本地 7B 模型能干什么、干不好什么？
• [ ] 本地和云端怎么混合使用？
• [ ] CPU offload 是什么？代价是什么？

---

学习进度：0 / 13 章

📝 本章小测验（3 题）

1. 8G 显存稳妥能跑多大的模型？

2. 为什么「大模型低量化」常优于「小模型高量化」？

3. CPU offload 的主要代价是？

一句话记住

显存决定上限，量化决定取舍——别用 8G 的机器做 70B 的梦。

---

延伸阅读

• LM Studio / Ollama 官方文档——版本更新快，以官方为准
• 各模型的量化版本说明（GGUF 文件命名规则）——买模型前必看
• 社区模型评测（如各种 benchmark）——别只看参数量

---

最后更新：2026-10