Jev LLM 路由器：把每条提示词交给能胜任的最便宜模型

这个路由器判断什么

上面的示例是一条用户请求：用流式方式解析一个 2GB 的传感器读数 CSV，按设备找出超过 5 分钟的数据缺口，并且内存不能超过 500MB。Jev 在一次调用里回答三个问题：

route 是决策本身，另外两个是可以记录、也可以参与路由的信号。这条请求是特意选的临界样本：代码本身是普通的 Python，但内存上限和流式处理的要求让它不只是一次查询。所以值得看的是概率在 medium 和 frontier 之间怎么分，以及 Jev 对这个分法有多确定。

对一条短提示词问三个问题只要 1 点；而且 Jev 会并行评估一次请求里的所有问题，多出来的两个问题几乎不增加延迟。

怎样写出好用的路由问题

按工作内容描述档位，而不是按模型名。 Jev 不知道你的 "small" 模型能做什么。"快速、便宜的模型就够了"是个起点；LangChain 路由示例里的写法更好："直接查询、信息抽取、目标明确的局部修改"，因为它说清了是哪类任务。

{
  "type": "choice",
  "instructions": "Which model tier should handle this request?",
  "criteria": {
    "small": "Lookups, extraction, rewording and short edits with an explicit target",
    "medium": "Multi-step tasks and ordinary code with clear requirements",
    "frontier": "Novel reasoning, architecture, or code with hard constraints"
  }
}

直接问决策。 一个 route Choice 给你一个可以直接行动的分布。只用 difficulty 反推档位，就得自己在 Score 上划分界线，更难调。

每个硬性要求配一个 Noul。 如果写代码的任务必须交给代码模型，就单独问 needs_code，而不是指望档位描述能覆盖到。"是否含个人数据""是否需要长上下文"也同理。

别让问题去数数。 TypeSafe 把数值精度列为已知弱点。"输入是否超过 10,000 token？"这类判断应该放在代码里，而不是交给 Jev。

更多写法见 设计 Jev 能回答的问题。

从一次判断到一层路由

1. 在第一次生成之前路由。 拿到提示词先调用 Jev，读取 route，再把请求发给对应档位的模型。TypeSafe 文档把模型路由列为一个独立用例，说法几乎一致：识别意图和领域，估计难度和风险，把需要更强模型的请求往上升级。
2. 把置信度当作第二个维度。 TypeSafe 的"置信度门控路由"模式里，选择决定"做什么"，置信度决定"要不要照做"。对路由器来说，置信度低时往上升一档是更稳妥的默认值：把简单请求交给大模型只是多花一点钱，把难的请求交给小模型则要付出一次失败回答加一次重试。
3. 把分布和选择一起记下来。 某次运行花费超出预期时，看概率就知道路由器当时是有把握还是在猜。
4. 记录模型版本。 每次响应都带有 model 字段（例如 jev-1.13.0）。把它和每条判定一起记下，版本变化时重新校验阈值——JevStation 在部署层固定模型，不需要你在请求里指定。
5. 在代码或框架里调用。 同样的评估可以用 API key 通过 System One API 调用。在 LangChain 里，实验性的 ModelRouterMiddleware 会根据最新一条用户消息选模型，并在整次运行中沿用。

路由、动作门控和升级处理怎样放进同一个智能体循环，见 用 Jev 构建 Agent Harness。

先验证，再信任

• 标注一批你自己的提示词。 Classmethod 的一位工程师在四个档位上跑了 40 次调用，每档 10 次全部分对，中位延迟约 0.65 秒，每次约 $0.000025。原文明确说明每档只用了一条提示词，不是准确率基准。你自己的流量才是基准。
• 盯住中间档。 同一测试里，两端档位返回的置信度是 1.0，而 medium 档落在 0.57–0.67 之间。临界提示词决定路由器能省下多少钱，先看它们。
• 和笨办法比一比。 LiteLLM 公布过一个基准：它基于规则的复杂度评分 AUC 只有 0.524，接近随机。如果 Jev 选出的档位还比不过你十行代码写出的规则，这个路由器就不值得。
• 看省了多少钱，而不只是准不准。 统计 small 被选中的比例，以及这些回答有多少需要重试。一个因为几乎总选 frontier 而从不出错的路由器，什么也省不下来。

Jev 不适合做路由的情况

• 决策取决于数字。 token 数、上下文长度、价格计算是代码的活，不是分类的活。
• 你需要路由器解释理由，给用户看或写进审计日志。Jev 返回的是概率，不是理由。
• 你要的是网关，而不只是决策。 Jev 只选档位，不代理请求、不重试、不做故障切换。把它和你已经在用的网关或客户端库搭配，Jev 只负责决定请求交给哪个模型。
• 所有请求本来就发给同一个模型。 如果一个模型便宜到足以处理全部流量，路由器只会多一次调用，什么也省不下。

在 试验台 里用你自己的提示词和档位试一试，或者在 定价页 看看大量路由判断要花多少。