Claude Code 最近被曝出 BUG 导致 token 消耗膨胀 10-20 倍，正好 3 月 31 日 Google 新发布了 Gemma 4，赶紧本地部署试试能不能替代 —— 结果踩了一路的坑。
![]()
测试环境
- 硬件：Mac Studio M4 Max / 128GB 统一内存 / 16 核 CPU / 40 核 GPU
- 模型：google/gemma-4-26b-a4b（Q4_K_M 量化，17.99 GB）
- 推理框架：LM Studio 0.4.9（Metal 加速，GPU 卸载 30/30 层满载）
2026 年 3 月 31 日，Google 发布了 Gemma 4 系列，包含 E2B、E4B、31B 和 26B A4B 四个版本。其中 26B A4B 采用 MoE（混合专家）架构，26B 总参数中每次推理只激活约 4B，理论上兼顾了性能和速度，是本地部署的热门选择。
速度实测：令人失望
| 场景 |
生成速度 |
Prompt 处理 |
体验 |
| 短对话（< 2K token） |
~30-40 tok/s |
1-2 秒 |
✅ 流畅 |
| 中等对话（~8K token） |
~20-30 tok/s |
5-10 秒 |
⚠️ 可接受 |
| Claude Code（29K+ token） |
~14 tok/s |
30-60 秒 |
❌ 无法正常使用 |
对比 Anthropic API：
| 对比项 |
本地 Gemma 26B |
Claude Sonnet（API） |
| 生成速度 |
14 tok/s |
80-120 tok/s |
| 上下文窗口 |
32K（勉强） |
200K |
| 系统提示兼容 |
❌ 29K 装不下 |
✅ 轻松容纳 |
| 首 token 延迟 |
30-60 秒 |
1-3 秒 |
| 费用 |
免费 |
~$3-5 / 天 |
速度差距在 6-8 倍，上下文差距更是天壤之别。
核心问题：为什么不能用？
- 系统提示溢出：Claude Code 的系统提示词高达 29000+ token，直接超过 4096、16384 的上下文窗口，模型连启动都启动不了
- 生成速度太慢：即使勉强跑起来，14 tok/s 的输出速度，一个函数重构要等好几分钟
- Prompt 处理瓶颈：每次请求都带着完整的系统提示 + 对话历史，本地模型 prefill 阶段就要几十秒
- 上下文迅速耗尽：32K 的窗口减去 29K 系统提示，只剩 3K 给对话，写不了几轮就溢出
简单说：Claude Code 天生就是为云端大模型的超长上下文设计的，本地 26B 模型目前接不住。
为什么想用本地模型？
最近 Claude Code 被曝出 BUG 狂吞 token—— 有用户逆向工程 Claude Code 二进制文件，发现两个独立 bug 导致 prompt cache 静默失效，token 消耗膨胀 10-20 倍。Max 5x（$100 / 月）一个小时烧完、Pro 用户一周只能用 12 天的吐槽在社区此起彼伏。2026 年 4 月，Anthropic 官方也承认 "用户消耗限额的速度远超预期，正在积极调查"。
正好 3 月 31 日 Google 新发布了 Gemma 4 系列，赶紧尝试下：本地跑 Gemma 4，对接 Claude Code，彻底摆脱 token 焦虑。
128GB 统一内存 + 40 核 GPU + MoE 架构的 26B 模型，纸面上看是完美组合。实际呢？下面是完整的踩坑过程。
环境搭建
LM Studio 作为推理后端
选 LM Studio 的原因很简单：GUI 操作、自带 Metal 加速、OpenAI 兼容 API、一键启动。
- 下载 LM Studio（v0.4.9）
- 搜索并下载
google/gemma-4-26b-a4b 模型
- 进入 Developer → Local Server，加载模型
- 服务默认监听
http://localhost:1234
Claude Code 对接配置
Claude Code 支持自定义 API 端点，配置指向本地 LM Studio 即可：
export ANTHROPIC_BASE_URL=http://localhost:1234/v1
export ANTHROPIC_API_KEY=lm-studio
看起来很简单对吧？然而坑从这里才刚开始。
踩坑一：上下文长度的致命陷阱
第一个真正的大坑来了。启动 Claude Code 后直接报错：
The number of tokens to keep from the initial prompt is greater than
the context length (n_keep: 29006 >= n_ctx: 4096)
翻译一下：Claude Code 的系统提示词就有 29000+ token，而我的上下文窗口只设了 4096。
这就好比你拿一个 4L 的水壶去装 29L 的水。
上下文长度调整历程
| 上下文长度 |
结果 |
| 4,096 |
❌ 系统提示都塞不进去 |
| 16,384 |
❌ 同样装不下（n_keep: 29006 >= n_ctx: 16384） |
| 32,768 |
⚠️ 勉强能跑，但留给对话的空间极小 |
| 40,960 |
✅ 能用，但 prompt 处理很慢 |
最终选了 32768，勉强够用但体验一般。
根本原因： Claude Code 的系统提示词为云端大模型设计（动辄 100K+ 上下文窗口），本地 26B 模型的上下文能力根本吃不消。
踩坑二：Prompt 处理速度极慢
即便上下文调到 32768 能跑了，每次请求的 prompt 处理（prefill）都要等很久。从日志能看到：
Prompt processing progress: 31.7%
Prompt processing progress: 33.5%
Prompt processing progress: 35.2%
...
逐步爬升，一个请求 prompt 阶段就要等几十秒。原因是 Claude Code 每次请求都带着庞大的系统提示 + 完整对话历史，本地模型处理这些长输入的速度远不如云端。
优化尝试与效果
有效的优化
| 优化项 |
操作 |
效果 |
| Flash Attention |
LM Studio 右侧开启 |
prefill 有一定提速 |
| Unified KV Cache |
开启 |
内存利用更高效 |
| 保持模型在内存中 |
开启 |
避免反复加载 |
| CPU 线程数 |
12 → 14 |
略有提升 |
| 评估批处理大小 |
512 → 2048 |
prefill 阶段提速 |
| /compact 命令 |
Claude Code 中使用 |
压缩上下文，缓解溢出 |
效果有限的优化
| 优化项 |
说明 |
| GPU 卸载 |
已经是最大值 30 |
| 更小量化（Q4_K_S） |
速度略提升，但不解决上下文根本问题 |
最终结论：本地模型跑 Claude Code，现阶段不太实际
说实话，经过这轮测试，我的结论是：
❌ 不推荐的场景
- Claude Code 日常开发：系统提示 29000+ token 的硬伤无解，本地模型的上下文窗口和处理速度都跟不上
- 需要频繁多轮对话的编码任务：上下文迅速膨胀，要么溢出要么极慢
✅ 推荐的场景
- OpenClaw / 其他轻量级 AI 对话：系统提示短，上下文可控，本地模型完全胜任
- 单轮问答、代码片段生成：不涉及长上下文，速度可以接受
- 隐私敏感项目：代码不出本机
更好的方案
对于 Claude Code 用户，更务实的做法是：
- 继续用 Anthropic API（Sonnet 性价比高）
- 安装 RTK（Rust Token Killer） 压缩命令输出，省 60-90% token
- 本地模型留给 OpenClaw 等聊天场景
- 善用 /compact 和 /model 切换，在 Opus 和 Sonnet 之间灵活切换
M4 Max 128GB 跑 Gemma 4 26B 的性能参考
| 指标 |
数值 |
| 模型大小 |
17.99 GB（量化后） |
| GPU 卸载层数 |
30/30（满载） |
| 生成速度（短上下文） |
~30-40 tok/s |
| 生成速度（长上下文） |
~14 tok/s |
| Prompt 处理（29K token） |
数十秒 |
| 内存占用 |
~18-25 GB |
写在最后
Apple Silicon 的统一内存架构让本地跑大模型成为可能，M4 Max 128GB 跑 26B 模型确实没有显存焦虑。但 "能跑" 和 "好用" 之间还有很大的距离。
Claude Code 的设计理念是面向云端大模型的超长上下文场景 —— 光系统提示就接近 3 万 token，这不是本地 26B 模型目前能优雅承载的。也许等到本地模型的上下文能力和推理速度再上一个台阶，这个方案才会真正可行。
