gemma

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

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

如果只看榜单，最容易心动的肯定是 31B。

但真把机器搬出来，还是那台没升级的 RTX 3060 12GB，判断马上就会变。怎么说呢，本地部署这件事，最后拼的不是谁最风光，而是谁最像能长期相处的那个。对我来说，这次真正值得先跑的，不是 31B，而是 26B A4B。

首发当天我本来想干的事很简单，找一个和 Gemma 3 对应得上的升级版，先下下来跑。

结果一圈看下来，人先有点傻眼。以前熟的 4B / 12B / 27B 那套名字没了，冒出来的是 E4B、26B A4B、31B。怎么说呢，这次谷歌真正改的，不只是模型大小，而是连“你该怎么理解这批模型”都一起改了。

最近把一些边角活往 MiniMax 和本地模型上迁，感受反而比一开始更清楚：很多任务不是非要最强模型才能做，而是不能把所有模型都放到同一个工位上比。

以前我容易问“这个模型强不强”。现在更愿意先问两件事：这件活错了以后代价有多大，重复跑一百次以后成本有多高。答案一变，低成本模型、本地模型和旗舰模型的位置也就变了。

复杂编码、长链路推理、模糊需求拆解，还是该给更强的模型；数据清洗、文档改写、资料初筛、固定格式转换，反而更适合交给便宜模型和本地模型。它们不一定聪明到能总包项目，但很适合把那些不值得人反复动手的活接住。

博客翻译项目最初设计过于复杂——先解析 Markdown 格式，再用占位符保护内容，最后送给大模型翻译。其实这完全是多此一举，大模型本身就具备识别 Markdown 语法的能力，可以直接处理原始内容并在翻译时保持格式完整。

我们的工作就从调试代码，切换到调试大模型的提示词。

模型：google/gemma-3-4b 硬件：Nvdia 3060 12GB

没错，选的非思考模型，思考模型在执行翻译任务时，效率不够高，对比了 4b 参数和 12b 参数的效果，针对翻译任务来说 gemma3 的 4b 参数已经足够了，12b 的参数在翻译任务上并没有明显的优势。

12b 参数的速度：11.32 tok/sec，4b 参数的速度：75.21 tok/sec。