原文地址 第3章 Gemma 3

3. Gemma 3

谷歌推出的 Gemma 系列模型一直表现优异，在我看来，和 Llama 系列等热门模型相比，它的市场热度始终被有所低估。

Gemma 的一大鲜明特征是词表规模较大，以此更好地支持多语言；同时产品线更侧重 270 亿参数规格，而非 80 亿或 700 亿档位。不过需要说明的是，Gemma 2 也提供更小的参数版本：10 亿、40 亿和 120 亿。

270 亿这个规格刚好卡在非常理想的平衡点：能力远强于 80 亿参数模型，资源消耗又远低于 700 亿参数模型，在我的 Mac Mini 上就能顺畅本地运行。

那么 Gemma 3 还有哪些值得关注的设计？如前文所述，DeepSeek V3/R1 等模型采用混合专家（MoE）架构，在模型总规模固定的前提下降低推理时的内存占用 —— 后文要介绍的多款模型也都沿用了 MoE 方案。
而 Gemma 3 选择了另一种技术路径来压缩计算成本：滑动窗口注意力。

3.1 滑动窗口注意力

滑动窗口注意力最早于 2020 年在《LongFormer》论文中提出，Gemma 2 也已采用该技术。借助滑动窗口注意力，Gemma 3 团队大幅降低了 KV 缓存的内存占用，如下图所示。

图 11：摘自 Gemma 3 论文（https://arxiv.org/abs/2503.19786）的标注图，展示滑动窗口注意力带来的 KV 缓存内存节省效果

Continue reading 【转载】大语言模型架构全面对比03：Gemma 3→

原文地址 第2章 OLMo 2

2. OLMo 2

非营利机构艾伦人工智能研究所（Allen Institute for AI）推出的 OLMo 系列模型，因其训练数据与代码的高度透明，以及相对详尽的技术报告而备受关注。

尽管 OLMo 系列模型或许不会登顶各类基准测试排行榜，但它们的实现规范干净；更重要的是，得益于极高的透明度，它们是大语言模型研发的绝佳参考范本。

OLMo 系列的知名度虽主要来自透明度，但性能表现也并不逊色。实际上，在今年 1 月发布时（早于 Llama 4、Gemma 3 与 Qwen 3），OLMo 2 系列模型就处于算力 – 性能的帕累托最优前沿，如下图 7 所示。

图 7：不同大语言模型的建模基准性能（数值越高越好）与预训练算力成本（FLOPs，数值越低越好）对比。本图标注版摘自 OLMo 2 论文：https://arxiv.org/abs/2501.00656

Continue reading 【转载】大语言模型架构全面对比02：OLMo 2→

原文地址 第1章 DeepSeek V3/R1

1. DeepSeek V3/R1

想必大家已经多次听闻，DeepSeek R1 在 2025 年 1 月发布时引发了巨大反响。DeepSeek R1 是基于 DeepSeek V3 架构打造的推理模型，而 DeepSeek V3 架构 于 2024 年 12 月首次推出。

尽管本文的核心关注点是 2025 年发布的架构，但将 DeepSeek V3 纳入讨论是合理的 —— 它是在 2025 年 DeepSeek R1 推出后，才真正获得广泛关注与应用。

Continue reading 【转载】大语言模型架构全面对比01：DeepSeek V3/R1→

原文地址：The Big LLM Architecture Comparison，by Sebastian Raschka, on 2025-07-19， updated on 2026-04-02

最近在读Sebastian Raschka博士的文章，内容十分的详实，收获很多。

国内很多朋友没有读过，网络也有些受限，于是准备用LLM翻译成中文，自己读的时候，也方便一下其他有需要的伙伴。

本文只翻译了文章的引言部分，后续将把相同模型的内容，放到一起翻译，顺序和原文地址不太一样，主要是读起来更方便一些。如果你等不及，可以直接看英文原文（如果语言不是障碍，强烈推荐读原文）：

原文地址

Continue reading 【转载】大语言模型架构全面对比00：引言→

原文地址：LLM Research Papers: The 2025 List (January to June)，by Sebastian Raschka, on 2025-07-01

大语言模型研究论文：2025年上半年精选（1-6月）

按主题分类的 200 余篇 2025 年大语言模型研究论文合集

熟悉我的读者可能知道，我一直有整理待读、待参考研究论文清单的习惯。

大约半年前，我分享了 2024 年的论文清单，很多读者都觉得很实用。因此我打算继续更新这个系列，并且采纳了大家反复提到的建议：「能不能按主题而非日期来整理论文？」

我划分的分类如下：

• 推理模型

  • 1a. 推理模型训练

  • 1b. 推理阶段推理策略

  • 1c. 大语言模型评估与推理解析

• 大语言模型的其他强化学习方法

• 其他推理阶段扩展方法

• 高效训练与模型架构

• 基于扩散的语言模型

• 多模态与视觉 – 语言模型

• 数据与预训练数据集

同时，大语言模型领域的研究更新速度极快，因此我决定将清单更新频率调整为半年一次。这样既能保证内容的时效性，也更易于阅读，希望能为大家的暑期研读提供一份扎实的参考资料。

请注意，目前这份内容仅为精选清单。在后续的文章中，我会针对其中更具价值、更有影响力的论文，按主题撰写更深入的解读与讨论，敬请期待。

Continue reading 【转载】大语言模型研究论文：2025年上半年精选（1-6月）→

原文地址：Understanding and Coding the KV Cache in LLMs from Scratch，by Sebastian Raschka, on 2025-07-17

从零开始理解并实现大语言模型中的KV缓存

KV缓存是生产环境中大语言模型实现高效推理的核心技术之一，也是提升大语言模型推理计算效率的重要组件。本文将从概念原理和代码实现两个层面，通过一套从零编写、可读性强的实现方案，讲解KV缓存的工作机制。

距离我上次分享讲解大语言模型基础概念的技术教程已经有一段时间了。目前我正处于伤病恢复期，同时在撰写一篇更重磅的大语言模型研究主题文章，因此打算分享一篇读者多次询问的主题教程（这个主题并未收录在我的《从零构建大语言模型》一书中）。
祝阅读愉快！

概述

简而言之，KV缓存会存储推理阶段（训练结束后）中间的键（K）和值（V）计算结果以供复用，从而大幅提升文本生成的速度。KV缓存的缺点在于会增加代码复杂度、提升内存需求（这也是我最初没有把它写入书中的主要原因），并且无法在训练过程中使用。但在生产环境部署大语言模型时，推理速度的提升通常足以覆盖代码复杂度和内存开销上的代价。

什么是KV缓存？

想象一下大语言模型正在生成文本的场景。具体来说，假设给模型输入的提示词是：“Time”。你可能已经知道，大语言模型每次生成一个单词（或词元），后续的两步文本生成过程可以用下图说明：

该图展示了大语言模型如何逐词元生成文本。从提示词“Time”开始，模型生成下一个词元“flies.”；下一步，再基于完整序列“Time flies”继续生成词元“fast”。

值得注意的是，大语言模型的文本生成过程存在大量重复计算，正如下图所突出显示的：

这张图标出了每一步生成时都需要重复处理的上下文（“Time flies”）。由于大语言模型没有缓存中间的键/值状态，每生成一个新词元（比如“fast”），它都要对完整序列重新编码一次。

我们实现大语言模型文本生成函数时，通常只会用到每一步生成的最后一个词元。但上图从概念层面揭示了其中最主要的低效问题之一。如果我们把视角聚焦到注意力机制本身，这种低效（或者说冗余）会更加清晰。（如果你对注意力机制感兴趣，可以阅读我的书https://amzn.to/4fqvn0D第3章，或者我发布的文章https://magazine.sebastianraschka.com/p/understanding-and-coding-self-attention了解更多内容。）

下图是大语言模型核心的注意力机制计算片段。图中输入词元（“Time”和“flies”）被编码为三维向量（实际应用中这些向量的维度要大得多，只是为了适配图片尺寸做了简化）。矩阵W是注意力机制的权重矩阵，负责将输入转换为键向量、值向量和查询向量。

下图展示了注意力分数计算的底层片段，其中高亮标出了键向量和值向量：

该图说明了大语言模型在注意力计算过程中，如何从词元嵌入中得到键（k）向量和值（v）向量。每个输入词元（比如“Time”和“flies”）都会通过训练得到的矩阵$W_k$和$W_v$进行投影，得到对应的键向量和值向量。

如前所述，大语言模型每次生成一个单词（或词元）。假设模型生成了单词“fast”，那么下一轮的提示词就变成了“Time flies fast”，如下图所示：

这张图展示了在每一步生成过程中，大语言模型如何对已经见过的词元（“Time”和“flies”）重复计算键向量和值向量。生成第三个词元（“fast”）时，模型会重新计算一遍完全相同的k(1)/v(1)和k(2)/v(2)向量，而不是直接复用它们。这种重复计算凸显了自回归解码过程中不使用KV缓存的低效性。

通过对比前两张图可以发现，前两个词元的键向量和值向量是完全相同的，如果每生成一个新词元都重新计算一遍，会造成大量的计算浪费。

而KV缓存的核心思路，就是实现一套缓存机制，存储之前生成的键向量和值向量以供复用，从而避免这些不必要的重复计算。

大语言模型生成文本的过程：无缓存 vs 有KV缓存

上一节我们讲完了基础概念，在看具体的代码实现之前，我们再进一步细化讲解。如果用不带KV缓存的方式生成“Time flies fast”这段文本，过程大致如下：

注意其中的冗余：词元“Time”和“flies”在每一步生成时都要被重新计算。KV缓存通过存储并复用之前计算好的键向量和值向量，解决了这种低效问题：

1. 初始阶段，模型计算输入词元的键向量和值向量，并缓存起来。
2. 每生成一个新词元时，模型只计算该词元对应的键向量和值向量。
3. 之前计算好的向量直接从缓存中读取，避免重复计算。

下表总结了计算和缓存的步骤与状态：

这样做的好处是，“Time”只计算1次、复用2次，“flies”只计算1次、复用1次。（这里为了简化用了短文本举例，不难理解：文本越长，已计算的键和值能被复用的次数就越多，生成速度的提升也就越明显。）

下图并排对比了第3步生成时，使用和不使用KV缓存的差异。

文本生成有无KV缓存的对比。上图（无缓存）中，每一步词元生成都要重新计算所有键向量和值向量，造成了冗余运算。下图（有缓存）中，之前计算好的键和值直接从KV缓存中读取，避免了重复计算，提升了生成速度。

所以，如果要在代码中实现KV缓存，我们只需要像往常一样计算键和值，然后把它们存储起来，供下一轮调用即可。下一节我们将通过具体的代码示例进行说明。

从零实现KV缓存

KV缓存的实现方式有很多，核心思想都是每一步生成时，只计算新生成词元对应的键张量和值张量。
我选择了一种偏重代码可读性的简单实现方案。我认为直接浏览代码改动，是最容易理解实现方式的途径。

我在GitHub上分享了两个文件，都是独立的Python脚本，分别从零实现了带KV缓存和不带KV缓存的大语言模型：

• https://github.com/rasbt/LLMs-from-scratch/blob/main/ch04/03_kv-cache/gpt_ch04.py ：摘自我的《从零构建大语言模型》一书第3、4章的完整代码，实现了大语言模型和基础的文本生成功能
• https://github.com/rasbt/LLMs-from-scratch/blob/main/ch04/03_kv-cache/gpt_with_kv_cache.py ：在上述代码基础上，加入了实现KV缓存所需的改动。

要查看KV缓存相关的代码修改，你可以选择以下任意一种方式：

a. 打开gpt_with_kv_cache.py文件，查找标注了# NEW的部分，这些就是新增的改动：

b. 用你习惯的文件对比工具，对比两个代码文件的差异：

此外，为了总结实现细节，下面的小节会做简要的步骤讲解。

1. 注册缓存缓冲区

在MultiHeadAttention（多头注意力）的构造函数中，我们添加两个缓冲区cache_k和cache_v，用于存储多步累积拼接起来的键和值：

