欢迎访问本站，持续更新中…
RSS

WikiFw 维基框架

本地模型终于能打了：Gemma 4 实测体验

1 天前 Gemma本地模型开源

每日一文

2026 年 6 月 17 日

晚上十一点，我盯着终端里跑完的测试结果，沉默了大概十秒。

然后我笑了。

因为本地模型——不是在云端的 API，不是 400 美金一月的订阅——就在我手边这台 M2 Mac 上——终于真的能用了。

说实话，这事儿让我挺感慨的。我从本地模型第一批能跑的时候就开始折腾了。踩过的坑，比走过的路还多。

封面

先说今天的热帖

Vicki Boykis 昨天（6 月 15 日）发了一篇博客，标题特别朴实："Running local models is good now"。

就七个字。

但在 Hacker News 上拿了 998 分。将近一千个开发者点了赞。

这说明什么？说明关注这个话题的人太多了——而且大家都憋着一肚子苦水想说。过去两年里，每次有人问"本地模型能不能替代云端 API"，评论区都是"不行""差太远了""等两年吧"。但这次，风向变了。

Vicki 的配置很实在：一台 2022 年的 M2 Mac，64GB 内存，1TB 存储。不是什么土豪级的 A100 集群，也不是什么双路 4090，更不是那种只有 FAANG 才用得起的 HGX 服务器——就是一台普通的开发者笔记本。

她用过的本地模型清单：Mistral 7B、Gemma 3、OpenAI OSS-20B、Qwen 3 MOE、Qwen 2.5 Coder。跨越的推理框架：llama.cpp + Open WebUI、llama-cpp-python、Ollama、llamafiles、LM Studio。

说实话，看到这个清单我就觉得亲切——这不是一篇"理论分析"的博客，这是真的踩过无数坑、经历过无数次"模型崩了"和"显存爆了"之后，才写出来的东西。

我记得我刚入坑本地模型的时候——大概是 2024 年初——跑一个 7B 模型都觉得慢得受不了。那时候的量化技术也不行，4-bit 量化之后模型质量下降得很厉害，回答都是"嗯嗯啊啊"的敷衍型。现在呢？7B 模型在手机上都能跑了。12B 在笔记本上跑得飞起。这差距不是线性进步，是跳跃式的。

转折点在哪？

我原本以为"本地模型总是 lagging behind 云端 6-12 个月"，后来发现这个结论可能已经过时了。

转折点在哪呢？Vicki 说了一个关键词：Gemma 4。

Google 的 Gemma 4 系列——特别是 Gemma 4 26B A4B 和 Gemma 4 12B QAT——让本地 AI 编码第一次接近了"可用"的门槛。

她的原话是这么说的："我最近终于能够在本地进行 agentic coding，循环工作速度/准确率大约是前沿模型的 75%。"

75%。

这个数字如果放在一年前，没人会信。一年前本地做 agentic coding 是什么体验？模型跑得慢，跑出来的代码质量低，经常给一些"看起来对但实际上跑不通"的代码。你要花大量时间做调试和验证。测试一下，如果当时有人说本地模型能跑到前沿模型 75% 的准确率，我会觉得他要么是 PR 稿写多了，要么就只用本地模型写过"Hello World"。

但 Beta——不对——但事实证明我错了。

我自己也测了一下。选了一个我觉得挺考验模型能力的场景：把一个 Jupyter Notebook 里乱糟糟的 Python 代码，重构成一个规范的 Python 包，包含 5-6 个模块，加上正确的类型注解和文档字符串。

用 Gemma 4 12B QAT（通过 LM Studio 跑），整个过程我没怎么介入，它就做完了。类型注解用了正确的 typing 语法——不是那种老式的 -> List[str]，而是 -> list[str]（Python 3.9+ 的现代写法）。这说明模型对新语法的知识是更新过的。

作为对比，我去年用 Mistral 7B 试过同样的任务。结果呢？惨不忍睹。它生成的代码里混着 Python 2 和 Python 3 的语法，类型注解直接用了不存在的数据类型，而且完全忽略了我要的模块结构。最终我花了两天时间手工重写。

一年的时间，本地模型的进展就是这么大。

内容

踩坑实录

但我不能光说好话，不报坏消息。因为本地模型虽然进步了，该踩的坑一个都没少。这些坑不是"小毛病"，是真的影响日常使用的硬伤。

第一个坑：内存消耗。

Gemma 4 12B 的量化版跑在 64GB 内存的 M2 Mac 上，KV cache 能吃到 64GB。对，你没看错——64GB。如果你只有 16GB 或 32GB 内存，只能跑更小的量化版，或者接受更短的上下文窗口。我试过在一台 16GB M1 上跑 Gemma 4 12B 的 4-bit 量化版。能跑。但生成速度大概是一秒钟一个 token。写一句代码等半分钟。那种体验说实话比不能用还难受——它让你尝到一点甜头，但每次等待都在提醒你"硬件不够"。我自己平时做开发必须保持思维连贯，如果每次补全都要等 30 秒，那还不如我自己手写代码。

