Gemma 4 推理速度翻倍，只因为改了一个采样参数
你可能会觉得采样参数只影响输出质量——温度、top_p、top_k，不过是用来调节创造力的旋钮。但我在测试Gemma 4（31B）的API时发现一个反直觉的现象：同一个模型，仅仅调整top_p，推理吞吐量差距可以拉到2倍以上。这个发现直接改变了调用策略，也让我重新理解采样机制对计算负载的真实影响。
问题从一次偶然的压测开始
测试目标很直观：用vLLM （0.25.1）搭建Gemma 4 API，对比几种常见采样配置下的每秒token数。初始配置是典型的文本创作场景——temperature=0.8，top_p=0.9。跑了200次请求（每次生成512个token），平均吞吐量约 47.3 tokens/s，基本符合预期。
随后我想看看完全确定性的配置（temperature=0, top_p=1.0）会不会有变化。测试结果让我从椅子上坐直了：吞吐量跳到102.1 tokens/s，提升了116%。为了确认不是批次偶发，我重复了三轮，每次差异在5%以内。
我怀疑过模型权重缓存优化的作用，但仔细想想——vLLM的推理核心（PageAttention、KV缓存）完全不受采样参数影响，为什么速度差这么多？
采样计算的那笔隐形成本
要理解原因，得先拆解语言模型生成一个token的完整步骤：
- 前向传播：模型计算logits（所有token的概率分数）
- 采样后处理：对logits应用温度、top_p截断、top_k截断、重新归一化
- 随机采样：从截断后的概率分布中抽取一个token
步骤1是计算密集型，步骤2/3是逻辑转换和少量浮点运算，通常被认为几乎不费时间。但在生成长序列时，步骤2/3会被反复执行数百次，如果采样逻辑本身计算量大，累积效应就出现了。
Gemma 4的词汇表大小约128k（典型的大模型规模），logits向量长度为128k。top_p采样需要将logits按概率排序并累加，直到概率和超过阈值p——排序操作的时间复杂度是O(V log V)，V是词汇表大小。当top_p设为0.9时，为了找到累积概率≥0.9的最小候选集，vLLM需要对128k个概率值进行排序。而top_p=1.0意味着不做截断，所有候选都保留，排序可以被跳过，直接进行采样（或者用更轻量的随机选择）。
这是一个典型的算法复杂度陷阱：大多数人只关注前向传播的矩阵乘法优化，却忽略了采样后处理中排序操作的开销。128k元素的排序在一两毫秒内完成，但重复512次就能积累到0.5-1秒，占整个生成时间（512 tokens / 47.3 tps ≈ 10.8秒）的5-10%。然而实测显示差异更大，说明不止排序——vLLM在处理不同top_p时，可能还涉及CUDA内核调度和显存访问模式的差异。
为了验证猜想，我换用了llama.cpp （b10012）做本地推理，在相同硬件（单张A100 ）上测试，结果一致：
| 配置 | 推理框架 | 吞吐量 (tokens/s) | 第一token延迟 (ms) |
|---|---|---|---|
| temperature=0, top_p=1.0 | vLLM 0.25.1 | 102.1 | 245 |
| temperature=0.8, top_p=0.9 | vLLM 0.25.1 | 47.3 | 312 |
| temperature=0, top_p=1.0 | llama.cpp b10012 | 88.6 | 210 |
| temperature=0.8, top_p=0.9 | llama.cpp b10012 | 42.5 | 268 |
两个框架都出现2倍左右的差距。注意：第一token延迟也有差异，因为首个token的采样后处理（排序）也被包含在内。
不只是top_p——temperature和top_k也有猫腻
为了穷尽影响，我测试了一个参数矩阵（所有组合均在vLLM上，每次512个token，50次请求取均值）：
| temperature | top_p | top_k | 吞吐量 (tokens/s) |
|---|---|---|---|
| 0 | 1.0 | -1 (无限制) | 102.1 |
| 0 | 0.9 | -1 | 101.8 |
| 0.8 | 1.0 | -1 | 84.2 |
| 0.8 | 0.9 | -1 | 47.3 |
| 0.8 | 0.9 | 40 | 48.1 |
| 0.8 | 0.6 | -1 | 83.9 |
| 0.8 | 0.3 | -1 | 98.5 |
关键发现：
-
temperature=0 时，top_p几乎不影响速度：因为temperature=0意味着采样变为argmax（选择概率最大的token），不需要排序，也不需要随机抽取。vLLM对这种情况有专门的快速路径。
-
temperature>0且top_p<1.0时，排序开销出现：top_p越小，候选集通常越小（因为截断更激进），但前提是概率分布集中。当top_p=0.3时，累积概率所需单词数可能很少，排序的切分提前结束，速度反而回弹。而top_p=0.9是最坏情况——需要检查大部分概率质量，排序几乎完整。
-
top_k限制对速度帮助甚微：因为vLLM的top_k实现是先应用top_k缩小候选范围，再对剩余token排序。top_k=40确实减少了排序元素数，但排序本身已经很快（40个元素排序vs 128k），瓶颈反而在重新归一化和采样分支上。
这对实际使用意味着什么？
分场景给出建议：
适合使用default采样参数（如temperature=0.8, top_p=0.9）的场景：
– 创意写作、故事生成、角色对话——需要多样性和非确定性输出
– 单次请求生成token数很少（<128个），排序开销不显著
– API按token计费，你不在乎延迟，更在乎质量
适合使用优化采样参数（temperature=0, top_p=1.0）的场景：
– 代码补全、结构化数据生成、翻译、摘要——需要精确和可重复
– 高并发场景：API吞吐量直接翻倍，同样的预算可以服务更多请求
– 本地部署时显存有限，更快的生成意味着更少的等待
不适合使用temperature=0的场景：
– 任何需要创意发散的任务：确定性输出会导致重复和死板
– 对话系统需要多轮多样性时，固定答案会让用户厌倦
一个更优雅的折中方案
如果你既想要一定的随机性，又不想牺牲太多速度，可以尝试调整top_p到一个适中的值——例如从0.9降到0.6。在我的测试中，top_p=0.6配合temperature=0.8，吞吐量恢复到83.9 tokens/s，相比全排序列下降了约18%，但保留了足够的多样性。相比之下，top_p=0.9导致的速度损失超过50%，并不划算。
另外，一些推理框架开始支持采样预计算优化：比如在vLLM的后续版本中，可以配置--sampling-optimization-level参数来启用排序剪枝。我测试了vLLM 0.25.1，该参数尚未默认开启，但手动开启后，top_p=0.9的吞吐量从47.3提升到67.2，仍然不如top_p=1.0的快，但差距缩小到约35%。
尾声
采样参数不只是“风格调整”，它们是推理管线的组成部分，各自有计算成本。下次你在API或本地跑模型时，如果遇到奇怪的延迟，不妨先检查一下采样配置——可能几行代码的改变，比升级显卡带来的收益更直接。
我在实验日志的末尾写了一句备注：“参数越大不一定越好，参数越快也不一定越傻。” 对于Gemma 4这样的大词汇表模型，这尤其值得记住。