self.register_buffer("cache_k", None)
self.register_buffer("cache_v", None)

（如果你想了解更多关于缓冲区的知识，我制作过一期YouTube视频：https://youtu.be/PetlIokI9Ao ）

2. 带use_cache标志的前向传播

接下来，我们扩展MultiHeadAttention类的forward方法，增加一个use_cache参数：

def forward(self, x, use_cache=False):
    b, num_tokens, d_in = x.shape
    keys_new = self.W_key(x)  # Shape: (b, num_tokens, d_out)
    values_new = self.W_value(x)
    queries = self.W_query(x)
    #...
    if use_cache:
        if self.cache_k is None:
            self.cache_k, self.cache_v = keys_new, values_new
        else:
            self.cache_k = torch.cat([self.cache_k, keys_new], dim=1)
            self.cache_v = torch.cat([self.cache_v, values_new], dim=1)
        keys, values = self.cache_k, self.cache_v
    else:
        keys, values = keys_new, values_new

这里对键和值的存储与读取，实现了KV缓存的核心思想。

存储
具体来说，通过if self.cache_k is None: ...完成缓存初始化后，我们分别通过self.cache_k = torch.cat(...)和self.cache_v = torch.cat(...)，将新生成的键和值追加到缓存中。

读取
之后，通过keys, values = self.cache_k, self.cache_v从缓存中取出存储的键和值。

本质上就是这些：KV缓存的核心就是存储与读取机制。后面的第3、4节只是处理一些实现上的细节问题。

3. 清空缓存

生成文本时，我们必须记得在两次独立的文本生成调用之间重置键缓冲区和值缓冲区。否则，新提示词的查询会注意力到上一条序列遗留下来的旧键值，导致模型依赖无关上下文、输出内容混乱。为了避免这种情况，我们给MultiHeadAttention类添加一个reset_cache方法，方便后续在两次文本生成调用之间调用：

def reset_cache(self):
    self.cache_k, self.cache_v = None, None

4. 在完整模型中传递use_cache参数

完成MultiHeadAttention类的修改后，我们现在来修改GPTModel类。首先，我们在构造函数中添加一个词元索引的位置追踪器：

self.current_pos = 0

这是一个简单的计数器，用于记录在增量生成过程中，模型已经缓存了多少个词元。

然后，我们把单行的块调用替换为显式循环，将use_cache参数传递给每个Transformer块：

def forward(self, in_idx, use_cache=False):
    # ...
    if use_cache:
        pos_ids = torch.arange(
            self.current_pos, self.current_pos + seq_len,
            device=in_idx.device, dtype=torch.long
        )
        self.current_pos += seq_len
    else:
        pos_ids = torch.arange(
            0, seq_len, device=in_idx.device, dtype=torch.long
        )
    pos_embeds = self.pos_emb(pos_ids).unsqueeze(0)
    x = tok_embeds + pos_embeds
    # ...
    for blk in self.trf_blocks:
        x = blk(x, use_cache=use_cache)

当设置use_cache=True时，上面的代码会从self.current_pos位置开始，计数seq_len个步长，然后累加计数器，这样下一次解码调用就会接着上次的位置继续。

之所以要追踪self.current_pos，是因为新的查询必须紧跟在已经存储的键和值之后。如果不用计数器，每一步都从位置0开始，模型就会认为新词元和之前的词元是重叠的。（另一种实现方式是通过offset = block.att.cache_k.shape[1]来追踪位置。）

上述改动还需要对TransformerBlock类做小幅修改，使其接收use_cache参数：

def forward(self, x, use_cache=False):
    # ...
    self.att(x, use_cache=use_cache)

最后，我们给GPTModel添加一个模型级别的重置方法，方便一次性清空所有块的缓存：

def reset_kv_cache(self):
    for blk in self.trf_blocks:
        blk.att.reset_cache()
    self.current_pos = 0

5. 在生成过程中使用缓存

完成GPTModel、TransformerBlock和MultiHeadAttention的修改后，最终我们可以这样在简单的文本生成函数中使用KV缓存：

def generate_text_simple_cached(
        model, idx, max_new_tokens, use_cache=True
):
    model.eval()
    ctx_len = model.pos_emb.num_embeddings  # max sup. len., e.g. 1024
    if use_cache:
        # Init cache with full prompt
        model.reset_kv_cache()
        with torch.no_grad():
            logits = model(idx[:, -ctx_len:], use_cache=True)
        for _ in range(max_new_tokens):
            # a) pick the token with the highest log-probability
            next_idx = logits[:, -1].argmax(dim=-1, keepdim=True)
            # b) append it to the running sequence
            idx = torch.cat([idx, next_idx], dim=1)
            # c) feed model only the new token
            with torch.no_grad():
                logits = model(next_idx, use_cache=True)
    else:
        for _ in range(max_new_tokens):
            with torch.no_grad():
                logits = model(idx[:, -ctx_len:], use_cache=False)
            next_idx = logits[:, -1].argmax(dim=-1, keepdim=True)
            idx = torch.cat([idx, next_idx], dim=1)
    return idx

注意，在步骤c中，我们只把新词元输入模型：logits = model(next_idx, use_cache=True)。而在无缓存的情况下，我们需要把完整的输入都传给模型：logits = model(idx[:, -ctx_len:], use_cache=False)，因为没有存储好的键和值可以复用。

简单的性能对比

从概念层面讲完KV缓存后，更重要的问题是：在实际的小例子中，它的性能到底怎么样？我们可以把上面提到的两个代码文件作为Python脚本运行，用一个1.24亿参数的小型大语言模型，基于4个词元的提示词“Hello, I am”生成200个新词元，来测试效果：

pip install -r https://raw.githubusercontent.com/rasbt/LLMs-from-scratch/refs/heads/main/requirements.txt
python gpt_ch04.py
python gpt_with_kv_cache.py

在搭载M4芯片的Mac Mini（CPU运行）上，结果如下：

可以看到，即使是1.24亿参数的小模型、仅生成200个词元的短序列，也已经获得了约5倍的速度提升。（注意：本实现的优化目标是代码可读性，而非CUDA或MPS的运行速度；如果要优化硬件运行速度，需要预分配张量，而不是反复重建和拼接张量。）

注意：两种情况下模型生成的都是“乱码”，也就是类似这样的文本：

输出文本：Hello, I am Featureiman Byeswickattribute argue logger Normandy Compton analogous bore ITVEGIN ministriesysics Kle functional recountrictionchangingVirgin embarrassedgl …

这是因为我们还没有训练模型。下一章会训练模型，之后你就可以在训练好的模型上用KV缓存（注意：KV缓存仅用于推理阶段）生成通顺的文本。这里用未训练的模型只是为了简化代码演示。

但更重要的是，gpt_ch04.py和gpt_with_kv_cache.py两种实现生成的文本完全一致。这说明KV缓存的实现是正确的——索引问题很容易出错，一旦出错就会导致输出结果不一致。

感谢阅读《Ahead of AI》！免费订阅即可接收新文章，支持我的创作。

KV缓存的优缺点

随着序列长度增加，KV缓存的优势和劣势都会更加凸显，具体表现为：

• 【优点】计算效率提升：没有缓存时，第t步的注意力必须将新查询与前t个键做对比，累计计算量呈平方级增长，复杂度为$O(n^2)$。使用缓存后，每个键和值只计算一次、后续复用，每一步的总复杂度降为线性的$(O(n))$。
• 【缺点】内存占用线性增长：每个新词元都会追加到KV缓存中。对于长序列和更大的大语言模型，累计的KV缓存会变得非常大，可能会占用大量（GPU）内存，甚至高到无法承受。作为折中方案，我们可以对KV缓存做截断，但这会进一步增加复杂度（不过在部署大语言模型时，这些代价通常是值得的）。

优化KV缓存的实现

上面这套KV缓存的概念实现侧重清晰易懂，主要服务于代码可读性和教学目的。如果要在实际场景中部署（尤其是更大的模型、更长的序列长度），还需要更细致的优化。

缓存扩展时的常见问题

• 内存碎片与重复分配：如前文所示，通过torch.cat不断拼接张量，会导致频繁的内存分配与重分配，形成性能瓶颈。
• 内存占用线性增长：如果处理不当，序列非常长时，KV缓存的体积会大到无法使用。

技巧1：预分配内存

与其反复拼接张量，我们可以根据预期的最大序列长度，预分配一个足够大的张量。这样能保证内存使用稳定，减少开销。伪代码大致如下：

# Example pre-allocation for keys and values
max_seq_len = 1024  # maximum expected sequence length
cache_k = torch.zeros(
    (batch_size, num_heads, max_seq_len, head_dim), device=device
)
cache_v = torch.zeros(
    (batch_size, num_heads, max_seq_len, head_dim), device=device
)

推理时，我们只需要往这些预分配张量的对应切片里写入数据即可。

技巧2：通过滑动窗口截断缓存

为了避免GPU内存爆炸，我们可以实现带动态截断的滑动窗口方案。通过滑动窗口，缓存中只保留最近的window_size个词元：

# Sliding window cache implementation
window_size = 512
cache_k = cache_k[:, :, -window_size:, :]
cache_v = cache_v[:, :, -window_size:, :]

实际应用中的优化

你可以在这个文件中找到这些优化实现：
https://github.com/rasbt/LLMs-from-scratch/blob/main/ch04/03_kv-cache/gpt_with_kv_cache_optimized.py

在搭载M4芯片的Mac Mini（CPU运行）上，生成200个词元、且窗口大小等于大语言模型的上下文长度（以保证结果一致，实现公平对比）时，代码的运行时间对比如下：

遗憾的是，在CUDA设备上，这种小模型的速度优势会消失。因为模型太小，设备间的数据传输和通信开销超过了KV缓存带来的收益。

结论

虽然缓存会带来额外的复杂度和内存开销，但效率上的显著提升通常足以覆盖这些代价，在生产环境中尤其如此。

请记住，本文的实现优先考虑代码的清晰性和可读性，而非运行效率；但核心结论是：工程落地的实现往往需要经过深思熟虑的优化，比如预分配内存、或者使用滑动窗口缓存来有效管理内存增长。从这个角度来说，希望这篇文章能对你有所帮助。

欢迎大家动手尝试这些技术，编码愉快！

---

补充：Qwen3和Llama 3中的KV缓存

在我从零实现的Qwen3（6亿参数）和Llama 3（10亿参数）中加入KV缓存后，我又做了额外的实验，对比了使用和不使用KV缓存时的模型运行时间。注意：我采用的是上文提到的torch.cat拼接方案，而不是“优化KV缓存实现”一节中说的预分配KV缓存张量。因为Llama 3和Qwen3支持的上下文长度非常大（分别为13.1万和4.1万个词元），预分配张量会额外消耗约8GB内存，开销很高。

此外，由于我使用更省内存的torch.cat方式动态生成张量，我把KV缓存移到了模型外部，这样就可以用torch.compile编译模型，进一步提升计算效率。

代码可以在这里查看：

• qwen3.py | README
• llama3.py | README

性能表现如下所示。

可以看到，在CPU上，KV缓存带来的速度提升最为显著，编译优化还能进一步提速。但在GPU上，常规的编译后模型就能达到最佳性能——这很可能是因为我们没有在GPU上预分配张量，而且模型本身规模也比较小。

---

这本杂志是我的个人热爱项目。如果你想支持我这位独立研究者，可以考虑购买我的书（https://amzn.to/4fqvn0D），或者订阅我的杂志（https://magazine.sebastianraschka.com/subscribe）。

《从零构建大语言模型》购买链接：https://amzn.to/4fqvn0D

如果你已经读过这本书，并且能抽出几分钟时间，我非常希望你能留下评价：https://www.amazon.com/Build-Large-Language-Model-Scratch/dp/1633437167 。这对我们作者帮助很大！
非常感谢你的支持！

原文地址：Coding LLMs from the Ground Up: A Complete Course，by Sebastian Raschka, on 2025-05-10

从零编写大语言模型：完整课程

