温度设为 0 仍然不完全确定：LLM 推理非确定性从哪来、怎么测、如何缓解

董厂长2025-12-27 9:35

很多团队会把 LLM 的 temperature 设为 0，期待"同一 prompt 每次输出都一模一样"。但你可能已经亲眼见过：即便温度为 0，输出仍偶尔出现轻微差异。

这不是错觉。多家服务商明确提示"温度=0 也不保证完全确定"。Anthropic 的文档直接说明即使 temperature=0.0 结果也不会完全确定（not be fully deterministic）[1](#1)[2](#2)；OpenAI 的 Cookbook 也强调：即使使用 seed 来追求可复现，结果也只是"mostly（大多数情况下）一致"，并且需要请求参数与 system_fingerprint 匹配；即便这样仍可能有小概率差异，因为模型/系统存在固有非确定性（inherent non-determinism）[3](#3)。

这篇博客把问题拆成三个层面：

  1. 解码策略层：温度到底控制什么？温度为 0 等价于什么（贪婪解码（每步取概率最大 token）还是别的）？
  2. 数值与并行层：即使每步都取 argmax，为什么 logits 仍可能"略微不一样"？
  3. 服务化与工程层：批处理、调度、后端更新为什么会影响"你以为确定"的输出？

最后我会给一个"尽量逼近确定性"的实操清单，以及一个专业术语详解表。

1. 先澄清：温度为 0，到底在做什么？

在大多数文本生成库里，"温度（temperature，控制采样随机性的缩放系数）"只在**采样（sampling，根据概率分布随机抽 token）**时才真正发挥作用。

以 Hugging Face Transformers 为例：当 num_beams=1 且 do_sample=False 时，使用的是贪婪解码（greedy decoding：每一步选择概率最高的 token，即 argmax） [4](#4)。

这里的参数组合可以用更直白的话翻译成两条"开关"：

  • do_sample=False（不采样）：不要"按概率抽签"，而是走确定的选择规则；一旦它是 False，像 temperature 这种"控制抽签随机度"的参数通常就不会生效（甚至会触发提示/警告）[5](#5)。
  • num_beams=1（只保留 1 条候选）：不要做束搜索（beam search：同时保留多条候选继续扩展），而是每一步只沿着当前最可能的那条路走下去。

把两者合在一起，就是：不抽签 + 不保留多条候选，所以行为上等价于"每一步都选概率最大的 token"。

所以工程上你经常看到的"temperature=0"，更准确的理解是：

  • 意图：避免"有意引入的随机性"（采样）；
  • 实现：走"更确定的解码路径"（通常等价于贪婪解码）；
  • 但不等价 ：并不自动让整个推理系统变成"逐位一致（bitwise identical）的确定系统"。

2. 为什么 argmax 也会变？非确定性的关键来源

温度为 0 之后，随机性并不是消失了，而是从"显式采样"转移到了"上游的微小差异"。只要 logits 发生了足够小的扰动，且刚好处在"第一名和第二名非常接近"的位置，最终 argmax 就可能翻转。

下面按"从上到下"的栈来拆。

2.1 提供方层：供应商就没承诺 100% 确定

  • Anthropic：文档明确指出即使 temperature=0.0 也不会完全确定[1](#1)[2](#2)。
  • OpenAI：Cookbook 说明可用 seed 尝试复现，但仅"mostly"一致，且要关注返回的 system_fingerprint（系统指纹：反映后端配置/版本）是否匹配；即便如此仍可能出现小概率差异[3](#3)。

结论很直接：如果你调用的是云端闭源推理服务，把 temperature 设为 0 只能降低随机性，但无法要求 100% 可复现。

2.2 框架与算子层：并行 + 浮点让"相同输入→相同 logits"变难

在本地推理里，很多"看似应该确定"的差异都来自底层数值与并行实现。

(1) PyTorch：不同版本/平台/设备不保证完全可复现

PyTorch 的可复现性说明明确提到：跨不同版本、平台、CPU/GPU 的"完全可复现"不被保证；但可以通过配置减少/消除某些非确定性算法，使相同输入多次调用得到相同结果，并提供 torch.use_deterministic_algorithms 作为全局开关（强制确定性实现或直接报错）[6](#6)[7](#7)。

这句话的工程含义是：你的模型"数学上确定"，不代表你的"实现路径"确定。

(2) cuDNN：原子操作（atomic operations）等会破坏重现

NVIDIA cuDNN Backend 文档在"Reproducibility (Determinism)"部分指出：某些例程如果以会引入"真正随机的浮点舍入误差"的方式使用原子操作，则即使在同一 GPU 架构上跨运行也可能无法保证完全重现；跨不同架构更不保证按位一致[8](#8)。

你可以把它理解成：GPU 为了快，会用一些"并行规约（parallel reduction：多线程并行求和/合并）"的方式算东西；而浮点加法不是严格可交换/可结合的，规约顺序不同就可能产生极小差异，差异在极端边界上能触发 token 选择变化。

(3) XLA：明确列了哪些算子可能不确定

OpenXLA 的 determinism 文档也很直白：XLA 编译的程序在 scatter、select-and-scatter、GEMM（矩阵乘）、卷积、多头注意力（multi-head attention：注意力机制的并行头实现）等操作上可能非确定，并提供切换到确定性实现的方式（往往更慢）；其中 select-and-scatter 甚至没有确定性实现[9](#9)。

这进一步印证：非确定性不是"你没设种子"这么简单，而是加速栈本身权衡性能后的常态。

2.3 推理引擎/服务化层：批处理与调度能改变结果

即使你本地用的是贪婪解码，服务化推理还会引入另一个变量：

  • "你的请求是否与别人的请求一起被动态分批？"
  • "调度策略是否保证批不变？"

vLLM 的文档专门提供"可复现（reproducibility）"机制，以及"批不变（batch invariance：同一输入在不同 batch 位置输出一致）"特性，并给出离线推理下的复现建议（例如设置 VLLM_ENABLE_V1_MULTIPROCESSING=0 来减少由多进程/调度引入的差异）[10](#10)[11](#11)。

Thinking Machines Lab 的工程文章也围绕"如何在推理中击败非确定性"讨论了很多服务端推理时的来源与对策[12](#12)。

如果你把 LLM 当成"线上服务"，那么**批处理（batching：把多个请求合并成一个更大计算）与调度（scheduling：决定谁先算、怎么拼 batch）**就是确定性的真实敌人之一。

3. "温度=0"并不总是最佳：和质量的关系

另一个常被忽略的点：就算你把非确定性压到最低，温度为 0（贪婪解码）也未必在文本质量上最优。

Holtzman 等人的经典论文指出：贪婪/束搜索（beam search：保留多个候选序列的搜索）容易产生"退化文本"（degeneration：重复、空洞、缺乏信息密度），并提出 nucleus sampling（top-p，核采样：只在累计概率达到 p 的候选集里采样）来改善生成质量[13](#13)。

工程含义是：

  • 确定性 与质量/多样性是拉扯关系；
  • 很多业务其实只需要"语义一致"，不需要"逐字符一致"。

4. 怎么把一致性做得更好？一份可执行的检查清单

下面这份清单按"你能控制的粒度"排序：越往后越接近底层、成本也越高。

4.1 云端 API（你无法控制底层）

  1. 先接受现实：供应商可能明确说不保证完全确定[1](#1)[2](#2)。
  2. 若提供 seed：使用它，并保证请求参数完全一致；同时记录/校验 system_fingerprint 是否匹配；它变化往往意味着后端更新，复现性会下降[3](#3)。
  3. 把"确定性验收指标"从字符串一致改为结构化一致：比如 JSON 解析后的字段一致、正则提取结果一致（这是工程上最省钱的"确定性"）。

4.2 Transformers / PyTorch（你能控制算法与部分算子）

  1. 明确使用贪婪解码（greedy decoding）路径：do_sample=False（不采样） + num_beams=1（不用束搜索，只走单一路径）[4](#4)。
  2. 使用 PyTorch 的确定性配置（deterministic algorithms：强制确定性实现）：torch.use_deterministic_algorithms(True)（注意：某些算子可能因此报错或变慢）[7](#7)。
  3. 理解边界：即便如此，PyTorch 仍提示跨版本/平台/设备的完全可复现不被保证[6](#6)。

4.3 cuDNN / XLA / 推理引擎（为了性能你可能付出确定性）

  1. 如果追求逐位一致：要关注底层库"确定性"章节里明确列出的例外（例如原子操作相关）[8](#8)。
  2. 如果用 XLA：避免/替换被标注为非确定的算子，或启用其确定性选项，并接受性能代价与功能缺失[9](#9)。
  3. 若用 vLLM 做线上推理：启用或对齐其可复现/批不变的建议；离线复现可参考其关闭多进程等建议[10](#10)[11](#11)。

6. 小结

把 temperature 设为 0 是降低随机性的正确起点，但它只解决"解码策略的随机性"，并不消除推理栈中的数值、并行、库实现与服务化调度带来的非确定性。

一句话总结：

温度=0 ≈ 贪婪解码（更确定），但"更确定"不等于"绝对确定"。

专业术语解释表（详细版）

下面的术语按"从上到下的推理栈"排列。每个解释都尽量用非学术话术，并配一个小例子。

术语 简要解释 更好理解的说法/例子
temperature（温度） 控制采样随机性的参数；通常通过缩放 logits 来改变分布"尖锐程度"。 想象你在抽奖：温度高=更敢抽小概率奖品；温度低=更倾向最大概率的选择。温度为 0 往往意味着不抽奖，直接选"最可能"的那个。^[4](#术语 简要解释 更好理解的说法/例子 temperature（温度） 控制采样随机性的参数；通常通过缩放 logits 来改变分布“尖锐程度”。 想象你在抽奖：温度高=更敢抽小概率奖品；温度低=更倾向最大概率的选择。温度为 0 往往意味着不抽奖，直接选“最可能”的那个。4 decoding（解码） 把模型输出的概率分布一步步变成最终文本的过程。 模型每一步给出“下一词的概率表”，解码策略决定你怎么从表里选一个词。4 greedy decoding（贪婪解码） 每一步都选择概率最大的 token（argmax）。 每次都选“最有把握的答案”。如果第一名和第二名非常接近，哪怕概率表有极小抖动，第一名也可能换人。4 sampling（采样） 按概率分布随机抽取 token。 即便第一名概率最高，也可能抽到第二名、第三名；这能带来多样性，但会降低可复现性。 do_sample（是否采样） Transformers 里控制“走采样还是走确定性选择”的开关。 do_sample=True 时就像“抽签选词”；do_sample=False 时更像“按最高分直接选”。当它是 False 时，temperature 往往就没意义了（因为都不抽签了）。45 num_beams（束宽） 束搜索（beam search）一次保留的候选序列数量。 num_beams=1 就是不做束搜索；num_beams=5 类似“同时保留 5 条可能的续写路线再比较”。束越宽通常越慢，也更可能改变输出风格。4 top-p / nucleus sampling（核采样） 只在“累计概率达到 p 的候选集合”内采样。 如果 p=0.9，就先挑出一组 token，让它们的概率加起来到 0.9，再在这组里抽；比“全分布采样”更稳，也更能避免离谱尾部。13 beam search（束搜索） 同时保留多个候选序列，搜索更高整体概率的序列。 像走迷宫时同时保留几条“看起来最优”的路继续探索；但在开放式文本生成中可能导致重复等退化现象。13 degeneration（文本退化） 生成文本出现重复、空洞、过度模板化等现象。 例如模型不停输出“当然当然当然……”。论文指出贪婪/束搜索更容易触发这种问题。13 logits（对数几率/未归一化分数） 模型在 softmax 之前给每个 token 的“分数”。 可以把 logits 当成“每个候选词的打分”。温度、softmax 等操作会把打分变成概率。 argmax（取最大值索引） 从一组数里选出最大值对应的索引。 从概率表里挑“最大概率的词”。若最大值与次大值非常接近，微小数值误差就可能改变结果。 reproducibility（可复现性） 同样输入在多次运行中得到同样输出的能力。 “我今天跑一次、明天跑一次，结果要一样”。但官方文档常提醒：跨版本/设备未必能做到 100%。6 deterministic algorithms（确定性算法） 强制使用不会引入非确定性的实现路径（或直接报错）。 PyTorch 提供 torch.use_deterministic_algorithms 这类开关：要么走确定性实现，要么宁愿失败也不悄悄给你不确定结果。7 atomic operations（原子操作） 多线程并发更新同一个值时的“不可分割更新”。 像多人同时往同一个存钱罐里塞硬币：原子操作保证“不会塞丢”，但塞的先后顺序可能不同；配合浮点舍入，最终小数点后可能略有差异。cuDNN 文档提示这会影响可复现。8 parallel reduction（并行规约） 把很多数求和/合并的并行算法。 1000 个数求和，GPU 会分组并行相加再合并；但浮点加法对顺序敏感，合并顺序不同会带来极小误差。8 system_fingerprint（系统指纹） 供应商返回的后端配置标识，用于判断“后端是否变了”。 如果你昨天和今天的 fingerprint 不同，即便你参数不变，也很可能因为后端升级导致输出/一致率变化。3 batch / batching（批处理） 把多个请求合并成一个大计算以提升吞吐。 像等电梯：把多个人一起送上去更省电。但你上电梯时遇到的人不同（批次不同），系统内部安排可能不同，从而影响输出一致性。vLLM 提到“批不变”就是在解决这个。10 batch invariance（批不变） 同一输入在不同 batch 位置时输出保持一致。 你和别人一起算/单独算，结果都一样。vLLM 把它作为重要特性来保证服务化一致性。10 scheduling（调度） 决定哪些请求先算、怎么拼 batch、怎么分配资源。 同一条任务在不同队列里先后顺序不同，内部拼 batch 的方式就可能不同，从而影响输出。1011 XLA（编译器） 把计算图编译成高性能内核的编译器/后端。 “为了跑得更快”，编译器会换算法/融合算子；但文档说某些算子在 GPU 上可能非确定。9)^
decoding（解码） 把模型输出的概率分布一步步变成最终文本的过程。 模型每一步给出"下一词的概率表"，解码策略决定你怎么从表里选一个词。^[4](#术语 简要解释 更好理解的说法/例子 temperature（温度） 控制采样随机性的参数；通常通过缩放 logits 来改变分布“尖锐程度”。 想象你在抽奖：温度高=更敢抽小概率奖品；温度低=更倾向最大概率的选择。温度为 0 往往意味着不抽奖，直接选“最可能”的那个。4 decoding（解码） 把模型输出的概率分布一步步变成最终文本的过程。 模型每一步给出“下一词的概率表”，解码策略决定你怎么从表里选一个词。4 greedy decoding（贪婪解码） 每一步都选择概率最大的 token（argmax）。 每次都选“最有把握的答案”。如果第一名和第二名非常接近，哪怕概率表有极小抖动，第一名也可能换人。4 sampling（采样） 按概率分布随机抽取 token。 即便第一名概率最高，也可能抽到第二名、第三名；这能带来多样性，但会降低可复现性。 do_sample（是否采样） Transformers 里控制“走采样还是走确定性选择”的开关。 do_sample=True 时就像“抽签选词”；do_sample=False 时更像“按最高分直接选”。当它是 False 时，temperature 往往就没意义了（因为都不抽签了）。45 num_beams（束宽） 束搜索（beam search）一次保留的候选序列数量。 num_beams=1 就是不做束搜索；num_beams=5 类似“同时保留 5 条可能的续写路线再比较”。束越宽通常越慢，也更可能改变输出风格。4 top-p / nucleus sampling（核采样） 只在“累计概率达到 p 的候选集合”内采样。 如果 p=0.9，就先挑出一组 token，让它们的概率加起来到 0.9，再在这组里抽；比“全分布采样”更稳，也更能避免离谱尾部。13 beam search（束搜索） 同时保留多个候选序列，搜索更高整体概率的序列。 像走迷宫时同时保留几条“看起来最优”的路继续探索；但在开放式文本生成中可能导致重复等退化现象。13 degeneration（文本退化） 生成文本出现重复、空洞、过度模板化等现象。 例如模型不停输出“当然当然当然……”。论文指出贪婪/束搜索更容易触发这种问题。13 logits（对数几率/未归一化分数） 模型在 softmax 之前给每个 token 的“分数”。 可以把 logits 当成“每个候选词的打分”。温度、softmax 等操作会把打分变成概率。 argmax（取最大值索引） 从一组数里选出最大值对应的索引。 从概率表里挑“最大概率的词”。若最大值与次大值非常接近，微小数值误差就可能改变结果。 reproducibility（可复现性） 同样输入在多次运行中得到同样输出的能力。 “我今天跑一次、明天跑一次，结果要一样”。但官方文档常提醒：跨版本/设备未必能做到 100%。6 deterministic algorithms（确定性算法） 强制使用不会引入非确定性的实现路径（或直接报错）。 PyTorch 提供 torch.use_deterministic_algorithms 这类开关：要么走确定性实现，要么宁愿失败也不悄悄给你不确定结果。7 atomic operations（原子操作） 多线程并发更新同一个值时的“不可分割更新”。 像多人同时往同一个存钱罐里塞硬币：原子操作保证“不会塞丢”，但塞的先后顺序可能不同；配合浮点舍入，最终小数点后可能略有差异。cuDNN 文档提示这会影响可复现。8 parallel reduction（并行规约） 把很多数求和/合并的并行算法。 1000 个数求和，GPU 会分组并行相加再合并；但浮点加法对顺序敏感，合并顺序不同会带来极小误差。8 system_fingerprint（系统指纹） 供应商返回的后端配置标识，用于判断“后端是否变了”。 如果你昨天和今天的 fingerprint 不同，即便你参数不变，也很可能因为后端升级导致输出/一致率变化。3 batch / batching（批处理） 把多个请求合并成一个大计算以提升吞吐。 像等电梯：把多个人一起送上去更省电。但你上电梯时遇到的人不同（批次不同），系统内部安排可能不同，从而影响输出一致性。vLLM 提到“批不变”就是在解决这个。10 batch invariance（批不变） 同一输入在不同 batch 位置时输出保持一致。 你和别人一起算/单独算，结果都一样。vLLM 把它作为重要特性来保证服务化一致性。10 scheduling（调度） 决定哪些请求先算、怎么拼 batch、怎么分配资源。 同一条任务在不同队列里先后顺序不同，内部拼 batch 的方式就可能不同，从而影响输出。1011 XLA（编译器） 把计算图编译成高性能内核的编译器/后端。 “为了跑得更快”，编译器会换算法/融合算子；但文档说某些算子在 GPU 上可能非确定。9)^
greedy decoding（贪婪解码） 每一步都选择概率最大的 token（argmax）。 每次都选"最有把握的答案"。如果第一名和第二名非常接近，哪怕概率表有极小抖动，第一名也可能换人。^[4](#术语 简要解释 更好理解的说法/例子 temperature（温度） 控制采样随机性的参数；通常通过缩放 logits 来改变分布“尖锐程度”。 想象你在抽奖：温度高=更敢抽小概率奖品；温度低=更倾向最大概率的选择。温度为 0 往往意味着不抽奖，直接选“最可能”的那个。4 decoding（解码） 把模型输出的概率分布一步步变成最终文本的过程。 模型每一步给出“下一词的概率表”，解码策略决定你怎么从表里选一个词。4 greedy decoding（贪婪解码） 每一步都选择概率最大的 token（argmax）。 每次都选“最有把握的答案”。如果第一名和第二名非常接近，哪怕概率表有极小抖动，第一名也可能换人。4 sampling（采样） 按概率分布随机抽取 token。 即便第一名概率最高，也可能抽到第二名、第三名；这能带来多样性，但会降低可复现性。 do_sample（是否采样） Transformers 里控制“走采样还是走确定性选择”的开关。 do_sample=True 时就像“抽签选词”；do_sample=False 时更像“按最高分直接选”。当它是 False 时，temperature 往往就没意义了（因为都不抽签了）。45 num_beams（束宽） 束搜索（beam search）一次保留的候选序列数量。 num_beams=1 就是不做束搜索；num_beams=5 类似“同时保留 5 条可能的续写路线再比较”。束越宽通常越慢，也更可能改变输出风格。4 top-p / nucleus sampling（核采样） 只在“累计概率达到 p 的候选集合”内采样。 如果 p=0.9，就先挑出一组 token，让它们的概率加起来到 0.9，再在这组里抽；比“全分布采样”更稳，也更能避免离谱尾部。13 beam search（束搜索） 同时保留多个候选序列，搜索更高整体概率的序列。 像走迷宫时同时保留几条“看起来最优”的路继续探索；但在开放式文本生成中可能导致重复等退化现象。13 degeneration（文本退化） 生成文本出现重复、空洞、过度模板化等现象。 例如模型不停输出“当然当然当然……”。论文指出贪婪/束搜索更容易触发这种问题。13 logits（对数几率/未归一化分数） 模型在 softmax 之前给每个 token 的“分数”。 可以把 logits 当成“每个候选词的打分”。温度、softmax 等操作会把打分变成概率。 argmax（取最大值索引） 从一组数里选出最大值对应的索引。 从概率表里挑“最大概率的词”。若最大值与次大值非常接近，微小数值误差就可能改变结果。 reproducibility（可复现性） 同样输入在多次运行中得到同样输出的能力。 “我今天跑一次、明天跑一次，结果要一样”。但官方文档常提醒：跨版本/设备未必能做到 100%。6 deterministic algorithms（确定性算法） 强制使用不会引入非确定性的实现路径（或直接报错）。 PyTorch 提供 torch.use_deterministic_algorithms 这类开关：要么走确定性实现，要么宁愿失败也不悄悄给你不确定结果。7 atomic operations（原子操作） 多线程并发更新同一个值时的“不可分割更新”。 像多人同时往同一个存钱罐里塞硬币：原子操作保证“不会塞丢”，但塞的先后顺序可能不同；配合浮点舍入，最终小数点后可能略有差异。cuDNN 文档提示这会影响可复现。8 parallel reduction（并行规约） 把很多数求和/合并的并行算法。 1000 个数求和，GPU 会分组并行相加再合并；但浮点加法对顺序敏感，合并顺序不同会带来极小误差。8 system_fingerprint（系统指纹） 供应商返回的后端配置标识，用于判断“后端是否变了”。 如果你昨天和今天的 fingerprint 不同，即便你参数不变，也很可能因为后端升级导致输出/一致率变化。3 batch / batching（批处理） 把多个请求合并成一个大计算以提升吞吐。 像等电梯：把多个人一起送上去更省电。但你上电梯时遇到的人不同（批次不同），系统内部安排可能不同，从而影响输出一致性。vLLM 提到“批不变”就是在解决这个。10 batch invariance（批不变） 同一输入在不同 batch 位置时输出保持一致。 你和别人一起算/单独算，结果都一样。vLLM 把它作为重要特性来保证服务化一致性。10 scheduling（调度） 决定哪些请求先算、怎么拼 batch、怎么分配资源。 同一条任务在不同队列里先后顺序不同，内部拼 batch 的方式就可能不同，从而影响输出。1011 XLA（编译器） 把计算图编译成高性能内核的编译器/后端。 “为了跑得更快”，编译器会换算法/融合算子；但文档说某些算子在 GPU 上可能非确定。9)^
sampling（采样） 按概率分布随机抽取 token。 即便第一名概率最高，也可能抽到第二名、第三名；这能带来多样性，但会降低可复现性。
do_sample（是否采样） Transformers 里控制"走采样还是走确定性选择"的开关。 do_sample=True 时就像"抽签选词"；do_sample=False 时更像"按最高分直接选"。当它是 False 时，temperature 往往就没意义了（因为都不抽签了）。^[4](#术语 简要解释 更好理解的说法/例子 temperature（温度） 控制采样随机性的参数；通常通过缩放 logits 来改变分布“尖锐程度”。 想象你在抽奖：温度高=更敢抽小概率奖品；温度低=更倾向最大概率的选择。温度为 0 往往意味着不抽奖，直接选“最可能”的那个。4 decoding（解码） 把模型输出的概率分布一步步变成最终文本的过程。 模型每一步给出“下一词的概率表”，解码策略决定你怎么从表里选一个词。4 greedy decoding（贪婪解码） 每一步都选择概率最大的 token（argmax）。 每次都选“最有把握的答案”。如果第一名和第二名非常接近，哪怕概率表有极小抖动，第一名也可能换人。4 sampling（采样） 按概率分布随机抽取 token。 即便第一名概率最高，也可能抽到第二名、第三名；这能带来多样性，但会降低可复现性。 do_sample（是否采样） Transformers 里控制“走采样还是走确定性选择”的开关。 do_sample=True 时就像“抽签选词”；do_sample=False 时更像“按最高分直接选”。当它是 False 时，temperature 往往就没意义了（因为都不抽签了）。45 num_beams（束宽） 束搜索（beam search）一次保留的候选序列数量。 num_beams=1 就是不做束搜索；num_beams=5 类似“同时保留 5 条可能的续写路线再比较”。束越宽通常越慢，也更可能改变输出风格。4 top-p / nucleus sampling（核采样） 只在“累计概率达到 p 的候选集合”内采样。 如果 p=0.9，就先挑出一组 token，让它们的概率加起来到 0.9，再在这组里抽；比“全分布采样”更稳，也更能避免离谱尾部。13 beam search（束搜索） 同时保留多个候选序列，搜索更高整体概率的序列。 像走迷宫时同时保留几条“看起来最优”的路继续探索；但在开放式文本生成中可能导致重复等退化现象。13 degeneration（文本退化） 生成文本出现重复、空洞、过度模板化等现象。 例如模型不停输出“当然当然当然……”。论文指出贪婪/束搜索更容易触发这种问题。13 logits（对数几率/未归一化分数） 模型在 softmax 之前给每个 token 的“分数”。 可以把 logits 当成“每个候选词的打分”。温度、softmax 等操作会把打分变成概率。 argmax（取最大值索引） 从一组数里选出最大值对应的索引。 从概率表里挑“最大概率的词”。若最大值与次大值非常接近，微小数值误差就可能改变结果。 reproducibility（可复现性） 同样输入在多次运行中得到同样输出的能力。 “我今天跑一次、明天跑一次，结果要一样”。但官方文档常提醒：跨版本/设备未必能做到 100%。6 deterministic algorithms（确定性算法） 强制使用不会引入非确定性的实现路径（或直接报错）。 PyTorch 提供 torch.use_deterministic_algorithms 这类开关：要么走确定性实现，要么宁愿失败也不悄悄给你不确定结果。7 atomic operations（原子操作） 多线程并发更新同一个值时的“不可分割更新”。 像多人同时往同一个存钱罐里塞硬币：原子操作保证“不会塞丢”，但塞的先后顺序可能不同；配合浮点舍入，最终小数点后可能略有差异。cuDNN 文档提示这会影响可复现。8 parallel reduction（并行规约） 把很多数求和/合并的并行算法。 1000 个数求和，GPU 会分组并行相加再合并；但浮点加法对顺序敏感，合并顺序不同会带来极小误差。8 system_fingerprint（系统指纹） 供应商返回的后端配置标识，用于判断“后端是否变了”。 如果你昨天和今天的 fingerprint 不同，即便你参数不变，也很可能因为后端升级导致输出/一致率变化。3 batch / batching（批处理） 把多个请求合并成一个大计算以提升吞吐。 像等电梯：把多个人一起送上去更省电。但你上电梯时遇到的人不同（批次不同），系统内部安排可能不同，从而影响输出一致性。vLLM 提到“批不变”就是在解决这个。10 batch invariance（批不变） 同一输入在不同 batch 位置时输出保持一致。 你和别人一起算/单独算，结果都一样。vLLM 把它作为重要特性来保证服务化一致性。10 scheduling（调度） 决定哪些请求先算、怎么拼 batch、怎么分配资源。 同一条任务在不同队列里先后顺序不同，内部拼 batch 的方式就可能不同，从而影响输出。1011 XLA（编译器） 把计算图编译成高性能内核的编译器/后端。 “为了跑得更快”，编译器会换算法/融合算子；但文档说某些算子在 GPU 上可能非确定。9)^^[5](#术语 简要解释 更好理解的说法/例子 temperature（温度） 控制采样随机性的参数；通常通过缩放 logits 来改变分布“尖锐程度”。 想象你在抽奖：温度高=更敢抽小概率奖品；温度低=更倾向最大概率的选择。温度为 0 往往意味着不抽奖，直接选“最可能”的那个。4 decoding（解码） 把模型输出的概率分布一步步变成最终文本的过程。 模型每一步给出“下一词的概率表”，解码策略决定你怎么从表里选一个词。4 greedy decoding（贪婪解码） 每一步都选择概率最大的 token（argmax）。 每次都选“最有把握的答案”。如果第一名和第二名非常接近，哪怕概率表有极小抖动，第一名也可能换人。4 sampling（采样） 按概率分布随机抽取 token。 即便第一名概率最高，也可能抽到第二名、第三名；这能带来多样性，但会降低可复现性。 do_sample（是否采样） Transformers 里控制“走采样还是走确定性选择”的开关。 do_sample=True 时就像“抽签选词”；do_sample=False 时更像“按最高分直接选”。当它是 False 时，temperature 往往就没意义了（因为都不抽签了）。45 num_beams（束宽） 束搜索（beam search）一次保留的候选序列数量。 num_beams=1 就是不做束搜索；num_beams=5 类似“同时保留 5 条可能的续写路线再比较”。束越宽通常越慢，也更可能改变输出风格。4 top-p / nucleus sampling（核采样） 只在“累计概率达到 p 的候选集合”内采样。 如果 p=0.9，就先挑出一组 token，让它们的概率加起来到 0.9，再在这组里抽；比“全分布采样”更稳，也更能避免离谱尾部。13 beam search（束搜索） 同时保留多个候选序列，搜索更高整体概率的序列。 像走迷宫时同时保留几条“看起来最优”的路继续探索；但在开放式文本生成中可能导致重复等退化现象。13 degeneration（文本退化） 生成文本出现重复、空洞、过度模板化等现象。 例如模型不停输出“当然当然当然……”。论文指出贪婪/束搜索更容易触发这种问题。13 logits（对数几率/未归一化分数） 模型在 softmax 之前给每个 token 的“分数”。 可以把 logits 当成“每个候选词的打分”。温度、softmax 等操作会把打分变成概率。 argmax（取最大值索引） 从一组数里选出最大值对应的索引。 从概率表里挑“最大概率的词”。若最大值与次大值非常接近，微小数值误差就可能改变结果。 reproducibility（可复现性） 同样输入在多次运行中得到同样输出的能力。 “我今天跑一次、明天跑一次，结果要一样”。但官方文档常提醒：跨版本/设备未必能做到 100%。6 deterministic algorithms（确定性算法） 强制使用不会引入非确定性的实现路径（或直接报错）。 PyTorch 提供 torch.use_deterministic_algorithms 这类开关：要么走确定性实现，要么宁愿失败也不悄悄给你不确定结果。7 atomic operations（原子操作） 多线程并发更新同一个值时的“不可分割更新”。 像多人同时往同一个存钱罐里塞硬币：原子操作保证“不会塞丢”，但塞的先后顺序可能不同；配合浮点舍入，最终小数点后可能略有差异。cuDNN 文档提示这会影响可复现。8 parallel reduction（并行规约） 把很多数求和/合并的并行算法。 1000 个数求和，GPU 会分组并行相加再合并；但浮点加法对顺序敏感，合并顺序不同会带来极小误差。8 system_fingerprint（系统指纹） 供应商返回的后端配置标识，用于判断“后端是否变了”。 如果你昨天和今天的 fingerprint 不同，即便你参数不变，也很可能因为后端升级导致输出/一致率变化。3 batch / batching（批处理） 把多个请求合并成一个大计算以提升吞吐。 像等电梯：把多个人一起送上去更省电。但你上电梯时遇到的人不同（批次不同），系统内部安排可能不同，从而影响输出一致性。vLLM 提到“批不变”就是在解决这个。10 batch invariance（批不变） 同一输入在不同 batch 位置时输出保持一致。 你和别人一起算/单独算，结果都一样。vLLM 把它作为重要特性来保证服务化一致性。10 scheduling（调度） 决定哪些请求先算、怎么拼 batch、怎么分配资源。 同一条任务在不同队列里先后顺序不同，内部拼 batch 的方式就可能不同，从而影响输出。1011 XLA（编译器） 把计算图编译成高性能内核的编译器/后端。 “为了跑得更快”，编译器会换算法/融合算子；但文档说某些算子在 GPU 上可能非确定。9)^
num_beams（束宽） 束搜索（beam search）一次保留的候选序列数量。 num_beams=1 就是不做束搜索；num_beams=5 类似"同时保留 5 条可能的续写路线再比较"。束越宽通常越慢，也更可能改变输出风格。^[4](#术语 简要解释 更好理解的说法/例子 temperature（温度） 控制采样随机性的参数；通常通过缩放 logits 来改变分布“尖锐程度”。 想象你在抽奖：温度高=更敢抽小概率奖品；温度低=更倾向最大概率的选择。温度为 0 往往意味着不抽奖，直接选“最可能”的那个。4 decoding（解码） 把模型输出的概率分布一步步变成最终文本的过程。 模型每一步给出“下一词的概率表”，解码策略决定你怎么从表里选一个词。4 greedy decoding（贪婪解码） 每一步都选择概率最大的 token（argmax）。 每次都选“最有把握的答案”。如果第一名和第二名非常接近，哪怕概率表有极小抖动，第一名也可能换人。4 sampling（采样） 按概率分布随机抽取 token。 即便第一名概率最高，也可能抽到第二名、第三名；这能带来多样性，但会降低可复现性。 do_sample（是否采样） Transformers 里控制“走采样还是走确定性选择”的开关。 do_sample=True 时就像“抽签选词”；do_sample=False 时更像“按最高分直接选”。当它是 False 时，temperature 往往就没意义了（因为都不抽签了）。45 num_beams（束宽） 束搜索（beam search）一次保留的候选序列数量。 num_beams=1 就是不做束搜索；num_beams=5 类似“同时保留 5 条可能的续写路线再比较”。束越宽通常越慢，也更可能改变输出风格。4 top-p / nucleus sampling（核采样） 只在“累计概率达到 p 的候选集合”内采样。 如果 p=0.9，就先挑出一组 token，让它们的概率加起来到 0.9，再在这组里抽；比“全分布采样”更稳，也更能避免离谱尾部。13 beam search（束搜索） 同时保留多个候选序列，搜索更高整体概率的序列。 像走迷宫时同时保留几条“看起来最优”的路继续探索；但在开放式文本生成中可能导致重复等退化现象。13 degeneration（文本退化） 生成文本出现重复、空洞、过度模板化等现象。 例如模型不停输出“当然当然当然……”。论文指出贪婪/束搜索更容易触发这种问题。13 logits（对数几率/未归一化分数） 模型在 softmax 之前给每个 token 的“分数”。 可以把 logits 当成“每个候选词的打分”。温度、softmax 等操作会把打分变成概率。 argmax（取最大值索引） 从一组数里选出最大值对应的索引。 从概率表里挑“最大概率的词”。若最大值与次大值非常接近，微小数值误差就可能改变结果。 reproducibility（可复现性） 同样输入在多次运行中得到同样输出的能力。 “我今天跑一次、明天跑一次，结果要一样”。但官方文档常提醒：跨版本/设备未必能做到 100%。6 deterministic algorithms（确定性算法） 强制使用不会引入非确定性的实现路径（或直接报错）。 PyTorch 提供 torch.use_deterministic_algorithms 这类开关：要么走确定性实现，要么宁愿失败也不悄悄给你不确定结果。7 atomic operations（原子操作） 多线程并发更新同一个值时的“不可分割更新”。 像多人同时往同一个存钱罐里塞硬币：原子操作保证“不会塞丢”，但塞的先后顺序可能不同；配合浮点舍入，最终小数点后可能略有差异。cuDNN 文档提示这会影响可复现。8 parallel reduction（并行规约） 把很多数求和/合并的并行算法。 1000 个数求和，GPU 会分组并行相加再合并；但浮点加法对顺序敏感，合并顺序不同会带来极小误差。8 system_fingerprint（系统指纹） 供应商返回的后端配置标识，用于判断“后端是否变了”。 如果你昨天和今天的 fingerprint 不同，即便你参数不变，也很可能因为后端升级导致输出/一致率变化。3 batch / batching（批处理） 把多个请求合并成一个大计算以提升吞吐。 像等电梯：把多个人一起送上去更省电。但你上电梯时遇到的人不同（批次不同），系统内部安排可能不同，从而影响输出一致性。vLLM 提到“批不变”就是在解决这个。10 batch invariance（批不变） 同一输入在不同 batch 位置时输出保持一致。 你和别人一起算/单独算，结果都一样。vLLM 把它作为重要特性来保证服务化一致性。10 scheduling（调度） 决定哪些请求先算、怎么拼 batch、怎么分配资源。 同一条任务在不同队列里先后顺序不同，内部拼 batch 的方式就可能不同，从而影响输出。1011 XLA（编译器） 把计算图编译成高性能内核的编译器/后端。 “为了跑得更快”，编译器会换算法/融合算子；但文档说某些算子在 GPU 上可能非确定。9)^
top-p / nucleus sampling（核采样） 只在"累计概率达到 p 的候选集合"内采样。 如果 p=0.9，就先挑出一组 token，让它们的概率加起来到 0.9，再在这组里抽；比"全分布采样"更稳，也更能避免离谱尾部。^[13](#术语 简要解释 更好理解的说法/例子 temperature（温度） 控制采样随机性的参数；通常通过缩放 logits 来改变分布“尖锐程度”。 想象你在抽奖：温度高=更敢抽小概率奖品；温度低=更倾向最大概率的选择。温度为 0 往往意味着不抽奖，直接选“最可能”的那个。4 decoding（解码） 把模型输出的概率分布一步步变成最终文本的过程。 模型每一步给出“下一词的概率表”，解码策略决定你怎么从表里选一个词。4 greedy decoding（贪婪解码） 每一步都选择概率最大的 token（argmax）。 每次都选“最有把握的答案”。如果第一名和第二名非常接近，哪怕概率表有极小抖动，第一名也可能换人。4 sampling（采样） 按概率分布随机抽取 token。 即便第一名概率最高，也可能抽到第二名、第三名；这能带来多样性，但会降低可复现性。 do_sample（是否采样） Transformers 里控制“走采样还是走确定性选择”的开关。 do_sample=True 时就像“抽签选词”；do_sample=False 时更像“按最高分直接选”。当它是 False 时，temperature 往往就没意义了（因为都不抽签了）。45 num_beams（束宽） 束搜索（beam search）一次保留的候选序列数量。 num_beams=1 就是不做束搜索；num_beams=5 类似“同时保留 5 条可能的续写路线再比较”。束越宽通常越慢，也更可能改变输出风格。4 top-p / nucleus sampling（核采样） 只在“累计概率达到 p 的候选集合”内采样。 如果 p=0.9，就先挑出一组 token，让它们的概率加起来到 0.9，再在这组里抽；比“全分布采样”更稳，也更能避免离谱尾部。13 beam search（束搜索） 同时保留多个候选序列，搜索更高整体概率的序列。 像走迷宫时同时保留几条“看起来最优”的路继续探索；但在开放式文本生成中可能导致重复等退化现象。13 degeneration（文本退化） 生成文本出现重复、空洞、过度模板化等现象。 例如模型不停输出“当然当然当然……”。论文指出贪婪/束搜索更容易触发这种问题。13 logits（对数几率/未归一化分数） 模型在 softmax 之前给每个 token 的“分数”。 可以把 logits 当成“每个候选词的打分”。温度、softmax 等操作会把打分变成概率。 argmax（取最大值索引） 从一组数里选出最大值对应的索引。 从概率表里挑“最大概率的词”。若最大值与次大值非常接近，微小数值误差就可能改变结果。 reproducibility（可复现性） 同样输入在多次运行中得到同样输出的能力。 “我今天跑一次、明天跑一次，结果要一样”。但官方文档常提醒：跨版本/设备未必能做到 100%。6 deterministic algorithms（确定性算法） 强制使用不会引入非确定性的实现路径（或直接报错）。 PyTorch 提供 torch.use_deterministic_algorithms 这类开关：要么走确定性实现，要么宁愿失败也不悄悄给你不确定结果。7 atomic operations（原子操作） 多线程并发更新同一个值时的“不可分割更新”。 像多人同时往同一个存钱罐里塞硬币：原子操作保证“不会塞丢”，但塞的先后顺序可能不同；配合浮点舍入，最终小数点后可能略有差异。cuDNN 文档提示这会影响可复现。8 parallel reduction（并行规约） 把很多数求和/合并的并行算法。 1000 个数求和，GPU 会分组并行相加再合并；但浮点加法对顺序敏感，合并顺序不同会带来极小误差。8 system_fingerprint（系统指纹） 供应商返回的后端配置标识，用于判断“后端是否变了”。 如果你昨天和今天的 fingerprint 不同，即便你参数不变，也很可能因为后端升级导致输出/一致率变化。3 batch / batching（批处理） 把多个请求合并成一个大计算以提升吞吐。 像等电梯：把多个人一起送上去更省电。但你上电梯时遇到的人不同（批次不同），系统内部安排可能不同，从而影响输出一致性。vLLM 提到“批不变”就是在解决这个。10 batch invariance（批不变） 同一输入在不同 batch 位置时输出保持一致。 你和别人一起算/单独算，结果都一样。vLLM 把它作为重要特性来保证服务化一致性。10 scheduling（调度） 决定哪些请求先算、怎么拼 batch、怎么分配资源。 同一条任务在不同队列里先后顺序不同，内部拼 batch 的方式就可能不同，从而影响输出。1011 XLA（编译器） 把计算图编译成高性能内核的编译器/后端。 “为了跑得更快”，编译器会换算法/融合算子；但文档说某些算子在 GPU 上可能非确定。9)^
beam search（束搜索） 同时保留多个候选序列，搜索更高整体概率的序列。 像走迷宫时同时保留几条"看起来最优"的路继续探索；但在开放式文本生成中可能导致重复等退化现象。^[13](#术语 简要解释 更好理解的说法/例子 temperature（温度） 控制采样随机性的参数；通常通过缩放 logits 来改变分布“尖锐程度”。 想象你在抽奖：温度高=更敢抽小概率奖品；温度低=更倾向最大概率的选择。温度为 0 往往意味着不抽奖，直接选“最可能”的那个。4 decoding（解码） 把模型输出的概率分布一步步变成最终文本的过程。 模型每一步给出“下一词的概率表”，解码策略决定你怎么从表里选一个词。4 greedy decoding（贪婪解码） 每一步都选择概率最大的 token（argmax）。 每次都选“最有把握的答案”。如果第一名和第二名非常接近，哪怕概率表有极小抖动，第一名也可能换人。4 sampling（采样） 按概率分布随机抽取 token。 即便第一名概率最高，也可能抽到第二名、第三名；这能带来多样性，但会降低可复现性。 do_sample（是否采样） Transformers 里控制“走采样还是走确定性选择”的开关。 do_sample=True 时就像“抽签选词”；do_sample=False 时更像“按最高分直接选”。当它是 False 时，temperature 往往就没意义了（因为都不抽签了）。45 num_beams（束宽） 束搜索（beam search）一次保留的候选序列数量。 num_beams=1 就是不做束搜索；num_beams=5 类似“同时保留 5 条可能的续写路线再比较”。束越宽通常越慢，也更可能改变输出风格。4 top-p / nucleus sampling（核采样） 只在“累计概率达到 p 的候选集合”内采样。 如果 p=0.9，就先挑出一组 token，让它们的概率加起来到 0.9，再在这组里抽；比“全分布采样”更稳，也更能避免离谱尾部。13 beam search（束搜索） 同时保留多个候选序列，搜索更高整体概率的序列。 像走迷宫时同时保留几条“看起来最优”的路继续探索；但在开放式文本生成中可能导致重复等退化现象。13 degeneration（文本退化） 生成文本出现重复、空洞、过度模板化等现象。 例如模型不停输出“当然当然当然……”。论文指出贪婪/束搜索更容易触发这种问题。13 logits（对数几率/未归一化分数） 模型在 softmax 之前给每个 token 的“分数”。 可以把 logits 当成“每个候选词的打分”。温度、softmax 等操作会把打分变成概率。 argmax（取最大值索引） 从一组数里选出最大值对应的索引。 从概率表里挑“最大概率的词”。若最大值与次大值非常接近，微小数值误差就可能改变结果。 reproducibility（可复现性） 同样输入在多次运行中得到同样输出的能力。 “我今天跑一次、明天跑一次，结果要一样”。但官方文档常提醒：跨版本/设备未必能做到 100%。6 deterministic algorithms（确定性算法） 强制使用不会引入非确定性的实现路径（或直接报错）。 PyTorch 提供 torch.use_deterministic_algorithms 这类开关：要么走确定性实现，要么宁愿失败也不悄悄给你不确定结果。7 atomic operations（原子操作） 多线程并发更新同一个值时的“不可分割更新”。 像多人同时往同一个存钱罐里塞硬币：原子操作保证“不会塞丢”，但塞的先后顺序可能不同；配合浮点舍入，最终小数点后可能略有差异。cuDNN 文档提示这会影响可复现。8 parallel reduction（并行规约） 把很多数求和/合并的并行算法。 1000 个数求和，GPU 会分组并行相加再合并；但浮点加法对顺序敏感，合并顺序不同会带来极小误差。8 system_fingerprint（系统指纹） 供应商返回的后端配置标识，用于判断“后端是否变了”。 如果你昨天和今天的 fingerprint 不同，即便你参数不变，也很可能因为后端升级导致输出/一致率变化。3 batch / batching（批处理） 把多个请求合并成一个大计算以提升吞吐。 像等电梯：把多个人一起送上去更省电。但你上电梯时遇到的人不同（批次不同），系统内部安排可能不同，从而影响输出一致性。vLLM 提到“批不变”就是在解决这个。10 batch invariance（批不变） 同一输入在不同 batch 位置时输出保持一致。 你和别人一起算/单独算，结果都一样。vLLM 把它作为重要特性来保证服务化一致性。10 scheduling（调度） 决定哪些请求先算、怎么拼 batch、怎么分配资源。 同一条任务在不同队列里先后顺序不同，内部拼 batch 的方式就可能不同，从而影响输出。1011 XLA（编译器） 把计算图编译成高性能内核的编译器/后端。 “为了跑得更快”，编译器会换算法/融合算子；但文档说某些算子在 GPU 上可能非确定。9)^
degeneration（文本退化） 生成文本出现重复、空洞、过度模板化等现象。 例如模型不停输出"当然当然当然......"。论文指出贪婪/束搜索更容易触发这种问题。^[13](#术语 简要解释 更好理解的说法/例子 temperature（温度） 控制采样随机性的参数；通常通过缩放 logits 来改变分布“尖锐程度”。 想象你在抽奖：温度高=更敢抽小概率奖品；温度低=更倾向最大概率的选择。温度为 0 往往意味着不抽奖，直接选“最可能”的那个。4 decoding（解码） 把模型输出的概率分布一步步变成最终文本的过程。 模型每一步给出“下一词的概率表”，解码策略决定你怎么从表里选一个词。4 greedy decoding（贪婪解码） 每一步都选择概率最大的 token（argmax）。 每次都选“最有把握的答案”。如果第一名和第二名非常接近，哪怕概率表有极小抖动，第一名也可能换人。4 sampling（采样） 按概率分布随机抽取 token。 即便第一名概率最高，也可能抽到第二名、第三名；这能带来多样性，但会降低可复现性。 do_sample（是否采样） Transformers 里控制“走采样还是走确定性选择”的开关。 do_sample=True 时就像“抽签选词”；do_sample=False 时更像“按最高分直接选”。当它是 False 时，temperature 往往就没意义了（因为都不抽签了）。45 num_beams（束宽） 束搜索（beam search）一次保留的候选序列数量。 num_beams=1 就是不做束搜索；num_beams=5 类似“同时保留 5 条可能的续写路线再比较”。束越宽通常越慢，也更可能改变输出风格。4 top-p / nucleus sampling（核采样） 只在“累计概率达到 p 的候选集合”内采样。 如果 p=0.9，就先挑出一组 token，让它们的概率加起来到 0.9，再在这组里抽；比“全分布采样”更稳，也更能避免离谱尾部。13 beam search（束搜索） 同时保留多个候选序列，搜索更高整体概率的序列。 像走迷宫时同时保留几条“看起来最优”的路继续探索；但在开放式文本生成中可能导致重复等退化现象。13 degeneration（文本退化） 生成文本出现重复、空洞、过度模板化等现象。 例如模型不停输出“当然当然当然……”。论文指出贪婪/束搜索更容易触发这种问题。13 logits（对数几率/未归一化分数） 模型在 softmax 之前给每个 token 的“分数”。 可以把 logits 当成“每个候选词的打分”。温度、softmax 等操作会把打分变成概率。 argmax（取最大值索引） 从一组数里选出最大值对应的索引。 从概率表里挑“最大概率的词”。若最大值与次大值非常接近，微小数值误差就可能改变结果。 reproducibility（可复现性） 同样输入在多次运行中得到同样输出的能力。 “我今天跑一次、明天跑一次，结果要一样”。但官方文档常提醒：跨版本/设备未必能做到 100%。6 deterministic algorithms（确定性算法） 强制使用不会引入非确定性的实现路径（或直接报错）。 PyTorch 提供 torch.use_deterministic_algorithms 这类开关：要么走确定性实现，要么宁愿失败也不悄悄给你不确定结果。7 atomic operations（原子操作） 多线程并发更新同一个值时的“不可分割更新”。 像多人同时往同一个存钱罐里塞硬币：原子操作保证“不会塞丢”，但塞的先后顺序可能不同；配合浮点舍入，最终小数点后可能略有差异。cuDNN 文档提示这会影响可复现。8 parallel reduction（并行规约） 把很多数求和/合并的并行算法。 1000 个数求和，GPU 会分组并行相加再合并；但浮点加法对顺序敏感，合并顺序不同会带来极小误差。8 system_fingerprint（系统指纹） 供应商返回的后端配置标识，用于判断“后端是否变了”。 如果你昨天和今天的 fingerprint 不同，即便你参数不变，也很可能因为后端升级导致输出/一致率变化。3 batch / batching（批处理） 把多个请求合并成一个大计算以提升吞吐。 像等电梯：把多个人一起送上去更省电。但你上电梯时遇到的人不同（批次不同），系统内部安排可能不同，从而影响输出一致性。vLLM 提到“批不变”就是在解决这个。10 batch invariance（批不变） 同一输入在不同 batch 位置时输出保持一致。 你和别人一起算/单独算，结果都一样。vLLM 把它作为重要特性来保证服务化一致性。10 scheduling（调度） 决定哪些请求先算、怎么拼 batch、怎么分配资源。 同一条任务在不同队列里先后顺序不同，内部拼 batch 的方式就可能不同，从而影响输出。1011 XLA（编译器） 把计算图编译成高性能内核的编译器/后端。 “为了跑得更快”，编译器会换算法/融合算子；但文档说某些算子在 GPU 上可能非确定。9)^
logits（对数几率/未归一化分数） 模型在 softmax 之前给每个 token 的"分数"。 可以把 logits 当成"每个候选词的打分"。温度、softmax 等操作会把打分变成概率。
argmax（取最大值索引） 从一组数里选出最大值对应的索引。 从概率表里挑"最大概率的词"。若最大值与次大值非常接近，微小数值误差就可能改变结果。
reproducibility（可复现性） 同样输入在多次运行中得到同样输出的能力。 "我今天跑一次、明天跑一次，结果要一样"。但官方文档常提醒：跨版本/设备未必能做到 100%。^[6](#术语 简要解释 更好理解的说法/例子 temperature（温度） 控制采样随机性的参数；通常通过缩放 logits 来改变分布“尖锐程度”。 想象你在抽奖：温度高=更敢抽小概率奖品；温度低=更倾向最大概率的选择。温度为 0 往往意味着不抽奖，直接选“最可能”的那个。4 decoding（解码） 把模型输出的概率分布一步步变成最终文本的过程。 模型每一步给出“下一词的概率表”，解码策略决定你怎么从表里选一个词。4 greedy decoding（贪婪解码） 每一步都选择概率最大的 token（argmax）。 每次都选“最有把握的答案”。如果第一名和第二名非常接近，哪怕概率表有极小抖动，第一名也可能换人。4 sampling（采样） 按概率分布随机抽取 token。 即便第一名概率最高，也可能抽到第二名、第三名；这能带来多样性，但会降低可复现性。 do_sample（是否采样） Transformers 里控制“走采样还是走确定性选择”的开关。 do_sample=True 时就像“抽签选词”；do_sample=False 时更像“按最高分直接选”。当它是 False 时，temperature 往往就没意义了（因为都不抽签了）。45 num_beams（束宽） 束搜索（beam search）一次保留的候选序列数量。 num_beams=1 就是不做束搜索；num_beams=5 类似“同时保留 5 条可能的续写路线再比较”。束越宽通常越慢，也更可能改变输出风格。4 top-p / nucleus sampling（核采样） 只在“累计概率达到 p 的候选集合”内采样。 如果 p=0.9，就先挑出一组 token，让它们的概率加起来到 0.9，再在这组里抽；比“全分布采样”更稳，也更能避免离谱尾部。13 beam search（束搜索） 同时保留多个候选序列，搜索更高整体概率的序列。 像走迷宫时同时保留几条“看起来最优”的路继续探索；但在开放式文本生成中可能导致重复等退化现象。13 degeneration（文本退化） 生成文本出现重复、空洞、过度模板化等现象。 例如模型不停输出“当然当然当然……”。论文指出贪婪/束搜索更容易触发这种问题。13 logits（对数几率/未归一化分数） 模型在 softmax 之前给每个 token 的“分数”。 可以把 logits 当成“每个候选词的打分”。温度、softmax 等操作会把打分变成概率。 argmax（取最大值索引） 从一组数里选出最大值对应的索引。 从概率表里挑“最大概率的词”。若最大值与次大值非常接近，微小数值误差就可能改变结果。 reproducibility（可复现性） 同样输入在多次运行中得到同样输出的能力。 “我今天跑一次、明天跑一次，结果要一样”。但官方文档常提醒：跨版本/设备未必能做到 100%。6 deterministic algorithms（确定性算法） 强制使用不会引入非确定性的实现路径（或直接报错）。 PyTorch 提供 torch.use_deterministic_algorithms 这类开关：要么走确定性实现，要么宁愿失败也不悄悄给你不确定结果。7 atomic operations（原子操作） 多线程并发更新同一个值时的“不可分割更新”。 像多人同时往同一个存钱罐里塞硬币：原子操作保证“不会塞丢”，但塞的先后顺序可能不同；配合浮点舍入，最终小数点后可能略有差异。cuDNN 文档提示这会影响可复现。8 parallel reduction（并行规约） 把很多数求和/合并的并行算法。 1000 个数求和，GPU 会分组并行相加再合并；但浮点加法对顺序敏感，合并顺序不同会带来极小误差。8 system_fingerprint（系统指纹） 供应商返回的后端配置标识，用于判断“后端是否变了”。 如果你昨天和今天的 fingerprint 不同，即便你参数不变，也很可能因为后端升级导致输出/一致率变化。3 batch / batching（批处理） 把多个请求合并成一个大计算以提升吞吐。 像等电梯：把多个人一起送上去更省电。但你上电梯时遇到的人不同（批次不同），系统内部安排可能不同，从而影响输出一致性。vLLM 提到“批不变”就是在解决这个。10 batch invariance（批不变） 同一输入在不同 batch 位置时输出保持一致。 你和别人一起算/单独算，结果都一样。vLLM 把它作为重要特性来保证服务化一致性。10 scheduling（调度） 决定哪些请求先算、怎么拼 batch、怎么分配资源。 同一条任务在不同队列里先后顺序不同，内部拼 batch 的方式就可能不同，从而影响输出。1011 XLA（编译器） 把计算图编译成高性能内核的编译器/后端。 “为了跑得更快”，编译器会换算法/融合算子；但文档说某些算子在 GPU 上可能非确定。9)^
deterministic algorithms（确定性算法） 强制使用不会引入非确定性的实现路径（或直接报错）。 PyTorch 提供 torch.use_deterministic_algorithms 这类开关：要么走确定性实现，要么宁愿失败也不悄悄给你不确定结果。^[7](#术语 简要解释 更好理解的说法/例子 temperature（温度） 控制采样随机性的参数；通常通过缩放 logits 来改变分布“尖锐程度”。 想象你在抽奖：温度高=更敢抽小概率奖品；温度低=更倾向最大概率的选择。温度为 0 往往意味着不抽奖，直接选“最可能”的那个。4 decoding（解码） 把模型输出的概率分布一步步变成最终文本的过程。 模型每一步给出“下一词的概率表”，解码策略决定你怎么从表里选一个词。4 greedy decoding（贪婪解码） 每一步都选择概率最大的 token（argmax）。 每次都选“最有把握的答案”。如果第一名和第二名非常接近，哪怕概率表有极小抖动，第一名也可能换人。4 sampling（采样） 按概率分布随机抽取 token。 即便第一名概率最高，也可能抽到第二名、第三名；这能带来多样性，但会降低可复现性。 do_sample（是否采样） Transformers 里控制“走采样还是走确定性选择”的开关。 do_sample=True 时就像“抽签选词”；do_sample=False 时更像“按最高分直接选”。当它是 False 时，temperature 往往就没意义了（因为都不抽签了）。45 num_beams（束宽） 束搜索（beam search）一次保留的候选序列数量。 num_beams=1 就是不做束搜索；num_beams=5 类似“同时保留 5 条可能的续写路线再比较”。束越宽通常越慢，也更可能改变输出风格。4 top-p / nucleus sampling（核采样） 只在“累计概率达到 p 的候选集合”内采样。 如果 p=0.9，就先挑出一组 token，让它们的概率加起来到 0.9，再在这组里抽；比“全分布采样”更稳，也更能避免离谱尾部。13 beam search（束搜索） 同时保留多个候选序列，搜索更高整体概率的序列。 像走迷宫时同时保留几条“看起来最优”的路继续探索；但在开放式文本生成中可能导致重复等退化现象。13 degeneration（文本退化） 生成文本出现重复、空洞、过度模板化等现象。 例如模型不停输出“当然当然当然……”。论文指出贪婪/束搜索更容易触发这种问题。13 logits（对数几率/未归一化分数） 模型在 softmax 之前给每个 token 的“分数”。 可以把 logits 当成“每个候选词的打分”。温度、softmax 等操作会把打分变成概率。 argmax（取最大值索引） 从一组数里选出最大值对应的索引。 从概率表里挑“最大概率的词”。若最大值与次大值非常接近，微小数值误差就可能改变结果。 reproducibility（可复现性） 同样输入在多次运行中得到同样输出的能力。 “我今天跑一次、明天跑一次，结果要一样”。但官方文档常提醒：跨版本/设备未必能做到 100%。6 deterministic algorithms（确定性算法） 强制使用不会引入非确定性的实现路径（或直接报错）。 PyTorch 提供 torch.use_deterministic_algorithms 这类开关：要么走确定性实现，要么宁愿失败也不悄悄给你不确定结果。7 atomic operations（原子操作） 多线程并发更新同一个值时的“不可分割更新”。 像多人同时往同一个存钱罐里塞硬币：原子操作保证“不会塞丢”，但塞的先后顺序可能不同；配合浮点舍入，最终小数点后可能略有差异。cuDNN 文档提示这会影响可复现。8 parallel reduction（并行规约） 把很多数求和/合并的并行算法。 1000 个数求和，GPU 会分组并行相加再合并；但浮点加法对顺序敏感，合并顺序不同会带来极小误差。8 system_fingerprint（系统指纹） 供应商返回的后端配置标识，用于判断“后端是否变了”。 如果你昨天和今天的 fingerprint 不同，即便你参数不变，也很可能因为后端升级导致输出/一致率变化。3 batch / batching（批处理） 把多个请求合并成一个大计算以提升吞吐。 像等电梯：把多个人一起送上去更省电。但你上电梯时遇到的人不同（批次不同），系统内部安排可能不同，从而影响输出一致性。vLLM 提到“批不变”就是在解决这个。10 batch invariance（批不变） 同一输入在不同 batch 位置时输出保持一致。 你和别人一起算/单独算，结果都一样。vLLM 把它作为重要特性来保证服务化一致性。10 scheduling（调度） 决定哪些请求先算、怎么拼 batch、怎么分配资源。 同一条任务在不同队列里先后顺序不同，内部拼 batch 的方式就可能不同，从而影响输出。1011 XLA（编译器） 把计算图编译成高性能内核的编译器/后端。 “为了跑得更快”，编译器会换算法/融合算子；但文档说某些算子在 GPU 上可能非确定。9)^
atomic operations（原子操作） 多线程并发更新同一个值时的"不可分割更新"。 像多人同时往同一个存钱罐里塞硬币：原子操作保证"不会塞丢"，但塞的先后顺序可能不同；配合浮点舍入，最终小数点后可能略有差异。cuDNN 文档提示这会影响可复现。^[8](#术语 简要解释 更好理解的说法/例子 temperature（温度） 控制采样随机性的参数；通常通过缩放 logits 来改变分布“尖锐程度”。 想象你在抽奖：温度高=更敢抽小概率奖品；温度低=更倾向最大概率的选择。温度为 0 往往意味着不抽奖，直接选“最可能”的那个。4 decoding（解码） 把模型输出的概率分布一步步变成最终文本的过程。 模型每一步给出“下一词的概率表”，解码策略决定你怎么从表里选一个词。4 greedy decoding（贪婪解码） 每一步都选择概率最大的 token（argmax）。 每次都选“最有把握的答案”。如果第一名和第二名非常接近，哪怕概率表有极小抖动，第一名也可能换人。4 sampling（采样） 按概率分布随机抽取 token。 即便第一名概率最高，也可能抽到第二名、第三名；这能带来多样性，但会降低可复现性。 do_sample（是否采样） Transformers 里控制“走采样还是走确定性选择”的开关。 do_sample=True 时就像“抽签选词”；do_sample=False 时更像“按最高分直接选”。当它是 False 时，temperature 往往就没意义了（因为都不抽签了）。45 num_beams（束宽） 束搜索（beam search）一次保留的候选序列数量。 num_beams=1 就是不做束搜索；num_beams=5 类似“同时保留 5 条可能的续写路线再比较”。束越宽通常越慢，也更可能改变输出风格。4 top-p / nucleus sampling（核采样） 只在“累计概率达到 p 的候选集合”内采样。 如果 p=0.9，就先挑出一组 token，让它们的概率加起来到 0.9，再在这组里抽；比“全分布采样”更稳，也更能避免离谱尾部。13 beam search（束搜索） 同时保留多个候选序列，搜索更高整体概率的序列。 像走迷宫时同时保留几条“看起来最优”的路继续探索；但在开放式文本生成中可能导致重复等退化现象。13 degeneration（文本退化） 生成文本出现重复、空洞、过度模板化等现象。 例如模型不停输出“当然当然当然……”。论文指出贪婪/束搜索更容易触发这种问题。13 logits（对数几率/未归一化分数） 模型在 softmax 之前给每个 token 的“分数”。 可以把 logits 当成“每个候选词的打分”。温度、softmax 等操作会把打分变成概率。 argmax（取最大值索引） 从一组数里选出最大值对应的索引。 从概率表里挑“最大概率的词”。若最大值与次大值非常接近，微小数值误差就可能改变结果。 reproducibility（可复现性） 同样输入在多次运行中得到同样输出的能力。 “我今天跑一次、明天跑一次，结果要一样”。但官方文档常提醒：跨版本/设备未必能做到 100%。6 deterministic algorithms（确定性算法） 强制使用不会引入非确定性的实现路径（或直接报错）。 PyTorch 提供 torch.use_deterministic_algorithms 这类开关：要么走确定性实现，要么宁愿失败也不悄悄给你不确定结果。7 atomic operations（原子操作） 多线程并发更新同一个值时的“不可分割更新”。 像多人同时往同一个存钱罐里塞硬币：原子操作保证“不会塞丢”，但塞的先后顺序可能不同；配合浮点舍入，最终小数点后可能略有差异。cuDNN 文档提示这会影响可复现。8 parallel reduction（并行规约） 把很多数求和/合并的并行算法。 1000 个数求和，GPU 会分组并行相加再合并；但浮点加法对顺序敏感，合并顺序不同会带来极小误差。8 system_fingerprint（系统指纹） 供应商返回的后端配置标识，用于判断“后端是否变了”。 如果你昨天和今天的 fingerprint 不同，即便你参数不变，也很可能因为后端升级导致输出/一致率变化。3 batch / batching（批处理） 把多个请求合并成一个大计算以提升吞吐。 像等电梯：把多个人一起送上去更省电。但你上电梯时遇到的人不同（批次不同），系统内部安排可能不同，从而影响输出一致性。vLLM 提到“批不变”就是在解决这个。10 batch invariance（批不变） 同一输入在不同 batch 位置时输出保持一致。 你和别人一起算/单独算，结果都一样。vLLM 把它作为重要特性来保证服务化一致性。10 scheduling（调度） 决定哪些请求先算、怎么拼 batch、怎么分配资源。 同一条任务在不同队列里先后顺序不同，内部拼 batch 的方式就可能不同，从而影响输出。1011 XLA（编译器） 把计算图编译成高性能内核的编译器/后端。 “为了跑得更快”，编译器会换算法/融合算子；但文档说某些算子在 GPU 上可能非确定。9)^
parallel reduction（并行规约） 把很多数求和/合并的并行算法。 1000 个数求和，GPU 会分组并行相加再合并；但浮点加法对顺序敏感，合并顺序不同会带来极小误差。^[8](#术语 简要解释 更好理解的说法/例子 temperature（温度） 控制采样随机性的参数；通常通过缩放 logits 来改变分布“尖锐程度”。 想象你在抽奖：温度高=更敢抽小概率奖品；温度低=更倾向最大概率的选择。温度为 0 往往意味着不抽奖，直接选“最可能”的那个。4 decoding（解码） 把模型输出的概率分布一步步变成最终文本的过程。 模型每一步给出“下一词的概率表”，解码策略决定你怎么从表里选一个词。4 greedy decoding（贪婪解码） 每一步都选择概率最大的 token（argmax）。 每次都选“最有把握的答案”。如果第一名和第二名非常接近，哪怕概率表有极小抖动，第一名也可能换人。4 sampling（采样） 按概率分布随机抽取 token。 即便第一名概率最高，也可能抽到第二名、第三名；这能带来多样性，但会降低可复现性。 do_sample（是否采样） Transformers 里控制“走采样还是走确定性选择”的开关。 do_sample=True 时就像“抽签选词”；do_sample=False 时更像“按最高分直接选”。当它是 False 时，temperature 往往就没意义了（因为都不抽签了）。45 num_beams（束宽） 束搜索（beam search）一次保留的候选序列数量。 num_beams=1 就是不做束搜索；num_beams=5 类似“同时保留 5 条可能的续写路线再比较”。束越宽通常越慢，也更可能改变输出风格。4 top-p / nucleus sampling（核采样） 只在“累计概率达到 p 的候选集合”内采样。 如果 p=0.9，就先挑出一组 token，让它们的概率加起来到 0.9，再在这组里抽；比“全分布采样”更稳，也更能避免离谱尾部。13 beam search（束搜索） 同时保留多个候选序列，搜索更高整体概率的序列。 像走迷宫时同时保留几条“看起来最优”的路继续探索；但在开放式文本生成中可能导致重复等退化现象。13 degeneration（文本退化） 生成文本出现重复、空洞、过度模板化等现象。 例如模型不停输出“当然当然当然……”。论文指出贪婪/束搜索更容易触发这种问题。13 logits（对数几率/未归一化分数） 模型在 softmax 之前给每个 token 的“分数”。 可以把 logits 当成“每个候选词的打分”。温度、softmax 等操作会把打分变成概率。 argmax（取最大值索引） 从一组数里选出最大值对应的索引。 从概率表里挑“最大概率的词”。若最大值与次大值非常接近，微小数值误差就可能改变结果。 reproducibility（可复现性） 同样输入在多次运行中得到同样输出的能力。 “我今天跑一次、明天跑一次，结果要一样”。但官方文档常提醒：跨版本/设备未必能做到 100%。6 deterministic algorithms（确定性算法） 强制使用不会引入非确定性的实现路径（或直接报错）。 PyTorch 提供 torch.use_deterministic_algorithms 这类开关：要么走确定性实现，要么宁愿失败也不悄悄给你不确定结果。7 atomic operations（原子操作） 多线程并发更新同一个值时的“不可分割更新”。 像多人同时往同一个存钱罐里塞硬币：原子操作保证“不会塞丢”，但塞的先后顺序可能不同；配合浮点舍入，最终小数点后可能略有差异。cuDNN 文档提示这会影响可复现。8 parallel reduction（并行规约） 把很多数求和/合并的并行算法。 1000 个数求和，GPU 会分组并行相加再合并；但浮点加法对顺序敏感，合并顺序不同会带来极小误差。8 system_fingerprint（系统指纹） 供应商返回的后端配置标识，用于判断“后端是否变了”。 如果你昨天和今天的 fingerprint 不同，即便你参数不变，也很可能因为后端升级导致输出/一致率变化。3 batch / batching（批处理） 把多个请求合并成一个大计算以提升吞吐。 像等电梯：把多个人一起送上去更省电。但你上电梯时遇到的人不同（批次不同），系统内部安排可能不同，从而影响输出一致性。vLLM 提到“批不变”就是在解决这个。10 batch invariance（批不变） 同一输入在不同 batch 位置时输出保持一致。 你和别人一起算/单独算，结果都一样。vLLM 把它作为重要特性来保证服务化一致性。10 scheduling（调度） 决定哪些请求先算、怎么拼 batch、怎么分配资源。 同一条任务在不同队列里先后顺序不同，内部拼 batch 的方式就可能不同，从而影响输出。1011 XLA（编译器） 把计算图编译成高性能内核的编译器/后端。 “为了跑得更快”，编译器会换算法/融合算子；但文档说某些算子在 GPU 上可能非确定。9)^
system_fingerprint（系统指纹） 供应商返回的后端配置标识，用于判断"后端是否变了"。 如果你昨天和今天的 fingerprint 不同，即便你参数不变，也很可能因为后端升级导致输出/一致率变化。^[3](#术语 简要解释 更好理解的说法/例子 temperature（温度） 控制采样随机性的参数；通常通过缩放 logits 来改变分布“尖锐程度”。 想象你在抽奖：温度高=更敢抽小概率奖品；温度低=更倾向最大概率的选择。温度为 0 往往意味着不抽奖，直接选“最可能”的那个。4 decoding（解码） 把模型输出的概率分布一步步变成最终文本的过程。 模型每一步给出“下一词的概率表”，解码策略决定你怎么从表里选一个词。4 greedy decoding（贪婪解码） 每一步都选择概率最大的 token（argmax）。 每次都选“最有把握的答案”。如果第一名和第二名非常接近，哪怕概率表有极小抖动，第一名也可能换人。4 sampling（采样） 按概率分布随机抽取 token。 即便第一名概率最高，也可能抽到第二名、第三名；这能带来多样性，但会降低可复现性。 do_sample（是否采样） Transformers 里控制“走采样还是走确定性选择”的开关。 do_sample=True 时就像“抽签选词”；do_sample=False 时更像“按最高分直接选”。当它是 False 时，temperature 往往就没意义了（因为都不抽签了）。45 num_beams（束宽） 束搜索（beam search）一次保留的候选序列数量。 num_beams=1 就是不做束搜索；num_beams=5 类似“同时保留 5 条可能的续写路线再比较”。束越宽通常越慢，也更可能改变输出风格。4 top-p / nucleus sampling（核采样） 只在“累计概率达到 p 的候选集合”内采样。 如果 p=0.9，就先挑出一组 token，让它们的概率加起来到 0.9，再在这组里抽；比“全分布采样”更稳，也更能避免离谱尾部。13 beam search（束搜索） 同时保留多个候选序列，搜索更高整体概率的序列。 像走迷宫时同时保留几条“看起来最优”的路继续探索；但在开放式文本生成中可能导致重复等退化现象。13 degeneration（文本退化） 生成文本出现重复、空洞、过度模板化等现象。 例如模型不停输出“当然当然当然……”。论文指出贪婪/束搜索更容易触发这种问题。13 logits（对数几率/未归一化分数） 模型在 softmax 之前给每个 token 的“分数”。 可以把 logits 当成“每个候选词的打分”。温度、softmax 等操作会把打分变成概率。 argmax（取最大值索引） 从一组数里选出最大值对应的索引。 从概率表里挑“最大概率的词”。若最大值与次大值非常接近，微小数值误差就可能改变结果。 reproducibility（可复现性） 同样输入在多次运行中得到同样输出的能力。 “我今天跑一次、明天跑一次，结果要一样”。但官方文档常提醒：跨版本/设备未必能做到 100%。6 deterministic algorithms（确定性算法） 强制使用不会引入非确定性的实现路径（或直接报错）。 PyTorch 提供 torch.use_deterministic_algorithms 这类开关：要么走确定性实现，要么宁愿失败也不悄悄给你不确定结果。7 atomic operations（原子操作） 多线程并发更新同一个值时的“不可分割更新”。 像多人同时往同一个存钱罐里塞硬币：原子操作保证“不会塞丢”，但塞的先后顺序可能不同；配合浮点舍入，最终小数点后可能略有差异。cuDNN 文档提示这会影响可复现。8 parallel reduction（并行规约） 把很多数求和/合并的并行算法。 1000 个数求和，GPU 会分组并行相加再合并；但浮点加法对顺序敏感，合并顺序不同会带来极小误差。8 system_fingerprint（系统指纹） 供应商返回的后端配置标识，用于判断“后端是否变了”。 如果你昨天和今天的 fingerprint 不同，即便你参数不变，也很可能因为后端升级导致输出/一致率变化。3 batch / batching（批处理） 把多个请求合并成一个大计算以提升吞吐。 像等电梯：把多个人一起送上去更省电。但你上电梯时遇到的人不同（批次不同），系统内部安排可能不同，从而影响输出一致性。vLLM 提到“批不变”就是在解决这个。10 batch invariance（批不变） 同一输入在不同 batch 位置时输出保持一致。 你和别人一起算/单独算，结果都一样。vLLM 把它作为重要特性来保证服务化一致性。10 scheduling（调度） 决定哪些请求先算、怎么拼 batch、怎么分配资源。 同一条任务在不同队列里先后顺序不同，内部拼 batch 的方式就可能不同，从而影响输出。1011 XLA（编译器） 把计算图编译成高性能内核的编译器/后端。 “为了跑得更快”，编译器会换算法/融合算子；但文档说某些算子在 GPU 上可能非确定。9)^
batch / batching（批处理） 把多个请求合并成一个大计算以提升吞吐。 像等电梯：把多个人一起送上去更省电。但你上电梯时遇到的人不同（批次不同），系统内部安排可能不同，从而影响输出一致性。vLLM 提到"批不变"就是在解决这个。^[10](#术语 简要解释 更好理解的说法/例子 temperature（温度） 控制采样随机性的参数；通常通过缩放 logits 来改变分布“尖锐程度”。 想象你在抽奖：温度高=更敢抽小概率奖品；温度低=更倾向最大概率的选择。温度为 0 往往意味着不抽奖，直接选“最可能”的那个。4 decoding（解码） 把模型输出的概率分布一步步变成最终文本的过程。 模型每一步给出“下一词的概率表”，解码策略决定你怎么从表里选一个词。4 greedy decoding（贪婪解码） 每一步都选择概率最大的 token（argmax）。 每次都选“最有把握的答案”。如果第一名和第二名非常接近，哪怕概率表有极小抖动，第一名也可能换人。4 sampling（采样） 按概率分布随机抽取 token。 即便第一名概率最高，也可能抽到第二名、第三名；这能带来多样性，但会降低可复现性。 do_sample（是否采样） Transformers 里控制“走采样还是走确定性选择”的开关。 do_sample=True 时就像“抽签选词”；do_sample=False 时更像“按最高分直接选”。当它是 False 时，temperature 往往就没意义了（因为都不抽签了）。45 num_beams（束宽） 束搜索（beam search）一次保留的候选序列数量。 num_beams=1 就是不做束搜索；num_beams=5 类似“同时保留 5 条可能的续写路线再比较”。束越宽通常越慢，也更可能改变输出风格。4 top-p / nucleus sampling（核采样） 只在“累计概率达到 p 的候选集合”内采样。 如果 p=0.9，就先挑出一组 token，让它们的概率加起来到 0.9，再在这组里抽；比“全分布采样”更稳，也更能避免离谱尾部。13 beam search（束搜索） 同时保留多个候选序列，搜索更高整体概率的序列。 像走迷宫时同时保留几条“看起来最优”的路继续探索；但在开放式文本生成中可能导致重复等退化现象。13 degeneration（文本退化） 生成文本出现重复、空洞、过度模板化等现象。 例如模型不停输出“当然当然当然……”。论文指出贪婪/束搜索更容易触发这种问题。13 logits（对数几率/未归一化分数） 模型在 softmax 之前给每个 token 的“分数”。 可以把 logits 当成“每个候选词的打分”。温度、softmax 等操作会把打分变成概率。 argmax（取最大值索引） 从一组数里选出最大值对应的索引。 从概率表里挑“最大概率的词”。若最大值与次大值非常接近，微小数值误差就可能改变结果。 reproducibility（可复现性） 同样输入在多次运行中得到同样输出的能力。 “我今天跑一次、明天跑一次，结果要一样”。但官方文档常提醒：跨版本/设备未必能做到 100%。6 deterministic algorithms（确定性算法） 强制使用不会引入非确定性的实现路径（或直接报错）。 PyTorch 提供 torch.use_deterministic_algorithms 这类开关：要么走确定性实现，要么宁愿失败也不悄悄给你不确定结果。7 atomic operations（原子操作） 多线程并发更新同一个值时的“不可分割更新”。 像多人同时往同一个存钱罐里塞硬币：原子操作保证“不会塞丢”，但塞的先后顺序可能不同；配合浮点舍入，最终小数点后可能略有差异。cuDNN 文档提示这会影响可复现。8 parallel reduction（并行规约） 把很多数求和/合并的并行算法。 1000 个数求和，GPU 会分组并行相加再合并；但浮点加法对顺序敏感，合并顺序不同会带来极小误差。8 system_fingerprint（系统指纹） 供应商返回的后端配置标识，用于判断“后端是否变了”。 如果你昨天和今天的 fingerprint 不同，即便你参数不变，也很可能因为后端升级导致输出/一致率变化。3 batch / batching（批处理） 把多个请求合并成一个大计算以提升吞吐。 像等电梯：把多个人一起送上去更省电。但你上电梯时遇到的人不同（批次不同），系统内部安排可能不同，从而影响输出一致性。vLLM 提到“批不变”就是在解决这个。10 batch invariance（批不变） 同一输入在不同 batch 位置时输出保持一致。 你和别人一起算/单独算，结果都一样。vLLM 把它作为重要特性来保证服务化一致性。10 scheduling（调度） 决定哪些请求先算、怎么拼 batch、怎么分配资源。 同一条任务在不同队列里先后顺序不同，内部拼 batch 的方式就可能不同，从而影响输出。1011 XLA（编译器） 把计算图编译成高性能内核的编译器/后端。 “为了跑得更快”，编译器会换算法/融合算子；但文档说某些算子在 GPU 上可能非确定。9)^
batch invariance（批不变） 同一输入在不同 batch 位置时输出保持一致。 你和别人一起算/单独算，结果都一样。vLLM 把它作为重要特性来保证服务化一致性。^[10](#术语 简要解释 更好理解的说法/例子 temperature（温度） 控制采样随机性的参数；通常通过缩放 logits 来改变分布“尖锐程度”。 想象你在抽奖：温度高=更敢抽小概率奖品；温度低=更倾向最大概率的选择。温度为 0 往往意味着不抽奖，直接选“最可能”的那个。4 decoding（解码） 把模型输出的概率分布一步步变成最终文本的过程。 模型每一步给出“下一词的概率表”，解码策略决定你怎么从表里选一个词。4 greedy decoding（贪婪解码） 每一步都选择概率最大的 token（argmax）。 每次都选“最有把握的答案”。如果第一名和第二名非常接近，哪怕概率表有极小抖动，第一名也可能换人。4 sampling（采样） 按概率分布随机抽取 token。 即便第一名概率最高，也可能抽到第二名、第三名；这能带来多样性，但会降低可复现性。 do_sample（是否采样） Transformers 里控制“走采样还是走确定性选择”的开关。 do_sample=True 时就像“抽签选词”；do_sample=False 时更像“按最高分直接选”。当它是 False 时，temperature 往往就没意义了（因为都不抽签了）。45 num_beams（束宽） 束搜索（beam search）一次保留的候选序列数量。 num_beams=1 就是不做束搜索；num_beams=5 类似“同时保留 5 条可能的续写路线再比较”。束越宽通常越慢，也更可能改变输出风格。4 top-p / nucleus sampling（核采样） 只在“累计概率达到 p 的候选集合”内采样。 如果 p=0.9，就先挑出一组 token，让它们的概率加起来到 0.9，再在这组里抽；比“全分布采样”更稳，也更能避免离谱尾部。13 beam search（束搜索） 同时保留多个候选序列，搜索更高整体概率的序列。 像走迷宫时同时保留几条“看起来最优”的路继续探索；但在开放式文本生成中可能导致重复等退化现象。13 degeneration（文本退化） 生成文本出现重复、空洞、过度模板化等现象。 例如模型不停输出“当然当然当然……”。论文指出贪婪/束搜索更容易触发这种问题。13 logits（对数几率/未归一化分数） 模型在 softmax 之前给每个 token 的“分数”。 可以把 logits 当成“每个候选词的打分”。温度、softmax 等操作会把打分变成概率。 argmax（取最大值索引） 从一组数里选出最大值对应的索引。 从概率表里挑“最大概率的词”。若最大值与次大值非常接近，微小数值误差就可能改变结果。 reproducibility（可复现性） 同样输入在多次运行中得到同样输出的能力。 “我今天跑一次、明天跑一次，结果要一样”。但官方文档常提醒：跨版本/设备未必能做到 100%。6 deterministic algorithms（确定性算法） 强制使用不会引入非确定性的实现路径（或直接报错）。 PyTorch 提供 torch.use_deterministic_algorithms 这类开关：要么走确定性实现，要么宁愿失败也不悄悄给你不确定结果。7 atomic operations（原子操作） 多线程并发更新同一个值时的“不可分割更新”。 像多人同时往同一个存钱罐里塞硬币：原子操作保证“不会塞丢”，但塞的先后顺序可能不同；配合浮点舍入，最终小数点后可能略有差异。cuDNN 文档提示这会影响可复现。8 parallel reduction（并行规约） 把很多数求和/合并的并行算法。 1000 个数求和，GPU 会分组并行相加再合并；但浮点加法对顺序敏感，合并顺序不同会带来极小误差。8 system_fingerprint（系统指纹） 供应商返回的后端配置标识，用于判断“后端是否变了”。 如果你昨天和今天的 fingerprint 不同，即便你参数不变，也很可能因为后端升级导致输出/一致率变化。3 batch / batching（批处理） 把多个请求合并成一个大计算以提升吞吐。 像等电梯：把多个人一起送上去更省电。但你上电梯时遇到的人不同（批次不同），系统内部安排可能不同，从而影响输出一致性。vLLM 提到“批不变”就是在解决这个。10 batch invariance（批不变） 同一输入在不同 batch 位置时输出保持一致。 你和别人一起算/单独算，结果都一样。vLLM 把它作为重要特性来保证服务化一致性。10 scheduling（调度） 决定哪些请求先算、怎么拼 batch、怎么分配资源。 同一条任务在不同队列里先后顺序不同，内部拼 batch 的方式就可能不同，从而影响输出。1011 XLA（编译器） 把计算图编译成高性能内核的编译器/后端。 “为了跑得更快”，编译器会换算法/融合算子；但文档说某些算子在 GPU 上可能非确定。9)^
scheduling（调度） 决定哪些请求先算、怎么拼 batch、怎么分配资源。 同一条任务在不同队列里先后顺序不同，内部拼 batch 的方式就可能不同，从而影响输出。^[10](#术语 简要解释 更好理解的说法/例子 temperature（温度） 控制采样随机性的参数；通常通过缩放 logits 来改变分布“尖锐程度”。 想象你在抽奖：温度高=更敢抽小概率奖品；温度低=更倾向最大概率的选择。温度为 0 往往意味着不抽奖，直接选“最可能”的那个。4 decoding（解码） 把模型输出的概率分布一步步变成最终文本的过程。 模型每一步给出“下一词的概率表”，解码策略决定你怎么从表里选一个词。4 greedy decoding（贪婪解码） 每一步都选择概率最大的 token（argmax）。 每次都选“最有把握的答案”。如果第一名和第二名非常接近，哪怕概率表有极小抖动，第一名也可能换人。4 sampling（采样） 按概率分布随机抽取 token。 即便第一名概率最高，也可能抽到第二名、第三名；这能带来多样性，但会降低可复现性。 do_sample（是否采样） Transformers 里控制“走采样还是走确定性选择”的开关。 do_sample=True 时就像“抽签选词”；do_sample=False 时更像“按最高分直接选”。当它是 False 时，temperature 往往就没意义了（因为都不抽签了）。45 num_beams（束宽） 束搜索（beam search）一次保留的候选序列数量。 num_beams=1 就是不做束搜索；num_beams=5 类似“同时保留 5 条可能的续写路线再比较”。束越宽通常越慢，也更可能改变输出风格。4 top-p / nucleus sampling（核采样） 只在“累计概率达到 p 的候选集合”内采样。 如果 p=0.9，就先挑出一组 token，让它们的概率加起来到 0.9，再在这组里抽；比“全分布采样”更稳，也更能避免离谱尾部。13 beam search（束搜索） 同时保留多个候选序列，搜索更高整体概率的序列。 像走迷宫时同时保留几条“看起来最优”的路继续探索；但在开放式文本生成中可能导致重复等退化现象。13 degeneration（文本退化） 生成文本出现重复、空洞、过度模板化等现象。 例如模型不停输出“当然当然当然……”。论文指出贪婪/束搜索更容易触发这种问题。13 logits（对数几率/未归一化分数） 模型在 softmax 之前给每个 token 的“分数”。 可以把 logits 当成“每个候选词的打分”。温度、softmax 等操作会把打分变成概率。 argmax（取最大值索引） 从一组数里选出最大值对应的索引。 从概率表里挑“最大概率的词”。若最大值与次大值非常接近，微小数值误差就可能改变结果。 reproducibility（可复现性） 同样输入在多次运行中得到同样输出的能力。 “我今天跑一次、明天跑一次，结果要一样”。但官方文档常提醒：跨版本/设备未必能做到 100%。6 deterministic algorithms（确定性算法） 强制使用不会引入非确定性的实现路径（或直接报错）。 PyTorch 提供 torch.use_deterministic_algorithms 这类开关：要么走确定性实现，要么宁愿失败也不悄悄给你不确定结果。7 atomic operations（原子操作） 多线程并发更新同一个值时的“不可分割更新”。 像多人同时往同一个存钱罐里塞硬币：原子操作保证“不会塞丢”，但塞的先后顺序可能不同；配合浮点舍入，最终小数点后可能略有差异。cuDNN 文档提示这会影响可复现。8 parallel reduction（并行规约） 把很多数求和/合并的并行算法。 1000 个数求和，GPU 会分组并行相加再合并；但浮点加法对顺序敏感，合并顺序不同会带来极小误差。8 system_fingerprint（系统指纹） 供应商返回的后端配置标识，用于判断“后端是否变了”。 如果你昨天和今天的 fingerprint 不同，即便你参数不变，也很可能因为后端升级导致输出/一致率变化。3 batch / batching（批处理） 把多个请求合并成一个大计算以提升吞吐。 像等电梯：把多个人一起送上去更省电。但你上电梯时遇到的人不同（批次不同），系统内部安排可能不同，从而影响输出一致性。vLLM 提到“批不变”就是在解决这个。10 batch invariance（批不变） 同一输入在不同 batch 位置时输出保持一致。 你和别人一起算/单独算，结果都一样。vLLM 把它作为重要特性来保证服务化一致性。10 scheduling（调度） 决定哪些请求先算、怎么拼 batch、怎么分配资源。 同一条任务在不同队列里先后顺序不同，内部拼 batch 的方式就可能不同，从而影响输出。1011 XLA（编译器） 把计算图编译成高性能内核的编译器/后端。 “为了跑得更快”，编译器会换算法/融合算子；但文档说某些算子在 GPU 上可能非确定。9)^^[11](#术语 简要解释 更好理解的说法/例子 temperature（温度） 控制采样随机性的参数；通常通过缩放 logits 来改变分布“尖锐程度”。 想象你在抽奖：温度高=更敢抽小概率奖品；温度低=更倾向最大概率的选择。温度为 0 往往意味着不抽奖，直接选“最可能”的那个。4 decoding（解码） 把模型输出的概率分布一步步变成最终文本的过程。 模型每一步给出“下一词的概率表”，解码策略决定你怎么从表里选一个词。4 greedy decoding（贪婪解码） 每一步都选择概率最大的 token（argmax）。 每次都选“最有把握的答案”。如果第一名和第二名非常接近，哪怕概率表有极小抖动，第一名也可能换人。4 sampling（采样） 按概率分布随机抽取 token。 即便第一名概率最高，也可能抽到第二名、第三名；这能带来多样性，但会降低可复现性。 do_sample（是否采样） Transformers 里控制“走采样还是走确定性选择”的开关。 do_sample=True 时就像“抽签选词”；do_sample=False 时更像“按最高分直接选”。当它是 False 时，temperature 往往就没意义了（因为都不抽签了）。45 num_beams（束宽） 束搜索（beam search）一次保留的候选序列数量。 num_beams=1 就是不做束搜索；num_beams=5 类似“同时保留 5 条可能的续写路线再比较”。束越宽通常越慢，也更可能改变输出风格。4 top-p / nucleus sampling（核采样） 只在“累计概率达到 p 的候选集合”内采样。 如果 p=0.9，就先挑出一组 token，让它们的概率加起来到 0.9，再在这组里抽；比“全分布采样”更稳，也更能避免离谱尾部。13 beam search（束搜索） 同时保留多个候选序列，搜索更高整体概率的序列。 像走迷宫时同时保留几条“看起来最优”的路继续探索；但在开放式文本生成中可能导致重复等退化现象。13 degeneration（文本退化） 生成文本出现重复、空洞、过度模板化等现象。 例如模型不停输出“当然当然当然……”。论文指出贪婪/束搜索更容易触发这种问题。13 logits（对数几率/未归一化分数） 模型在 softmax 之前给每个 token 的“分数”。 可以把 logits 当成“每个候选词的打分”。温度、softmax 等操作会把打分变成概率。 argmax（取最大值索引） 从一组数里选出最大值对应的索引。 从概率表里挑“最大概率的词”。若最大值与次大值非常接近，微小数值误差就可能改变结果。 reproducibility（可复现性） 同样输入在多次运行中得到同样输出的能力。 “我今天跑一次、明天跑一次，结果要一样”。但官方文档常提醒：跨版本/设备未必能做到 100%。6 deterministic algorithms（确定性算法） 强制使用不会引入非确定性的实现路径（或直接报错）。 PyTorch 提供 torch.use_deterministic_algorithms 这类开关：要么走确定性实现，要么宁愿失败也不悄悄给你不确定结果。7 atomic operations（原子操作） 多线程并发更新同一个值时的“不可分割更新”。 像多人同时往同一个存钱罐里塞硬币：原子操作保证“不会塞丢”，但塞的先后顺序可能不同；配合浮点舍入，最终小数点后可能略有差异。cuDNN 文档提示这会影响可复现。8 parallel reduction（并行规约） 把很多数求和/合并的并行算法。 1000 个数求和，GPU 会分组并行相加再合并；但浮点加法对顺序敏感，合并顺序不同会带来极小误差。8 system_fingerprint（系统指纹） 供应商返回的后端配置标识，用于判断“后端是否变了”。 如果你昨天和今天的 fingerprint 不同，即便你参数不变，也很可能因为后端升级导致输出/一致率变化。3 batch / batching（批处理） 把多个请求合并成一个大计算以提升吞吐。 像等电梯：把多个人一起送上去更省电。但你上电梯时遇到的人不同（批次不同），系统内部安排可能不同，从而影响输出一致性。vLLM 提到“批不变”就是在解决这个。10 batch invariance（批不变） 同一输入在不同 batch 位置时输出保持一致。 你和别人一起算/单独算，结果都一样。vLLM 把它作为重要特性来保证服务化一致性。10 scheduling（调度） 决定哪些请求先算、怎么拼 batch、怎么分配资源。 同一条任务在不同队列里先后顺序不同，内部拼 batch 的方式就可能不同，从而影响输出。1011 XLA（编译器） 把计算图编译成高性能内核的编译器/后端。 “为了跑得更快”，编译器会换算法/融合算子；但文档说某些算子在 GPU 上可能非确定。9)^
XLA（编译器） 把计算图编译成高性能内核的编译器/后端。 "为了跑得更快"，编译器会换算法/融合算子；但文档说某些算子在 GPU 上可能非确定。^[9](#术语 简要解释 更好理解的说法/例子 temperature（温度） 控制采样随机性的参数；通常通过缩放 logits 来改变分布“尖锐程度”。 想象你在抽奖：温度高=更敢抽小概率奖品；温度低=更倾向最大概率的选择。温度为 0 往往意味着不抽奖，直接选“最可能”的那个。4 decoding（解码） 把模型输出的概率分布一步步变成最终文本的过程。 模型每一步给出“下一词的概率表”，解码策略决定你怎么从表里选一个词。4 greedy decoding（贪婪解码） 每一步都选择概率最大的 token（argmax）。 每次都选“最有把握的答案”。如果第一名和第二名非常接近，哪怕概率表有极小抖动，第一名也可能换人。4 sampling（采样） 按概率分布随机抽取 token。 即便第一名概率最高，也可能抽到第二名、第三名；这能带来多样性，但会降低可复现性。 do_sample（是否采样） Transformers 里控制“走采样还是走确定性选择”的开关。 do_sample=True 时就像“抽签选词”；do_sample=False 时更像“按最高分直接选”。当它是 False 时，temperature 往往就没意义了（因为都不抽签了）。45 num_beams（束宽） 束搜索（beam search）一次保留的候选序列数量。 num_beams=1 就是不做束搜索；num_beams=5 类似“同时保留 5 条可能的续写路线再比较”。束越宽通常越慢，也更可能改变输出风格。4 top-p / nucleus sampling（核采样） 只在“累计概率达到 p 的候选集合”内采样。 如果 p=0.9，就先挑出一组 token，让它们的概率加起来到 0.9，再在这组里抽；比“全分布采样”更稳，也更能避免离谱尾部。13 beam search（束搜索） 同时保留多个候选序列，搜索更高整体概率的序列。 像走迷宫时同时保留几条“看起来最优”的路继续探索；但在开放式文本生成中可能导致重复等退化现象。13 degeneration（文本退化） 生成文本出现重复、空洞、过度模板化等现象。 例如模型不停输出“当然当然当然……”。论文指出贪婪/束搜索更容易触发这种问题。13 logits（对数几率/未归一化分数） 模型在 softmax 之前给每个 token 的“分数”。 可以把 logits 当成“每个候选词的打分”。温度、softmax 等操作会把打分变成概率。 argmax（取最大值索引） 从一组数里选出最大值对应的索引。 从概率表里挑“最大概率的词”。若最大值与次大值非常接近，微小数值误差就可能改变结果。 reproducibility（可复现性） 同样输入在多次运行中得到同样输出的能力。 “我今天跑一次、明天跑一次，结果要一样”。但官方文档常提醒：跨版本/设备未必能做到 100%。6 deterministic algorithms（确定性算法） 强制使用不会引入非确定性的实现路径（或直接报错）。 PyTorch 提供 torch.use_deterministic_algorithms 这类开关：要么走确定性实现，要么宁愿失败也不悄悄给你不确定结果。7 atomic operations（原子操作） 多线程并发更新同一个值时的“不可分割更新”。 像多人同时往同一个存钱罐里塞硬币：原子操作保证“不会塞丢”，但塞的先后顺序可能不同；配合浮点舍入，最终小数点后可能略有差异。cuDNN 文档提示这会影响可复现。8 parallel reduction（并行规约） 把很多数求和/合并的并行算法。 1000 个数求和，GPU 会分组并行相加再合并；但浮点加法对顺序敏感，合并顺序不同会带来极小误差。8 system_fingerprint（系统指纹） 供应商返回的后端配置标识，用于判断“后端是否变了”。 如果你昨天和今天的 fingerprint 不同，即便你参数不变，也很可能因为后端升级导致输出/一致率变化。3 batch / batching（批处理） 把多个请求合并成一个大计算以提升吞吐。 像等电梯：把多个人一起送上去更省电。但你上电梯时遇到的人不同（批次不同），系统内部安排可能不同，从而影响输出一致性。vLLM 提到“批不变”就是在解决这个。10 batch invariance（批不变） 同一输入在不同 batch 位置时输出保持一致。 你和别人一起算/单独算，结果都一样。vLLM 把它作为重要特性来保证服务化一致性。10 scheduling（调度） 决定哪些请求先算、怎么拼 batch、怎么分配资源。 同一条任务在不同队列里先后顺序不同，内部拼 batch 的方式就可能不同，从而影响输出。1011 XLA（编译器） 把计算图编译成高性能内核的编译器/后端。 “为了跑得更快”，编译器会换算法/融合算子；但文档说某些算子在 GPU 上可能非确定。9)^

参考文献

  1. Create a Text Completion - Claude API Reference, Anthropic, https://docs.anthropic.com/claude/reference/complete_post ↩︎ ↩︎ ↩︎ ↩︎

  2. Create a Message Batch - Claude API Reference, Anthropic, https://docs.anthropic.com/en/api/creating-message-batches ↩︎ ↩︎ ↩︎ ↩︎

  3. Reproducible outputs with the seed parameter, OpenAI Cookbook, https://cookbook.openai.com/examples/reproducible_outputs_with_the_seed_parameter ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  4. Generation - Hugging Face Transformers (Text generation main classes), Hugging Face, https://huggingface.co/docs/transformers/en/main_classes/text_generation ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  5. Forced to hit UserWarning when generating with temperature=0 (issue #36896), HuggingFace Transformers GitHub, 2025-03-21, https://github.com/huggingface/transformers/issues/36896 ↩︎ ↩︎ ↩︎

  6. Reproducibility --- PyTorch 2.9 documentation, PyTorch, https://docs.pytorch.org/docs/stable/notes/randomness.html ↩︎ ↩︎ ↩︎ ↩︎

  7. torch.use_deterministic_algorithms --- PyTorch 2.9 documentation, PyTorch, https://docs.pytorch.org/docs/stable/generated/torch.use_deterministic_algorithms.html ↩︎ ↩︎ ↩︎ ↩︎

  8. Odds and Ends --- NVIDIA cuDNN Backend: Reproducibility (Determinism), NVIDIA, https://docs.nvidia.com/deeplearning/cudnn/backend/latest/developer/misc.html#reproducibility-determinism ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  9. Determinism (GPU), OpenXLA, https://openxla.org/xla/determinism ↩︎ ↩︎ ↩︎ ↩︎

  10. Reproducibility - vLLM, vLLM Documentation, https://docs.vllm.ai/en/latest/usage/reproducibility/ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  11. Reproducibility (Offline Inference) - vLLM v0.10.2, vLLM Documentation, https://docs.vllm.ai/en/v0.10.2/examples/offline_inference/reproducibility.html ↩︎ ↩︎ ↩︎ ↩︎

  12. Defeating Nondeterminism in LLM Inference, Thinking Machines Lab, 2025, https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/ ↩︎ ↩︎

  13. The Curious Case of Neural Text Degeneration, Ari Holtzman, Jan Buys, Li Du, Maxwell Forbes, Yejin Choi, 2019, arXiv, https://arxiv.org/abs/1904.09751 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

相关推荐
一招定胜负3 小时前
计算机视觉入门：opencv基本操作
人工智能·opencv·计算机视觉
wenzhangli73 小时前
深度解析Ooder架构：A2UI时代全栈设计的四大核心思考
大数据·人工智能
m0_462605223 小时前
第N11周：seq2seq翻译实战-Pytorch复现
人工智能·pytorch·python
LiFileHub3 小时前
ISO/IEC TR 29119-11:2020中文版
人工智能
光影34153 小时前
调用阿里的通义千问3-VL-Flash 系统提示词和用户提示词使用的token量比较
人工智能
啊阿狸不会拉杆3 小时前
《数字图像处理》实验3-频率域处理方法
图像处理·人工智能·算法·计算机视觉·数字图像处理
哥本哈士奇3 小时前
使用Gradio构建AI前端 - RAG召回测试
前端·人工智能
赋创小助手3 小时前
超微SYS-821GE-TNHR深度测评:8卡 NVIDIA H200 风冷 AI 服务器
运维·服务器·人工智能·深度学习·计算机视觉·语言模型·自然语言处理
xwz小王子3 小时前
Mini3DV 2025 | 观点总结：具身智能前沿与展望
人工智能·3d
热门推荐
01从快手“12·22”直播攻击事件看：一次教科书式的业务层饱和攻击02GitHub 镜像站点033D 圣诞树网页代码04Linux下V2Ray安装配置指南05UV安装并设置国内源06电脑检测软件—图吧工具箱07在VSCode配置Java开发环境的保姆级教程（适配各类AI编程IDE）08Gemini3 生成的基于手势控制3D粒子圣诞树09jdk21下载、安装（Windows、Linux、macOS）10Claude Code Skills 实用使用手册