模型路由与提示预处理：控制大语言模型成本、提升令牌使用效果的新方法！

大语言模型使用成本问题凸显

并非所有提示都是相同的。通过将简单的提示路由到更便宜的模型，能在令牌成本上节省一大笔钱。图片来源：Shutterstock Gen AI

作为资深的 Delphi 开发者，对当年和 Visual Basic 开发者之间的“语言战争”记忆犹新。Delphi 早期代号是“VBK”，即“VB 杀手”，这引起 VB 社区不满，他们会到 Delphi 论坛挑起争端，而 Delphi 开发者也会反击，引发激烈口水战。那些日子令人怀念。

如今，讨论更上层次——哪种模型更适合用于编码？虽现在争论没当年 VB 和 Delphi 之争激烈，但大家各有看法。企业在为团队选择模型前，会对不同模型进行评估，大多数团队已选定常用的一系列模型。

有时，与 Claude 或 Codex 聊天体验欠佳。不久后，像 GStack 和 Superpowers 这样的脚手架工具开始为与大语言模型（LLM）交互提供基础支持，即在提示到达模型本身之前，对其进行基本处理。这些工具有助于建立有用的上下文，就像在“原始提示”之上增加一层。上下文工程是在聊天界面之上添加的第一层，也是最常见的一层。

选定模型和工具后，大家追求令牌使用最大化。但账单寄来时，管理者不高兴了。随着成本飙升，领导层担心钱没花在刀刃上。

模型路由：下一层解决方案

就像汇编语言和手动调整寄存器被编译器和结构化语言取代，进而发展出框架和库，最近又出现大语言模型和提示工程一样，开发者和管理者开始意识到，有更好方法管理大语言模型使用成本。但自然地，刚弄清楚事情运作方式，新的一层就会出现，让辛苦积累的知识过时。显然，仅能用英语编写代码不足以阻止下一次抽象出现。所以，又一层抽象出现了。（世事皆如此。）因此，模型路由成为让每一分令牌成本都发挥最大价值的最新方法。

其理念是，并非所有提示都需要同等处理能力。向 Claude 提出的问题，并非都需要前沿模型深度思考。模型路由器可以分析提示内容，决定哪个模型最适合回答该提示，并将查询导向该模型。也许简单请求更适合用旧模型处理，也许代码审查用专门为此设计的模型效果更好。模型路由可以提高令牌使用效率。如今使用 Claude Code 时，必须为整个会话选择一个模型，若想用顶级模型，无论最终做什么都得为此付费。而模型路由器可以让灵活选择模型，从而控制成本。像 Coinbase 这样的公司，在令牌使用量增加的同时，AI 支出却减少了一半。

从令牌最大化到令牌匹配

大语言模型不断发展，功能越来越强大，也越来越专业化。将提示路由到既适合任务又具有成本效益的模型，是提高令牌使用效果的关键。目前，团队是手动进行这项工作的，但未来，人工智能本身将成为做出此类决策的最佳方式。例如，Claude Code Router 可以根据每个提示所需的工作类型，将其路由到多个流行模型中的任意一个，而且它是开源的。

接下来出现的将是提示预处理。可以努力编写好的提示，但人工智能本身可以对提问进行优化。提示工程中最好的技巧之一，就是告诉大语言模型“提出我没问但应该问的问题”。不难想象，未来写出一个提示，人工智能会帮助澄清、完善它，然后将其路由到最合适、最具成本效益的模型来获取答案。将不再需要选择特定的大语言模型提供商，而是可以专注于明确表达自己的需求。所以，别再为特定模型手工编写提示了，让即将出现的模型路由器和提示预处理器为完成这些繁琐的工作吧。人工智能、开发工具、生成式 AI、软件开发该何去何从呢？