多模型切换时，你的上下文正在偷偷"缩水"|上下文|新论文|模型切换|调用|路由

同一句话，OpenAI数出1200个词元，Claude却算出1450个。这不是bug，是每家大模型厂商的"方言"差异。当系统需要在对话中途切换模型时，这种差异会让你的上下文窗口无声崩溃。

Backboard.io联合创始人Jonathan Murray团队最近公开了他们解决这个问题的思路。这件事的有趣之处在于：它暴露了一个被行业长期忽视的底层矛盾——我们以为"词元"是通用货币，实际上每家都在发自己的钞。

词元不是通用语言

大模型厂商的词元切分规则各不相同。同一个英文单词，有的模型拆成3个片段，有的拆成2个；中文差异更大，标点、空格、特殊符号的处理几乎每家都有独特逻辑。

这种差异直接冲击实际业务。假设你在做一个需要长期记忆的客户服务机器人，对话进行到第20轮时系统决定从GPT-4切换到Claude 3——为了节省成本，或者因为前者暂时不可用。

新模型需要完整重读前19轮对话。但Claude的词元计数比OpenAI多出20%左右，原本"刚好满"的上下文窗口，现在直接溢出。结果要么是请求失败，要么是被迫截断早期对话，用户突然发现自己的"记忆"被删除了。

Murray团队最初的想法很直觉：建立一个统一的词元估算器，加个安全余量。实测后发现这条路走不通。余量设太小，切换时照样崩溃；设太大，又会在不该截断的时候提前删减，对话质量无故受损。

「单一估算会在两个方向上都出错」，Murray在文中写道。低估导致失败，高估导致浪费，没有中间地带。

让路由器学会"说方言"

他们的解法是把词元计数做成模型感知型。上下文管理层不再维护一个通用数字，而是针对每个目标模型，用该模型自己的规则重新计算。

具体实现上，系统在路由决策前完成三步：

第一，实时监测对话逼近目标模型窗口边界的进度。不是看"还剩多少词元"，而是看"按这家模型的数法还剩多少"。

第二，智能压缩历史记录。需要删减时，不是机械地从最前面砍掉固定比例，而是根据内容重要性做选择性压缩。早期寒暄可以缩，关键决策节点必须留。

第三，屏蔽切换复杂度。用户端保持对话连贯，系统端处理"每家词元方言不同"的脏活。

这个设计的核心洞察是：词元计数不是静态属性，而是模型相关的动态测量。把它当成通用基础设施，就会在多模型场景下持续踩坑。

路由层的隐藏地基

词元计数问题之所以值得单独拿出来解决，是因为它支撑着一个更大的架构目标：让LLM路由对用户完全透明。

Murray团队正在构建的路由层，允许产品在运行中切换底层模型——基于成本、能力或可用性——而不把这套复杂度暴露给终端体验。模型感知型词元计数是这个能力的地基性组件。没有它，切换就是俄罗斯轮盘赌。

这个方向的行业意义在于：它把"多模型策略"从架构层的妥协方案，变成了产品层的主动设计选择。

过去，选一个模型绑定到底是最省心的做法。现在，系统可以在单次对话里动态组合不同厂商的优势：用Claude处理长上下文分析，切到GPT-4做代码生成，再换到Gemini处理多模态输出——全程用户无感知。

这种灵活性正在从" nice to have"变成" must have"。模型能力迭代速度差异、定价策略波动、区域性可用性限制，都在推动产品架构向"模型无关"演进。

但演进的前提是解决好词元计数这类底层兼容问题。Murray的坦白很说明问题：「我们做这个，这样你就不用做了。」暗示这是每个做多模型系统的团队都会撞上的墙，只是大多数人没公开讨论过。

被低估的工程债务

这个词元计数案例折射出AI基础设施领域的一个普遍现象：表层API的统一性掩盖了底层实现的碎片化。

OpenAI、Anthropic、Google都提供"聊天补全"接口，返回值结构相似，调用方式雷同。但词元切分规则、速率限制计算方式、错误重试策略、工具调用格式——这些真正决定系统稳定性的细节——几乎没有两家一致。

结果是，很多团队在"接入了5家模型API"之后才发现，真正的工程工作量不在于调用本身，而在于处理它们之间的微妙不兼容。词元计数只是最隐蔽的一个，因为错误不会立即暴露，而是在特定长度、特定切换时机才触发。

Backboard.io选择把这个问题组件化、服务化，本质上是在押注一个趋势：未来大多数AI应用都会是多模型的，但不会有太多团队愿意自己维护这套适配层。

这和云计算早期的演变逻辑相似。AWS最初只是"能租服务器"，后来逐渐长出负载均衡、自动扩缩容、多可用区部署——这些能力你也可以自己用开源软件搭，但维护成本让"买服务"成为更理性的选择。

AI基础设施可能正在经历类似的层化过程。最底层是算力和基础模型，中间层是路由、记忆、词元管理等跨模型能力，最上层才是垂直应用。Murray团队卡位的是中间层，而词元计数是他们验证这个层位价值的首个切口。

一个值得观察的信号是：如果更多团队开始公开讨论"我们如何解决X模型和Y模型的Z不兼容问题"，说明多模型架构正在从先锋实验变成主流实践。届时，专门解决这类兼容性问题的中间件价值会快速上升。

反之，如果行业迅速收敛到某一家模型的生态主导，这类基础设施的投资回报就会大打折扣。目前看，前者概率更高——没有一家模型在所有场景都领先，而成本压力正在加速模型切换的常态化。

给技术决策者的参考

如果你正在评估多模型策略，Murray的案例提供了几个检查点：

你的上下文管理系统是否硬编码了单一模型的词元计算规则？如果是，切换模型时准备如何处理计数差异？

历史对话的截断策略是固定比例，还是内容感知？后者需要额外的摘要或重要性评分机制，但能在模型切换时保留更多有效信息。

词元计数错误是被当作可接受的边缘情况处理，还是有专门的降级路径？前者在toC场景可能勉强过关，toB场景的客户不会接受"偶尔丢记忆"。

最后，这个组件是自己维护还是采购？判断标准不是"能不能做"，而是"是不是核心差异化能力"。对大多数产品团队，词元计数的正确性属于"必须对但不必自己做"的范畴。

Murray在文末用了个笑脸表情：「我们做这个，这样你就不用做了。」这句话的潜台词是，他们已经踩过坑、付过学费，现在把这个能力打包成服务。对正在做多模型架构的团队，这既是一个可选项，也是一个警示——如果你没遇到这个词元计数问题，可能只是因为还没切换到足够多的模型，或者还没在足够长的对话里测试边界情况。