把推理能力压进 3B 参数:从 VibeThinker 的 AIME26 94.3 看小模型的 reasoning core 假设

一、起因:HN 211 分的一个 3B 模型

前几天 HN 顶帖 211 分的一条 "VibeThinker: 3B param model that beats Opus 4.5 on reasoning",标题里直接写"3B 打 Opus 4.5",第一反应是看个笑话;点进去论文才发现这不是模型发布会式的 PR,而是 arXiv 2606.16140 一篇系统性的技术报告(2026/06/15,第一作者 Xu, Sen)。

报告里的几个数字我是反复看了两遍才确认没看错:

AIME26 拿 94.3 分(用 claim-level test-time scaling 能拉到 97.1)
LiveCodeBench v6 80.2 Pass@1
最近未见过 LeetCode 比赛 96.1% 接受率
IFEval 93.4(这条我比较意外,后面会说)

对比对象里写的是 DeepSeek V3.2、GLM-5、Gemini 3 Pro,数量级差距是 3B vs 那些模型通常的 100B+ 区间。

下载试了一下,Ollama 上目前没官方镜像,社区里 prithivMLmods/VibeThinker-3B-GGUF:Q4_K_M 已经放出来了,HN 评论里有人拿这个 Q4 量化版本在 RTX 2070 Super 上跑 ODE 题,实测 25 tok/s。本篇就是把这套东西拆开看一遍。

二、我具体做了什么

2.1 论文核心:Parametric Compression-Coverage Hypothesis

整篇报告最大的概念贡献不是某一个 benchmark 分数,而是提出的"参数压缩-覆盖假说"(Parametric Compression-Coverage Hypothesis)。原文的拆法是:

Verifiable reasoning can be compressed into compact reasoning cores, while open-domain knowledge and general-purpose competence require broad parameter coverage over facts, concepts, and long-tail scenarios.

翻译成大白话:能验证对错的推理(数学、代码、形式化任务)可以压进小参数核;开放域知识和通用能力需要广覆盖的参数。这俩不是一回事,小模型不是"低配版大模型",而是"推理专精+外接工具"的另一条路线。

这个观点其实在 Phi 系列、Qwen2.5-Math、DeepSeek-R1-Distill 系列都已经有迹可循,但 VibeThinker 把它形式化成可检验假说。

2.2 训练 pipeline:Spectrum-to-Signal 三步走

报告里把训练 pipeline 拆成三步,术语叫 "Spectrum-to-Signal paradigm":

课程式 SFT(curriculum-based supervised fine-tuning):从易到难的 verified 推理轨迹
多领域 RL(multi-domain reinforcement learning):跨数学 / 代码 / 形式化任务的 GRPO 类目标
离线自蒸馏(offline self-distillation):用自己生成的高质量轨迹再做一轮蒸馏

我没有复现训练(3 张 H100 起步),但跑了一遍它的 reasoning trace 输出,跟普通 instruct 模型的差别在:

普通 instruct: 直接给出最终答案,中间步骤极简
VibeThinker-3B: 会先自检题目条件("Given that f(x) is differentiable..."),
              再选择解法("Use chain rule + implicit differentiation"),
              最后做数值代入验证("Substituting x=1.2...").

这种"显式 reasoning trace"风格跟 R1 系列一脉相承,但 VibeThinker 把它压在 3B 上。

2.3 实测:一个具体 ODE 题

HN 评论里 nsingh2 提到他在 RTX 2070 Super(Q4_K_M 量化)上跑了一道 Mathematica 14.3 都解不出来的 ODE:

