本地部署 on Kalend's Blog

AI Agent的'遗忘症'怎么治？三层方案从金鱼脑到长期记忆

Fri, 24 Jul 2026 08:30:00 +0800

先说结论：三层方案能治，且完全免费本地运行。

你一定经历过这种崩溃——跟AI说了一百遍"代码用TypeScript不要JavaScript"，换个对话窗口它又问你用什么语言。你跟它讲过的项目背景、踩过的坑、你的审美偏好，下次全部归零。

这不是模型的问题，是架构的问题。LLM天生没有状态，context window有物理上限，窗口关了记忆就没了。之前分析过记忆架构的理论框架，今天直接上手搭——三层方案，从热记忆到语义搜索到知识图谱，照着做就能跑通。

为什么大多数AI助手是"金鱼脑"

先搞清楚病因。

LLM是无状态函数——输入token，输出token，没有内部记忆寄存器。你的"对话历史"就是每次请求时把前面的内容重新塞进context window发给模型。这就是为什么窗口越来越大（从4K到128K到1M），但问题没有根本解决：

限制	表现
物理上限	128K窗口大约装10万字中文，一个复杂项目的完整上下文轻松超限
成本线性增长	token越多越贵，1M窗口一次调用可能几块钱
信息衰减	“Lost in the Middle"效应——中间的信息被遗忘，首尾偏好
跨会话断连	关掉对话窗口，一切归零

那向量检索（RAG）呢？它解决了"找不到"的问题，但没解决"记不准"的问题。向量检索的本质是模糊联想——你问"上次那个数据库迁移方案”，它能找到语义相近的段落，但找不到你说的那一个精确段落。而且它没有结构化能力：“张三负责后端、李四负责前端"这种关系型信息，向量检索搞不定。

所以需要多层方案。每一层解决不同的问题。

第一层：热记忆——每轮都带上你的核心信息

热记忆是最简单也最有效的一层。原理很直白：把最重要的信息写进一个固定文本段，每次对话开始时自动注入到system prompt里。

载体和格式

热记忆通常存在一个markdown文件里，比如这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


## 用户偏好
- 代码语言：TypeScript，禁止JavaScript
- 回复风格：先结论后细节，不要铺垫
- 禁止行为：不要用emoji，不要加"首先"/"其次"连接词

## 环境信息
- 操作系统：Debian 13，内核6.12
- 部署方式：Docker Compose，compose文件在~/infra/
- 数据库：PostgreSQL 16，连接串在.env

## 高频踩坑
- Hugo日期必须RFC3339格式，否则日期变0001-01-01
- 又拍云API只支持HMAC-SHA1签名，不支持Basic Auth

工作原理

每轮对话开始时，系统把这段内容注入到system prompt中。模型看到的不是"你是一个通用助手”，而是"你是一个帮忞写代码的助手，用TypeScript，先给结论，不要emoji"。

这就是热记忆的核心——每轮都带上的上下文常量。

怎么写、怎么更新

写热记忆的原则：

只放高频信息。你的项目结构、技术栈、编码习惯——每次对话都需要的
控制在2000字符以内。热记忆占用context window，太长浪费token
用结构化格式。分块（用户偏好/环境/踩坑），用列表不用段落
定期清理。过时的信息及时删除，否则会"污染"新对话

更新方式：手动编辑文件，或者在对话中告诉AI"记住XXX"，它会自动更新热记忆段。

适用场景

场景	是否适合热记忆
用户编码偏好	✅ 高频、稳定、短文本
高频踩坑记录	✅ 避免重复犯错
项目架构概览	⚠️ 可以放摘要，细节放其他层
历史对话记录	❌ 太长，放不下
人物关系网络	❌ 结构化信息，需要图谱

热记忆是第一道防线，解决80%的"又忘了"问题。但它的容量有限，跨会话的深度信息需要更深的存储。

第二层：语义搜索——跨会话的"长期记忆"

当信息量超过热记忆的容量限制，或者你需要查找历史对话中的某个细节时，就需要语义搜索层。

这一层的核心是向量数据库——把文本切块、转成向量、存入数据库，查询时用语义相似度匹配。

为什么不用传统搜索

传统搜索（grep、全文检索）是精确匹配。你搜"数据库迁移"，它只找包含这几个字的段落。但用户可能说的是"把MySQL换成PostgreSQL那件事"——语义一样，措辞完全不同。

向量搜索解决的就是这个问题。它把文本编码成高维向量，语义相近的文本在向量空间中距离更近。

实际工具怎么用

以MemPalace为例（57.6k stars，本地免费，ChromaDB底层）：

存储信息：

1
2
3
4
5


mempalace_store(
 wing="devops", # 域/分类
 room="hugo-blog", # 主题/子分类
 content="Hugo日期必须用RFC3339格式(2026-05-14T10:00:00+08:00)，否则日期变0001-01-01"
)

语义搜索：

1
2
3
4
5


mempalace_recall(
 query="Hugo日期格式问题",
 wing="devops", # 可选，限定搜索范围
 top_k=5 # 返回最相关的5条
)

搜索结果包含文本内容、相似度分数、来源wing/room，可以按相关性排序后注入到当前对话中。

组织结构：Wing-Room-Drawer

MemPalace用三层结构组织信息：

1
2
3
4
5
6
7
8


Wing（域）→ Room（主题）→ Drawer（条目）
───────────────────────────────────────
devops/ hugo-blog/ Hugo日期格式踩坑
 又拍云API签名问题
 docker/ Compose网络配置
