关键词： Gemma 4、gpt-oss-20b、MoE、Dense、llama.cpp、vLLM、GGUF、单卡部署、长上下文、并发测试、L20 48GB
先看结论
- 如果你最关心单卡 48GB 下的吞吐、并发和显存余量，当前测试里最均衡的选择是 Gemma 4 26B A4B + llama.cpp GGUF。
- 如果你更在意 OpenAI 兼容工作流、harmony format 和工具调用生态，gpt-oss-20b + vLLM 会更顺手。
- 如果你更看重公开 benchmark 上略高一些的理论上限，并且能接受明显更低的吞吐，Gemma 4 31B Dense + llama.cpp GGUF 更合适。
- 文中
tps如无特别说明，均指 completion decode 吞吐，不包含 prompt prefill 的处理速率。 - 文中性能、显存、冷热启动数据均来自实测；
MMLU Pro、AIME 2026属于公开 benchmark 数据，用来辅助理解模型定位，不是本文重新复现的结果。
背景
2026 年 Q1-Q2 密集发布了多个高质量开源模型。对于做本地推理和私有化部署的团队来说，最核心的问题不是"谁的 benchmark 更高"，而是：
- 我手上的单卡 48GB 能不能跑起来？
- 能跑的话，能支撑多少并发？
- 长上下文场景下的真实吞吐是多少？
- 不同推理引擎之间有没有兼容性坑？
本文尝试用同一台服务器、同系列显卡、同一套压测脚本，对三个模型做一次尽量公平的横向对比。
测试对象
| 模型 | 架构 | 参数规模 | 权重格式 | 权重体积 | 推理引擎 |
|---|---|---|---|---|---|
| Gemma 4 26B A4B IT | MoE（128 experts, 8 active + 1 shared） | 25.2B total / 3.8B active | GGUF UD-Q8_K_XL | 27.9GB | llama.cpp |
| Gemma 4 31B IT | Dense | 30.7B | GGUF UD-Q8_K_XL | 35GB | llama.cpp |
| gpt-oss-20b | MoE（32 experts, 4 active） | 21B total / 3.6B active | MXFP4（原始权重） | ~16GB | vLLM |
三个模型覆盖了两种 MoE 和一种 Dense 架构，权重格式也不相同（GGUF Q8 vs MXFP4），推理引擎也不一样（llama.cpp vs vLLM）。这种差异是有意保留的------真实部署中你不可能让所有模型都跑在同一个引擎上，兼容性本身就是部署成本的一部分。
测试环境
- GPU：NVIDIA L20 48GB（单卡，每个模型独占一张）
- 操作系统：Ubuntu 22.04
- CUDA：12.2
- llama.cpp：从源码编译最新版（支持
gemma4架构需要 2026 年 4 月以后的版本） - vLLM：
vllm-cu122:0.13.0（Docker） - 压测脚本：自研 Python 脚本，并发发送长上下文 RAG 风格请求，记录延迟和吞吐
部署踩坑记录
在测试之前，三个模型的部署过程本身就暴露了不少工程问题。
gpt-oss-20b：vLLM 兼容性
官方模型卡给出的是定制版 vllm==0.10.1+gptoss（依赖 CUDA 12.8），但实测 vllm-cu122:0.13.0 可以正常运行。说明 gpt-oss-20b 的架构支持已经在 vLLM 0.13.0 中合入主线。
结论：不需要单独构建定制镜像。
Gemma 4：推理引擎兼容性是最大的坑
Gemma 4 是 2026 年 4 月初刚发布的模型，推理引擎生态尚未完全跟上。实测结果：
sglang 0.5.10：
- 无
Gemma4ForConditionalGeneration原生实现 - 回退到 Transformers backend 后因 MoE
top_k配置无法解析而崩溃 - 且 sglang 0.5.10 锁定
transformers==5.3.0，而gemma4架构需要更新版本，升级 transformers 又会破坏 sglang 的依赖约束
llama.cpp：
- 旧版本不支持
gemma4架构（报unknown model architecture: 'gemma4'） - 需要拉取最新源码重新编译
- 编译完成后即可正常运行
结论：Gemma 4 目前只能走 llama.cpp GGUF 路线。 这也是 Unsloth 社区第一时间提供 GGUF 量化的原因------GGUF 不依赖 Python 生态，绕开了 transformers 版本兼容性问题。
一个容易被忽视的点：更新 llama.cpp 不影响已在运行的服务
如果服务器上已经有旧版 llama.cpp 在跑其他模型（比如 Qwen3.5），新版编译可以放在独立目录（如 llama.cpp-master），不会影响正在运行的进程。Linux 下正在运行的进程持有旧二进制的引用，覆盖文件不会中断它。
显存占用对比
三个模型在各自最佳配置下的显存占用：
| 模型 | 权重体积 | 配置 | 显存峰值 | 48GB 卡余量 |
|---|---|---|---|---|
| Gemma 4 26B A4B | 27.9GB | 64K x 4 并发 | 33730MiB (~33.7GB) | ~14.3GB |
| gpt-oss-20b | ~16GB | 32K x 4 并发 | 41568MiB (~41.6GB) | ~4.4GB |
| Gemma 4 31B Dense | 35GB | 32K x 2 并发 | 41918MiB (~41.9GB) | ~4.1GB |
最值得关注的发现：Gemma 4 26B A4B 的权重虽然有 27.9GB，但在 64K x 4 并发下总显存占用只有 33.7GB------比 gpt-oss-20b 在 32K x 4 下的 41.6GB 还少了近 8GB。
原因在于 KV cache 压力：
- Gemma 4 26B A4B：30 层，8 KV heads，MoE 架构下 KV cache 极其轻量
- gpt-oss-20b：虽然 MXFP4 权重只有 ~16GB，但 vLLM 的显存管理策略（
--gpu-memory-utilization 0.90）会预分配大量 KV cache 空间
这说明权重体积和最终显存占用之间不是简单的线性关系，KV cache 的结构和推理引擎的显存管理策略同样重要。
长上下文并发吞吐对比
这是本文最核心的数据。所有测试均使用同一套压测脚本，发送中文为主的 RAG 风格长上下文请求。
这里先说明一下统计口径：下表里的 单路 tps 和 合计 tps，均按 completion tokens / elapsed time 计算，主要反映 decode 阶段的输出吞吐，不等同于整条请求的总 token 吞吐。
各模型最佳配置下的热态表现
| 模型 | 引擎 | 上下文 x 并发 | prompt tokens | 热态总耗时 | 单路 tps | 合计 tps |
|---|---|---|---|---|---|---|
| Gemma 4 26B A4B | llama.cpp | 64K x 4 | 65366 | 3.26s | ~39.4 | ~157 |
| gpt-oss-20b | vLLM | 32K x 4 | 32337 | 4.61s | ~28.1 | ~112 |
| Gemma 4 31B Dense | llama.cpp | 32K x 2 | 29488 | 8.46s | ~15.2 | ~30 |
接近 32K prompt 的参考对比
由于三个模型的上下文窗口和并发配置不同，上面的数据更多反映"各自最佳配置下的能力上限"。为了给读者一个更接近 32K prompt 场景的参考，这里补充 gpt-oss-20b 和 Gemma 4 31B 在接近 32K prompt 下的数据：
| 模型 | prompt tokens | 并发 | 热态总耗时 | 单路 tps | 合计 tps |
|---|---|---|---|---|---|
| gpt-oss-20b | 32337 | 4 | 4.61s | ~28.1 | ~112 |
| Gemma 4 31B Dense | 29488 | 2 | 8.46s | ~15.2 | ~30 |
Gemma 4 26B A4B 这次没有单独补做 32K prompt 测试，因此这里不把它强行放进"同口径对比"表中。现有结果能说明它在 64K x 4 下依然保持很强的吞吐和显存效率，但如果要做严格横评，后续仍建议补一组 32K 标准化测试。
并发均匀性
三个模型的一个共同特点是：多路并发的耗时差异极小。
- Gemma 4 26B A4B（4 路）：3.24s ~ 3.26s，最大差异 0.02s
- gpt-oss-20b（4 路）：4.53s ~ 4.59s，最大差异 0.06s
- Gemma 4 31B Dense（2 路）：8.40s ~ 8.45s，最大差异 0.05s
这说明无论是 llama.cpp 的 slot 机制还是 vLLM 的 continuous batching，在当前负载下都没有出现明显的排队或资源争抢。
冷启动 vs 热启动
这是很多人在做本地部署时容易忽视的维度。
| 模型 | 冷启动 | 热态 | 差距倍数 |
|---|---|---|---|
| Gemma 4 26B A4B | 85.10s | 3.26s | ~26x |
| Gemma 4 31B Dense | 80.57s | 8.46s | ~9.5x |
| gpt-oss-20b | 未采集 | 4.61s | - |
冷启动延迟的主要来源：
- CUDA kernel 首次编译和初始化
- KV cache 和 runtime buffer 的首次分配
- 长上下文 prefill 的首轮开销
- 操作系统文件缓存预热
工程建议：对于任何需要长期服务化的模型，务必在服务启动后发送预热请求，再挂入正式流量。尤其是使用 systemd 做定时重启的场景，warm-up 步骤不可省略。
Tokenizer 效率对比
不同模型的 tokenizer 对中文的压缩效率差异明显，这直接影响"多少字符能塞进多大的上下文窗口"。
| 模型 | 字符/token | 说明 |
|---|---|---|
| Qwen3.5 系列 | ~1.6-1.7 | 中文压缩效率最高 |
| Gemma 4 | ~1.53 | 介于 Qwen 和 gpt-oss 之间 |
| gpt-oss-20b | ~1.40 | 中文压缩效率最低 |
实际影响：同样 32K token 的上下文窗口，Qwen 能塞进约 54K 字符的中文内容，而 gpt-oss-20b 只能塞进约 45K 字符。在中文 RAG 场景下，这个差异不可忽视。
MoE vs Dense：真实部署下的差距有多大
Gemma 4 同时提供了 26B A4B（MoE）和 31B（Dense）两个版本，这给了我们一个难得的机会在同模型家族、同硬件上直接对比两种架构。
| 维度 | 26B A4B (MoE) | 31B Dense | MoE 优势 |
|---|---|---|---|
| 并发能力 | 64K x 4 | 32K x 2 | 4x 并发，2x 上下文 |
| 合计吞吐 | ~157 tps | ~30 tps | 5.2x |
| 显存余量 | ~14GB | ~4GB | 3.5x |
| 单路 tps | ~39.4 | ~15.2 | 2.6x |
| MMLU Pro（公开 benchmark） | 82.6% | 85.2% | Dense +2.6% |
31B Dense 在公开 benchmark 上略占优（例如 MMLU Pro +2.6%，AIME 2026 +0.9%），但代价是吞吐降为约 1/5、并发能力减半、显存余量从 14GB 缩到 4GB。
在实际在线服务场景里，这部分质量优势能否稳定转化为业务收益，要看任务类型；而吞吐和并发的差距，往往会更直接地影响响应体验和服务成本。
选型建议
基于以上实测数据，给出以下选型建议：
如果你追求单卡最强吞吐和并发
选 Gemma 4 26B A4B + llama.cpp GGUF
- 64K x 4 并发，合计 ~157 tps
- 显存仅占 33.7GB，48GB 卡上余量充足
- 当前测试路径下，文本推理性能和长上下文并发表现最突出
- 模型原生支持多模态（文本 + 图片）和 function calling，但本文没有单独展开验证 llama.cpp 下这两项能力
- 缺点：需要最新版 llama.cpp，sglang / vLLM 暂未适配到可直接使用的状态
如果你需要 harmony format 或 OpenAI 原生生态
选 gpt-oss-20b + vLLM
- 32K x 4 并发，合计 ~112 tps
- 原生支持 harmony format、configurable reasoning、function calling、structured outputs
- Docker 部署，与宿主机环境完全隔离
- 缺点：显存占用偏高（41.6GB），余量较小
如果你对推理质量有极致要求
选 Gemma 4 31B Dense + llama.cpp GGUF
- 32K x 2 并发，合计 ~30 tps
- 公开 benchmark 上的理论成绩更高，Gemma 4 家族里更偏向质量优先路线
- 缺点：吞吐低、并发少、显存紧张，更适合离线分析或低并发高质量场景
总结
| 模型 | 一句话定位 |
|---|---|
| Gemma 4 26B A4B | 在本文测试条件下，单卡 48GB 场景里吞吐、并发、显存占用最均衡的选择 |
| gpt-oss-20b | 如果你需要 harmony format 和 OpenAI 兼容工作流，它是更顺手的选择 |
| Gemma 4 31B Dense | 更偏向质量优先路线，适合对速度不敏感、对效果更苛刻的场景 |
写到最后还是想强调一点：模型选型不应该只看 benchmark 分数。在真实部署中，推理引擎兼容性、显存管理策略、tokenizer 效率、冷启动延迟这些"看不见的成本"，往往才是决定一个模型能不能真正上线的关键因素。
测试日期：2026 年 4 月 7 日
声明：本文所有数据均基于特定硬件和软件版本的实测结果，不同环境下的表现可能有所差异。文中涉及的所有模型均为 Apache-2.0 开源许可。