一家公司的 AI 请求很少同样难。工单分类只需从几个标签里选一个，合同审阅要读长文并指出依据，智能体调用工具还要理解参数和前后步骤，全部交给最贵的模型，简单任务也按高价计算。全部交给小模型，复杂请求又容易掉质量。模型路由在请求到达以后，从允许的候选模型里替它选一个。
我对照了 Microsoft Foundry 和 Amazon Bedrock 当前的路由说明，两者都会分析请求并预测哪一个模型更合适，然后把实际模型信息放进响应。路由器替应用做选择，企业仍要决定候选池、成本与质量的取舍，并用自己的请求检查结果。
路由依据藏在完整请求里
Azure 文档说明，路由器会读取系统消息、用户消息、工具定义和对话历史，再判断任务类型与难度。它提供 Balanced、Cost 和 Quality 三种模式。平衡模式同时考虑成本与质量，成本模式更偏向便宜模型，质量模式把质量放在前面。
一个短问题带着几十页历史消息，路由时仍要考虑上下文。候选池中最小模型的上下文窗口可能限制整个端点，长请求到来后无法靠路由器凭空扩大。Azure 建议用模型子集排除窗口太小的候选。公司还有数据区域、模型许可和安全审批要求时，也应先把不合规模型挡在候选池外。
AWS 的智能提示路由当前在同一模型家族内选择，并列出两项明确限制。它主要针对英文提示优化，也不会根据某个应用自己的历史表现自动改变决定。中文客服、行业缩写和公司内部格式都可能超出它的训练分布，默认路由结果只能算待验证方案。
实际去了哪里必须能查
评测时先保留一个固定模型作为基线，再让路由端点跑同一批代表性请求。每条记录至少要有任务类别、所选模型、输入输出 Token、耗时、费用和质量结果。Azure 文档建议一次只改一个条件，模式或候选池变化以后重新比较，这样才能知道差异来自哪里。
只看平均费用也会误导。简单分类占九成时，账单很容易下降，剩下的一成长合同却可能决定业务是否敢上线。分类、抽取、长文审阅和工具调用应分开看，关键任务还要保留人工抽查或可验证答案。
路由上线后，响应里的模型字段要进入日志。Azure Monitor 可以按底层模型拆分流量，AWS 也会返回实际使用的模型。发现某个模型频繁接到不合适的任务时，先收紧候选池或改路由模式，再用原测试集重跑。模型路由省的是逐条人工选模型的麻烦，质量责任仍留在使用它的公司。