Flide开源：决策模型最高提速9.5倍

Flide 开源，瞄准 Agent 最贵的那段延迟

Flide 近日正式开源，项目方给出的核心卖点很直接：让 Jev 类决策模型的推理速度最高提升 9.5 倍。根据 OmniJev 公布的 GitHub 仓库，Flide 的重点不是训练一个新的通用模型，而是压缩决策模型在实际运行中的推理开销。

Jev 类决策模型是一类面向分类、动作选择、评分和结构化判断的模型，它们不追求逐 token 写出一段完整回答，而是直接在有限候选项中给出选择或概率。典型任务包括判断邮件应该分发到哪个部门、从浏览器页面的候选动作中选出下一步、给安全告警排序，以及判断一个 Agent 轨迹是否值得继续执行。

Flide 是一个面向 Jev 类决策模型的开源推理加速项目，它优化的是模型作出选择的执行路径，而不是把选择重新包装成长文本生成。这个定位很重要，因为决策模型竞争已经从“能不能做出判断”，迅速转向“能不能在几十毫秒内稳定完成判断”。

截至 2026 年 11 月 9 日，Flide 对外最醒目的数字仍是最高 9.5 倍加速。不过，这个数字来自项目方展示的最佳结果，不等于所有模型、硬件、候选数量和输入长度下都能稳定获得 9.5 倍提升。

它不是新的 Jev，而是 Jev 类模型的“加速档”

Flide 最值得关注的地方，是它与 Jev、Clef、Laya 或 CLM 并不完全处于同一层。后几者主要回答“用什么模型做决策”，Flide 更接近回答“怎样把这类模型跑得更快”。

Jev-like 描述的是任务和接口形态，而不是对 Jev 未公开内部架构的复刻。只要一个模型接收状态、问题或候选动作，并直接输出类别、分数或概率，而不是自由生成长文本，它就可能被归入这一类决策模型。

这种模型的效率优势来自对输出空间的主动收缩。传统大语言模型面对“下一步该点击搜索、返回还是填写日期”时，往往先生成分析文本，再输出动作名称；决策模型则直接比较几个候选动作，一次前向计算后给出结果。前者像让员工写一份报告再做选择，后者像让员工直接在表格里勾选。

Flide 进一步追问的是：既然输出只剩几个候选项，推理栈是否还有重复计算、调度开销或不必要的数据搬运可以去掉？这类优化未必改变模型权重，却可能直接改变模型是否适合进入 Agent 的高频热路径。

所谓 Agent 热路径，是智能体在完成任务时反复经过、其延迟会持续累积的关键执行链路。浏览器 Agent 每打开一个页面，都可能经历“读取状态—生成候选动作—模型评分—执行动作”这一循环；如果一个任务需要 20 次决策，单次延迟看似只差 200 毫秒，最终就会多出 4 秒等待。

最高 9.5 倍意味着什么

9.5 倍加速真正有价值的场景，不是每天执行一次的后台分类，而是每个任务连续调用十几次甚至几十次的 Agent。决策频率越高，推理加速对端到端体验的影响越明显。

以一个假设场景计算，如果基线模型单次决策耗时 250 毫秒，理想的 9.5 倍加速会把这一数字压到约 26.3 毫秒。一个包含 20 次决策的任务，其纯模型决策时间会从 5 秒下降到约 0.53 秒，理论上减少约 4.47 秒。

这组计算只是对“9.5 倍”量级的解释，并不是 Flide 在某一固定硬件上的官方实测结果。真实端到端延迟还包括文本预处理、网络传输、候选动作构建、浏览器截图、工具调用和页面加载，Flide 不可能把这些时间一并消除。

Flide 的价值因此取决于模型推理在整个任务耗时中的占比。如果页面本身需要 3 秒加载，把模型从 200 毫秒压到 30 毫秒，用户未必有明显感知；如果是机器人控制、游戏动作、实时审核或高并发路由，百毫秒级差距就可能决定系统能否工作。

决策模型赛道已经从模型战打到系统战

