DigitalOcean 推理路由器新增缓存感知能力：为什么最便宜的模型不一定最省钱

Coinbase CEO Brian Armstrong 最近提出了一个问题，也是所有正在扩大 AI 使用规模的企业都在面对的问题：当 Token 用量呈指数增长时，怎样才能让 AI 支出保持基本不变？

这并不是一个假设场景，而是各行各业的企业正在真实面对的问题：

Uber 在今年前 4 个月就用完了全年的 AI 编程预算，随后为每名员工设置了每月 1,500 美元的使用上限。
Walmart 在发现员工反复让内部 Code Puppy Agent 解决类似问题后，对它设置了 Token 使用上限。
一名 Priceline 员工表示，一次常规的 Cursor 续费报价变成了原来的 4～5 倍。

限制用量确实可以帮助控制账单，但也会同时限制真正有价值的工作。更好的办法，是通过更合理的默认模型、更智能的模型选择，以及针对具体工作负载更充分地利用缓存，改善每一次请求的成本结构。

现在，DigitalOcean 推理路由器正式加入缓存感知（Cache-aware）能力 。今年 4 月，我们推出了偏好感知路由，让推理路由器能够根据开发者的任务类型和优先目标，为每次请求匹配更合适的模型。现在，它还可以把已经缓存的上下文价值纳入模型选择。这样一来，推理路由器不再只是"为单次请求选择模型"，而是可以从质量、成本和缓存复用等多个维度，对整个 Agent Session 进行优化。随着这项功能上线，开发者也获得了更完整的控制能力，可以按照团队真实的工作方式构建自己的智能模型选择层。

热缓存的价值，有时比更便宜的模型更高

在构建 Agent 时，缓存是一个非常关键的因素，因为 Agent 会反复发送大量相同上下文，包括 System Instruction、Tool Definition、Repository Context，以及不断累积的 Conversation History。

目前，一些主流模型平台已经在积极利用缓存能力：

Z.ai （智谱）在估算 Coding 套餐用量时，会把 90.9% 的 Cache Hit Rate 作为编程工作负载的平均假设。
Anthropic 表示，Claude Code 会通过 Prompt Caching 降低连续调用的成本，同时缩短响应时间。
OpenAI 的数据显示，缓存 Prompt 最多可以把延迟降低 80%。

对于 Agent 来说，缓存并不是一个边缘优化项。它会直接影响后续几乎每一次模型调用的成本和延迟。在 DigitalOcean，我们随着为客户扩展越来越多模型，也越来越明显地观察到了这一点。随着近期 Kimi K3 上线，开发者开始大量用它处理 Coding 和 Long-horizon 任务，我们在自身工作负载中观察到整体 Cache Hit Rate 超过 90%；当然，不同工作负载的实际结果会有所不同。

把缓存因素纳入模型选择后，原本看起来很简单的"哪个模型更便宜"就会变得不一样。举个例子，假设一个 Agent 的上下文一共有 100,000 个输入 Token，其中已经有 90,000 个 Token 缓存在 Claude Sonnet 5 上。按照标准价格，输入价格为每百万 Token 2.5 美元（已启用 Cache Write），Cached Token 为每百万 Token 0.2 美元。在 90% Cache Hit 的情况下，下一次请求的输入成本大约只有 0.043 美元。（价格信息以本文发布时为准。）

相比之下，GLM-5.2 的未缓存输入价格为每百万 Token 0.7 美元，看起来明显更便宜。但如果此时切换模型，现有热缓存就会失效，新模型必须重新处理全部 100,000 个输入 Token。按照这个示例中的假设，这次请求的成本会变成 0.07 美元------大约是在这个场景中继续使用那个"标价更贵"模型的 1.6 倍。继续使用已有热缓存的模型，只需要对 10,000 个未缓存 Token 做 Prefill；切换模型则需要重新处理全部 100,000 Token，也就是生成开始之前需要处理的 Prompt 数量增加到 10 倍。这并不意味着延迟一定增加 10 倍，因为不同模型和 Serving System 的 Prefill 性能不同。但它确实解释了，为什么一次破坏缓存的模型切换，即使目标模型本身速度更快，也可能明显增加 Time to First Token。