近几个月我写了很多关于推理模型的内容（一连更了 4 篇）。除了 “智能体” 相关方向之外，推理能力是 2025 年大语言模型领域最核心的议题之一。

但这个月，我想分享一些更底层、更 “基础” 的内容 —— 如何从零编写大语言模型。这是理解 LLM 工作原理的最佳方式之一。

为什么要做这套内容？因为去年我分享的精简版 LLM 实战 workshop 反响非常好，很多人都从中受益：

《从零构建大语言模型：3 小时编码实战课》

所以我想，这套时长约为原版 5 倍、内容更详尽的课程（总时长约 15 小时），实用价值会更高。

另外很遗憾的是，我最近颈部受了重伤，过去三周基本没法对着电脑工作。目前我先尝试保守治疗，再考虑医生建议的手术方案。这个时机实在糟糕 —— 我刚找回工作节奏，生活就又抛来一记曲线球。

所以在康复期间，我把前几个月录好的这些视频整理出来，作为过渡内容分享给大家。

希望这份内容对你有帮助，也感谢大家的支持！

附：这些视频原本是我《从零构建大语言模型》一书的配套补充内容，但实际体验下来，它们作为独立课程也完全成立。

Continue reading 【转载】从零编写大语言模型：完整课程→

原文地址：The State of Reinforcement Learning for LLM Reasoning，by Sebastian Raschka, on 2025-04-19

大语言模型推理的强化学习现状

解读GRPO与推理模型论文的新洞见

这个月发生了不少大事，尤其是GPT-4.5和Llama 4等新一代旗舰模型相继发布。但你可能已经注意到，市场对这些发布的反响相对平淡。为什么？原因之一或许是GPT-4.5和Llama 4仍属于传统模型，也就是说它们的训练过程没有针对推理能力引入专门的强化学习。

与此同时，xAI和Anthropic等竞争对手已经在自家模型中加入了更多推理能力与功能。例如，xAI的Grok和Anthropic的Claude界面现在都为特定模型配备了“思考”（或“深度思考”）按钮，可以显式开启推理能力。

无论如何，市场对GPT-4.5和Llama 4这类非推理模型反响平淡，说明我们正在逼近仅靠扩大模型规模与数据量所能达到的性能上限。

不过，OpenAI近期发布的o3推理模型证明，只要有策略地投入算力，尤其是通过面向推理任务定制的强化学习方法，性能仍有相当大的提升空间。（根据OpenAI工作人员在近期直播中的透露，o3的训练算力是o1的10倍。）

虽然推理能力本身并非万能灵药，但迄今为止，它能稳定提升模型在高难度任务上的准确率与问题解决能力。而且我预计，聚焦推理的后训练将成为未来大语言模型流水线的标准操作。

因此，本文将探讨通过强化学习实现推理的最新进展。

由于文章篇幅较长，我在下方整理了目录概览。如需跳转目录，请使用网页视图左侧的滑动条。

• 理解推理模型

• RLHF基础：一切的起点

• PPO简介：强化学习的主力算法

• 强化学习算法：从PPO到GRPO

• 强化学习奖励建模：从RLHF到RLVR

• DeepSeek-R1推理模型的训练方式

• 近期推理模型强化学习论文的经验教训

• 值得关注的推理模型训练研究论文

小贴士：如果你已经熟悉推理基础、强化学习、PPO和GRPO，可以直接跳转到“近期推理模型强化学习论文的经验教训”部分，该部分汇总了近期推理研究论文中的有趣洞见。

---

理解推理模型

绕不开的话题当然是“推理”的定义。简而言之，推理指的是让大语言模型更擅长处理复杂任务的推断方法与训练技术。

为了更详细地说明其实现原理（就目前的技术而言），我对推理的定义如下：
在大语言模型的语境下，推理指模型在给出最终答案之前生成中间步骤的能力。这一过程通常被称为思维链（Chain-of-Thought, CoT）推理。在思维链推理中，大语言模型会显式生成一系列结构化的陈述或计算过程，展示自己得出结论的推导路径。

下方是配合该定义的示意图。

如果你刚接触推理模型，想要更全面的入门介绍，推荐阅读我之前的文章：
https://magazine.sebastianraschka.com/p/first-look-at-reasoning-from-scratch

https://magazine.sebastianraschka.com/p/understanding-reasoning-llms

正如本节开头所暗示的，提升大语言模型的推理能力有两种途径，OpenAI一篇博客中的示意图很好地诠释了这一点：

准确率提升可通过增加训练算力或测试时算力实现，其中测试时算力与推理时算力、推理时扩展同义。

在我之前的文章中：
https://magazine.sebastianraschka.com/p/state-of-llm-reasoning-and-inference-scaling

我只重点讨论了测试时算力方法。而在本文中，我终于可以详细聊聊训练方法了。

---

RLHF基础：一切的起点

用于构建和优化推理模型的强化学习训练方法，或多或少都与用于开发和对齐传统大语言模型的**基于人类反馈的强化学习（Reinforcement Learning with Human Feedback, RLHF）**方法相关。因此，在讨论面向推理的强化学习训练变体之前，我先简要回顾一下RLHF的工作原理。

传统大语言模型通常经历三步训练流程：

1. 预训练

2. 监督微调

3. 对齐（通常通过RLHF实现）

RLHF是“原版”的大语言模型对齐方法，是遵循InstructGPT论文开发大语言模型的标准流程之一，该论文描述了初代ChatGPT模型的训练方案。

RLHF的最初目标是让大语言模型对齐人类偏好。例如，假设你多次调用大语言模型，针对同一个提示生成多个答案，RLHF会引导模型生成更多你偏好风格的答案。（通常，RLHF也用于模型的安全对齐：避免泄露敏感信息、避免使用脏话等等。）

如果你刚接触RLHF，这里有我几年前一次演讲的片段，用不到5分钟讲解了RLHF：

或者，下文用文字形式描述RLHF。

RLHF流水线以预训练模型为起点，先进行监督式微调。这一步微调还不属于强化学习环节，而主要是前置准备。

随后，RLHF通过一种名为**近端策略优化（Proximal Policy Optimization, PPO）**的算法进一步对齐大语言模型。（注：也可以使用其他算法替代PPO；我这里专门讲PPO，是因为它是RLHF最初采用的算法，至今仍是最主流的选择。）

为简化起见，我们将RLHF流水线分为三个独立步骤：

• RLHF第1步（前置准备）：对预训练模型进行监督微调（Supervised Fine-Tuning, SFT）

• RLHF第2步：构建奖励模型

• RLHF第3步：通过近端策略优化（PPO）进行微调

RLHF第1步如下图所示，是一个监督微调步骤，用于创建后续RLHF微调的基础模型。

在RLHF第1步中，我们（例如从数据库中）构造或采样提示，然后让人工撰写高质量回复。接着用这个数据集以监督方式微调预训练基础模型。如前所述，严格来说这不属于强化学习训练，而只是前置条件。

在RLHF第2步中，我们利用监督微调（SFT）得到的模型来构建奖励模型，如下图所示。

如上图所示，针对每个提示，我们用上一步微调后的大语言模型生成四个回复。然后人工标注者根据偏好对这些回复进行排序。虽然排序过程耗时，但可能比创建监督微调数据集的工作量要小一些，因为对回复排序通常比撰写回复更简单。

整理好包含这些排序的数据集后，我们就可以设计一个奖励模型，为RLHF第3步的后续优化输出奖励分数。其核心思路是用奖励模型替代并自动化人力密集的人工排序，让大规模数据集上的训练变得可行。

这个奖励模型（Reward Model, RM）通常源自上一步监督微调（SFT）得到的大语言模型。要将RLHF第1步的模型转化为奖励模型，需要将其输出层（下一词分类层）替换为回归层，该层只有一个输出节点。

RLHF流水线的第三步是利用奖励模型（RM）微调上一步监督微调（SFT）得到的模型，如下图所示。

在RLHF的最终阶段（第3步），我们基于第2步创建的奖励模型输出的奖励分数，通过近端策略优化（PPO）更新SFT模型。

《Ahead of AI》是读者支持型出版物。想要接收新文章并支持我的创作，欢迎成为免费或付费订阅者。

---

PPO简介：强化学习的主力算法

如前所述，原版RLHF方法使用一种名为近端策略优化（PPO）的强化学习算法。

PPO的开发初衷是提升策略训练的稳定性与效率。（在强化学习中，“策略”就是我们想要训练的模型；在本文场景下，策略=大语言模型。）

PPO的核心思想之一是限制每次更新步中策略的变化幅度。这通过裁剪损失函数实现，有助于避免模型因更新幅度过大而导致训练失稳。

除此之外，PPO的损失中还包含KL散度惩罚项。该项将当前策略（正在训练的模型）与原始SFT模型进行对比，鼓励更新幅度保持在合理范围内。毕竟，我们的目标是对模型进行偏好微调，而不是完全重新训练。

这就是“近端策略优化”中“近端”一词的由来：算法在允许性能提升的同时，尽量让更新贴近现有模型。此外，为了鼓励一定程度的探索，PPO还加入了熵奖励项，鼓励模型在训练中丰富输出的多样性。

接下来，我会介绍更多术语，从较高层面讲解PPO的原理。不过涉及的专业术语较多，所以在继续之前，我先在下图中总结了关键术语。

下面，我将通过伪代码讲解PPO的关键步骤。

为了更直观，我还会用一个类比：想象你是一位经营小型外卖店的厨师，你不断尝试新的配方变体来提升顾客满意度。你的总体目标是根据顾客反馈（奖励）调整配方（策略）。

1. 计算新策略与旧策略的下一词概率比值：

ratio = new_policy_prob / old_policy_prob

简而言之，这一步是检查新配方和旧配方的差异程度。

注：关于“new_policy_prob”，我们此时还没有使用最终更新后的策略，而是使用当前版本的策略（也就是正在训练过程中的模型）。但按照惯例，我们称之为“新”策略。所以即使你还在试验阶段，按照惯例我们也把当前的版本称为“新策略”。

2. 将该比值乘以动作的优劣程度（称为优势值）：

raw_score = ratio * advantage

为简化起见，我们可以假设优势值是基于奖励信号计算的：

advantage = actual_reward - expected_reward

在厨师的类比中，我们可以把优势值理解为新菜品的表现好坏：

advantage = 顾客评分 - 预期评分

例如，如果顾客给新菜品打了9/10分，而顾客通常给我们打7/10分，那么优势值就是+2。

注意这是简化说法。实际上这涉及广义优势估计（Generalized Advantage Estimation, GAE），为了不让文章过于冗长，我在此省略。不过有一个重要细节需要说明：预期奖励由所谓的“评判器”（critic，有时也称为价值模型）计算，而实际奖励由奖励模型计算。也就是说，优势值的计算涉及另外两个模型，通常与我们正在微调的原始模型规模相同。

在类比中，我们可以把评判器/价值模型想象成一位朋友，在把新菜品端给顾客之前先请他试吃，让他预估顾客会打多少分（也就是预期奖励）。而奖励模型就是实际给出反馈的顾客（也就是实际奖励）。

3. 计算裁剪后的分数：
   如果新策略变化过大（例如比值>1.2或<0.8），我们就对比值进行裁剪，如下所示：

clipped_ratio = clamp(ratio, 0.8, 1.2)
clipped_score = clipped_ratio * advantage

在类比中，想象新配方得到了特别好（或特别差）的评价，我们可能会忍不住直接 overhaul 整个菜单，但这样做风险很高。所以我们先限制配方的改动幅度。（比如，我们可能把菜品做辣了很多，刚好这位顾客爱吃辣，但这不代表所有人都爱吃。）

4. 取原始分数与裁剪后分数中的较小值：

final_score = min(raw_score, clipped_score)

（感谢Johanna Reiml指出我之前关于PPO下界性质的问题，现已修正。）

这同样是出于谨慎的考虑。例如，如果优势值为正（新行为更好），我们会对奖励设置上限，因为我们不想过度信任一个可能只是巧合或运气带来的好结果。

