面向边缘 AI 推理的 API 网关：路由、约束与可观测性

API 网关可以让边缘 AI 推理的路由决策变得明确：认证调用方、校验有边界的请求、选择合格的本地或远程目标、执行截止时间，并记录由哪个模型端点提供服务。但它不能调度 GPU，不能从一次基础 TCP 探测证明模型已经加载，也不能自行认定云端回退在法律与语义上都可以接受。

边缘场景最关键的限制并不只是距离。站点可能存在间歇性网络、小规模加速器容量、严格数据驻留要求、延迟的控制面更新，以及与云端并不完全相同的模型。路由设计应从这些限制出发，而不是把边缘当作缩小版区域。

核心要点

• 把地域、模型/版本、硬件、隐私、截止时间和回退许可拆成独立的策略维度。
• Kubernetes 调度、推理服务器就绪和网关请求路由要归属各自正确的负责人。
• 网关健康只是一个信号；把目标判定为合格前，还要使用模型队列、计算、加速器和模型就绪信号。
• 云端回退意味着新的数据传输和模型决策，不能当成自动重试。
• 明确站点断网时认证、配置新鲜度、配额和审计证据如何工作。
• 用有界标签关联网关与推理指标；不要把设备 ID 或请求 ID 放入 Prometheus 标签。

区分边缘放置与边缘路由

Kubernetes 可以把工作负载放到具备所需加速器的节点，并在拓扑域之间分散副本。它的拓扑分布约束可以根据策略选择 DoNotSchedule，让 Pod 保持 Pending；也可以选择 ScheduleAnyway，尽量偏向更好的放置位置。

放置回答“模型服务器可以在哪里运行”，网关则回答“当前哪个合格端点可以接收这个请求”。两者不是同一个决策。Pod 已经被调度，并不代表模型已经加载完成：它也可能仍在预热内存、排空流量、容量饱和，或者运行了错误版本。

同样，网关不负责模型批处理、加速器分配或推理正确性。应明确划分职责：

设计边缘请求路径

1flowchart LR
2    D[设备或站点应用] --> G[边缘网关]
3    G -->|合格的本地目标| L[本地推理服务]
4    G -->|策略明确允许回退| C[云端或区域推理]
5    L --> M[模型运行时与加速器]
6    S[签名策略与模型清单] --> G
7    L -. 就绪、队列、计算、加速器指标 .-> K[容量与就绪控制器]
8    K -->|合格或排空决策| G
9    G -. 网关指标、日志、链路追踪 .-> O[站点可观测缓冲]
10    O -. 恢复连接后延迟导出 .-> R[区域可观测系统]

容量控制器负责解释推理服务器信号，并给出目标合格或排空决策；网关负责执行该路由决策，而不是自行把某个 GPU 指标变成裁决。这样，服务负责人才能增加迟滞、最小样本窗口、模型版本检查和安全排空行为。

建立路由契约

对每个推理 API，都要定义：

• 工作负载： 分类、检测、嵌入、生成或批量分析；
• 输入： 最大字节数、媒体类型、尺寸和敏感数据类别；
• 模型身份： 批准的模型、版本或摘要、Tokenizer/预处理契约和硬件兼容性；
• 延迟： 调用方总截止时间、网关预算、排队预算和计算预算；
• 地域： 仅站点、区域受限或可进入云端；
• 容量： 最大队列、并发、加速器内存和温度/功耗约束；
• 回退： 允许的目标、触发条件、披露方式、模型等价性和重放安全性；
• 证据： 决策版本、目标、模型版本、各阶段延迟与最终结果。

不要让调用方提供的模型名称、站点 ID 或优先级请求头选择任意端点。应把已经认证的调用方上下文映射到服务端策略。只有认证过程把设备标识与请求绑定起来时，设备标识才具有权威性。

同时考虑网关和推理就绪状态

Apache APISIX 3.19.0 的主动健康检查可以通过 HTTP、HTTPS 或 TCP 探测上游，被动检查则从已代理结果中学习。这些检查有助于避免反复选择失败端点，但基础探测不能证明所需模型已经加载或仍有队列容量。

APISIX 还说明，当无法选择任何健康节点时，它仍会继续访问上游。这条“没有健康节点”路径是一条明确的放行边界。如果站点要求拒绝请求，而不是继续联系正在排空的推理服务器，就应增加独立的资格/准入决策并进行测试。

只有推理平台确认满足要求后，目标才应变为合格。例如：

NVIDIA Triton 指标文档分别提供请求、队列、输入计算、推理计算、输出计算、GPU 利用率、GPU 内存和 CPU 指标。这些属于推理服务器信号，不是 APISIX 指标；阈值取决于模型、批处理策略、硬件和延迟目标。

把云端回退变成明确的策略决策

把本地请求发送到云端，可能改变：

• 数据驻留和网络暴露范围；
• 模型版本、准确性、安全性和输出格式；
• 认证方式与供应商凭证；
• 延迟、可用性与成本；
• 操作是否可以安全重放；
• 是否必须向用户披露执行位置发生了变化。

应使用明确的决策表：

