判断工单该分给谁值得动用几百亿参数吗有人做了个 22 毫秒拍板的 0.8B 模型先看一个很具体的动作。一条客服工单进来「包裹到货时被压坏了客户要求退款。」Agent 在这一步要做两个判断这事该分给哪个团队客户是不是在气头上。常规做法是调大模型。把工单塞进 prompt等它生成一段文本再用正则或 JSON 解析把答案抠出来。麻烦的地方不在模型想得慢而在于它必须「说」出来你才读得到——中间隔着一层生成和一层解析两头都可能出错。今天 Hacker News 上冲到 491 分、184 条评论的项目 firelex/jeff把这一步改成了分类你把情境和候选选项用大白话写出来模型一次前向传播返回每个选项的校准概率不生成文本也就没有解析环节。作者给的数字很直白。0.8B 权重 1.7 GB在 RTX PRO 6000 上每次判断22 毫秒Apple M4 MaxMLX上28 毫秒32 线程 CPU 上 463 毫秒。对照组是它兼容请求格式的 Jev公开的 Doom 跑测里每次调用 114–212 毫秒还包含网络往返HN 讨论。它是分类器不是「小号大模型」这个区分很关键作者自己在 README 里就点破了Jeff 是 Jev 请求格式下的零样本分类模型用 Qwen3.5 的 0.8B / 2B 和 Gemma 4 E2B 微调而来权重在 Hugging Face 上Apache 2.0。零样本的意思是选项可以是你现编的客服队列、用户意图、审核标签、语音指令、游戏走法。这些类别不需要出现在训练数据里你描述出来它就在里面挑。三种问法choice最多 26 个选项里选一个、noul是/否直接返回概率、score你描述的一根刻度返回落点。模型参数量权重16 位RTX PRO 6000M4 MaxMLXCPU32 线程Jeff-Qwen3.5-0.8B0.8B1.7 GB22 ms28 ms463 msJeff-Qwen3.5-2B2B4.2 GB24 ms60 ms708 msJeff-Gemma4-E2B2B 有效存 4.6B9.3 GB29 ms—1.0 sAutoJev-27B27B~54 GB未公布——Jev未披露只有 API公开跑测 114–212 ms含网络训练前后差了 34 个百分点但推理类的题它追不上4,599 道题、五个公开 benchmark加上 JevBench 的公开 hard 层105 题单独计分。数字放在一起看很有意思Benchmark0.8B 未训练Jeff-0.8B2B 未训练Jeff-2BJev公布五项总评45.379.146.583.183.0BBH39.564.046.068.094.3Financial PhraseBank36.096.453.496.377.0JudgeBench56.662.657.464.678.6RAGTruth49.186.135.988.977.3WinoGrande49.268.652.279.090.7JevBench hard36.247.645.753.373.3同样是 0.8B 的底子总评从 45.3 拉到 79.1中间没有蒸馏大模型的能力只有一次全权重微调。看分布更有价值分类和接地类任务Financial PhraseBank、RAGTruth上0.8B 直接压过 Jev而 BBH、JudgeBench、WinoGrande、JevBench 这些吃多步推理的题差着 20 到 27 分。作者自己写得很清楚这个尺寸的模型不该指望它推理。「校准」是怎么落地的概率要能用必须校准否则 0.82 就跟废纸没区别。训练配方其实不长全权重微调、跑一个 epoch、batch 256loss 是在A–Z 选项字母上做交叉熵然后再拟合一个温度参数做校准checkpoint 看开发集选绝不在 benchmark 面板上选。训练集里每个任务族至少有一半样本遵循 benchmark 面板的排版约定——只学格式不学题目。更值得注意的是硬件账0.8B 在一张 RTX PRO 6000 上跑完约2 小时2B 约3.5 小时。所有合成训练数据由一个开源模型Qwen3.8-Flash-Next在两台 DGX Spark 上写出来测试在 MacBook 上做。没有云 GPU训练数据里没有闭源模型的输出闭源模型只用来抽检合成数据质量。训练配方继承自 AutoJevDenis Yarats许可证与数据来源逐条列在 docs/data-sources.md。一个请求同时回答好几个判断这是我最喜欢的一处工程细节。多个独立判断可以合并进同一次前向传播不用串行调用curl-slocalhost:8765/v1/systemone-Hcontent-type: application/json-d{ model: jeff-latest, state: Refund request: the customer says the parcel arrived crushed and wants their money back., questions: { route: {type: choice, instructions: Which team should handle this?, criteria: {1: Refunds and payments, 2: Damaged or lost parcels, 3: Account and login problems}}, angry: {type: noul, instructions: Is the customer angry?} } }返回里每个问题都带逐选项概率、选中的那项和置信度。也就是说「分给哪个组」和「客户情绪」两次判断的延迟约等于原来一次。限制比宣传更值得读这个项目难得之处是把 caveat 写得跟功能一样长几条直接影响能不能上生产最多 26 个选项超了直接拒绝。选项按 A–Z 编码再往后是 AA、AB。训练集里最大的题只有 19 个选项所以发布的模型从没学过两个字母的编码——排在 27 位之后的选项等于永远选不中跟它写什么无关。服务端因此拒绝超过 26 个选项的请求issue #1。长列表要先自己收敛成短名单。措辞的影响大到离谱。给 Frogger 的「目标选项」换成和其余前进选项相同的说法一局过马路次数从 15 次变成 23 次。这不是玄学是分类任务对表述一致性的天然敏感。benchmark 分数不预测实战。未训练的 Gemma 4 E2B 在 benchmark 上打得过未训练的 Qwen但打游戏最差吃豆人 3.2 颗。训练把它的吃豆人修到 53.2Doom 和 Frogger 却没救回来。2B 比 0.8B 更不会做决定。作者承认 2B 更保守训练后 Doom 得分甚至是 −0.9这个现象还挂着「待调查」。只支持英文和文本。中文场景目前要自己微调。零样本游戏测试就是冲着「不像训练数据」去的描述情境和合法走法「你左边一点有只怪物」但从不说哪一步是对的。0.8B 的吃豆人从随机策略的 11.2 颗提到57.0 颗Frogger 跑到10.3 次跟手写规则机器人的 10.25 次打平Doom 拿到 6.55 击杀与规则机器人相同。M4 Max 上每步 29–49 毫秒。社区在吵什么HN 评论区的分歧比项目本身更有信息量。一条高赞观点RamblingCTO说得很准agentic engineering 里有一半就是分类——审查、把关、决定接下来该读什么文件这些都不需要完整 LLM。另一条baobabKoodaa举了自己项目的例子两年里被模型下线逼着做过三四个强制升级每次升到「更强」的模型内部 benchmark 反而变差。也有人泼冷水认为 0.8B 不可能替代通用模型去处理难的分类任务或者干脆说「embedding 加一个 MLP 就够了」dingody还有人质疑那套概率未必真校准jmpeax。至于闭源产品 Jev最实在的批评是数据要发出去benterix。如果你要在多个模型、多个尺寸之间做同一套 prompt 的横评光给每个后端单独搭一套环境就够折腾的likeai520.cc 这类 API 中转能省掉一部分接入和验证的工作。可以带走的三条第一把「判断」和「生成」拆开看。生成贵、慢、还难解析判断往往只需要一次前向传播。一个成熟的 Agent 里大量步骤其实是判断。第二小模型的可用性来自微调不是来自参数量。0.8B 的基础分只有 45.3微调后 79.1语音导航那套 1.1 万条场景样本单张 GPU 半小时把 held-out 准确率从 31.7% 推到 95.8%每次判断约 40 毫秒。这条路对国内团队的意义是数据不出内网、硬件不靠租。第三先量清延迟预算再选模型。22 毫秒和 212 毫秒不是同一个量级的设计——前者可以塞进每一次循环后者只能放在关键路径上。项目地址github.com/firelex/jeff训练脚本 scripts/train_all.sh游戏测试基线 jev-plays-doom。
判断工单该分给谁，值得动用几百亿参数吗？有人做了个 22 毫秒拍板的 0.8B 模型
判断工单该分给谁值得动用几百亿参数吗有人做了个 22 毫秒拍板的 0.8B 模型先看一个很具体的动作。一条客服工单进来「包裹到货时被压坏了客户要求退款。」Agent 在这一步要做两个判断这事该分给哪个团队客户是不是在气头上。常规做法是调大模型。把工单塞进 prompt等它生成一段文本再用正则或 JSON 解析把答案抠出来。麻烦的地方不在模型想得慢而在于它必须「说」出来你才读得到——中间隔着一层生成和一层解析两头都可能出错。今天 Hacker News 上冲到 491 分、184 条评论的项目 firelex/jeff把这一步改成了分类你把情境和候选选项用大白话写出来模型一次前向传播返回每个选项的校准概率不生成文本也就没有解析环节。作者给的数字很直白。0.8B 权重 1.7 GB在 RTX PRO 6000 上每次判断22 毫秒Apple M4 MaxMLX上28 毫秒32 线程 CPU 上 463 毫秒。对照组是它兼容请求格式的 Jev公开的 Doom 跑测里每次调用 114–212 毫秒还包含网络往返HN 讨论。它是分类器不是「小号大模型」这个区分很关键作者自己在 README 里就点破了Jeff 是 Jev 请求格式下的零样本分类模型用 Qwen3.5 的 0.8B / 2B 和 Gemma 4 E2B 微调而来权重在 Hugging Face 上Apache 2.0。零样本的意思是选项可以是你现编的客服队列、用户意图、审核标签、语音指令、游戏走法。这些类别不需要出现在训练数据里你描述出来它就在里面挑。三种问法choice最多 26 个选项里选一个、noul是/否直接返回概率、score你描述的一根刻度返回落点。模型参数量权重16 位RTX PRO 6000M4 MaxMLXCPU32 线程Jeff-Qwen3.5-0.8B0.8B1.7 GB22 ms28 ms463 msJeff-Qwen3.5-2B2B4.2 GB24 ms60 ms708 msJeff-Gemma4-E2B2B 有效存 4.6B9.3 GB29 ms—1.0 sAutoJev-27B27B~54 GB未公布——Jev未披露只有 API公开跑测 114–212 ms含网络训练前后差了 34 个百分点但推理类的题它追不上4,599 道题、五个公开 benchmark加上 JevBench 的公开 hard 层105 题单独计分。数字放在一起看很有意思Benchmark0.8B 未训练Jeff-0.8B2B 未训练Jeff-2BJev公布五项总评45.379.146.583.183.0BBH39.564.046.068.094.3Financial PhraseBank36.096.453.496.377.0JudgeBench56.662.657.464.678.6RAGTruth49.186.135.988.977.3WinoGrande49.268.652.279.090.7JevBench hard36.247.645.753.373.3同样是 0.8B 的底子总评从 45.3 拉到 79.1中间没有蒸馏大模型的能力只有一次全权重微调。看分布更有价值分类和接地类任务Financial PhraseBank、RAGTruth上0.8B 直接压过 Jev而 BBH、JudgeBench、WinoGrande、JevBench 这些吃多步推理的题差着 20 到 27 分。作者自己写得很清楚这个尺寸的模型不该指望它推理。「校准」是怎么落地的概率要能用必须校准否则 0.82 就跟废纸没区别。训练配方其实不长全权重微调、跑一个 epoch、batch 256loss 是在A–Z 选项字母上做交叉熵然后再拟合一个温度参数做校准checkpoint 看开发集选绝不在 benchmark 面板上选。训练集里每个任务族至少有一半样本遵循 benchmark 面板的排版约定——只学格式不学题目。更值得注意的是硬件账0.8B 在一张 RTX PRO 6000 上跑完约2 小时2B 约3.5 小时。所有合成训练数据由一个开源模型Qwen3.8-Flash-Next在两台 DGX Spark 上写出来测试在 MacBook 上做。没有云 GPU训练数据里没有闭源模型的输出闭源模型只用来抽检合成数据质量。训练配方继承自 AutoJevDenis Yarats许可证与数据来源逐条列在 docs/data-sources.md。一个请求同时回答好几个判断这是我最喜欢的一处工程细节。多个独立判断可以合并进同一次前向传播不用串行调用curl-slocalhost:8765/v1/systemone-Hcontent-type: application/json-d{ model: jeff-latest, state: Refund request: the customer says the parcel arrived crushed and wants their money back., questions: { route: {type: choice, instructions: Which team should handle this?, criteria: {1: Refunds and payments, 2: Damaged or lost parcels, 3: Account and login problems}}, angry: {type: noul, instructions: Is the customer angry?} } }返回里每个问题都带逐选项概率、选中的那项和置信度。也就是说「分给哪个组」和「客户情绪」两次判断的延迟约等于原来一次。限制比宣传更值得读这个项目难得之处是把 caveat 写得跟功能一样长几条直接影响能不能上生产最多 26 个选项超了直接拒绝。选项按 A–Z 编码再往后是 AA、AB。训练集里最大的题只有 19 个选项所以发布的模型从没学过两个字母的编码——排在 27 位之后的选项等于永远选不中跟它写什么无关。服务端因此拒绝超过 26 个选项的请求issue #1。长列表要先自己收敛成短名单。措辞的影响大到离谱。给 Frogger 的「目标选项」换成和其余前进选项相同的说法一局过马路次数从 15 次变成 23 次。这不是玄学是分类任务对表述一致性的天然敏感。benchmark 分数不预测实战。未训练的 Gemma 4 E2B 在 benchmark 上打得过未训练的 Qwen但打游戏最差吃豆人 3.2 颗。训练把它的吃豆人修到 53.2Doom 和 Frogger 却没救回来。2B 比 0.8B 更不会做决定。作者承认 2B 更保守训练后 Doom 得分甚至是 −0.9这个现象还挂着「待调查」。只支持英文和文本。中文场景目前要自己微调。零样本游戏测试就是冲着「不像训练数据」去的描述情境和合法走法「你左边一点有只怪物」但从不说哪一步是对的。0.8B 的吃豆人从随机策略的 11.2 颗提到57.0 颗Frogger 跑到10.3 次跟手写规则机器人的 10.25 次打平Doom 拿到 6.55 击杀与规则机器人相同。M4 Max 上每步 29–49 毫秒。社区在吵什么HN 评论区的分歧比项目本身更有信息量。一条高赞观点RamblingCTO说得很准agentic engineering 里有一半就是分类——审查、把关、决定接下来该读什么文件这些都不需要完整 LLM。另一条baobabKoodaa举了自己项目的例子两年里被模型下线逼着做过三四个强制升级每次升到「更强」的模型内部 benchmark 反而变差。也有人泼冷水认为 0.8B 不可能替代通用模型去处理难的分类任务或者干脆说「embedding 加一个 MLP 就够了」dingody还有人质疑那套概率未必真校准jmpeax。至于闭源产品 Jev最实在的批评是数据要发出去benterix。如果你要在多个模型、多个尺寸之间做同一套 prompt 的横评光给每个后端单独搭一套环境就够折腾的likeai520.cc 这类 API 中转能省掉一部分接入和验证的工作。可以带走的三条第一把「判断」和「生成」拆开看。生成贵、慢、还难解析判断往往只需要一次前向传播。一个成熟的 Agent 里大量步骤其实是判断。第二小模型的可用性来自微调不是来自参数量。0.8B 的基础分只有 45.3微调后 79.1语音导航那套 1.1 万条场景样本单张 GPU 半小时把 held-out 准确率从 31.7% 推到 95.8%每次判断约 40 毫秒。这条路对国内团队的意义是数据不出内网、硬件不靠租。第三先量清延迟预算再选模型。22 毫秒和 212 毫秒不是同一个量级的设计——前者可以塞进每一次循环后者只能放在关键路径上。项目地址github.com/firelex/jeff训练脚本 scripts/train_all.sh游戏测试基线 jev-plays-doom。