如果优势值为负（新行为更差），我们会限制惩罚幅度。思路也是类似的：除非我们非常确定，否则不会因为一次坏结果就反应过度。

简而言之，当优势值为正时，我们取两个分数中的较小值（避免过度奖励）；当优势值为负时，取较大值（避免过度惩罚）。

在类比中，这能确保如果配方表现超出预期，我们不会贸然重奖，除非我们有足够把握；如果配方表现不佳，我们也不会过度惩罚，除非它一直很差。

5. 计算损失：
   我们在训练中最大化这个最终分数（将分数取负后用梯度下降最小化）。此外，我们还加入KL惩罚项，其中β是惩罚强度的超参数：

loss = -final_score + β * KL(new_policy || reference_policy)

在类比中，我们加入惩罚项是为了确保新配方不会和我们原本的风格相差太远，避免你每周都“彻底颠覆厨房”。比如，我们不想突然把意大利餐厅改成烧烤店。

讲了这么多信息，我在下图中用大语言模型场景下的具体数值例子做了总结。如果觉得太复杂也可以跳过，不影响理解文章后续内容。

我承认刚才的PPO讲解可能有点太细了，但写都写了，舍不得删掉。希望你们当中有人能觉得有用！

话虽如此，下一节相关的核心结论是：PPO涉及多个模型：

1. 策略模型：经过SFT训练、我们想要进一步对齐的大语言模型。

2. 奖励模型：经过训练、用于预测奖励的模型（见RLHF第2步）。

3. 评判器：用于估计奖励的可训练模型。

4. 参考模型（原始策略）：用于确保策略不会偏离太远。

顺便说一句，你可能会好奇，为什么我们同时需要奖励模型和评判器模型？奖励模型通常在使用PPO训练策略模型之前就训练好了，它的作用是替代人工标注者进行偏好标注，为策略大语言模型生成的完整回复打分。

而评判器则是对部分回复进行评判，我们用它来生成最终的回复。奖励模型通常保持冻结，而评判器模型会在训练过程中更新，以更好地估计奖励模型给出的奖励。

PPO的更多细节超出了本文范围，感兴趣的读者可以在早于InstructGPT论文的四篇论文中找到数学细节：
(1) https://arxiv.org/abs/1602.01783 (2016)，Mnih、Badia、Mirza、Graves、Lillicrap、Harley、Silver和Kavukcuoglu提出了策略梯度方法，作为深度强化学习中Q学习的替代方案。
(2) https://arxiv.org/abs/1707.06347 (2017)，Schulman、Wolski、Dhariwal、Radford和Klimov提出了一种改进的近端策略强化学习流程，比上述原版策略优化算法数据效率更高、可扩展性更强。
(3) https://arxiv.org/abs/1909.08593 (2020)，Ziegler、Stiennon、Wu、Brown、Radford、Amodei、Christiano、Irving阐述了将PPO和奖励学习应用于预训练语言模型的概念，包括KL正则化以防止策略偏离自然语言过远。
(4) https://arxiv.org/abs/2009.01325 (2022)，Stiennon、Ouyang、Wu、Ziegler、Lowe、Voss、Radford、Amodei、Christiano提出了流行的RLHF三步流程，该流程后来也被应用于https://arxiv.org/abs/2203.02155 论文中。

---

强化学习算法：从PPO到GRPO

如前所述，PPO是RLHF最初使用的算法。从技术角度看，它在用于开发推理模型的强化学习流水线中完全可以正常工作。不过，DeepSeek-R1在其强化学习流水线中使用了一种名为**组相对策略优化（Group Relative Policy Optimization, GRPO）**的算法，该算法最早在他们的一篇早期论文中提出：
https://arxiv.org/abs/2402.03300 (2024)

DeepSeek团队将GRPO介绍为：

近端策略优化（PPO）的一种变体，在提升数学推理能力的同时优化了PPO的内存占用。

所以，其核心动机是提升计算效率。

效率提升的实现方式是去掉了“评判器”（价值模型），也就是用于计算价值函数（即预期未来奖励）的大语言模型。

GRPO不再依赖这个额外的模型来计算估计奖励以得到优势值，而是采用了更简单的方法：从策略模型本身采样多个答案，利用它们的相对质量来计算优势值。

为了说明PPO和GRPO的区别，我借用了DeepSeekMath论文中的一张经典示意图：

《Ahead of AI》是读者支持型出版物。想要接收新文章并支持我的创作，欢迎成为免费或付费订阅者。

---

强化学习奖励建模：从RLHF到RLVR

到目前为止，我们介绍了RLHF流程，以及两种常用于RLHF的强化学习算法：PPO和GRPO。

但如果RLHF已经是大语言模型对齐工具包的核心部分，那这和推理又有什么关系呢？

RLHF和推理的关联，来自DeepSeek团队将类似的强化学习方法（搭配GRPO）应用于训练其R1和R1-Zero模型的推理能力。

区别在于，DeepSeek-R1团队没有依赖人类偏好并训练奖励模型，而是使用了可验证奖励。这种方法被称为基于可验证奖励的强化学习（Reinforcement Learning with Verifiable Rewards, RLVR）。

需要再次强调：与标准RLHF不同，RLVR不需要奖励模型。

也就是说，模型不需要从人工标注的示例中学习什么是“好”答案，而是从确定性工具（例如符号验证器或基于规则的工具）获得直接的二元反馈（正确或错误）。比如数学题用计算器、代码生成用编译器。

这么做的动机之一，是用自动正确性检查作为强化学习中的监督信号，避免嘈杂或昂贵的人工/学习型奖励。另一个动机是，通过使用计算器这类“低成本”工具，我们可以省去昂贵的奖励模型训练和奖励模型本身。由于奖励模型通常是完整的预训练模型（只是换成了回归头），RLVR的效率要高得多。

简而言之，DeepSeek-R1使用了搭配GRPO的RLVR，这在训练流程中省去了两个昂贵的模型：奖励模型和价值模型（评判器），如下图所示。

下一节，我将简要梳理DeepSeek-R1的训练流水线，并讨论DeepSeek团队使用的不同可验证奖励。

---

DeepSeek-R1推理模型的训练方式

既然我们已经厘清了RLHF和RLVR，以及PPO和GRPO的概念，下面结合强化学习与推理的语境，简要回顾DeepSeek-R1论文的核心结论。

首先，该系列有三类模型：

• DeepSeek-R1-Zero：纯强化学习训练

• DeepSeek-R1：指令微调（SFT）+强化学习训练

• DeepSeek-Distill变体：通过指令微调（SFT）生成，无强化学习

我制作了一张DeepSeek-R1流水线示意图，说明这些模型之间的关系，如下所示。

DeepSeek-R1-Zero采用搭配GRPO的可验证奖励（RLVR）训练，事实证明这足以让模型通过生成中间步骤展现出推理能力。这说明跳过SFT阶段是可行的，模型通过探索而非从示例中学习来提升推理能力。

DeepSeek-R1是旗舰模型，性能最佳。与DeepSeek-R1-Zero的区别在于，它交替进行指令微调、RLVR和RLHF。

DeepSeek-Distill变体定位是更小、更易部署的模型；它们是用DeepSeek-R1模型的指令数据，对Llama 3和Qwen 2.5模型进行指令微调生成的。该方法在推理部分没有使用任何强化学习（不过Llama 3和Qwen 2.5基础模型本身是用RLHF训练的）。

关于DeepSeek-R1流水线的更多细节讲解，可以参见我之前的文章《理解推理型大语言模型》：
https://magazine.sebastianraschka.com/p/understanding-reasoning-llms

这里的核心结论是，DeepSeek团队训练DeepSeek-R1-Zero时没有使用基于大语言模型的奖励模型。相反，他们为DeepSeek-R1-Zero和DeepSeek-R1的推理训练使用了基于规则的奖励：

我们在开发DeepSeek-R1-Zero时没有应用结果型或过程型神经奖励模型，因为我们发现神经奖励模型在大规模强化学习过程中可能会出现奖励钻取问题……

为训练DeepSeek-R1-Zero，我们采用了一套基于规则的奖励系统，主要包含两类奖励：
（1）准确性奖励：准确性奖励模型评估回复是否正确。例如，对于有确定性结果的数学题，要求模型以指定格式（例如放在方框内）给出最终答案，从而实现可靠的基于规则的正确性验证。同理，对于LeetCode题目，可以用编译器基于预定义测试用例生成反馈。
（2）格式奖励：除了准确性奖励模型，我们还采用了格式奖励模型，强制模型将思考过程放在和标签之间。

---

近期推理模型强化学习论文的经验教训

我知道前面的引言部分比我预想的长得多。不过我觉得，要理解后面的经验教训，这段长篇引言或许是必要的。

上个月我研读了大量近期的推理模型论文，在本节汇总了其中最有意思的想法与洞见。（类似“[1]”的引用对应文末列出的相应论文。）

1. 强化学习可进一步提升蒸馏模型的性能

DeepSeek-R1的原始论文明确证明，监督微调（SFT）后接强化学习（RL）的效果优于纯强化学习。

基于这一观察，额外的强化学习理应能进一步提升蒸馏模型的性能（因为蒸馏模型本质上就是用更大模型生成的推理示例，通过SFT训练得到的模型）。

事实上，DeepSeek团队也明确观察到了这一现象：

此外，我们发现对这些蒸馏模型应用强化学习能带来显著的额外提升。我们认为这值得进一步探索，因此本文仅展示简单SFT蒸馏模型的结果。

多个团队独立验证了这些观察结果：

• [8] 研究人员使用1.5B参数的DeepSeek-R1-Distill-Qwen模型，仅用7000个示例和42美元的算力预算，通过强化学习微调就实现了大幅性能提升。令人印象深刻的是，这个小模型在AIME24数学基准上超过了OpenAI的o1-preview。

• [15] 但另一团队提醒说，这些提升可能并不总是具有统计显著性。这表明，虽然强化学习可以优化更小的蒸馏模型，但基准测试结果有时可能高估了提升幅度。

2. 错误长回复的问题

我之前提到，基于可验证奖励的强化学习（RLVR）并非必须搭配GRPO算法；DeepSeek的GRPO恰好效率高、表现好而已。

不过，[12]表明，原版PPO搭配基础的二元正确性奖励，就足以让模型在推理能力和回复长度上实现扩展。

更有意思的是，PPO和GRPO都存在长度偏差。多篇论文探讨了解决错误回复过长问题的方法：

• [14] 分析说明了PPO如何因损失计算中的数学偏差而无意中偏向更长的回复；GRPO可能也存在同样的问题。

承接上述结论，[7][10]明确指出了GRPO中的长度偏差与难度偏差。改进变体Dr. GRPO通过移除长度和标准差归一化来简化优势值计算，提供更清晰的训练信号。

• [1] 在GRPO中明确惩罚冗长的错误回复，同时奖励简洁正确的回复。

• [3][6] 没有在GRPO中直接控制回复长度，但发现token级奖励很有帮助，能让模型更好地聚焦关键推理步骤。

• [5] 在GRPO中引入了对超出特定长度回复的明确惩罚，实现了推理过程中的精准长度控制。

3. 强化学习催生的涌现能力

除了DeepSeek-R1论文中提到的“顿悟”时刻，研究表明强化学习还能让模型产生宝贵的自我验证与反思推理能力[2][9]。有趣的是，和“顿悟”时刻类似，这些能力是在训练中自然涌现的，无需显式指令。

• [1] 表明扩展上下文长度（最高128k token）能进一步提升模型的自我反思与自我纠错能力。

4. 跨特定领域的泛化能力

目前大多数研究都聚焦于数学或编程场景下的推理任务。不过，[4]证明通过在逻辑谜题上训练模型，可以实现成功的泛化——在逻辑谜题上训练的模型，在数学推理任务上也取得了优异表现。这证明强化学习能够诱导出独立于特定领域知识的通用推理行为。

5. 向更广泛领域扩展

承接上一节，另一个有趣的洞见[11]是：推理能力可以自然延伸到数学、编程、逻辑等结构化领域之外。

