面向 AI 与机器学习推理的 API 网关：流量、安全与可观测性

API 网关可以让 AI 与机器学习推理流量变得可治理：认证调用方、限制请求与 Token 用量、选择获准的模型端点、保护模型服务凭据，并输出有用的运维信号。但它无法判断模型答案是否正确，也不能阻止所有提示词攻击，更不能取代模型服务平台自身的容量控制。

因此，设计任务不是简单地“在模型前面放一个代理”，而是要明确哪些决策属于网关，哪些属于推理服务，以及模型提供商、流式连接、配额存储或策略依赖发生故障时系统如何响应。

核心要点

• 将请求准入、模型路由、内容策略和模型执行分开；它们的负责人和故障路径并不相同。
• 分别限制请求数、并发流、输入大小、输出 Token 和模型服务开支。
• 请求进入第三方模型服务前，移除调用方凭据与内部请求头。
• 即使已经返回 HTTP 200，缺少协议结束标记的流也必须视为不完整。
• 观测模型、Token、延迟、缓存与故障切换结果，默认不要记录提示词或响应正文。

划清责任边界

本文负责生产推理工作负载的设计决策。若要了解代理大模型请求的基础机制，请阅读API 网关如何代理大模型请求；若要区分 API 网关、AI 网关与 MCP 网关，请阅读AI 网关、MCP 网关与 API 网关的区别。

使用分层请求路径

1sequenceDiagram
2    participant C as 应用
3    participant G as API 或 AI 网关
4    participant P as 策略与配额依赖
5    participant M as 获准的推理端点
6    C->>G: 请求与调用方凭证
7    G->>G: 认证、授权、验证并移除请求头
8    G->>P: 检查服务端身份与预算
9    P-->>G: 策略与剩余额度
10    G->>M: 规范化请求与模型服务凭据
11    M-->>G: 响应或事件流
12    G-->>C: 响应与有边界的遥测

调用方凭证用于应用向网关证明身份，模型服务凭据用于网关向模型端点证明身份。它们是两类不同的机密信息，不能互相转发。同样，调用方提供的模型名或租户请求头，在服务端策略将其映射到允许的目标之前，都只是请求提示。

限制实际工作量，而不只是请求数

不同推理请求的成本可能相差很大。有效的策略模型应包括：

• 请求速率，用于吸收突发流量和明显滥用；
• 请求与流式连接的并发数，用于保护 Socket 和 Worker；
• 最大输入字节数和模型上下文大小；
• 模型服务支持时，由服务端设置最大输出 Token；
• 按 Consumer 或租户划分的 Token 时间窗口；
• 分别管理 Embedding、批处理和交互式生成预算；
• 上游超时与取消行为。

Apache APISIX 3.19.0 提供 ai-rate-limiting 进行 Token 限流，并提供 ai-proxy 执行面向模型提供商的请求转换。Token 限制是一种准入控制，不是计费账本：重试、不完整的流、提供商侧计量和异步上报的用量仍需要对账。

在 APISIX 中保护模型服务边界

下面的 APISIX 3.19.0 JSON 是配置片段，不是完整的可运行部署。请通过获准的机密信息交付机制替换占位符，并测试所选提供商协议。

1{
2  "uri": "/v1/chat/completions",
3  "methods": ["POST"],
4  "plugins": {
5    "proxy-rewrite": {
6      "headers": {
7        "remove": ["Authorization", "Cookie", "X-Internal-User"]
8      }
9    },
10    "ai-proxy": {
11      "provider": "openai-compatible",
12      "auth": {
13        "header": {
14          "Authorization": "Bearer <provider-key-from-secret-manager>"
15        }
16      },
17      "options": {
18        "model": "production-model"
19      },
20      "override": {
21        "endpoint": "https://inference.internal.example/v1/chat/completions",
22        "llm_options": {
23          "max_tokens": 1024
24        }
25      }
26    }
27  }
28}

