第4章：大模型基础（LLM Fundamentals）
这一章讲 Agent 背后的引擎——大语言模型。你不需要从零训练一个 LLM 才能做 Agent 开发，但你需要理解它的核心机制、能力边界和关键参数，才能做出正确的工程决策。
为什么 Agent 开发者需要懂这些？因为当你的 Agent 在第 8 步突然开始胡说八道时，你需要知道这可能是上下文窗口溢出导致的注意力退化；当你的 Agent 调用工具的参数总是出错时，你需要知道降低 Temperature 可能就能解决；当你在成本和质量之间权衡时，你需要理解 KV Cache、模型路由和推理模型的 token 经济学。
4.1 Transformer 架构核心
核心直觉
Transformer 的核心思想是：让文本中的每个词都能"看到"所有其他词，然后根据相关性决定该关注谁。这个"看到并关注"的机制就是 Self-Attention。
Self-Attention 机制
给定一个输入序列（比如一个句子的 token 嵌入矩阵 X），Self-Attention 通过三个可学习的矩阵把输入投影成三组向量：
- Query（Q）= X · W_Q — "我在找什么"
- Key（K）= X · W_K — "我能提供什么"
- Value（V）= X · W_V — "我实际包含的信息"
然后用这个公式计算注意力：
Attention(Q, K, V) = softmax(QK^T / √d_k) · V拆开看：
QK^T：计算每对 token 之间的"相关性分数"。Q 有 n 行（n 个 token），K^T 有 n 列，结果是一个 n×n 的矩阵——每个 token 对其他每个 token 都有一个分数。
除以 √d_k：缩放因子。d_k 是 Key 向量的维度。如果不做缩放，当维度较高时点积值会变得很大，softmax 会被推到梯度接近于零的区域，训练就不动了。这个看似不起眼的 √d_k 是 Transformer 能稳定训练的关键细节之一 [1]。
softmax：把每一行归一化成概率分布。现在每个 token 对其他 token 的"注意力"加起来等于 1。
乘以 V：用注意力权重对 Value 做加权求和。每个 token 的输出是所有其他 token 的信息按注意力权重混合的结果。
O(n²) 复杂度：为什么这是 Agent 开发的核心约束
QK^T 这一步产生了一个 n×n 的矩阵，n 是序列长度。计算量和内存占用都是 O(n²)。
这意味着：
- 序列长度翻倍，计算量翻四倍
- 一个 4K token 的序列需要 1600 万个注意力分数；128K token 需要 160 亿个
对 Agent 开发的直接影响：Agent 的对话历史、工具调用记录、推理链都是 token。随着任务进行，上下文不断增长，注意力计算的成本呈二次方增长。这就是为什么上下文管理（Context Engineering，第 6 章）是 Agent 工程的核心问题。
Multi-Head Attention：为什么需要多头
与其用一个大的注意力函数，不如把 Q、K、V 分别投影到 h 个不同的低维子空间，各自计算注意力，最后拼接：
head_i = Attention(Q·W_Q_i, K·W_K_i, V·W_V_i)
MultiHead = Concat(head_1, ..., head_h) · W_O为什么这么做？因为不同的"关注模式"需要不同的参数空间。一个头可能学会关注语法依赖（主语和动词的距离关系），另一个头关注语义共指（代词指向谁），第三个头关注位置邻近性。多头让模型同时捕捉多种关系，比单个大注意力更有效 [1]。
KV Cache：自回归推理的关键优化
生成文本时，模型一次只产生一个 token。天真的实现中，生成第 t 个 token 需要对前面所有 t-1 个 token 重新计算注意力——每生成一个新 token 就重复所有之前的计算。
KV Cache 的优化很直接：之前 token 的 K 和 V 不会变（因为因果掩码保证了过去 token 只能看到更早的 token），所以缓存起来不重算。每生成一个新 token，只需要计算它自己的 Q、K、V，把新的 K、V 追加到缓存里，然后用新 Q 对整个缓存做注意力计算。
这把每一步的复杂度从 O(n²) 降到了 O(n)——生成速度有质的提升。
但 KV Cache 占内存。一个 70B 参数的模型，100 万 token 的 KV Cache 大约需要 320 GB 显存 [2]。这是长上下文推理的主要瓶颈——不是算不了，是存不下。
对 Agent 的影响：Agent 系统经常涉及长对话、多轮工具调用、大量中间推理。KV Cache 的大小直接决定了一个 GPU 能同时服务多少个 Agent 会话、上下文能增长到多长。
高效注意力变体
为了缓解 O(n²) 和 KV Cache 的内存压力，业界发展了几种关键优化：
Flash Attention [3]：不改变注意力的数学计算（结果完全一样），而是优化了 GPU 内存访问模式。通过分块计算（tiling），让注意力在 GPU 的高速 SRAM 中完成，避免把完整的 n×n 矩阵写入慢速的 HBM 显存。FlashAttention-3 在 H100 上达到 75-85% 的模型 FLOPs 利用率，比 FlashAttention-2 快 1.5-2 倍。
Grouped-Query Attention（GQA） [4]：标准 Multi-Head Attention 中，每个 Query 头有自己的 K 和 V 头。GQA 让多个 Query 头共享同一组 K/V 头，大幅减少 KV Cache 的大小。它已经成为很多现代 Decoder-only 模型提升长上下文推理效率的常见做法。
| 变体 | 机制 | KV Cache 缩减 | 质量影响 |
|---|---|---|---|
| MHA（标准） | 每个 Q 头有自己的 K/V | 无（基线） | 基线 |
| MQA | 所有 Q 头共享一组 K/V | h 倍（h 为头数） | 可能显著下降 |
| GQA | Q 头分 G 组，每组共享一组 K/V | h/G 倍 | 接近 MHA |
位置编码
Self-Attention 本身是"位置无关"的——它只看 token 之间的内容相关性，不知道谁在前谁在后。但语言显然有顺序，所以需要额外注入位置信息。
RoPE（Rotary Position Embedding） [5]：目前最主流的方案。核心思想是对 Q 和 K 向量施加位置相关的旋转——位置 m 的 token 旋转角度为 m·θ。巧妙之处在于：两个旋转后向量的点积只取决于它们的相对位置差 (m-n)，自然编码了相对位置关系。不需要可学习参数，理论上可以外推到任意长度（实践中需要频率缩放技术来支持超长上下文）。
ALiBi（Attention with Linear Biases） [6]：更简单——不改 token 嵌入，直接在注意力分数上加一个线性偏置：距离越远的 token 对，扣分越多。每个头有不同的衰减斜率。实现简单，在训练长度外的外推表现不错。但在最新一代前沿模型中，RoPE 家族已成为主流，ALiBi 主要在 BLOOM、MPT、Falcon 等稍早期的模型中使用。
为什么 Decoder-only 架构成为主流
最初的 Transformer 是 Encoder-Decoder 架构（用于翻译）。但从 GPT 系列开始，Decoder-only 架构逐步成为通用大语言模型的主流选择 [7]。
原因有几个：
- 训练效率：Decoder-only 的每个 token 都参与损失计算。Encoder-Decoder 的 BERT 式预训练只有 15% 的 token（被 mask 的那些）贡献损失，85% 的计算"白做了"。
- 扩展简单：一个统一的层堆叠，并行化和硬件利用更直接。没有 Encoder-Decoder 之间的信息瓶颈。
- 不需要配对数据：直接在原始文本上训练，可用数据量大了几个数量级。
- 涌现能力：In-context Learning、Chain-of-Thought、指令跟随——这些能力在大规模 Decoder-only 模型中涌现。
有研究重新审视了 Encoder-Decoder [8]，发现经过指令微调后，Encoder-Decoder 在长输入短输出的任务（翻译、摘要）上推理效率更高。但这没有改变前沿模型的选择——在通用能力和规模扩展上，Decoder-only 的优势目前是压倒性的。
4.2 预训练与规模定律（Scaling Laws）
核心直觉
模型越大、数据越多、算力越大，效果就越好——而且这个关系出奇地可预测。
Kaplan 定律（2020）
OpenAI 的 Kaplan 等人在 2020 年发现 [9]，模型的损失值和三个变量之间存在幂律关系：
- 参数量 N：L(N) ~ N^(-0.076)
- 数据量 D：L(D) ~ D^(-0.095)
- 计算量 C：L(C) ~ C^(-0.050)
这些关系跨越了 7 个数量级都成立。更重要的结论是：架构细节（宽度、深度的比例）在很大范围内影响不大。这意味着你可以在小规模实验中预测大模型的表现，极大降低了研发风险。
Chinchilla 定律（2022）：数据量被严重低估了
DeepMind 的 Hoffmann 等人在 2022 年纠正了一个重要偏差 [10]：Kaplan 定律暗示应该优先加大模型，少量数据就够了。但 Chinchilla 定律表明，参数和数据应该同比例扩展——大约每个参数对应 20 个训练 token。
这意味着之前的大模型严重"欠训练"了。GPT-3（1750 亿参数）只用了 3000 亿 token 训练，ratio 约为 1.7:1。Chinchilla（700 亿参数）用了 1.4 万亿 token 训练，ratio 为 20:1，结果全面超越了大它 4 倍的 Gopher——用同样的计算预算。
实践中的"违背"：推理成本重于训练成本
Chinchilla 定律说的是训练时的计算最优。但在生产环境中，你还要考虑推理成本——模型训完了要用很多很多次。
这导致了一个反直觉的趋势 [11]：故意"过度训练"小模型。Llama 3 的 8B 模型用了 15 万亿 token 训练——每参数 1,875 个 token，是 Chinchilla 最优比的 94 倍。为什么？因为更小的模型每次推理更便宜。多花训练算力、换来更便宜的推理，当你考虑模型整个生命周期的总成本时，这其实是最优的。
另一个新趋势是推理时计算扩展（Inference-time Compute Scaling）。ICLR 2025 的一篇论文表明 [12]，通过在推理时增加计算（重复采样、搜索、Chain-of-Thought），小模型在某些任务上可以逼近甚至超过更大的模型。这对 Agent 架构的影响很直接：推理模型（Reasoning Models）本质上就是把更多计算投入到推理阶段。
4.3 Tokenization：你以为的一个词不是模型看到的一个词
核心直觉
模型不直接处理文字，它处理的是 token——一种把文本切成小块的方式。理解 tokenization 对 Agent 开发的成本估算、上下文管理和多语言支持都很关键。
BPE 算法
几乎所有主流 LLM 都使用 BPE（Byte Pair Encoding）或其变体做 tokenization。算法步骤 [13]：
- 初始化：词表从所有单字节（256 个 token）开始
- 统计：数整个语料库中每对相邻 token 的出现频率
- 合并：把最高频的一对合并成一个新 token，加入词表
- 重复：回到第 2 步，直到词表达到目标大小（比如 10 万）
举个例子：如果语料里 "th" 出现频率最高，就合并成一个 token；然后如果 "the" 最高频，再合并。最终常见词变成一个 token，罕见词被拆成多个子 token。
对 Agent 开发的影响
成本估算：API 按 token 计费。如果你不了解 tokenization，就无法准确预估每次调用的成本。不同的 tokenizer 对同样的文本会产生不同数量的 token——换模型意味着重新算。
上下文管理：Agent 需要在上下文窗口内管理对话历史、工具调用记录和推理链。Token 数（而非字符数）才是真正的约束。
多语言问题：不同语言的 token 效率差异很大。中日韩等非拉丁文字在很多 tokenizer 下往往会比英文消耗更多 token。这意味着对于多语言 Agent，有效上下文长度可能更短，成本也更高。
工具调用格式：JSON 结构的工具调用定义和函数签名都消耗 token。理解 tokenization 有助于优化工具描述，减少开销。
4.4 推理参数：Temperature、Top-p、Top-k
核心直觉
这些参数控制模型输出的"随机性"。Agent 做工具调用时要尽量确定，做创意生成时可以随机一点。
Temperature
在 softmax 之前对 logits 做缩放：p_i = exp(z_i / T) / Σ exp(z_j / T)
- T = 0（或接近 0）：几乎确定性输出，总是选概率最高的 token
- T < 1：分布更尖锐，输出更集中、更可预测
- T > 1：分布更平坦，输出更随机、更多样
Top-p（核采样）
按概率从高到低排列 token，累加到总概率刚好超过 p 为止，只从这个子集中采样。和 Top-k 不同，Top-p 的候选数量是动态的——高置信度时候选少，低置信度时候选多。
Top-k
只保留概率最高的 k 个 token，重新分配概率，从中采样。固定的候选数量，不管分布形状如何。OpenAI 和 Anthropic 的 API 默认不暴露 Top-k 参数。
Agent 任务的参数建议
| 任务类型 | Temperature | Top-p | 理由 |
|---|---|---|---|
| 工具调用 / Function Calling | 0.0–0.1 | 1.0 | 需要确定性的有效 JSON |
| 分类 / 信息提取 | 0.0–0.2 | 1.0 | 一致性优先 |
| 代码生成 | 0.2–0.4 | 0.9–0.95 | 正确性和多样性平衡 |
| 一般对话 / 问答 | 0.5–0.7 | 0.9–0.95 | 自然变化 |
| 创意写作 / 头脑风暴 | 0.8–1.0 | 0.95–1.0 | 鼓励多样性 |
官方指导：
- OpenAI 的 API 文档建议一次只调一个采样参数（
temperature或top_p，不要同时调）。部分最新的 reasoning 模型不支持开发者直接设置这些参数，或者只暴露有限控制项 [14]。 - Anthropic 的 API release notes 也明确提到，开启 extended thinking 后，
top_p的可调范围会受到限制 [15]。
常见误区
误区："Temperature 调到 0 就完全确定了。" 在工程上它通常会显著提高稳定性，但不等于严格数学意义上的完全确定。底层数值实现、并行计算和服务侧优化都可能带来极小的不确定性。如果你的系统依赖可复现输出（比如做回归测试），还需要额外的缓存、固定流程和结果校验。
4.5 大模型的能力边界
核心直觉
LLM 很强，但它有几个硬伤。知道这些边界，才能设计出不依赖模型"无所不能"的 Agent 系统。
幻觉（Hallucination）
最新的研究越来越倾向于把幻觉理解成一个系统性激励问题 [16]：下一个 token 预测的训练目标，更擅长产出"看起来合理的延续"，并不天然擅长表达"我不确定"。
这件事在工程上最重要的结论不是某个具体百分比，而是两个更稳定的规律：
- 任务越开放、越依赖外部最新事实、越缺少可验证反馈，幻觉风险越高。
- 只要系统允许模型在没有证据的情况下直接下结论，幻觉就不会真正消失。
对 Agent 开发的含义：永远不要把 LLM 的输出当作事实本身。更稳的做法是：
- 用 RAG 或搜索工具提供外部知识
- 用代码工具验证计算和格式
- 用结构化约束减少自由发挥空间
- 在高风险输出前加人工审查或程序化校验
Agent 系统的可靠性，不能建立在"模型不会犯错"这个假设上。
上下文窗口
模型厂商通常会给出一个标称上下文窗口，但你在工程上真正关心的是有效上下文窗口。这两者不是一回事。
为什么？因为上下文越长，注意力越分散，检索早期信息的难度越高；而且很多任务并不是"能放进去就等于能用好"。你把大量历史对话、工具调用记录、中间思考和长文档一起塞进去，模型未必会把真正关键的那几段信息放在正确位置上。
对 Agent 的直接含义是：
- 不要把标称窗口当成可放心塞满的容量
- 为关键信息留出充足的注意力预算
- 把不重要的中间结果及时清理或压缩
- 长任务优先用检索、笔记和状态外置，而不是单纯堆上下文
第 6 章（Context Engineering）会专门讨论怎么管理这件事。
推理天花板
LLM 在以下方面仍然不可靠 [17]：
- 多步逻辑推理：错误在每一步累积。5-6 个变量的逻辑谜题仍然不稳定。
- 新颖数学推理：能解训练中见过的题型，但换个不常见的数字或结构就可能出错。
- Prompt 鲁棒性：微小的措辞变化可能导致准确率下降最多 54%——模型严重过拟合于表面形式。
- 自我校准：模型无法可靠地判断自己是否知道答案。自信程度和正确性之间的相关性并不强。
- 计数、空间推理、规划：没有工具辅助时仍然薄弱。
这些限制的工程含义：不要让 Agent 独自承担它做不好的事。计算用代码工具、事实查询用搜索工具、关键决策加人工检查。Agent 的价值不在于模型无所不能，而在于把模型擅长的（语言理解、推理框架、工具编排）和确定性工具擅长的（精确计算、数据查询、格式验证）组合起来。
4.6 模型选择策略：模型路由
核心直觉
不是所有任务都需要最贵的模型。用一个路由器把简单任务发给便宜快速的小模型，只把真正难的任务发给前沿大模型——这能在几乎不损失质量的前提下大幅降低成本。
为什么需要模型路由
前沿模型很强，但通常也更贵、更慢。如果你的 Agent 大部分操作其实只是分类、信息提取、轻量路由或参数整理，那把所有请求都扔给最强模型，通常是在浪费预算。
四层模型策略
| 层级 | 适合的任务 | 典型能力 | 特点 |
|---|---|---|---|
| 前沿推理模型 | 复杂规划、多步推理、困难代码 | 长链条推理、审查、纠错 | 最强但最贵最慢 |
| 中型通用模型 | 日常工具调用、对话、轻量规划 | 稳定执行、基础推理 | 性价比平衡 |
| 小模型 | 意图分类、参数提取、简单问答 | 高吞吐、低延迟 | 快且便宜 |
| 特化模型 | 嵌入、重排序、分类 | 单一任务优化 | 单一功能最优 |
Router 怎么实现？ 最简单的方案是基于规则——根据输入长度、任务类型、关键词路由。更复杂的方案是用一个小型分类模型做路由决策。OpenAI 和 Anthropic 的指南都建议 [14] [15]：简单任务路由到小模型，只把高复杂度任务分配给前沿模型。
工程权衡
模型路由增加了系统复杂度——你需要维护多个模型的 API 调用、处理不同模型的能力差异和输出格式差异。如果你的 Agent 任务比较单一（比如全是代码生成），用单一模型反而更简单可靠。路由在任务类型多样化时才有价值。
4.7 推理模型（Reasoning Models）对 Agent 架构的影响
核心直觉
推理模型在回答前会先"想一会儿"——消耗额外的 token 做内部推理。想得越久越准，但也越贵越慢。对 Agent 来说，这改变了"什么时候该让模型多想，什么时候该让它快答"的权衡。
什么是推理模型
推理模型（Reasoning Models）在生成最终回答之前，会投入额外的推理计算预算。不同厂商的产品形态不一样：有的把它暴露成 reasoning effort，有的叫 extended thinking，有的允许你设置 thinking budget；但底层想解决的是同一件事：让模型在难题上多想一会儿，再给答案 [18]。
推理 token 的工程陷阱
推理模型最容易被忽视的一点，不是"贵"，而是预算结构变复杂了。
在一些 API 设计里，推理过程会体现在 reasoning_tokens、reasoning effort 或 thinking budget 这类字段上 [18]。对工程师来说，真正要注意的是：
- 你为模型留了多少预算给"思考"
- 这些预算会不会挤占最终可见输出
- 一次多想带来的首次正确率提升，能不能抵消后续重试成本
所以推理模型不是简单的"更强模型"，而是把更多计算前移到单次调用里。
对 Agent 架构的影响
推理模型改变了 Agent 的成本结构。传统上，Agent 通过多轮重试来提高成功率——失败了就再来一次。推理模型提供了另一条路：一次花更多钱让模型想清楚，减少重试次数。
什么时候用推理模型：
- 复杂规划任务：Agent 需要生成多步执行计划，首次准确率很重要（重新规划代价大）
- 代码生成和调试：高难度编程任务，推理模型的首次通过率显著更高
- 审查和纠错：Agent 系统中的 Evaluator 角色——审查其他 Agent 的输出
什么时候不用推理模型：
- 高吞吐低复杂度任务：分类、意图识别、参数提取——小模型就够了，推理模型的延迟和成本不值
- 延迟敏感场景：思考过程会增加数秒延迟
- 成本敏感流水线：如果简单模型已经能达到足够的准确率，推理模型的额外成本没有 ROI
更稳的实践策略：构建路由架构——简单任务发给小模型，中等任务发给中型模型，只有最高复杂度的任务（规划、审查、困难代码）才发给推理模型。
推理 token vs 传统 CoT：本质区别
表面上，推理模型的"内部思考"和传统的 Chain-of-Thought prompting 看起来很像——都是让模型逐步推理。但有几个本质区别：
- 训练方式不同：推理模型经过专门训练来支持更长链条的内部推理；传统 CoT 主要是通过 prompt 引导普通模型"一步步想"。
- 计算预算不同：推理模型通常允许你显式或隐式地给更多推理预算；传统 CoT 的推理深度更多取决于 prompt 和模型的自发倾向。
- 工程使用方式不同：推理模型改变的是单次调用的成本结构；传统 CoT 更像是在原有模型上加一种提示技巧。
- 显式 CoT 提示的必要性下降：在推理模型上，你不需要再写"Let's think step by step"——模型本身就会。但任务分解、检查点和外部验证仍然必要——模型想得再好，也需要从环境中获取真实反馈。
面试高频题
题目一：Attention 的时间复杂度是什么？如何优化？KV Cache 的原理？
好的回答思路：
Self-Attention 的核心计算是 QK^T，产生一个 n×n 的矩阵，所以时间和空间复杂度都是 O(n²)，n 是序列长度。
优化主要在两个维度：
计算效率：Flash Attention 通过分块计算（tiling）优化 GPU 内存访问模式，避免在 HBM 中存储完整的 n×n 矩阵。它不改变计算结果，只改变计算方式，实现了 1.5-2 倍加速。
KV Cache 压缩：自回归生成时，之前 token 的 K/V 不会变，缓存起来避免重复计算。这把每步生成从 O(n²) 降到 O(n)。但 KV Cache 本身很占显存。GQA 让多个 Query 头共享 K/V 头，减少缓存大小；MQA 更激进，所有头共享一组 K/V，但可能影响质量。
加分点：
- 提到 70B 模型 100 万 token 的 KV Cache 约需 320GB 显存
- 解释为什么这对 Agent 特别重要——长对话和工具调用链会持续增长上下文
- 提到 Flash Attention 不减少 O(n²) 的复杂度本身，只是优化了 IO
题目二：推理模型的"推理 token"和传统 CoT 有什么本质区别？
好的回答思路：
传统 CoT 是通过 prompt 引导普通模型输出推理步骤——比如加上"Let's think step by step"。模型并没有经过专门训练来做长链条推理，它只是被 prompt "引导"了输出格式。
推理模型的 thinking tokens 是经过专门训练（通常结合强化学习）的内部推理过程。模型在输出答案前先进行一段扩展的链式思考，这些思考 token 计费但通常不对用户可见。
关键区别有三个：一、推理模型的推理链经过训练优化，通常更连贯和准确；二、计算预算可调——有些模型支持设置 thinking budget，让你控制模型"想多久"；三、推理 token 改变了 Agent 的成本结构——花更多钱在单次推理上，可能减少整体重试次数，总成本反而更低。
加分点：
- 提到计费陷阱：思考 token 占用 max_tokens 预算，可能导致实际输出被截断
- 给出 Agent 架构中的实际应用：推理模型做 Planner 和 Evaluator，普通模型做 Executor
- 提到 OpenAI 推理模型固定 Temperature=1.0 的原因——内部多路径评估需要随机性
参考资料
[1] Ashish Vaswani et al. Attention Is All You Need. NeurIPS 2017. arXiv:1706.03762
[2] Hugging Face. KV Caching Explained. https://huggingface.co/blog/not-lain/kv-caching ; KV Cache Optimization Strategies survey, arXiv:2603.20397
[3] Tri Dao et al. FlashAttention-3: Fast and Accurate Attention with Asynchrony and Low-precision. arXiv:2407.08608
[4] Joshua Ainslie et al. GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints. arXiv:2305.13245
[5] Jianlin Su et al. RoFormer: Enhanced Transformer with Rotary Position Embedding. 2021. arXiv:2104.09864
[6] Ofir Press et al. Train Short, Test Long: Attention with Linear Biases Enables Input Length Extrapolation. ICLR 2022. arXiv:2108.12409
[7] Sebastian Raschka. The Big LLM Architecture Comparison. https://magazine.sebastianraschka.com/p/the-big-llm-architecture-comparison
[8] arXiv:2510.26622. Revisiting Encoder-Decoder Language Models.
[9] Jared Kaplan et al. Scaling Laws for Neural Language Models. 2020. arXiv:2001.08361
[10] Jordan Hoffmann et al. Training Compute-Optimal Large Language Models. 2022. arXiv:2203.15556
[11] Meta. Introducing Meta Llama 3: The most capable openly available LLM to date. https://ai.meta.com/blog/meta-llama-3/
[12] Charlie Snell et al. Scaling LLM Test-Time Compute Optimally. ICLR 2025. arXiv:2408.00724
[13] Andrej Karpathy. minbpe. https://github.com/karpathy/minbpe ; Sebastian Raschka. BPE from Scratch. https://sebastianraschka.com/blog/2025/bpe-from-scratch.html
[14] OpenAI. API Reference: Temperature and sampling. https://platform.openai.com/docs/api-reference
[15] Anthropic. API Reference: Messages. https://docs.anthropic.com/en/api/messages
[16] Comprehensive Survey of Hallucinations in Large Language Models. arXiv:2510.06265
[17] LLM Reasoning Failures survey. arXiv:2602.06176
[18] OpenAI API reference: Responses / reasoning fields. https://platform.openai.com/docs/api-reference/responses/create ; Anthropic API release notes. https://docs.anthropic.com/en/release-notes/api