VibeThinker：1.5B 与 3B 小模型如何在可验证推理任务上对标大模型
Tiny Model, Big Logic: Diversity-Driven Optimization Elicits Large-Model Reasoning Ability in VibeThinker-1.5B
秒懂
- 它是什么？
- WeiboAI 的 VibeThinker 用 SSP 后训练方法把推理能力压进 1.5B 和 3B 的稠密模型，README 给出了 AIME、HMMT、LiveCodeBench 的数字和 7800 美元的训练成本，但仓库本身只是模型卡与论文入口，落地前要分清哪些是模型权重、哪些是论文结论。
- 适合谁用？
- 适合采用的人：手里有明确可验证答案的任务（数学竞赛题、算法题、带约束的指令跟随），并且愿意为推理长度付出显存和延迟成本的团队。不适合的人：需要通用对话、开放域写作、多轮工具调用的场景，README 没有给出这方面的任何评测，把它当通用助手会踩空。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 32 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它要解决的是小模型在可验证任务上推理不稳定的问题
README 把 VibeThinker 定位成对“小模型天生缺乏推理能力”这一判断的反例。目标场景写得很窄：数学推理、竞赛编程、STEM 推理，以及带显式约束的指令跟随。这些任务的共同点是答案可以被自动判定对错，也就是 README 反复提到的 verifiable reasoning。
面向的读者也因此明确。如果你在做题库求解、代码评测辅助、需要本地部署且显存有限的推理服务，1.5B 和 3B 这两个体量是有吸引力的。反过来，如果你的任务没有可靠的验证信号，README 没有提供任何证据说明这套方法仍然有效。SSP 和 MGPO 的设计前提就是“正确信号可以被识别出来”，验证环节缺失时，整套后训练逻辑的立足点就不存在了。
Spectrum-to-Signal：先铺开多样性，再放大正确信号
1.5B 的方法论叫 Spectrum-to-Signal Principle（SSP），分两个阶段。SFT 阶段用 Two-Stage Diversity-Exploring Distillation，目的是让模型产出尽量宽的解空间，也就是 README 说的 broad spectrum of solutions。RL 阶段换成 MaxEnt-Guided Policy Optimization（MGPO），在这个已经铺开的分布里放大正确的那部分信号。
这个顺序值得注意。多数后训练流程是先做 SFT 收敛行为、再上 RL 精修，SSP 把多样性放在前面，意味着它接受 SFT 阶段输出质量参差不齐，把筛选的活交给后面的 RL。代价是训练管线更长，对数据合成和质量过滤的要求更高。3B 版本的做法印证了这一点：README 说它系统性地升级了 SSP，在 SFT 里强化数据合成、质量过滤和课程学习，把 MGPO 风格的 RL 扩展到多个可验证领域，并保留完整的长上下文推理轨迹，最后用离线自蒸馏和 Instruct RL 收敛能力。
3B 还引入了 Claim-Level Reliability Assessment（CLR），一种面向答案可验证推理的测试时扩展策略。README 给出的效果是 AIME26 从 94.3 提升到 97.1，HMMT25 从 89.3 提升到 95.4，BruMO25 达到 99.2。也就是说这部分增益不是来自权重，而是来自推理时的额外计算。
仓库本身是模型卡入口，不是推理代码
从仓库结构看，VibeThinker 提供的是 README、figures 目录下的图表，以及指向 Hugging Face 和 ModelScope 的权重链接。README 的 Model Downloads 一节只列出 WeiboAI/VibeThinker-3B 和 WeiboAI/VibeThinker-1.5B 两个模型页，没有给出推理脚本、依赖清单或启动命令。
这一点直接影响上手方式。你拿到的不是一套可以 clone 下来直接跑的服务，而是权重加论文。README 也没有提供任何 pip install 或 python 调用示例，因此具体的加载代码需要参照 Hugging Face 模型页或所用推理框架的文档，本仓库里没有。
唯一在仓库内可查的代码入口是 CLR：2026.08.12 的新闻指向 github.com/WeiboAI/CLR，并附带论文 arxiv.org/abs/2608.11994。如果你打算复现 3B 加 CLR 的那组数字，代码要从这个独立仓库找，而不是 VibeThinker 主仓库。
1.5B 与 3B 不是同一套东西的两个尺寸
两个版本共享 SSP 这个名字，但训练管线和能力范围差别不小。1.5B 基于 1.5B 参数稠密模型，README 强调它用两阶段多样性探索蒸馏加 MGPO 就达到了对标效果。3B 明确基于 Qwen2.5-Coder-3B，后训练管线升级为课程式 SFT、多领域 RL、离线自蒸馏、指令导向 RL 的组合。
基座不同带来一个实际问题：3B 的起点是代码模型，README 也把竞赛编程列为主要场景之一，LiveCodeBench v6 上给出 80.2 Pass@1，以及 2026 年 4 月 25 日到 5 月 31 日期间未见过的 LeetCode 周赛和双周赛 96.1% 的接受率。1.5B 的 README 部分则把重心放在数学基准上，AIME24 80.3、AIME25 74.4、HMMT25 50.4，对比对象是 DeepSeek R1-0120。
如果你的任务以代码为主，3B 的基座选择更自然；如果只是要一个数学题求解器且显存紧张，1.5B 是更直接的选项。README 没有给出两个版本在同一套评测上的横向对照表，跨版本比较需要自己跑。
成本数字和基准数字都是论文结论，不是仓库可复现的承诺
README 里最抓眼的两个数字，一是 1.5B 的后训练成本 7800 美元，对比 DeepSeek R1 的 29.4 万美元和 MiniMax-M1 的 53.5 万美元，README 称这是 30 到 60 倍的削减；二是 1.5B 在三个数学基准上超过参数量 400 倍以上的初版 DeepSeek R1，AIME24 80.3 对 79.8，AIME25 74.4 对 70.0，HMMT25 50.4 对 41.7。
这些数字出自技术报告和 arXiv 论文，README 只是转述。仓库里没有训练脚本、没有数据配方、没有成本核算表，因此 7800 美元这个量级无法从仓库侧验证，它取决于论文里对算力单价的假设。基准数字同理，README 没有给出评测配置、采样参数或重复次数。
一个需要留意的细节是 AIME24 上 80.3 对 79.8 的差距只有 0.5 个百分点。README 把它写成 surpasses，但在这个量级的差距上，评测设置的变化就足以翻转结论。引用这组数字时，最好回到 2511.06221 这篇论文看具体的评测条件。
什么时候它不该出现在你的方案里
最直接的失效场景是任务缺少可验证信号。SSP 的 RL 阶段依赖正确信号可被放大，CLR 更是明确写着 for answer-verifiable reasoning。开放域问答、创意写作、需要主观判断的评审类任务，README 没有给出任何评测，也没有声称适用。
第二个边界是推理长度带来的成本。3B 的训练管线里明确提到 preserves complete long-context reasoning trajectories，CLR 又是在推理时额外增加计算来换准确率。这意味着即便权重只有 3B，实际显存占用和延迟会明显高于同参数量的普通模型。如果你的场景对首 token 延迟敏感，或者需要在高并发下控制单请求成本，这套方法的性价比需要重新算。
第三个边界是通用能力。README 的评测集中在数学、代码和 STEM，没有 MMLU 之类的通用知识评测，也没有多轮对话、工具调用的结果。把它当作通用助手的替代品，缺少依据。
与 DeepSeek R1 这类大模型蒸馏路线的差别
README 反复拿 DeepSeek R1 做对比，两者的路径确实不同。R1 走的是大规模基座加 RL 的路线，参数量在 671B 量级，能力来自规模本身。VibeThinker 反过来，用 1.5B 或 3B 的稠密模型，把投入放在后训练方法上，靠 SSP 的两阶段设计在有限的参数预算里挤出推理能力。
差别体现在部署侧。671B 的模型即便量化后也需要多卡，1.5B 和 3B 可以在单卡甚至消费级显卡上跑，这是 README 强调 100x 到 600x smaller 的实际意义。但代价是能力覆盖面窄：VibeThinker 的评测全部落在可验证任务上，R1 系列在通用任务上的表现有更广泛的公开评测支撑。
另一个参照是 README 提到的 GPT OSS-20B Medium，1.5B 的 README 说它与后者表现相当。如果 20B 级别已经在你的硬件预算内，选择就变成方法路线之争，而不是能不能跑起来的问题。
许可、维护状态与升级时要看的东西
仓库采用 MIT 许可，这是宽松型许可，允许修改和再分发，但需要注意两点：MIT 覆盖的是这个仓库的内容，模型权重的使用条款要单独看 Hugging Face 或 ModelScope 模型页上的说明，两者不一定一致；另外 3B 基于 Qwen2.5-Coder-3B，基座模型自身的许可条款也会传递过来，README 没有在这里展开。以上是许可文本层面的观察，具体合规判断需要你自己或法务确认。
维护节奏上，仓库未归档，最近一次推送是 2026-08-14。README 的新闻区显示 1.5B 在 2025 年 11 月开源，3B 在 2026 年 6 月发布，CLR 的独立论文和代码在 2026 年 8 月放出。没有检索到 release 记录，也就是说没有版本化的权重或代码发布，升级只能跟随 main 分支和模型页的变化。
这意味着升级成本主要不在代码，而在评测。每次权重或 CLR 策略更新，你都需要在自己任务的验证集上重跑一遍，因为 README 给出的数字来自论文的评测配置，不保证迁移到你的数据分布上。1.5B 和 3B 之间切换时，还要重新评估推理长度和显存占用，这两个版本的训练管线差异足以影响部署参数。
编辑结论
适合采用的人：手里有明确可验证答案的任务（数学竞赛题、算法题、带约束的指令跟随），并且愿意为推理长度付出显存和延迟成本的团队。不适合的人：需要通用对话、开放域写作、多轮工具调用的场景，README 没有给出这方面的任何评测，把它当通用助手会踩空。上手前先确认三件事：一是 Hugging Face 或 ModelScope 上 WeiboAI/VibeThinker-1.5B、VibeThinker-3B 的权重是否完整可下载，二是推理框架对长上下文推理轨迹的支持程度，三是 CLR 这套测试时扩展策略是否已经在 WeiboAI/CLR 仓库里给出可运行代码，因为 3B 报告里 AIME26 从 94.3 提到 97.1 的那部分增益完全依赖它。
社区笔记