我认识的一位开发者上个月拉出了推理账单，却解释不清为什么修改配置文件中的一个拼写错误的成本竟然几乎和花了整个下午构建的功能相当。两个请求都经过了同一个编码代理。两者都调用了同一个模型。这正是该代理的设计方式：一个模型、一个 API 密钥、每 token 一个价格，无论它面前的任务是琐碎的还是真正艰难的。
没有人会坐下来专门决定这一点。之所以会这样，是因为选择单一模型很容易，而构建更智能的方案需要大多数团队没有时间投入的工作。于是，快速查询和简短摘要最终为那些其实可以由更便宜的模型同样胜任的任务支付了前沿价格。如果在一个会进行数百次工具调用的代理上反复发生，或者同时运行十几个代理，浪费就会迅速积累。
Kimi K3 是 Moonshot AI 在 2026 年 7 月发布的 2.8 万亿参数开放权重模型，这里可以把它放在 Claude 旁边作为参考。它不是竞争对手，而是合作伙伴：它们在不同方面各有优势，定价也不同，正是这种差异使得路由变得值得进行。本文将讲解手写路由逻辑为何会失效、Kimi K3 和 Claude 各自实际上擅长什么，以及如何使用 DigitalOcean 的 Inference Router 在它们之间进行真实的路由。
M.A.R.S. 目前仅通过邀请制的私有预览提供。点此申请访问。
硬编码路由的问题
显而易见的解决办法是自己构建路由。根据提示长度做 if/else。进行关键字检查。或者调用一个读取请求并决定去向的 LLM。正是这个最后的选项让大多数团队最终陷入其中，也是事情变得混乱的地方。
假设你使用类似 Haiku 的小模型在发送请求之前对每个请求进行分类。那么你将为每个请求永久地支付两次调用而不是一次的费用。而且，通用模型把分类当作副业来做并不擅长。随着流量变化或你引入新模型，它的准确度会下降，而你需要自行发现并修复。实际上，你已经构建了一个第二个应用，它唯一的任务就是决定哪个模型来处理第一个请求。
相反，基础设施层的路由才是可行的做法：它读取请求，决定需要哪个模型，然后将请求发送过去，而你的应用代码无需知晓或关心。这是一项狭窄的工作，值得交给专门为此构建的模型来处理。
两种模型，两种不同的任务
Claude 是一个封闭模型。Anthropic 负责构建、部署并端到端调优，您为此付费：行为稳定、推理强劲、在长而复杂的任务中工具使用可靠。
Kimi K3 是另一种工具。它是开放权重的，总参数达 2.78 万亿，拥有 896 个路由专家，融合了 Kimi Delta Attention 和 Gated Multi-head Latent Attention 层，上下文窗口最高可达 100 万个 token，并原生支持视觉。Moonshot 将其设计为可运行数小时：自主编码、多步研究、能够在数百次工具调用中不丢线的代理工作。在编码和代理基准测试中，它几乎击败市场上所有其他模型，仅落后于少数真正的前沿模型。由于权重开放，服务提供商可以以比同等规模封闭模型低得多的成本提供它。
两者都不是绝对的赢家。当任务需要真正的深度且您愿意付费时，会选择 Claude；当任务较长、工具密集或仅是高吞吐量，而前沿定价会是浪费时，会选择 Kimi K3。路由器的任务是逐请求地将这两者区分开来。
它们之间的价格差异正是此事重要的根本原因。开放权重的模型由任何想要以相同权重竞争价格的提供商服务。封闭模型的价格由单一供应商决定。通过代理发送足够流量时，将大部分流量路由到更便宜的模型与全部路由到更昂贵的模型之间的差异会体现在您的发票上，而不仅仅出现在基准表中。
DigitalOcean 的推理路由器如何实现这一点
推理路由器 位于 DigitalOcean 模型目录之前，根据您定义的成本、延迟或其他策略，将每个请求发送到您自定义池中的最佳模型。这只是对您代码的小改动：不再直接指定模型名称，而是指定带有 router: 前缀的路由器名称，路由器会为您选择合适的模型。
它建立在 Plano 之上，这是一种为这类工作而设计的开源代理。值得关注的是，决定请求去向的过程根本不经过通用大语言模型。它通过 Plano-Orchestrator 运行，这是 DigitalOcean 专门为路由训练的模型，提供 4B 和 30B 两个版本。在 DigitalOcean 自行测试中，覆盖近 2,000 条消息和 605 次对话，30B 版本平均准确率达到 87.84%，领先于 GPT-5.1（86.93%）和 Claude Sonnet 4.5（86.11%），且决策耗时约 200 毫秒。您无需支付前沿模型的费用仅仅为了决定由哪个模型来回答。
路由器由任务组成。每个任务包含一个名称、一个用于与对话匹配的纯语言描述、路由模型允许选择的模型池，以及一种策略：最便宜、最快，或您自己设定的固定顺序。任何不匹配的内容会回退到您配置的后备模型，按顺序尝试，以确保请求永不卡住。
构建一个汇集 Kimi K3 和 Claude 的路由器
这是一个包含两个任务的路由器：一个用于短时、高吞吐且不需要太多推理的工作，另一个用于两个模型都能处理的多步骤编码和分析工作，此时您更倾向于让路由器选择更快或更便宜的选项，而不是硬编码一个胜者。
curl -X POST "https://api.digitalocean.com/v2/gen-ai/models/routers" \
-H "Authorization: Bearer $DIGITALOCEAN_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"name": "kimi-claude-router",
"description": "Routes quick lookups and long-running agentic coding work across Kimi K3 and Claude",
"policies": [
{
"custom_task": {
"name": "quick_turnaround",
"description": "Short questions, summaries, quick lookups, or single-step answers"
},
"models": ["kimi-k3", "anthropic-claude-sonnet-4.6"],
"selection_policy": { "prefer": "cheapest" }
},
{
"custom_task": {
"name": "agentic_coding",
"description": "Multi-step coding tasks, long-horizon tool use, or deep codebase analysis"
},
"models": ["anthropic-claude-opus-4.6", "kimi-k3"],
"selection_policy": { "prefer": "fastest" }
}
],
"fallback_models": ["kimi-k3"]
}'
任务名称和描述不仅仅是标签，它们是路由模型读取的内容，用来决定请求应该发往何处。如果描述写得太宽泛，比如“处理编码相关的事情”，它会匹配所有请求；如果太窄，则会漏掉本应匹配的请求。保持描述足够具体以区分任务，你就能获得比默认设置更好的路由效果。
路由器一旦存在，使用它只需对你已经在进行的任何调用做一行修改：
curl https://inference.do-ai.run/v1/chat/completions \
-H "Authorization: Bearer $MODEL_ACCESS_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "router:kimi-claude-router",
"messages": [
{"role": "user", "content": "What does a KeyError mean in Python?"}
]
}'
这个问题很短且只需一步，所以它应该落在 quick_turnaround 中，并在此时选择 Kimi K3 或 Claude Sonnet 中费用更低的那个，因为费用是实时检查的，而不是一次性设定的。响应会告诉你确切发生了什么：model 字段显示哪个模型回答了问题，而 x-model-router-selected-route 头显示它匹配了哪个任务。
对于多轮代理会话，您通常希望同一个模型从头到尾处理任务。像 Anthropic 这样的提供商会缓存对话的早期部分，以便重复请求的处理更便宜、更快，但该缓存与构建它的特定模型绑定。如果在对话中途切换模型，您就会丢失该缓存，因此您希望路由器坚持使用一个模型，而不是在每轮都重新考虑。稳定的 X-Model-Affinity 头部（即您应用已经跟踪的会话或任务 ID）可以将工作保持在同一个模型上。如果您仍希望在数字明显支持时路由器能够在会话中途切换，X-Routing-Max-Switch-Spend-Pct 将限制其为进行切换所能额外花费的比例。默认情况下，这个上限是保持不变的成本的 20%。
验证其是否真的有效
在您将其用于生产环境之前，可以使用 DigitalOcean 的 Playground 将路由器与单个模型在相同的提示上进行比较。它会并排显示每个模型的成本和延迟。Evals 则进一步深入：在带标签的数据集上运行路由器，获取正确性和完整性得分，从而在上线前了解路由器在质量方面的表现，而不是事后才知。
一旦上线，Analyze 仪表盘会向您展示实际情况：请求实际上匹配您的任务的频率与落回到备用模型的频率；流量在 Kimi K3 和 Claude 之间的分配情况；缓存上下文被重复使用的频率；以及按模型和任务细分的延迟。如果 agentic_coding 请求有 90% 的时间落在 Claude 上，即使 Kimi K3 也在池中，您会在模型分布图中看到这一点。这通常表明您的任务描述需要改进，而不是 Kimi K3 无法完成任务。
在得出结论之前，请给它一到两周的时间。价格和延迟会波动：提供商的响应时间可能会在一天内因负载而波动两到三倍，这就是为什么路由器会检查实时数据，而不是仅依赖一次设定的规则。随着流量的变化，路由器可能会失去平衡，而回退率的上升通常是第一个线索。
结论
其实这根本不是 Kimi K3 与 Claude 的二选一问题。如果只选其中一个，你仍然需要为每项任务支付同样的单一费用，只是费用不同罢了。如果把它们放在路由器后面，则在需要深度时使用 Claude，在需要大量处理但不需要深度时使用 Kimi K3。随着定价变化或新模型发布，你只需更新路由器的配置，而无需修改应用代码。这就是这里的真正优势：不是哪个模型更好，而是你不必再被迫只选其一。
参考文献
- 如何使用推理路由器，DigitalOcean 文档
- 我们如何构建 DigitalOcean 推理路由器，DigitalOcean 博客
- 幕后：服务 Kimi K3，DigitalOcean 博客
- DigitalOcean 推理支持的模型，DigitalOcean 文档
- 无服务器推理 API 参考，DigitalOcean 文档
- 现已上线：Anthropic Claude Opus 4.6 在 DigitalOcean 的 Agentic 推理云上，DigitalOcean 博客
- Kimi K3，Moonshot AI（Hugging Face 模型卡）
- 什么是 Moonshot AI 的 Kimi K3 模型以及它为何引起关注？，Bloomberg
——