user/ preferences/ 编码风格偏好
 background/ 技术背景
conversation/ general/ 历史对话摘要

这种结构的好处是搜索时可以限定范围——搜Hugo相关的问题只在devops/hugo-blog里找，不会被无关信息干扰。

容量和性能

当前实际运行数据：

指标	数值
总Drawer数	21,986
Wing数	14
底层存储	ChromaDB（本地SQLite）
单次查询延迟	<100ms
存储成本	零（纯本地）

2万多个drawer，查询依然在100毫秒内完成。这就是向量数据库的优势——检索时间不随数据量线性增长。

适用场景

场景	是否适合语义搜索
查找历史对话	✅ 语义匹配，模糊查询
技术记录检索	✅ 按wing/room分类存储
项目详情	✅ 长文本切块后存储
精确关系查询	❌ “谁负责后端"这种结构化问题
时间序列分析	❌ 需要专门的时间窗口支持

语义搜索解决了"跨会话的深度记忆"问题，但它的底层还是文本匹配。当你需要查询结构化的关系信息——“项目A现在的状态是什么”、“张三和李四什么关系”——就需要知识图谱。

第三层：知识图谱——结构化的"关系网络”

向量搜索是模糊匹配，知识图谱是精确查询。

知识图谱的核心是三元组：Subject → Predicate → Object。比如：

1
2
3
4


忞 → 负责 → 博客系统
博客系统 → 使用 → Hugo + Stack主题
博客系统 → 部署到 → 又拍云CDN
忞 → 偏好 → TypeScript

这种结构让查询变得精确——“忞负责什么？“直接返回"博客系统”，不需要语义匹配。

时间窗口：自动废止旧事实

知识图谱最容易出的问题是信息过时。“张三负责后端”，三个月后张三离职了，旧事实还在图谱里，查出来就是错的。

解决方案是时间窗口——每条三元组都有valid_from和valid_to字段：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 添加事实
mempalace_kg_add(
 subject="张三",
 predicate="负责",
 object="后端服务",
 valid_from="2026-01"
)

# 后来张三离职了，废止旧事实
mempalace_kg_invalidate(
 subject="张三",
 predicate="负责",
 object="后端服务"
)
# valid_to 自动设为今天

查询时只返回当前有效的事实（valid_to为空或大于今天），过时的信息自动过滤。

实际使用场景

场景1：追踪人物关系

1
2
3
4
5
6
7
8


# 记录团队分工
mempalace_kg_add(subject="张三", predicate="负责", object="后端API")
mempalace_kg_add(subject="李四", predicate="负责", object="前端React")
mempalace_kg_add(subject="项目Alpha", predicate="后端负责人", object="张三")

# 查询：谁负责后端？
mempalace_knowledge(entity="后端API")
# → 张三 → 负责 → 后端API

场景2：追踪项目状态变化

1
2
3
4
5


# 项目状态随时间变化
mempalace_kg_add(subject="项目Alpha", predicate="状态", object="开发中", valid_from="2026-01")
mempalace_kg_invalidate(subject="项目Alpha", predicate="状态", object="开发中")

mempalace_kg_add(subject="项目Alpha", predicate="状态", object="测试中", valid_from="2026-04")

场景3：技术栈关系

1
2
3
4
5
6
7
8


mempalace_kg_add(subject="博客系统", predicate="使用框架", object="Hugo")
mempalace_kg_add(subject="博客系统", predicate="使用主题", object="Stack")
mempalace_kg_add(subject="博客系统", predicate="托管平台", object="又拍云")
mempalace_kg_add(subject="Stack主题", predicate="依赖", object="Hugo 0.144+")

# 查询：博客系统的依赖链是什么？
mempalace_knowledge(entity="博客系统")
# → 返回所有相关三元组

何时该用知识图谱，何时不该

场景	用知识图谱	用语义搜索
“谁负责后端”	✅ 精确关系	❌ 模糊匹配不准
“上次聊了什么”	❌ 不适合文本	✅ 语义匹配
“项目状态历史”	✅ 时间窗口	❌ 无时间概念
“技术文档查询”	❌ 结构化太重	✅ 文本匹配
“依赖关系链”	✅ 图遍历	❌ 无法表达关系

简单判断：如果查询里有"谁/什么/关系/状态/版本"这种结构化关键词，用知识图谱。如果是"上次/记得/聊过/说过"这种模糊回忆，用语义搜索。

四级回忆链：怎么把三层串起来

三层不是独立工作的，它们形成一个级联回忆链：

1
2
3
4
5
6
7


热记忆（每轮自动注入）
 ↓ 没找到？
MemPalace语义搜索（按需查询）
 ↓ 还没找到？
session_search（跨会话精确搜索）
 ↓ 最后手段
结构化文件搜索（grep/全文检索）

决策逻辑很简单：

热记忆：高频、稳定、短文本——每次自动带上，不需要主动查询
语义搜索：中频、长文本、需要模糊匹配——用户提到某个话题时触发
session_search：低频、需要精确匹配某个历史对话——明确要求时触发
文件搜索：兜底——其他方式都找不到时，直接grep源文件

这个级联的效率在于：热记忆零成本（已经注入了），语义搜索100ms内返回，session_search秒级，文件搜索最慢但最全。90%的需求在前两层就解决了。

遗忘机制

记忆系统不仅要能记，还要能忘。过时的信息如果不清理，会造成"记忆污染”——AI带着过期信息做决策，比没有记忆更糟糕。

