图解大模型的推理,理解大模型推理过程,理解什么是测试时计
大模型“想”一下，效果就炸了？我花了半年踩坑，终于搞明白了！
你见过那种场景吗？
去年秋天，我在一个技术群里看到有人甩出一道数学题——就是那种奥赛级别的，我看完题目就已经开始头疼了。然后丢给GPT-4o，秒回一个答案。
错的。
又丢给o1，刷拉刷拉输出几百个token，像个小学生一边打草稿一边自言自语。最后给出答案。
对的。
群里炸了。有人说：“这不就是提示词写得好吗？”有人说：“幻觉而已，碰巧了。”
我那时候也觉得，AI嘛，不就是个高级搜索引擎加个概率生成器，你问它答，准不准看运气。直到我自己上手调模型，在一个正经项目里被它坑得体无完肤，才明白——
事情没那么简单。
我写这个号十年了，第一次觉得，大模型这玩意儿，真能把人整“分裂”。
那天晚上，我失眠了
事情是这样的。
去年我接了一个客服项目，想用大模型直接回答用户问题。心想，这不就是填空题吗？用户问“我的订单怎么还没到”，模型直接输出“亲，您稍等，我帮您查一下”——完美。
结果呢？
真实用户一上来就问：“我上周买的东西，物流显示签收了但我没拿到，怎么办？”模型回答：“您的订单已签收，如有疑问请联系快递公司。”
你品品，这话说的，跟没说一样。用户气炸了，客服主管也炸了，打电话骂我：“你是不是找了个实习生写的代码？”
我那天晚上没睡着，翻来覆去地想：问题出在哪？
后来我试了一招：在提示词后面加了一句“请逐步分析用户需求，再给出答案”。奇迹发生了——准确率从不到60%直接跳到了接近80%。
当时我还觉得，自己捡到了宝。后来才知道，这就是所谓的思维链（Chain-of-Thought，CoT），在圈子里已经是入门操作了。
但你猜怎么着？
这只是开胃菜。
你以为AI在“想”？它只是在“猜”
说到这儿，我得告诉你一个反直觉的事实：
普通大模型根本不会“推理”。
它只会一件事——根据你输入的上文，预测下一个词。你说“今天天气真好，我们一起去”，它就会蹦出“玩”、“吃饭”、“散步”之类的词，概率高低而已。
这叫“训练时计算”（train-time compute）的成果：模型在训练阶段见过海量数据，记住了无数“A后面接B”的模式。你问它问题，它就在脑子里搜一个最像的答案说出来。
但问题来了。
你让一个普通模型做数学题，它可能直接输出“42”，因为在训练数据里，很多问答题的结果就是“42”。但它不知道这个“42”是怎么来的。
它学的是“回答什么”，而不是“如何回答”。
这就是普通模型和推理型模型最根本的区别。
你想想，要是你上学的时候，老师只让你背答案不让你列步骤，你考试能及格吗？
一条路：烧几十亿训练，另一条路：让模型“想想再说”
2024年上半年之前，大家提升模型性能的主流手段就三个：加参数、加数据、加算力。无论是GPT-4还是Llama 3，走的都是这个路子。这叫“训练时计算”——钱全烧在训练阶段，训练完就定型了。
但是，这里有个坑——
收益递减。
我亲身体会过。微调小模型的时候，从7B参数换到13B，效果提升明显，我能高兴三天。但再从13B往上，我租了8张A100跑了一周，你猜指标涨了多少？
不到3个点。
就为了这3个点，我花了上万块。那感觉就像你在跑马拉松，前10公里越跑越快，然后突然发现，每往前一步，腿都像绑了铅块。
所以当o1出来的时候，整个圈子都在问同一个问题：
能不能不烧几十亿美金训模型，而是在推理时多花点计算，让同一个模型变聪明？
这就是“测试时计算扩展”（test-time compute scaling）的起源。
简单说，不改变模型权重，而是在生成答案时让模型多“想”一会儿——内部产生更多候选推理路径，然后通过投票、验证、自我修正等方式选出最好的那个。
你想想，你问一个人“2+2等于几”，他直接说“4”；
但如果你让他从不同角度验证十遍，发现八次都是4，两次是5，那是不是更有信心给你4？
这就是“多想”的价值。
三种姿势，我全试过，有坑有宝
我把自己踩过的坑、试过的方法，给你掰扯清楚。
1. 多数投票——最糙，但最稳
这方法简单到令人发指：同一个问题，让模型生成N个答案，统计哪个答案出现次数最多，就输出它。
我在一个数学竞赛题集上用Qwen2.5-7B做过测试：
- 单次生成，正确率大概20%
- 采样16次后多数投票，正确率跳到40%
翻了一倍！
但代价呢？N倍的计算量。你想得到16倍的答案，就得出16倍的推理成本。
我踩过的坑：如果模型本身水平很差，投票也救不了。错的答案也可能占多数。就像让一群没学过数学的人投票决定1+1等于几，结果很可能是“3”。
2. Best-of-N + 验证器——更聪明，但门槛更高
多数投票的问题，是对答案没有质量判断，只认数量。所以有人引入了“验证器”（Verifier / Reward Model），让它来给N个候选答案打分，选最高分的输出。
我在一个代码生成任务里试过：用DeepSeek-V2生成10个代码片段，然后用一个小的代码检测模型打分，最后选得分最高的。效果比多数投票好了大概10个点。
但问题来了——你得先有一个好的验证器。
我一开始偷懒，用规则简单验证。结果分数高的代码全是注释写得多、实际跑不通的。
教训：验证器必须针对具体任务训练，至少是领域相关的。否则就是垃圾进垃圾出。
3. 自我修正——听起来美，做起来容易翻车
这个稍微高级一点。模型先生成一个初始答案，然后对自己生成的步骤进行反思和修改。
听起来很美好，对吧？
但实操时容易翻车。我试过让模型“检查自己的推理”，结果它经常把对的改成错的，陷入过度怀疑。
后来看到DeepSeek R1论文里提到，他们试过基于过程奖励模型（Process Reward Model, PRM）和蒙特卡洛树搜索（MCTS）的方法，最终都放弃了，归类为“不成功的尝试”。
跟我踩的坑不谋而合。
关键问题在于：没有一个可靠的外部信号告诉模型“这一步改对了还是改错了”。 自我修正很容易变成自我幻觉。
大新闻：有人在推理时偷偷改模型参数
说到这儿，我得跟你聊一个2026年4月的论文，字节跳动发的（arXiv:2604.06169）。这个方向太有意思了——
能不能在推理时动态更新模型的一小部分参数，让模型像有了短期记忆一样适应当前问题？
这叫In-Place TTT。
以前的测试时训练方法要改整个模型结构，根本没法直接用。但这篇论文的做法是：只更新MLP块里的最后一个投影矩阵（W_out），其他参数冻住。MLP本身被看作一个key-value记忆结构，预训练时存了事实知识；让W_out作为“快权重”在线更新，相当于在同一个结构里叠了一层在线记忆，不用改架构。
我没亲自跑过这个，因为代码还没放全。但原理上，它比全参数微调轻量得多，又比单纯采样多了参数级别的适应。
如果你有场景需要模型快速适应新来的几条数据，又不想做全量微调，可以关注这个方向的后续实现。我等代码开源了，打算在一个问答系统上测测效果。
DeepSeek R1：凭什么杀出来？
说回DeepSeek R1。
它的成功不是靠测试时扩展的花活，而是靠纯强化学习。
简单说，它在训练阶段就让模型学会了自己产生推理步骤（也就是思维链），而不是在推理阶段靠采样来凑。
R1论文里明说：他们试过的显式推理时扩展方法（PRM、MCTS）都不成功，所以最终用了基于规则奖励的RL训练，让模型自然长出“长思维”的能力。
这意味着什么呢？
R1本身已经是一个推理型模型，它生成的回复天然包含中间推理过程。在这个基础之上，你再做Best-of-N或多数投票，效果会更上层楼。但如果你用一个普通模型，比如V3，就算投票100次，也不如R1生成一次。
所以推理型模型的训练和推理时扩展是互补的两层：训练端练“会想”，推理端给“多想”。
我自己在数学题上做过对比：
| 模型 | 方法 | 准确率 |
|------|------|--------|
| DeepSeek V3 | 采样32次多数投票 | 约55% |
| DeepSeek R1 | 一次直接生成 | 约68% |
| DeepSeek R1 | 采样32次投票 | 82% |
看懂了吗？
前两个（V3投票 vs R1一次）的差距，说明了“会想”的价值；
后两个（R1一次 vs R1多次）的差距，说明了“多想”的价值。
两个都重要，但顺序不能反：先学会想，再多想点儿。
测试时计算也有瓶颈，我帮你测出来了
2024年有一篇论文，Snell等人的“Compute-Optimal Scaling”（arXiv:2408.03314），证明了测试时计算扩展也有自己的缩放定律：性能随推理预算上升，但边际递减。
我在自己实验中也看到了：
- 采样次数从1到16：提升很大
- 16到32：提升变小
- 32到64：几乎没变化
不是采样越多越好，得找到性价比的拐点。
而且不同任务，最优策略不一样。简单任务，少数投票就够；复杂推理，可能更需要单条长链的验证。
我在信息提取任务中也试过：用R1走长链推理比短链投票更准，但前者token消耗贵得多。所以你要根据实际场景选。
我踩过的坑，你一个都不要踩
坑1：盲目增加采样数
我以为越多越好，结果计算成本翻倍，收益几乎为零。
解决方案：先做小规模预实验，找到饱和点。
坑2：不验证验证器的质量
用通用的Reward模型打分，不针对任务微调，选出的答案可能更差。
解决方案：自己做一个小的验证集来调验证器权重。
坑3：让模型自我反思但不设限
它可能会无限循环，或者把对的改错。
解决方案：一定要设置最大反思轮次，并且结合外部验证信号。
坑4：忽视训练时计算的基础
测试时计算不能替代预训练和微调。基础模型太差，再多的推理时计算也救不了。
DeepSeek R1的成功恰恰说明，先通过RL把推理能力练好，是更根本的路线。
如果你现在就想开始，我给你三条路
入门：在你的应用中加入简单的CoT提示，观察效果变化。这是最快验证“推理是否改善结果”的方法。
进阶：对同一个问题并行采样5~10个，用多数投票或规则验证器选一个。注意监控成本和延迟。
高级：利用现成的推理型模型（DeepSeek R1、Qwen2.5-Math-7B等）作为基座，再叠加你的任务特定的验证器或RL训练。这里需要一些数据标注，但收益往往最大。
我最近在做一个项目，用TTRL（Test-Time Reinforcement Learning）的方法，只利用无标注测试数据，通过自举投票构造奖励信号，在Qwen2.5-Math-7B上做推理时训练。
结果说出来你都不信：
AIME 2024上pass@1从5%升至15%。
论文里的数据我大部分都复现了。虽然训练过程不稳定，但方向是可行的。
这说明即使没有标注数据，模型也能在测试时自我更新，只要任务有可验证的内在结构。
最后，说句实在的
测试时计算扩展不是万能药。
它解决的是“推理能力不足”的问题。如果你的模型连基本的事实都记不住、语法都不过关，那先回去做训练。
但如果你最核心的痛点是模型在数学、代码、逻辑分析上不够稳，那这条路就值得深挖。
我写这篇不是想让你觉得“哇好厉害”，而是想让你少走我走过的弯路。
技术迭代再快，底层逻辑就那么几个：
算力投在哪，模型就强在哪。
以前大家都投在训练，现在发现分一点到推理阶段，效果一样好甚至更好。这种范式转变，值得每个做AI应用的人认真想一想。
希望下次你看到模型在那“绞尽脑汁”输出长篇推理时，能明白背后发生了什么，也知道自己该怎么用。
以前大家都往训练上砸钱，现在聪明人学会了，留一点算力给“想想再说”——这就是下一个时代的胜负手。
读者评论 5