Gemma-4-31B-it 在 DGX Spark 上的性能测试结果

以下是Gemma-4-31B-IT 在 DGX Spark 上的性能测试结果数据来自 2026 年 4 月 2 日模型发布当天NVIDIA 开发者论坛发布的初步基准测试。️ 测试硬件环境规格数值架构Grace Blackwell SuperchipGB10统一内存122 GB LPDDR5X内存带宽~273 GB/s平台Ubuntu 24.04, aarch64CUDA13.0驱动 580.142部署使用官方 Docker 镜像vllm/vllm-openai:gemma4-cu130上下文窗口配置为 256K tokens262144KV cache 类型为 fp8。 测试模型对比模型量化方式磁盘大小gemma-4-31B-itbf16~62 GBgemma-4-31B-it-AWQ-8bitint8~33 GBgemma-4-31B-it-AWQ-4bitint4~20 GBgemma-4-26B-A4B-itMoEbf16~49 GB⚡ Prompt 处理吞吐量t/s越高越好模型pp128pp512pp204831B bf16244 ± 46757 ± 671066 ± 4831B AWQ int8267 ± 26399 ± 33430 ± 031B AWQ int4545 ± 104778 ± 39810 ± 226B-A4B MoE429 ± 1651299 ± 4413105 ± 372 Token 生成解码吞吐量t/s越高越好模型tg128峰值31B bf163.7 ± 0.14.031B AWQ int86.5 ± 0.17.031B AWQ int410.6 ± 0.011.026B-A4B MoE23.7 ± 0.024.0⏱️ 首次响应时间ms越低越好模型TTFR pp128TTFR pp512TTFR pp204831B bf16547 ± 91686 ± 641929 ± 8931B AWQ int8490 ± 511297 ± 1084761 ± 231B AWQ int4247 ± 46664 ± 332533 ± 826B-A4B MoE371 ± 176464 ± 197672 ± 82本地实测部署参数4并发70%显存占用参数含义--model /home/admin/models/modelscope/gemma-4-31B-it模型路径指定 Gemma 4 31B 指令微调版的位置--served-model-name gemma-4-31b对外暴露的模型名称API 调用时使用的标识名--enable-auto-tool-choice启用自动工具选择让模型自动决定是否调用工具--tool-call-parser pythonic工具调用解析器格式使用 Python 风格的工具调用格式--reasoning-parser gemma4推理解析器专门用于解析 Gemma 4 模型的推理输出格式--gpu-memory-utilization 0.70GPU 内存使用率上限限制使用 70% 的显存预留空间给其他进程--host 0.0.0.0监听地址绑定到所有网络接口允许外部访问--port 30000服务端口容器内部监听端口与 Docker 映射的 30000 对应--kv-cache-dtype fp8KV 缓存数据类型使用 8 位浮点量化减少显存占用--load-format safetensors模型加载格式使用 SafeTensors 格式更安全、加载更快--enable-prefix-caching启用前缀缓存对相同前缀的输入复用 KV 缓存加速推理--enable-chunked-prefill启用分块预填充将长输入分块处理减少显存峰值占用--max-model-len 262144最大上下文长度支持 262,144 tokens约 20 万字--max-num-seqs 4最大并发序列数同时处理 4 个请求序列--max-num-batched-tokens 8192最大批处理 token 数每个批次最多处理 8192 个 token 关键分析31B是稠密模型属性E2BE4B31B 稠密总参数量2.3B 有效参数含嵌入层共 5.1B4.5B 有效参数含嵌入层共 8B30.7B层数354260滑动窗口大小512 个 token512 个 token1024 个 token上下文长度128K 个 token128K 个 token256K 个 token词表大小262K262K262K支持的模态文本、图像、音频文本、图像、音频文本、图像视觉编码器参数量~1.5 亿~1.5 亿~5.5 亿音频编码器参数量~3 亿~3 亿不支持音频解码受限于内存带宽在 DGX Spark 上单用户 Token 生成受限于内存带宽。理论值与实测值对比如下31B bf16273 GB/s ÷ 62 GB ≈ 4.4 t/s实测 3.7 t/s效率 84%31B int8≈ 8.8 t/s实测 6.5 t/s效率 74%31B int4≈ 17.0 t/s实测 10.6 t/s效率 62%26B-A4B MoE≈ 34.0 t/s实测 23.7 t/s效率 70%MoE 的结构性优势MoE 模型解码优势来自其架构特性尽管 49 GB 的专家权重全部驻留在显存中每个 Token 生成时只需读取 4B 激活参数解码吞吐量比 dense bf16 基准高 6.4 倍比 AWQ int4 高 2.2 倍。31B AWQ int4 是 dense 模型的最佳选择对于需要完整 31B dense 模型质量的场景AWQ int4 是最优选择解码速度 10.6 t/s约为 bf16 基准的 3 倍短提示首次响应时间最低247 ms且仅占用 20 GB 磁盘为 256K 上下文留出充裕的 KV 缓存空间。 总结建议对于交互式和 Agentic 工作负载26B-A4B MoE 是 DGX Spark 上的明确赢家最快解码速度23.7 t/s、长上下文下最佳 Prompt 处理速度pp2048 达 3105 t/s、首次响应时间也具有竞争力。LPDDR5X 统一内存架构在限制 dense 模型的同时反而有利于 MoE 设计——每个 Token 只需流式读取 4B 激活参数。⚠️注意这是 2026 年 4 月 2 日模型发布当天的初步快照随着 vLLM 内核成熟、量化方案优化和服务参数调整数字会持续改善。