移除请求头至关重要，因为 APISIX 3.19.0 的 ai-proxy 默认会转发传入请求头，只会丢弃 Host、Content-Length 与 Accept-Encoding，并强制设置 Content-Type: application/json；模型服务认证请求头会覆盖客户端传入的同名请求头。官方文档建议用 proxy-rewrite 等方式移除不得发送给第三方模型服务的请求头。

配置的 max_tokens 是服务端输出上限。它不保证固定成本或总延迟，也不会验证提示词在语义层面是否安全。

设计流式故障语义

流式响应会改变故障的表达时机。APISIX 3.19.0 文档说明：如果读取上游数据时，在任何事件到达客户端之前发生错误，超时仍可返回 HTTP 504，其他读取错误可返回 500。第一个 SSE 事件把下游响应提交为 200 后，后续故障无法再修改状态码；此时流会在没有正常结束标记的情况下终止。

因此，客户端必须检查协议结束标记，而不能只看 HTTP 状态。除非应用能够承受重复工作、重复工具调用和首次尝试可能产生的费用，否则不要自动重放不完整的生成请求。对交互式客户端，应明确显示“响应不完整”，再由产品策略决定是否重试。

把故障切换作为明确的产品决策

备用模型的价格、延迟、上下文窗口、数据驻留、内容审核或回答质量可能不同。启用前应记录：

1. 哪些故障会触发切换到其他实例；
2. 原请求是否可能已经被处理；
3. 合同允许使用哪些模型和区域；
4. 响应是否必须披露模型变化；
5. 最大尝试次数与总时长。

健康检查与 HTTP 状态规则可以选择另一个端点，却无法证明两个模型在语义上等价。故障切换是一条受控降级路径，不代表自动获得正确结果。

在不采集对话的前提下进行观测

应先采集元数据：已认证 Consumer、路由、所选模型、模型服务实例、请求与响应 Token 数、首字节时间、总耗时、缓存状态、故障切换次数和最终结果。Apache APISIX 3.19.0 的 prometheus 插件包含提示词与响应 Token 直方图。

提示词和响应正文可能包含个人数据、凭据、专有代码或受监管内容。在 APISIX 3.19.0 中，logging.summaries 与 logging.payloads 均默认为 false。logging.summaries: false 会从 logger 插件消费的结构化记录中省略 llm_summary 对象，设为 true 则加入模型、耗时、请求 Token 与响应 Token 摘要；logging.payloads: false 会从这些记录中省略 llm_request 与 llm_response_text，设为 true 才会加入。NGINX access log 变量由日志格式单独配置。两者都不影响 error.log，不能验证调用方身份，也不能让记录自动成为审计证据。若为受控排障启用任一项，应把事件与独立验证的 Consumer 上下文关联，并在采集前定义脱敏、访问、保留和删除规则。

生产检查清单

• 调用方是否通过服务端映射到获准的模型和提供商？
• 添加模型服务认证前，是否已移除公网凭据与内部请求头？
• 请求、并发、字节、Token 与费用预算是否彼此独立？
• 客户端能否识别缺少流结束标记的情况？
• 重试和故障切换规则对工具调用等副作用是否安全？
• 遥测能否反映模型和区域变化？
• 能否分别测试配额、模型服务与遥测故障？
• 日常日志是否排除提示词和响应正文？

常见问题

每个机器学习 API 都需要 AI 网关吗？

不需要。对可预测的请求/响应推理，传统 API 网关可能已经足够。需要按提供商计量 Token、模型路由、语义缓存与流式遥测时，AI 感知的网关能力会更有价值。

网关能否阻止提示词注入？

不能。网关可以执行确定性输入策略并调用外部检测服务，但提示词注入还取决于模型行为、检索数据、工具与应用授权。

推理请求超时后是否应该自动重试？

只有在应用确定操作可安全重复并限制尝试次数时才可以。超时并不能证明模型服务没有执行任何工作。

后续步骤

将本设计与分布式限流的权衡、安全的超时与重试策略以及日志存储与保留边界结合起来。