VibeThinker：一个 3B 参数模型，借助新颖的 SFT+GRPO 在推理上击败 Opus 4.5

原文 ↗ Hacker News 讨论 ↗

模型重点与能力

  • 3B 参数模型，由一个小型 coder base 蒸馏而来，面向“封闭世界、可验证推理”（数学、竞赛编程、自包含编码任务）。
  • 多位用户表示它在数学和高难 ODE 上“强得离谱”，在这类问题上有时能与更大的模型持平甚至超越。
  • 在 LiveCodeBench 等基准上 Python 表现很强；论文声称其在受限任务上的推理能力达到前沿水平。
  • 几个人认为它更像一个推理“核心”或子代理，而不是通用聊天模型。

局限与失败模式

  • 没有工具调用或 agentic 训练；作者明确建议不要把它用于函数调用、API 编排，或仓库级编码代理。
  • 在通用知识、多轮对话和开放式任务上较弱（例如 SVG 生成、历史问题、整仓库安全审计）。
  • 据报告，它比其他小模型更不擅长挖掘真实世界的安全漏洞。
  • 结构化输出不稳定；需要受限生成技巧。

探索的用例

  • 作为本地编码助手，处理 Python/C++ 函数、leetcode 风格问题，以及由人类控制结构的 IDE 支持。
  • 作为复杂符号问题的数学助手，有时几乎完全在“thinking” tokens 中运行。
  • 被建议用作：
    • 对更大 agent 输出进行快速验证/把关的模型。
    • 双模型方案中的推理后端（一个模型负责工具/UX，这个模型负责深度推理）。

工具调用、harness 和变通方案

  • 尽管没有原生工具训练，一些用户仍构建了 harness，能够：
    • 将推理隔离在 <think> 块中。
    • 之后通过受限解码强制 JSON 或 tool-call 语法。
    • 用简单的多工具循环将其包装起来，模拟 agentic 行为。

推理 vs 知识 争论

  • 线程中有大量讨论：一个“纯推理”且世界知识极少的模型是否可行、是否有用。
  • 许多人认为，要有效推理，甚至要知道该搜索什么、该用哪些工具，都需要相当程度的事实与概念基础。
  • 也有人认为，这项工作证明：如果通过工具/RAG 将知识外置，一个出人意料地小的核心也能处理高级推理。

小模型与生态影响

  • 大家对在消费级 GPU 甚至未来 ASIC 上本地运行强推理模型感到兴奋。
  • 有人推测未来会出现针对不同语言/技术栈的专用小模型，以及多模型工作流。
  • 怀疑者质疑“击败 Opus 4.5”的说法，认为可能是基准过拟合或真实工作流覆盖有限。