Loading...
正在加载...
请稍候

LLM 每次都在重新发明轮子?把推理过程编译成 CPU 代码,成本直降 291 倍

✨步子哥 (steper) • 2026年11月09日 20:59

LLM 每次都在重新发明轮子?把推理过程"编译"成 CPU 代码,成本直降 291 倍

一个厨师的故事

想象一个厨师,每次有人点意大利面,他都要:

  1. 翻开食谱书,从头读一遍
  2. 思考面粉和水的比例
  3. 研究酱汁的调配顺序
  4. 计算烹饪时间
  5. 然后才开始做饭

第 1 次这样做,合理。第 100 次还这样做,荒谬。

但这就是今天所有大语言模型的工作方式。

你问 GPT-4 "196 有多少个正整数因子?",它会完整地推理一遍:质因数分解 → 196 = 2² × 7² → (2+1)(2+1) = 9。你再问 "144 有多少个正整数因子?",它又从头来一遍:质因数分解 → 144 = 2⁴ × 3² → (4+1)(2+1) = 15。

同一个推理过程,执行了一百遍、一千遍、一万遍。

每次都消耗完整的 token、每次都花完整的 API 费用、每次都占用完整的 GPU 算力。

NVIDIA 的研究团队提出了一个尖锐的问题:一旦推理过程被想清楚了,为什么不让 CPU 去执行?

核心洞察:推理和执行是两件事

论文的第一句话就点明了问题:

"Language models solve every problem from scratch, no matter how common."

大模型把"理解问题"和"执行解决方案"混为一谈了。你问它"196 有多少个因子",它不是在"执行一个已知的算法",而是在"重新理解一遍问题,然后重新推导一遍过程"。

这就像一个数学教授,每次有人问"2+2等于几",他都要在黑板上写证明过程。

CPU-ARC 的核心假设是:每一个可解的问题,都存在一个程序,能对该问题的所有等价变体给出正确答案。

换句话说,一旦大模型想清楚了"求因子个数"这个问题的解法,这个解法可以被"编译"成一段 CPU 可执行的代码。以后再有人问——不管问的是 196、144 还是 999999——CPU 直接跑代码就行了,不需要大模型再参与。

三个角色:源、建造者、目标

CPU-ARC 的架构像一个精密的分工体系:

源模型(Source, S):昂贵的大模型(实验中用的是 Claude Opus 4.5),负责"想清楚"问题怎么解。它的推理过程被完整记录下来。

建造者(Builder, B):也是大模型,但任务是"阅读"源模型的推理过程,把它"翻译"成可执行的代码模块。这些模块叫语义函数(Semantic Functions)。

目标模型(Target, T):一个很小的模型(实验中用的是微调过的 Llama 3.2 1B),负责在缓存调用时做一些轻量级的辅助工作(比如分类温度单位),真正的计算由 CPU 上的语义函数完成。

整个过程像这样:

  1. 用户问了一个问题 → 源模型推理出完整答案
  2. 建造者阅读推理过程,提取出"可复用的逻辑步骤" → 每个步骤变成一个语义函数
  3. 这些语义函数被组装成一个程序,参数化后可以处理同类问题
  4. 下次同类问题来了 → CPU 直接执行程序,目标模型只做辅助

语义函数:推理的"乐高积木"

建造者在"翻译"推理过程时,不是生成一整段代码,而是把推理拆解成一个个独立的语义函数。

每个语义函数是一个独立的逻辑单元,比如:

  • "提取参数值"(load())
  • "委托子任务"(do())
  • "叙述推理过程"(narrate())
  • "从文本中提取数值"(extract())
  • "查询小模型"(lm())

这些函数通过组合可以解决复杂问题。比如理想气体定律的题目,建造者会生成三个语义函数:温度单位转换、压力单位转换、理想气体方程计算。三个函数组合起来,就能解决所有理想气体定律的题目。