开源决策模型在过去一个多月迅速增多，原因不是 Jev 的能力无法替代，而是开发者需要更低延迟、更可控部署和更明确的成本结构。Clef、Laya、CLM、Kev 等项目采取了不同路径，但目标都类似：别让大模型为一个简单选择写一篇文章。

下表汇总了目前几条代表性路线，但这些数字来自不同团队、不同硬件和不同测试口径，不能直接当作统一排行榜：

| 项目 | 产品定位 | 已公开速度数据 | 输出方式 | 开放情况 | 需要注意的口径 | |---|---|---:|---|---|---| | Flide | Jev 类决策模型推理加速项目 | 最高 9.5 倍加速 | 延续底层模型的结构化决策输出 | GitHub 已开源 | 最高值不代表所有任务；需核对硬件、批量和基线 | | Jev | 闭源决策模型及服务 | 第三方资料常见约 236—276 毫秒 | 概率、分类、评分等 | 闭源 | 版本、网络和服务端负载会影响结果 | | Clef-flash | Cloudflare 开源决策模型 | 中位延迟 38.8 毫秒 | 直接决策，支持多模态 | Apache 2.0 | 官方内部评测与第三方结果应分开看 | | Laya | 面向本地运行的轻量决策模型 | 项目相关资料给出 32.8 毫秒 | 分类、评分、是非判断 | Apache 2.0 | 数据主要来自作者测试，仍需独立复现 | | CLM | Qwen3-8B 编码器加投影头的决策路线 | 部分零样本任务最高约 9 倍；验证器场景约 4.1—5.7 倍 | 编码状态与候选动作后比较 | 代码与权重开放 | 两组加速数据对应不同任务，不能混用 |

Flide 与这些模型更可能形成组合关系，而不是简单替代关系。一个开源决策模型解决准确率、许可和本地部署问题，Flide 则尝试继续挤压其推理时间；如果适配范围足够广，这种工具层的影响可能比再发布一个模型 checkpoint 更持久。

Clef-flash 已经把单次决策中位延迟推到 38.8 毫秒，而公开资料中的 Jev 延迟通常在 236—276 毫秒区间。即使不同测试不能横向硬比，这个数量级差异仍说明，决策模型的性能瓶颈已经不只取决于参数规模，还取决于打分头、执行图、批处理方式和推理运行时。

9.5 倍不能脱离准确率和校准单独看

决策模型的第一指标不是生成得像不像人，而是选得对不对。一次动作选择快了 9.5 倍，却更容易点错按钮、放过安全告警或错误拒绝正常交易，系统总体成本反而可能上升。

概率校准是决策模型必须单独评估的能力，它衡量模型给出的置信度是否与真实正确率一致。一个模型若对错误答案也经常给出 95% 置信度，哪怕分类准确率尚可，也很难安全地接入自动执行系统。

开发者评估 Flide 时首先应确认加速前后是否保持相同决策结果，而不只是看吞吐量。尤其涉及低精度计算、近似打分或执行图优化时，需要比较类别一致率、概率偏移、期望校准误差 ECE，以及不同阈值下的精确率和召回率。

候选动作数量同样会显著影响测试结果。二选一判断、十分类任务与上百个工具动作的选择，其计算和内存访问形态并不相同；只公布一个“最高 9.5 倍”，不足以说明它在真实 Agent 上的稳定收益。

长输入也可能重新改变瓶颈位置。输入只有几十个 token 时，框架调度与数据搬运的占比更高；输入扩展到数千 token 后，注意力计算和 KV Cache 管理会成为主要成本。一个在短文本分类上非常亮眼的优化，不一定能等比例迁移到长页面状态或复杂工具描述。

评测 Flide，至少要盯住六个变量

开发者不应直接用项目首页的最高数字估算生产容量，而应在自己的任务、硬件和并发设置下重跑基准。以下六项会直接决定 Flide 的真实收益：

