필사 모드: 用 500 美元微调的 9B 赢过前沿模型的条件 — 以及这些条件有多窄

• 引言 — 那篇 336 分的文章实际主张了什么
• 把这个实验照原样搬过来
• 赢的不是模型，而是任务的形状
• 可复现条件清单
• 500 美元是账单上最便宜的一项
• 盈亏平衡的算术 — 利用率决定单价
• 直接用 API 才对的情况，以及没有被验证的部分
• 结语 — 窄任务的胜利只支撑窄的结论

引言 — 那篇 336 分的文章实际主张了什么

2026 年 7 月 28 日，发在 Hacker News 上的一篇文章拿到了 336 分。要点是：把一个 9B 的开源模型用约 500 美元的 GPU 时间做强化学习，结果在电商目录审核任务上赢过了前沿模型。原文是 Fermisense 写的案例研究，标题接近「智能所有权的崛起」。

首先必须把这篇文章没有主张的东西讲清楚。它不是在主张 9B 模型比前沿模型更聪明。它主张的是一个为特定任务训练出来的专家，在这位专家自己的任务上赢过了通用模型。漏掉这个区分，结论就会朝相反方向被外推。HN 讨论帖里点破这一点的评论也有好几条排在前面。

而且这个结果从未被复现过。评分器、数据流水线、训练配置，全都在同一个组织内部。下面我会把数字照原样搬过来，但阅读时必须以「没有任何一项经过独立验证」为前提。另外说明一下：我没能直接取到原文页面(访问被拦截)，下面的数值是我在引用原文的二手报道和 HN 讨论帖之间交叉核对过的值。

把这个实验照原样搬过来

表里最扎眼的一行不是分数，而是它下面那行。报告说五套前沿配置在彼此 0.1 分以内趋于平坦。意思是，无论怎么打磨提示词、换成更贵的模型，都撞上同一个天花板。这与其说是模型的极限，不如说是关于任务形状的信息。后面还会再看。

记下一处不一致。二手报道明确写了 200 条 episode 的分层 holdout，而 HN 讨论帖里有人指出，原文里任何地方都没有提到训练、验证、holdout 的划分，因此无法判断是否过拟合。要么其中一方是错的，要么原文更新过，要么报道参考了别的材料。我没能确认是哪一种。

赢的不是模型，而是任务的形状

五套前沿配置在 0.1 分以内停住，这个事实才是这个实验真正的结果。通用模型撞天花板的原因大体是固定的 — 当任务要求的不是智能，而是对隐性规则的顺从的时候。

目录审核正是这样一类任务。哪个商品名算夸大、哪种品牌写法算违规、哪种类目错放算严重、哪种算轻微，这些不是世间的常识，而是那家公司的政策。你没法把政策全部写进提示词，就算写进去，几十条规则彼此冲突的边界情形下该用什么权重，也不是文字能表达的。那个权重藏在标签里。强化学习做的正是把标签搬进权重这件事，提示词工程做不到。

到这里，这个结果真正的条件就显露出来了。微调能赢的地方，不是存在「模型不知道的知识」的地方，而是正确答案的标准只存在于组织内部，而且这个标准以标签的形式大量存在的地方。反过来，想靠微调注入新知识的尝试，已经在多篇论文里被反复测量为失败。这个区分我在RAG · 微调 · 长上下文该用哪一个一文里按论文逐一整理过。

第 250 步、也就是一天之内就越过前沿区间的这个观察，说的也是同一件事。不是模型获得了新能力，而是把它本来就有的能力，朝这个评分器想要的方向对齐，这么多步就够了。

可复现条件清单

那么在什么样的任务上，这个结果会重演呢。只有下面五条全部为真的时候。任何一条不成立，那 500 美元就收不回来。

• 任务窄，且输出格式固定。看一条目录、把规定字段填上，这种活儿行；「把客户咨询答好」不行。
• 可以自动评分。强化学习需要奖励信号，而在每次都得由人来评分的任务上，跑不了 1,000 步。这个实验成立的一半理由，就是评分器是个程序。
• 标签已经大量存在，或者可以合成。这里是从公开数据集合成了 17 万 7 千条。若想用自然产生的数据凑到这个规模，数据成本会比训练成本先涨上去。
• 正确答案的标准在组织内部。如果任务靠世间常识就能解，通用模型早就在天花板附近，微调没有可越过的空间。
• 量大且能持续。后面会算，量小的话这笔算术就不成立。

这里还挂着一个不算条件的陷阱。自己造评分器的组织，再用这个评分器评自己的模型，就没有可以检出奖励作弊的外部标准了。Fermisense 自己也说明，评分器编码的是本公司的目录政策与按领域设定的扣分权重。87.3% 这个数字的含义是「按这个评分器算 87.3%」，而不是「把目录审核做到了 87.3% 的好」。前沿模型也是用同一个评分器测的，所以比较本身是公平的，但那个评分器与实际业务成果的相关程度，是另一个问题。

500 美元是账单上最便宜的一项

