同名参数不等于同义
多厂商接入时最容易踩的坑，是以为名称相同的采样参数含义一致。实际情况差异很大：温度的取值范围不同，是否与其他参数相互缩放不同，top_p 与 top_k 是否同时生效、谁优先也不同；惩罚类参数的统计窗口、输出上限是否包含输入、终止序列是否留在输出里，各家实现都有自己的口径。对齐的做法不是把数字抄成一样，而是建立参数映射并用行为基线验证。
基本信息
| 需对齐参数 | 温度、top_p、top_k、惩罚类、随机种子、输出上限、终止序列 |
|---|---|
| 实现差异 | 取值范围、是否互斥、统计窗口、默认值、是否被结构化模式覆盖 |
| 对齐步骤 | 先列映射关系，再跑同一批样本对比行为 |
| 验证方式 | 固定输入多次运行，比较输出长度分布与格式合法率 |
| 记录要求 | 把厂商、参数、取值与行为结论一并归档 |
| 依据来源 | 各厂商参数说明与默认值以官方文档为准 |
典型使用场景
- 多厂商接入：同一业务在不同供应商之间切换或分流
- 提示词复用：同一套提示词需要跨平台生效，避免参数语义不一致
- 成本对比：输出上限与终止序列口径不同会让 token 用量不可比
- 灰度试点：新厂商按比例接入，用基线对比确认行为可比
- 结构化输出：确认 JSON 模式与工具调用下采样参数是否需要调整
- 故障排查：怀疑参数被下游覆盖时，用映射表逐项核对
参数与常见差异
| 参数 | 常见差异 | 对齐做法 |
|---|---|---|
| 温度 | 取值范围与是否与其他参数相互缩放 | 先确认范围，再按行为而非数值对齐 |
| top_p | 与 top_k 是否同时生效、谁优先 | 固定只用一个，避免叠加 |
| top_k | 部分平台不提供或忽略该参数 | 不依赖它做控制，改用可验证的参数 |
| 频率与存在惩罚 | 统计窗口与计入口径不同 | 用同一批样本观察重复度变化 |
| 输出上限 | 含输入还是仅输出、是否计入推理内容 | 按输出 token 实测，不按字段名推断 |
| 终止序列 | 是否包含在返回内容中 | 统一在应用层裁剪，避免下游解析受影响 |
| 随机种子 | 支持情况与可复现强度不同 | 不支持时用多次运行看分布 |
| 结构化模式 | 启用后可能限制或覆盖采样参数 | 以官方文档说明为准并实测确认 |
参数映射与基线
参数映射与基线
# 一张表把语义差异摊开，避免逐家试错
vendor_a:
temperature: 范围 0-2，默认 1，与 top_p 有交互
output_limit: 仅统计输出 token
stop: 终止序列不出现在返回内容中
json_mode: 支持，启用后采样受约束
vendor_b:
temperature: 范围 0-1，默认 0.7，与 top_p 独立
output_limit: 输入与输出合计
stop: 终止序列会保留在返回内容里
json_mode: 通过工具调用实现
baseline:
suite: core-v3
runs: 3 # 同一输入重复次数
metrics: [output_len_p50, output_len_p95, parse_fail_rate, repeat_rate]
conclusion: 记录等价参数组合，而不是照抄数值跨平台复用提示词时，参数对齐的优先级低于提示词对齐：先把系统提示、字段说明与示例统一，再调参数。只调参数不改提示词，常得到「像同一个模型但性格不同」的结果。
终止序列的处理方式建议在应用层统一：无论上游是否把终止符留在输出里，都在解析前裁掉并校验长度。这样下游解析逻辑不必感知厂商差异。
强行把数值对齐可能破坏行为：某平台上合理的温度值在另一平台可能过于发散，导致格式合法率下降。参数范围、默认值与结构化模式的约束，一律以对应厂商官方文档为准，并以实测行为作为最终判据。