1. 计时边界：模型前向时间、运行时总时间和端到端 Agent 时间是三组不同指标。
2. 硬件与精度：GPU 型号、CPU、显存带宽，以及 FP16、BF16、INT8 或其他量化方案都会改变结果。
3. 预热状态：首次加载通常包含权重初始化和编译时间，不能与预热后的连续请求混为一谈。
4. 批量与并发：Batch 1 的交互延迟和大批量吞吐优化经常存在取舍。
5. 输入与候选规模：Prompt 长度、候选数量和候选文本长度必须固定后再比较。
6. 质量等价性：加速前后的准确率、概率分布、阈值表现和失败样本应同时公开。

P50 与 P95 延迟也应该一起报告。P50 代表典型请求速度，P95 更接近生产系统在高负载或复杂输入下的体验；Agent 每一步都有尾延迟，多个步骤串联后，偶发慢请求会被明显放大。

吞吐量则不能代替单请求延迟。一个系统每秒能处理更多请求，不代表单个浏览器 Agent 会更快完成任务；对实时交互应用而言，Batch 1 的端到端延迟往往比峰值吞吐更重要。

Flide 的现实意义：让小模型不只是“便宜”，而是真的快

Flide 反映出的行业变化，是决策模型正在形成独立于通用聊天模型的工程栈。过去开发者习惯把所有任务都交给一个自回归大模型，现在越来越多系统会把规划、决策、执行和验证拆开，并为每一段选择不同模型。

这种分层架构更接近传统软件工程。高能力模型负责制定计划或处理模糊问题，轻量决策模型负责高频动作选择，普通程序负责真正执行点击、数据库查询或设备控制；模型不再包办全部流程，而是被放在最适合它的位置。

Flide 最适合的潜在场景包括：

• 浏览器 Agent 在有限按钮和输入框之间选择下一步；
• 客服系统进行工单分流、紧急度判断和回复策略选择；
• 安全平台对告警进行升级、忽略或转交人工；
• 推荐与广告系统对候选结果进行快速重排；
• 游戏和设备控制系统在预定义动作集合中高频决策；
• 多 Agent 系统判断任务应该交给哪个专用 Agent。

Flide 不太适合替代开放式推理或长文本生成。需要写代码、总结复杂文档、解释因果关系或制定多阶段计划时，通用大模型仍然更合适；强行把开放问题收缩成几个候选项，可能只是把复杂性转移到了候选构造环节。

我们的判断：方向比 9.5 倍这个数字更重要

Flide 当前最有价值的信号，不是它在某个最佳样本上快了 9.5 倍，而是 Jev 类模型已经开始拥有独立的推理优化层。模型、运行时和 Agent 框架一旦分层，开发者就能分别替换和优化，不必把所有性能问题都归结为“换一个更小的模型”。

9.5 倍仍需要更多可复现数据支撑，尤其需要明确基线模型、硬件、精度、输入长度、候选数量、Batch Size 和质量变化。只要缺少其中几项，这个数字就更适合被理解为性能上限展示，而不是生产环境承诺。

Flide 值得 Agent 开发者关注，但暂时不值得仅凭一个峰值倍数全面迁移。更稳妥的做法，是先在一个动作空间明确、调用频率高、错误成本可量化的子任务上接入，对比 P50、P95、准确率和单位吞吐成本，再决定是否扩展。

决策模型真正的竞争才刚开始。Jev 证明了“直接判断”可以成为独立产品，Clef、Laya 和 CLM 证明了开源模型能够跟进，而 Flide 进一步把战场推向推理系统：下一阶段比的不只是模型会不会选，还要看它能否在几十毫秒内、以可校准的概率稳定选对。

参考来源

• OmniJev/Flide GitHub 仓库：Flide 官方开源项目与最高 9.5 倍加速说法的主要来源。
• 38 毫秒：Cloudflare 开源的 Clef 决策模型，本地 6GB 就能跑：介绍 Clef 系列延迟、Decision Index 评测、上下文窗口与开源许可。
• Jev 刚发布就封神？独立研究员讨论 Jev 与开源替代路线：整理 Laya 等 Jev 类方案的技术思路、延迟和校准数据。