前言

谷歌（Google）在月初发布了Gemma4系列开放模型，原生支持多模态输入和工具调用能力。经过本人最近几天测试下来发现 google/gemma-4-31B-it和 google/gemma-4-26B-A4B-it这两个模型非常具有潜力，在一些逻辑测试和编码测试（例如：接入claude code 写代码和修bug）中都表现得不错。并且部署成本也相对不那么高，在一些消费级的设备上也能运行，所以我打算对这两个模型做一下深度分析和压力测试。

模型架构对比

模型名称	架构	参数量	激活参数	权重大小	运行机制
gemma-4-31B-it	Dense Model（稠密模型）	310亿	全量激活	～62.58GB	每一个输入 Token 都会激活模型中的所有参数。
gemma-4-26B-A4B	MoE Model （混合专家模型）	260亿	40亿	～51.64GB	模型包含一个门控网络（Gating Network / Router）和多个专家网络（Experts）。对于每个输入 Token，门控网络会实时判断，只将其发送给 1-2 个最相关的“专家”进行处理。

逻辑测试

洗车问题

对于前段时间AI圈很火的洗车问题，这两款模型也能给出相对合理的答案。

• gemma-4-31B-it

可以看出gemma-4-31B-it对于这个问题的思考时间很短，回答的也很简短。

• gemma-4-26B-A4B-it

可以看到gemma-4-26B-A4B-it 会分析你的目的，可以说考虑的很周全。

竹竿过门问题

这道题考验的是模型对于现实三维空间的理解，可以测出模型是不是只会刷题，但是不会考虑实际情况。

• gemma-4-31B-it

• gemma-4-26B-A4B-it

压力测试

GPU与软件规格

• H20-96G x 1

• vLLM v0.19.1

• CUDA Version: 12.8

服务启动参数

维度	参数名称	解释	实战建议
基础架构	--tensor-parallel-size	张量并行组数量。将模型参数横向切分到多张 GPU 上并行计算。	必须等于或能整除实际使用的 GPU 数量。
	--trust-remote-code	信任远程代码。允许执行模型权重自带的自定义层逻辑。	加载某些模型时必须开启。
显存管理	--gpu-memory-utilization	GPU 显存利用率 (0~1)。vLLM 启动时预占用的显存比例。	默认 0.9。若有其他进程或监控，建议调低至 0.85 避免 OOM。
	--kv-cache-dtype	KV 缓存数据类型（如 auto, fp8）。存储对话历史的精度。	设置为 fp8 可显著提升并发量，但需显卡硬件支持。
	--enable-prefix-caching	启用前缀缓存。自动缓存公共 Prompt 前缀的计算结果。	多轮对话必备。能极大降低后续对话的首字延迟（TTFT）。
性能调优	--max-model-len	最大上下文长度。定义 Input 和 Output 的 Token 总和上限。	显存不足时的“保命”手段，调小此值可直接降低显存压力。
	--max-num-seqs	最大并发序列数。单次迭代中系统处理的最大请求个数。	决定吞吐量上限。值越大吞吐越高，但单个用户的延迟可能增加。
	--max-num-batched-tokens	单次最大批处理 Token 数。控制预填充阶段的计算强度。	默认通常为 2048。增大此值可加速长文本处理，但更吃显存。
	--enable-chunked-prefill	分块预填充。将长 Prompt 切碎分次处理，防止“大任务”卡死“小任务”。	推荐开启。能有效缓解长文本输入导致的服务卡顿（Jitter）。
	--async-scheduling	异步调度。允许调度引擎与 GPU 计算并行执行，减少间隙。	默认开启。保持高 GPU 利用率的核心，除非调试否则不建议关闭。
多模态	--limit-mm-per-prompt	多模态输入上限。限制单个 Prompt 允许包含的图片/视频/音频数量。	防止用户输入过多多媒体素材导致显存瞬时爆掉。

测试关键指标

指标	全称	含义	决定因素
TTFT	Time to First Token	首字延迟：从发送请求到看到第一个字跳出来的时间。	Prefill（预填充）阶段的计算速度。
TPOT	Time Per Output Token	生成延迟：第一个字出来后，后续每个字产生的平均速度。	Decoding（解码）阶段的计算速度。
TPS	Token Per Second	吞吐量：每秒所产生的Token	显存带宽 (Memory Bandwidth)、算力利用率 (FLOPS)、模型规模

