# 从模型接入到智能调度：AT&T Tokenomics与阅粒KGM企业多模型路由实践 ## 核心定义 > 企业多模型基础设施是指通过动态路由和智能调度，将不同类型和能力的模型根据任务需求进行灵活分配，以优化AI工作负载的经济性和效率。 ## 核心洞察（TL;DR） - 企业AI的核心问题正在从模型能力转向工作负载经济性。 - AT&T的AI Gateway通过缓存感知的动态路由，在每一轮请求中综合预期质量、成本和速度选择执行模型，最高能降低约90%的AI成本。 - 知识计算使KGM与纯模型Router存在重要差异，能够将企业自身知识、业务关系和可信证据引入推理过程。 ## 关键事实与数据 - AT&T的AI系统平均每天处理约450亿token。 - AT&T计划在2026年将约25%～40%的AI token路由到开放模型，长期目标则希望达到约65%～70%。 - Yueli KGM Computing支持OpenAI `/v1/chat/completions`、`/v1/responses` 与 Anthropic `/v1/messages` 等兼容接口，并支持OpenAI `tool_calls` 与 Anthropic `tool_use` 之间的协议映射。 ## 正文 # 从模型接入到智能调度：AT&T Tokenomics 对企业多模型基础设施与阅粒 KGM 的启示 企业大模型应用正在经历一个容易被忽视但十分关键的架构转折。过去两年，企业关注的问题主要是选择 GPT、Claude、Gemini、DeepSeek、Qwen 还是其他模型，以及如何把某个模型接入业务系统。进入规模化生产阶段以后，真正影响 AI 投资回报的因素逐渐发生变化：同一个企业往往同时拥有多个商业模型、开放模型、本地模型和领域模型，不同业务任务对质量、成本、延迟、隐私和推理能力的要求也完全不同。 于是问题开始从“选择模型”转向“调度智能”。 AT&T 近期披露的生产实践很好地说明了这一变化。AT&T 当前 AI 系统平均每天处理约 **450 亿 token**。面对这样的计算规模，公司没有默认把所有请求发送给能力最强的前沿模型，而是在应用与模型之间建设 AI Gateway，通过缓存感知的动态路由，在每一轮请求中综合预期质量、成本和速度选择执行模型。AT&T 表示，这套机制在部分应用中最高能够降低约 **90% 的 AI 成本**，并已经产生数百万美元级节省。 这类实践对企业 AI 的真正启示，并不是“应该更多使用开放模型”，而是模型正在从一个与应用绑定的产品能力，逐渐成为一种可以按照任务特征动态分配的计算资源。 对于正在建设企业知识计算与推理基础设施的组织而言，这个变化尤其重要。 ## 企业 AI 的核心问题正在从模型能力转向工作负载经济性 传统大模型应用通常具有非常直接的架构关系： **Application → Model API** 应用在开发阶段确定模型，此后的绝大多数请求都会进入同一个服务商或者同一类模型。模型升级往往意味着修改 API、重新测试 Prompt、处理不同工具协议，甚至重新适配应用代码。 这种方式在每天几百万 token 的实验阶段问题并不突出，但在每天几十亿甚至数百亿 token 的生产环境中，固定模型绑定会迅速转化为经济问题。 AT&T 的实践实际上把这一结构改变成： **Application → AI Gateway → Workload Routing → Model Portfolio** 业务应用不再需要首先决定“调用什么模型”，而是描述需要完成的任务。Gateway 再根据工作负载的需求、上下文状态以及模型运行情况决定任务应该由哪个模型完成。 AT&T Data Office 副总裁 Mark Austin 对外披露，公司计划在 2026 年把约 **25%～40% 的 AI token** 路由到开放模型，长期目标则希望达到约 **65%～70%**。其生成式 AI 使用量已经从每天约 80 亿 token 增长到约 450 亿 token，因此模型路由、开放模型和领域模型已经不只是技术选择，而成为控制总体 AI 经济性的基础能力。 这意味着企业真正应该管理的对象，不再是模型，而是 **AI Workload**。 一个客服摘要任务、一次复杂代码重构、一个合同风险判断和一次战略研究虽然都可以调用 LLM，但它们对于推理能力、错误风险、数据安全、上下文规模和实时性的要求完全不同。如果全部交给同一种最高等级模型，本质上相当于企业要求所有计算任务都运行在最昂贵的硬件实例上。 规模化 AI 不可能长期按照这种方式运行。 ## 多模型路由的本质，是决定一个任务需要购买多少智能 多模型路由经常被理解为根据价格在不同 API 之间进行分流，这种理解过于简单。 研究领域已经对这一问题进行了形式化探索。ICLR 2025 的 RouteLLM 工作提出，根据任务特征预测强模型相对于弱模型能够带来的质量增益，在需要时调用强模型，否则交给更低成本模型。其公开实验显示，在特定基准和模型组合下，学习型 Router 可以显著改善成本与质量之间的权衡。 但是企业生产环境中的 Router 比这样的二元模型选择更加复杂。 实际决策函数更接近： `Route = f(Quality, Cost, Latency, Risk, Privacy, Context, Cache, Availability)` 其中，Quality 表示业务要求和模型预期质量；Cost 包括完整执行成本；Latency 是 SLA；Risk 表示错误产生的业务后果；Privacy 决定数据是否允许离开企业环境；Context 描述任务当前携带的状态；Cache 表示模型切换可能造成的缓存损失；Availability 则包括模型服务、GPU 和外部供应商当前是否可用。 因此，Router 实际回答的问题并不是“哪个模型最便宜”，而是： **满足当前业务质量和风险约束的前提下，哪一种计算路径具有最低的任务完成成本。** 这也是企业多模型基础设施与普通 API Gateway 的本质区别。 ## AT&T 案例中最值得重视的是 Cache-aware，而不是模型价格 AT&T 官方特别强调，其 AI Gateway 是一个 **cache-aware router**。这实际上揭示了多模型调度中非常重要，却经常在概念方案里被忽略的问题。 假设一个 Coding Agent 已经围绕某个大型代码仓库工作了三十轮，会话中包含源代码、工具结果、历史修改记录以及大量上下文。此时，一个新的请求单独看可能只需要低成本模型即可处理。但如果为了节省本轮推理费用而切换模型，原有 Prompt Cache 可能无法复用，新模型需要重新处理几十万甚至上百万 token 的历史上下文。 “单价更便宜”最终反而可能使完整任务成本更高。 因此，企业不应该只计算： `Request Cost = Input Token + Output Token` 而应该计算： `Task Cost = Inference + Context + Cache Loss + Tools + Retry + Review + Failure Recovery` 进一步还应该考虑人工检查和返工： `Cost per Successful Task = Total Execution Cost / Successfully Completed Tasks` 这才是真正具有经营意义的 AI 成本指标。 AT&T 的案例说明，当 AI 从 Chatbot 进入 Agent、Coding、知识工作和企业流程以后，会话状态本身已经成为一种具有经济价值的计算资产。Router 必须理解当前任务所在的运行状态，而不能只分析当前这一条 Prompt。 ## 阅粒 KGM 的价值，应从“模型兼容”进一步理解为“推理编排基础设施” 从这一视角重新观察阅粒知识计算引擎 Yueli KGM Computing，它与 AT&T 所体现的架构方向存在明显交集。 截至目前公开版本，Yueli KGM Computing 已经以自托管 AI Gateway 和推理编排运行时的形式提供 OpenAI `/v1/chat/completions`、`/v1/responses` 与 Anthropic `/v1/messages` 等兼容接口，并支持 OpenAI `tool_calls` 与 Anthropic `tool_use` 之间的协议映射。业务应用因此可以通过统一 Base URL 使用不同模型，而不必直接绑定某一家模型供应商。 这一层能力看似只是 API 兼容，实际上解决的是企业 AI 架构中非常关键的 **应用—模型解耦** 问题。 只有先完成解耦，模型才可能被调度。 公开版本的 KGM 同时支持通过 llama.cpp、vLLM、SGLang、ds4、TokenSpeed 等方式管理本地推理 Worker，也可以接入外部模型服务，通过 Provider 配置执行路由、失败回退和运行状态管理。最新公开包还已经包含 runtimeId 会话亲和、pricing、failover、prefix-hit 统计以及 Prometheus 指标等运行机制。 这意味着企业可以进一步把原本的： **Application → 某个商业模型** 改造为： **Application → KGM → Local / Open / Frontier / Domain Model** 底层模型可以变化，而上层应用协议保持稳定。 这正是企业真正实施多模型路由的前提。 ## 知识计算使 KGM 与纯模型 Router 存在一个重要差异 如果阅粒 KGM 仅仅完成模型选择，它与市场上大量 LLM Gateway、Router 的差异不会足够明显。 KGM 更值得关注的部分在于：**模型路由与知识计算发生在同一个推理基础设施中。** HaxiTAG 对 Yueli KGM 的公开定位包括知识图谱、GraphRAG、私有知识处理、动态上下文构建以及通过事实节点约束模型推理。其核心目标之一，是把企业自身知识、业务关系和可信证据引入推理过程，使概率模型的生成行为受到确定性知识边界约束。 这个能力会直接改变 Router 的设计。 传统 Router 主要判断： **这个问题有多难？** 知识感知 Router 还需要判断： **企业已经拥有多少解决这个问题所需要的确定性知识？** 例如，一项企业制度查询本身可能属于专业问题，如果没有知识库，可能必须交给能力较高的前沿模型。但如果 KGM 已经检索到版本正确、权限匹配、相关度足够高的制度条款，那么推理实际上已经从“依赖模型自身知识回答”变成“根据确定事实进行归纳表达”。 此时，一个规模更小、成本更低的模型完全可能达到业务要求。 因此，未来更加合理的调度函数可以进一步写成： `Route = f(Task Difficulty, Knowledge Coverage, Context Quality, Model Capability, Risk, Cost)` 知识质量越高，对通用模型内部知识和复杂推理能力的依赖就可能越低。 这意味着 **知识工程本身也可以成为降低推理成本的方法**。 ## 企业 AI 最终需要的是“知识平面、控制平面和计算平面”的协同 AT&T 的案例进一步说明，单独部署一个 Router 很难解决企业 AI 的全部生产问题。AT&T 对 Sovereign AI 的描述实际上同时包含 AI Gateway、专业模型、治理和安全体系。 按照企业 AI 基础设施的运行逻辑，可以把体系抽象为三个相互关联的平面。 第一层是 **Knowledge Plane，知识平面**。负责企业数据、知识图谱、规则、经验、文档和业务事实的组织、检索、版本控制与权限约束。它决定“AI 可以依据哪些事实进行工作”。 第二层是 **Control Plane，控制平面**。负责模型注册、策略、权限、成本、SLA、安全、路由、降级、熔断、审计和评估。它决定“这个任务可以在哪里、以什么成本和什么风险等级运行”。 第三层是 **Compute Plane，计算平面**。包括云端 Frontier Model、开放模型、本地 GPU、领域模型以及不同推理引擎。它真正完成 token 计算。 Yueli KGM 当前公开的知识图谱、GraphRAG、双协议 Gateway、本地 Worker、Provider Routing、Managed Runtime 和 Metrics 等能力，实际上已经分布在这三个层面。 下一阶段真正值得继续增强的，不是简单增加更多模型 Provider，而是让三个平面开始根据业务结果形成闭环。 ## 模型路由不应该只有一次选择，而应该支持逐级升级 企业生产环境不能假设 Router 的第一次判断永远正确。 更加稳健的设计应该采用分级执行和 Escalation： **Deterministic → Small/Open Model → Domain Model → Frontier Model → Multi-model Review** 首先判断任务能否由检索、规则、SQL、传统机器学习或者确定性函数完成。如果可以，就没有必要启动生成式模型。 对于摘要、分类、信息抽取、格式转换、知识充分的企业问答，可以优先由低成本开放模型或者企业本地模型执行。 对于具有稳定专业知识的大规模任务，可以进一步使用领域模型或者经过微调的模型。 只有复杂规划、未知问题、高难推理以及高错误成本任务，才进入 Frontier Model。 对于安全审计、重大决策分析、复杂架构设计等高价值问题，则可以进入多个模型或多个实例的并行探索，再通过 Reviewer、Verifier 或规则系统完成结果验证。 这样，企业购买的不是“一个统一等级的 AI”，而是一组可以逐级升级的智能资源。 Router 真正需要优化的指标，也从模型调用比例变成 **Escalation Rate 与 Successful Task Cost**。如果低成本模型能够稳定解决 80% 的任务，仅有 20% 需要升级，路由才能形成真正经济价值；如果多数任务最终都需要再次调用高端模型，那么第一次低成本调用只是增加了延迟和额外费用。 ## 阅粒 KGM 下一阶段可以从规则路由走向业务效用路由 从公开能力来看，Yueli KGM 已经建立了多 Provider、本地 Runtime、失败回退、成本与运行指标等模型调度基础。 但从 AT&T 的大规模生产案例以及 RouteLLM 等研究来看，更值得继续演进的是 **Routing Intelligence 本身**。 第一步可以建立 **Model Capability Registry**。不仅登记模型名称和 Provider，还持续维护 Coding、Reasoning、Extraction、中文理解、长上下文、Tool Use、结构化输出等能力画像。 第二步建立 **Workload Profile**。每一种企业任务记录质量要求、SLA、风险等级、隐私要求、平均上下文长度、成功率和实际使用成本。 第三步建立 **Eval-driven Routing**。使用企业自己的真实任务集持续测试不同模型，不依赖通用 Benchmark 决定生产路由。 第四步建立 **Cache-aware / Context-aware Routing**。把当前会话上下文、prefix hit、runtime affinity 和切换成本纳入决策。 第五步建立 **Adaptive Routing**。根据生产执行结果持续调整路由策略，而不是长期使用静态 if/else 规则。 最终的优化目标可以表达为： `min Expected Cost` 约束条件为： `Quality ≥ Required Quality` `Latency ≤ SLA` `Risk ≤ Risk Budget` `Privacy = Policy Compliant` 模型选择因此从配置问题，转变为一个持续运行的约束优化问题。 ## Eval 必须成为 Router 的前置基础设施 这里存在一个非常现实的工程风险：如果没有 Eval，多模型 Router 很容易退化成“价格路由器”。 企业知道模型 A 每百万 token 比模型 B 便宜，却不知道同一业务任务交给 A 后，成功率下降了多少、人工 Review 增加了多少、客户投诉或者返工增加了多少。 这种情况下所谓降本可能只是成本转移。 RouteLLM 的研究之所以需要 preference data，本质上就是因为模型调度必须建立在“什么结果更好”的比较依据之上。 企业环境则需要比公开 preference 更严格的评价体系，包括业务正确率、事实一致性、结构合规、任务完成率、人工接管率、工具调用成功率、风险事件和最终业务结果。 因此，合理的工程顺序应当是： **Workload → Eval → Model Baseline → Router → Production Feedback** 而不是先建设 Router，再寻找评价标准。 每增加一个模型、升级一个模型版本或者改变一条路由规则，都应该能够在相同 Workload Dataset 上重新执行 Regression Eval。 只有这样，模型自由度增加以后，系统可靠性才不会同步下降。 ## 开放模型真正改变的是企业的模型资产结构 AT&T 计划逐渐提高开放模型承担 token 的比例，并不意味着 Frontier Model 会消失。恰恰相反，前沿模型会越来越集中在真正需要前沿能力的任务上。 这形成了一种值得企业借鉴的模型生命周期： **Frontier Model → Open General Model → Domain Model → Deterministic Software** 一个刚出现的新问题，由最先进的模型快速探索解决方案；随着任务重复出现，企业积累训练数据、知识、Prompt、规则和 Eval 数据；开放模型逐渐具备足够能力以后，任务下沉；规模进一步扩大以后，可以通过微调或者领域模型降低成本；当业务规则已经完全稳定，部分任务甚至可以重新实现为传统软件或机器学习。 因此，前沿模型更像探索层，开放模型承担规模化执行，领域模型承担专业化生产，而确定性软件负责已经被完全理解的问题。 企业 AI 的技术资产也由此发生变化：真正长期积累下来的并不是某个模型，而是 **Workload、Knowledge、Eval、Routing Policy 和 Execution Trace**。 这些资产才具有跨模型周期的持续价值。 ## 多模型体系最大的风险，是复杂度增长快于收益增长 多模型并不是天然先进。 每增加一种模型，就会增加 API 差异、上下文行为差异、工具调用差异、输出格式差异、版本管理、评测、监控、计费、故障处理和安全治理成本。 如果业务每天只有很小的模型调用规模，引入复杂 Router 甚至可能没有经济意义。 因此，企业实施多模型架构应该首先回答三个问题： 第一，当前 AI Workload 是否已经达到足够规模？ 第二，不同模型之间是否存在显著的 Cost–Quality 差异？ 第三，企业是否拥有足够可靠的 Eval 来判断这种差异？ 只有三个条件同时成立，动态路由才真正具有经济价值。 这也是阅粒 KGM 作为开源基础设施需要保持的重要边界：它可以提供构建企业多模型调度和知识计算体系的技术基础，但真正获得多少成本收益，仍然取决于企业自身的任务分布、模型选择、部署成本、评测数据和运营能力。AT&T 在 450 亿 token/日规模下获得的结果，不应被机械复制成其他企业的 ROI 预测。 ## 从 Open Model Router 走向 Enterprise Intelligence Control Plane 从更长的技术周期看，多模型路由可能只是企业智能控制平面的早期形态。 今天 Router 决定的是： “GPT、Claude、DeepSeek、Qwen 或本地模型中的哪一个来回答？” 未来它需要进一步决定： 是否需要调用 LLM； 是否应该先检索知识； 是否使用企业领域模型； 是否值得启动多个模型实例； 是否需要人类审批； 是否允许访问某项企业数据； 是否可以调用外部工具； 失败以后应该降级还是升级； 执行结果是否达到企业业务指标。 此时，系统所管理的已经不再只是 Model，而是 **Intelligence Execution**。 阅粒 KGM 的知识计算能力在这个方向上具有特殊意义。模型 Router 解决“由谁计算”，知识计算解决“依据什么计算”，Gateway 与 Runtime 解决“在哪里计算”，治理和 Eval 则解决“是否允许这样计算以及计算结果是否可靠”。 这些能力最终需要被整合到同一个企业 AI 运行闭环： **Observe → Evaluate → Route → Execute → Verify → Measure → Re-route** 企业持续收集真实工作负载，通过 Eval 比较模型，通过 Router 调度执行，通过 Metrics 记录结果，再根据实际质量、成本和风险重新调整策略。 模型因此不再是企业 AI 架构的中心。 **业务任务和企业知识开始成为中心，模型只是完成任务过程中可以被动态替换的计算资源。** AT&T 每天 450 亿 token 的生产实践已经证明，在足够大的 AI 规模下，这种转变能够产生非常现实的经济价值。Yueli KGM Computing 这样的开放推理编排与知识计算基础设施，则为企业自主建设类似能力提供了另一条技术路径：通过统一协议屏蔽模型差异，通过本地与云端混合推理提高模型选择自由度，通过知识图谱和 GraphRAG 提升上下文质量，再进一步通过 Eval、Routing Policy 和运行时指标建立持续优化机制。 企业 AI 下一阶段真正需要解决的，已经不再是“还能接入什么新模型”，而是如何把不同等级、不同成本、不同部署方式的智能能力组织成一套稳定、可审计、可替换、可持续优化的生产系统。 当这一体系成熟以后，企业拥有的就不再只是若干大模型账户或 GPU 集群，而是一套能够根据每个业务任务的价值、知识条件、风险和成本，持续决定**应该调用多少智能、在哪里计算以及怎样验证结果**的企业智能基础设施。 ## 关注「哈希泰格」服务号 ![关注哈希泰格公众号二维码](/logo/qrcode_for_gh_f9203b130c32_344.jpg) --- ## 引用与溯源 **来源**：哈希泰格 (HaxiTAG) **原始链接**：[https://haxitag.com/articles/enterprise-ai-model-routing](https://haxitag.com/articles/enterprise-ai-model-routing) **来源索引（站内可追溯）**：[麦肯锡](https://haxitag.com/search?q=%E9%BA%A6%E8%82%AF%E9%94%A1)、[普华永道](https://haxitag.com/search?q=%E6%99%AE%E5%8D%8E%E6%B0%B8%E9%81%93)、[Gartner](https://haxitag.com/search?q=Gartner)、[IDC](https://haxitag.com/search?q=IDC)、[Forrester](https://haxitag.com/search?q=Forrester) **版权声明**：本文由哈希泰格 AI 引擎优化生成，引用请注明出处。