Tokenless让模型自己换挡

Tokenless 把模型选择交给路由器

**Tokenless 于近日推出自动模型路由服务，并在 Hacker News 的 Launch HN 板块亮相，其核心卖点是根据任务自动切换模型，以更低成本完成 AI 请求。**其发布标题标注为 YC S26，意味着这是一家进入早期产品验证阶段的基础设施创业公司，而不是已经拥有完整企业产品线的成熟平台。

**Tokenless 是一个位于 AI 应用与大模型之间的自动路由层。**开发者把原本发给固定模型的请求交给 Tokenless，系统先判断任务类型、复杂度和质量要求，再选择更合适的模型执行，而不是让所有请求都默认调用最强、也通常最贵的模型。

这套思路并不复杂：摘要、分类、格式转换等任务，大多数时候不需要顶级推理模型；复杂代码修改、数学推理和多步骤规划，则不能只看价格。Tokenless 想做的，就是像汽车变速箱一样，根据路况自动换挡——平路用低挡位成本模型，高负载时再切到更强的模型。

**截至 2026 年 7 月 29 日，Tokenless 尚未在公开发布材料中给出完整模型名单、正式价格表或可复现的成本基准。**这意味着它目前最值得关注的是产品方向，而不是某个已经被充分验证的节省比例。对于一家路由服务来说，“能自动切换”只是起点，真正决定价值的是选错模型的概率、额外延迟以及质量回退机制。

它解决的不是接入，而是每次该用谁

**自动模型路由是根据请求内容和业务约束，为每一次调用动态选择模型的调度机制。**它与传统的统一模型接口并不是一回事：后者主要解决不同厂商接口格式不一致的问题，最终使用哪个模型仍由开发者手动指定；前者则要替开发者做出选择。

**模型路由目前大致可以分为四类。**第一类是手动路由，业务代码根据任务标签写死模型；第二类是规则路由，例如输入超过一定长度就切换长上下文模型；第三类是故障路由，在主模型超时或限流时切到备用模型；第四类才是 Tokenless 主打的语义路由，即分析请求本身，判断它需要多强的模型。

| 路由方式 | 模型如何选择 | 主要价值 | 主要问题 | 成本形态 | |---|---|---|---|---| | Tokenless 自动路由 | 根据任务自动判断并切换 | 减少人工维护，优化单次请求成本 | 路由精度、延迟和定价尚待验证 | 官方公开材料暂未披露完整价格 | | 统一模型网关 | 开发者手动指定模型 | 统一接口、日志与账单 | 不替开发者判断任务难度 | 通常按调用量或平台套餐计费 | | 业务规则路由 | 按长度、标签、用户等级等规则选择 | 可解释、容易控制 | 规则会快速膨胀，难跟上模型变化 | 自研成本加模型调用成本 | | RouteLLM 等学习型路由 | 用分类器预测强弱模型需求 | 可以围绕质量与价格做优化 | 需要评测集、训练和持续校准 | 软件可自托管，基础设施另计 | | LiteLLM 等网关式故障切换 | 按配置执行重试、降级和备用链 | 提升稳定性，减少供应商单点故障 | 故障切换不等于任务级智能选择 | 软件可自托管，运维成本另计 |

**Tokenless 的差异点应该是把“模型选择”做成默认能力，而不是只提供模型列表。**如果用户还需要提前知道哪一个模型最适合代码、哪一个适合摘要，再自己编写规则，那么产品只是另一个模型网关，并没有真正消除选择负担。

成本为什么可能降下来

**AI 应用的成本浪费，往往来自用高价模型处理大量低难度请求。**一个客服系统可能同时包含意图分类、知识检索改写、答案生成、合规检查和会话摘要，其中只有最终答案和少部分复杂问题需要强模型，其余步骤完全可以交给轻量模型。

**路由节省的上限由强弱模型价差和简单任务占比共同决定。**下面用一组假设数据说明这笔账，数字不代表 Tokenless 官方报价，也不对应某个特定模型：

• 假设强模型输入价格为每百万 token 3 美元，输出价格为每百万 token 15 美元；
• 假设轻量模型输入价格为每百万 token 0.3 美元，输出价格为每百万 token 1.2 美元；
• 每次请求平均包含 800 个输入 token 和 200 个输出 token；
• 每月调用量为 100 万次，其中 70% 属于简单任务。

**如果全部请求都使用强模型，月度模型成本约为 5400 美元。**单次请求的输入成本为 0.0024 美元，输出成本为 0.003 美元，合计 0.0054 美元。

