AIAI 落地

我们把 LLM 换成了 Jev，成本降低 39%

Polylane 把值班 agent 每天几千个小决策从 LLM 换成了 Jev，这个不生成文本的模型只输出判断，成本降了 39%。文章列了迁移前后 30 项决策的对照。

PolylaneVi Tran8 分钟阅读

中文
中文日本語
复制
Polylane 博客题图：Jev 与 LLM 成本对比的示意图

我们的 on-call agent 每天要做出几千个小决策。我们把这些决策从 LLM 迁到了 Jev——一个不生成文本的模型——成本降低了 39%。

发布于：2026 年 9 月 25 日 作者：Vi Tran 和 Boris Tane 原文链接：https://polylane.com/blog/we-swapped-our-llms-for-jev/

我们正在做一个全天候运行的 on-call agent，它需要不停做决策，比如：

  • 这个问题有多严重？
  • 我们该主动介入这个 Slack 讨论串吗？
  • 这个故障我们之前见过吗？

直到上周，这些任务一直由 LLM 承担。这周一拿到 Jev 的访问权限，我们就开始试了。

Jev 是什么？

Jev 是 TypeSafe AI 推出的决策模型。它不生成文本，而是用带类型的值和经过校准的概率回答关于你数据的问题。TypeSafe 把它定位为「智能 if 语句」，用在分类、路由、打分这些手写逻辑太脆弱的环节，官方给出的响应时间是 70 到 500 ms，输出 token 免费。我们的 agent 整天都在做这类决策，于是直接上了生产环境。

工作原理

一个请求包含两部分：state，即你要对其做决策的文本或 JSON；以及你想得到答案的 questions。每个问题属于三种类型之一：

graph TB
    S["State: a message, thread, or evaluation case"] --> J["Jev"]
    Q["Questions"] --> J
    J --> N["Noul<br/>yes/no"]
    J --> C["Choice<br/>pick an option"]
    J --> R["Score<br/>rate against a rubric"]
    style J fill:#d1fae5,stroke:#6ee7b7,color:#065f46
    style N stroke:#3b7dd8,color:#2b5fa8
    style C stroke:#3b7dd8,color:#2b5fa8
    style R stroke:#3b7dd8,color:#2b5fa8
  • Noul 返回 yes 的概率。
  • Choice 从给定选项中选出一个。
  • Score 在一个有序评分标准上返回概率加权后的值。

用例一：路由，或者说 agent 什么时候该回应？

我们的 agent 会主动参与 Slack 和 Github。只要它们有对用户有价值的洞察，就会回复 Slack 消息或 Github 评论。用户提出请求时 agent 必须行动，但又不能对每个事件都过度反应。这正好适合用 Jev 的 Noul 问题来解决。

flowchart LR
    E["New event"] --> M["PR comment<br/>Slack message"]
    M --> J["Jev Noul<br/>Triage?"]
    J -->|Yes| W["Wake agent<br/>to follow up"]
    J -->|No| N["No action"]
    style J fill:#77a52d,stroke:#5c8023,color:#ffffff
    style W stroke:#77a52d,color:#5c8023
    style N fill:#e5e5e8,stroke:#d1d2d6,color:#47484d
  • 我们 agent 提交的 PR 下的评论： 审查者要求修改，会唤醒 agent；CI 状态更新或一句「谢谢」不会。
  • Slack 频道： 只有确实能帮上忙时，比如有人直接问基础设施相关的问题，agent 才会不请自来地插话。人类之间互相协调时，它不参与。
  • agent 所在的 Slack 讨论串： 它会回复针对自己的消息，忽略人类之间的对话，有人让它退出时它就退出。

下面是一个 Jev 请求示例，用来判断 agent 是否应该跟进某条 Slack 消息。

{
  "model": "jev-1.13.0",
  "state": {
    "slack_channel": "#Deployment",
    "user_message": "Watch this PR until fully deployed"
  },
  "questions": {
    "respond": {
      "type": "noul",
      "instructions": {
        "question": "Should the agent follow up on this user message?"
      }
    }
  }
}

我们运行 Jev 大约一周，并与之前用于这项任务的 LLM 做了对比。

图 1. 响应路由：延迟与每 1,000 次调用成本