三种遗忘机制：

机制	触发方式	作用
kg_invalidate	手动标记	知识图谱中的事实失效，设valid_to=今天
热记忆清理	定期审计	删除过时的高频信息，释放context空间
sync清理	文件删除后同步	删除源文件时自动清理对应的存储条目

避坑指南

坑1：过早上知识图谱

最常见的错误。需求还没验证就建复杂系统——三元组设计了一百个关系类型，实际只用到三个。

正确做法：先用热记忆+语义搜索跑一个月，确认确实有结构化查询需求，再加知识图谱。三层方案是渐进式的，不是一步到位的。

坑2：记忆污染

跨会话的过时信息混入当前对话。比如三个月前记录的"项目状态：开发中"，现在已经是"已上线"了，但没有及时更新。

正确做法：给信息打时间戳，定期审计，用kg_invalidate废止过时事实。热记忆更要频繁清理——它每轮都注入，过时信息的伤害最大。

坑3：热记忆膨胀

什么都往热记忆里塞，2000字符变成5000字符，再变成10000字符。结果context window被记忆占了大半，留给实际对话的空间不够了。

正确做法：热记忆只放"每轮都需要"的信息。“偶尔用到的"放语义搜索，“结构性的"放知识图谱。一个判断标准：如果这条信息连续5轮对话都没被用到，就不该在热记忆里。

坑4：向量检索的"记忆泡沫”

向量搜索返回的结果看着相关，但实际上是噪声。比如你问"数据库性能优化”，它返回了"数据库备份方案"——语义相近但不是你要的。

正确做法：用wing/room限定搜索范围，设置相似度阈值过滤低质量结果。语义搜索是召回，不是精确匹配，返回结果需要二次筛选。

落地建议：最小可用方案

不需要三层一步到位。推荐的渐进路线：

第一周：只用热记忆

把用户偏好、技术栈、高频踩坑写进热记忆段，2000字符以内。这一层零成本，立即见效。

第二周：加入语义搜索

安装MemPalace（本地ChromaDB，不需要API Key），开始把重要对话、技术记录存进去。配置wing/room分类结构。

第三周：按需加知识图谱

如果发现经常需要查询"谁负责什么"、“项目状态”、“依赖关系"这种结构化信息，再加知识图谱层。不需要就不加。

整个方案完全本地运行，不需要任何云服务、API Key或月费。MemPalace底层是ChromaDB（SQLite），数据存在本地磁盘，隐私完全可控。

记忆系统的终点不是"记住”，而是"学会"。

三层方案解决的是信息的存储和检索，但真正有价值的是从记忆中提取规律、变成行为。热记忆让你不用重复解释偏好，语义搜索让你不用重复查找历史，知识图谱让你不用重复梳理关系。

把这些省下来的时间和精力，用在真正需要创造力的地方。

— varkm

一张4090能跑GLM-5.2还是Qwen3-32B？国产大模型本地部署2026版

Thu, 23 Jul 2026 08:30:00 +0800

先说结论：4090 跑不了 GLM-5.2，Qwen3-30B-A3B 才是你的甜区。

GLM-5.2 是 744B 参数的 MoE 模型，哪怕 2-bit 量化也要 238GB 显存，4090 的 24GB 连零头都不够。别折腾了，老老实实调 API。

但 4090 并不是废物。2026 年国产大模型格局变了，MoE 架构让小显存也能跑大模型。一张 4090，能跑的东西比你想的多。

4090 的 24GB 显存，2026 年能跑什么？

2026 年国产大模型三足鼎立：DeepSeek V4、GLM-5.2、Qwen3。

但「能发布」和「能本地跑」是两回事。4090 的 24GB 显存有硬天花板：

量化方案	显存需求上限	能跑的最大模型
FP16	24GB	~12B
INT8	24GB	~24B
INT4/Q4_K_M	24GB	~32B
2-bit	24GB	~48B（质量严重下降）

关键点：MoE 模型虽然只激活部分参数，但推理时需要加载全部权重到显存。30B 总参 / 3B 激活的 MoE，显存需求按 30B 算，不是 3B。

所以 4090 的实际天花板是：32B INT4 或 30B MoE Q4_K_M。

GLM-5.2 — 744B 的"看得到吃不到"

GLM-5.2 是智谱 2026 年的旗舰模型：

参数	值
总参数	744B
激活参数	~40B（MoE）
架构	MoE，256 个专家（每个 token 激活 8+1 个）
2-bit 量化显存	238GB
4-bit 量化显存	~372GB

即使是最激进的 2-bit 量化（质量已经很差），也需要 238GB 显存。4090 的 24GB 只有它的十分之一。

这个模型适合什么硬件？

Mac Studio 256GB 统一内存：勉强能跑 2-bit，速度慢但可用
多卡服务器：4×A100 80GB 或 8×4090，用张量并行
云 GPU：按小时租 A100/H100，适合偶尔用

4090 用户想用 GLM 系列，替代方案是：

模型	参数	显存（FP16）	可用性
GLM-4-9B	9B	~18GB	✅ 4090 轻松跑
GLM-Z1-9B	9B（推理增强）	~18GB	✅ 4090 轻松跑
GLM-5.2 API	744B	无	✅ 按 token 付费

说实话，GLM-4-9B 和 GLM-Z1-9B 的能力跟 GLM-5.2 差了一个量级。如果你需要 GLM-5.2 级别的能力，调 API 是唯一现实选择。