**如果 70% 的请求切换到轻量模型，月度模型成本会降至约 1956 美元。**其中 70 万次轻量调用约花费 336 美元，30 万次强模型调用约花费 1620 美元，相比全量使用强模型减少 3444 美元，理论降幅为 63.8%。

**误判和重试会直接侵蚀路由带来的节省。**如果被分配到轻量模型的请求中有 5% 质量不达标，并且全部需要重新调用强模型，那么会增加约 189 美元成本，月度支出变为 2145 美元，实际降幅从 63.8% 收窄至约 60.3%。这还没有计算路由服务费、评估成本和额外延迟。

自动路由真正优化的不是 token 数量，而是每个 token 使用哪一种模型计算。

**“Tokenless”这个名字不应被理解为模型调用不再消耗 token。**大模型仍然按照输入、输出、缓存或推理资源计费，路由器只是尽量避免把昂贵 token 用在低价值步骤上。对于长上下文 Agent，历史消息压缩、工具描述裁剪和缓存仍然同样重要，单靠换模型无法解决上下文不断膨胀的问题。

真正困难的是判断任务，而不是调用模型

**路由器最难解决的问题是如何在执行前预测一次请求需要多强的模型。**输入长度是一个信号，但不是可靠答案：一段 5000 字的新闻摘要可能很简单，而一句只有十几个字的数学证明题可能需要长时间推理。

**一个可用的路由系统至少需要同时观察五类特征。**这些特征包括任务类型、提示词复杂度、上下文长度、结构化输出要求，以及工具调用或视觉输入等能力约束。对于生产环境，它还要结合用户等级、延迟预算、单次成本上限和数据合规区域。

**能力约束必须先于价格排序。**如果请求包含图片，候选模型必须支持视觉输入；如果业务依赖严格的 JSON Schema，路由器就不能选择结构化输出稳定性不足的模型；如果 Agent 需要调用工具，还要验证模型能否可靠地产生函数参数。只按价格挑最便宜模型，很容易把“成本优化”变成“失败率优化”。

**质量判断也不能只依赖模型公开跑分。**MMLU、代码测试集或数学基准反映的是通用能力，却不能直接代表企业内部的工单分类、商品属性抽取和合同审查效果。成熟路由器需要基于真实业务评测集，持续记录不同模型在不同任务上的成功率。

**反馈闭环是 Tokenless 能否形成壁垒的关键。**理想状态下，系统需要知道用户是否重试、输出是否通过校验、工具调用是否成功，以及结果是否被人工接受，再据此更新路由策略。否则模型选择只能依赖静态标签和厂商宣传数据，很难随着模型更新而自动改善。

延迟可能比价格更早暴露问题

**自动路由会在正式模型调用之前增加一次决策过程。**如果路由器本身要调用另一个大模型分析提示词，用户就会承担额外首字延迟和额外调用成本；如果使用本地小分类器或规则系统，速度更快，但对复杂任务的识别能力可能下降。

**路由决策最好控制在总请求延迟的较小比例内。**例如原始模型首字延迟为 800 毫秒，路由判断增加 50 毫秒，额外开销约为 6.25%；如果路由过程花费 500 毫秒，总等待时间就会增加 62.5%，对于实时聊天、语音交互和代码补全已经很难接受。

**投机式并行是降低路由等待的一种办法。**系统可以在判断任务的同时，先向默认轻量模型发起请求；一旦发现任务复杂，再终止或升级到强模型。不过这种方案会产生被取消请求的计算成本，也需要模型服务支持及时中止。

**故障回退则是自动路由必须补上的另一层能力。**一个模型即使价格最低、质量最高，也可能遇到限流、区域故障或延迟抖动。生产系统需要在超时后切换到同等级备选模型，而不是简单降到更便宜但无法完成任务的模型。

Tokenless 面对的竞争并不轻松

**模型路由已经从新概念变成 AI 基础设施的拥挤赛道。**开源社区有 RouteLLM 这类强弱模型路由框架，也有 LiteLLM 这类统一网关；大型云平台正在把多模型管理、配额控制和故障切换做进现有产品，部分团队则直接在业务层编写路由规则。

**Tokenless 的直接竞争者并不是某一个模型，而是企业自建路由的成本。**对小团队来说，接入托管服务比维护模型价格表、评测集和 fallback 逻辑更方便；对调用量足够大的企业来说，路由策略本身会涉及核心业务数据和成本结构，自托管的吸引力反而更高。