指标DeepSeek V4.1 FlashJev
P90 延迟（ms）1,466 ms472 ms
每 1,000 次调用成本（USD）$0.238$0.123

路由的 P90 延迟快了 3 倍，从 1.5 秒降到 500 ms 以内，成本也几乎减半。

用例 2：分类，或者说这些证据意味着什么？

我们还运行了一些需要 agent 把内容分到不同类别的任务。比如，根据给出的证据，agent 应该开始调查这个问题，还是把它归为与某个已有问题相关，抑或它其实是某个已解决问题的重复？

一个 Jev Choice 问题会依据我们定义的标准，把那些证据变成一个标签，下一步由这个标签决定。大致是这样：

flowchart LR
    I["New incident"] --> E["Evidence from tool calls"]
    E --> J["Jev Choice"]
    J -->|Same root cause| D["Defer to the original"]
    J -->|Related| L["Link both incidents"]
    J -->|Independent| N["Investigate on its own"]
    style J fill:#77a52d,stroke:#5c8023,color:#ffffff
    style D stroke:#77a52d,color:#5c8023
    style L stroke:#77a52d,color:#5c8023
    style N fill:#e5e5e8,stroke:#d1d2d6,color:#47484d

我们用这种方式运行了三个分类任务。每个都用一个带明确标准的 Choice 问题，并且各自替换了不同的 LLM，所以是分开测量的。

这些事件相关吗？

新事件开启时，agent 会把它与已有事件做比较：它们是否同属一个根因，是相关，还是彼此独立？下面这个示例只展示了一个候选；生产环境中的调用会把多个候选与同一个新事件做比较。

{
  "model": "jev-1.13.0",
  "state": {
    "incident": "Checkout cannot authenticate to the database.",
    "candidate_0": "Billing cannot authenticate to the same database.",
    "evidence": "Both services use a credential revoked at 14:00."
  },
  "questions": {
    "candidate_0": {
      "type": "choice",
      "instructions": "How is candidate_0 connected to the new incident?",
      "criteria": {
        "duplicate_same_root_cause": "One underlying problem explains both",
        "related": "Distinct problems share a trigger or blast radius",
        "independent": "No evidenced connection"
      }
    }
  }
}

在这个用例中改用 Jev 后，P90 延迟快了近 8 倍，从 2.9 秒降到 400 ms 以内，成本降低 27%。

图 2. 事件关联：延迟与每 1,000 次调用成本

指标GPT-OSS 120BJev
P90 延迟（ms）2,859 ms373 ms
每 1,000 次调用成本（USD）$0.388$0.285

我们提交的这个 PR 为什么被关闭了？

我们的 agent 会向开发者提交 pull request，而合并率是我们的关键成功指标之一。我们需要弄清楚 pull request 为什么会被关闭，这样才能改进产品。

当我们的某个 PR 未合并就被关闭时，agent 会阅读评审意见、讨论内容以及对其他工作的引用，然后判断原因：修复本身有误、有人用别的方式修好了、问题属于误报、PR 搁置过久，或者该行为本就是预期行为。

在这个场景中改用 Jev 后，P90 延迟提升到快 6 倍，但成本只降低了 17%。

图 3. 修复类 PR 关闭原因：延迟与每 1,000 次调用成本

指标GPT-OSS 120BJev
P90 延迟（ms）2,379 ms416 ms
每 1,000 次调用成本（USD）$0.123$0.102

这个 pull request 有多紧急？

在把 pull request 提交给开发者之前，我们的 agent 需要对其排序，让严重程度更高的问题排在前面。做这个分类时，agent 会按从 critical 到 info 的阶梯给底层问题定级。它评估的是当前影响，而非假设性风险。

图 4. Autofix 严重程度：延迟与每 1,000 次调用成本

指标DeepSeek V4.1 FlashJev
P90 延迟（ms）1,456 ms313 ms
每 1,000 次调用成本（USD）$0.197$0.081

在这里改用 Jev 大幅降低了成本：比 DeepSeek V4.1 Flash 便宜 59%，P90 延迟快了近 5 倍。

在所有分类任务上 Jev 都更快。在它替换 GPT-OSS 120B 的地方，收益主要体现在延迟上。在它替换 DeepSeek V4.1 Flash 的地方，账单也减少了一半以上。