Qwen3-30B-A3B — 4090 的真正甜区

Qwen3 系列里，最适合 4090 的不是 Qwen3-32B，而是 Qwen3-30B-A3B。

为什么？MoE 架构。

对比项	Qwen3-30B-A3B	Qwen3-32B
总参数	30B	32B
激活参数	3B	32B（全量）
架构	MoE	Dense
Q4_K_M 显存	~18GB	~20GB
推理速度（4090）	~45 tok/s	~18 tok/s
综合能力	接近	略强

Qwen3-30B-A3B 的核心优势：

显存友好：Q4_K_M 量化后只需 ~18GB，4090 还剩 6GB 给 KV Cache
速度快：只激活 3B 参数做推理，速度是 Dense 32B 的 2-3 倍
能力不差：MoE 的 30B 总参保证了知识容量，3B 激活保证了速度

实际推理速度（4090 + Ollama Q4_K_M）：

模型	输出速度	首 token 延迟
Qwen3-30B-A3B	~45 tok/s	~0.3s
Qwen3-32B	~18 tok/s	~0.8s
Qwen3-14B	~35 tok/s	~0.4s
Qwen3-8B	~65 tok/s	~0.2s

30B-A3B 的速度接近 14B，但能力接近 32B。这就是 MoE 的魔力。

4090 能跑的国产模型清单

以下是 2026 年 4090（24GB）实测可用的国产大模型：

模型	参数	量化方案	显存需求	推荐场景
Qwen3-30B-A3B	30B/3B激活	Q4_K_M	~18GB	⭐ 日常对话+编程
Qwen3-32B	32B	Q4_K_M	~20GB	需要最高质量
Qwen3-14B	14B	INT8	~15GB	需INT8，平衡之选
Qwen3-8B	8B	FP16	~16GB	轻量级，速度最快
DeepSeek-R1-32B（蒸馏）	32B	INT4	~20GB	推理/数学任务
GLM-4-9B	9B	FP16	~18GB	GLM 生态兼容
GLM-Z1-9B	9B	FP16	~18GB	推理增强

场景推荐：

日常对话：Qwen3-30B-A3B（速度快、质量好）
编程辅助：Qwen3-30B-A3B 或 Qwen3-32B（代码能力 32B 更强）
数学/推理：DeepSeek-R1-32B 蒸馏版（推理任务专项优化）
Agent/工具调用：Qwen3-30B-A3B（速度快，适合多轮工具调用）
GLM 生态：GLM-Z1-9B（但能力有限，复杂任务建议 API）

框架选择 — Ollama vs vLLM vs SGLang

选完模型，还要选推理框架。三个主流选择：

框架	优势	劣势	适用场景
Ollama	5分钟上手，一键安装	并发性能一般	个人使用、开发调试
vLLM	高并发吞吐	配置复杂	服务化部署、多人共用
SGLang	Agent/工具调用优化	生态较小	AI Agent 开发

Ollama（推荐大多数人）：

1
2
3
4
5
6
7
8


# 安装
curl -fsSL https://ollama.com/install.sh | sh

# 拉取模型（自动选 Q4_K_M）
ollama pull qwen3:30b

# 运行
ollama run qwen3:30b

5 分钟搞定，适合个人开发者。Ollama 会自动根据你的显存选择量化方案，不需要手动配置。

vLLM（需要高并发时）：

1
2
3
4
5
6
7
8


# 安装
pip install vllm

# 启动服务
python -m vllm.entrypoints.openai.api_server \
 --model Qwen/Qwen3-30B-A3B \
 --quantization awq \
 --max-model-len 8192

如果你要给团队用，或者需要同时处理多个请求，vLLM 的 PagedAttention 能把吞吐量提升 3-5 倍。

SGLang（Agent 开发专用）：

1
2
3
4
5
6
7


# 安装
pip install sglang

# 启动
python -m sglang.launch_server \
 --model-path Qwen/Qwen3-30B-A3B \
 --quantization awq

SGLang 对工具调用和结构化输出有专门优化，如果你在做 AI Agent 开发，值得试试。

结论：消费级显卡本地部署的理性预期

一张 4090 能跑的国产大模型，比 2025 年多了不少，但别指望能跑旗舰。

值得本地跑的场景：

日常对话、写作辅助（Qwen3-30B-A3B 足够）
编程辅助（30B-A3B 或 32B，取决于代码复杂度）
隐私敏感任务（不能把数据发到云端）
高频调用（API 按 token 计费，高频场景本地更划算）
学习和实验（理解模型推理过程）

用 API 更划算的场景：

需要最强模型能力（GLM-5.2、DeepSeek V4 旗舰版）
低频使用（偶尔用一次，不值得买显卡）
多模态任务（图像、语音理解，本地模型支持有限）
长上下文（本地模型上下文窗口通常 8K-32K，API 可以 128K+）

2026 年的现实是：MoE 架构让消费级显卡也能跑「够用」的大模型，但「最强」的大模型仍然需要专业硬件或 API。4090 + Qwen3-30B-A3B 是目前性价比最高的组合，别被 GLM-5.2 的参数量迷了眼。

作者：varkm

Qwen 全家桶本地部署指南：从 0.6B 到 480B，你的显卡该跑哪个？

Mon, 22 Jun 2026 10:00:00 +0800

