部署Gemma 4之前，我的AI推理平台NeuroScale已经跑了108次提交、21轮冒烟测试、6次里程碑复盘。开发者填个Backstage表单，系统自动生成KServe配置，ArgoCD完成部署，生产环境就绪。这套流程对Dense模型和标准MoE都适用——直到Gemma 4出现。
资源请求表单上的数字看起来毫无异常：一个250亿参数的模型，按惯例申请48GB显存。但实际跑起来完全不对账：GPU计算利用率卡在40%，p95延迟翻倍，OpenCost按相同费率向两个团队计费，可他们的实际单token成本差了整整两倍。所有异常指向同一个源头——Gemma 4的架构设计打破了平台对MoE的既有假设。
三条路径并行的"异类"MoE
标准MoE（Mixtral、DeepSeek、Qwen）的做法很一致：用稀疏专家替换Dense FFN，路由层每token挑几个专家激活，Dense路径彻底消失。Gemma 4 26B不走这条路——它同时运行三条路径：
输入 → Attention → 分叉为Dense FFN（常开）、Shared Expert（常开）、Router（从128个专家中激活8个）→ 三者输出相加 → 输出。
总计约252亿参数，每token激活约38亿。活跃参数占比0.15，低于Mixtral 8x7B的0.28，也低于DeepSeek-V2的0.09（后者总参数量级完全不同）。这个比例是30B以下MoE中最低的，因为常开的Dense FFN和Shared Expert吃掉了参数预算，却不计入"活跃参数"。
Google的设计意图很明显：Dense FFN是结构性安全网，路由选错专家时，常开路径兜底信号。这解释了为什么Gemma 4量化后仍稳定运行、训练过程更平滑。但对平台工程师而言，"内存中的参数"与"实际参与计算的参数"之间的裂隙，比任何同规模MoE都宽。
裂隙击穿的三处平台假设
成本归因失效。NeuroScale强制要求InferenceService打成本中心标签，Kyverno拦截无标签部署，OpenCost按标签归集GPU小时。但Gemma 4的计费单位变得可疑：相同硬件上，两个团队的请求模式不同，实际单token成本可能差两倍，账单却显示相同费率。
容量规划失真。平台按"活跃参数×批大小"估算吞吐，Gemma 4的常开路径让这套公式低估内存压力、高估计算效率。48GB显存确实能装下模型，但40%的GPU利用率说明内存带宽和计算单元没对齐——Dense FFN和Shared Expert在每次前向传播中全量参与，却不贡献到"活跃参数"的直觉预期里。
延迟预算失控。p95延迟翻倍不是因为吞吐饱和，而是三条路径的同步累加开销。标准MoE的路由开销可预测，Gemma 4的"三路径求和"让延迟分布出现新的尾部。
测量数据一览
H100吞吐测试基于JarvisLabs SPEED-Bench（vLLM 0.8.5），显存占用在A6000 BF16环境下控制变量，API定价参照Google Cloud Vertex AI。复现命令：vllm serve google/gemma-4-27b-it --tensor-parallel-size 1 --max-model-len 8192。
关键发现：同等硬件条件下，Gemma 4的吞吐-延迟曲线与参数规模相近的Dense模型完全不同，却与激活参数规模差异巨大的标准MoE也不重合。它自成一类。
平台工程师的应对
NeuroScale正在调整资源模型：显存申请不再绑定"总参数量"，而是拆分"常驻内存"（Dense FFN + Shared Expert + 全部专家权重）与"激活内存"（当前token的专家缓存）。成本标签增加"请求模式"维度，区分高并发短序列与低并发长序列。延迟SLO按路径组合重新建模，而非单一P90阈值。
Gemma 4不是更好的MoE，是另一种东西。它用架构冗余换取训练稳定性和量化鲁棒性，把复杂性转嫁给下游平台。下次有人再拿"活跃参数占比"做容量规划，先问清楚：那占比里，有没有把常开路径算进去？
热门跟贴