原帖：
https://www.reddit.com/r/LocalLLaMA/comments/1woscea/contrastive_language_models/
（抱歉，我觉得它没有得到 CLM 应有的关注）
它是什么：一个用于 Qwen3-8B 的新投影头。
github：
https://github.com/Contrastive-LM/CLM
hf：
https://huggingface.co/Contrastive-LM
在 API 和功能接口层面，CLM 支持 Jev 所做的一切——它并非其子集。
然而，两者在泛化能力、上下文规模和架构方面存在重要的权衡。
- 功能对等（相同原语） CLM 是专门作为
TypeSafe AI 的 Jev
的开权重、可自托管替代方案而设计的。它实现了完全相同的“系统一”决策接口，并支持 Jev 的全部三种核心问题原语：
Choice
：评估一组离散候选，并返回分类概率分布。
Noul
：为某个命题或护栏检查输出经过校准的真/假概率。
Score
：根据有序评分标准或量表对输入进行评分。
为 TypeSafe Jev 客户端编写的代码可以直接指向 clm-serve 端点，实现即插即用的兼容性（from clm import CLMClient, Choice, Noul, Score）。 2. CLM 优于 Jev 之处 延迟与分离式缓存：
Jev 是一个专有云模型，会联合评估状态和问题选项。CLM 将
状态头
与
动作头
分离。如果智能体拥有一组持久化的工具或动作，CLM 会将这些动作嵌入一次并缓存。在交互式浏览器智能体和游戏（T-Rex、Super Mario）等基准测试中，CLM 比 Jev
快 4 到 13 倍
。
开权重与可微调性：
Jev 是封闭 API，不支持用户微调（你只能通过状态和问题指令来提示它）。由于 CLM 的头是极小的开权重（约 75 MB），你可以在自己的智能体轨迹上对它们进行微调。
编码基准验证器：
在智能体轨迹上微调后，CLM 在
Terminal-Bench 2.1（87.6%）
和
DeepSWE（81.6%）
上达到了最先进的验证器性能，而零样本的 Jev 在这些相同基准上表现不佳（在 DeepSWE 上得分约 71%）。 3. Jev 仍占优势之处（CLM-8B 的局限） 尽管 CLM 覆盖了 Jev 的全部功能面，但当前的 CLM-v0.1-8B 版本在少数方面仍落后于 Jev：
零样本广泛知识：
Jev 由更大的专有模型支撑。在零样本开放域任务上，Jev 在边缘案例准确率上仍占优势（例如，Berkeley Function Calling Leaderboard v4：Jev 得分 99.2%，而 CLM-8B 为 95.2%；WikiRacing：Jev 30/30，而 CLM-8B 为 26/30）。
上下文预算：
Jev 开箱即支持最高
64K token 上下文
的请求。CLM-8B 是在
2K 到 8K 上下文
下测试和校准的。虽然其 Qwen3 主干可以接受更长的提示，但超过 8K 的表示尚未针对参考头进行校准。
概率归一化：
CLM 通过点积和 softmax 在该请求中传入的候选上计算概率。其概率本质上是相对于所提供候选集的，而 Jev 的评分则是针对绝对标准在内部校准的。
总结
如果你在问，使用 CLM 而非 Jev 是否会失去 API 功能：
不会，你获得完整的原语集（Choice、Noul、Score），同时带来巨大的延迟收益和零 API 成本。
与 TypeSafe 的托管服务相比，你只是在冷门域外任务上牺牲了一些零样本泛化能力。
阅读更多
讨论精选
QuantumFTL (314↑)：我也厌倦了 Jev 的炒作，但 Jev 的全部意义就在于 零样本广泛知识
。如果你没有这个，你就不是 Jev 的竞争对手，就像“和 ChatGPT 一样聪明，但你不能和它聊天”的 AI 对 OpenAI 来说也不是竞争对手一样。
我已经完全受够了这些帖子，它们说“我在一个山洞里像托尼·斯塔克一样一天就做出了 Jev，除了
零样本广泛知识
那部分”。这不是最严重的违规者，但我不得不怀疑，为什么这么多人都无法对不同问题的不同类型解决方案做出
明显的
区分！
WithoutReason1729 (1↑)：你的帖子越来越受欢迎，我们刚刚在我们的 Discord 上推荐了它！ 来看看吧！
你也因为你的贡献获得了一个特殊的标签。我们感谢你的帖子！
我是一个机器人，这个操作是自动执行的。