AI Agent 会在许多本不需要生成文字的节点输出冗长文本,消耗大量无意义算力;文章分析了 agent 决策路径中的 token 浪费模式。
AI agents 在生成无人真正需要的文本上浪费了惊人的算力。Agent 在执行过程中所做的决策其实并不需要书面答案,但 agents 仍然会把这些决策发送给生成模型、等待回答(同时消耗大量 tokens)、然后再解析输出。这种开销已经引起关注——OpenAI 的研究人员在最近披露,仅运行 agent 工作负载每天就要花费 $7,000。Kev 是一个基于 Qwen 3.5 构建的开源决策模型新家族,它采用了不同的方式:彻底跳过生成环节。
开发者 Jared Palmer 于周日发布了新一代 Kev,包含 0.8B、4B 和 9B 三种参数规模的模型,均基于 Qwen 3.5。Kev 采用纯 prefill 架构,在单次前向传播中处理状态、问题和候选选项,然后从 pointer head 直接读取决策结果,无需自回归解码循环。
Kev 是一个基于 Qwen 3.5 构建的开源决策模型新家族,它采用了不同的方式:彻底跳过生成环节。
Kev 支持三种决策类型:Noul 用于是非判断、Choice 用于从候选中选择、Score 用于有序级别评分,这与 TypeSafe 的 System One API 设计一致。开发者提供状态和问题,pointer head 返回各候选选项的概率分布。
对于工具路由决策,输出可能长这样:
{"reasoning": "", "candidates": ["fetch", "search", "calculate"], "choice": "search", "scores": [0.23, 0.71, 0.06]}
Kev 仍然可能选错工具,但因为它只对给定的候选进行评分,所以不会引入列表之外的选项。
路由、安全检查、升级和排序可以迁移到决策层,腾出更大的推理模型来处理开放式工作。
Kev 仍然可能选错工具,但因为它只对给定的候选进行评分,所以不会引入列表之外的选项。
多个决策也可以针对同一状态在单次前向传播中完成,block-causal attention mask 将各问题隔离,pointer head 独立为每组候选评分。
Palmer 的文档显示,4B 模型在 M5 的 bf16 环境下处理三个问题耗时 277 毫秒,但由于没有在同一硬件上与 Qwen 生成等效答案的受控对比,该结果无法说明这种方法实际快了多少。
随着 agent 循环变得越来越复杂,在同一上下文中评估多个决策的能力可能会变得更有用,但跳过生成并不会让决策本身变得更好。
根据 Palmer 的模型卡,最大模型 Kev-9B 在项目的 locked out-of-domain 测试中达到了 83.7% 的准确率。这是开发者自己报告的基准,Palmer 也记录了一些局限性。
Kev 返回的概率并不总是能反映开发者应该对结果有多大信心。Palmer 发现,温度校准在未见过的源分布上可能会漂移,这对于使用概率阈值来决定是否执行操作或升级问题的 agents 来说是个问题——因为即使是高概率的选择仍然可能是错的。
微调也会改变从底层模型继承的一些能力。Palmer 的评估显示,模型在通用知识和算术测试上有所下降,小模型尤为明显。这与 Kev 作为通用模型配套的专业角色是一致的,尽管它在动态 agent 环境中的表现也取决于它处理训练中从未见过的工具、选择和标签的能力——而调试 agent 故障通常指向的是基础设施而非模型本身。
这种思路早于 Kev。TypeSafe 在本月早些时候推出了 Jev,作为其 System One 平台的一部分,使用相同的 Noul、Choice 和 Score 原语,Kev 实现了其 /v1/systemone 请求和响应格式,因此针对该 API 构建的应用可以指向本地 Kev 服务器。
最大的区别在于 Palmer 以 Apache 2.0 协议发布了 Kev,包含模型权重、训练代码和评估工具,让开发者可以选择在自己的基础设施上运行和训练它。然而 Jev 的权重和训练数据并未公开,这使得直接性能比较变得困难,因为模型之间的差异无法被隔离到架构、大小或训练上。
对于只做少量有界决策的应用,在已有模型上进行约束解码可能比向技术栈中添加另一个模型更简单。然而,Agent 循环会不断地做决策——在生成大量面向用户的文本之前,经历路由、排序、安全检查、工具选择和升级。这个模式正出现在各种模型架构中——当任务不需要时就去掉不必要的计算。
当这些步骤只需要选择或概率时,Kev 可以直接处理决策,同时将开放式推理和最终响应留给更大的生成模型。
当这些步骤只需要选择或概率时,Kev 可以直接处理决策,同时将开放式推理和最终响应留给更大的生成模型。