企业官网建设流程全解析

如果你是在搜索引擎里搜“采样”这个词误入这篇文章的，我先帮你把概念边界划清楚：搜“vllm采样”时，经常会混进来ADC采样、电流采样、下采样、带通采样定理这类信号处理领域的内容，那些是硬件采样的概念，跟vLLM里的采样完全是两码事。vLLM是做大模型推理服务的，这里的“采样”指的是模型生成下一个token时，从词表的概率分布里抽取候选词的过程。采样与解码参数，就是决定这个抽取过程怎么抽、抽完怎么选、选完怎么停的一组开关。

这个系列已经写到第5篇。前面几篇聊过部署、量化、性能调优和服务化，这一篇把直接影响生成质量的采样与解码参数单独拎出来讲透。适合已经能在vLLM上把模型跑起来、但对参数配置还停留在“照着抄”阶段的开发者。

我自己刚开始用vLLM时经历过一个很典型的困惑：模型部署好了，API也通了，prompt一个字没改，但两次请求返回的内容时而稳定时而跳跃，甚至出现大段重复文本。当时一度怀疑是模型有问题，后来才反应过来，问题出在参数配置上。vLLM作为服务化推理框架，参数控制的位置、粒度、生效方式和HuggingFace Transformers的单机脚本完全不一样，这恰恰是很多人容易踩坑的地方。

1. 为什么说采样与解码参数是“输出整形器”

1.1 “采样”这个词在vLLM里的真实含义

在大模型推理里，模型每次前向计算会输出一个词表大小的logits向量，经过softmax之后变成一个概率分布，然后从分布里抽出一个token，这就是一次采样。vLLM里的“采样”就是指这个环节，跟信号处理里把连续信号变成离散点的采样毫无关系。

可以近似理解成：模型是一个极其庞大的“推荐系统”，词表里每个token都有个得分，采样参数决定了你把所有推荐词都看一遍再随机挑，还是只盯着排名最高的几个选。很多做嵌入式或者硬件背景的开发者第一次接触vLLM，会下意识把“采样”理解成“数据采集”，比如ADC采样、电流采样那套，然后开始找采样率、采样深度之类的参数，结果发现对不上。所以开篇先把这个概念理清楚，后面聊参数才不容易跑偏。

1.2 参数决定的是“模型的说话方式”

同一份prompt，temperature=0和temperature=0.8输出结果可能差异巨大。这不是模型不稳定，而是解码策略本身就是概率性的——它天生允许“同一问题不同答案”。

举一个实际例子。我在测试Qwen2.5-7B-Instruct的时候，prompt是“给我写一封请假邮件”。temperature=0时，模型每次都输出几乎一样的内容，措辞严谨但略死板；temperature=0.7时，两次输出的邮件开头可能分别是“尊敬的领导”和“您好”，正文详略也有差异。这个差异对闲聊、文案类任务可能是优点，但对代码生成、JSON抽取这类任务就是灾难。

所以，采样与解码参数本质上是“输出整形器”：它们不改变模型的知识量，只改变模型把知识表达出来的方式。vLLM把这一整组参数封装成了SamplingParams对象，并且允许每个请求单独覆盖默认值——这是服务化框架和单机脚本最核心的设计差异。你不需要为不同业务线分别部署模型，只需要按请求传入不同的解码参数就行。

2. temperature、top_k、top_p：三个主流参数的数学直觉与配合方式

2.1 temperature：logits缩放带来的“冒险程度”

temperature是采样参数里最基础的一个。模型前向输出logits之后，softmax之前的logits会先除以temperature，再做归一化。公式长这样：

P(w) = softmax(logits / temperature)

举一个具体的数字例子。假设词表里只有三个候选token，logits是[2.0, 1.0, 0.5]，不同temperature下softmax后的概率分布如下：

temperature越小，logits被放得越大，分布越尖锐，最高分token的概率被进一步放大，模型输出越保守。temperature趋近0时，实际上就是选择logits最高的那个token，也就是贪心解码。temperature越大，分布越平坦，低分token也有机会被抽到，输出越发散。常用范围在0到1.5之间，超过1.5时输出质量通常会断崖式下降，因为模型开始“胡言乱语”。

这里有个常见误解：很多人以为temperature是“随机强度”，调大一点就是“多点随机性”。其实它只是缩放logits分布的形状，不引入任何额外随机源。temperature=0时是确定性解码，但只要大于0，即使设成0.1，也存在概率去选中非最高分的token，只是概率很低。

2.2 top_k和top_p：两套截断策略

top_k和top_p都是在采样前对候选词表做截断，目的是把概率很低的“垃圾词”排除在抽取范围之外。

