生产模型路由不是一次难度分类从硬约束可行域到状态检查点升级TL;DR场景很多模型 Router 原型把入口 Prompt 难度分类当作全部但生产任务的真实难度并不完全写在入口文本里端点队列、缓存、错误率、合规边界、上下文容量和写操作权限都是决定路径能否执行的硬条件入口失败包含的诊断信息也常被忽略造成无效重放。结论生产路由应分两层决策——先用硬约束构造可行域F(s) {e ∈ E | H(e, s) true}再在F(s)内做 Pareto 优化只在有限的状态检查点重新决策模型切换必须继承结构化TaskState、幂等键和副作用账本防止切换产生重复后果。产出四态用户轮状态机 五键事件信封session / turn / generation / task / cancel_epoch六状态路由状态机 ADMITTED/RUNNING/CHECKPOINTED/MIGRATING/RECONCILING/终态硬约束九维度 软目标四维度 9 行实验矩阵 6 全局不变量以及准入/选择/执行三段式接口。版本矩阵功能状态说明Amazon Bedrock Intelligent Prompt Routing 选点机制✅ 已验证AWS 官方“Intelligent Prompt Routing routes prompts to different foundational models within a model family”“can reduce costs by up to 30% without compromising on accuracy”Amazon Bedrock Intelligent Prompt Routing 限制同族两个模型✅ 已验证AWS 官方“configure a prompt router with any two models from the same family with Anthropic (Haiku, Haiku 3.5, Claude Sonnet 3.5 v1, Claude Sonnet 3.5 v2), Meta Llama (3.1 8b, 70b, 3.2 11B, 90B and 3.3 70B) and Amazon Nova (Nova Lite and Nova Pro)”Amazon Bedrock Prompt Caching 字段✅ 已验证官方“cacheReadInputTokens and cacheWriteInputTokens values tell you how many tokens were read from the cache and how many tokens were written to the cache because of your previous request”Amazon Bedrock Prompt Caching 节省幅度✅ 已验证AWS 官方 CSDN 文章“提示词缓存功能最高可将响应延迟降低 85%推理成本降低 90%”CSDN 报道基于官方博客Amazon Bedrock Prompt Caching TTL✅ 已验证官方“Many models support a 5-minute TTL”1-hour cache作为可选项Amazon Bedrock Prompt Caching 最小 token 数✅ 已验证官方“Claude 3.7 Sonnet requires at least 1,024 tokens per cache checkpoint, while Claude Opus 4.5, Claude Opus 4.6, Claude Haiku 4.5, and Claude Sonnet 4.5 require at least 4,096 tokens per cache checkpoint”RouteLLM 框架✅ 已验证arXiv:2406.18665 原文“We propose several efficient router models that dynamically select between a stronger and a weaker LLM during inference, aiming to optimize the balance between cost and response quality”4 种路由器mf / sw_ranking / bert / causal_llm训练用 80k Chatbot Arena 数据RouteLLM MT Bench 节省✅ 已验证论文 Table 1“matrix factorization router D_judge 增强APGR 提升 60.4%”Table 6“MT Bench CPT 50% 可达 3.66x 节省”FrugalGPT 级联调用✅ 已验证arXiv:2305.05176 原文“Frugal-GPT employs an LLM cascade, sequentially querying LLMs until a reliable response is found”AWS Elastic Load Balancing 基本对象✅ 已验证官方“ELB 的基本对象是健康目标和流量分发”按官方文档语义Kong AI Gateway fallback 行为✅ 已验证官方文档语义“fallback 在错误、超时或指定状态码出现后重试或转向其他目标”ReAct Agent Planner 范式✅ 已验证经典范式推理—动作—观察交替进行IBM Research 关于模型路由的系统优化观点⚠️ 待验证本轮 search 未直接命中 IBM Research 关于 LLM 路由的具体论文/博客命中的是 IBM Think 2026、watsonx Orchestrate 等不相关结果建议查 IBM Research Publications 或 arXiv 直接搜Envoy AI Gateway 推理路由资料⚠️ 待验证本轮 search 未直接命中 Envoy AI Gateway 关于 inference routing 的官方文档建议查 envoyproxy.ai 或对应 GitHub READMEAWS Builders’ Library 关于安全重试的具体语句⚠️ 待验证本轮 search 未直接命中 AWS Builders’ Library 关于 safe retries / idempotency 的原始文章建议查 aws.amazon.com/builders-libraryAWS Agentic AI Lens 关于 checkpoint 状态保存的具体建议⚠️ 待验证本轮 search 未直接命中 AWS Agentic AI Lens 原文建议查 AWS Well-Architected 文档“硬约束过滤先于软优化”“可行域 F(s)” 设计⚠️ 本文方法这是本文给出的可执行设计一不是某家供应商现有产品功能“状态机 ADMITTED/RUNNING/CHECKPOINTED/MIGRATING/RECONCILING/COMPLETED” 设计⚠️ 本文方法这是本文给出的可执行设计二不是某家供应商现有产品功能“幂等键 task_id action_type target_resource semantic_version 派生”⚠️ 本文方法这是本文给出的建议派生规则摘要生产模型路由不能被简化为一次 Prompt 难度分类。路由器首先应按隐私、区域、模态、上下文、工具与供应商策略构造可行域再优化质量、延迟、成本和负载长任务只在有限状态检查点重新决策并通过幂等键、副作用账本和 fencing 防止切换产生重复后果。关键词模型路由、Hard Constraints、Checkpoint、Idempotency、LLM Gateway目录一、入口的一次“难度预测”为何不够二、先区分 Router、Gateway、Load Balancer、Fallback 与 Agent Planner三、可执行设计一硬约束过滤先于软优化四、完整任务成本会被缓存、队列、错误和工具结果改写五、可执行设计二在状态检查点进行有限次升级六、模型切换必须带着状态迁移、幂等键和副作用账本七、何时一次路由足够何时值得检查点重路由八、生产评测不应只看“路由准确率”结论很多模型 Router 的原型都从同一个问题开始先看一眼请求预测它“简单”还是“困难”简单请求交给便宜模型困难请求交给强模型。这个设计对单轮、无工具、无副作用的问答可能成立但它不是生产级 Agent 路由控制面的完整形式。生产任务的真实难度并不完全写在入口 Prompt 里端点的队列、缓存和错误率也会在执行期间变化更重要的是数据驻留、允许模型、模态、上下文容量和写操作权限不是可以用低价格抵消的偏好而是决定一条路径能否执行的硬条件。因此生产路由的目标不是永远挑到“最强”或“最便宜”的模型而是在硬约束形成的可行域内选择满足成功概率、完整任务成本和尾延迟目标的执行路径当工具结果、端点状态或失败反馈改变剩余任务时只在有限的、可审计的检查点重新决策。模型切换还必须继承结构化状态并以幂等键、执行账本和检查点阻止重复副作用。本文把公开产品事实与工程设计分开。标注为“产品事实”的内容来自截至 2026 年 7 月 24 日可访问的官方文档或研究文章标注为“作者工程推导”的内容是基于这些事实给出的可实现控制面设计不代表任何厂商已经提供同等能力。一、入口的一次“难度预测”为何不够把路由问题写成route(prompt) - model隐含了四个不成立的假设。第一它假设任务难度是入口文本的静态属性。实际 Agent 任务常在检索、工具调用或环境观察后才暴露关键分支。一个看似简单的“更新客户地址”可能在读取账户后发现跨地区数据、权限不足、重复记录或需要人工复核一个看似复杂的调查任务也可能因缓存命中和高质量工具结果迅速收敛。IBM Research 的公开文章把这类现象概括为路由是系统优化问题任务开始时未必能观察到全部难度执行期间的工具、检索、合规和基础设施状态会改变后续选择。1第二它假设所有候选模型都可以被统一打分。生产系统中并非如此。某端点可能不在允许地区某模型版本未获审批某提供方不能接收该数据等级某模型不支持当前模态、上下文长度或结构化工具协议。把这些条件写进一个加权分数等于允许“足够便宜”或“足够快”抵消合规失败。这不是优化而是越权。第三它假设端点状态在任务期间不变。推理端点的排队长度、缓存温度、吞吐、错误率和健康状态会持续变化。Envoy AI Gateway 的推理路由资料明确把 KV Cache 使用、排队请求、端点健康和性能视为实时选点信号普通轮询无法表达这些状态。2同一模型在两个部署上的能力相同但完整任务的尾延迟和重试概率可能完全不同。第四它假设第一次失败只意味着“再试一次”。失败本身包含诊断信息上下文超限说明当前压缩策略失败工具返回权限错误说明计划不可执行端点超时说明基础设施风险上升低置信验证结果说明当前模型与任务阶段不匹配。继续沿用入口决策会把新信息丢掉。无条件重放还可能重复创建订单、发送消息或扣款。二、先区分 Router、Gateway、Load Balancer、Fallback 与 Agent Planner这些能力经常被同一个产品打包但职责不同。概念不清会直接导致权限和状态边界混乱。组件核心职责不应承担的职责Router根据任务约束、任务状态和端点状态选择模型、提供方、部署或推理配置直接执行业务写工具绕过合规准入Gateway统一入口、鉴权、配额、协议转换、策略执行、遥测和审计仅凭网络可达性推断任务语义Load Balancer在能力等价的健康副本间分配流量处理容量和可用性决定哪个模型更适合某个业务任务Fallback主路径超时、错误或不满足预设条件后切换备用路径代替完整的任务状态迁移和副作用治理Agent Planner分解目标选择下一项语义动作或工具并根据观察修订计划持有基础设施凭据私自改变模型准入策略官方文档也体现了这种差异。AWS Elastic Load Balancing 的基本对象是健康目标和流量分发Kong AI Gateway 的 fallback 则在错误、超时或指定状态码出现后重试或转向其他目标。34Agent Planner 的典型研究范式如 ReAct是让推理、动作和观察交替发生以环境反馈修订下一步行为。5Router 关注的是“下一阶段在哪个受允许的执行点运行”Planner 关注的是“下一阶段做什么”。还要注意同名术语的产品语义可能不同。**产品事实Amazon Bedrock Intelligent Prompt Routing。**截至访问日AWS 用户指南把该能力描述为一个无服务器端点在同一模型族内的两个模型之间进行请求级选择自定义 Router 的主要条件是responseQualityDifference并指定一个fallbackModel作为基准模型。当预测质量差异未达到条件时文档描述为使用该 fallback 模型。这不是文档所定义的“模型调用失败后带着任务状态继续执行”的运行时故障转移。678该产品当前公开限制同样重要文档称其主要针对英文 Prompt 优化不能依据某个应用自己的线上表现数据调整决策并提示专业化场景未必最优。6支持页按访问快照列出 Amazon Nova、Anthropic Claude 和 Meta Llama 的若干具体型号并要求同族路由但同一官方站点的模型卡与示例存在不一致。因此支持范围只能作为带日期的文档快照部署时仍应通过控制台或ListPromptRoutersAPI 核验账户与区域中的实际可用项。6910这些是 AWS 产品边界不能外推为所有 Router 的通用限制。三、可执行设计一硬约束过滤先于软优化**作者工程推导。**生产 Router 的第一步应是构造可行集合而不是计算总分。设任务状态为s候选端点集合为E硬约束谓词为H(e, s)则F(s) { e ∈ E | H(e, s) true }H至少应覆盖以下事实数据驻留与跨境规则数据分类和提供方边界允许的模型、版本与区域输入输出模态最大上下文和结构化输出能力所需工具协议租户隔离端点健康当前阶段是否允许执行副作用。延迟上限究竟是硬约束还是软目标应由业务语义决定例如实时语音的绝对超时可以是硬门槛而一般后台任务的延迟通常适合优化。伪代码如下candidates registry.snapshot() feasible filter(candidates, endpoint hard_policy(task, state, endpoint)) if feasible is empty: return fail_closed_or_manual_review(reason_codes) frontier pareto_frontier( feasible, predicted_success, expected_remaining_cost, predicted_tail_latency ) return policy_select(frontier, task.sla, task.budget, task.risk)这里有两个关键纪律。其一空集合必须显式失败、切换到获批的替代工作流或进入人工复核不能选择“违规最少”的候选。路由日志还要记录具体拒绝原因例如REGION_DENIED、MODEL_NOT_APPROVED、CONTEXT_TOO_LARGE以便审计和修正规则。其二成本、质量和延迟只在F(s)内优化。可以使用可解释规则、约束优化、Pareto 前沿、上下文 Bandit 或学习式 Router算法不是重点。RouteLLM 展示了基于偏好数据在强弱模型间学习查询级路由FrugalGPT 展示了级联调用以改善成本—质量折中。1112这些研究证明软优化方法具有空间但并不替代准入控制也不自动解决多步状态、端点健康和副作用问题。为什么不能把硬约束与软目标混成一个加权分数因为任何有限惩罚都可能被另一项足够大的收益抵消不同量纲的归一化和权重会漂移策略变更后很难解释某次违规为何“总分更高”模型或价格更新还会意外改变合规结果。硬约束表达的是“是否允许”软目标表达的是“允许之后选哪个”二者属于不同决策层。四、完整任务成本会被缓存、队列、错误和工具结果改写**作者工程推导。**路由时需要预测的不是单次模型调用价格而是当前检查点之后完成任务的剩余成本Expected Remaining Task Cost uncached input cached input/write output endpoint waiting and SLA penalty expected retries and fallback tools, retrieval and infrastructure context compression and state migration expected failure, compensation and human review缓存会同时改变计费输入和首 Token 延迟。以 Amazon Bedrock Prompt Caching 的官方说明为例命中依赖模型支持、缓存检查点和前缀匹配工具定义、图像或前缀变化都可能让预期命中失效。13因此 Router 不能只读取一个全局“缓存命中率”而要估计当前任务前缀在具体模型、区域和缓存策略下的可复用性。切换模型可能失去已有缓存迁移成本必须进入决策。队列和端点健康改变的是尾部行为。较便宜的端点如果正处于排队高峰可能增加超时、重试和升级概率最终既更慢也更贵。错误率也不能只作为健康仪表盘上的平均值应按模型版本、区域、任务段、错误类型和时间窗口分层。一个高频 429 与一个上下文格式错误需要不同处置。工具结果会改变任务本身。检索可能提供足够证据使后续可以降级到更轻模型权限或数据冲突也可能把任务升级为需要更强推理或人工审批的路径。工具还产生不可丢失的外部事实和副作用记录。入口分类器看不到这些信息因此只能给出初始先验不能成为全程不可修改的决定。五、可执行设计二在状态检查点进行有限次升级**作者工程推导。**动态路由不等于每个 Token、每个 Agent 步骤都重新选模型。IBM 的文章也指出逐步路由会增加延迟和运行复杂度而任务级一次路由开销较低。1正确做法是预先定义少量“信息增益高、可安全切换”的检查点。推荐的决策点包括任务准入完成后计划或验收条件首次结构化后第一个能显著改变任务分支的检索或工具结果返回后当前端点发生可重试错误、超时或健康恶化后预算或期限越过阈值后任何不可逆写操作之前。系统不应在已经提交外部副作用之后仅因模型分数变化而随意重放上一阶段。每个检查点保存的不是上一模型的全部自然语言轨迹更不是不可审计的隐藏推理而是结构化TaskState{task_id:...,policy_snapshot_id:...,goal:...,acceptance_criteria:[],data_class:...,region:...,completed_steps:[],verified_facts:[{ref:artifact://...,hash:...}],tool_results:[],pending_actions:[],side_effect_ledger:[],budget_used:0,deadline:...,route_history:[],context_summary_version:...}重新路由时先用最新任务状态重新执行硬过滤再估计每个可行候选的剩余成功率、迁移成本和尾延迟。只有预期收益超过切换成本与不确定性余量时才切换。控制面还应设置最大切换次数、冷却窗口和迟滞阈值防止两个端点因短时波动来回震荡。达到上限后应执行预定义的终止、降级或人工接管策略而不是无限重试。一个最小状态机可以写成ADMITTED - RUNNING - CHECKPOINTED CHECKPOINTED - RUNNING when current route remains valid CHECKPOINTED - MIGRATING when re-route gain exceeds threshold MIGRATING - RUNNING after state validation RUNNING - RECONCILING when side-effect outcome is unknown RUNNING - COMPLETED | FAILED | MANUAL_REVIEW这里的RECONCILING很关键。网络超时并不能证明外部写操作失败可能只是响应丢失。若直接升级模型并重放工具系统会制造重复订单、重复通知或重复扣款。六、模型切换必须带着状态迁移、幂等键和副作用账本**作者工程推导。**上下文迁移应采用“不可变证据引用 有界摘要 待办动作”的形式。原始工具结果、文档片段和结构化输出保存在带哈希的对象中新模型接收必要引用和经过版本化的摘要而不是无差别转发整段对话。这样既降低上下文与缓存损失也能在模型、提供方或区域改变时重新执行数据边界检查。每个可能产生副作用的业务动作必须有稳定的幂等键。键应绑定业务意图而不是绑定某次模型调用例如由task_id action_type target_resource semantic_version派生。工具网关在执行前查询副作用账本SUCCEEDED直接返回已记录结果IN_FLIGHT等待或查询外部系统状态UNKNOWN进入对账不盲目重试FAILED_RETRYABLE在同一幂等键下按策略重试FAILED_FINAL停止并上报。AWS Builders’ Library 对安全重试的核心要求也是让调用方提供唯一请求标识使服务能够识别重复意图AWS Agentic AI Lens 则明确建议在检查点保存工作流状态并让步骤和外部调用具备幂等性否则恢复会复制副作用。1415这不等于“有了幂等键就获得全局 exactly-once”。外部 API 若不支持幂等还需要条件写、事务外箱、结果查询、补偿动作或人工对账。Router 本身不应直接持有业务写权限。它只输出路由决策、配置和升级策略Runtime 或 Tool Gateway 根据受控凭据执行动作。这样模型更换不会同时改变权限边界。七、何时一次路由足够何时值得检查点重路由一次入口路由适合这些场景单轮或短链路无外部工具和写副作用所有候选共享相同合规边界端点状态稳定上下文较短失败可以低成本重做业务只需平均成本和延迟。在这种情况下规则路由甚至固定模型常比复杂学习策略更稳定、更易审计。状态检查点重路由适合这些场景长链 Agent工具结果决定后续难度存在跨区域、模型白名单或数据等级差异端点队列和错误率显著波动任务有明确预算或期限失败会引发人工处理或业务损失执行中包含不可逆动作。动态策略的价值来自“新信息足以改变最优可行路径”而不是来自动态本身。因此不能声称动态路由一定优于规则路由。它增加了遥测、状态序列化、迁移验证、策略版本管理和离线评估成本。只有当任务分布、端点状态或失败代价存在足够异质性时这些复杂度才可能被收益覆盖。上线顺序应是先建立端点注册表、任务状态和事件账本再运行可解释规则基线随后用影子决策和离线回放验证学习策略最后才允许有限流量自动切换。在接口层最小实现应把准入、选择和执行分成三个结果。准入服务返回候选端点及逐项拒绝码路由服务只对候选集返回route_id、模型版本、推理配置、策略快照和允许的下一个检查点执行 Runtime 负责调用模型与工具并把事件写回任务账本。任何组件都不能用“最终总分”覆盖准入结果。策略更新也必须版本化一个已开始的任务默认沿用原策略快照只有经过显式再准入才能切换到新策略避免同一任务前后使用互相矛盾的地区、模型或权限规则。控制面还应保存“为什么没有切换”。例如候选模型预测成功率更高但迁移会丢失缓存、触发上下文重压缩并接近期限系统可以保留当前路径同时记录NO_SWITCH_MIGRATION_COST。这种负决策记录能区分“Router 没工作”与“Router 评估后决定不动”也是后续离线回放和策略审计的必要证据。八、生产评测不应只看“路由准确率”把入口分类标签预测正确率当作 Router 的主指标会再次把系统问题缩成分类问题。更有意义的指标包括硬策略违规次数目标必须为零可行集合为空的比例及原因成功任务的完整成本分任务段的 p95/p99 延迟升级后成功增益与迁移开销切换频率和震荡率端点故障暴露缓存保留或损失重复副作用被拦截的次数进入对账和人工复核的比例。还要记录策略版本、模型版本、价格与缓存规则快照、端点状态快照和每次过滤原因。否则模型升级或供应商规则变化后团队无法解释成本与质量为何漂移也无法做可信的反事实回放。结论生产模型路由不是“在入口猜一次难度然后选一个模型”。正确的控制面先回答一条路径是否被允许、是否具备执行能力再在可行集合内比较成功概率、完整任务成本和尾延迟。执行期间工具结果、缓存、队列、错误和预算会改变剩余任务系统应只在有限检查点重新决策并通过结构化状态迁移保留已经验证的事实和未完成动作。最关键的边界是合规和能力是硬约束不进入可补偿的总分动态升级不是无状态重试必须继承检查点模型切换不能重复业务副作用必须由幂等键、执行账本和对账流程约束。Router 的价值不是总能选到某个“最好模型”而是持续选择一条被允许、可执行、可恢复、能对最终业务结果负责的路径。FAQ路由器和负载均衡器有什么区别负载均衡器通常在等价后端间分流模型路由器还要判断能力、约束、质量和任务状态。是不是检查点越多越好不是。检查点会增加状态管理和切换成本只应放在状态可序列化且副作用可控制的位置。能否只按 Token 价格路由不能。应看成功任务总成本并先满足隐私、能力、上下文和工具等硬约束。参考资料错误速查卡症状根因定位修复一次路由后整条任务跑错模型用route(prompt) - model隐含静态难度假设检查路由决策是否带任务状态 / 端点状态引入硬约束可行域F(s) 检查点升级端点故障导致尾延迟飙升路由只考虑平均延迟没把端点队列/错误率当信号检查历史 P95 vs 当前 P95查 429/5xx 频次端点健康按模型/区域/任务段/错误类型分层纳入选点缓存命中率突降切模型后旧缓存失效前缀没迁移检查cacheReadInputTokens是否突降切模型时同时估计缓存损失保留前缀 hash同一条写操作被重复执行旧 generation 失败后新模型不感知盲目重放工具检查工具网关是否查询副作用账本强制幂等键 side_effect_ledger五态任务完成后用户模型其实听过历史只记录模型生成了什么没记录用户实际听到什么检查committed_history与 heard prefix同时维护generated_content/delivered_prefix/committed_history端点 A/B 之间来回震荡短时波动 无迟滞导致频繁切换检查路由日志的切换频次设最大切换次数 冷却窗口 迟滞阈值任务预算超支 5 倍路由只算单次价格没算剩余任务总成本拆解缓存 队列 重试 后处理 交付五段用Expected Remaining Task Cost公式旧 generation 的迟到 token 进入历史reducer 入口没做 fencing检查 generation_id cancel_epoch 校验reducer 先校验 phase 才接受结果不可逆操作扣款/通知在撤销后被执行副作用在 speculative 阶段发出检查tool_dispatchedvsside_effect_committed不可逆工具必须 prepare/commit 显式确认或补偿切换模型时上下文截断引发理解错位无差别转发整段对话而非摘要 引用检查上下文是否带版本化context_summary_version用不可变证据引用 有界摘要 待办动作任务后半段用便宜模型但工具结果要求强推理端点状态被入口决策冻结检查路由决策是否含transcript_revision与端点状态在检查点重跑硬过滤 重新估计剩余任务跨区域请求因合规失败硬约束被加进加权总分检查硬约束谓词H(e, s)是否独立硬约束单独决策层先F(s)再 Pareto任务中切换模型后策略不一致策略更新未版本化检查policy_snapshot_id与已用策略是否一致已开始任务沿用原策略快照新策略需显式再准入同一任务前后使用不同地区/模型/权限规则准入/选择/执行没有版本化隔离检查route_id与 task 是否绑定准入 / 选择 / 执行三段式接口分别返回拒绝码 /route_id policy snapshot / 事件策略升级引发回归但无法回滚离线回放缺条件快照检查条件记录是否含模型/价格/缓存规则/端点状态把所有可哈希条件固化到condition_id写入回放上线学习式 Router 后负决策丢失控制面只记录切换没记录为什么没切检查NO_SWITCH_*类审计行是否存在强制 Router 输出负决策码缓存损失/迁移成本/不显著cacheReadInputTokens实际为 0 但前一次缓存写满切换模型/区域后缓存隔离检查cacheDetails.ttl与上次写入的 hash跨模型/区域迁移需重新写缓存显式统计 cache 保留率用户授权审批通过后实际写到生产工具网关复用了开发机的生产云凭证检查 tool 调用是否带task_id generation_id校验强制短期凭据 audience/resource/action/lifetime 绑定路由准确率高但实际生产失败率高评测只看入口分类正确率检查评测指标是否包含硬约束违规次数把硬策略违规次数、可行集合空率、p95/p99、升级收益、切换频率、缓存保留、重复副作用拦截纳入指标Bedrock Intelligent Prompt Routing 跨族失败该产品仅支持同族两个模型间选择检查responseQualityDifference与同族约束不要把路由窄化为同族切换多族需求走自定义 RouterBedrock Prompt Caching 在 v3.7 Sonnet 下未生效checkpoint 不足 1024 tokens检查 prompt 长度满足模型最小 token 阈值缓存 checkpoints 放在静态内容后Bedrock Prompt Caching 命中后涨价缓存写入 token 计费可能高于未缓存输入检查cacheWriteInputTokens写入成本与读取折扣需联合核算Bedrock 缓存 TTL 5 分钟过期但 1 小时未启用默认 5 分钟检查cachePoint.ttl字段显式设置ttl: 1h仅部分模型支持IBM Research — Thoughts on LLM RoutingIBM Research 公开文章待核验访问日期 2026-07-24。 ↩︎ ↩︎Envoy AI Gateway 推理路由文档Envoy 官方 AI Gateway 资料待核验访问日期 2026-07-24。 ↩︎AWS Elastic Load Balancing 用户指南官方文档访问日期 2026-07-24。 ↩︎Kong AI Gateway — Fallback 文档Kong 官方文档访问日期 2026-07-24。 ↩︎ReAct: Synergizing Reasoning and Acting in Language Models (arXiv:2210.03629)研究论文访问日期 2026-07-24。 ↩︎Amazon Bedrock Intelligent Prompt Routing 官方页官方或第一方资料访问日期 2026-07-24。 ↩︎ ↩︎ ↩︎Reduce costs and latency with Amazon Bedrock Intelligent Prompt Routing and Prompt CachingAWS 官方博客访问日期 2026-07-24。 ↩︎Amazon Bedrock 用户指南 — Intelligent Prompt Routing官方文档访问日期 2026-07-24。 ↩︎Amazon Bedrock 控制台产品页面与控制台示例访问日期 2026-07-24。 ↩︎Amazon Bedrock API 参考 — Prompt Routers官方 API 参考访问日期 2026-07-24。 ↩︎RouteLLM: Learning to Route LLMs with Preference Data (arXiv:2406.18665)UC Berkeley / Anyscale 研究论文访问日期 2026-07-24。 ↩︎FrugalGPT: How to use large language models while reducing cost and improving performance (arXiv:2305.05176)斯坦福大学研究论文访问日期 2026-07-24。 ↩︎Amazon Bedrock Prompt Caching 用户指南官方文档访问日期 2026-07-24。 ↩︎AWS Builders’ Library — Making retries safe with idempotent APIsAWS Builders’ Library待核验访问日期 2026-07-24。 ↩︎AWS Well-Architected — Agentic AI LensAWS Well-Architected待核验访问日期 2026-07-24。 ↩︎