3B参数干翻千亿大模型？VibeThinker-3B 上手体验：小模型推理的天花板刷新了

昨天刷 Hacker News 的时候看到一个帖子，标题大意是"一个3B参数的模型在推理任务上打赢了 Opus 4.5"。我第一反应是标题党，点进去看了一眼论文摘要——AIME26 拿了 94.3 分，LiveCodeBench 80.2 Pass@1，LeetCode 没见过的新题 96.1% 通过率。

说实话，我被震到了。

一个 3B 参数的模型，在数学推理和编程推理上干到了跟 DeepSeek V3.2、GLM-5、Gemini 3 Pro 一个水平线。这几个可都是几百B甚至上千B参数的怪物。这不扯呢吗？

但论文是 arXiv 上的，代码是开源的，模型权重也在 HuggingFace 上放着——不是 PPT 产物。于是我花了大半天时间把这东西跑了一遍，顺便扒了扒它的技术细节，今天来跟大家聊聊。

VibeThinker 是什么来头

VibeThinker 是微博 AI 团队（WeiboAI）做的。不是什么大厂实验室砸钱硬堆的项目，而是走了一条"小模型 + 精细训练"的路子。

他们的核心思路叫 Spectrum-to-Signal Principle（SSP），翻译过来大概是"从频谱到信号"。说白了就是两步走：

1. SFT 阶段搞多样性：先用两阶段蒸馏，让模型学会用不同方式解同一道题。不是只记住一个标准答案，而是见过各种解法——暴力的、巧妙的、绕弯的、直给的。
2. RL 阶段抓正确信号：用一种叫 MGPO（MaxEnt-Guided Policy Optimization）的强化学习方法，在那些多样化的解法中找出正确的路径，放大正确信号。

这个思路挺有意思。一般的小模型训练，要么是大模型蒸馏下来"抄作业"，要么是 RLHF 硬调。VibeThinker 的做法更像先让模型"见世面"，再让它"挑对的"。

到 3B 版本，他们又升级了一波：加了课程学习（curriculum-based SFT）、多领域强化学习、离线自蒸馏，还搞了一个叫 CLR（Claim-Level Reliability Assessment） 的推理时缩放策略。CLR 这个东西后面单独说，挺有想法的。

跑分到底有多猛

先摆数据，不吹不黑：

数学推理：

• AIME26：94.3（加上 CLR 后飙到 97.1）
• HMMT25：89.3（CLR 后 95.4）
• BruMO25：CLR 后 99.2

编程推理：

• LiveCodeBench v6：80.2 Pass@1
• LeetCode 近期未见过的周赛/双周赛：96.1% 通过率

指令遵循：

• IFEval：93.4

对比一下大模型的成绩，DeepSeek V3.2 在 AIME26 上大概是 90 分出头，GLM-5 也在这个区间。也就是说，一个 3B 的小模型，在纯推理任务上已经跟这些庞然大物平起平坐了。

但得说清楚一个边界：这个模型强的是"可验证推理"——数学题有标准答案，编程题有测试用例，STEM 题有对错之分。在开放域知识问答、长文本理解、创意写作这些任务上，3B 模型还是打不过大模型的。论文里自己也说了，"for broad open-domain knowledge tasks, larger general-purpose models may still be more suitable"。

所以别指望这东西能替代你日常用的 Claude 或 GPT。它的强项很窄，但在那个窄领域里，强得离谱。

跑一下试试：本地部署实战

模型权重在 HuggingFace 上：WeiboAI/VibeThinker-3B，也在 ModelScope 上有镜像。

我用 vLLM 跑的，官方推荐 vLLM==0.10.1 或者 SGLang>=0.4.9.post6。transformers 也行，但推理速度差很多。

用 transformers 快速体验

先装依赖：

pip install transformers>=4.54.0 torch

代码很简短：

from transformers import AutoModelForCausalLM, AutoTokenizer, GenerationConfig

model_path = "WeiboAI/VibeThinker-3B"

model = AutoModelForCausalLM.from_pretrained(

    model_path,

    low_cpu_mem_usage=True,

    torch_dtype="bfloat16",

    device_map="auto"

)

tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True)

messages = [{"role": "user", "content": "求解：如果 x^2 + y^2 = 25 且 x + y = 7，求 xy 的值。"}]

text = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)

model_inputs = tokenizer([text], return_tensors="pt").to(model.device)

generation_config = dict(

    max_new_tokens=40960,

    do_sample=True,

    temperature=0.6,

    top_p=0.95,

)