Qwen 是目前本地部署生态最完善的国产大模型。不管是 8GB 内存核显笔记本、4090 工作站，还是无显卡老机器，都有对应型号和量化方案。本文不说空话，直接按显卡预算给推荐。

我测试了 Qwen3.5 全系列 + Ollama/vLLM 三种部署方式，对比了内存占用、首 token 延迟、生成速度，帮你找到最值的那款。

Qwen 模型家族全图景

Qwen 在 2026 年形成完整矩阵：

模型	参数量	激活参数	显存需求（Q4）	适用场景
Qwen3.5	397B MoE (A17B)	17B	~200GB+	企业级、对标 GPT-4o
Qwen3-Coder	480B-A35B	35B	~240GB+	编程专用、多卡服务器部署
Qwen3.6-35B-A3B	35B-A3B MoE	3B	~18GB	性价比甜点、推理快
Qwen3.5-9B	9B Dense	9B	5.5GB	消费级显卡推荐起点
Qwen3.5-4B	4B Dense	4B	~2.5GB	核显笔记本可跑
Qwen3.5-2B	2B Dense	2B	~1.2GB	老旧机器过渡
Qwen3.5-0.8B	0.8B Dense	0.8B	~0.5GB	无显卡纯 CPU

核心差异：MoE（专家混合）vs Dense。MoE 模型（Qwen3.5、Qwen3-Coder）只激活部分参数，推理时等效于小模型，但需要更大的总显存来加载完整权重。Dense 模型（Qwen3.5-9B）所有参数都参与计算，显存占用低但推理慢。

三种部署方式对比

工具	安装难度	性能	适用平台	适合人群
Ollama	一行命令	中等	Linux/Mac/Windows	入门用户、日常使用
vLLM	pip 安装	高（多卡并行）	Linux + GPU	API 服务、生产环境
LM Studio/MLX	GUI	中等	macOS	Mac 用户首选

结论：入门用 Ollama，生产用 vLLM。下文覆盖两者完整实战。

实战一：Ollama 一键部署 Qwen3.5-9B

Ollama 是最简单的本地部署方式。以 Qwen3.5-9B 为例：

1
2
3
4
5


# 1. 安装 Ollama（Linux/macOS 一行搞定）
curl -fsSL https://ollama.com/install.sh | sh

# 2. 拉取并运行 Qwen3.5-9B（首次自动下载 5.5GB 模型）
ollama run qwen3.5:9b

默认 Q4_K_M 量化，8GB RAM 可流畅运行。实测在 16GB RAM + RTX 3060（12GB）上：首 token 延迟约 0.8s，生成速度约 28 tok/s。

Modelfile 自定义：调整上下文长度、温度：

1
2
3
4


FROM qwen3.5:9b
PARAMETER num_ctx 32768
PARAMETER temperature 0.7
PARAMETER top_p 0.9

保存为 Modelfile，运行 ollama create custom-qwen -f Modelfile && ollama run custom-qwen。

实战二：vLLM 部署 Qwen3.6-35B-A3B

Qwen3.6-35B-A3B 是性价比甜点：MoE 架构只激活 3B 参数，推理速度堪比 7B 模型，但需要约 18GB 显存加载完整权重。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 1. 安装 vLLM（支持 CUDA）
pip install vllm

# 2. 启动 vLLM 服务器（OpenAI 兼容 API）
python -m vllm.entrypoints.openai.api_server \
 --model Qwen/Qwen3.6-35B-A3B-Instruct \
 --quantization awq \
 --tensor-parallel-size 1 \
 --dtype auto \
 --max-model-len 32768 \
 --port 8000

为什么用 AWQ 量化：相比 GPTQ，AWQ 在 MoE 模型上的精度损失更小，且推理速度更快。

实测在 RTX 4090（24GB）上：首 token 延迟约 0.4s，生成速度约 45 tok/s，相比 Ollama 有明显提升。

OpenAI 兼容调用：

1
2
3
4
5
6
7


curl http://localhost:8000/v1/chat/completions \
 -H "Content-Type: application/json" \
 -d '{
 "model": "Qwen/Qwen3.6-35B-A3B-Instruct",
 "messages": [{"role": "user", "content": "写一个快速排序"}],
 "temperature": 0.7
 }'

按显卡预算推荐配置

显卡	推荐模型	量化级别	预期性能
无显卡（8GB RAM）	Qwen3.5-2B	Q4	首 token 约 2s，约 15 tok/s
核显（16GB RAM）	Qwen3.5-4B	Q4	首 token 约 1.5s，约 20 tok/s
RTX 3060 12GB	Qwen3.5-9B	Q4_K_M	首 token 约 0.8s，约 28 tok/s
RTX 4070 Ti 16GB	Qwen3.5-9B	Q8_0	首 token 约 0.6s，约 35 tok/s
RTX 4090 24GB	Qwen3.6-35B-A3B	AWQ	首 token 约 0.4s，约 45 tok/s
多卡服务器（240GB+）	Qwen3-Coder 480B	AWQ	首 token 约 0.3s，约 60 tok/s

无显卡方案：Ollama 会自动降级到 CPU 推理，速度慢但可用。临时测试跑大模型可上云 GPU（RunPod/Lambda Labs），按小时计费约 $0.5-1/h。

进阶：用 Qwen3-Coder 做 Vibe Coding

本地 Qwen3-Coder + Claude Code CLI 或 OpenCode，可实现完整的 Vibe Coding 工作流：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 1. 安装 Qwen3-Coder（需要多卡或云 GPU）
ollama pull qwen3-coder:480b