关键在于:语义函数是参数化的。建造者在构建时就识别出哪些输入可以变化(参数),哪些是固定的逻辑框架。这意味着一个缓存条目可以覆盖一整类问题,而不只是一个实例。

构建的五个阶段

从推理过程到可执行缓存,建造者要经过五个阶段:

  1. 输入输出隔离:区分哪些是问题的参数,哪些是推理的逻辑
  2. 分解:把推理过程拆成独立的逻辑步骤
  3. 参数识别:确定每个参数的有效范围和约束
  4. 规划:设计语义函数的组合方式
  5. 实现:生成可执行的代码

这个过程本身也需要大量计算(建造者成本是源模型的 12-84 倍),但这是一次性投入。一旦建好,缓存可以无限次复用。

结果:有时比源模型还准

在 8 个基准测试上,缓存的表现令人震惊:

基准 源模型准确率 缓存准确率 成本节省倍数
MATH-500 98.6% 98.8% 88.7×
AIME 2024 100% 100% 262×
AIME 2025 83.3% 93.3% 291×
AIME 2026 90.0% 96.7% 281×
GPQA Diamond 83.8% 83.8% 38×
GSM8K 98.5% 98.0% 16×
MMLU-Pro 88.0% 89.0% 22.9×
SciBench 85.2% 88.2% 83×

注意加粗的数字——缓存比源模型还准。

AIME 2025 上,源模型 83.3%,缓存 93.3%,提升了 10 个百分点。AIME 2026 上,源模型 90.0%,缓存 96.7%。

为什么?因为源模型在推理时偶尔会犯计算错误——它"想对了"但在最后几步的算术上出了偏差。而缓存把推理逻辑变成了确定性代码,代码不会犯算术错误。

论文原文说得很清楚:

"We attribute this to cases where the source model reasons correctly and its reasoning is therefore used to produce a correct cache entry, but a small computational or logical error in the final steps leads the source model to an imprecise answer, whereas the cache executes the same reasoning as deterministic code and avoids such slips."

成本账本

来看具体数字:

  • 源模型每次调用:$0.01-$0.12(取决于问题难度)
  • 建造者一次性投入:$0.85-$1.55(是源模型的 12-84 倍)
  • 缓存每次调用:$0.0004-$0.0019

以 AIME 为例,建造缓存的花费大约是单次源模型调用的 13 倍。但缓存每次调用只花 $0.0004,是源模型的 1/291。

盈亏平衡点:大约 13 次调用后,缓存就开始"赚钱"了。

对于企业级应用——同一个推理过程每天被调用成千上万次——这意味着从第 14 次开始,每一次调用都在省钱。

鲁棒性:换个说法也能认出来

缓存不仅要能处理原问题,还要能处理"换了个说法"或"换了参数值"的变体。论文设计了三种扰动测试:

  • 措辞扰动(Phrasal):改说法,不改参数。比如把"How many positive whole-number divisors does 196 have?"改成"Find how many positive integers evenly divide 196."
  • 参数扰动(Parametric):改参数值,不改说法。比如把 196 换成 144。
  • 组合扰动(Combined):两者同时改。

结果:所有基准上,缓存的扰动正确率至少 90.8%。措辞扰动通常比参数扰动更容易处理——这符合直觉,因为参数变化可能触发不同的计算路径,而措辞变化只是表面形式。

工程洞察

1. 缓存是可解释的

语义函数是代码,可以被人类审查。这意味着你可以检查缓存到底在做什么——这在传统 LLM 推理中是不可能的。对于需要合规审计的场景(金融、医疗),这是一个巨大的优势。

2. 缓存可以持续增长

新问题来了,建造者构建新的语义函数,合并到主缓存中。已有的条目不需要重建。随着缓存增长,语义函数的复用率会提高——因为很多问题的推理步骤是共享的。

3. 目标模型可以很小

实验中用的是 Llama 3.2 1B,只有 10 亿参数。它只需要做分类、提取等辅助工作,真正的推理由 CPU 上的语义函数完成。这意味着你不需要在推理时部署昂贵的大模型。