• top_k是硬截断：只保留概率最高的K个token，其余全部排除。K=50是早年GPT时代的常用值，现在的模型词表更大、训练更充分，K=50基本够用，小模型或者词表特别杂的模型可以适当调小。
• top_p是软截断：从概率最高的token开始，不断把下一个token加进候选集，直到累积概率超过P。候选数量是动态的——分布越尖锐，候选越少；分布越平坦，候选越多。

可以这样理解：top_k像“只在大厂前三名里招人”，top_p像“先看候选人综合把握有多大，凑到九成把握就收手”。两者并不互斥，vLLM在同时设置时，采样器会先按top_k做硬截断，再在截断后的集合里按top_p做软截断。但工程上我一般只设一个，要么top_k，要么top_p，两个同时开反而增加了排查问题的维度。

2.3 组合选择：不是所有参数都必须同时用

很多框架默认同时开top_k和top_p，是为了兼容历史模型。但实际调参时，不应该把这一堆参数全都设上。temperature=0时top_k和top_p实际上失效，因为必然选argmax；temperature较高时，top_p设在0.9左右通常能挡住长尾噪声。

我常用的任务级配置组合如下：

这里面top_k=-1表示关闭，不同框架关闭方式不一样，vLLM里传0或-1都可以。

3. presence_penalty和frequency_penalty：专治复读机的惩罚机制

3.1 两种惩罚的计算逻辑差异

模型生成到一半经常会出现“车轱辘话来回说”的问题，比如摘要写到大段重复、对话回答中反复出现同一句。解决这个问题主要靠两个惩罚因子：presence_penalty和frequency_penalty。

两者的差异在统计口径上：

• presence_penalty：某个token只要在已生成序列中出现过，就施加一个固定大小的惩罚，与出现次数无关。它鼓励模型去开辟新话题，避免绕着同一个词打转。
• frequency_penalty：某个token出现的次数越多，惩罚越大。它对“高频重复词”有很强的压制力，适合处理反复出现同一长句的场景。

实际实现时，vLLM是在采样前的logits上做减法：对每一个已出现的token，presence_penalty减一个固定值；frequency_penalty则乘上一个和出现次数正相关的系数。这样做的好处是不改变分布的形状，只是把已出现token的概率从源头压低。

3.2 真实场景里怎么配惩罚参数

我在做长文本生成时遇到过最典型的问题：让模型写一篇1000字左右的文章，写到中间开始整段重复之前的内容。排查prompt无果后，把frequency_penalty从0调到0.5，重复现象明显减少；继续调到0.8时，虽然不再重复，但句子之间的衔接开始变得生硬，出现了“每个句子都在强行换风格”的感觉。

所以惩罚因子不是越大越好。我的经验是：

• 对话场景：presence_penalty=0.2~0.4，frequency_penalty=0.3~0.6。
• 长文生成：presence_penalty=0.3，frequency_penalty=0.5~0.8，同时配合max_tokens控制总长度。
• 代码生成：不建议开惩罚，尤其不要开frequency_penalty，否则模型会刻意避免重复使用同一个变量名，生成一些看起来“陌生”但实际上不合理的命名。

还有一点要注意：不要同时叠加repetition_penalty。vLLM的repetition_penalty是HuggingFace风格参数，和OpenAI风格的两种penalty底层逻辑不同，同时开会出现双重惩罚，模型变“词穷”，甚至生成不完整句子。

3.3 vLLM中惩罚参数与OpenAI字段的映射

vLLM的OpenAI兼容接口里，frequency_penalty和presence_penalty可以直接在请求体里传，字段名和OpenAI原版的语义一致。同时vLLM也保留了repetition_penalty作为扩展字段，通过extra_body传入。如果你是从OpenAI迁移到vLLM的，前两个参数可以直接沿用原有配置；如果你是从Transformers脚本迁移过来的，要特别注意repetition_penalty的语义和frequency_penalty完全不同，一个是乘法系数，一个是加法惩罚，不能等价替换。

4. best_of、beam search与logprobs：vLLM特有的可控生成选项

4.1 best_of和beam search的关系

vLLM的SamplingParams里有几个参数是Transformers生态里不常直接暴露的，最典型的就是best_of和use_beam_search。

best_of表示生成候选序列的数量。当use_beam_search=False时，vLLM会独立生成best_of条候选序列，从中挑选得分最高的返回；当use_beam_search=True时，best_of就变成了beam search的beam宽度，模型会同步维护多条候选路径，每一步都保留得分最高的best_of条前缀，最终输出全局得分最高的完整序列。

beam search适合摘要、翻译这类“确定性强”的任务，因为在这些任务里通常存在一个相对明确的“最优答案”，beam search能通过全局搜索贴近这个最优解。对话、创意写作则不建议用beam search——多项研究都发现，人类读者更偏好采样生成的文本，因为beam search倾向输出“平庸但高频”的句子，语言乏味且缺少意外感。

