生产环境的模型路由不是一次难度分类：从硬约束可行域到状态检查点升级

武子康2026-07-27 9:21

生产模型路由不是一次难度分类：从硬约束可行域到状态检查点升级

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 README
AWS Builders' Library 关于"安全重试"的具体语句 ⚠️ 待验证 本轮 search 未直接命中 AWS Builders' Library 关于 safe retries / idempotency 的原始文章；建议查 aws.amazon.com/builders-library
AWS 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 的原型都从同一个问题开始：先看一眼请求，预测它"简单"还是"困难"，简单请求交给便宜模型，困难请求交给强模型。这个设计对单轮、无工具、无副作用的问答可能成立，但它不是生产级 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 则在错误、超时或指定状态码出现后重试或转向其他目标。^3^^4^ Agent Planner 的典型研究范式如 ReAct，是让推理、动作和观察交替发生，以环境反馈修订下一步行为。^5^ Router 关注的是"下一阶段在哪个受允许的执行点运行"，Planner 关注的是"下一阶段做什么"。

还要注意同名术语的产品语义可能不同。

**产品事实：Amazon Bedrock Intelligent Prompt Routing。**截至访问日，AWS 用户指南把该能力描述为一个无服务器端点，在同一模型族内的两个模型之间进行请求级选择；自定义 Router 的主要条件是 responseQualityDifference，并指定一个 fallbackModel 作为基准模型。当预测质量差异未达到条件时，文档描述为使用该 fallback 模型。这不是文档所定义的"模型调用失败后，带着任务状态继续执行"的运行时故障转移。^6^^7^^8^

该产品当前公开限制同样重要：文档称其主要针对英文 Prompt 优化，不能依据某个应用自己的线上表现数据调整决策，并提示专业化场景未必最优。^6^ 支持页按访问快照列出 Amazon Nova、Anthropic Claude 和 Meta Llama 的若干具体型号，并要求同族路由；但同一官方站点的模型卡与示例存在不一致。因此，支持范围只能作为带日期的文档快照，部署时仍应通过控制台或 ListPromptRouters API 核验账户与区域中的实际可用项。^6^^9^^10^ 这些是 AWS 产品边界，不能外推为所有 Router 的通用限制。

三、可执行设计一：硬约束过滤先于软优化

**作者工程推导。**生产 Router 的第一步应是构造可行集合，而不是计算总分。设任务状态为 s，候选端点集合为 E，硬约束谓词为 H(e, s)，则：

text 复制代码 
F(s) = { e ∈ E | H(e, s) = true }

H 至少应覆盖以下事实：数据驻留与跨境规则；数据分类和提供方边界；允许的模型、版本与区域；输入输出模态；最大上下文和结构化输出能力；所需工具协议；租户隔离；端点健康；当前阶段是否允许执行副作用。延迟上限究竟是硬约束还是软目标，应由业务语义决定：例如实时语音的绝对超时可以是硬门槛，而一般后台任务的延迟通常适合优化。

伪代码如下：

text 复制代码 
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 展示了级联调用以改善成本---质量折中。^11^^12^ 这些研究证明软优化方法具有空间，但并不替代准入控制，也不自动解决多步状态、端点健康和副作用问题。

为什么不能把硬约束与软目标混成一个加权分数？因为任何有限惩罚都可能被另一项足够大的收益抵消；不同量纲的归一化和权重会漂移；策略变更后很难解释某次违规为何"总分更高"；模型或价格更新还会意外改变合规结果。硬约束表达的是"是否允许"，软目标表达的是"允许之后选哪个"，二者属于不同决策层。

四、完整任务成本会被缓存、队列、错误和工具结果改写

**作者工程推导。**路由时需要预测的不是单次模型调用价格，而是当前检查点之后完成任务的剩余成本：

text 复制代码 
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：

json 复制代码 
{
  "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": "..."
}

重新路由时，先用最新任务状态重新执行硬过滤，再估计每个可行候选的剩余成功率、迁移成本和尾延迟。只有预期收益超过切换成本与不确定性余量时才切换。控制面还应设置最大切换次数、冷却窗口和迟滞阈值，防止两个端点因短时波动来回震荡。达到上限后，应执行预定义的终止、降级或人工接管策略，而不是无限重试。

