一个值得重新思考的问题： 为什么 AI Agent 的每一个决策，都要调用一个几十 B 甚至上百 B 参数的大模型？ 最近 vLLM Semantic Ro… · @xqliu · TwKit

@xqliu

一个值得重新思考的问题： 为什么 AI Agent 的每一个决策，都要调用一个几十 B 甚至上百 B 参数的大模型？ 最近 vLLM Semantic Router 发布的 Decision 3.0 系列，让我觉得专用决策模型可能会成为 Agent 架构中越来越重要的一层。 Decision 3.0 并不是传统意义上的聊天模型。 它主要面向结构化决策任务。 输入可以是文本、JSON、图片或视频。 输出则可以是选项概率、是或否的判断，以及评分结果。 不需要生成几百个 Token 的自然语言解释。 这一系列包含两个值得关注的模型。 d3：260.9 亿参数，基于 Qwen3.8-27B。 d3-lite：8.5 亿参数，基于 Qwen3.5-0.8B。 在官方公布的 Jev Decision Index 0.3.2 评测中： d3：66.3 分，上一代为 55.9 分。 d3-lite：32.3 分，上一代同档模型为 17.5 分。 其中 d3-lite 在 AMD MI325X 上报告的文本请求中位延迟为 13.6ms。 当然，这个延迟来自特定服务器 GPU 和测试配置，不能直接套用到消费级显卡。 真正让我感兴趣的，是它背后的架构思路。 现在很多 Agent 系统都采用一个相对通用的设计： 把所有信息交给大型语言模型，让它判断下一步应该做什么。 但 Agent 工作流中，其实存在大量不需要复杂文本生成的决策。 例如： 当前任务应该交给哪个模型？ 这个操作是否需要人工审核？ 某个测试失败是否值得重试？ 当前任务应该继续执行还是终止？ 应该调用代码生成模型，还是代码审查模型？ 是否需要升级到更昂贵的推理模型？ 这些问题的输出通常非常简单。 可能只是一个类别、一个概率、一个分数，或者一个结构化决策。 如果每次都调用大型生成模型，不仅增加延迟，也会增加推理成本。 更重要的是，自然语言生成并不是完成这些任务的必要条件。 我认为未来的 Agent 系统可能会逐渐形成更明确的分工。 小型 Decision Model 负责高频、低延迟的决策。 大型 Reasoning Model 负责复杂分析和规划。 Coding Model 负责实现。 Verifier 负责验证结果。 Runtime 则负责维护状态、管理资源和协调执行。 这种架构的优势不只是降低成本。 它还可能让系统的行为更加容易观察和评估。 因为结构化决策可以直接记录概率、置信度和最终选择。 但这里有一个必须注意的问题。 分类 Benchmark 的高分，并不意味着真实 Agent 工作流一定会更好。 一个路由模型即使有 95% 的决策准确率，如果错误集中在关键步骤，也可能让整个任务失败。 因此，真正需要验证的是端到端任务成功率、错误路由成本，以及整体执行延迟。 而不是单纯比较分类准确率。 我的判断是： Agent 系统未来不一定需要一个越来越大的模型来处理所有事情。 更有可能出现的是多个不同规模、不同职责的模型协同工作。 其中，小型专用决策模型可能成为非常重要的基础组件。 不是每个决策都值得消耗一次昂贵的大模型推理。 项目：https://github.com/vllm-project/semantic-router

曝光 130 · 评论 1 · 点赞 0 · 书签 0