模型成功将推理应用于医学、化学、心理学、经济学、教育等领域，利用生成式软评分方法有效处理自由形式的答案。

推理模型值得关注的下一步方向包括：

• 将现有推理模型（例如o1、DeepSeek-R1）与外部工具调用、检索增强生成（RAG）等能力结合；OpenAI刚发布的o3模型就在这方面做出了表率。

• 说到工具调用与搜索，[9]表明赋予推理模型搜索能力，会催生自我纠错、跨基准稳健泛化等行为，即便训练数据集很小也能实现。

从DeepSeek-R1团队为维持知识型任务性能所做的努力来看，我认为给推理模型增加搜索能力几乎是必然趋势。

6. 推理能力完全来自强化学习吗？

DeepSeek-R1（以及R1-Zero）的核心主张是，RLVR明确诱导出了推理能力。但近期研究[10]表明，包括“顿悟时刻”在内的推理行为，可能早已存在于基础模型中——因为预训练数据包含了大量思维链内容。

我最近对比DeepSeek V3基础版和R1的结果也印证了这一观察，更新后的基础模型也展现出类推理行为。例如，原版V3和R1模型的对比，清晰体现了非推理模型与推理模型的区别：

但如果对比更新后的V3基础模型和R1，这种差异就不再明显：

此外，[13]发现自我反思与自我纠错行为在预训练过程中，会跨不同领域、不同模型规模逐步涌现。这进一步让“推理能力完全来自强化学习”的归因变得复杂。

或许结论是：强化学习确实能将简单的基础模型转化为推理模型，但它并非诱导或提升推理能力的唯一途径。正如DeepSeek-R1团队所展示的，蒸馏也能提升推理能力。而本文中的蒸馏，指的是在思维链数据上进行指令微调——既然预训练和指令微调本质上都是基于下一词预测任务和损失函数，那么在包含思维链的数据上进行预训练，应该也能诱导出这些能力。（正如我在书中通过实战代码所讲的，预训练和指令微调终究是基于相同的下一词预测任务和损失函数。）

---

值得关注的推理模型训练研究论文

上个月我研读了大量推理论文，在上一节总结了最核心的收获。不过，对于想更深入了解来源的读者，我在本节列出了15篇相关论文作为选读。（为简便起见，以下总结按发表时间排序。）

请注意，这份列表并不全面（我限定在了15篇），因为本文已经够长了！

---

[1] 扩展强化学习（与上下文长度）
📄 1月22日，《Kimi k1.5: Scaling Reinforcement Learning with LLMs》，https://arxiv.org/abs/2501.12599

有意思的是，这篇论文和DeepSeek-R1论文同一天发布！作者们展示了一个用强化学习训练的多模态大语言模型。和DeepSeek-R1类似，他们没有使用过程奖励模型（PRM），而是采用了可验证奖励。过程奖励模型是强化学习（尤其是大语言模型训练）中使用的一类奖励模型，它不仅评估最终答案，还评估得出答案的推理步骤。

另一个核心思路是，扩展上下文长度（最高128k token）有助于模型在推理过程中进行规划、反思和自我纠错。因此，除了和DeepSeek-R1类似的正确性奖励，他们还加入了长度奖励。具体来说，他们鼓励更简短的正确回复，对冗长的错误回复施加更重的惩罚。

他们还提出了一种名为long2short的方法，将这些长思维链技能蒸馏为更高效的短思维链模型。（其实现方式是：通过模型合并、最短拒绝采样、DPO以及第二轮带更强长度惩罚的强化学习等方法，从长思维链模型中蒸馏出更短的正确回复。）

---

[2] 大型推理模型的竞技编程
📄 2月3日，《Competitive Programming with Large Reasoning Models》，https://arxiv.org/abs/2502.06807

这篇来自OpenAI的论文评估了他们的o系列模型（如o1、o1-ioi和o3）在竞技编程任务上的表现。虽然没有深入讲解强化学习的技术细节，但仍提供了一些有趣的结论。

首先，这些模型是用基于结果的强化学习训练的，而非基于过程的奖励模型。这和DeepSeek-R1、Kimi等方法类似。

其中一个有趣的发现是，o3可以自己学习测试时（即推理时扩展）策略。例如，它经常先写出问题的简单暴力解法（一种牺牲效率换正确性的做法），然后用它来验证自己更优解法的输出。这种策略不是人工编写的，而是模型自己摸索出来的。

总体而言，论文认为扩展通用型强化学习，能让模型发展出自己的推理与验证方法，无需任何人工启发式或特定领域的推理流水线。相比之下，o1-ioi等更早的模型依赖手工设计的测试时策略，比如对数千个样本聚类并重排序，这需要大量的人工设计与调优。

---

[3] 探索结果奖励的极限
📄 2月10日，《Exploring the Limit of Outcome Reward for Learning Mathematical Reasoning》，https://arxiv.org/abs/2502.06781

这篇论文探究了仅靠二元“正确/错误”反馈的强化学习（就像DeepSeek-R1那样）在解决数学问题上能走多远。为此，他们首先使用最优N采样（Best-of-N sampling）收集正样本，并对其进行行为克隆，且从理论上证明这足以优化策略。

为了应对奖励稀疏的挑战（尤其是当长思维链包含部分正确步骤时），他们加入了一个token级奖励模型，学习为推理的不同部分分配重要性权重。这有助于模型在学习时聚焦最关键的步骤，从而提升整体性能。

---

[4] 基于规则强化学习的大语言模型推理（逻辑数据）
📄 2月20日，《Logic-RL: Unleashing LLM Reasoning with Rule-Based Reinforcement Learning》，https://arxiv.org/abs/2502.14768

DeepSeek-R1聚焦于数学和编程任务，而这篇论文用逻辑谜题作为主要训练数据来训练7B模型。

研究人员采用了和DeepSeek-R1类似的基于规则的强化学习设置，但做了几处调整：

1. 引入严格的格式奖励，惩罚走捷径的行为，确保模型用和标签区分推理过程和最终答案。

2. 还使用了系统提示，明确告诉模型在给出最终答案之前，先一步步思考问题。

即便只用了5000道合成逻辑题，模型也发展出了良好的推理能力，并且能很好地泛化到AIME、AMC等更难的数学基准上。

这一点尤其有意思，因为它表明基于逻辑的强化学习训练，能教会模型以可迁移到原领域之外的方式进行推理。

---

[5] 控制推理模型的思考长度
📄 3月6日，《L1: Controlling How Long A Reasoning Model Thinks With Reinforcement Learning》，https://arxiv.org/abs/2503.04697

推理模型的一个显著特点是，由于思维链推理，它们往往会生成更长的输出。但默认情况下，没有明确的方法来控制回复长度。

这篇论文提出了长度控制策略优化（Length Controlled Policy Optimization, LCPO），这是一种简单的强化学习方法，能帮助模型在优化准确率的同时，遵守用户指定的长度约束。

简而言之，LCPO和GRPO类似，相当于“加入长度控制定制奖励的GRPO”，奖励公式为：

reward = reward_correctness - α * |target_length - actual_length|

其中目标长度作为用户提示的一部分提供。上述LCPO方法鼓励模型严格贴合给定的目标长度。

此外，他们还提出了LCPO-Max变体，它不鼓励模型精确匹配目标长度，而是鼓励模型保持在最大token长度以下：

reward = reward_correctness * clip(α * (target_length - actual_length) + δ, 0, 1)

作者用LCPO训练了一个名为L1的1.5B模型，它可以根据提示调整输出长度。这让用户可以根据任务在准确率和算力之间做权衡。有趣的是，论文还发现这些长思维链模型其实也非常擅长短推理，在相同token长度下甚至超过了GPT-4o等大得多的模型。

---

[6] 激励大语言模型的搜索能力
📄 3月10日，《R1-Searcher: Incentivizing the Search Capability in LLMs via Reinforcement Learning》，https://arxiv.org/abs/2503.05592

像DeepSeek-R1这类用强化学习训练的推理模型，依赖的是自身的内部知识。本文作者专注于提升这类模型在知识型任务上的表现——这些任务需要更多时效性或最新信息——方法是让模型接入外部搜索系统。

因此，本文通过教模型在推理过程中使用外部搜索系统来改进这些模型。作者没有依赖测试时策略或监督训练，而是采用两阶段强化学习方法，帮助模型自主学习搜索的时机与方式。模型先学习搜索格式，然后学习如何利用搜索结果找到正确答案。

---

[7] 规模化开源大语言模型强化学习
📄 3月18日，《DAPO: An Open-Source LLM Reinforcement Learning System at Scale》，https://arxiv.org/abs/2503.14476

虽然这篇论文主要围绕开发一套类DeepSeek-R1的训练流水线并将其开源，但它也对DeepSeek-R1训练中使用的GRPO算法提出了有趣的改进：

1. 更高裁剪上限（Clip-higher）：提高PPO裁剪范围的上限，鼓励探索并防止训练过程中的熵坍缩。

2. 动态采样：过滤掉所有采样回复要么全对、要么全错的提示，提升训练效率。

3. Token级策略梯度损失：从样本级损失计算转为token级损失计算，让更长的回复对梯度更新产生更大影响。*

4. 过长奖励塑形：对因过长而被截断的回复加入软惩罚，减少奖励噪声并帮助稳定训练。

*标准GRPO采用样本级损失计算：先对每个样本的token损失求平均，再对所有样本的损失求平均。由于每个样本权重相同，回复更长的样本中的token对整体损失的贡献可能不成比例地偏低。同时，研究人员观察到更长的回复在最终答案之前往往包含无意义内容，而在原版GRPO的样本级损失计算中，这些无意义内容不会得到足够的惩罚。

---

[8] 小型大语言模型的推理强化学习：有效与无效之处
📄 3月20日，《Reinforcement Learning for Reasoning in Small LLMs: What Works and What Doesn’t》，https://arxiv.org/abs/2503.16219

DeepSeek-R1的原始论文表明，开发小型推理模型时，蒸馏的效果优于纯强化学习。在这篇论文中，研究人员跟进了这一结论，研究如何用强化学习进一步优化小型蒸馏推理模型。

他们使用1.5B参数的DeepSeek-R1-Distill-Qwen模型，发现仅用7000个训练示例和42美元的算力预算，强化学习微调就能带来显著提升。例如，这种提升足以让模型在AIME24数学基准上超过OpenAI的o1-preview。

此外，论文还有3个有趣的发现：

1. 小型大语言模型使用紧凑、高质量的数据集，在最初的50-100个训练步内就能快速获得推理提升。但如果训练时间过长，性能会迅速下降，主要原因是长度限制和输出不稳定。

2. 混合简单题和难题有助于模型在训练早期生成更短、更稳定的回复，但长期来看性能仍会下降。

3. 使用余弦形奖励函数能更有效地控制输出长度，提升训练一致性，但与标准的基于准确性的奖励相比，峰值性能会略有下降。

---

[9] 学会带着搜索进行推理
📄 3月25日，《ReSearch: Learning to Reason with Search for LLMs via Reinforcement Learning》，https://arxiv.org/abs/2503.19470

本文提出的ReSearch框架，将DeepSeek-R1论文的强化学习方法扩展为将搜索结果作为推理过程的一部分。模型会根据正在进行的推理链学习何时搜索、如何搜索，然后利用检索到的信息进行后续推理步骤。

这一切都无需推理步骤的监督数据。研究人员还表明，这种方法能催生出自我纠错、反思等有用行为，并且尽管只在一个数据集上训练，却能在多个基准上很好地泛化。

附：这种方法和之前讨论的R1-Searcher有什么区别？
R1-Searcher采用两阶段、基于结果的强化学习方法：第一阶段教模型如何调用外部检索；第二阶段学习利用检索到的信息回答问题。

而ReSearch将搜索直接整合到推理过程中，它通过强化学习端到端训练模型，不对推理步骤做任何监督。对错误查询进行反思并纠正等行为，是在训练中自然涌现的。

---

