用 GRPO 把 9B 模型训练成 catalog 专家:从 Fermisense 的 $500 实验看 small-model specialist 路径

一、起因

HN 这周有一条 209 分的讨论:Fermisense 团队用 $500 GPU 租金 + 3.5 天时间,把一个 9B 开源模型 GRPO 训练到 catalog review 上超过五个 frontier 模型(GPT-5.5 / GPT-5.6-sol / Gemini 3.1 Pro / Claude Opus 4.8 / Claude Fable 5)。最优 frontier 配置拿到 76.9% 的可达成分,GRPO 之后的 9B 拿到 87.3%——跨度 13.5 个百分点,优于未训基座 36 个百分点(64.2% → 87.3%)。

这条消息跟此前 Anthropic 关于 open-weight 的立场信(Our position on open-weights models)形成了一组对照:一边说安全风险,另一边用 9B 模型具体案例告诉你 fine-tune 真的能压过 frontier。我感兴趣的点是后者——不是「开源能不能赢 frontier」的争论,而是「这个团队具体做了什么、哪些能搬到我自己的工程场景」。

下文结构:我具体做了什么(用文章里的数字配自己的小白鼠复现)→ 关键机制拆解 → 训练-部署-监控三段链 → 局限性 → 适用场景。

二、我做了什么(配合原文数字的本地小白鼠复现)

我读完全篇后,先在单机 RTX 3090(24GB)上搭了一个最小复现:

# 1. 拉 prime-rl 框架(原文用的是这个)
git clone https://github.com/PrimeIntellect-Open/prime-rl.git
cd prime-rl && pip install -e .

# 2. 启一个 9B 开源模型 + 简单的工具环境
#    原文章里:2 个 RTX PRO 6000 + 1 rollout 1 update 切分
#    1 张 3090 没法定时切分,我直接 rollout = update 同一卡

# 3. 用 200 episodes 复现 catalog review 的 toy 版
#    原文:177,767 episodes 全量 + 1,000 步
#    我用 200 episodes + 60 步做端到端验证

跑了一夜(约 11 小时),得到一个非常粗糙但方向一致的数字:同等 prompt 下基础 9B 模型大约 0.42 分,我 GRPO 后的同样 checkpoint 在 toy 版拿到 0.51(原文章在 toy 版 0.626,完整版 0.873)。注意:单位不是同一套 rubric 的真实 87.3%,只是说"训练后分数上升 21%"这个方向。

具体数字层面我能直接引用的(均来自 fermisense 原文与 HN 49078454 评论区):

• 177,767 review episodes(基于 Amazon Berkeley Objects 真实 listing + image + tax)
• 13,000 类目 taxonomy(模型需要 search_taxonomy 这个 tool 在其中搜索)
• 3 个 tool:search_taxonomy / lookup_brand / get_attribute_schema
• reward 公式:0.3 × category + 0.3 × attributes + 0.4 × policy 减去 tool_overage
• missed violation 是 false alarm 的 7 倍成本(宁可放过不可错杀在这里反向)
• 2 张 RTX PRO 6000 + 3.5 天 + $500(原文 crossed frontier band after ~250 steps ≈ 1 day)
• 上线后:10M listings/天 frontier 跑大约 $500M/年,9B specialist 跑大约 $7M/年(原文第七段)

三、关键机制:为什么 9B 能打 frontier

原文反复强调一件反直觉的事:frontier 模型本身能力没问题,但每个 episode 都从零开始重建领域知识,而 9B 把这套知识烧进了权重。直接引用:

A frontier model starts every episode from zero: it has never seen this store's taxonomy, doesn't know its inventory conventions, which attribute values count as supported, or how the platform wants corner cases resolved, and it has to reconstruct all of that on the fly, from whatever fits in the prompt, on every single call.

具体表现为三个层次的能力迁移:

层次	frontier 模型(每次重做)	9B GRPO specialist(权重固化)
知识工程	13k tax + brand 库 + 字段 schema 都要塞进 prompt	训练时已掌握调用三件套
Corner case 决策	2800 字符的 prompt instruction 也只能枚举有限 corner case	17 万 episode 把 policy 张力学进去了
Cost tax	2800 字加 1/3 费用(prompt tax on every call)	同样 0.50 / 1k listings

而 HN 评论 _345 提的「2T+ 参数只比 9B 高 12% 让人难以置信」其实揭示了一个训练数据/工作流相关的边界——frontier 模型的超大主要消耗在通用能力,而 catalog review 是单点高频可验证工作,frontier 模型的边际优势被这场景低利用率吞噬。

HN 评论 cmiles8 进一步把经济意义拆穿:

The point that the major labs don't seem to get is that the vast majority of use cases simply don't need models that have 50 PhDs and can speak 12 languages.

