Jeff 是独立开发者 firelex 在 2026 年 9 月 28 日发布的小模型家族，定位刻意做得非常窄：你描述一个情境，用自然语言列出候选选项，Jeff 通过一次前向传播返回每个选项的校准概率。不生成文本，不需要解析，也不用从对话模型里套模板。1.1 版本把 Qwen3.5 与 Gemma 4 微调成 0.8B 和 2B 两个 checkpoint，可选选项上限从 v1.0 的 26 个提到 254 个；README 给出的数据是 RTX PRO 6000 上每次判断约 22 毫秒，Apple M4 Max 走 MLX 约 28 毫秒。整个项目都在本地硬件上完成：一张工作站 GPU 负责训练，两台 DGX Spark 生成合成数据，MacBook 上做测试。
核心功能
- 输出概率而不是散文：一次前向传播给出每个选项的校准分数，下游代码直接对数字分支，不必解析自由文本。
- 零样本选项：分类目不需要出现在训练数据里，调用时描述即可，适合客服队列、意图路由、内容审核标签和语音指令。
- 两档规模对应不同预算：0.8B 几乎随处可跑，2B 用一点延迟换准确率。
- 兼容 Jev 的请求格式：如果你已经按 TypeSafe 的 Jev API 写过代码，同样的请求结构可以直接用，这让它成为一个很自然的本地备选。
- 长选项列表真的可用：1.1 把上限从 26 提到 254，0.8B 在该项目的长列表测试上从 40% 提升到 95%。
- 文档足够诚实：README 明确写着这些模型在基准上接近、偶尔超过 Jev，但推理能力不如 Jev，这在模型卡片里很少见。
适用场景
谁应该使用这个工具？
- 要给流程加路由层的开发者：当 Agent 或流水线需要判断"这属于 40 个意图里的哪一个"，小模型的成本和稳定性都优于调用前沿模型。
- 数据不能出内网的团队：训练和推理都在本地硬件上跑，不向托管 API 发送任何内容。
- 需要大批量分类的场景：每次判断几十毫秒，经济性和按 token 计费的 API 完全不是一回事。
解决的问题
- 用前沿模型做小判断太浪费：在 12 个客服分类之间选一个，不需要推理模型，也不需要它的账单。
- 输出解析不可靠：直接返回概率，去掉了从生成文本里抠标签这个脆弱步骤。
- 数据合规：本地训练与推理让敏感分类数据留在你自己的机器上。
定价方案
Jeff 以 MIT 协议免费开源，权重发布在 Hugging Face，v1.0 以 revision 形式保留。你的成本是硬件。README 说明在单张 RTX PRO 6000 上 0.8B 训练约 2 小时、2B 约 3.5 小时，也就是说用自己的样本做一次短微调，时间单位是"一个下午"，而不是"一个季度"。
优势对比
相比竞品：
- 边缘速度：毫秒到几十毫秒的判断可以放进请求链路里，而多数托管分类器做不到这一点。
- 可复现的来源：全部训练数据都是合成的，由开放模型生成，闭源模型只用来抽查样本质量。
- 微调是被写进文档的退路：README 提到一次语音导航微调在半小时内把留出集准确率从 31.7% 提到 95.8%。
独特卖点：
- 与 Jev 相同的请求格式，迁移基本只是改配置。
- 254 个选项的上限让它从玩具变成可用的路由器。
- 校准是产品本身，而不是事后补的。
用户评价
项目在 9 月下旬登上 Hacker News，反应和所有小模型发布一样分成两派：想要廉价路由层的人立刻感兴趣，默认"0.8B 一定是玩具"的人立刻质疑。基准数字来自作者自测，README 里那句关于推理能力的坦诚说明在这里作用很大：它把预期定在"快速、校准良好的判断"，而不是"替代你的模型"。请把这些准确率当作作者的数据，并在自己的数据集上重新测过再依赖。
快速开始
入门指南
- 先选规模：从 0.8B 起步，在自己的硬件上确认延迟。
- 用自然语言写选项：调用时描述分类即可，不需要准备标签文件。
- 按 Jev 的方式调用：按文档中的请求格式发送情境和选项列表。
- 先测再信：跑自己的留出集，比较校准而不只是 top-1 准确率。
- 差一点就微调：如果准确率接近够用，用真实样本做一次短微调就是文档给出的下一步。
集成
- 本地推理栈：Apple 芯片上的 MLX、RTX 硬件上的 CUDA。
- 已有的 Jev 客户端代码，因为请求格式兼容。
- 需要在前沿模型之前插入快速分类步骤的 Agent 路由和流水线。
- Hugging Face 上的权重，包括固定版本的 v1.0 revision。
常见问题
Jeff 能替代 Jev 吗？
不能。README 把它定位为小得多的模型，在分类基准上接近 Jev，但推理能力不如 Jev，并建议在零样本准确率不够时做微调。
最多可以在多少选项中选择？
1.1 版本支持最多 254 个选项，v1.0 为 26 个。
有多快？
项目给出的是 RTX PRO 6000 上每次判断约 22 毫秒，Apple M4 Max 走 MLX 约 28 毫秒。围绕这些数字做设计前，请先在自己的硬件上实测。
可以用自己的数据微调吗？
可以，这也是文档给出的标准路径，README 描述了所需硬件和训练时长。
会把数据发出去吗？
训练和推理都在本地运行，整个流程不依赖任何托管 API。
替代方案
如果 Jeff 不适合，可以考虑：
- Jev：想要原始 API 和更强推理能力时，TypeSafe 的托管 System One 模型。
- LangGraph：当你缺的是围绕多次决策调用的编排，而不是分类器本身时更合适。
- MiroFish：另一种本地优先思路，面向多智能体模拟而非分类。
- Buzz：当你缺的是 Agent 工作区而不是决策模型时。
使用技巧
- 做校准而不只做排序：能设阈值的概率比一个标签更有用，前提是你检查过校准。
- 保持选项措辞稳定：零样本意味着选项措辞就是接口的一部分，请像对待代码一样给它做版本管理。
- 先试小 checkpoint：从下限开始，延迟预算更容易推算。
- 用真实样本微调：合成数据负责起步，生产样本负责最后那 60 个点。
总结
Jeff 是一个边界清晰的小工具：只做一件事，返回数字而不是段落，跑在你已有的硬件上。如果你的瓶颈是放在大模型之前的那一步路由或分类判断，0.8B 便宜到本周就能试一试，而 README 里那条微调路径，才是把它从聪明演示变成可上线组件的关键。
评论
还没有评论。成为第一个评论的人！