回退不等于自动重试。如果图片、支付决策、机器人命令或工具操作可能已经被处理，第二次尝试就可能产生重复效果。应限制总尝试次数；需要重放时，由应用维护幂等性不变量。

为断网运行做好准备

边缘站点可能与区域控制面失去连接，但本地客户端与模型仍然可达。需要定义以下离线行为：

• 路由、策略、信任锚和模型清单的最大允许年龄；
• 认证密钥轮换与撤销信息的新鲜度；
• 本地配额执行和恢复连接后的对账；
• 证书到期与时钟漂移；
• 更新被拒绝后的配置回滚；
• 本地审计存储、加密、容量和延迟导出；
• 断网时仍必须生效的紧急禁用或拒绝规则。

“使用最后一份配置”只有在明确的新鲜度窗口内才安全。缓存的公钥仍可能验证在断网后已被撤销的凭证。应按操作类别判断风险是否可接受，并在超过新鲜度边界后停止接收工作。

策略与模型清单应作为经过签名和版本化的包交付，原子应用，并保留上一份已验证包。网关应记录请求使用了哪个策略包和模型版本，同时默认不记录敏感载荷。

限制边缘请求

边缘资源比中心流量池更容易耗尽。代理前应执行：

• 正文大小、尺寸、采样时长与批量大小上限；
• 允许的内容类型与 Schema；
• 按认证类别限制请求速率和并发推理；
• 总截止时间与最长流式持续时间；
• 批准的模型映射；
• 请求到达第三方或区域供应商前移除敏感请求头。

这些检查用于限制传输和资源消耗，不能验证模型语义，不能发现所有对抗性输入，也不能证明媒体文件对所有解码器都安全。推理服务仍需要加固的解析和模型特定校验。

同时观测网关两侧

Apache APISIX 3.19.0 的 prometheus 插件可以暴露请求状态、延迟、响应来源、带宽与上游健康。应把它与推理服务指标结合，而不是强迫一个组件承担所有信号。

至少跟踪：

• 请求速率、拒绝、客户端可见状态和响应来源；
• 分开的网关、上游、队列和计算延迟；
• 所选站点、目标池、批准的模型版本和回退结果；
• 请求与响应字节数；
• 模型就绪和加载失败；
• 队列深度、加速器利用率/内存和功耗/温度事件；
• 断网时长、策略年龄和遥测积压。

使用环境、站点类型、网关集群、路由、模型家族与批准版本等有界维度。请求 ID、设备 ID、用户 ID、原始路径与输入内容应进入访问受控、且策略允许的日志或链路追踪，而不是 Prometheus 标签。OpenTelemetry 语义约定可以提供一致的属性名称，但采集仍然需要最小化、基数和隐私规则。

测试边缘故障矩阵

应演练：

1. 模型已加载、端点健康且队列在预算内；
2. 端点可达，但模型缺失或仍在预热；
3. 队列饱和，但网关延迟暂时看起来正常；
4. 加速器内存压力与温度降频；
5. 没有合格目标，但 APISIX 健康检查原本会放行；
6. 站点到区域的网络断开与恢复；
7. 断网期间策略过期、证书到期和身份被撤销；
8. 本地执行可能已经开始后的超时；
9. 云端回退被禁止、被允许，以及模型语义不同；
10. 本地遥测存储接近容量上限。

每种情况都要断言目标、尝试次数、总截止时间、数据边界、模型版本、客户端可见结果和审计证据。HTTP 成功响应还不够；可行时应执行领域特定的正确性测试。

边缘 AI 网关检查清单

• 放置、目标资格、网关路由和模型质量是否由不同负责人管理？
• 批准的模型版本或摘要是否属于路由契约？
• 就绪判断是否包含队列和模型状态，而不只是 TCP/HTTP 探测？
• APISIX 在没有健康节点时的放行行为是否可接受并已测试？
• 地域、数据类别和云端回退许可是否由服务端执行？
• 每次重试或回退是否能在剩余截止时间内安全完成？
• 离线身份、撤销、策略年龄与配额限制是否明确？
• 是否在推理前限制载荷大小、并发与流式持续时间？
• 网关与推理遥测能否在不使用无界标签的情况下关联？
• 回滚能否恢复相互兼容的策略、模型清单与网关配置？

常见问题

把网关放到边缘就能保证低推理延迟吗？

不能。网络距离可能缩短，但排队、模型加载、预处理、加速器压力或温度限制仍可能成为主要延迟来源。应分别测量各阶段。

边缘网关应该自动回退到云端吗？

只有数据策略、模型兼容性、延迟、成本和重放语义明确允许时才可以。否则应拒绝、排队，或使用有记录的本地降级模式。

APISIX 健康检查能判断模型是否就绪吗？

只有配置的探测准确暴露了所需就绪契约时才可以。通用 TCP 或浅层 HTTP 响应无法证明模型版本、队列容量或输出正确性。

后续步骤

参考更完整的 AI 与 ML 推理网关架构设计供应商、Token 和流式控制；用 API 网关可靠性工程治理降级模式；再把容量信号连接到弹性网关扩缩容。