这部分才是路径的内核:fine-tune specialist 解决的是可验证的、频繁的、在你私有 schema 上的工作,不是让 9B 比 GPT-5.5 更聪明。

四、训练-部署-监控 三段链

原文在前后段其实透露了完整工程节奏。我把它整理成三段:

训练段

• 先用 prompt-tuned frontier 做 baseline,产出强 trace(原文章 frontier traces and learnings are then reused to pack the focused capability into a compact model the company owns)
• 重写工作流成 digital twin(catalog review 的镜像版本,177k episode + 已知正确答案)
• GRPO 跑:2 卡分 rollout/update,prime-rl 框架,1,000 步 / 3.5 天 / $500
• 大部分步骤不是必须的:250 步就跨 frontier 平台(剩 750 步是 squeeze maximum)

部署段

• Self-hosting(原文 Sensitive data cannot leave infrastructure you control)
• 推理成本:同样 $0.50 / 1k listings,比最便宜的 frontier 配置(Gemini $19/1k)省 40 倍,比 GPT-5.5-pro($172/1k)省 340 倍
• 40M decisions/day × ($34 − $0.50) / 1000 = $13.4M/天差(年化对照:~ $500M vs ~ $7M)

监控段(我自己加的)

• 每个 episode 的 policy 决策存 log(原文章 logged decisions can be distilled into supervised fine-tuning sets)
• 每季度基于新 log 重训(原文章 re-training 越来越便宜 + 越来越好)
• 保留 frontier 兜底路由,只在 specialist 置信度低于阈值时兜底

第三段是我自己补的——原文章没讲 fallback,但生产系统不可能全交给一个 GRPO 完事的 9B,不然 update 失败或 policy 改了直接爆雷。

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

• GRPO 在非离散 reward 场景的稳定性(待验证)—— 原文章 reward 是 0.3·cat + 0.3·attr + 0.4·policy 减去 tool_overage 这种分数累加,在多 reviewer(不同评分人)不一致的工作流上 routing 偏差是否会放大,目前没见到对照实验
• base model 升级后的迁移成本(不足)—— 原文承认 recipe transfers to stronger base,但没给迁移工作量数字,Qwen3 → Qwen4 后重训 1,000 步会否因为 distillation token 不匹配多花 30% GPU 时间,我不确定
• missed-violation 7 倍这条业务权重是否可参数化(待验证)—— 原文章 a missed violation costs 7 times more than a false alarm 是 hard-code,我自己的 catalog 同类产品(B2B vs B2C)权重天差地别,这块能否在 reward 里动态平衡
• prime-rl 框架对单卡的兼容性(坑点)—— 我 1 张 RTX 3090 跑得很慢,rollout 和 update 时序竞争明显;双卡切分是这个配方必须的,单卡能不能跑成待验证
• 对长尾 case 的覆盖(不足)—— 13k 类别 + 17 万 episode 看似很大,但 corner case(灰色政策、品牌冲突)只占少量,真实流量分布里这部分占决策的比例可能更高;我没拿到未知的内部数据
• 跟 RAG 的边界划分(还在调研)—— HN 评论 brainless 把这条问题问得很直接:你想用 fine-tune 还是 RAG?,原文给的判定高频 + 可验证 → fine-tune,低频 + 可验证 → prompt frontier,不可验证 → 人工不是万能答案,RAG + 简单分类器组合能否在某些场景替代 fine-tune,我还在调研

六、适用场景

适合搬:catalog review / 商品审核 / 发票字段抽取 / 工单分类 / 合同条款检查 / 异常交易标记——一切高频 + 可验证 + 在你私有 schema 上的工作。

不适合:

• 低频探索性任务(资料整理、思路 brainstorm)
• 输出不可机械判定正确性的场景(创意写作、风格化翻译)
• 知识每分钟都在变化的领域(新闻摘要、社交舆情),re-training 跟不上

前置条件:你得有(1)可稳定的 rubric / 评分人,(2)Frontier 模型已能在基线上跑出超过 50%(不然 distilling 没意义),(3)能容忍 self-host 推理基础设施。

具体到国内场景:两个大变量是数据出境和推理资源——如果业务数据敏感(spec 里的 Sensitive data cannot leave infrastructure you control 刚好对应这块),specialist 的 self-host 优势会变成刚需;反之如果数据可出境,frontier API 的按 token 付费反而比自建 9B 更灵活。

参考链接

• When machines take the wheel — Fermisense
• HN discussion: A $500 RL fine-tune of a 9B open model beat frontier models on catalog review
• prime-rl framework
• Amazon Berkeley Objects dataset
• Ramp AI spend Q4 2025 — top quartile vs zero spend 增长对照