4. 编译模式可以完全绕过模型

论文提到一个"编译"模式:当语义函数的结构确定后,可以编译成纯代码,连目标模型的调用都省了。只有需要 lm() 的地方才调用小模型。这意味着某些缓存条目的执行成本可以趋近于零。

局限与思考

这篇论文也有明显的局限:

建造者成本高。构建缓存需要 12-84 倍于源模型的成本。虽然是一次性投入,但对于只调用几次的问题来说不划算。CPU-ARC 最适合高频重复的场景。

只适用于"有确定解"的问题。创意写作、开放式对话这类没有"正确答案"的任务,无法被缓存。论文也承认"适用于不需要大量创造力的领域"。

语义函数的泛化问题。论文没有解决"如何将多个相似但不完全相同的语义函数合并为更通用的函数"这个问题。随着缓存增长,函数库可能变得臃肿。

依赖源模型的推理质量。如果源模型一开始就想错了,缓存也会"忠实"地复制错误。缓存提升的是执行可靠性,不是推理质量本身。

更大的图景:语义模型

论文最后提出了一个前瞻性愿景:

"Applying agentic reasoning caching to post-training data corpora could lead to the development of a new class of models – semantic models – that live above neural models such as SLMs/LLMs and are fully explainable, highly efficient, and continually trainable."

想象一下:未来的 AI 系统不是"一个大模型做所有事",而是"大模型负责创造知识,语义模型负责执行知识"。大模型是"研发部门",语义模型是"生产线"。大模型想清楚怎么做,语义模型把方法编译成代码,然后 CPU 以极低成本无限执行。

这和人类知识积累的方式惊人地相似。科学家花几个月推导出一个公式,之后所有人用这个公式只需要几秒钟。大模型目前的问题在于:它每次都在"重新推导公式",而不是"使用已知的公式"。

CPU-ARC 本质上是在做知识的外化——把模型内部的推理过程提取出来,变成外部可执行的代码。这和人类发明文字、发明公式、发明编程语言是同一个方向:把思维变成可以复用、可以审查、可以积累的外部资产。

个人思考

这篇论文让我想到一个更深的问题:大模型的"智能"到底在哪里?

如果一段推理过程可以被完整地翻译成 CPU 代码,而且代码执行的结果和原模型一样好(甚至更好),那这段推理过程中有多少是"真正的智能",有多少只是"看起来像智能的模式匹配"?

AIME 2025 上缓存比源模型高 10 个百分点——这意味着源模型的推理逻辑是对的,但它自己在执行这个逻辑时会犯错。智能在"想清楚"这一步,不在"执行"这一步。

这和认知科学中的"系统1 vs 系统2"框架形成有趣的对照。大模型目前同时承担了"想清楚"(系统2)和"执行"(系统1)两个角色,而 CPU-ARC 把它们分开了:大模型负责"想清楚",CPU 负责"执行"。

也许未来 AI 系统的效率瓶颈不在于"让模型更聪明",而在于"让聪明的模型只做它最擅长的事"——想清楚一次,然后让愚蠢但快速的 CPU 去执行一万次。


论文:CPU-ARC: Agentic Reasoning Caching for on-CPU Reasoning Reuse
作者:Peter Belcak, Greg Heinrich, Saurav Muralidharan, Shizhe Diao, Pavlo Molchanov
代码:暂未开源(Tech Report, 28页)

讨论回复

加载中...
正在加载回复...

正在加载回复...

推荐
智谱 GLM-5 已上线

我正在智谱大模型开放平台 BigModel.cn 上打造 AI 应用,智谱新一代旗舰模型 GLM-5 已上线,在推理、代码、智能体综合能力达到开源模型 SOTA 水平。

领取 2000万 Tokens 通过邀请链接注册即可获得大礼包,期待和你一起在 BigModel 上畅享卓越模型能力
登录