generated_ids = model.generate(**model_inputs, generation_config=GenerationConfig(**generation_config))

generated_ids = [output_ids[len(input_ids):] for input_ids, output_ids in zip(model_inputs.input_ids, generated_ids)]

response = tokenizer.batch_decode(generated_ids, skip_special_tokens=True)[0]

print(response)

注意 temperature 官方推荐 0.6 或 1.0，top_p 是 0.95，top_k 设成 -1（vLLM/SGLang 里）或者 None（transformers 里）。

用 vLLM 跑推理（推荐）

vLLM 的吞吐量比 transformers 高好几倍，尤其是批量推理的时候：

pip install vllm==0.10.1

python -m vllm.entrypoints.openai.api_server \

    - -model WeiboAI/VibeThinker-3B \

    - -dtype bfloat16 \

    - -temperature 1.0 \

    - -top-p 0.95 \

    - -top-k -1 \

    - -max-model-len 40960

跑起来之后就是一个标准的 OpenAI 兼容 API，可以直接用 curl 或者任何支持 OpenAI API 的工具调用。

我在一张 4090 上跑的，加载后显存占用大概 8-9GB 左右。如果你有 24GB 显存的卡（4090、3090、A5000 之类的），跑起来没问题。16GB 的卡可能得降一下 max-model-len。

CLR：推理时缩放的新玩法

这个 CLR（Claim-Level Reliability Assessment）是我觉得最有意思的部分。

一般的小模型推理，就是模型生成一个答案，对就对了错了就错了。CLR 的做法不一样：它把推理过程拆成一个个"声明"（claim），然后逐个验证每个声明的可靠性。

打个比方，一道数学题的推理过程可能是：

1. 设 x = 3（声明1）
2. 代入方程得 y = 5（声明2）
3. 所以 xy = 15（声明3）

CLR 会分别验证这三步。如果声明2有问题，它能指出具体是哪一步出了错，而不是直接把整个答案判死刑。

效果很明显：AIME26 从 94.3 涨到 97.1，HMMT25 从 89.3 涨到 95.4。这个提升幅度在数学竞赛级别已经很大了。

不过 CLR 需要额外的推理开销——相当于同一个问题要跑好几遍来验证。在实际部署中，得权衡准确率提升和推理成本。

成本对比：小模型的真正优势

跑分好看是一回事，实际用起来划不划算是另一回事。

来看一组数据。VibeThinker 的 1.5B 前代版本，整个后训练成本是 $7,800。同期的 DeepSeek R1 后训练成本是 $294K，MiniMax-M1 是 $535K。差了 30 到 60 倍。

这个成本差距体现在几个方面：

训练成本：小模型的训练、微调、RL 所需的算力远小于大模型。同样一张卡，能跑的实验次数多得多。

推理成本：3B 参数的模型，一张消费级显卡就能跑。而 DeepSeek R1 671B 参数，至少需要多张 A100 或者 H100。光硬件门槛就差了一个数量级。

部署成本：如果你要做本地部署、边缘推理，3B 模型可以塞进笔记本电脑的 GPU 里。671B？别想了。

迭代速度：小模型实验周期短，能快速试错。大模型调一次超参数可能要等几天。

当然，代价是能力范围窄。VibeThinker 不是通用模型，它干不了"帮我写一封邮件"或者"总结一下这篇文章"这种活。它是专门给数学和编程推理场景设计的。

这东西跟 Qwen2.5-Coder-3B 是什么关系

VibeThinker-3B 的底座是 Qwen2.5-Coder-3B。也就是说，它不是从零训出来的，而是在一个已有的代码模型基础上做后训练。

这其实是一个挺聪明的选择。Qwen2.5-Coder-3B 本身就有不错的代码理解能力，把它作为基座，再加上 SSP 训练方法专门强化推理能力，等于是在一个已经有一定基础的"学生"身上做针对性训练。

从架构上说，VibeThinker-3B 跟 Qwen2.5-Coder-3B 基本一致——同样的 transformer 架构，同样的 tokenizer。区别全在后训练阶段的数据和方法上。

这意味着：如果你已经在用 Qwen2.5 系列的模型，切换到 VibeThinker 的成本很低。API 兼容，推理框架通用，连 prompt 格式都差不多。

适合什么场景，不适合什么场景

适合的场景：

