企业已经有多个应用分别直连外部模型、私有模型和内部推理服务。应用团队希望快速增加模型，安全团队要求按身份授权，财务希望知道用量归属，平台团队却只有分散密钥和日志。AI网关选型要从这张责任分布图开始，而不是从供应商支持的模型数量开始。

选型任务：先判断企业缺少的是统一协议、路由策略、身份隔离、用量归属还是异常控制，再决定网关建设范围。

盘点调用方、模型和责任主体

选型输入应包含应用、用户或租户、模型来源、接口协议、数据级别、调用窗口、密钥持有人、用量归属和故障联系人。只有模型清单，没有调用方与责任人，网关上线后仍无法解决越权和成本争议。

盘点时还要区分直连是临时试验还是生产依赖。某些低风险、单应用场景可能不需要完整平台；多团队共享模型、策略频繁变化或审计要求较高时，统一治理价值更明显。

四个问题决定网关建设范围

下面的决策树依次询问是否存在多模型差异、多应用身份、动态路由与用量归属。不同答案会导向轻量代理、现有网关扩展或专用AI治理层，而不是默认采购最大套件。

决策树只是收敛范围。实际候选方案还需验证现有API网关、模型平台与身份系统能否复用，避免重复建设。

路由必须同时处理正常和异常路径

正常路由可以按应用、任务、模型能力或人工配置选择后端；异常路由还要处理超时、限流、不可用、容量不足和模型版本撤回。策略必须记录命中原因和最终执行模型，调用方也应知道切换是否会改变功能。

可自动切换不等于可以无条件等价替换。 高风险或输出差异明显的业务，宁可明确失败或人工接管，也不应悄悄换模型。POC要同时验证主路径、备用路径和策略回退。

身份、权限和用量要落到应用对象

共享一个上游密钥会让审计和成本归属失效。网关应识别应用、用户或租户，并将其与允许的模型、配额、策略和日志关联。业务对象权限仍应由应用负责，网关处理的是调用入口授权，二者不能混为一层。

Token和请求用量可以支持预算观察与内部归属，但不自动等于供应商账单或财务结算。评估时应检查输入、输出、失败、缓存或重试如何记录，以及模型价格或内部成本口径变化后能否追溯。

用真实调用形成短名单结论

POC至少选择两个应用身份、两类能力有差异的模型、一个超限请求和一个后端故障。结果保留策略配置、请求记录、错误、路由原因、用量和恢复动作。

概念和入口边界可先参考 AI网关入口治理；如需比较已有方案，可结合 AI网关产品评估 查看既有能力分类。

选型结论分为满足、需集成、需定制和不满足，并标注企业自身责任。如果方案只能展示统一入口，却无法证明身份、策略、用量和异常证据，不能进入生产采购结论。

选型结果要从功能矩阵落到实施与退出工作量

候选方案完成POC后，平台、应用、安全和采购团队应分别复述同一组结论。若平台只看到路由，安全只看到日志，采购只看到支持项，说明证据仍未形成共同口径。报告要把已验证能力、依赖集成、企业自担责任和不满足项并排列出。

功能矩阵之外还要增加实施工作量：现有API网关与身份系统如何连接，模型目录由谁维护，策略和日志怎样迁移，告警进入哪个值班流程，版本升级由谁回归。需要专有插件、人工脚本或少数专家长期维护的部分，应作为风险而不是隐藏在备注里。

退出材料同样属于选型证据。应用与模型映射、策略、用量和审计记录能否导出，凭证如何撤销，旧入口怎样恢复，专有SDK需要多少改造，都决定未来主动权。候选方案如果入口能力丰富却无法解释退出路径，不宜仅凭演示进入采购结论。

最终建议可以分为直接采用、集成后采用、限定场景采用和淘汰。每类结论写明创建条件和复测触发器。这样选型会服务后续实施，而不是在合同签订后重新发现架构边界。

采购短名单还要比较团队接管与供应商退出能力

