Multi-LLM上下文管理的隐藏挑战

Source: Dev.to

为什么在跨供应商构建时，令牌计数并不是一个已解决的问题

构建跨多个 LLM 供应商的 AI 产品会遇到一个大多数开发者在真正碰到之前并未预料到的挑战：上下文窗口并不兼容。

表面上看，在多 LLM 系统中管理上下文似乎很直接。你只需跟踪对话的长度，必要时进行裁剪，然后继续。但实际上，这要复杂得多——如果你在 OpenAI、Anthropic、Google、Cohere 或 xAI 等供应商之间路由请求，就会出现根本性的不匹配，可能以微妙的方式导致产品出错。

令牌化问题

每个主要的 LLM 供应商都有自己的分词器。这些分词器的计数方式并不一致。同一段文字在不同模型上会产生不同的令牌数量，差异通常在 10%–20% 之间，有时甚至更大。

这在实际中的含义是：在某个模型的上下文窗口内能够舒适容纳的对话，可能在另一个模型中悄然溢出。一个发送给 OpenAI 的提示可能计为 1,200 个令牌，而相同的提示发送给 Claude 时可能计为 1,450 个。这个差距是关键。

出错的地方

失败模式往往出现在边界上。当你在对话进行中切换供应商时，新的模型必须读取完整的先前上下文。如果你的上下文管理层是基于之前模型的分词器校准的，那么新模型可能会看到已经接近或超过限制的上下文——在它甚至开始响应新内容之前。

这会产生三种常见的失败模式：

• 意外的上下文窗口溢出： 之前正常的对话现在突破了限制。
• 不一致的截断： 不同模型在不同位置截断，导致模型实际看到的先前上下文发生变化。
• 路由失败： 由于系统使用的数字与模型实际使用的数字不匹配，导致不可预测的错误。

为什么简单估算会失效

直觉上会想维护一个带有宽裕安全边际的“令牌估算”。问题在于，你需要的安全边际会因供应商、模型版本以及内容类型（代码的分词方式与散文不同）而异。为一种使用场景校准的边际，要么对另一种场景太紧导致失败，要么太宽松导致不必要的截断，进而降低对话质量。

解决方案：供应商感知的令牌计数

一个稳健的多 LLM 上下文管理层会对每个供应商进行独立的令牌计数。它不再维护单一的估算，而是按照实际目标模型的方式对每个提示进行计数。路由层使用这些针对不同供应商的计数结果，在请求发送之前做出决策。

这样系统就能提前预知上下文限制：它知道对话何时接近上限，能够针对接收请求的具体模型进行裁剪或压缩历史记录，避免因令牌计数错误而产生的费用和失败惊喜。

最终的效果就是用户应当看到的：无论由哪个模型提供服务，都能获得流畅的对话体验。 “每个模型说的都是稍有差异的令牌语言” 这一复杂性被封装在基础设施层内部，对使用产品的用户而言是透明的。

Rob Imbeault – Apr 17, 2026