不逐字生成了！CLM 用「打分代替生成」重构 Agent 决策，一周屠榜引刷屏

不逐字生成了CLM 用「打分代替生成」重构 Agent 决策一周屠榜引刷屏【免费下载链接】CLM项目地址: https://gitcode.com/gh_mirrors/clm2/CLM过去两年Agent 的每一次决策本质上都是一次写作把当前状态连同一段指令喂给自回归大模型等它一个 token 一个 token 地把动作写出来。写答案意味着要跑完完整的解码循环、KV Cache 越积越长意味着一次工具选择动辄上百毫秒意味着同一个动作下次还要重新想一遍。CLMContrastive Language Models对比语言模型把这个流程整个调转了过来决策不是生成而是打分。状态被编码成一个向量每个候选动作被编码成另一个向量相似度最高的那个就是答案。在仓库自带的 T-Rex 实时对局基准里一次决策的模型侧耗时中位数只有 2.6ms对照模型 Jev 为 131.9ms同样的 60 秒游戏CLM 做了 3342 次决策对手只做了 1119 次。9 月中旬发布后一周内它冲上 GitHub 热榜有源码评测文记录到第 6 位Google 新闻聚合的报道将其归因于斯坦福大学与 NVIDIA社区里源码评测、Playground 实战、System One 部署指南在三天内接连出现。这篇文章从仓库源码出发拆解三件事CLM 到底改了什么、加速从哪来、以及为什么不打字的语言模型第一次进入主流视野。一、CLM 在做什么从写动作到选动作1.1 双编码器 一个点积一次打分完成一次决策CLM 的推理管线是冻结编码器 可训练投影头。编码器是 Qwen3-8Blast-token pooling输出 4096 维 embedding见 src/clm/heads.py 中的HIDDEN 4096它被完全冻结真正可训练的是两个约 2000 万参数的投影头——state_head和action_head各自把 4096 维编码压到 512 维投影空间PROJ_DIM 512再做 L2 归一化。决策的数学形式极简一对(状态, 候选动作)的分数等于exp(logit_scale) * cos(state_head(s), action_head(a))一组候选的分数过 softmax 就是答案分布。这一设计在 src/clm/engine.py 中体现得淋漓尽致——所谓推理就是一个矩阵乘zq self._cached(f{ns}/state, dim, states, tokens, head.project_states) za self._cached(f{ns}/action, dim, cands, tokens, head.project_actions) ... cos za[k:k len(texts)] zq[i] # 每个候选一次内积 answers[qid] answer_from_logits(questions[qid], keys, (scale * cos / temperature).tolist())注意 src/clm/engine.py 返回的usage里写着output_tokens: 0——它真的一个字都不生成输出是一个概率向量。打分的前提是把问题结构化成状态 候选集合。仓库把这一层做成 TypeSafe 兼容的 typed questions 机制noul是非判断、choice从若干选项里选、score按有序量表打分。src/clm/schema.py 的build_pairs负责把每个问题拆成state 文本和候选文本列表if t choice: keys list(crit) texts [to_text(crit[k]) if crit[k] not in (None, ) else k for k in keys]于是客户端可以一次请求同时回答多个问题——src/clm/client.py 的示例里同一个客服工单状态同时问是否紧急Noul、该转哪个部门Choice、客户愤怒程度Score一次system_one调用全部出结果README 记录的实测是 38 个输入 token、58.1ms冷缓存时因选项文本首次嵌入为 106 tokens。1.2 训练配方双向 InfoNCE 与三阶段对齐打分头不是凭空来的它靠对比学习把状态和正确动作拉近、把其他动作推远。训练目标是双向 InfoNCEREADME 中给出的L_CLM对 batch 内的 $B$ 对(state, action)构造 $B \times B$ 相似度矩阵两个方向$s_i \to a_i$ 与 $a_i \to s_i$都做检索式损失。仓库的微调脚本 train/finetune.py 里对应实现是_clm_loss双向交叉熵 组内掩码同一步的重复样本不参与负例。数据配方是三阶段、逐级变难的状态-动作对齐预训练约 6000 万条 Nemotron DQA 问答对问题当状态、答案当动作学到广泛的语义表征中段训练约 3000 万条由 Gemini 2.5 Flash-Lite 合成的难负样本语义相似但错误的答案注入 InfoNCE 损失练出对看起来都对的候选的精细区分后训练约 100 万条 Agent 轨迹ADP 数据集 Endless-Terminals、LiteCoder-Terminal-SFT 的终端轨迹每条轨迹步都是一个状态-动作对。配方里有两个数字很能说明问题只做预训练、一个难负样本都不见时10 万条留出问题上的 top-1 是 52.1%加一段中段训练后升到 69.2%。而如果从一开始就上难负样本提升虽快却会在 62.4% 封顶过拟合——难负样本是预训练之上的精修不是替代品同一预算下两阶段配方净赚约 7 个点。二、为什么偏偏是现在火高频决策的延迟痛点与实测加速2.1 痛点Agent 每走一步都要等一段文章工具调用、GUI 操作、游戏操控是 Agent 里最典型的高频决策场景循环里每一步都阻塞在读状态 → 生成动作 → 执行上。自回归模型的输出长度不可控、解码必须串行一次选择调用哪个工具也要付出一次完整生成的成本。候选动作明明只有几个模型却要为一个 token 序列付全价。仓库用 Chrome 离线小恐龙游戏做了最直观的对照实验同一个物理规划器、同一份 prompt、同一个 TypeSafe wire format 请求examples/t_rex/README.md一边连本地clm-serve一边连 TypeSafe 托管的 Jevjev-1.13.0实时跑 60 秒。原始结果就存在仓库里examples/t_rex/results/clm_realtime.json 与 examples/t_rex/results/jev_realtime.json。指标5 个种子 × 60 秒实时对局CLM-8BJev 1.13.0比值请求延迟 p50客户端侧中位数16.5 ms149.8 ms约 9.1×模型推理 p502.6 ms131.9 ms约 50.7×单种子 encoder 输入 token4,515 ~ 47,528605K ~ 638K最高约 136×60 秒内决策次数均值3,341.81,119.0约 3×存活种子 / 死亡数5 / 05 / 0持平两条曲线都存活且拿到了相同的最高分 697但达成方式完全不同Jev 靠与规划器标签 98.7% 的一致率想清楚再动CLM 则以 65.8% 的一致率、靠 2.6ms 的决策速度和更多在途请求换来了 4519 次答案落地后仍来得及纠偏的机会arrival_saves对手仅 18 次。延迟之外还有一个更惊人的账Jev 单条种子 60 秒烧掉约 61.7 万 encoder tokenCLM 首条种子只花 47,528后续种子因为服务端缓存命中更是低至 4,515。社区 9 月 26 日的研究简报引用的最高 13× 加速在 token 维度上精确成立617,719 ÷ 47,528 ≈ 13.0仓库官方口径则是端到端延迟最高约 9×——两者都对只是度量维度不同。2.2 加速的三个来源把加速拆开来自三个可独立解释的工程决策第一不做解码。输出是向量内积 softmax长度恒定、无自回归依赖一次/v1/systemone请求能同时回答多个 typed questions适合 Agent 循环里一个状态、多路判断的典型模式。第二状态与动作解耦 候选预缓存。这是 CLM 的核心设计状态向量和动作向量互不依赖可以独立缓存、独立复用。Agent 的候选动作集合工具名、GUI 按钮、best-of-N 的候选解通常是固定的动作侧 embedding 只需算一次状态侧即使每步都变也只需要一次新的 embedding。README 的原话是 States and actions are disaggregated, so their embeddings are cached and reused independently。第三服务端显存竞技场VectorArena。src/clm/cache.py 实现了一个vLLM 式的预留缓存clm-serve启动时按预算默认 2% 显存或512MiB等绝对大小一次性划走一块设备内存切成不同宽度的池子之后绝不增长——长跑服务不会漂移进 OOM。命中的请求跳过 encoder 调用、host→device 拷贝和投影头前向LRU 淘汰且缓存键带 head 与 generation热重载换权重后旧向量自动失效。启动日志长这样[clm] vector cache 505.0 MB reserved on cuda (215,764x512d 3,852x4096d)README 在 RTX 4090 上给出了诚实的缓存对照表状态每步都新的场景3 个动作28.6→28.0ms几乎无增益——encoder 该付的还是要付状态会复访的场景20 个房间、重复状态1.7→0.6ms约2.8×加速。此外 src/clm/embedder.py 还有一层 20 万条文本级 LRU 缓存兜底。缓存的适用面被如实标注这也是它和刷榜营销之间最明显的分野。2.3 零样本横评不是只有快快是手段能力持平才是前提。README 的零样本评估覆盖四类任务T-Rex游戏、BFCL v4工具调用、WikiRacing网页导航、Super Mario游戏。结论是 CLM-8B 与 Jev 表现持平速度最高 9× 更快且候选动作越多、或动作跨状态复用越频繁加速越明显WikiRacing 与 T-Rex 正是这两种极端。这直接指向它的适用域候选集合稳定、决策频率高的任务。三、刷屏背后不打字的语言模型第一次进入主流视野3.1 System One把决策从思考里拆出来CLM 的副标题写得很直白A System One Model for Fast and Generalizable Decision-MakingREADME.md。卡尼曼的双系统理论里System One 是快而直觉的判断System Two 是慢而审慎的推理。主流的 LLM Agent 是拿 System Two 的引擎长链自回归推理硬扛 System One 的活每帧、每次工具调用都要做的快决策代价就是延迟与成本。CLM 则把决策这个环节从生成管线里单独拆出来做成一个可缓存、可打分、自带置信度的检索模块——这是它能在工程社区引发共鸣的根本原因。3.2 验证器best-of-N 的裁决者比打游戏更接近产业价值的是它作为**验证器/裁决者verifier**的角色先采样多个候选解DeepSWE 用 Opus 5、Terminal-Bench 用 Fable 5再用 CLM 给每条轨迹打分、选出最好的。仓库的评估脚本 evaluation/bon_eval.py 展示了完整的打分协议逐轨迹步打分、取最后--window步的分数均值作为轨迹分aggregate、再按分数选出 best-of-N。结果是38 个留出 DeepSWE 任务上达到81.6%30 个留出 Terminal-Bench 2.1 任务上达到87.6%双双刷新 SOTA而 Jev 在这类长程任务上作为验证器失败——得分低于 pass1 基线无法胜任。且验证场景下 CLM 仍比 Jev 快4.1–5.7×H100 实测。这个结果的意义在于裁决哪条候选轨迹更好本质上是给有限集合打分——又是一次不生成的决策。当评估范式从让模型写答案变成让模型选答案CLM 的对比学习表征恰好落在痛点上。3.3 工程形态75MB 参考头 两个进程社区文章密集出现三步搭建 Playground部署 System One 决策服务不是偶然这个仓库把部署成本压到了极低编码器与决策层解耦vllm serve Qwen/Qwen3-8B --runner pooling起一个 pooling 服务serve_qwen3_8b.sh显存占用可调clm-serve在另一个进程提供 FastAPIsrc/clm/server.py参考投影头只有75MBdownload_head.sh 一行拉取首次运行自动下载权重与代码同为 Apache-2.0服务还内置一个无构建步骤的 Web Playgroundsrc/clm/static/每个请求同时以 JSON、curl、Python 三种形式展示甚至带一个clm-raw消融模型跳过投影头、直接在原始编码空间做余弦供对照——src/clm/engine.py 里RAW_MODEL就是这么个可在线验证的消融实验checkpoints 支持热重载--model NAMEPATH可同时服务多个头CLM_API_KEY鉴权、--no-ui、--cors等生产细节一应俱全。微调同样轻train/finetune.py 在冻结 encoder 上只训练两个投影头支持 Agent 轨迹--task clm与 typed decisions--task choice在标注分布上做软标签训练两类适配器train/adapters.py。README 还给出复现 SOTA 的完整命令——hf download Contrastive-LM/deepswe-clm-heads-8k拉权重、evaluation/bon_eval.py跑 38 个留出任务。3.4 适用边界它不是LLM 的替代品刷屏最容易带来的误解是CLM 要取代大模型。仓库自己的措辞更准确候选集合稳定、决策频率高的任务工具调用、GUI 操作、best-of-N 裁决、typed decisions收益最大开放式长文本生成从来不是它的主场——它连一个 token 都不吐。正确的读法是CLM 把 LLM 的能力从写拓展到判让选择这个占据 Agent 循环大部分开销的动作第一次不必付出写作的代价。与之配套的还有 README 里披露的规模化规律InfoNCE 损失随训练算力、数据量、投影头尺寸和编码器尺寸呈幂律下降缩放编码器收益最大固定算力下最优头尺寸与训练 token 数近似线性正比$N^* \propto D^{1.02}$约每参数 310 tokens——这意味着打分式决策是一条可以继续按规律喂数据、稳定变强的路线而不是一次性的工程 hack。项目 Roadmap 也已列出下一站更大骨干、多模态与机器人/computer-use 支持。CLM 这一周刷屏背后真正值得记住的东西是它对决策是什么的重新定义在一个候选集合给定的世界里最好的决策方式不是把答案写出来而是把问题编码、把选项编码、让相似度说话。当延迟从 150ms 掉到 2.6ms、输出 token 归零、同一个状态的动作向量可以缓存到永远Agent 的循环频率、成本结构和架构边界都会随之改写。这一次不打字的模型第一次以一个完整、可部署、可微调、可复现的工程形态站到了主流视野里。【免费下载链接】CLM项目地址: https://gitcode.com/gh_mirrors/clm2/CLM创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考