LLM路由分层实战：auto是成本控制，不是质量选项

运营一个对接50多个模型的OpenAI兼容聊天端点时，开发者往往会被一个看似便利的功能带偏：auto路由。本文作者在构建自己的LLM Chat API过程中发现，auto本质上是一个披着便利外衣的成本控制机制，而非质量决策。

从直连到分层：一个定价问题浮出水面

最初的设计很简单：模型名、价格、直通。但当作者自己的AI代理在琐碎的“这是PDF吗”之类的分类调用上消耗大量token时，问题出现了——他正在按前沿模型的价格支付这些简单问题。

于是，三层路由应运而生：eco面向廉价快速模型，premium面向前沿模型，auto则按请求自动选择。真正的意外不在于分层本身，而在于auto层实际需要知道什么。

auto路由的核心：一个小型决策引擎

路由不能只看提示长度。一个40 token的请求可能需要前沿模型（“解释这个定理”），而一个4000 token的请求可能只是纯提取（“给我合同里的日期”）。作者构建了一个微型分类器：任务类型启发式（摘要/提取/代码/推理/聊天）、长度带以及按调用方覆盖。auto层现在是一个小型决策引擎，而不是负载均衡器。

任务类型启发式指的是一种基于规则或轻量分类器的预判机制，它不依赖模型理解语义，而是通过关键词、句式结构或调用上下文来推断请求意图。例如，出现“总结”“摘要”关键词即归为摘要任务，出现“提取”“列出”归为提取任务。这类启发式通常由正则表达式、n-gram匹配或极小的逻辑回归模型实现，开销在微秒到毫秒级，远低于一次模型调用。

长度带是将请求的token数划分为若干离散区间（如<50、50-500、>500），而非连续值。这样做的原因是路由决策对长度的敏感度是阶跃式的：极短请求可能是简单分类，也可能是高密度推理问题，需要结合任务类型联合判断；而中长请求往往对应文档处理类任务。离散化也便于人工审核和规则调整。

意料之外的失败模式：重试导致的成本倒挂

eco模型虽然快，但在边缘案例上有时会出错，导致代理盲目重试——一次eco调用加一次premium回退的成本，比直接调用premium还高。作者加入了置信度阈值：如果eco模型的输出看起来不确定（开放问题得到短答案、模棱两可的措辞），立即升级，而不是让代理盲目重试。

置信度阈值是一种轻量级的不确定性度量，通常不需要额外模型推理。常见实现包括：检查输出长度是否远低于同任务类型的期望值（开放问题得到极短答案是典型信号）、检测输出中是否包含“我不确定”“可能”等模糊措辞、或比较多个采样结果的一致性。阈值设定需要在漏判（该升级却没升级，导致代理重试）和误判（不该升级却升级，浪费premium额度）之间权衡。

盲目重试的成本问题在于，代理框架通常不会区分“模型能力不足”和“临时错误”，当eco模型返回低质量结果时，代理会将其视为失败并触发重试逻辑，而重试往往直接跳到premium层。这意味着一轮子任务实际上消耗了eco加premium两次调用。更糟的是，如果代理对上一步的失败没有记忆，可能反复在eco和premium之间震荡，产生指数级成本放大。

直连与路由的权衡：集成税 vs 路由税

与直接调用提供商相比，作者节省了集成税（一个API密钥、一个基础URL、一个计费关系），但增加了路由税（分类器在每个请求上运行，约2毫秒）。对于他自己的代理，这值得；对于已经知道想要哪个模型的开发者，分层只是噪音——他们仍然可以传递明确的模型名，完全绕过auto。

集成税指的是开发者为对接每一个模型提供商所付出的工程成本：各自的API密钥管理、请求/响应格式差异、错误码映射、计费对账、限流策略、SDK维护等。当模型数量达到50+时，集成税会迅速膨胀，且每当有模型退役或新模型上线都需要重复投入。OpenAI兼容端点通过统一接口将这些异构性封装在服务端，让开发者只需维护一份客户端代码。

路由税则是为“统一接口”付出的代价：每个请求都要经过分类器判断，产生额外延迟（本文约2毫秒）和计算开销。此外，路由层还是一个潜在的单点故障和可观测性盲区——如果分类器误判，问题会以“模型质量下降”的形式出现，而非明确的错误。路由税通常是固定且可预测的，而集成税随模型数量线性增长，这正是分层路由在管理大量模型时更具经济性的原因。

核心教训：为“不知道需要什么”的代理设计

“auto”听起来像便利功能，实践中却是成本控制功能穿着便利的外衣。如果你在构建代理基础设施，请为那些不知道自己需要什么的代理设计——因为大多数代理在大多数时候都是如此。

该服务打包为OpenAI兼容的/v1/chat/completions端点，模型列表和费率可在/tools/llm_chat/models查看。