4.2 beam search在vLLM里的性能代价

beam search不是免费的。每条beam都等价于一个独立的token流，需要独立的KV cache和注意力计算。beam宽度为4时，最直观的影响就是decode阶段的吞吐量几乎呈线性下降。可以跑一下vllm bench serve做个对比，同一个模型、同一组prompt，用beam search和普通采样分别压测，吞吐差距非常直观。

官方对beam search的态度也比较谨慎：vLLM的优化重点在采样范式，beam search的访存模式恰好是它不太擅长处理的。我的建议是，除非任务对结果确定性要求极高，否则不要开beam search。非要用的话，best_of控制在2或3，别超过4。

如果你之后考虑切换到SGLang引擎做对比，也要注意：两个框架对采样参数的命名和默认值不一致，从vLLM迁移配置时不要直接复制，先看文档确认一下。

4.3 logprobs：把采样概率变成可观测信号

logprobs是很容易被忽略但生产环境里非常实用的参数。它可以让模型返回每个生成token的对数概率，vLLM的SamplingParams里通过logprobs指定返回的top logprobs数量。在OpenAI兼容接口里对应logprobs和top_logprobs两个字段。

这个参数有个很经典的高级用法：把大模型当成分类器。让模型用固定模板输出“A/B/C”其中的一个字母，再拿logprobs去比较A、B、C三个选项的概率，哪个概率高就选哪个。这种方式比直接解析模型输出的文本更稳定，也比纯分类模型在少样本场景下更灵活。价格上，用一个7B模型做路由判别的成本远比用一个小模型单独训练分类头来得低。

另外，logprobs还能用来做置信度评估。我在做RAG问答质量监控时，会把答案token的平均对数概率作为一道弱信号，如果某次回答的概率明显低于历史均值，就触发告警，人工复核这条答案。这个策略不完美，但能抓出不少“模型其实在硬编”的情况。

5. 参数怎么传：从离线推理到OpenAI兼容服务的API映射

5.1 离线推理的配置入口

在vLLM里做离线推理，核心入口是SamplingParams。下面这段代码覆盖了常用参数：

from vllm import LLM, SamplingParams sampling_params = SamplingParams( temperature=0.3, top_p=0.9, top_k=-1, max_tokens=512, frequency_penalty=0.3, presence_penalty=0.2, stop=["\n\n"], seed=42, ) llm = LLM(model="Qwen/Qwen2.5-7B-Instruct") outputs = llm.generate( ["请用三句话解释什么是事务的ACID特性"], sampling_params, )

这里有几个参数之间的隐性约束关系值得注意：

• temperature >= 0，为0时实际走贪心解码。
• top_p的取值范围是(0, 1]。
• use_beam_search=True时要求best_of > 1。
• best_of必须大于等于n，因为你要从候选里挑出n条不同的返回。

vLLM在初始化SamplingParams时会做参数校验，如果违反约束会直接抛异常。报错信息通常很清楚，但很多人写代码时没接异常处理，导致线上出现“请求失败”却找不到原因。我的习惯是在服务启动前先用一批离线样本把参数组合全部跑通，再做服务化封装。

5.2 OpenAI兼容服务的请求级参数覆盖

服务化部署场景里，大家通常走OpenAI兼容接口。可以看到很多参数直接在HTTP请求里传就行：

import requests resp = requests.post( "http://localhost:8000/v1/chat/completions", json={ "model": "qwen25-7b", "messages": [{"role": "user", "content": "推荐三个适合初学者学习编程的项目"}], "temperature": 0.7, "top_p": 0.9, "max_tokens": 256, "frequency_penalty": 0.5, "presence_penalty": 0.2, }, ) print(resp.json()["choices"][0]["message"]["content"])

vLLM服务会把请求体里的参数解析成SamplingParams，覆盖启动时配置文件里的默认值。所以同一个后端服务，A业务线要稳定输出，B业务线要发散创意，只需要在请求侧传不同参数，服务端不用重新部署。

非OpenAI标准字段，比如repetition_penalty、min_p、seed，需要通过extra_body传。如果你是直接用requests发请求的，直接在json里加字段即可；如果用的是openai官方Python SDK，得显式构造extra_body，否则部分版本会把这些扩展字段静默丢掉。这个坑我踩过一次，排查了好半天才发现是SDK把扩展字段过滤了。

5.3 参数在调度器中的生效路径

理解参数生效路径，有助于排查“为什么我的参数好像没生效”这类问题。一次完整的vLLM生成流程大致是：

