多候选的两种做法
单次请求可以返回多个候选：一种做法是直接把多个结果返回给调用方，另一种是在内部采样多个候选后按累计概率挑一个返回。前者的成本体现在返回内容上，后者的成本体现在内部生成量上。两者都要按总生成词元数估算容量，而不是按请求数。
基本信息
| 适用平台 | OpenAI 兼容接口与自托管推理引擎 |
|---|---|
| 两种参数 | 返回多个候选；内部多采样后择优返回 |
| 成本口径 | 按总生成词元数估算，不是按请求数 |
| 典型用途 | 候选挑选与质量对比 |
两种写法
两种写法
# OpenAI 兼容：{ "n": 2 }
# vLLM
SamplingParams(n=1, best_of=4) # 内部生成 4 个候选，返回 1 个典型使用场景
- 质量优先场景：内部多采样后择优，用算力换质量
- 对比实验：返回多个候选做人工或自动评估
- 成本控制：先小流量验证收益，再决定是否常开
- 容量核算：按生成量而不是请求数规划显存与耗时
- 效果分析：记录最终选中的候选序号，便于评估择优策略
参数与成本
| 参数 | 含义 | 成本影响 |
|---|---|---|
| 候选数 | 一次返回的结果个数 | 返回体积与生成量成倍上升 |
| 择优候选数 | 内部采样多少个再挑一个 | 内部生成量放大，返回仍是一个 |
| 温度 | 采样的随机性 | 温度越高，候选之间差异越大 |
容量估算按总生成词元数而不是请求数：候选数或择优数上调会直接放大显存与耗时需求。
择优不等于一定更好：挑选用的是累计概率，与业务期望不一定一致，收益要按评测确认。
先小流量验证：多候选带来的成本是线性的，收益却随任务类型变化，值得先测一小批。
返回多个候选时注意接口契约：索引与顺序要稳定，客户端才能可靠地按位置取用。