[10] 解读类R1-Zero训练：批判性视角
📄 3月26日，《Understanding R1-Zero-Like Training: A Critical Perspective》，https://arxiv.org/abs/2503.20783

这篇论文研究了为什么DeepSeek-R1-Zero的纯强化学习方法能有效提升推理能力。

作者发现，像Qwen2.5这样的一些基础模型，即使没有经过任何强化学习，也已经展现出很强的推理能力，甚至能出现“顿悟时刻”。所以“顿悟时刻”可能不是强化学习诱导的，而是从预训练中继承来的。这对“仅靠强化学习就能产生深度推理行为”的观点提出了挑战。

论文还指出了GRPO的两个偏差：

1. 回复长度偏差：GRPO用回复长度对优势值做归一化，这使得长错误回复受到的惩罚更小，于是模型学会生成更长的错误答案。

2. 难度级别偏差：GRPO还会按每个问题奖励的标准差做归一化，简单题或难题（奖励方差低）会被过度加权。

为了解决这个问题，作者提出了Dr. GRPO，这是标准GRPO的改进版本。他们在优势值计算中去掉了回复长度归一化，同时去掉了问题级的标准差。这会让训练更高效，减少不必要的长回复。尤其是当模型出错时，不再鼓励生成长答案。

---

[11] 跨多元领域扩展可验证奖励强化学习
📄 3月31日，《Crossing the Reward Bridge: Expanding RL with Verifiable Rewards Across Diverse Domains》，https://arxiv.org/abs/2503.23829

DeepSeek-R1和后续大多数推理模型都聚焦于代码、数学等容易验证的领域的奖励信号。这篇论文探索了如何将这些方法扩展到医学、化学、心理学、经济学、教育等更复杂的领域——这些领域的答案通常是自由形式的，更难验证（不只是简单的对/错）。

作者发现，使用专家撰写的参考答案，能让评估在这些更广泛的领域中变得比预期更可行。为了提供奖励信号，他们引入了一种生成式软评分方法，不需要大量的特定领域标注。

---

[12] 用简单设置扩展强化学习
📄 3月31日，《Open-Reasoner-Zero: An Open Source Approach to Scaling Up Reinforcement Learning on the Base Model》，https://arxiv.org/abs/2503.24290

在这篇论文中，作者探索了一种极简的强化学习设置，用于在推理任务上训练大语言模型。他们使用原版PPO而非GRPO（DeepSeek-R1-Zero用的是GRPO），并且跳过了RLHF流水线中常见的KL正则化。

有趣的是，他们发现这种简单设置（原版PPO + 基于答案正确性的基础二元奖励函数）足以训练出在推理性能和回复长度上都能实现扩展的模型。

使用和DeepSeek-R1-Zero相同的Qwen-32B基础模型，他们的模型在多个推理基准上表现更优，而训练步数仅为后者的1/10。

---

[13] 重新思考预训练中的反思能力
📄 4月5日，《Rethinking Reflection in Pre-Training》，https://arxiv.org/abs/2504.04022

基于DeepSeek-R1论文的有趣洞见——即对基础模型应用纯强化学习，我们认为大语言模型的推理能力源自强化学习。而这篇论文带来了一点反转：它指出自我纠错其实在预训练阶段就已经更早出现了。

具体来说，作者通过在任务中引入故意出错的思维链，测试模型是否能识别并纠正这些错误。他们发现，显式和隐式形式的反思能力都会在预训练过程中稳步涌现，这一现象跨多个领域、多种模型规模都存在。即使是相对早期的检查点也表现出自我纠错的迹象，并且随着预训练算力的增加，这种能力会变得更强。

---

[14] 通过强化学习实现简洁推理
📄 4月7日，《Concise Reasoning via Reinforcement Learning》，https://arxiv.org/abs/2504.05185

众所周知，推理模型往往会生成更长的回复，这会推高算力成本。而这篇新论文表明，这种行为源于强化学习训练过程，而非因为长答案真的能提升准确率。当模型得到负奖励时，强化学习损失倾向于偏好更长的回复——我认为这解释了纯强化学习训练中出现的“顿悟”时刻和更长的思维链。

也就是说，如果模型得到负奖励（即答案错误），PPO背后的数学机制会让更长回复的平均每token损失变得更小。于是模型会间接地被鼓励拉长回复，即便这些额外的token其实对解决问题毫无帮助。

回复长度和损失有什么关系？当奖励为负时，更长的回复可以稀释单个token受到的惩罚，从而得到更低（也就是更好）的损失值（哪怕模型还是答错了）。

所以模型“学会了”：更长的回复能减轻惩罚，即便它们对提升正确率毫无帮助。

不过需要强调的是，这一分析是针对PPO的：

值得注意的是，我们目前的分析不适用于GRPO，对此类方法的精确分析留待未来工作。

此外，研究人员表明，第二轮强化学习（只用少量可解的问题）可以在保持甚至提升准确率的同时缩短回复长度。这对部署效率有重要意义。

---

[15] 理性看待大语言模型推理的进展
📄 4月9日，《A Sober Look at Progress in Language Model Reasoning: Pitfalls and Paths to Reproducibility》，https://arxiv.org/abs/2504.07086

这篇论文深入审视了近期“强化学习能提升蒸馏语言模型（比如基于DeepSeek-R1的模型）”的相关主张。

例如，我之前讨论过的3月20日那篇《小型大语言模型的推理强化学习：有效与无效之处》，就发现强化学习对蒸馏模型有效。

而DeepSeek-R1论文也提到：

此外，我们发现对这些蒸馏模型应用强化学习能带来显著的额外提升。我们认为这值得进一步探索，因此本文仅展示简单SFT蒸馏模型的结果。

虽然早期论文报告强化学习带来了大幅性能提升，但这项研究发现，其中很多提升可能只是噪声。作者表明，像AIME24这样的小型基准上的结果非常不稳定：仅仅改变随机种子，分数就可能波动好几个百分点。

在更受控、更标准化的设置下评估强化学习模型时，提升幅度远小于最初报告的数值，而且通常不具备统计显著性。不过，一些用强化学习训练的模型确实表现出适度提升，但通常弱于监督微调的效果，并且往往无法很好地泛化到新基准上。

因此，虽然强化学习在某些情况下确实能帮助优化更小的蒸馏模型，但这篇论文认为其益处被夸大了，我们需要更好的评估标准来理解真正起作用的是什么。

---

本杂志是一项个人热爱项目。如果你想支持我这位独立研究者，欢迎购买我的书：https://amzn.to/4fqvn0D ，或者订阅https://magazine.sebastianraschka.com/subscribe 。

如果你读过这本书，能抽出几分钟时间的话，我会非常感谢你留下评价：https://www.amazon.com/Build-Large-Language-Model-Scratch/dp/1633437167 。这对我们作者帮助很大！

非常感谢你的支持！

原文地址：First Look at Reasoning From Scratch: Chapter 1，by Sebastian Raschka, on 2025-04-29

从零初探推理：第1章

当代大语言模型的推理入门

大家好：

如各位所知，我近期撰写了大量关于大语言模型推理前沿研究的内容。在下一篇聚焦研究的博客文章发布前，我想为付费订阅者准备一份特别内容，感谢大家一直以来的支持。

目前我正在撰写一本关于大语言模型推理原理的新书，今天先和大家分享全书的第 1 章。这一章约 15 页，是大语言模型领域的推理入门内容，概述了推理时算力扩展、强化学习等核心方法。

感谢各位的支持！希望大家喜欢这一章节，也敬请期待我下一篇关于推理研究的博客文章。

祝阅读愉快
塞巴斯蒂安

---

第 1 章 引言

欢迎来到大语言模型（LLM）发展的下一阶段：推理。大语言模型已经彻底改变了我们处理与生成文本的方式，但此前其能力的核心驱动力主要是统计模式识别。如今，推理方法的新进展让大语言模型能够应对更复杂的任务，比如解答逻辑谜题、完成多步算术运算。理解这些方法，正是本书的核心主题。

在这一入门章节中，你将学习：

• “推理” 在大语言模型语境下的具体定义

• 推理与模式匹配的本质区别

• 大语言模型常规的预训练与后训练阶段

• 提升大语言模型推理能力的核心方法

• 为什么从零搭建推理模型，能帮助我们更深入地理解其优势、局限与实际权衡

在本章搭建完基础概念之后，后续章节将转向实操代码案例，带你直接实现大语言模型的推理技术。

1.1 对大语言模型而言，“推理” 意味着什么？

Continue reading 【转载】从零初探推理：第1章→

原文地址：The State of LLM Reasoning Model Inference，by Sebastian Raschka, on 2025-03-08

大语言模型推理模型的推理现状

提升推理模型的推理时计算扩展方法

2025年3月8日

提升大语言模型（LLM）的推理能力已成为2025年最热门的话题之一，这并非没有缘由。更强的推理能力让大语言模型能够解决更复杂的问题，使其在用户关心的各类任务中表现更出色。

过去几周，研究人员提出了大量提升推理能力的新策略，包括推理时计算扩展、强化学习、监督微调以及知识蒸馏。许多方法还会结合这些技术以实现更优效果。

本文探讨了推理优化型大语言模型的最新研究进展，重点关注自深度求索（DeepSeek）R1发布以来涌现的推理时计算扩展技术。

我在《理解推理型大语言模型》（https://magazine.sebastianraschka.com/p/understanding-reasoning-llms）一文中阐述的推理模型实现的四大类别。本文聚焦于推理时扩展方法。

在大语言模型中实现并优化推理：四大类别

由于大多数读者可能已经熟悉大语言模型推理模型，我将简而言之：基于大语言模型的推理模型是一类通过生成中间步骤或结构化“思考”过程来解决多步骤问题的大语言模型。与仅输出最终答案的简单问答类大语言模型不同，推理模型要么显式展示其思考过程，要么在内部完成处理，这让它们在谜题、编程挑战和数学问题等复杂任务中表现更优。

基础大语言模型的单行回答与推理型大语言模型的解释性回答的并排对比。

总体而言，提升推理能力主要有两种策略：（1）增加训练计算量；（2）增加推理计算量，也称为推理时扩展或测试时扩展。（推理计算量指的是训练完成后，模型响应用户查询生成输出所需的算力。）

可通过增加训练计算量或测试时计算量实现准确率提升，其中测试时计算量与推理时计算量、推理时扩展含义相同。来源：改编自《学会用大语言模型推理》（https://openai.com/index/learning-to-reason-with-llms/）中的配图。

需要注意的是，上图看起来似乎我们只能通过训练时计算量或测试时计算量其中一种方式来提升推理能力。但实际上，大语言模型通常会结合大量训练时计算（通常结合强化学习或专用数据进行大规模训练或微调）与增加的测试时计算（让模型“思考更久”或在推理过程中执行额外运算），共同提升推理能力。

与推理时扩展含义相近的诸多术语。

要理解推理模型的开发与优化路径，分别研究不同技术仍有其价值。在我之前的文章《理解推理型大语言模型》（https://magazine.sebastianraschka.com/p/understanding-reasoning-llms）中，我将其细分为四大类别，如下图所示。

上图中的第2-4类方法通常会让模型生成更长的回答，因为输出中包含了中间步骤和解释。由于推理成本随回答长度线性增长（例如，长度翻倍的回答需要两倍的计算量），这些训练方法本质上与推理扩展相关联。但在本节关于推理时计算扩展的内容中，我将专门聚焦于那些通过额外采样策略、自校正机制或其他方式，显式调控生成token数量的技术。

在本文中，我将重点介绍2025年1月22日深度求索R1发布之后，围绕推理时计算扩展涌现的最新研究论文与模型发布。（原本我打算在本文中涵盖所有类别的方法，但由于篇幅过长，我决定未来单独发布一篇聚焦训练时计算方法的文章。）

我在上一篇文章《理解推理型大语言模型》（https://magazine.sebastianraschka.com/p/understanding-reasoning-llms）中讨论的深度求索推理模型开发流程。

在深入探讨推理时计算扩展方法，以及推理模型在该领域的各项进展之前，我先简要概述一下所有四大类别。