1. 请求进入LLMEngine，被包装成SequenceGroup，每个Sequence对象上挂着一个SamplingParams。
2. Scheduler根据显存情况决定哪些SequenceGroup可以进入decode阶段。
3. Worker中的模型前向计算得到logits。
4. Sampler根据SamplingParams做logits处理（惩罚、截断、温度缩放）和最终采样。

关键点在于，每个Sequence独立持有自己的SamplingParams。所以即使一批请求混在一起做continuous batching，不同请求也可以有不同的temperature、top_p和penalty，互不干扰。这是vLLM相比简单批量推理引擎的优势：多租户场景下，不需要为不同参数的请求分别排队。

6. 实际场景的参数组合与排坑记录

6.1 代码生成与结构化输出：先把temperature锁死在0

代码生成、JSON修复、SQL生成这类任务，第一原则是可复现。同一个prompt，两次生成完全不同的函数实现，对开发者来说就是灾难。

我在本地部署Qwen2.5-Coder时，默认配置就是temperature=0、top_p=1、top_k=-1。跑一轮测试集后，将输出和预期结果对齐，确认功能没问题，再把temperature调到0.1~0.2，给模型留一点点同义变量名和注释风格的变化空间。但绝不调presence_penalty和frequency_penalty，因为代码里大量重复使用同一个标识符是正常需求，开了惩罚会出现“命名漂移”——模型为了不重复用同一个词，生成一个语义相同但拼写奇怪的变量名。

6.2 长文本与对话场景的“防绕圈”配置

长文本生成最常见的翻车现场是：模型写到一半开始复述前文，甚至死循环。我实际查过很多次，logits层面并没有报错，就是采样概率导致模型在几个高频token之间来回跳。

解决思路分两步。第一步，给frequency_penalty一个0.3~0.5的底数，抑制局部重复。第二步，在prompt里加入明确的结束信号，比如要求“回答结束请输出END”，并在stop里配上"END"。这样即使模型自己忘了收尾，也会被stop参数强行截断。我还习惯把中文句号。也加入stop列表，防止模型在生成完一句话后又接着补充无关内容。这个做法是从一次线上故障里学到的——模型把标点当作普通token继续生成，看起来很通顺，但业务方拿到的答案被截断在了一半。

6.3 实测踩坑：temperature在beam search下不生效

有一次为了做翻译任务，我开了use_beam_search=True，然后想去调节temperature来增加一点翻译风格的多样性。结果调了半天，输出一模一样。当时第一反应是vLLM的缓存出问题了，后来翻文档加看源码才确认：beam search是确定性搜索算法，temperature、top_p、top_k、penalty这一整套概率采样参数都不会生效。SamplingParams里use_beam_search=True时，采样器直接走BeamSearchSampler，这些参数即使传了也会被忽略。

这个坑的麻烦之处在于，vLLM启动时不会因为这些参数冗余而报错，你必须自己去文档里翻到对应字段的注释才会发现。所以如果你正在调参但输出没有任何变化，先确认一下是否开了beam search，别在参数上浪费太多时间。

6.4 EOS token与stop参数的边界

还有一类问题经常被误判为“采样参数失效”：模型已经生成完核心内容，但迟迟不输出EOS，一直生成到max_tokens上限。这种情况在中文模型里尤其常见，因为中文的句号、逗号等标点在分词后经常被合并进token，模型对“何时应该结束”的判别不如英文模型稳定。

我自己的处理方案是把ignore_eos保持默认False，同时把max_tokens设置成业务可接受的上限，再配合stop参数做文本级截断。stop参数匹配的是tokenize之后的文本片段，所以把["END", "\n\n"]传进去，模型生成到这个标记时一定会停。这在生产环境里比单纯依赖EOS token可靠得多。

6.5 我的参数调试流程

最后分享一套我自己在用的调试流程，基本思路是“固定不变量，一次只动一个变量”。

先跑一遍temperature=0的基线，记录输出作为功能正确性基准。然后在同一批prompt上逐个变量扫描，每次只改一个参数，记录输出差异到表格里。用同一个随机种子，保证结果可对比。以下是我做某次对话文本风格调优时的部分记录：

这套流程看起来很笨，但比凭感觉随机试参数高效得多。vLLM的请求级参数覆盖让这件事做起来非常舒服：同一套服务，开两个测试脚本，各自传不同的SamplingParams，几十个prompt跑下来，哪个组合适合生产就一目了然。

采样与解码参数在大模型服务里的重要性，不亚于模型本身。vLLM把这些参数从单机脚本带进了生产环境，让每个请求都可以有独立配置，这种设计对整个服务化体系的灵活性帮助巨大。如果你正在做模型服务落地，建议把常用参数组合固化成配置模板，按业务线去切换，比每次开发都重新调一遍省力得多。