**Tokenless 必须用数据证明它比固定规则更聪明。**最有说服力的指标不是“支持多少模型”，而是在同一批真实任务上，以相同成功率为约束，平均成本降低多少、P95 延迟增加多少、路由误判率是多少。若没有这三组数据，开发者很难判断节省来自智能路由，还是单纯把更多请求塞给便宜模型。

| 关键指标 | 开发者应该关注什么 | 合理的披露方式 | |---|---|---| | 质量保持率 | 路由后任务成功率是否低于固定强模型 | 使用同一业务测试集对照 | | 平均成本 | 每个成功任务而非每次请求的成本 | 计入重试、失败和路由费用 | | 路由延迟 | 决策增加了多少首字等待时间 | 公布 P50、P95 和 P99 | | 升级率 | 轻量模型输出有多少需要强模型重做 | 按任务类型分别统计 | | 可解释性 | 为什么某次请求被送到某个模型 | 提供路由原因和策略日志 | | 数据治理 | 提示词是否被存储或用于训练 | 明确保留周期与关闭选项 |

数据安全是托管路由绕不开的一关

**托管路由服务会天然接触完整提示词、上下文和模型输出。**这意味着 Tokenless 不只是一个流量调度器，也可能成为企业数据链路中的新增处理方。对于代码、医疗记录、客户工单和内部文档，数据是否落盘、保留多久、流向哪些模型厂商都需要明确。

**企业用户需要能够限制候选模型和数据区域。**一个通用路由器也许认为某个模型最便宜，但企业可能因为合同、合规或数据驻留要求而不能使用它。可配置白名单、区域约束和零数据保留策略，通常比“自动选择所有模型”更重要。

**可观测性决定了路由器能否进入生产环境。**开发者至少需要看到每次请求选择了哪个模型、选择原因、输入输出 token、调用延迟、失败原因和重试链路。否则成本虽然可能下降，排障难度却会上升。

现阶段更适合谁

**Tokenless 现阶段最适合任务类型多、调用量大且对单一模型没有强依赖的 AI 产品。**典型场景包括客服自动化、内容审核、批量文档处理、搜索查询改写和多步骤 Agent，这些产品往往同时存在大量简单步骤和少量复杂推理步骤。

**代码补全、语音对话和强风格内容生成则需要更谨慎地测试。**代码补全对延迟非常敏感，语音对话要求稳定的实时响应，品牌内容则可能依赖某个模型的固定文风；频繁切换模型可能带来输出风格和行为不一致。

**小规模产品也不一定能从自动路由中获得明显收益。**如果每月模型成本只有几十美元，引入新服务、评估质量和处理数据合规的工程投入可能高于节省金额。只有当模型费用、调用规模或多模型维护成本达到一定水平，路由层才会从“有趣功能”变成“必要设施”。

判断：方向成立，但 Tokenless 还要补齐证据

**Tokenless 抓住了 2026 年 AI 应用成本结构中的真实矛盾。**模型数量越来越多，同一个模型很难同时在价格、速度、代码、推理、多模态和长上下文上占优，让每个团队手工维护模型映射表并不经济。

**自动路由的价值也比单纯统一模型接口更进一步。**统一接口只是让切换变得容易，自动路由则试图决定什么时候切换；前者解决工程兼容，后者直接介入产品质量与成本，是一个更难但也更有价值的位置。

**不过，Tokenless 当前仍需要公开基准、价格和数据策略来证明产品成熟度。**如果它能在相同任务成功率下，把每个成功任务的综合成本稳定降低 30% 以上，同时把额外 P95 延迟控制在 100 毫秒以内，这会是一个很有吸引力的基础设施产品；如果节省主要来自激进使用小模型，并伴随较高重试率，那么开发者用几条业务规则也能得到类似结果。

**最终决定 Tokenless 成败的不是它能连接多少模型，而是它能否持续比开发者更懂该选哪个模型。**模型路由不会让 token 消失，但如果判断足够准确，它确实可能让昂贵模型只出现在真正需要它的地方。

参考来源

• RouteLLM GitHub 仓库：由 LMSYS 推出的开源大模型路由框架，可用于理解强弱模型动态选择及其评测方法。
• LiteLLM GitHub 仓库：开源 LLM 网关项目，覆盖多模型统一调用、预算管理、重试和故障切换等能力。
• 掘金：多模型统一管理与按任务路由实践：介绍多模型接入、任务分级、成本优化和备用模型切换的工程背景。