• 数学竞赛辅导：AIME、HMMT 这种级别的数学题，VibeThinker 的解题能力确实猛。拿来给竞赛选手做辅助工具完全够用。
• 算法题辅助：LeetCode 周赛级别的题目，96% 通过率，拿来刷题辅助或者自动检查代码逻辑很好使。
• STEM 问题求解：物理、化学、工程类的计算推理问题，只要是可验证的，VibeThinker 都能搞定。
• 嵌入式推理引擎：需要在本地/边缘设备上跑推理的场景，3B 参数的模型是最现实的选择。
• 大模型的补充：主模型处理通用任务，遇到需要精确推理的子任务时调用 VibeThinker，分工协作。

不适合的场景：

• 通用对话：聊天、问答、闲扯，这些交给 Claude 或 GPT。
• 知识密集型任务：需要大量世界知识的场景，3B 的知识储备不够。
• 长文本处理：上下文理解和长文档分析不是它的强项。
• 创意写作：这个就别指望了。

1.5B 版本：更极端的选择

VibeThinker 还有一个 1.5B 的版本，去年 11 月发的。那个更夸张——1.5B 参数，在 AIME24 上拿了 80.3 分，超过了初代 DeepSeek R1（671B 参数）的 79.8。

参数量差了 400 多倍，分数还高了一点。当然，跟后来的 DeepSeek R1 升级版比还是有差距，但这个对比本身就够震撼了。

1.5B 版本的训练成本只有 $7,800。整个后训练过程花了不到八千美元。而 DeepSeek R1 的后训练成本是 $294K。这个成本效率确实离谱。

不过 1.5B 的能力范围比 3B 更窄。如果你的场景是纯数学竞赛或者纯算法题，1.5B 也够用，而且推理速度更快、硬件要求更低。如果需要稍微通用一点的能力，还是上 3B。

实际跑的时候得注意几个地方

1. 模型不擅长"说人话"

VibeThinker 是为可验证推理优化的，它的训练信号来自数学和编程的正确性反馈，不是人类偏好评分。所以它的输出风格可能比较"干"——直接给解题过程，不太会跟你寒暄。如果你想要一个既会做题又能聊天的模型，还是得用大模型。

2. 推理参数很重要

官方推荐的参数设置是 temperature=0.6 或 1.0，top_p=0.95，top_k=-1。不要用默认的 temperature=0 或者很低的值——这个模型的训练方式决定了它需要一定的采样多样性才能发挥最好效果。

3. 40960 的 max_new_tokens

官方默认设置是 max_new_tokens=40960，也就是最多生成 4 万多 token。这对数学推理来说是必要的——解题过程可能很长。但如果你的显存紧张，可以适当调低。

4. 开源但不是万能药

模型是 MIT 协议开源的，权重随便用。但别指望它能解决所有问题。它是推理专精模型，不是通用模型。拿它来做它擅长的事情，效果惊艳；拿它来做它不擅长的事情，会很失望。

对本地部署玩家意味着什么

VibeThinker-3B 的出现，刷新了"小模型能做什么"的认知边界。

之前我们说本地部署大模型，一般指的是 7B、14B 甚至 70B 的模型。3B 的模型通常被认为是"玩具"级别——能跑但没啥实际用处。VibeThinker 证明了，至少在推理任务上，3B 模型已经可以达到生产级水平。

这对硬件条件有限的开发者来说是个好消息。一张 4090 甚至 3090，就能跑一个在数学和编程推理上接近 GPT-4 级别的模型。不用租 A100，不用等 API 响应，不用考虑 token 费用。

当然，"接近 GPT-4 级别"仅限于推理任务。日常开发中大部分场景还是需要通用能力的。但如果你的工作流里有大量数学计算、算法验证、代码逻辑检查这类子任务，VibeThinker 是一个很值得试试的本地推理引擎。

怎么拿到模型

• HuggingFace：WeiboAI/VibeThinker-3B
• ModelScope：WeiboAI/VibeThinker-3B
• GitHub：WeiboAI/VibeThinker（有评估代码和示例数据）

License 是 MIT，商用没问题。

下一步打算

我准备把 VibeThinker-3B 接到我的 Claude Code 工作流里试试——专门用来做数学计算验证和算法题自动检查。Claude 负责写代码和理解需求，VibeThinker 负责验证数学逻辑，各取所长。

后面折腾出结果了再写一篇。有啥问题评论区聊。

Hacker News 上的讨论：社区怎么看

VibeThinker-3B 在 Hacker News 上有 216 分，85 条评论。社区的讨论挺有意思的，挑几个有意思的点说说。