# 2. 配置 Claude Code 使用本地模型（需修改 Claude Code 配置指向 Ollama API）
# 参考：https://claude.ai/code/docs

# 3. 实战体验
# - 代码重构、测试生成：本地跑更划算
# - 大规模代码库分析：云 GPU 快速完成
# - 迭代调试：本地 9B 足够，频繁调用

对比 DeepSeek：Qwen3-Coder 在编程任务上表现强劲，本地部署生态更完善。DeepSeek 最新开源 V3/R1 系列，在标准 NVIDIA GPU 上即可运行，但模型体积较大，本地部署门槛较高。

踩坑指南：常见问题和解决方案

问题 1：显存不足 OOM

vLLM 启动时如果报 CUDA out of memory，尝试：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 方案一：增加 tensor-parallel-size 分摊到多卡
python -m vllm.entrypoints.openai.api_server \
 --model Qwen/Qwen3.6-35B-A3B-Instruct \
 --tensor-parallel-size 2 \
 --quantization awq

# 方案二：换更激进的量化级别（awq → gptq，显存省约 10%）
python -m vllm.entrypoints.openai.api_server \
 --model Qwen/Qwen3.6-35B-A3B-Instruct \
 --quantization gptq

问题 2：中文输出质量差

Ollama 默认英文 prompt 优先，在 Modelfile 中强制中文：

1

SYSTEM 你是一个中文助手，请用中文回答所有问题。

问题 3：量化精度损失

Qwen3.5-9B Q4_K_M 在中文理解上基本无损，但复杂逻辑推理可能出错。对精度要求高的任务（数学证明、代码审查），推荐 Q8_0 或 FP16。

结论：一张决策表搞定

1
2
3
4
5


预算充足（240GB+） → Qwen3-Coder 480B → vLLM + 多卡并行
单卡旗舰（24GB） → Qwen3.6-35B-A3B → vLLM + AWQ 量化
消费级推荐（12GB） → Qwen3.5-9B → Ollama Q4_K_M
预算紧张（核显） → Qwen3.5-4B → Ollama CPU 推理
临时测试 → 云 GPU → 按小时计费

核心原则：先确定显卡预算，再选对应模型和量化级别。MoE 模型适合显卡充足的用户（推理快），Dense 模型适合预算有限的用户（显存占用低）。

你的显卡到底该跑哪个：国产大模型本地部署横向实测

Mon, 15 Jun 2026 08:00:00 +0800

先给结论：没有"最强"，只有"最合适"。

你的显存	推荐模型	预期速度
8GB	Qwen3:4b（中文万金油）	100+ tokens/s
12GB	DeepSeek-R1:7b（推理强）	40-70 tokens/s
16GB	Qwen3:14b 或 DeepSeek-R1:14b	70-120 tokens/s
24GB	DeepSeek-R1:32b 蒸馏版	30-60 tokens/s

这是我在 RTX 3060 12GB 和 RTX 4090 24GB 上跑了两个星期、测试了十几个模型后得出的真实结论。下面展开说。

一、为什么是 DeepSeek、Qwen、GLM 这三家

国产开源大模型不少，但真正在 Ollama 上能跑、社区支持成熟、中文效果好的，就这三家：

DeepSeek（深度求索）：推理、数学、代码领域的王者。采用 MoE（混合专家）架构，满血版 DeepSeek V4 Pro 有 861B 参数——但那是云端模型，本地根本跑不了。我们本地能用的是 R1 蒸馏系列：把满血模型的推理能力"蒸馏"进 1.5B 到 32B 的小模型里，性能远超同参数量的普通模型。DeepSeek V4 Flash 版 158B 参数的 API 调用价格仅 0.28 美元/百万 token，是目前性价比最高的云端模型之一。但本地部署用 R1 蒸馏版，7B 仅需 4.7GB 显存，效果已经非常能打。

Qwen（通义千问）：多语言能力最强，支持 119 种语言，中文效果极佳。最大优势是覆盖全：从 0.6B 到 235B 全系覆盖，树莓派上都能跑 4B 版本。生态最完善，量化版本最丰富。在 RTX 4090 上实测，Qwen3:0.6b 推理速度达 280 tokens/s，4b 也有 107 tokens/s，8b 为 69 tokens/s——速度表现是三家里最快的。

GLM（智谱）：中英双语专精，长文本（32K 上下文）处理能力强，GLM-5.1 满血版 753B 参数也是云端模型。本地能跑的是 GLM-4:9b，5.5GB Q4 量化即可运行。在长文本摘要、中英翻译、专业文档分析场景下，GLM-4 的表现超出其参数量预期。

为什么不用 Llama 或 Mistral？两个原因：中文支持弱，而且它们不是国产。这篇文章就是写给想用国产模型的人。

二、5 分钟装好 Ollama

Ollama 是目前最简单的本地大模型运行工具。三平台一行命令：

1
2
3
4
5


# macOS / Linux
curl -fsSL https://ollama.com/install.sh | sh

# Windows
# 官网下载 OllamaSetup.exe，双击安装

装完验证：

1
2


ollama --version
# 应显示版本号，无 Warning

第一个坑：默认装在 C 盘。 Windows 用户装完会发现模型默认存在 C:\Users\你的用户名\.ollama\models，几十 GB 很快吃满系统盘。解决方法：

1
2
3


# 设置环境变量后重启 Ollama 服务
# Windows: 系统环境变量添加 OLLAMA_MODELS=D:\ollama-models
# Linux: export OLLAMA_MODELS=/data/ollama-models