推理路由器如何在模型选择时考虑缓存

在缓存感知能力上线之前，推理路由器会把每次请求独立评估。它可能正确判断出另一个模型更便宜，或者更适合当前上下文，但并不知道这次请求其实属于一个正在持续进行、并且已经建立热 Prompt Cache 的 Agent Session。

问题在于，一旦切换模型，现有 Cache 就可能失效，目标模型不得不重新处理整个 Prompt。对于会反复发送大量 System Instruction、Tool Definition、Repository Context 和 Conversation History 的 Agent 来说，切到那个"更便宜"的模型，反而可能让下一次请求变得更贵、更慢。另一个问题是，在 Agent Loop 执行到一半时更换模型，还可能改变模型行为。

当客户告诉我们，他们希望对这种取舍拥有更强控制能力之后，我们构建了缓存感知模型选择机制。它引入了两个互补机制：对于已经自行管理 Session 的应用，可以使用显式模型亲和性；同时还提供 Routing Budget Policy，用来判断什么时候放弃当前模型和缓存、承担额外成本，才是值得的。

使用自定义 HTTP Header `X-Model-Affinity` 显式关联请求

已经维护 Session ID 或 Task ID 的应用，可以在每次请求中传入一个明确的 Affinity Key：

python 复制代码

import os
import uuid
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MODEL_ACCESS_KEY"],
    base_url="https://inference.do-ai.run/v1/",
)

session_id = str(uuid.uuid4())
messages = []
user_turns = [
    "Help me debug this failing test.",
    "Here's the stack trace, what's causing it?",
    "That fixed it, now can you also add a regression test?",
]

for user_turn in user_turns:
    messages.append({"role": "user", "content": user_turn})

    response = client.chat.completions.create(
        model="router:<your-router-name>",
        messages=messages,
        extra_headers={
            "X-Model-Affinity": session_id,
        },
    )
    assistant_reply = response.choices[0].message.content
    messages.append({"role": "assistant", "content": assistant_reply})

第一次请求会按照开发者配置好的 Task、Model Pool 和 Routing Preference 进行模型选择。之后，只要请求携带相同的 X-Model-Affinity 值，推理路由器就会把它们视为同一个工作单元，从而保留该 Session 与模型之间的绑定，并继续复用已经缓存的上下文。Affinity Identifier 应该对应真正有意义的工作单元，例如一次 Coding Session、Research Task、Support Conversation，或者单独的一次 Agent Run。当应用真正开始一个全新任务时，就可以生成新的 Identifier，让推理路由器重新根据任务和偏好选择模型。

对于常见 Agent 请求，如果应用没有提供显式 Identifier，推理路由器也可以自行推断 Affinity。它会从多轮请求中保持稳定的上下文生成 Session Key，包括 System Instruction、Developer Instruction、Tool Definition 和第一条 User Message。如果这部分稳定 Prefix 发生变化，推理路由器就会把 Cache 视为冷缓存，并建立新的模型绑定。新的 Session 会被重新分配到某个模型，然后从头开始积累自己的热缓存。

通过 Routing Budget 控制会破坏缓存的模型切换

Model Affinity Header 很适合那些已经能够追踪明确工作单元的应用，例如 Research Task 或 Support Conversation，而且开发者希望确定哪些请求必须共享同一个模型绑定。随着这次更新，我们还加入了 Routing Budget：它是另一项互补控制能力，可以让推理路由器继续评估其他候选模型，同时不要求修改应用代码。

