你的智能体调用中，有多少真正需要前沿模型？

liumuhui 3小时前阅读数 1 #区块链

并非每一轮都需要你的最强模型。 我们测出只有 7%，而这些调用占了账单的 68%
路由是一种权衡。 便宜 74%，但准确率下降约 6 个点
在动手构建之前，先计算成本权衡公式。 用判断模型成本除以价格差，得到你需要分流的下限。如果两个模型价格接近，这个数字会超过 100%，路由就无法回本，除非你自己托管廉价模型

AI Agent 会发起大量 LLM 调用，而大多数团队会把每一次调用都发给同一个模型。NVIDIA NeMo Switchyard 是一个开源模型路由库，可在 agent 工作流各步骤中自动完成模型选择，这样不需要前沿模型的工作就不会被送去调用前沿模型。

我们通过 Switchyard 运行了 Deep Agents 评估套件，并测量了路由器将多少轮次发送给了前沿模型。答案是 7%。一个 30B 参数的模型处理了其余 93% 的工作。在 NVIDIA Nemotron 3.5 Lightning 和 Claude Opus 4.8 之间进行路由，与单独运行 Opus 相比，总成本降低了 74%，同时在相同的调用上保留了 93% 的准确率。

下面是我们测得的数据，以及一个公式，它告诉你在什么情况下应该考虑为自己的工作负载采用同样的策略。

只选一个模型的问题

在模型更便宜、能力更接近的时代，把所有调用都发给同一个模型是一个合理的默认做法。但情况已经变了。前沿模型变得更贵、能力更强，而开放权重模型已经变得足够快、足够便宜，可以承担 agent 工作中相当一部分，尽管不是全部。与此同时，“读取这个文件”这样的轮次和“搞清楚这个测试为什么失败”这样的轮次，仍然以相同的每 token 价格发送给同一个模型，哪怕一个无关紧要，另一个并非如此。

真正需要昂贵模型的轮次有多少，决定了路由是否划算。我们已经在 Deep Agents 上运行基准测试套件，所以这次我们把套件指向了一个路由器，而不是一个模型。

Switchyard 的作用

Switchyard 是 NVIDIA 的开源路由库。它根据你为每一步配置的策略，自动将每个 agent 查询路由到闭源和开源模型的任意组合上。你可以把它作为 agent 指向的代理来运行，也可以作为 agent 进程内部的中间件来运行。

它提供了两种路由方案，第三种还在研究阶段，它们在延迟和准确率之间的取舍方式各不相同：

LLM 分类器。 一个小型判断模型参与路由决策。它有三种运行模式：capability 模式为每次调用选择一个目标；escalation 模式以低成本启动每个任务，在连续多次糟糕的轮次后将会话升级到更大的模型；custom 模式让你自定义。这种方式有更高的准确率潜力，代价是额外调用一次小型模型。
阶段路由器（启发式）。 NVIDIA 将其描述为按工作流阶段路由，读取错误模式、推理模式和 token 数量。它不会增加额外的模型调用，在延迟上的成本几乎为零。只有当你的 agent 流量产生它寻找的信号时，它才会触发；我们没有对它进行基准测试。
Prefill-activation MLP。它根据模型内部状态进行路由，读取 prefill 阶段的激活模式。目前处于研究阶段而非生产就绪，但这是 NVIDIA 正在探索的方向。

我们以 escalation 模式对 LLM 分类器进行了基准测试，也就是下方配置中的 type = "llm_classifier"。Escalation 模式让每个任务都从较便宜的模型开始。一个小型判断模型会读取每一轮完成的结果，并投票判断 agent 是否走在正确的轨道上。连续两次否定判定后，该任务之后会被路由到昂贵模型。这种单向门机制降低了路由成本，因为随着任务升级，判断模型就不需要在每一轮都运行了。

Escalation 路由：两次判定后，任务在整个会话剩余部分被切换到昂贵模型。

我们测量了什么

我们的 Deep Agents 评估套件包含 145 个多步骤 agentic 任务，平均每个任务 6.3 次模型调用，其工具操作映射到实际生产工作负载：

在策略约束下的客户支持对话。
值班事件调查。
跨消息、问题跟踪和电子邮件的多步骤工作流自动化。

这些评估涵盖工具使用、多步骤检索、文件系统操作和长上下文摘要，场景来自 τ²-bench airline、Berkeley Function Calling Leaderboard、FRAMES 和 Nexus。你可以在此处查看评估本身。

在分享结果之前，先说明一下适用范围。这些评估是在受控场景中运行的。这种方法的好处是我们可以直接将失败归因到原因上。然而，这种受控性的代价是它也让套件变得饱和：三种工作负载类型的准确率都很高，30B 参数模型与前沿模型之间只有 8 个点的差距。这使得路由证明自身价值的空间，比更难的工作负载更小。请将以下内容视为对一种工作负载的测量，而不是对你工作负载的预测。所有成本中，缓存输入按缓存费率计价，这也是账单上显示的价格。