1. 推理时计算扩展

该类别包含在推理阶段提升模型推理能力、无需训练或修改底层模型权重的方法。核心思路是以增加计算资源为代价换取性能提升，通过思维链推理、各类采样流程等技术，让固定参数的模型也能具备更强的能力。

尽管我将推理时计算扩展单独归类以便聚焦研究，但需要注意的是，该技术可应用于任何大语言模型。例如，OpenAI通过强化学习开发了o1模型，随后又额外运用了推理时计算扩展技术。有趣的是，正如我在上一篇关于推理模型的文章（https://magazine.sebastianraschka.com/p/understanding-reasoning-llms）中提到的，深度求索R1的论文明确将常见的推理时扩展方法（如基于过程奖励模型和蒙特卡洛树搜索的方法）归为“不成功的尝试”。这表明，除了模型本身生成长回答的自然倾向（这是相对于V3基座模型的一种隐式推理时扩展）之外，深度求索并未在R1中显式使用这些技术。不过，由于显式推理时扩展通常在应用层实现，而非大语言模型内部，深度求索也表示可以很轻松地将其集成到R1的部署或应用中。

2. 纯强化学习

该方法完全依靠强化学习（RL）来开发或提升推理能力，通常利用数学或编程领域中可验证的奖励信号训练模型。虽然强化学习能让模型形成更具策略性的思维和自我提升能力，但也存在奖励破解、训练不稳定、计算成本高等挑战。

3. 强化学习与监督微调结合

这种混合方法将强化学习与监督微调（SFT）相结合，相比纯强化学习能实现更稳定、泛化性更强的提升。通常先让模型在高质量指令数据上进行监督微调训练，再通过强化学习进一步优化特定行为。

4. 监督微调与模型蒸馏

该方法通过在高质量标注数据集上进行指令微调（SFT）来提升模型的推理能力。如果这份高质量数据集由更大的大语言模型生成，那么在大语言模型语境下，这种方法也被称为“知识蒸馏”或简称“蒸馏”。但需要注意，这与深度学习中的传统知识蒸馏略有不同——传统知识蒸馏通常不仅利用大模型的输出（标签），还会利用教师模型的logits（对数概率）来训练小模型。

《Ahead of AI》是一份读者支持的出版物。想要接收新文章并支持我的创作，欢迎成为免费或付费订阅者。

---

推理时计算扩展方法

上一节已经简要概述了推理时计算扩展。在讨论该领域的最新研究之前，我先更详细地介绍一下推理时扩展。

推理时扩展通过在推理阶段增加计算资源（“算力”）来提升大语言模型的推理能力。其背后的逻辑可以用一个简单的类比来解释：人类有更多时间思考时，会给出更优质的回答；同理，大语言模型也能通过鼓励生成过程中进行更多“思考”的技术来提升表现。

其中一种方法是提示工程，比如思维链（CoT）提示——通过“一步步思考”这类表述引导模型生成中间推理步骤。这能提升复杂问题的准确率，但对于简单的事实类查询则没有必要。由于思维链提示会生成更多token，实际上也推高了推理成本。

经典思维链提示示例，出自2022年论文《大语言模型是零样本推理器》（https://arxiv.org/abs/2205.11916）。

另一种方法是投票与搜索策略，比如多数投票或集束搜索，通过筛选最优输出来优化回答。

不同的基于搜索的方法依靠过程奖励模型来选择最佳答案。改编自论文《大语言模型的测试时计算》（https://arxiv.org/abs/2408.03314）中的配图。

1. “s1：简单测试时扩展”

本文余下部分将聚焦于提升大语言模型推理能力的推理时扩展领域的最新研究进展。我先详细讨论一篇论文，作为推理时扩展的典型案例。

该领域近期一篇有意思的论文是《通过预算强制实现大语言模型的可控推理》（https://arxiv.org/abs/2501.19393，2025年1月31日），文中提出了所谓的“等待”（wait）token，可以看作是前文提到的“一步步思考”提示修改方法的更现代版本。

需要注意的是，该方法需要通过监督微调生成初始模型，因此并非纯粹的推理时扩展方法。但其最终目标是通过推理时扩展主动调控推理行为，因此我将这篇论文归入“1. 推理时计算扩展”类别。

简而言之，他们的方法分为两部分：

1. 构建一份经过筛选的监督微调数据集，包含1000个带推理轨迹的训练样本。
2. 通过以下方式控制回答长度：
   a) 追加“等待”token，让大语言模型生成更长的回答、进行自我验证与自我修正；
   b) 添加思考结束标记分隔符（“最终答案：”）来终止生成。
   他们将这种长度控制称为“预算强制”（budget forcing）。

插入“等待”token控制输出长度的示意图。改编自论文《通过预算强制实现大语言模型的可控推理》（https://arxiv.org/abs/2501.19393）中的配图。

预算强制可以看作一种串行推理扩展技术，因为它仍然是逐个生成token（只是生成更多）。与之相对的是多数投票这类并行技术，通过聚合多个独立生成的结果来实现扩展。

回答准确率与长度的相关性。改编自论文《通过预算强制实现大语言模型的可控推理》（https://arxiv.org/abs/2501.19393）中的配图。

他们发现，预算强制方法比我之前讨论过的多数投票等其他推理扩展技术效果更好。如果说有什么值得商榷或改进的地方，我希望能看到更复杂的并行推理扩展方法的结果，比如集束搜索、前瞻搜索，或是谷歌去年论文《大语言模型的测试时计算》（https://arxiv.org/abs/2408.03314）中提出的最优计算搜索方法。哪怕是和思维链提示（“一步步思考”）这种经典串行方法做个简单对比也好。

无论如何，这都是一篇非常有意思的论文，提出的方法也很有价值！

附：为什么是“等待”token？我猜研究人员是受到了深度求索R1论文中“顿悟时刻”配图的启发——研究人员观察到大语言模型会生成类似“等等，等等。等一下。这是一个顿悟时刻，我可以在这里标记一下。”的内容，这表明纯强化学习可以诱导大语言模型产生推理行为。

有趣的是，他们也尝试了“嗯（Hmm）”等其他token，但发现“等待”的表现略胜一筹。

“等待”与“嗯”token效果对比。改编自论文《通过预算强制实现大语言模型的可控推理》（https://arxiv.org/abs/2501.19393）中的配图。

---

其他值得关注的推理时计算扩展研究论文

近一个月推理模型研究领域非常活跃，为了控制文章篇幅，我需要简要概括其他论文。因此，以下是其他与推理时计算扩展相关的精彩研究的简介，按发表时间升序排列。

如前所述，并非所有论文都完全属于推理时计算扩展类别，部分研究也涉及特定的训练环节。但这些论文的共同点在于，对推理时计算量的调控是其核心作用机制。（我将在后续文章中介绍的许多蒸馏或监督微调方法也会让回答变长，这也可以看作一种推理时计算扩展。但它们不会在推理过程中主动控制长度，这是与本文介绍方法的核心区别。）

2. 测试时偏好优化

📄 1月22日，《测试时偏好优化：通过迭代文本反馈实现实时对齐》，https://arxiv.org/abs/2501.12895

测试时偏好优化（TPO）是一种在推理阶段让大语言模型输出对齐人类偏好的迭代过程（无需修改底层模型权重）。在每一轮迭代中，模型会：

1. 针对给定提示生成多个回答；
2. 用奖励模型对回答打分，选出得分最高和最低的回答，分别作为“选中”和“被拒”回答；
3. 引导模型对比并点评“选中”与“被拒”的回答；
4. 将点评转化为文本建议，以此优化模型最初的回答。

通过重复执行步骤1-4，模型不断打磨其原始回答。

改编自论文《测试时偏好优化：通过迭代文本反馈实现实时对齐》（https://arxiv.org/abs/2501.12895）中的配图。

3. 思考杂乱无章：o1类大语言模型的思考不足问题

📄 1月30日，《思考杂乱无章：o1类大语言模型的思考不足问题》，https://arxiv.org/abs/2501.18585

研究人员探究了一种名为“思考不足”（underthinking）的现象：推理模型会频繁在不同推理路径之间切换，而非专注深入探索有潜力的路径，从而降低了解题准确率。

为解决“思考不足”问题，他们提出了“思考切换惩罚”（TIP）方法，通过调整思考切换token的对数概率，抑制推理路径的过早跳转。

该方法无需模型微调，实验证明可在多个高难度测试集上提升准确率。

改编自论文《思考杂乱无章：o1类大语言模型的思考不足问题》（https://arxiv.org/abs/2501.18585）中的配图。

4. 以推理时计算换取对抗鲁棒性

📄 1月31日，《以推理时计算换取对抗鲁棒性》，https://arxiv.org/abs/2501.18841

在大多数情况下，增加推理时计算量能提升推理型大语言模型的对抗鲁棒性，降低攻击成功率。与对抗训练不同，该方法无需专门训练，也不需要提前了解具体的攻击类型。

但也存在一些重要的例外情况。例如，在涉及策略模糊性或漏洞利用的场景中，提升效果有限。此外，“少思考”“书呆子狙击”等新型攻击策略，也会削弱推理提升带来的鲁棒性增益。

因此，尽管研究表明扩展推理时计算量可以提升大语言模型的安全性，但仅凭这一点无法完全解决对抗鲁棒性问题。

改编自论文《以推理时计算换取对抗鲁棒性》（https://arxiv.org/abs/2501.18841）中的配图。

5. 关联思维链

📄 2月4日，《CoAT：提升大语言模型推理能力的关联思维链框架》，https://arxiv.org/abs/2502.02390

研究人员将经典的蒙特卡洛树搜索推理时扩展，与一种“联想记忆”相结合——后者在推理路径探索过程中充当大语言模型的知识库。借助这种联想记忆，大语言模型能更容易地回溯之前的推理路径，并在回答生成过程中运用动态演化的信息。

改编自论文《CoAT：提升大语言模型推理能力的关联思维链框架》（https://arxiv.org/abs/2502.02390）中的配图。

6. 退一步，进千里：通过自回溯提升语言模型推理能力

📄 2月6日，《退一步，进千里：通过自回溯提升语言模型推理能力》，https://arxiv.org/abs/2502.04404

本文提出了一种自回溯机制，让大语言模型通过在训练和推理阶段学习何时、何处回溯来提升推理能力。训练阶段通过<backtrack>标记教模型识别并修正欠佳的推理路径；而其核心贡献是一种推理时的树状搜索方法，利用习得的回溯能力探索备选解法。

其独特之处在于，这种探索无需依赖外部奖励模型（与本文“1. 推理时计算扩展方法”部分开头提到的基于过程奖励模型的搜索方法不同）。

改编自论文《退一步，进千里：通过自回溯提升语言模型推理能力》（https://arxiv.org/abs/2502.04404）中的配图。

我将这篇论文放在这里，是因为它重点聚焦于提出的回溯式推理时扩展方法——该方法通过动态调整搜索深度与广度提升推理能力，而非从根本上改变训练范式（尽管仍需要用<backtrack>标记进行训练）。

7. 基于隐式推理的测试时计算扩展：循环深度方法

📄 2月7日，《基于隐式推理的测试时计算扩展：循环深度方法》，https://arxiv.org/abs/2502.05171

研究人员没有通过生成更多token来提升推理能力，而是提出了一种模型，通过在隐空间中迭代循环深度模块来扩展推理时计算量。该模块的作用类似于循环神经网络（RNN）中的隐藏状态，让模型无需生成更长的token输出就能优化推理过程。

但一个关键缺点是缺乏显式的推理步骤——在我看来，显式步骤对人类可解释性很重要，也是思维链方法的一大优势。

改编自论文《基于隐式推理的测试时计算扩展：循环深度方法》（https://arxiv.org/abs/2502.05171）中的配图。

8. 10亿参数大语言模型能超越4050亿参数模型吗？

📄 2月10日，《10亿参数大语言模型能超越4050亿参数模型吗？重新思考计算最优的测试时扩展》，https://arxiv.org/abs/2502.06703