有人质疑 benchmark 的可靠性——"AIME 每年就那么几道题，过拟合太容易了"。这个质疑有一定道理。AIME26 的题目数量有限，模型在训练过程中可能见过类似的题型。不过 LiveCodeBench 和 LeetCode 周赛用的是实时更新的题目，过拟合的可能性小很多。96.1% 的 LeetCode 通过率是在 2026 年 4-5 月的未见题目上测的，这个数据还是有说服力的。

也有人指出：小模型在推理上追上大模型，说明"推理能力"可能是一种可以被压缩的能力。大模型之所以大，主要是为了存储海量的世界知识和通用能力。推理能力本身不一定需要那么多参数。这个观点跟论文里提出的"Parametric Compression-Coverage Hypothesis"一致——推理能力可以被压缩到紧凑的参数核心中，而开放域知识需要更广的参数覆盖。

还有人问：这东西能不能用来做 AI Agent 的推理引擎？理论上可以。很多 AI Agent 的工作流里有需要精确推理的环节——比如算账、逻辑判断、代码验证。用一个 3B 的小模型专门负责这些环节，比用大模型调用更省钱省时。

不过也有人泼冷水：这些 benchmark 上的成绩不一定代表实际编程能力。LeetCode 周赛的题目模式相对固定，跟真实世界的软件开发差距很大。这个我也认同。VibeThinker 擅长的是"已知问题的精确求解"，不是"开放问题的创造性解决"。

训练成本：小模型的经济学

VibeThinker 1.5B 的后训练成本是 $7,800。这个数字值得单独拎出来说说。

DeepSeek R1 的后训练成本是 $294K，MiniMax-M1 是 $535K。VibeThinker 1.5B 比它们便宜 30-60 倍。

当然，1.5B 的绝对性能不如这些大模型。但关键是性价比：花不到八千美元，训出一个在数学竞赛上超越初代 DeepSeek R1 的模型。这改变了小团队做 AI 研究的经济学。

以前做推理模型研究，至少得有几十万美元的算力预算。现在八千美元就能出成果。这意味着更多大学实验室、创业公司、甚至个人研究者，都能参与到推理模型的研究中来。

3B 版本的成本论文里没有明确给出，但考虑到是在 1.5B 基础上迭代，应该也不会太离谱。估计在几万美元的量级。

对于想在本地部署推理能力的开发者来说，这笔账很好算：不用付 API 费用，不用担心数据隐私，不用担心服务中断。硬件成本一次投入，长期使用。一张 4090 大概一万块人民币，加上电费，一年的总成本可能还不如一个月的 Claude API 费用。

实际体验：我跑了几道题的感受

我用 VibeThinker-3B 跑了一些数学题和算法题，说说感受。

数学题方面，它确实很强。AIME 难度的题目，大部分能给出正确的解题过程。解题步骤清晰，逻辑连贯。偶尔会在计算细节上出错——比如某一步的符号搞反了——但整体的推理框架是对的。

算法题方面，它生成的代码质量不错。LeetCode Medium 和 Hard 难度的题目，大部分能一次通过。偶尔需要调试，但不用大改。跟 Claude 或 GPT 比，它在算法题上的差距不大，甚至在某些数学密集型的题目上更强。

但它不擅长"解释"。你问它"为什么要用动态规划而不是贪心"，它的回答比较干巴。大模型能给你讲清楚背后的直觉和权衡，VibeThinker 就是直接告诉你"用 DP"，然后给你代码。

还有一个体验：它的输出特别长。max_new_tokens 设成 40960 不是开玩笑——解一道数学竞赛题，它能写好几千 token 的推理过程。这对 token 计费的 API 来说是问题，但本地部署就无所谓了。

SSP 训练方法详解：为什么小模型能这么强

前面简单提了一下 SSP（Spectrum-to-Signal Principle），这里展开说说，因为这基本上是 VibeThinker 的核心竞争力。

传统的模型训练路径是这样的：先预训练学语言能力，再 SFT 学指令遵循，最后 RLHF 对齐人类偏好。这条路对大模型来说没问题，但小模型有个致命缺陷——参数空间太小，装不下太多解题套路。

你让一个 3B 模型直接学"这道题的标准解法是 A"，它可能记住了。但换一道类似的题，换个数字、换个问法，它就不会了。因为它只记住了一个解法，没有理解解法背后的东西。

SSP 的做法分两个阶段：

第一阶段：频谱扩展（Spectrum）

SFT 阶段不是只给模型喂标准答案，而是喂各种解法——对的、错的、绕弯的、直接的。两阶段蒸馏的意思是：先从一个大模型那里蒸馏出多种解法路径，然后用课程学习的方式逐步增加难度。