候选方案顺利获得功能POC后，采购团队应追问谁维护模型目录、路由规则、密钥、配额和成本口径。若所有变更都需要供应方后台操作，企业取得的是托管服务依赖；若由内部维护，则要评估权限模型、培训、文档和升级回归工作。两种模式都可以选择，但责任与持续成本必须公开。

交付证据应包含应用和模型清单、策略版本、权限映射、日志字段、告警规则、运行手册及一次配置回滚。供应方演示环境中的默认设置不能直接成为企业基线，实施团队需要把现有身份、API入口、日志与工单系统接入并复测。无法自动集成的部分应估算人工操作频率和交接难度。

合同边界可按软件能力、实施集成、运行服务和企业自担四层拆分。模型故障、网关故障、身份系统异常和账单差异分别指定取证与升级路径。版本更新时由谁发布兼容说明、谁执行回归、失败如何回退，也应在签约前确认，避免升级责任悬空。

退出验收要实际导出应用映射、策略、用量与必要审计记录，重新签发或撤销凭证，并让一个测试应用切回旧入口。专有SDK、插件或日志格式造成的改造应列入迁移清单。不能由非原实施人员完成退出演练的候选方案，应在采购评分中体现接管风险。

采购比较还应抽查一次版本升级。升级前导出配置和影响范围，升级后复跑身份、路由、限流、用量与回滚样本。候选方案若只保证全新安装，却无法说明跨版本迁移和失败恢复，长期运维风险仍然没有被验证。

用量与成本能力也要经过对账抽查。选择同一应用的一组正常、失败、重试和备用模型请求，将网关记录与上游账单或自建资源记录对照，标记无法解释的差异。采购结论关注数据能否追溯和修正，不把界面中的总数直接当作财务结算结果。

下一步建议

先整理现有应用到模型的调用矩阵，并找出密钥、权限、路由和用量责任的断点。用四个问题收敛建设范围，再让候选方案处理同一组正常与异常请求。采购短名单应附带未满足项、集成工作量、退出方式和责任人。

常见问题

已经有API网关，还需要AI网关吗？

不一定。现有API网关通常可以承接认证、通用路由、限流和基础日志，如果企业只有少量模型、策略简单，并且不需要Token、模型能力、流式语义或备用模型治理，扩展现有平台可能更合适。

当多模型差异、应用级配额、模型切换、用量归属和提示词或响应审计成为核心对象时，应评估专用AI治理层。决定前用真实调用测试现有网关缺口，不要因名称不同重复采购，也不要因已有入口就忽略模型语义。

差距表应明确现有API网关、模型平台和候选AI网关各自承担什么，并把需要插件、定制或人工流程的部分单列。后续模型与应用规模变化时，以这张表触发复评，而不是默认继续扩张原方案。

AI网关选型最先验证什么？

最先验证应用身份能否贯穿请求、策略、模型和日志。若网关只识别一个共享密钥，即使模型路由和限流功能丰富，也无法回答谁调用、谁越权、谁消耗以及谁应收到故障通知。身份对象是权限、配额、审计和成本归属的共同基础。

在此基础上，再验证正常路由、超限、上游超时和策略回退。每次测试都要保留配置和结果，避免把控制台菜单或一次成功响应当成生产证据。

选型第一轮用应用身份贯穿允许、拒绝、超限和故障切换请求，并核对策略、最终模型与审计。若身份在中途丢失，权限、配额、告警和用量都无法稳定归属，应先解决对象模型再比较高级功能。

Token统计是否等于成本结算？

不等于。Token统计是调用用量的一种记录，商业费用还可能受模型、输入输出计价、缓存、批量、重试、合同折扣或自建资源占用影响。不同后端返回的用量字段也可能存在差异，需要验证采集和归一方式。

企业可以用网关数据做预算观察、异常发现和内部归属，但应与供应商账单、资源成本和财务制度对账。文章不给予单价和节省比例。采购时要确认数据能否导出、追溯和修正，而非宣称自动完成结算。

成本报表必须允许回查应用、模型、重试和切换原因，并与外部账单或自建资源记录对账。无法解释的差异要保留修正流程和责任人；数据只适合预算观察时，就不能在采购材料中包装成自动财务结算。