实验组	准确率	每次运行成本	每个完成任务成本
仅 Opus 4.8	86.0%	$11.45	$0.092
Opus 和 Nemotron 3.5 Lightning（路由）	80.0%	$3.00	$0.026
仅 Nemotron 3.5 Lightning	77.7%	$0.72	$0.006

调用去向与费用去向之间的对比是核心发现。Nemotron 3.5 Lightning 承担了 93% 的模型调用，却只占支出的 10.4%；而 Opus 承担了 7% 的调用，却占了支出的 68.4%。前沿模型的使用频率远低于单模型设置所假设的水平，而最后 6 个点的准确率，让每个完成任务的成本高出 3.5 倍。

路由实验组中模型调用占比与支出占比的对比。调用次数不包括判断模型，它在每个低成本轮次中触发一次。

判断模型占据了剩余 21.2% 的支出。它在任务升级之前的每一轮都会运行，而且与前沿模型不同，它无法从 prompt 缓存中获益，因此它成为路由实验组中第二大支出项，约为 Opus 成本的三分之一。所以如果你想削减路由成本，判断模型本身值得优化，而不只是优化升级率。

准确率的代价是真实存在的。 路由便宜了 74%，但准确率低了 6 个点。单次运行的波动约为 2.7 个点，因此 6 个点的差距远在噪声范围之外。
价值来自将流量从前沿模型移开，而不是移向它。 把简单的工作交给廉价模型，节省就来自这里。当廉价模型表现不佳时把任务移交给 Opus，比全程运行廉价模型得分高 2.3 个点。这个差距小于运行本身的波动幅度，所以我们不能说路由在这里击败了廉价模型。
多次运行的成本保持稳定。 Opus 在三次运行中的成本仅波动了 1.5%，因此 74% 这个数字建立在稳定的基线上。每次运行的节省幅度在 68.5% 到 81.1% 之间，原因见下一节。

按区间做预算，而不是按单一数字

五次运行中，前沿模型流量占比在 4.1% 到 9.1% 之间，平均为 6.9%；升级最频繁的运行，其升级次数是最不频繁运行的 2 倍以上。一次 Opus 调用花费 $0.0324，而 Nemotron 3.5 Lightning 只需 $0.00037，相差约 87 倍，因此这种波动带来了 $2.16 到 $3.61 的成本区间。这些运行之间唯一的变量是路由器决定升级哪些轮次，而账单依然波动了 67%。

这就是使用路由器的代价：它降低了你的平均支出，但同时也拉大了支出波动的区间。请按区间的上限做预算。如果你想缩小这个区间，判定次数是你手中杠杆作用最大的设置。它就是下方配置中的 confirmations，决定判断模型在将一个任务升级到前沿模型之前需要看到多少次糟糕的轮次。调低它，你会更频繁地升级，而那些正是昂贵的调用。判断模型本身是另一个杠杆：它占了路由支出的 21.2%，所以换一个更便宜的判断模型，或者一个能跳过明显运行良好的轮次的判断模型，省下的钱会直接体现在你的账单上。

最明显的质疑

单独使用 Nemotron 3.5 Lightning，每次运行花费 $0.72，得分 77.7%；单独运行 Opus 花费 $11.45，得分 86.0%；路由方案花费 $3.00，得分 80.0%。那为什么还要用模型路由器呢？

路由方案比廉价模型得分高 2.3 个点，但成本是它的 4.2 倍。这个差距小于运行本身的 2.7 个点波动，所以我们不能说路由在这里击败了廉价模型。值得直说的一点是：廉价模型表现很好。在这套评估中，Nemotron 3.5 Lightning 与前沿模型之间只有 8 个点的差距。这是一个单一工作负载，所以在你据此行动之前，请先对照你自己的情况验证。

这种比较还带有后见之明。我们知道这 145 个任务的结果如何。在生产环境中，你无法预知刚到的请求是简单还是困难，全程运行廉价模型意味着在困难请求上你也要接受它的答案。路由是为“不必猜测”付出的成本，它也降低了你的成本上限：我们最差的一次路由运行花费了 $3.61，大约是单独运行 Opus 的三分之一。

所以，如果你的首要目标是成本最低，而且你的流量与这个工作负载相似，那么单独使用 Nemotron 3.5 Lightning 是更好的选择。路由适合那些在困难请求上需要前沿能力、但又无法提前判断哪些请求是困难请求的团队。

这个权衡在你的工作负载上是否值得

只有当你发送给较小模型的轮次占比超过这个门槛时，使用路由器相比单独使用前沿模型才能降低总成本：

minimum offload = judge cost / (expensive cost - cheap cost)

判断模型是对每次运行的固定征税。它在任务升级之前的每一轮都会运行，无论最终是否有任务被升级。所以问题从来不是“我的廉价模型够好吗？”，而是“两个模型之间的价格差是否足以支付判断模型的费用？”

在我们的组合中，判断模型每次运行花费 $0.64，而价格差为 $10.73，因此我们需要分流 5.9% 的轮次。我们分流了 93%，超出门槛 16 倍。差距如此悬殊，所以对于这种一边倒的组合，这个公式更像是走个过场。当模型价格差较窄时，答案不那么明显，公式会更有用。