许多推理时扩展技术都依赖采样，需要过程奖励模型（PRM）来筛选最优解。本文系统分析了推理时计算扩展与过程奖励模型、问题难度之间的相互作用。

研究人员提出了一种计算最优的扩展策略，可根据过程奖励模型、策略模型和任务复杂度自适应调整。结果表明，采用合适的推理时扩展方法后，10亿参数模型的表现能超过未使用推理时扩展的4050亿参数Llama 3模型。

他们还证明，70亿参数模型结合推理时扩展后，性能超越深度求索R1，同时保持了更高的推理效率。

这些发现凸显了推理时扩展对大语言模型的显著提升作用——只要推理计算预算合理，小模型也能超越大得多的模型。

改编自论文《10亿参数大语言模型能超越4050亿参数模型吗？重新思考计算最优的测试时扩展》（https://arxiv.org/abs/2502.06703）中的配图。

9. 测试时从反馈中学习推理

📄 2月16日，《测试时从反馈中学习推理》，https://arxiv.org/abs/2502.15771

很难将该方法单纯归为推理时或训练时方法，因为它会在推理阶段优化大语言模型、修改其权重参数。

本文探究了一种让大语言模型在推理阶段从错误中学习的方法，无需将失败尝试存入提示（那样成本很高）。传统方法要么通过将之前的尝试加入上下文来修正答案（串行修正），要么盲目生成新答案（并行采样）；而该方法会在推理时更新模型权重。

为此，作者提出了OpTune——一个小型可训练优化器，根据模型上一次尝试中的错误更新权重。这意味着模型能记住自己的错误，无需在提示/上下文中保留错误答案。

改编自论文《测试时从反馈中学习推理》（https://arxiv.org/abs/2502.15771）中的配图。

10. 面向大语言模型推理与规划的推理时计算

📄 2月18日，《面向大语言模型推理与规划的推理时计算：基准与洞见》，https://www.arxiv.org/abs/2502.12521

本文针对推理与规划任务，对多种推理时计算扩展技术进行了基准测试，重点分析了它们在计算成本与性能之间的权衡。

作者在算术推理、逻辑推理、常识推理、算法推理和规划五大类共11项任务上，评估了思维链、思维树、规划式推理等多种技术。

核心发现是，尽管扩展推理时计算量能提升推理能力，但没有任何一种技术能在所有任务上始终优于其他方法。

改编自论文《面向大语言模型推理与规划的推理时计算：基准与洞见》（https://www.arxiv.org/abs/2502.12521）中的配图。

11. 内思考Transformer

📄 2月19日，《内思考Transformer：利用动态深度扩展促进自适应内部思考》，https://arxiv.org/abs/2502.13842

内思考Transformer（ITT）会在推理阶段动态分配更多算力。标准Transformer架构的大语言模型对所有token都使用固定深度（即相同层数），而ITT采用自适应token路由，为难度更高的token分配更多算力。这些高难度token会多次经过同一层进行额外处理，从而增加了它们的推理计算预算。

改编自论文《内思考Transformer：利用动态深度扩展促进自适应内部思考》（https://arxiv.org/abs/2502.13842）中的配图。

12. 面向代码生成的测试时扩展

📄 2月20日，《S*：面向代码生成的测试时扩展》，https://arxiv.org/abs/2502.14382

推理时扩展可以通过并行扩展（生成多个答案）、串行扩展（迭代优化答案）实现，也可以两者结合，正如2024年夏季谷歌的论文（https://arxiv.org/abs/2408.03314）中所述。

S*是专门为代码生成设计的测试时计算扩展方法，同时优化了并行扩展（生成多个解法）和串行扩展（迭代调试）。

改编自论文《S*：面向代码生成的测试时扩展》（https://arxiv.org/abs/2502.14382）中的配图。

该方法分为两个阶段：

阶段1：生成阶段

模型生成多份代码解法，并利用执行结果与问题提示中的测试用例迭代优化。
这就像编程竞赛：模型提交解法、运行测试、修正错误：

1. 模型生成多个候选解法；
2. 每个解法在公开测试用例（预定义的输入输出对）上运行；
3. 如果解法失败（输出错误或程序崩溃），模型分析执行结果（错误信息、输出内容）并修改代码以优化；
4. 该优化过程持续迭代，直到模型找到能通过测试用例的解法。

例如，假设要求模型实现一个is_even(n)函数，偶数返回True，奇数返回False。
模型的第一次尝试可能是：

def is_even(n):
    return n % 2  # ❌ 错误：应该是 `== 0`

模型用公开测试用例测试该实现：

输入	预期结果	模型输出	状态
is_even(4)	True	False	❌ 失败
is_even(3)	False	True	❌ 失败

查看结果后，模型意识到4 % 2返回的是0而非True，于是修改函数：

def is_even(n):
    return n % 2 == 0  # ✅ 已修正

现在该函数通过了所有公开测试，调试阶段完成。

阶段2：筛选阶段

当多个解法都通过了公开测试，模型需要选出最优解（如果可行的话）。为此，S*提出了自适应输入合成方法，避免随机选择：

1. 模型对比两份都通过公开测试的解法；
2. 它自问：“我能不能生成一个输入，测出这两个解法的差异？”
3. 构造新的测试输入，运行两个解法；
4. 如果一个解法输出正确而另一个失败，模型选择更优的那个；
5. 如果两个解法表现完全一致，模型随机选一个。

例如，考虑is_perfect_square(n)的两种不同实现：

import math
def is_perfect_square_A(n):
    return math.isqrt(n) ** 2 == n

def is_perfect_square_B(n):
    return math.sqrt(n).is_integer()

两者在简单示例上都通过了给定的测试用例：

n = 25
print(is_perfect_square_A(n))  # ✅ True（正确）
print(is_perfect_square_B(n))  # ✅ True（正确）

但当大语言模型生成边界用例时，我们会发现其中一个失败了，因此这种情况下模型会选择解法A：

n = 10**16 + 1
print(is_perfect_square_A(n))  # ✅ False（正确）
print(is_perfect_square_B(n))  # ❌ True（错误）

13. 草稿链

📄 2月25日，《草稿链：少写多思，提速推理》，https://arxiv.org/abs/2502.18600

研究人员观察到，推理型大语言模型通常会生成冗长的分步解释，而人类通常只依靠捕捉核心信息的简洁草稿。

受此启发，他们提出了草稿链（CoD）提示策略，通过生成极简但信息量大的中间步骤来降低冗余度。因此从某种意义上说，这是一种推理时扩展方法，通过生成更少的token提升推理时扩展的效率。

改编自论文《草稿链：少写多思，提速推理》（https://arxiv.org/abs/2502.18600）中的配图。

从结果来看，草稿链的简洁程度接近标准提示，准确率却和思维链提示相当。正如我之前所说，在我看来，推理模型的优势之一是用户可以阅读推理轨迹来学习，也能更好地评估和信任回答。草稿链一定程度上削弱了这一优势。但在不需要冗长中间步骤的场景中，它会非常实用——既提升了生成速度，又保持了思维链的准确率。

14. 更优质的反馈与编辑模型

📄 3月6日，《专用反馈与编辑模型赋能开放域通用任务的推理时扩展》，https://arxiv.org/abs/2503.04378

许多扩展推理时推理的技术都依赖答案可验证的任务（比如可以校验的数学和编程题），这让它们难以应用于写作、通用问题解决等开放式任务。

为解决答案可验证性带来的局限，研究人员构建了一套系统：一个模型生成初始回答，另一个提供反馈（“反馈模型”），第三个根据反馈优化回答（“编辑模型”）。

他们利用大规模人工标注的回答与反馈数据集，训练了这些专用的“反馈”和“编辑”模型。这些模型能在推理阶段生成更优质的反馈、做出更有效的修改，从而提升回答质量。

<

《Ahead of AI》是一份读者支持的出版物。想要接收新文章并支持我的创作，欢迎成为免费或付费订阅者。

---

结论

推理时计算扩展已成为今年最热门的研究方向之一，它无需修改模型权重，就能提升大语言模型的推理能力。

我在上文总结的技术种类繁多，从“等待”token这种简单的基于token的干预，到测试时偏好优化、关联思维链等复杂的基于搜索与优化的策略。

从宏观层面看，一个反复出现的结论是：与标准方法相比，增加推理时算力能让即便规模较小的模型也获得（推理基准上的）显著提升。

这表明，推理策略有助于缩小体积更小、成本更低的模型与大模型之间的性能差距。

成本警示

需要注意的是，推理时扩展会推高推理成本。因此，是选择搭配大量推理扩展的小模型，还是训练一个大模型、少用甚至不用推理扩展，需要根据模型的使用频率来权衡计算。

举例来说，大量使用推理时扩展的o1模型，实际上成本仍略低于可能未使用推理时扩展、规模更大的GPT-4.5模型。

（看看GPT-4.5搭配o1或o3风格的推理时扩展后表现如何，会是件有意思的事。）

该选哪种技术？

然而，推理时计算扩展并非万能良药。尽管蒙特卡洛树搜索、自回溯、动态深度扩展等方法能大幅提升推理性能，但效果仍取决于任务类型与难度。正如之前某篇论文所示，没有任何一种推理时计算扩展技术能在所有任务上都表现最优。

此外，许多这类方法都是以牺牲响应延迟为代价换取推理能力提升，而响应过慢可能会让部分用户感到困扰。比如我处理简单任务时，通常会从o1切换到GPT-4o，因为它响应速度更快。

未来展望

展望未来，我认为今年会有更多论文围绕“通过推理时计算扩展实现推理”的两大分支展开：

1. 纯粹以打造榜单最优模型为核心的研究；
2. 关注在不同推理任务中平衡成本与性能权衡的研究。

无论哪条路径，推理时计算扩展的优点在于，它可以应用于任何现有大语言模型，针对特定任务提升表现。

按需思考

产业界一个有意思的趋势，我称之为“按需思考”。深度求索R1发布后，各家公司似乎都在争相为自己的产品增加推理能力。

一个值得关注的进展是，大多数大语言模型服务商都开始为用户提供开启或关闭思考功能的选项。其底层机制尚未公开，但很可能是同一个模型，只是调低了推理时计算扩展的程度。

例如，Anthropic的Claude 3.7 Sonnet（https://www.anthropic.com/news/claude-3-7-sonnet）和xAI的Grok 3（https://x.ai/blog/grok-3）现在都支持用户为模型开启“思考”功能；而OpenAI则需要用户在不同模型间切换——比如想用显式推理模型，就要在GPT-4o/4.5与o1/o3-mini之间切换。不过OpenAI首席执行官提到，GPT-4.5可能会是他们最后一款没有显式推理或“思考”模式的模型。开源领域方面，就连IBM也在其Granite 3.2模型（https://www.ibm.com/new/announcements/ibm-granite-3-2-open-source-reasoning-and-vision）中加入了显式的“思考”开关。

总体而言，无论是通过推理时还是训练时计算扩展来增加推理能力，这一趋势都是2025年大语言模型发展的一大进步。

假以时日，我认为推理将不再是可选的特殊功能，而会成为标配——就像如今经过指令微调或RLHF训练的模型，早已取代原始预训练模型成为主流一样。

如前所述，由于推理领域研究非常活跃，本文篇幅已经很长，因此仅聚焦于推理时计算扩展。未来我计划写一篇文章，介绍所有精彩的训练时计算扩展推理方法。

这本杂志是我的个人兴趣项目。如果你愿意支持我这位独立研究者，可以考虑购买我的书（https://amzn.to/4fqvn0D），或者订阅我的杂志（https://magazine.sebastianraschka.com/subscribe）。

《从零构建大语言模型》现已上市：https://amzn.to/4fqvn0D

如果你读过这本书，并且能抽出几分钟时间，我会非常感谢你在亚马逊上留下评价（https://www.amazon.com/Build-Large-Language-Model-Scratch/dp/1633437167）。这对我们作者帮助很大！

你的支持意义重大！非常感谢！