用例 3：排序，或者说这个云资源有多重要？

为了充分发挥 Polylane 的作用，团队会接入自己的云账户。我们会为所有云资源构建一张上下文图，让 agent 能快速理解计算节点、数据库、队列等之间的关系。

平台上有一些团队的云账户极其繁忙，拥有数万个节点。每台服务器、每个沙箱、每个数据库和每个队列都是我们上下文图中的一个节点。必须对这些节点进行排序，agent 才能知道哪些对你的应用至关重要，哪些挂了基本“没关系”。

我们为每个资源分配四个优先级之一：Critical、Standard、Low 或 Minimal。

flowchart LR
    C["Cloud account"] --> G["Context graph"]
    G -->|Each node + metrics| J["Jev Choice"]
    J --> T1["Critical"]
    J --> T2["Standard"]
    J --> T3["Low"]
    J --> T4["Minimal: fine to fail"]
    style J fill:#77a52d,stroke:#5c8023,color:#ffffff
    style T1 stroke:#77a52d,color:#5c8023
    style T2 stroke:#77a52d,color:#5c8023
    style T3 stroke:#77a52d,color:#5c8023
    style T4 fill:#e5e5e8,stroke:#d1d2d6,color:#47484d

Jev 会针对每个资源评估一个 Choice 问题，判断依据来自配置、环境、近期指标和依赖关系。

{
  "model": "jev-1.13.0",
  "state": {
    "instructions": "Assign importance relative to the other resources in this cohort.",
    "cohort": [
      {
        "id": "database-a",
        "environment": "production",
        "daily_queries": 80000,
        "dependents": 6
      },
      {
        "id": "database-b",
        "environment": "preview",
        "daily_queries": 0,
        "dependents": 0
      }
    ]
  },
  "questions": {
    "resource_0": {
      "type": "choice",
      "instructions": "Assign the importance tier for database-a.",
      "criteria": {
        "1": "Critical: substantial production traffic or blast radius",
        "2": "Standard: active and operationally relevant",
        "3": "Low: limited activity or importance",
        "4": "Minimal: idle or disposable, without meaningful dependents"
      }
    }
  }
}

排序正是 Jev 的强项：P90 延迟快 10 倍以上，从 5.4 秒降到约半秒，成本还低 34%。这也是我们调用量最大的决策，因此整体节省主要来自这里。

图 5. 资源排序：延迟与每 1,000 次调用成本

指标GPT-OSS 20BJev
P90 延迟（ms）5,445 ms511 ms
每 1,000 次调用成本（USD）$0.817$0.542

总结

总体来看，Jev 在延迟和每 1,000 次调用估算成本上都带来了大幅下降：

  • P90 延迟下降：4,752 ms --> 508 ms。
  • 每 1,000 次调用成本下降：$0.76199 --> $0.46369。

图 6. 已完成调用上 Jev 与 LLM 的对比 2026 年 9 月 20 日 20:00 至 9 月 24 日 20:00 UTC · 36,664 次 LLM 调用与 23,951 次 Jev 调用

指标LLMJev
P90 延迟（ms）4,752 ms508 ms
每 1,000 次调用成本（USD）$0.76199$0.46369

P90 延迟约快 89.3%。 从 4,752 ms 降至 508 ms。

每 1,000 次调用成本低 39.1%。 从每 1,000 次调用 $0.76199 降至 $0.46369。

36,664 次 LLM 调用与 23,951 次 Jev 调用，包含资源层级分类；P90 为近似值，每 1,000 次调用成本为已完成调用的均值。

按模型看，Jev 既是最快的，也是最便宜的：比 DeepSeek V4.1 Flash 略便宜，远低于两个 GPT-OSS 模型。

图 7. 各模型的延迟与每 1,000 次调用成本

P90 延迟每 1,000 次调用成本
OpenAI GPT-OSS 20B5,445 ms$0.82
DeepSeek V4.1 Flash1,372 ms$0.51
OpenAI GPT-OSS 120B2,255 ms$0.74
TypeSafe AI Jev508 ms$0.46

只要我们的 agent 是从固定答案集中选择，Jev 现在就是默认选项：我们迁移过来的每一个决策，它都更快、更便宜。

来源: Polylane← 返回首页