← 返回书架人工智能 · 交互式 Wiki

生成与检索服务进阶计算演示

EXACT MECHANICS / DECODING

解码算法：从 logits 到一个输出 token

模型给出分数，解码器按温度、候选筛选、约束和采样规则选择输出。固定一组 logits，逐项检查候选如何被保留、重新归一化和采样。

01 / DISTRIBUTION

先声明顺序，再计算概率

\begin{aligned}p_i&=\frac{\exp((z_i+m_i)/T)}{\sum_j\exp((z_j+m_j)/T)},\\m_i&\in\{0,-\infty\}.\end{aligned}

操作	明确规则	需要声明
Greedy	选择当前合法候选中分数最高者。	并列规则、停止 token、约束与处理顺序。
Top-k	只保留概率最高的 k 个候选，再归一化。	候选少于 k 时保留全部；并列如何处理。
Top-p / nucleus	按概率降序，保留累计概率首次达到阈值的最小前缀。	阈值、排序、边界候选保留规则和前面的过滤。
随机采样	按最终分布抽取一个候选。	随机种子、采样器与其状态；同 seed 跨实现未必逐位一致。

固定词表的解码账本

有限教学词表 · mask → 温度 → Top-k → Top-p

温度 Top-kTop-p 启用有限语言约束已有前缀采样位置 u

Greedy 候选

按 u 采样的候选

Token	Logit	语法允许	初始概率	筛选保留	最终概率

u∈[0,1) 是固定的逆 CDF 采样位置，按展示词表顺序累计最终概率。滑块替代随机数生成，不代表重复请求始终使用同一随机位置。

02 / CONSTRAINTS

合法 token 取决于已有前缀与语法状态

本例的合法完整文本只有 {"ok":true} 和 {"ok":false}。候选 token 接到当前前缀后，必须仍是某个合法文本的前缀；只有完整对象后才允许 EOS。这是有限语言的显式前缀检查，不是通用 JSON grammar 引擎。

真实 tokenizer 的一个 token 可能包含多个字符、部分字符串或多个语法片段。约束引擎需要结合词表与语法状态生成 token mask；只按单字符判断容易漏掉跨字符和转义情况。XGrammar 等系统专门处理这类计算。

语法保证有适用范围

约束可以要求合法 JSON 或指定字段类型。事实正确性、外部状态和业务规则还需要独立验证；超时或长度截断可能留下未完成的前缀。

处理顺序会影响候选

先 Top-k 再做语法 mask，可能删掉所有合法候选。本例先约束再筛选；真实引擎的处理链和空候选错误处理应明确记录。

停止条件属于协议

EOS、停止字符串、最大长度与工具调用边界分别处理。停止字符串可能跨 token，终止时应明确是否保留匹配内容。

缓存跟随实际接受前缀

确定输出后才将其作为下一轮输入。修改或拒绝一段候选时，KV 状态需要与保留前缀一致。

03 / SEARCH

当前最高概率，未必通向最高概率完整序列

两步概率树

等长完整路径，无 EOS 和长度惩罚

Beam width

第一步 A:0.6、B:0.4；A 后 x:0.51/y:0.49，B 后 x:0.99/y:0.01。

保留的最好完整序列：

深度	路径	联合概率	是否保留

\log p(y_{1:T})=\sum_{t=1}^T\log p(y_t\mid y_{<t})

序列概率衡量模型赋予文本的概率，不直接等于任务正确性。这里宽度 2 能找到小树的最好路径，不能推广为任意规模下的全局最优保证。随机采样、greedy 和搜索有不同目标，评估时应固定预算与任务指标。

Prefill、decode 与 KV 投机采样的验收条件概率、正确性与校准

04 / RANDOM STREAMS

同一个 seed，为什么请求换个批次就不一样？

分布、取数位置与请求身份都需要对齐。先隔离随机数分配，再判断 logits 或数值计算是否发生变化。

seed 指向生成器初态，已经消费的随机状态还要另外保存。这里用可手算的 u 清单和游标展示分配过程：三个请求的分布始终固定，按 x、y、z 的顺序做上面的逆 CDF 采样；不计算模型 logits。

请求	p(x), p(y), p(z)	绑定该请求的三次 u
A	0.20, 0.30, 0.50	0.12, 0.66, 0.23
B	0.50, 0.25, 0.25	0.87, 0.49, 0.72
C	0.10, 0.20, 0.70	0.34, 0.91, 0.05

全局 u 清单为 0.12, 0.87, 0.34, 0.66, 0.49, 0.91, 0.23, 0.72, 0.05，特意与 ABC 顺序下的三条请求清单逐轮对齐。按槽位分配时，槽位 0/1/2 分别使用 A/B/C 这一列清单；请求结束后活动批次会紧凑排列。所有清单都为说明机制而指定，不是某个框架 seed 的实际输出，也不用于检验随机性或独立性。

展开随机流分配与恢复账本 · 固定分布计算演示

先保留全局流并更换请求顺序，再切换到“按请求 ID”。也可以让 B 提前结束，观察槽位压缩；最后比较恢复游标和重置游标。

每轮请求顺序随机流归属 B 的输出预算何时暂停恢复随机状态

启用 JavaScript 可切换调度并查看逐项账本；上面的概率和 u 清单也可直接手算。

先声明要复现的层次

全局流按不同顺序分配，产生不同样本路径并不直接说明算法错误。若要求同一请求在批次重排后保持相同输出，应同时对齐分布、采样规则、请求到随机流的映射和当前状态。真实浮点计算仍可能受批次形状影响。

接续运行要保存进度和状态

重置游标类比从相同 seed 的初态重建生成器；恢复游标类比接续保存的随机状态。本例还保留当前事件位置与已输出前缀。真实引擎需要一起恢复采样器、已接受前缀和对应 KV，且同一请求的流不能被并发消费。

PyTorch 的 Generator 文档说明了随机状态的保存与恢复。此处的游标只是固定清单的状态表示；它不替代框架生成器状态，也不保证不同平台或采样器逐值一致。

先核对填充与缓存 logits 按首次差异定位复现问题恢复状态的职责

适用范围与一手资料

固定六 token 解码词表与两步 Beam 小树；语法仅接受两条 JSON 文本的前缀。随机流账本用三个请求、固定概率和指定 u 清单隔离分配与恢复，不是模型实测，不声明随机性质量或跨框架逐值一致。

公式与机制的原始依据 · 5 项

Transformers · Generation strategiesGreedy、采样和 Beam search；实际顺序与参数依版本
XGrammar: Flexible and Efficient Structured Generation Engine for Large Language Models (2024)语法约束、词表与 token mask 的结构化生成系统
Fast Inference from Transformers via Speculative Decoding (2022)接受概率、残差采样与目标分布保持的条件
PyTorch 2.9 · Reproducibility2026-10-28 核对固定版本正文：控制随机源与确定性算法有适用环境，seed 不保证跨版本或平台逐值一致
PyTorch 2.9 · Generator2026-10-29 核对生成器管理随机算法状态及 get_state/set_state；本站随机流账本采用人为指定的 u 清单，不模拟某个框架 seed 的输出