JeecgBoot AI专题研究 | 谷歌 Gemma 4 本地部署对接 Claude Code 的完整踩坑实录与性能分析
起因：Claude Code 的 Token 黑洞事件
2026 年 4 月前后，Claude Code 社区炸了锅。有开发者逆向分析了 Claude Code 的二进制文件，揪出了两个互相独立的 Bug，直接导致 Prompt Cache 静默失效——原本应该被缓存复用的系统提示词，每次请求都在重新计算，Token 消耗凭空膨胀了 10 到 20 倍。
这意味着什么？Max 5x 订阅（$100/月）的用户，一个小时就能把配额烧光；Pro 用户一周的额度只够撑 12 天左右。Anthropic 官方随后也承认"用户消耗限额的速度远超预期，正在积极调查"。
正巧赶上 2026 年 3 月 31 日，Google 发布了 Gemma 4 系列模型。一个自然的想法冒了出来：既然云端 Token 在流血，为什么不把模型搬到本地，彻底绕开这个问题？
128GB 统一内存 + 40 核 GPU + MoE 架构的轻量模型——纸面数据堪称完美。但实际跑下来，踩了一路的坑。这篇文章就是完整的踩坑复盘。
关于 Gemma 4 系列：为什么选 26B A4B
Google 这次一口气发布了四个版本：E2B、E4B、31B 和 26B A4B。
其中 26B A4B 之所以成为本地部署的热门选择，核心在于它采用了 MoE（Mixture of Experts，混合专家）架构——虽然总参数量达到 26B，但每次推理实际只激活约 4B 的参数。理论上，这意味着你能用 4B 级别的算力开销，获得接近 26B 的推理质量。
对于 Apple Silicon 设备来说，这简直是量身定制的：统一内存架构省去了 CPU-GPU 数据搬运的瓶颈，Metal 加速又能把 GPU 利用率拉满。
实测环境一览
开始之前，先交代测试平台的硬件和软件配置：
- 硬件：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 层满载）
选 LM Studio 的理由很朴素：图形化操作零门槛、内置 Metal 加速、提供 OpenAI 兼容 API、一键就能起服务。
环境搭建：看起来很简单
整个搭建过程四步走：
- 下载 LM Studio（v0.4.9）
- 搜索并下载
google/gemma-4-26b-a4b模型 - 进入 Developer → Local Server，加载模型
- 服务默认监听
http://localhost:1234
Claude Code 原生支持自定义 API 端点，只需要两行环境变量就能对接：
export ANTHROPIC_BASE_URL=http://localhost:1234/v1
export ANTHROPIC_API_KEY=lm-studio
到这里一切看起来都挺顺利。但启动 Claude Code 的那一刻，真正的麻烦才刚刚开始。
第一个大坑：系统提示词直接撑爆上下文
启动 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，连提示词都塞不进去，遑论对话了。
打个比方，这相当于拿一个 4 升的水壶去装 29 升的水。
于是开始一轮接一轮地调上下文窗口大小：
| 上下文长度 | 结果 |
|---|---|
| 4,096 | ❌ 系统提示都塞不进去 |
| 16,384 | ❌ 依然装不下（n_keep: 29006 >= n_ctx: 16384） |
| 32,768 | ⚠️ 勉强能跑，但留给对话的空间极其有限 |
| 40,960 | ✅ 能用，不过 Prompt 处理速度明显变慢 |
最终折中选了 32768。虽然勉强能启动，但 32K 减去 29K 的系统提示，留给实际对话的窗口只剩不到 3K Token——聊不了几轮就会溢出。
这背后的根本矛盾是：Claude Code 从设计之初就面向云端大模型的超长上下文场景（动辄 100K+），本地 26B 模型的上下文能力完全不在同一个量级。
第二个坑：Prompt 预处理慢到令人窒息
即便上下文窗口调到了 32768 勉强能跑，每次请求的 Prompt 预处理（prefill）阶段都令人焦灼。从日志里能看到进度条在一点一点地往前爬：
Prompt processing progress: 31.7%
Prompt processing progress: 33.5%
Prompt processing progress: 35.2%
...
一个请求光 prefill 就要等几十秒。原因也不难理解：Claude Code 每次请求都会携带完整的系统提示 + 全部对话历史，这对本地模型的长序列处理能力是巨大的考验。
速度对比：差距不是一星半点
实测下来，不同上下文长度场景下的生成速度差异非常明显：
| 场景 | 生成速度 | 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 倍，上下文差距更是天壤之别。 唯一的优势就是不花钱——但体验上的落差实在太大。
优化尝试：能救多少救多少
虽然基本面不乐观，但还是尝试了一系列优化手段，看看能不能把体验拉到可用线：
有明显效果的调整
| 优化项 | 具体操作 | 实际效果 |
|---|---|---|
| Flash Attention | LM Studio 右侧面板开启 | Prefill 阶段有一定提速 |
| Unified KV Cache | 开启 | 内存利用效率提升 |
| 模型常驻内存 | 开启 | 避免每次请求重新加载模型 |
| CPU 线程数 | 从 12 调到 14 | 略有改善 |
| 评估批处理大小 | 从 512 调到 2048 | Prefill 阶段提速明显 |
| /compact 命令 | 在 Claude Code 中定期使用 | 压缩对话上下文，延缓溢出 |
收效甚微的调整
| 优化项 | 原因 |
|---|---|
| GPU 卸载层数 | 已经拉满到 30，没有提升空间 |
| 更激进的量化（Q4_K_S） | 速度略有提升，但不解决上下文容量的根本问题 |
总的来说，这些优化能让短对话场景下的体验更流畅，但对 Claude Code 这种 29K+ Token 的重型场景，属于杯水车薪。
四个核心矛盾，一个都绕不开
把所有问题归纳一下，本地 Gemma 4 跑 Claude Code 面临的核心瓶颈其实就四条：
- 系统提示溢出：Claude Code 的系统提示词高达 29000+ Token，直接逼近甚至超出本地模型的上下文上限，模型在有些配置下连启动都启动不了
- 生成速度不达标：即便勉强跑起来，14 tok/s 的输出速度意味着一个简单的函数重构可能要等好几分钟
- Prefill 成为瓶颈：每次请求都携带完整的系统提示和对话历史，本地模型处理这些长输入动辄几十秒
- 上下文空间严重不足：32K 窗口减去 29K 系统提示，实际可用的对话空间不到 3K，写不了几轮就爆
一句话总结：Claude Code 天生就是为云端大模型的超长上下文量身打造的，26B 级别的本地模型在现阶段根本接不住。
M4 Max 128GB 跑 Gemma 4 26B：硬件性能参考
虽然结论不太乐观，但硬件性能数据本身还是有参考价值的：
| 指标 | 数值 |
|---|---|
| 模型体积 | 17.99 GB（Q4_K_M 量化后） |
| GPU 卸载层数 | 30/30（满载） |
| 生成速度（短上下文） | ~30-40 tok/s |
| 生成速度（长上下文） | ~14 tok/s |
| Prompt 处理（29K Token） | 数十秒 |
| 内存占用 | ~18-25 GB |
Apple Silicon 的统一内存架构确实让本地大模型部署成为可能——128GB 内存跑 26B 模型毫无显存压力。但"能跑"和"好用"之间，隔着的不止是一条鸿沟。
那什么场景适合本地模型？
虽然跑 Claude Code 不太现实，但本地 Gemma 4 在以下场景下表现完全合格：
- 轻量级 AI 对话工具（如 OpenClaw 等）：系统提示短小、上下文可控，本地模型游刃有余
- 单轮问答和代码片段生成：不涉及长上下文累积，响应速度在可接受范围内
- 隐私敏感项目：代码完全不出本机，对安全合规有硬性要求的团队可以考虑
更务实的方案：省 Token 而非换模型
对于 Claude Code 用户来说，与其折腾本地部署，不如从"节流"入手：
- 继续使用 Anthropic API，Sonnet 的性价比在同级模型中依然突出
- 安装 RTK（Rust Token Killer） 压缩命令行输出，实测可省 60-90% 的 Token 消耗
- 本地模型留给聊天场景，跑 OpenClaw 或其他轻量对话工具
- 善用 /compact 和 /model 切换，在 Opus 和 Sonnet 之间按需灵活调度
写在最后
这次实测最大的收获，不是验证了"本地模型能不能替代 Claude Code"，而是更清晰地看到了云端大模型和本地推理之间的真实差距——尤其是在上下文容量和处理速度这两个维度上。
Claude Code 的产品设计从一开始就深度绑定了云端超长上下文的能力，光系统提示就接近 3 万 Token。这不是当前任何 26B 级别的本地模型能优雅承载的。也许等本地模型的上下文窗口和推理速度再跨上一个台阶，这条路才会真正走通。
在那一天到来之前，把云端和本地各自放在最擅长的赛道上，才是最理性的选择。
本文为 JeecgBoot AI 专题研究系列文章。
