我在 24GB 的 Mac mini 上折腾本地大模型，最后放弃了——一场关于「理想与内存」的和解

一句话总结：我想让本地大模型接进 Hermes 这个 AI agent，折腾了大半天，撞了三堵墙，最后没成。但这趟没白走——磁盘从 22GB 清到了 73GB，脑子里那团关于「大模型到底怎么跑」的浆糊，也终于清干净了。

起点：一个朴素的念头

我有一台 Mac mini（M4 芯片 / 24GB 统一内存），平时还算够用。某天冒出个念头：

能不能让本地大模型跑在自己电脑上，还接进我常用的 Hermes（一个 AI agent 客户端）？这样不用联网、数据不出门、还免费。

听起来很美好。于是我打开了 Claude Code，说：「帮我检查下这个大模型是否匹配我的电脑配置。」

故事就这么开始了。

第一站：清磁盘（意外的最大赢家）

准备装 Ollama 之前，先看了眼磁盘——只剩 22GB。这点空间连模型都塞不下几个。

于是顺手做了次大扫除，结果发现电脑里全是「僵尸缓存」：

清理项	释放
`~/.gemini/tmp` 暂存	14 GB
npm 缓存	~6 GB
VSCode 过期扩展（85 个残留版本！）	20 GB
Go module 缓存	3 GB
Cursor 对话历史 DB、剪映缓存等	~4 GB

磁盘从 22GB 一路清到 73GB。 好家伙，正事还没开始，先赚了 50 个 G。

💡 教训一：想跑本地模型，先看磁盘。开发机上的缓存垃圾比你想象的多得多。VSCode 那个 anthropic.claude-code 扩展，我一个人就囤了 36 个历史版本。

第二站：搞懂 Ollama 到底是啥

装好 Ollama、拉下第一个模型 qwen3:14b 后，我才真正搞明白一个一直没分清的概念：

Ollama 是「播放器」，大模型是「影片」。

Ollama = 一个软件工具，负责下载、加载、用 GPU 加速、提供对话接口。它自己不会思考。
Llama / Qwen = 真正会回答问题的「大脑」，是 Meta / 阿里开源的模型。

名字里都有 llama 纯属历史原因。现在 Ollama 什么模型都能跑。

第一次 ollama run qwen3:14b，中文流畅、100% GPU 加速、只吃 9.3GB 内存——丝滑。那一刻我信心爆棚：这不轻轻松松？

第三站：想接 Hermes，撞上第一堵墙——64K

兴奋没持续多久。我想让 Hermes 用这个本地模型，结果一跑就报错：

Model qwen3:14b has a context window of 40,960 tokens,
which is below the minimum 64,000 required by Hermes Agent.

Hermes 硬性要求模型上下文 ≥ 64K，而 qwen3:14b 只有 40K。 被当场拒绝。

我不信邪，翻了 Hermes 的源码，确认这是写死的常数：

MINIMUM_CONTEXT_LENGTH = 64_000

为什么这么高？源码注释说得很清楚：

"Tool schemas + system prompt use a large fixed prefix."

原来 Hermes 是个重型 agent，每次开场就往上下文里塞一大包「工具定义 + 系统提示词」。我用它自带的 prompt-size 一量：

固定开销	大小
系统提示词	62 KB
27 个工具的 schema	72 KB
合计	~134 KB ≈ 约 3 万 token

你还没打第一个字，3 万 token 就没了。 难怪它要 64K——扣掉 3 万的固定开销，才剩一半给你真正对话。

💡 教训二：上下文限制是「模型」的属性，不是 agent 的。但 agent 决定「吃掉多少 + 要不要设门槛」。Hermes 属于最奢侈的那一类。

第四站：换 llama3.1:8b，撞上第二堵墙——它是个「人工智障」

qwen3 上下文不够，那换个原生支持 128K 的呗。llama3.1:8b 上场——128K 上下文，轻松过门槛，内存 9.4GB，完美契合预算。

设成 Hermes 默认，一跑……先是报 does not support thinking（llama 不支持思考模式，关掉 reasoning_effort 解决）。然后，真正的灾难来了。

我让它「说中文」，它吐给我一坨原始 JSON：