这个公式也可以排除路由方案。如果你的两个模型价格接近，每次分流轮次能省下的钱很少，公式会要求你把超过 100% 的轮次发送给廉价模型，这是不可能的。任何判断模型配置都无法解决这个问题。唯一的例外是本地托管的廉价模型。如果你自己把它部署在 NVIDIA DGX Spark 这样的设备上，其推理成本几乎为零，这会拉开价格差，让路由重新变得划算。

这个公式无法告诉你这个路由器能否在你的流量上做出正确的选择。它只能告诉你，正确的选择是否值得付费。用它来从成本角度排除路由方案。要验证路由是否可行，请运行你自己的工作负载。

什么时候不应该使用

你对延迟敏感。 判断模型每轮会带来第二次模型调用，大约 700ms，而阶段路由器的延迟几乎为零。
你的工作负载很短。 Escalation 需要多轮轨迹才有内容可读。

快速开始

有两种方式可以将 Switchyard 与 Deep Agents 一起运行，它们适合不同的目标。

复现我们的测量结果

我们的数据来自 escalation 模式，这是 Switchyard 服务器上的一种路由配置。从 NVIDIA-NeMo/Switchyard 启动服务器，将你 agent 的 base_url 指向它，并在配置文件中描述你的模型。


schema_version = 1

[llm_clients.nvidia]
format = "openai_chat"
base_url = "https://integrate.api.nvidia.com/v1"
api_key_env = "NVIDIA_API_KEY"

[llm_clients.anthropic]
format = "anthropic_messages"
base_url = "https://api.anthropic.com"
api_key_env = "ANTHROPIC_API_KEY"

[llm_clients.gemini]
format = "openai_chat"
base_url = "https://generativelanguage.googleapis.com/v1beta/openai"
api_key_env = "GOOGLE_API_KEY"

[targets.weak]
id = "nvidia/nemotron-3.5-lightning-30b-a3b"
llm_client = "nvidia"

[targets.strong]
id = "claude-opus-4-8"
llm_client = "anthropic"

[targets.judge]
id = "gemini-3.1-flash-lite"
llm_client = "gemini"

[routes.switchyard]
id = "switchyard"
type = "llm_classifier"
mode = "escalation"
weak_target = "weak"
strong_target = "strong"
classifier_target = "judge"

[routes.switchyard.escalation]
confirmations = 2      # 在切换到强模型之前需要连续多少次判定

Switchyard 会在不同格式之间进行转换，所以上面三个模型分别使用 OpenAI Chat、Anthropic Messages 和 OpenAI Chat 格式，而你的 agent 只使用 OpenAI Chat 格式。

在你的 agent 内部进行路由

现在，Deep Agents 也有了一个 Switchyard 中间件。路由在进程内完成，无需单独运行服务，任何 LangChain 聊天模型都可以作为路由目标。工具绑定、回调、追踪和结构化输出都能继续正常工作，每个响应都会在 response_metadata["switchyard"] 中携带路由追踪信息，其中 selected_model 是最终选择，decisions 是当算法多次决策时的有序追踪记录。


from deepagents import create_deep_agent
from langchain_openrouter import ChatOpenRouter
from switchyard.libsy import LlmTarget, algorithms
from langchain_nvidia_switchyard import LangChainLlmClient, SwitchyardRoutingMiddleware

## 换成你希望在其间路由的任意一对模型。
efficient_model = ChatOpenRouter(model="nvidia/nemotron-3.5-lightning-30b-a3b")
capable_model = ChatOpenRouter(model="anthropic/claude-opus-4.8")

## 参数顺序很重要：能力强的目标在前，高效的目标在后。
router = algorithms.stage_router(
    LlmTarget("capable", LangChainLlmClient(capable_model)),
    LlmTarget("efficient", LangChainLlmClient(efficient_model)),
    picker="efficient_first",
    confidence_threshold=0.5,
    recent_window=3,
)

## Deep Agents 仍然需要一个基础模型。中间件会在每次调用时替换为它自己的选择，
## 因此复用已配置的目标可以避免多余的第三个模型。
agent = create_deep_agent(
    model=efficient_model,
    middleware=[SwitchyardRoutingMiddleware(router)],
)

result = await agent.ainvoke(
    {"messages": [{"role": "user", "content": "Summarize the important files in this project."}]}
)

该中间件仍处于实验阶段，尚未作为包发布。你需要同时克隆 Switchyard 和 langchain-nvidia 并在本地安装，环境要求 Python 3.12 或更高版本，deepagents 0.7.4 或更高版本。它提供阶段路由、LLM 任务分类器、随机和 noop。我们的数据来自服务器上 escalation 模式下的 LLM 分类器路由，那是一种路由配置，而不是中间件算法，所以上面的示例不会直接复现这些数据。阶段路由依赖工具调用和工具结果的信号，适合工具流量密集的 agent，比如编程类 agent。