一个最小状态机可以写成：

text 复制代码 
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 则明确建议在检查点保存工作流状态，并让步骤和外部调用具备幂等性，否则恢复会复制副作用。^14^^15^ 这不等于"有了幂等键就获得全局 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_dispatched vs side_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 与同族约束 不要把"路由"窄化为同族切换；多族需求走自定义 Router
Bedrock 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"（仅部分模型支持）

Footnotes

  1. IBM Research --- Thoughts on LLM Routing，IBM Research 公开文章（待核验），访问日期 2026-07-24。 ↩ ↩2

  2. Envoy AI Gateway 推理路由文档，Envoy 官方 AI Gateway 资料（待核验），访问日期 2026-07-24。 ↩

  3. AWS Elastic Load Balancing 用户指南，官方文档，访问日期 2026-07-24。 ↩

  4. Kong AI Gateway --- Fallback 文档，Kong 官方文档，访问日期 2026-07-24。 ↩

  5. ReAct: Synergizing Reasoning and Acting in Language Models (arXiv:2210.03629)，研究论文，访问日期 2026-07-24。 ↩

  6. Amazon Bedrock Intelligent Prompt Routing 官方页，官方或第一方资料，访问日期 2026-07-24。 ↩ ↩2 ↩3

  7. Reduce costs and latency with Amazon Bedrock Intelligent Prompt Routing and Prompt Caching，AWS 官方博客，访问日期 2026-07-24。 ↩

  8. Amazon Bedrock 用户指南 --- Intelligent Prompt Routing，官方文档，访问日期 2026-07-24。 ↩

  9. Amazon Bedrock 控制台，产品页面与控制台示例，访问日期 2026-07-24。 ↩

  10. Amazon Bedrock API 参考 --- Prompt Routers，官方 API 参考，访问日期 2026-07-24。 ↩

  11. RouteLLM: Learning to Route LLMs with Preference Data (arXiv:2406.18665)，UC Berkeley / Anyscale 研究论文，访问日期 2026-07-24。 ↩

  12. FrugalGPT: How to use large language models while reducing cost and improving performance (arXiv:2305.05176)，斯坦福大学研究论文，访问日期 2026-07-24。 ↩

  13. Amazon Bedrock Prompt Caching 用户指南，官方文档，访问日期 2026-07-24。 ↩

  14. AWS Builders' Library --- Making retries safe with idempotent APIs，AWS Builders' Library（待核验），访问日期 2026-07-24。 ↩

  15. AWS Well-Architected --- Agentic AI Lens，AWS Well-Architected（待核验），访问日期 2026-07-24。 ↩

相关推荐
m沐沐1 小时前
【计算机视觉】OpenCV 物体跟踪——原理、算法与CSRT跟踪器实战
人工智能·python·深度学习·opencv·算法·计算机视觉·人脸识别
rain_sxr1 小时前
一个模型打天下：多模型路由前端的策略层与降级兜底
人工智能
AlfredZhao1 小时前
中国的 Agent 时代，正在从工程能力里长出来
agent
墨舟的AI笔记1 小时前
前端 Prompt 工程化：模板版本管理与 A/B 评测的工程闭环
人工智能
前方视点1 小时前
给我推荐个AI写小说的工具？资深创作者的FeelFish实战测评
人工智能
没刮胡子1 小时前
AI完全离线的ASR语音识别+TTS语音合成+大模型对话
人工智能·ai·语音识别·tts·asr
海兰1 小时前
【高速缓存】 RedisVL MCP 运行指南（下）
人工智能·redis·哈希算法·高速缓存
aneasystone本尊1 小时前
Headroom 上手：wrap 与 proxy 两种接入方式实战
人工智能
老猿AI洞察1 小时前
智能视觉检测平台——完整商业化项目全功能详解
人工智能·yolo·计算机视觉·视觉检测
热门推荐
01如何新建文件夹？ 电脑新建文件夹的4种方法022026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片03GitHub 镜像站点04AI科技热点日报 | 2026年07月01日05国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）06AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路072026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？082026 年 AI 大模型 & AI 编程工具实战全总结09幻兽帕鲁 - 服务器管理员权限与 GM 命令完全指南10微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新