而且还有一个更隐蔽的问题：大上下文窗口下的内存爆炸。如果你在本地模型上加载一个有 10 万行代码的项目，上下文窗口拉长之后，KV cache 占用的内存会急剧增长。我曾经试过加载一个中型 Django 项目（大概 50 个文件），然后问模型一个涉及跨文件引用的问题。结果模型推理到一半，进程直接被系统 kill 了——OOM。

第二个坑：agent 流程的 Docker 限制。

Vicki 提到她把所有 agent 工作流都放在 Docker 容器里，只给 bash 权限，不给联网、不给执行 Python 的能力。

这个限制对于安全审计来说是非常必要的——你肯定不想让一个 AI agent 在宿主机上随便跑代码——但同时也意味着很多 agent 功能被阉割了。比如它不能自己安装依赖、不能运行测试、不能做 web scraping。

我试过放宽限制。结果呢？第一次跑 agent 它就试图安装一个从 GitHub 随便拉下来的包——那个包的代码我没审查过。而且它还尝试连接本地的数据库（检测到了我映射过去的端口），被我防火墙拦住了。吓得我立刻把权限收回来了。所以安全性和功能性之间的平衡，是本地 AI agent 面临的核心难题。目前没有完美的解决方案。

第三个坑：模型的"幻觉"仍然存在。

之前我测试让 Gemma 4 帮我写一个 Go 语言的并发下载器，用来做日常备份。它生成的代码看着没问题：goroutine 用了，channel 用了，错误处理也写了。但跑起来之后，发现它的并发控制有问题——它用了 sync.WaitGroup，但是没有在 wg.Add() 之前正确计数，导致程序在下载文件数量不确定的时候提前退出了。修复这个问题花了我 15 分钟。如果我没认真 review 就部署到 CI pipeline 里，后果会是一堆坏文件被当作备份上传到 S3。

这种 bug 如果出现在云端的前沿模型（Claude、GPT-4o）上，通常不会有——这些模型对并发编程的理解更深入。本地模型虽然进步了，但在这个层级的细节上还是偶尔翻车。

部署的三种姿势

经过这段时间的折腾，我总结出三种本地模型的部署方式，各有优劣。

方案一：纯本地 + Ollama。 最简单，一行命令安装，模型自动下载。缺点是大模型（20B+）在 Ollama 上跑得不够快，而且 agent 集成不如 LM Studio 方便。

方案二：LM Studio + Pi agent。 Vicki 推荐的方式。LM Studio 做推理后端，Pi 做 agent 框架。配置略复杂——需要在 Docker 里配 network、设环境变量、修改 Pi 的 models.json——但一旦跑起来，体验是最顺滑的。我目前用这个方案。说实话，配置过程确实折腾了一阵——特别是在 Docker Compose 里让容器能访问 host 的 LM Studio 服务端。需要加 extra_hosts: ["host.docker.internal:host-gateway"]，还要在 LM Studio 里启用 "Allow cross-origin requests"。但这些配置是一次性的。

方案三：llama.cpp 直跑。 性能最好，但配置最麻烦，没有 GUI，没有 agent 集成，适合硬核玩家。用来跑基准测试或者批量推理很好，日常编码就算了。

值与不值

一个现实的问题摆在面前：值不值得花时间折腾本地模型？

我的判断是：看场景。

如果你只是写写脚本、做做数据分析、调调 API，云端的前沿模型体验确实更好。速度快、不需要自己管理和升级模型、不出幺蛾子。但如果你的场景涉及敏感代码、或者经常在没有网络的环境下工作（飞机上、地铁里）、或者你是个技术控想折腾——那么现在的本地模型已经足够好了。

Gemma 4 12B QAT 在 LM Studio 上跑，我日常的代码修改、单元测试、文档生成，大概 70% 的工作可以交给它。剩下的 30%——复杂的架构设计、跨模块的深入重构、涉及业务逻辑的关键变更——我还是会回到云端模型或者自己手写。但这个比例在六个月前是 10% 和 90%。进步的速度让我觉得，到年底，这个比例可能变成 90% 和 10%。到了那个时候，买一台 128GB 内存的 Mac 可能就成了开发者的标配——而不仅仅是少数人的玩具。

我一直觉得本地 AI 和云端 AI 不是对立关系，而是互补关系。你可以用云端模型做复杂的架构设计，用本地模型做日常的代码生成和检查。两者配合使用，效率最高。

现在这个互补关系终于站得住脚了。

关于维基框架

维基框架（Wiki Framework）是一套面向复杂业务场景的轻量级开发框架，支持多语言、多协议、多部署形态。适用于企业级应用开发、微服务架构、云原生部署等场景。