HN 讨论帖里被重复得最多的一条意见就是这个。500 美元是真实成本清单里最下面那一行。把排在它上面的列出来：

• 数据构建。合成 17 万 7 千条训练 episode 的流水线，以及验证这条流水线是否贴近真实目录分布的工作。
• 奖励设计。造出评分器本身，再反复去找并堵上它被奖励作弊攻破的路径。强化学习项目里最耗时间的一段，大体就在这里。
• 超参数搜索。有一条评论把成功那一次训练背后隐藏的失败运行成本估到了 5,000 美元以上。这是估计值，不是被报告出来的数字。
• 评估体系。要持续测量上线后质量有没有维持住，就需要另一套评估集和 harness。没有这个，出问题时你不知道原因。
• 应对分布漂移。目录的商品构成、品牌清单、政策会不断变。越是为窄任务特化的模型，越经不起漂移。如果重训周期是季度，那产生的就不是一年 2,000 美元的 GPU 成本，而是一年四次的工程事件。
• 服务。下一节来算。

把这些项目全部加起来，就得到初始投入 T。500 美元占 T 的百分之几，才说明了这个项目真正的性质。

盈亏平衡的算术 — 利用率决定单价

有两个盈亏平衡点要算。第一个是初始投入的回收。

相对前沿的节省额(按最便宜的配置)
  19.00 - 0.50 = 18.50 美元 / 1,000 条  ->  0.0185 美元 / 条

回收初始投入 T 所需的量:
  T =    500 美元(只算 GPU)             ->     27,000 条
  T =  5,500 美元(GPU + 失败的探索)     ->    297,000 条
  T = 30,000 美元(含工程师时间)         ->  1,620,000 条

只数那 500 美元的话，2 万 7 千条就回本；但把现实的初始投入代进去，就变成百万条量级。对目录有几百万件的电商平台来说这是个轻松的数字，对只有几万件商品的服务来说则是永远够不到的数字。同一个实验结果，会因组织规模不同而得出完全相反的结论。

第二个盈亏平衡点更常被忽略。1,000 条 0.50 美元这个单价，来自「GPU 不闲着」这个前提。自托管服务的成本结构不与用量成正比，而与时间成正比。

假设: 1 张推理用 GPU 按每小时 2 美元常态运行(assumption，实际费率需要确认)
  月固定成本 = 2 x 24 x 30 = 1,440 美元

每月处理 X 条时
  自托管服务总成本 = 1,440 + 0.0005 X
  前沿 API         = 0.019 X          (每 1,000 条 19 美元)

  相等的点:  1,440 = 0.0185 X   ->   X = 约 77,800 条 / 月

在每月 7 万 8 千条以下，无论微调做得多好，最便宜的前沿 API 在总成本上获胜。因为闲着的 GPU 会把 token 单价上的优势整个吃掉。每月 1 万条的负载，实际单价约为每 1,000 条 144 美元，和表里最贵的那套前沿配置处在同一个数量级。

跳出这个算式的方法只有两个。把 GPU 与别的任务共用以提高利用率，或者改用无服务器推理把固定成本换成变动成本。选了后者，1,000 条 0.50 美元这个数字就不再成立，得重新算。

直接用 API 才对的情况，以及没有被验证的部分

把上面的条件反过来，就得到决策规则。下面任何一条成立，就别开始微调，用 API。

• 月处理量达不到盈亏平衡量的一半。
• 造不出自动评分器。质量判断只存在于人的眼睛里。
• 任务定义还在动。如果每三个月需求就变一次，那么每次改一行提示词，比每次重训要好。
• 前沿模型已经能做到 90% 以上好。如果剩下的 10% 属于无法用标签表达的那一类，微调也越不过去。
• 团队里没有人做过强化学习的实操与调试。这个项目难的部分不是训练，而是奖励设计与失败诊断。

最后整理一下这个案例里没有被验证的部分。没有独立复现。评分器没有公开，所以无法从外部确认有没有奖励作弊。关于训练与 holdout 划分的表述，各份材料互相不一致。训练数据是从公开数据集合成的，所以它与真实运营目录的分布有多像，无从得知。前沿配置有没有使用各家厂商推荐的 scaffolding、上线时如果出现更好的模型差距会变成什么样，也都没有涉及。而上线六个月之后的质量 — 也就是经历过分布漂移之后的数字 — 压根就不存在。微调项目真正的成绩单，正是那个数字。

结语 — 窄任务的胜利只支撑窄的结论

这个实验展示的东西很明确。如果正确答案的标准在组织内部、可以自动评分、标签大量存在、并且量足够大，那么把一个 9B 模型训练几天，是可以越过前沿的。而这样的任务，在人们尝试微调的任务里，只是非常薄的一层。

如果只记一个数字，我希望是 7 万 8 千条，而不是 500 美元。训练成本是一次性的，服务成本是每个月的，但关于微调的讨论大多只谈前者。而垫在 500 美元下面的数据、奖励、评估、重训这些项目，在成功项目的文章里几乎不出现，在失败的项目里却总是原因。