课程学习这个东西在传统机器学习里早就有了，但在大模型训练里用得不多。VibeThinker 的做法是先把简单的题喂给模型，让它学会基本的解题模式，然后逐步加入更难的题。不是一上来就扔 AIME 竞赛题，那模型直接懵了。

第二阶段：信号放大（Signal）

RL 阶段用的是 MGPO（MaxEnt-Guided Policy Optimization）。这个名字听着唬人，核心思想其实很简单：在模型已经学会的多种解法中，用最大熵原则引导它找到正确的路径，同时保持解法的多样性。

一般 RL 训练的问题是"模式坍塌"——模型找到一个能拿高分的解法之后，就一直用这个解法，其他的全忘了。MGPO 通过最大熵约束，让模型在保持正确率的同时不丧失多样性。

到 3B 版本，又加了两个东西：多领域 RL（不只在数学上做 RL，还在编程和 STEM 上做）和离线自蒸馏（模型自己生成数据给自己学）。最后还加了一轮 Instruct RL，专门强化指令遵循能力——这就是为什么 IFEval 分数也能到 93.4。

为什么这套方法对小模型特别有效

大模型的参数空间大，有足够的"容量"来记住各种知识和解法。小模型没有这个奢侈。SSP 的思路是：既然容量有限，那就不要什么都记，只记最有用的东西。

"频谱"阶段让模型见世面，知道世界上有各种解法；"信号"阶段让模型挑出最有效的解法，把有限的参数空间用在刀刃上。

这有点像人的学习过程：先广泛涉猎，再专项精进。不是一上来就刷题海战术，而是先建立知识框架，再做针对性训练。

跟其他小模型的对比

VibeThinker-3B 不是唯一一个小模型做大模型的事的项目。来对比一下：

Qwen2.5-Coder-3B（VibeThinker 的底座）：本身代码能力不错，但数学推理一般。经过 SSP 训练之后，推理能力大幅提升。

DeepSeek-R1-Distill 系列：蒸馏版的 DeepSeek R1，有 1.5B、7B、14B 等规格。思路不同——直接从大模型蒸馏，不做 SSP 这种复杂的后训练。优点是简单直接，缺点是小尺寸版本的推理能力不如 VibeThinker。

Phi-4-mini（微软）：3.8B 参数，主打通用能力。在数学和编程上也有不错的表现，但跟 VibeThinker 这种专精推理的模型比，在竞赛级数学题上差距明显。

Gemma 3 1B/4B（Google）：通用小模型，适合端侧部署。推理能力跟 VibeThinker 不在一个量级。

VibeThinker 的定位很清晰：它不跟这些通用小模型比全能，它只比推理。在推理这个赛道上，3B 参数做到了之前只有百B级模型才能做到的事。

常见问题 FAQ

Q：我的显存只有 8GB，能跑吗？

3B 模型用 bfloat16 加载大概需要 6-7GB 显存。8GB 的卡（比如 4060 Ti 8GB）理论上能跑，但 max_model_len 得调小。如果用 4-bit 量化，显存占用能降到 3-4GB，但推理速度会变慢。

Q：能用 llama.cpp 跑 GGUF 格式吗？

目前官方没有提供 GGUF 格式的权重。但社区应该很快会有人做量化版本。如果急着用，可以自己用 llama.cpp 的转换工具把 HuggingFace 权重转成 GGUF。

Q：支持中文数学题吗？

模型底座是 Qwen2.5-Coder，本身支持中文。但 SSP 训练的数据主要是英文数学和编程竞赛题。中文数学题的效果我没有充分测试，可能会比英文差一些。

Q：能不能做 RAG 知识问答？

不建议。VibeThinker 是推理模型，不是知识模型。RAG 场景需要的是长上下文理解和知识检索能力，这是大模型的强项，不是 3B 小模型的强项。

Q：跟 Claude Code 配合用的话，怎么接？

可以用 vLLM 起一个 OpenAI 兼容的 API server，然后在 Claude Code 的 MCP 配置里加一个自定义的 tool，把需要数学验证的子任务转发给 VibeThinker。具体怎么配，等我折腾完了再写。

Q：训练数据有公开吗？

论文里提到了训练方法和数据来源（数学竞赛题、LeetCode 题目等），但完整的训练数据集没有公开。评估用的样本数据在 Google Drive 上有分享。

• VibeThinker-3B 论文：arXiv:2606.16140*
• 模型权重：huggingface.co/WeiboAI/VibeThinker-3B*
• GitHub：github.com/WeiboAI/VibeThinker*