谷歌这次把 Gemma 4 放开了（三）

Wed, 08 Apr 2026 23:56:20 +0800

这次刷论坛，最让我长记性的不是哪家又发了榜单，而是一句很土的话，显存不够，参数再大也白搭。

以前我总把“模型慢”理解成算力问题。后来越看越明白，很多时候根本不是 GPU 算不动，而是数据没法待在对的地方。只要内存路径一变，token 速度就不是慢一点，是直接掉下去。

前两篇已经把前置问题收完了。第一篇讲发布和协议，第二篇讲 3060 12GB 上为什么先看 26B A4B。最后这一篇，就只讲速度到底是怎么塌的。

显存不够，慢的不是一点点

推理这件事，拆开看就两块特别关键：

模型权重
KV cache

权重决定模型本身，KV cache 记录前文状态。上下文越长，KV cache 越大。只要这两块都能稳稳留在 GPU 显存里，生成 token 的时候基本就是在高带宽显存里取数据、做计算、回写结果，速度通常还能看。

真正麻烦的，是显存装不下。

一旦装不下，推理框架就得退让：

一部分权重放系统内存
或者一部分 KV cache 放系统内存
或者干脆 CPU 和 GPU 来回搬

这时候问题就不是“多算了点”，而是“每出一个 token 都要等数据”。

为什么会出现断崖，不是线性变慢

很多人第一次遇到这个坑，直觉都会觉得，模型从 14B 变成 31B，那就慢一倍多，忍一忍也行。

现实不是这样。

真正的分界线不是参数翻倍，而是工作集有没有跨过显存边界。

只要没跨过去，模型变大通常还是一种可预期的变慢。

一旦跨过去，系统状态就变了：

原来是“显存内闭环”
现在变成“显存 + 主内存 + 总线搬运”

路径一换，代价就完全不一样了。尤其是 decode 阶段，本来就是逐 token 往前走，batch 也不大，这时候最怕的就是每个 token 都要跨设备去等一批数据回来。

所以你会看到一种很典型的现象：

模型不是不能跑
GPU 也不是完全闲着
但 token/s 直接很难看

这就是大家说的“断崖”。不是模型突然变蠢，是内存路径突然变笨了。

`26B A4B` 为什么对本地玩家友好一点

这一点也正好解释了，为什么我前一篇一直更看重 26B A4B。

它的总盘子当然不小，但每个 token 真正激活的大约只有 3.8B。这意味着在相似部署条件下，它对计算和显存路径的压力，往往比 dense 大模型更容易控制。

这也不是魔法。

如果你上下文拉太长，或者量化和框架支持不到位，它一样会难受。只是相比那种一上来就把整块显存顶满的 dense 模型，26B A4B 更像是留给消费级显卡的一条现实路线。

所以很多时候不是 31B 不强，而是本地机器更适合和谁长期相处。

Mac 为什么看起来“不容易爆”

Mac 这边最不一样的，不在模型，在内存结构。

Apple silicon 走的是统一内存。CPU 和 GPU 共享同一池内存，而不是像独显机器那样，一边是显存，一边是主内存，中间再靠总线搬。

这套结构最大的好处，就是很多在独显机器上“显存根本装不下”的模型，到 Mac 上会变成另外一种状态：

不一定很快
但大概率先能装进去

也就是说，Mac 更不容易在第一步就撞上那堵非常生硬的“显存墙”。

这就是为什么很多人会觉得，Mac 在本地大模型这件事上特别适合兜底。它解决的是“能不能先把整套工作集塞进同一池内存里”。

但统一内存不等于送你高速度

这个地方一定要拆开看。

统一内存解决了什么？

解决了独显显存和主内存硬分家
解决了很多模型在小显存卡上直接装不下
解决了部分极难看的跨设备来回搬运

但它没有解决什么？

没有把大模型推理从“海量读内存”变成别的事情
没有让大模型突然不吃带宽
没有让所有推理框架自动拥有 CUDA 那套成熟生态

所以 Mac 的舒服，和英伟达大显存卡的快，不是同一回事。