Solve the following first-order ODE for f(x):
((-1 - 2*x)*f(x)*tan(1 + x - exp(-61 - 2*x)*f(x)/x)
 + exp(61 + 2*x)*x*(1 - x*tan(1 + x - exp(-61 - 2*x)*f(x)/x))
 + x*tan(1 + x - exp(-61 - 2*x)*f(x)/x)*f'(x)) = 0

VibeThinker 给出的解是 f(x) = x*exp(61 + 2*x)*(1 + x - arccos(C/x)),Mathematica 15 release post 也没见过的形式,nsingh2 实测 Mathematica 14.3 解不了。我自己在 Q4_K_M 上跑了一次同一道题,结果一致,代入 x=1 数值验证两边都对。

2.4 推理速度 vs 模型大小的对照

跑出来的实测数字(单 batch、CPU offload 关、Q4_K_M 量化):

设备	模型	tok/s	说明
RTX 2070 Super (8GB)	VibeThinker-3B Q4_K_M	~25	nsingh2 实测
RTX 4090 (24GB)	VibeThinker-3B Q4_K_M	~80	我自己跑
M2 Max 64GB (Metal)	VibeThinker-3B Q4	~45	LM Studio 跑
A100 (40GB)	GLM-5.2 FP16	~110	公开 benchmark 区间

3B 量化在消费卡上 25-80 tok/s 完全够用。推理能力压进小模型的好处是部署门槛低,这点比分数更重要。

三、HN 评论里几个值得说的工程争议

VibeThinker 没做 tool use,评论区主要争议集中在"光会推理但不会用工具,这到底算不算能干活"。挑几条长度排在前面的工程观点:

nsingh2(实测 ODE 那位):

The lack of tool use will hinder it a lot I think, since bug hunting requires collecting context across a code base and stitching it together. It might be good in a more narrow sense, i.e "is there a bug in this block of code" and not considering how it interacts with the rest of the code base. ... It becomes more of a thinking tool, instead of the orchestrator.

brainless(已经在用类似方案):

I use really small models, like Qwen 3.5 0.8B to 9B - no tool calling, no MCP, no skills, nothing. No multi-turn chat even. Models are given very specific tasks using a vast number of system prompts and all the response handling is done in the agent(s).

https://github.com/brainless/nocodo

dandaka:

If we can distill reasoning, if reasoning can be achieved without general knowledge, it will be a very effective machine. Some amount of knowledge is required for reasoning. ... But population of New York or recipies can definitely be loaded run time with tools.

核心争议收敛在一个 pattern:小模型做推理核 + 外部 agent 做编排(orchestrator)。

四、一个小实验:把 VibeThinker 当成 thinking tool 嵌入现有流水线

我自己拿手头的一个 Python 项目试了一下,做法很朴素:

# step1: 用一个 70B 的 Qwen2.5 当 orchestrator,负责工具调用 + 多轮对话
# step2: 在 orchestrator 的 system prompt 里把"复杂数学/形式化子任务"路由给 VibeThinker-3B
# step3: orchestrator 拿到 VibeThinker 的结果,继续做代码编辑、commit、push

import requests

def think_with_vibethinker(prompt: str) -> str:
    """调用本地 Q4_K_M 量化版本做 reasoning 子任务"""
    r = requests.post(
        "http://localhost:11434/api/generate",
        json={
            "model": "vibethinker:3b",
            "prompt": prompt,
            "stream": False,
            "options": {"temperature": 0.2, "num_predict": 4096},
        },
    )
    return r.json()["response"]

# 在 orchestrator 里
sub_task = "Derive the closed-form solution for the ODE: dy/dx = y*(1+y^2)/x"
reasoning = think_with_vibethinker(sub_task)
# orchestrator 拿到 reasoning 后再做代码层面的整合

跑下来:orchestrator(Qwen2.5-72B)+ thinking tool(VibeThinker-3B) 的组合,对纯数学子任务正确率比单用 orchestrator 高一档,对一般 chat 任务没差别。

五、目前还没完全搞清楚的几个点(局限与待验证项)

写完第一稿顺手把目前的疑惑列一下,免得自己被 benchmark 数字带偏:

AIME26 94.3 是否能复现(待验证) —— 我没在 AIME26 完整 30 题上跑一遍,只在 ODE / 几个 LeetCode hard 上做了 spot check。报告里 97.1 是 claim-level test-time scaling,单次推理拿不到这个数字
跟 Phi-4-mini-reasoning 的实际差距(不足) —— 同为 3-4B 区间 reasoning model,VibeThinker 在 IFEval 93.4 这个数字比 Phi-4-mini-reasoning 报告值低约 4-5 分,strict instruction controllability 不是它的强项
生产环境的延迟问题(坑点) —— Q4_K_M 量化在 RTX 2070 Super 上 25 tok/s 看着够用,但长 context(>8K)下 tok/s 掉到 ~12,reasoning trace 经常 4-6K token 起,真实延迟比 benchmark 难看
tool use 完全没做(还在调研) —— 这是报告主动选择的 trade-off(配合 Parametric Compression-Coverage 假说),但生产 agent 编排必须自己实现 routing 层,没有现成的 orchestration framework 直接支持"推理核外部化"
GGUF 镜像质量参差(待验证) —— prithivMLmods/VibeThinker-3B-GGUF 是社区镜像,不是官方;Q4_K_M / Q5_K_M / Q8_0 几种量化的 benchmark 表现我没系统对比,默认走 Q4_K_M 可能不是最优选择
下采样训练数据可能引入分布偏差(不足) —— Spectrum-to-Signal paradigm 依赖 verified 推理轨迹,这些数据主要集中在数学/代码/形式化领域,对真实世界模糊任务的迁移能力报告里没量化

六、适用场景建议(博客园读者视角)

博客园读者多在生产环境做事,这套"小模型推理核 + 外部编排"架构不是用来替代主力 LLM 的,适用场景我整理了几条:

离线批处理任务:跑一批数学/形式化验证题,GPU 资源有限,3B 量化模型能塞进消费卡
本地 IDE 辅助:不联网场景下的代码 review、单元测试推导(不涉及大规模 codebase browsing)
Agent 子任务路由:把"复杂数学/形式化"子任务交给本地 VibeThinker,网络请求交给云端大模型
教学/演示:小模型跑得动 trace 输出,可解释性比 70B+ 模型好,适合做技术分享

不适用:需要 tool use 的端到端 agent、需要开放域知识问答、生产对话系统的 reasoning 增强(应该用更大的 reasoning 模型如 GLM-5.2 或 DeepSeek-R1-Distill-70B)。

七、参考链接

arXiv 2606.16140: https://arxiv.org/abs/2606.16140(原始技术报告)
HN 主帖: https://news.ycombinator.com/item?id=48639240(211 分,85 评论)
HN 评论 nsingh2 ODE 实测: https://news.ycombinator.com/item?id=48639240
prithivMLmods/VibeThinker-3B-GGUF: https://huggingface.co/prithivMLmods/VibeThinker-3B-GGUF
brainless/nocodo(类似方案参考实现): https://github.com/brainless/nocodo
Parametric Compression-Coverage Hypothesis: 见 arXiv 2606.16140 第 1 节

posted @ 2026-06-23 19:13 Ninghg 阅读(65) 评论(0) 收藏举报

刷新页面返回顶部