谷歌Gemma 4微调实战：96GB显存能喂饱31B模型吗？

当谷歌把Gemma 4的权重文件丢进开源社区时，一个问题立刻浮出来：上一代27B模型刚能塞进云服务器，这一代直接跳到31B，还加了混合专家架构——现有的无服务器GPU方案会不会瞬间撞墙？

一位工程师决定用NVIDIA RTX PRO 6000的96GB显存硬碰硬，目标是做一件看似 trivial 的事：让模型分清猫狗品种。但真正的测试不在准确率，而在"能不能跑起来"。

为什么Gemma 4不是简单的版本号+1

谷歌这次开源的Gemma 4带着五个硬指标出场。最扎眼的是许可协议从之前的限制条款换成了Apache 2.0——这意味着企业可以毫无顾虑地商用，不用像上一代那样提心吊胆读法律条款。

模型本身的排位也变了。Gemma 4 31B在Arena AI文本排行榜上冲到第三，26B的MoE（混合专家）版本排第六。一个有趣的对比：这两个模型的体积只有排行榜上某些模型的1/20，但排名却更靠前。

架构层面的改动更深层。Gemma 4原生支持函数调用、结构化JSON输出、系统级指令——这些不是后加的插件，是训练时就埋进去的。多模态能力扩展到图像、视频，边缘模型甚至能处理音频。上下文窗口拉到256K，MoE架构在推理时只激活26B参数中的3.8B，响应速度理论上会快很多。

但正是这些"进步"，让直接沿用Gemma 3的微调脚本变成不可能。作者在原代码库上踩了一圈坑，才整理出一份能跑通的修改清单。

显存账本的精细计算

Cloud Run Jobs新上架的NVIDIA RTX PRO 6000 Blackwell Edition给的是96GB显存。这个数字听起来宽裕，但31B模型在16位精度（bfloat16）下裸重就达62GB——31亿参数×2字节/参数。

作者引用了自己之前博客里的显存计算公式：总HBM占用≈模型体积+优化器状态+梯度+激活值。LoRA（低秩适配）的价值在这里凸显：冻结基座权重，只训练一小部分参数，意味着基座模型的梯度和优化器状态可以忽略不计。

62GB基座+LoRA的额外开销，确实能塞进96GB。但这是理论上限，实际操作中激活值和临时缓存会吃掉余量。作者没有给出具体数字，但暗示这个配置是"刚好够"而非"很宽裕"。

一个细节被反复提及：Gemma 4的tokenizer和prompt结构变了。上一代那套"用户/模型"对话格式需要调整，系统指令的注入方式也不同。这些不是文档里加粗强调的breaking change，是跑通训练后才发现的隐性成本。

代码层面的具体手术

作者开源的修改清单包含几个关键文件调整。首先是动态标签掩码（dynamic label masking）的实现——Gemma 4的推理导向设计让模型倾向于生成思维链式的中间步骤，但分类任务只需要最终答案。如何屏蔽掉那些"思考过程"的loss计算，成为微调脚本必须处理的新问题。

其次是prompt结构的重新设计。Gemma 3时代那套"下面是一只猫，品种是___"的填空式prompt，在Gemma 4上需要 wrapping 进系统指令和工具调用的框架里。作者没有展开讲具体语法，但强调"复制粘贴旧prompt会拿到奇怪的结果"。

PEFT（参数高效微调）库的适配也有坑。LoRA的配置参数——秩（rank）、缩放系数（alpha）、dropout率——需要针对Gemma 4的注意力头重新调参。作者提到自己试了若干组合，但没有透露最终采用的数值，只说"比Gemma 3更敏感"。

最隐蔽的改动可能在数据加载环节。256K上下文窗口理论上能塞下更多样本，但作者实际用的是短文本分类任务，这个能力并未被利用。他留下一个开放式观察：长上下文对微调究竟是福是祸，取决于你的数据分布。

无服务器GPU的边界测试

Cloud Run Jobs的定位是"按需启动、按秒计费"的无服务器容器。把96GB显存的GPU塞进这个框架，谷歌实际上在试探一个边界：多大参数的模型可以真正"serverless"？

Gemma 4 31B的答案似乎是"勉强可以"。62GB基座+训练开销，没有给批量大小（batch size）留下太多腾挪空间。作者没有报告训练时长和成本，但读者可以推算：如果单步迭代需要把全量激活值过一遍显存，时间成本不会低。

MoE版本的26B模型可能是更务实的选择。3.8B激活参数意味着推理时的内存压力骤减，但微调时的行为更复杂——专家路由的梯度如何传播，LoRA应该加在哪些层，这些问题作者没有深入，但暗示"和dense模型完全不同"。

一个未被回答的问题是：为什么选宠物分类这个看似简单的任务？作者的逻辑可能是反向的——不是任务需要31B，而是31B需要一个小任务来验证"能不能跑"。如果连二分类都调不通，更复杂的场景无从谈起。

开源模型的商业许可转折点

Apache 2.0的切换值得单独拆解。Gemma前几代的开源协议带有商业限制条款，企业法务部门往往需要逐条审阅。这次谷歌选择最宽松的主流协议，信号明确：他们希望Gemma 4被集成进产品，而非仅仅作为研究玩具。

这个决策的时间点耐人寻味。Llama系列仍在用自定义的社区协议，Mistral的许可条款随版本变动，阿里Qwen的商用授权需要单独申请。谷歌用Apache 2.0把自己放在了"最无摩擦"的位置。

但许可的宽松不等于技术的易用。作者整篇博客的核心是在讲"怎么让它跑起来"——从显存计算到代码补丁，从prompt redesign到标签掩码。这些 friction 不会因为协议变宽松而消失，反而因为模型能力变强而变得更隐蔽、更难以调试。

对从业者的实用判断

如果你正在评估Gemma 4的落地路径，这篇实战笔记提供了几个硬参考：

第一，96GB显存是31B模型的入场券，但不是舒适区。你的训练脚本必须精打细算，任何内存泄漏或缓存冗余都会导致OOM（显存溢出）。LoRA几乎是必选项，全参数微调在这个硬件配置下不现实。

第二，"推理优化"和"微调友好"之间存在张力。Gemma 4为Agent场景设计的系统指令、函数调用、JSON输出，在简单分类任务里反而需要额外处理来"压制"或"引导"。不是所有任务都需要模型的全部能力，但屏蔽不需要的能力需要技巧。

第三，无服务器GPU的计费模型适合实验性工作负载，不适合大规模训练。作者没有披露成本，但Cloud Run Jobs的GPU实例按秒计费，长时间训练的费用会迅速累积。对于生产级微调，Reserved实例或自建集群可能更经济。

最后，MoE架构的26B版本可能是被低估的选项。排行榜第六名的成绩、3.8B激活参数的轻量推理、潜在的更低微调成本——这些组合对于资源受限的团队更具吸引力。但作者没有提供这个版本的完整微调记录，留下一个待验证的假设。

谷歌把Gemma 4的定位从"开源模型"推向了"开源产品"——Apache 2.0是产品化的法律基础，函数调用和结构化输出是产品化的功能基础，Cloud Run的无服务器GPU是产品化的基础设施。但产品化的最后一环，是有人能把这些拼图真正拼起来跑通业务。这篇博客的价值，正在于展示了拼图过程中的具体卡点，以及绕过它们所需的工程判断。