Mac 更像是：

机器安静
总内存大
统一
很多原本塞不下的模型，终于能先跑

英伟达大显存卡更像是：

生态成熟
CUDA 工具链完整
真把模型和 cache 留在 GPU 里以后，速度更容易拉起来

为什么想要速度，最后还是得看英伟达大显存

这不是情绪判断，是本地部署一路折腾下来很容易得出的现实结论。

如果你追求的是这些东西：

本地助手常驻
多轮长对话
长上下文
更高 token/s
尽量减少等待

那最后看的还是大显存英伟达卡。因为你真正在买的，是把模型和 cache 尽量稳定留在 GPU 那边的能力。

Mac 当然也成立，但它更适合另外一类诉求：

我想一台机器先把更大的模型装进去
我接受速度一般，但不想折腾驱动和外设
我更在乎整体体验、功耗和噪音

这两种路线都合理，只是解决的问题不一样。

放回到 Gemma 4，我的最终判断

Gemma 4 这次确实让我觉得，本地开源模型已经进入了一个更值得认真讨论硬件的阶段。

但模型变强，不代表物理规律跟着一起松了。

31B 再强，显存不够也会掉速。

26B A4B 再务实，上下文过长也会吃压力。

Mac 统一内存再舒服，也只是让“先跑起来”更容易，不会白送你一张大显存 CUDA 卡的速度。

所以最后还是那句很土的话：

要速度，优先英伟达大显存
要兜底，Mac 的统一内存确实舒服
要在 3060 12GB 这种机器上长期玩，别老惦记 dense 大模型，26B A4B 这种路线更现实

这组文章写到这里，也就收住了。

参考资料

写作附记

原始提示词

$blog-writer 谷歌时隔一年，发布了 Gemma4 模型，老规矩，尝试本地部署，还是那台没升级的台式 3060 12GB 英伟达显卡。这次赶上了首发，但是没找到以前常用 Gemma3 的升级版本，但是多有个类似的版本 GemmaE4b，你先搜索介绍下，本次发布了的所有型号，里面的缩写字母什么意思，然后搜索下网上关于 Gemma4 的评价，关键是，本次谷歌更新该了模型的协议，大家用起来的限制更少了。最大的惊喜，我常用的测试题：写一段 C++ 代码，在控制台输出五角星，去年的小参数开源模型都没搞定这个问题，谷歌这次搞定了，第一版给出答案，完全超出我的意料，它知道了我的陷阱，控制台输出五角星很麻烦，它直接硬编码了一个五角星的字符串，控制台直接输出。这是原文：由于在纯文本的控制台（Console）中通过数学逻辑直接绘制一个具有精确几何结构的五角星非常复杂（涉及到坐标系转换和像素填充），最经典且视觉效果最好的方法是使用 ASCII Art（字符艺术）。在我去强制要求进行计算以后，它也搞定了，通过数学计算，成功的绘制了五角星。以前常用 Gemma4 进行本地的翻译任务，当前博客很多历史文章的多语言版本就是这样来的。本地测试用的：gemma-4-26b-a4b 模型，31b 版本属实太慢了。但是看测评 31b 效果很不错，排行榜的成绩很好。同时刷论坛，我认知到了，显存如果不够，模型参数上去了，生成 token 的速度会断崖式下降，你解释下为什么？Mac 不会有这个问题，它走的是统一内存，解释下技术原因。还有就是，如果需要速度，那还是 英伟达大显存的显卡才行。Mac 的方案能兜底，但是速度上不去。本次的内容很多，你评估下是否拆成系列文章。

写作思路摘要

第三篇只保留“速度为什么塌”和“Mac 为什么不等于快”这两条线，不再回头解释前两篇的内容。
先讲显存边界，再讲非线性掉速，逻辑比上一版更顺。
Mac 和英伟达被拆成两个不同维度来讲，一个偏兜底，一个偏速度。
结尾只保留硬件判断，不再重复解释为什么拆系列。

显存 on 向叔记事簿