{"type":"function","name":"say","parameters":{"text":"你想要我说什么","lang":"zh-Hans"}}

我让它「帮我写个 html」，它又吐：

{"parameters":{"path":"example.html","content":"<html>...Hello World...</html>"}}

它「知道」该调哪个工具、参数也对，但没能力把 JSON 变成真正的工具调用——直接漏成了聊天内容。 这是弱模型跑复杂 tool-calling 的典型翻车。

我盯着屏幕，心情复杂：连接是通的、内存是够的、就是这个 8B 的脑子……撑不起这么复杂的活。

💡 教训三：能跑 ≠ 能用。8B 小模型做多工具、多步骤的 agent，力不从心。

第五站：加码到 16GB，换 qwen2.5:14b——撞上第三堵墙，彻底死结

我不甘心。把内存预算从 14GB 放宽到 16GB，上 14B 的大脑——qwen2.5:14b，中文和工具调用都是开源第一梯队。这总行了吧？

结果一头撞死在墙上：

尝试	结果
qwen2.5 原生上下文	❌ 只有 32K，又不够
设 `num_ctx 65536` 强行拉大	❌ 被 ollama 夹回 32768
骗 Hermes `context_length=64000`	❌ Hermes 还会查 runtime 实际值，再次识破
用 rope 缩放强制拉伸	❌ 这个 ollama 版本不支持这参数

到这里我终于看清了那个死结：

Qwen 系列（qwen2.5=32K、qwen3=40K）架构原生就 <64K，而 ollama 无法把它们扩到 64K。Hermes 又严格要求 runtime 真的 ≥64K。
中文最强的 Qwen，技术上进不了 Hermes；能进的（llama3.1:8b），脑子又不够用。

这不是我不会配置，是硬件 + 工具 + 模型三方限制夹击的必然结果。

释然：和「理想」握手言和

折腾到这，我停下来问自己：我到底图什么？

答案其实很简单：我想要本地、隐私、免费地用 AI。而「本地模型 + 重型 agent」这个具体组合，在一台 24GB 的 Mac mini 上，性价比极差：

那 3 万 token 的固定开销，每轮都要用 GPU 重新算一遍 → 慢到以分钟计。
预算够得着的模型太弱，够强的模型内存放不下。

于是我做了个决定：放弃「本地模型塞进 Hermes」，让它们各司其职。

需求	最优解
Agent 干活（调工具、写文件、多步骤）	Hermes + 云端（快、对、200K 上下文、有缓存打折）
本地 / 隐私 / 中文聊天 / 写代码	`ollama run qwen2.5:14b`（不套 agent，32K 绰绰有余，又快又干净）

其实我早就同时拥有两者了，分开用就是最优解。 非要把重型 agent 硬塞进本地小模型，是我一开始就想拧了。

最后，我把所有本地模型和 Ollama 全部卸载，系统干干净净——但脑子里那团浆糊，清干净了。

复盘：这趟到底学到了什么

Ollama 是运行器，模型是大脑——别再搞混了。
上下文限制看模型，不看 agent；但 agent 决定吃掉多少、要不要设门槛。
重型 agent 的固定开销惊人（Hermes ~30K token/轮），云端靠 prompt caching 扛，本地只能硬算 → 慢。
Ollama 里的 Qwen 被锁在原生上下文（32K/40K），扩不到 64K；要 128K 请认准 llama / mistral 这些原生长上下文的家族。
能跑 ≠ 能用：8B 做 agent 会翻车；14B 内存又吃紧。24GB 的机器跑本地 agent，先天不足。
最大的赢家是磁盘清理：22GB → 73GB。有时候你出发去找宝藏，捡到的却是回家的路。

写在最后

失败吗？技术目标上，是。但我不觉得亏。

我搞懂了一整套原本一知半解的东西，顺手把电脑清干净了 50GB，还认清了一个道理——

工具是用来解决问题的，不是用来供着的。 与其为了「全都要本地」而忍受糟糕的体验，不如让云端和本地各干各擅长的事。

理想主义撞上 24GB 的内存墙，最体面的结局，是握手言和。

—— 记于一次「失败」但值得的折腾之后

Karp的技术站