当系统判断有必要切换模型时，推理路由器会先计算放弃当前 Session 热缓存所增加的额外成本。具体来说，它会比较继续使用当前模型时的 Cached Input 成本，与在候选模型上重新构建全部上下文时的 Uncached Input 成本，然后再把这部分额外费用和整个 Session 已累计的模型切换支出进行比较。

开发者可以通过 Maximum Switching Budget 来定义这种取舍，其基准是"如果整个 Session 一直留在当前模型上，本来会花多少钱"。例如，X-Routing-Max-Switch-Spend-Pct: 20 表示累计模型切换成本最多只能比这个基准高 20%。模型能力判断和切换成本判断是分开的：推理路由器先选出更适合当前任务的模型，再由 Routing Budget 判断，为了切换过去而承担额外输入成本是否值得。

bash 复制代码

curl -i "https://inference.do-ai.run/v1/chat/completions" \
  -H "Authorization: Bearer $MODEL_ACCESS_KEY" \
  -H "Content-Type: application/json" \
  `# X-Model-Affinity is managed by the router if not set explicitly` \
  -H "X-Routing-Max-Switch-Spend-Pct: 20" \
  -d '{
    "model": "router:software-engineering",
    "messages": [
      {"role": "user", "content": "Summarize this in 2 sentences."}
    ]
  }'

结合起来，开发者可以根据需要选择不同程度的控制方式：

如果应用本身已经拥有权威 Session ID 或 Task ID，可以使用 X-Model-Affinity。
如果没有显式 ID，可以让推理路由器根据多轮请求中稳定的 Agent Context 自动判断 Affinity。
可以配置 X-Routing-Max-Switch-Spend-Pct，限制推理路由器为了切换模型最多能够承担多少额外输入成本。

新版 Analyze 页面

我们还更新了 Analyze 页面，让你可以更详细地看到推理路由器是如何做出缓存相关决策的。

在 Router 顶层视图里，可以快速回答这些问题：

整体缓存效率是多少？
有多少请求发生了模型切换？
有多少请求为了保持热缓存而继续留在原模型上？这样做之后整体延迟表现又如何？

从下面这张图，你可以很清晰地看到推理路由器当前运行状态的整体情况。

在此基础上，还可以继续深入查看具体模型和 Task 的行为，更详细地理解流量组成。这有助于发现某些模型上的流量热点、验证当前模型选择策略，并随着时间推移持续调整 Router Preference。

我们还新增了 Cache Efficiency 趋势追踪，可以从 Request 和 Token 两个层面观察缓存效率随时间的变化。这样更容易发现 Cache Regression、理解性能趋势，并验证 Prompt 和 Cache 调优到底带来了什么效果。

把这些视图结合起来之后，团队就可以直接在推理路由器 UI 中，从高层监控进一步深入到针对性的优化。

模型路由应该优先考虑开发者的实际需求

当我们推出 DigitalOcean 推理引擎和推理路由器时，就允许开发者定义 Task、创建 Model Pool，并明确希望优先优化质量、成本还是延迟。推理路由器会先在语义层面判断每次请求属于哪一类任务，再根据这些偏好选择模型。开发者可以直接使用 DigitalOcean Preset------这些是根据我们的评测结果形成、带有明确取向并且持续更新的模型组合------也可以自行定义 Task、Model Pool 和优先级。无论采用哪一种方式，都可以直接使用，不需要重新训练 Router，也不需要在应用端自己编写模型选择逻辑。早期客户 LawVo 表示，在保持用户所需要的准确率、速度和可靠性的同时，推理成本降低了超过 40%*。

这种方法建立在多年针对 Preference-aware Routing 的研究之上。在论文 Arch-Router: Aligning LLM Routing with Human Preferences 中，我们介绍了一款紧凑的 15 亿参数模型，可以把请求映射到开发者定义的 Domain 和 Action，同时还能在不重新训练的情况下加入新模型。我们已经将这个模型以开放权重形式发布，更完整的方法则可以通过 Plano 使用，它是我们采用 Apache License 开源的 AI Proxy 和 Data Plane。这项研究最初来自一个非常简单的观察：Benchmark 很有参考价值，但它不能代表开发者真正关心的目标。