ollama pull 和 ollama run 的区别：pull 只下载不启动，run 下载后直接进入对话。第一次用建议先 pull，确认下载完成再 run，避免网络中断导致模型损坏。下载支持断点续传——如果中途断了，重新执行 ollama pull 会从断点继续，不需要从头来。

下载速度提示：Ollama 的模型仓库（registry）在国内网络环境下直连速度约 4-5MB/s，第一次下载大模型需要耐心。不要中途 Ctrl+C，让它跑完。

三、显存分级选型指南（核心章节）

本地部署最重要的决策：你的显存能跑什么？这里有一个公式：

显存需求 ≈ 参数量(B) × 量化系数 + KV缓存开销

Q4_K_M（4-bit 量化）的系数约为 0.7。以 7B 模型为例：7 × 0.7 ≈ 4.9GB 模型本体，加上上下文缓存，实际需要 6-7GB 显存。

必须知道的事实：Ollama 的显存占用比 vLLM 多约 30-40%，因为 Ollama 底层封装了 llama.cpp，有额外的运行时开销。同样的模型，vLLM 可能用 5GB，Ollama 要 7GB。这是易用性的代价。

第一档：集成显卡 / 8GB 内存（贫民窟）

项目	数据
推荐模型	Qwen3:1.7b 或 Qwen3:0.6b
模型大小	1.4GB（0.6b）/ 2.5GB（1.7b Q4）
预期速度	20-40 tokens/s
能干什么	简单问答、文本摘要、翻译
不能干什么	代码生成、复杂推理、长文本分析

这个档位别指望太多，能跑起来就是胜利。

第二档：6-8GB 独立显卡

项目	数据
推荐模型	Qwen3:4b（中文首选）、DeepSeek-R1:1.5b（推理入门）
模型大小	2.5GB（Qwen3:4b Q4）/ 1.1GB（R1:1.5b）
预期速度	40-107 tokens/s
能干什么	日常对话、文案写作、简单代码、翻译
不能干什么	复杂算法题、大型代码重构

Qwen3:4b 实测可以跑到 107 tokens/s，日常使用完全够用。这是我推荐的"万金油"选择。

第三档：12-16GB 显存（甜点区）

项目	数据
推荐模型	DeepSeek-R1:7b、Qwen3:8b、GLM-4:9b
模型大小	4.7GB / 5.2GB / 5.5GB（均为 Q4_K_M）
预期速度	40-70 tokens/s
能干什么	中等难度代码、数学推理、长文写作、多轮对话
不能干什么	70B 级别的复杂推理

这是性价比最高的档位。DeepSeek-R1:7b 在 RTX 3060 12GB 上流畅推理，4.7GB 模型占用加 2GB 上下文缓存，总共不到 7GB，还有余量。

第四档：24GB 显存

项目	数据
推荐模型	DeepSeek-R1:32b、Qwen3:14b
模型大小	20GB（R1:32b）/ 9.3GB（Qwen3:14b）
预期速度	30-60 tokens/s（32b）/ 70-120 tokens/s（14b）
能干什么	高质量代码生成、复杂推理、专业领域分析
不能干什么	满血 671B 模型（需要 400GB+ 显存）

到了这个档位，R1:32b 的推理能力已经接近 GPT-4 水平，32B 蒸馏版是本地能跑的最大 R1 模型。

四、三模型实测对比

以下数据基于 RTX 4090 24GB，同一硬件、同一 prompt 的横向对比：

推理速度（token/s，Q4_K_M 量化）

模型	参数量	模型大小	推理速度
Qwen3:4b	4B	2.5GB	107 t/s
Qwen3:8b	8B	5.2GB	69 t/s
DeepSeek-R1:7b	7B	4.7GB	55 t/s
GLM-4:9b	9B	5.5GB	48 t/s
DeepSeek-R1:14b	14B	9.0GB	35 t/s
Qwen3:32b	32B	20GB	22 t/s

速度跟参数量基本呈反比。但 DeepSeek-R1 系列因为推理时会输出思考过程，实际等待时间比纯速度数字更长。

中文理解质量

同一道题：“请解释量子纠缠，用小学生能听懂的话。”

Qwen3：比喻贴切，用词自然，最像真人说话。中文确实是强项。
GLM-4：准确但偏书面，有点像教科书。
DeepSeek-R1：先在思考链里推理了 200 多个 token，然后给出答案。答案质量最高，但等待时间长。

代码生成

同一题：“用 Python 写一个快速排序，加注释。”

DeepSeek-R1:7b：代码正确，注释详细，还主动给出了测试用例。推理过程耗时约 8 秒（包含思考链），但最终输出质量最高。这正是 R1 蒸馏的优势——推理能力被完整保留。
Qwen3:8b：代码正确，注释简洁，3 秒出结果。日常使用完全够用。
GLM-4:9b：代码正确，但格式略乱，缩进有不一致的地方。

长文本处理

输入一篇 3000 字的技术文章，要求总结要点：

GLM-4:9b：32K 上下文窗口的优势在这里体现，要点提取最完整，逻辑清晰。
Qwen3:8b：摘要质量不错，但遗漏了一些次要要点。
DeepSeek-R1:7b：会先在思考链里梳理全文结构再输出，总结最深入，但耗时最长。

如果只能装一个，选谁？