启动命令

• 基础命令

vllm serve google/gemma-4-31B-it \ 
  --tensor-parallel-size 1 \
  --max-model-len 32768 \
  --no-enable-prefix-caching \
  --limit-mm-per-prompt '{"image": 0, "audio": 0}' \
  --async-scheduling

• gemma-4-31B-it

vllm serve google/gemma-4-31B-it \
  --tensor-parallel-size 1 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.95 \
  --enable-chunked-prefill \
  --max-num-batched-tokens 8196 \
  --enable-prefix-caching \
  --limit-mm-per-prompt '{"image": 0, "audio": 0}' \
  --async-scheduling \
  --kv-cache-dtype fp8 \
  --max-num-seqs 8 \
  --trust-remote-code

• gemma-4-26B-A4B-it

vllm serve google/gemma-4-26B-A4B-it \
  --tensor-parallel-size 1 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.95 \
  --enable-chunked-prefill \
  --max-num-batched-tokens 8196 \
  --enable-prefix-caching \
  --limit-mm-per-prompt '{"image": 0, "audio": 0}' \
  --async-scheduling \
  --kv-cache-dtype fp8 \
  --max-num-seqs 8 \
  --trust-remote-code

这上面的启动服务命令参数是本人经过反复在H20上测试，得出的比较好的模型服务启动参数，具体办法就是在最基础的启动命令上加一些优化的参数使得TTFT和TPOT降低。

测试命令

# Prompt-heavy benchmark (8k input / 1k output)
vllm bench serve \
  --model google/gemma-4-31B-it \ # 测试模型名称
  --dataset-name random \ # 要进行基准测试的数据集的名称。
  --random-input-len 8000 \ # 输入token长度
  --random-output-len 1000 \ # 输出token长度
  --request-rate 1 \ # 最大并发请求数。
  --num-prompts 16 \ # 请求次数
  --ignore-eos # 忽略eos标志，直到输出上述要求的--random-output-len 长度

测试结果

关键指标	Dense 模型 (gemma-4-31B-it)	MoE 模型 (gemma-4-26B-A4B-it)	性能倍率 (MoE vs Dense)
请求吞吐量 (Request/s)	0.13 req/s	0.47 req/s	~3.6x
输出 Token 吞吐量 (tok/s)	131.14 tok/s	469.77 tok/s	~3.6x
总 Token 吞吐量 (tok/s)	1180.22 tok/s	4227.97 tok/s	~3.6x
平均首字延迟 (Mean TTFT)	30931.34 ms (30.9s)	2321.20 ms (2.3s)	~13.3x 提速
平均每字延迟 (Mean TPOT)	82.35 ms	13.37 ms	~6.1x 提速
峰值输出吞吐量	336.00 tok/s	744.00 tok/s	~2.2x
P99 TPOT (长尾延迟)	115.58 ms	15.61 ms	~7.4x 提速

结论

本文主要介绍了Gemma4系列的两个模型，一个是Dense模型gemma4-31B-it，另一个是MoE模型gemma4-26B-A4B。还介绍了vLLM框架在部署模型服务时的一些关键参数和一些关键性能指标，以及如何使用vLLM框架对这两个进行基准测试。从最终的测试结果来看，MoE 架构的 gemma-4-26B-A4B-it 在如 H20 这种拥有 96GB 大显存 但 算力（TFLOPS）受限 的显卡上表现异常惊艳。

在传统的 Dense 模型中，每一层计算都需要动用全部 31B 参数，这让 H20 相对孱弱的计算核心不堪重负，导致了我们最初看到的 30.9 秒首字延迟。而 MoE 模型虽然总参数量高达 26B（占用显存大），但每次推理仅激活约 4B 的专家参数。虽然 H20 通常被归类为“降级版”的数据中心卡，但它表现出的“大显存、低算力”特征，恰恰是未来高性能端侧设备（如高端 AI PC、一体机、甚至未来的移动工作站）的缩影。Gemma4系列的这两个模型让我们看agentic 模型在端侧设备上运行的可能，在模型厂商的coding plan 越来越难买和越来越贵情况下，本地部署它们或许是个不错的选择。

谢谢收看，希望这篇文章对你有用～

参考链接

Gemma 4 Usage Guide

vllm bench serve

vllm serve