Benchmark 可以参考，但不能直接决定模型怎么选

Benchmark 让我们能够在受控、可重复的条件下比较不同模型。它可以帮助缩小庞大的模型目录，识别不同模型的大致优势，并在应用还没有积累足够真实流量进行自身评测之前，为模型选择提供一个初始依据。因此，它们是 DigitalOcean Preset 很有价值的起点。

但模型的真实表现取决于它所在的应用环境，包括 System Prompt、Tool Definition、Context、Output Constraint、Conversation History，以及什么才算"成功"。只要更换 Agent Harness，不同模型之间的相对排名也可能随之变化。一个在独立 Coding Benchmark 中表现最好的模型，放进一个需要处理大型 Repository、数十个 Tool 和长对话历史的 Coding Agent 里，并不一定还是最佳选择。

类似地，一名开发者在图像生成时可能更喜欢某个模型的视觉风格，而另一个开发者可能更重视 Instruction Following、Tool-call Reliability、Latency 或 Cost。这些偏好都无法从通用排行榜里推断出来。只根据 Benchmark 分数选模型，还算不上真正的智能模型路由。只有系统知道开发者究竟更看重质量、成本、延迟还是其他指标，模型选择才真正有意义。从长期来看，这最终会变成一个 Personalization 问题。但即使是能够理解开发者偏好的系统，如果每次请求都完全独立评估，也依然可能在成本上做出错误决策。

更合理的默认模型、更智能的模型选择，以及更高效的缓存

面对快速增长的推理账单，很多行业最直接的反应往往都是限制用量。但 Coinbase 曾公开表示，Coinbase 员工中有 91% 并没有触及现有 Usage Cap。进一步降低限额，只会制造更多告警和使用阻力，却无法解决真正推动大部分支出的原因。Coinbase 后来转向更便宜的默认模型、Task-aware Routing 和更好的缓存策略。据其公布的数据，这让 LibreChat 的 Cache Hit Rate 从 5% 提升到了 60%。

这三种控制方式会互相增强：

更合理的默认模型：避免所有请求一开始就落到最贵的模型上。
根据任务和开发者关注的指标选择模型：例如质量、成本或延迟。
在模型选择时考虑缓存：尽量保留 Agent Session 已经积累的缓存价值，避免频繁切换模型导致缓存失效。

便宜的默认模型可能达不到复杂任务所要求的质量标准。只根据 Benchmark 做模型选择，也可能无法反映应用自身真实评测结果。缓存感知系统同样不应该在当前模型已经不适合任务时，仅仅因为 Cache 是热的就坚持不切换。没有任何一种技术单独拿出来就足够解决问题。真正的目标，不是最大化 Token 数量，也不是盲目把 Token 单价降到最低，而是在满足每个应用所要求的质量、延迟和可靠性的前提下，最大化每一美元能够获得的有效智能产出。

只有当系统同时理解"你究竟想优化什么"，以及"离开一个正在进行的任务究竟会付出什么代价"时，这样的模型选择机制才真正称得上智能。DigitalOcean 推理路由器提供了相应的控制能力和可观测性，让你能够按照团队真实的工作方式构建自己的智能层。现在就可以创建 Preset 或自定义 Router，并在下一套 Agent 工作流中加入 Model Affinity。本文所有数字均为示例，基于文章发布时可用的价格、模型和配置；第三方数据均按照对应第三方公开信息引用。实际结果和成本节省会因配置、实现方式和使用情况不同而变化，并不构成保证。所有商标均归各自权利人所有，本文不代表任何关联或背书。

*免责声明：以上内容反映的是 LawVo 在自身环境中报告的实际体验，并不代表其他客户一定能够获得相同结果。