日常对话 + 中文场景 → Qwen3:8b（速度和质量的最佳平衡）
写代码 + 数学推理 → DeepSeek-R1:7b（推理质量碾压同级别）
长文档分析 → GLM-4:9b（32K 上下文窗口最大）

我的建议：先装 Qwen3:8b，用顺了再根据需求加装其他模型。Ollama 切换模型只需 ollama run 模型名。

五、量化怎么选不踩坑

Ollama 默认下载的就是 Q4_K_M（4-bit）量化版本。但 Ollama 也支持其他量化级别：

量化级别	每参数比特	7B 模型大小	质量损失	适用场景
Q4_K_M	~4.5 bit	4.7GB	约 5%	性价比之王，默认选择
Q5_K_M	~5.5 bit	5.7GB	约 2%	显存够就升级
Q8_0	8 bit	7.0GB	几乎无	追求极致质量
F16	16 bit	14GB	无损	调试/对比基准

Q4_K_M 为什么是性价王？ 因为它把模型压缩到原来的 30%，但质量只损失 5%。对绝大多数日常使用场景，你根本感受不到差别。

量化的"看不见的代价"：在简单任务上（翻译、摘要）几乎无感，但在复杂推理任务上（多步数学推导、长链代码逻辑），Q4 相比 F16 的差距会被放大。如果你用模型做复杂推理，建议上 Q5_K_M 或 Q8_0。

手动指定量化版本：

1
2
3
4
5


# 下载 Q5_K_M 版本
ollama pull qwen3:8b-q5_K_M

# 下载 Q8 版本
ollama pull deepseek-r1:7b-q8_0

六、常见踩坑与排障

坑 1：OOM 崩溃

报错 CUDA out of memory 或程序直接闪退。先判断是显存不够还是内存不够：

1
2
3
4
5
6


# 查看显存使用（NVIDIA）
nvidia-smi

# 查看内存使用
free -h # Linux
# Windows: 任务管理器 → 性能 → 内存

如果 nvidia-smi 显示显存占用 95%+，说明模型太大，换小一号。如果内存也快满了，说明上下文太长，减小 num_ctx 参数。

坑 2：选了 70B 发现 16GB 根本跑不起来

这是一个常见误区：参数越大越好。70B 模型 Q4 量化后需要 43GB 显存，RTX 4090 24GB 都扛不住。它会自动降速到 CPU 推理，速度从 50 tokens/s 暴跌到 2 tokens/s，基本不可用。

我见过太多人下载了 deepseek-r1:671b（404GB），等了半天下载完，跑起来一个字要等 10 秒。

记住：选模型的第一标准是你的显存，不是"越大越好"。 参数量翻倍，推理能力提升可能只有 10-15%，但显存需求翻倍，速度腰斩。32B 蒸馏版已经能覆盖绝大多数使用场景。

坑 3：中文输出乱码或英文 fallback

部分模型在上下文较短时会混入英文回答。解决方法：

1
2
3
4
5


# 在 Modelfile 里设置系统提示
ollama create my-qwen -f - << 'EOF'
FROM qwen3:8b
SYSTEM "你是一个中文助手，请始终用中文回答。"
EOF

坑 4：速度优化

三个有效的优化手段：

确保 GPU offload 开启：Ollama 默认自动 offload，但如果你的 CUDA 驱动版本不对，会静默回退到 CPU。检查 nvidia-smi 在推理时是否有显存占用。
控制上下文长度：默认 2048 token，长对话会吃掉大量 KV 缓存显存。如果不需要长上下文，别开太大。
别同时加载多个模型：Ollama 默认 5 分钟后卸载空闲模型，但如果频繁切换，多个模型同时驻留显存会导致 OOM。

关于 Ollama 的安全通报

2025 年 Ollama 曾出现在国家网络漏洞通报中（CVE 评估），主要涉及本地 API 端口暴露问题。Ollama 默认监听 127.0.0.1:11434，只要不手动改成 0.0.0.0 暴露到公网，风险可控。如果你需要远程访问，建议用 SSH 隧道而非直接暴露端口。

七、进阶——接进你的代码

本地部署的模型如果只是命令行聊天，那就是个高级玩具。真正有用的是接进你的工作流。

Ollama 提供 OpenAI 兼容 API，一行代码就能调用：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


from openai import OpenAI

client = OpenAI(
 base_url="http://localhost:11434/v1",
 api_key="ollama" # 随便填，本地不需要认证
)

response = client.chat.completions.create(
 model="qwen3:8b",
 messages=[{"role": "user", "content": "用一句话解释什么是递归"}]
)
print(response.choices[0].message.content)

这意味着什么？所有支持 OpenAI API 的工具——代码编辑器插件、知识库系统、自动化脚本——只要把 API 地址从 api.openai.com 改成 localhost:11434，就能用本地模型替代付费 API。

比如在 VS Code 的 Continue 插件里配置本地模型：

1
2
3
4
5
6
7
8


{
 "models": [{
 "title": "Local Qwen3",
 "provider": "openai",
 "model": "qwen3:8b",
 "apiBase": "http://localhost:11434/v1"
 }]
}

零成本、零延迟、数据不出本机。这才是本地部署的意义——不是把模型装上就完事，而是把它变成你日常工具链的一部分。

以上就是全部内容。总结一下：8GB 装 Qwen3:4b，12GB 装 DeepSeek-R1:7b，16GB 以上看需求选 14b 级别。量化用默认 Q4_K_M 就行。装完记得接进代码里用起来，别让它吃灰。