LLM Gateway 和普通 API Gateway 差在哪？拆开一次模型请求就明白了

普通 API Gateway 已经会认证、限流、路由、转发、记录状态码和延迟。那为什么 AI 应用还要单独引入 LLM Gateway？

最准确的答案不是“LLM Gateway 更智能”，而是：

普通 API Gateway 主要理解 HTTP 请求；LLM Gateway 还要理解请求里的模型语义。

POST /v1/chat/completions 看起来仍然是 HTTP，但它的 model、messages、tools、图片、缓存字段、SSE 事件和 usage 都会改变路由、重试、账单和观测方式。

普通网关并非做不到这些。Envoy、Kong、AWS API Gateway 都能通过插件、过滤器、函数或外部服务扩展。区别在于：当你为普通网关补齐协议适配、模型路由、Token 计费和流事件解析后，这组扩展本身就构成了 LLM-aware gateway 层。

本文从一条流式模型请求拆成 10 个阶段，并对照 Nbility 当前代码验证哪些能力真的存在，避免把产品类别写成营销口号。

先看能力边界

能力	普通 API Gateway	LLM Gateway 的额外语义
API Key / JWT / mTLS	原生强项	映射用户 Key 与上游供应商凭据
路径和 Host 路由	原生强项	根据模型、能力、分组和渠道选路
RPM 限流	原生强项	增加 TPM、预算、模型和用户维度
HTTP/SSE 转发	可以	解析不同供应商的流事件和结束语义
请求转换	模板或插件可做	转换 messages、tools、多模态和输出约束
负载均衡	状态码、延迟、权重	加入模型可用性、价格、配额和缓存亲和性
重试	按 HTTP 状态和幂等性	判断是否已输出 Token、是否触发工具副作用
计费	请求数、流量、套餐	输入、输出、推理、缓存写入/读取 Token
观测	QPS、4xx/5xx、延迟	TTFT、Token/s、模型、渠道、缓存和成本
内容安全	WAF、Schema、大小限制	Prompt/输出审核与模型级策略，但仍需业务层配合

表中不是“支持/不支持”的打勾游戏。普通网关通过自定义代码可以实现右列；LLM Gateway 的价值是把这些模型语义做成一等对象，而不是每个团队重复拼插件。

一条模型请求经历的 10 个阶段

我们用以下请求作为基准：

{
  "model": "customer-support-fast",
  "stream": true,
  "messages": [
    {"role": "user", "content": "Summarize ticket T-1024"}
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_ticket",
        "parameters": {
          "type": "object",
          "properties": {"id": {"type": "string"}},
          "required": ["id"]
        }
      }
    }
  ]
}

customer-support-fast 是应用层别名，不是某家供应商的真实模型 ID。请求经过：

1 认证
→ 2 限流/预算
→ 3 解析模型请求
→ 4 模型映射
→ 5 选择渠道
→ 6 协议转换
→ 7 上游调用
→ 8 流式转发与安全重试
→ 9 usage 结算
→ 10 日志与观测

我把这条链路写成一个可执行的 Python 追踪表，逐阶段标记普通网关能力与 LLM 语义。它不是网络性能测试，而是代码化架构证据：文章中的能力矩阵可由脚本稳定重建，而不是凭印象画框图。

阶段 1–2：认证和 RPM 限流，普通网关已经很擅长

AWS 对 API Gateway 的定义包括创建、发布、维护、监控和保护 REST、HTTP 与 WebSocket API；其 REST API 还能按账户、Stage、Method 和 API Key 使用计划做节流。Envoy 的 HTTP Connection Manager 也原生处理路由表、Header 操作、访问日志、请求 ID、Tracing 和统计。

所以这些能力不应包装成 LLM Gateway 独有：

• TLS 终止；
• API Key、JWT、OIDC、mTLS；
• CORS 与 WAF；
• IP 和请求体大小限制；
• RPM、并发和带宽限制；
• 路径、Host、Header 路由；
• 4xx/5xx、总延迟与 QPS。

但模型流量很快越过“请求次数”维度：两个 HTTP 请求，一个输入 300 Token，另一个输入 300,000 Token，它们对成本、GPU 时间和上下文占用完全不同。LLM Gateway 通常还要限制：

用户 / Key / 模型 / 分组 / 时间窗口
× requests
× input tokens
× output tokens
× estimated budget

Nbility 的真实请求中间件已经包含 TokenAuth()、ModelRequestRateLimit() 与 Distribute()；Token 还能限制可用模型、分组和剩余额度。这是从 HTTP 身份转向模型预算的第一步。

阶段 3：必须读懂请求体，不能只看 URL

普通网关可以看到：

POST /v1/chat/completions
Content-Type: application/json
Authorization: Bearer ...

LLM-aware 层还要读：

• model 是公开模型还是别名；
• stream 是否开启；
• 输入是纯文本、图片、音频还是文件；
• 是否包含工具定义；
• 是否要求 JSON Schema；
• Prompt Cache 参数是否存在；
• 输出上限和推理参数是否被供应商支持。

一个基础聊天请求成功，不能证明网关兼容工具、图片、结构化输出或流式 usage。此前的多供应商原生 API 格式对照已经说明：模型 API 的差异不是换一个 Base URL 就结束。

阶段 4：模型映射不是路径改写

普通 API Gateway 擅长：

/api/orders → orders-service
/api/users  → users-service

LLM Gateway 需要处理：

customer-support-fast
→ 按用户分组解析可用能力
→ 映射到某个上游模型 ID
→ 确认该渠道支持 tools + stream
→ 再选择凭据和节点

模型别名的目标可能因为区域、价格、供应商下线或企业策略变化而改变。客户端不应因此改代码。

Nbility 当前渠道模型配置包含 ModelMapping、模型列表、分组、优先级和权重；分发中间件把渠道 Model Mapping 写入请求上下文，并保留应用请求模型与 UpstreamModelName。因此日志可以展示用户请求了什么、实际发送到上游的是什么。

阶段 5：负载均衡要多看四类信号

传统负载均衡常看：

• 节点健康；
• 权重；
• 连接数；
• 延迟；
• HTTP 错误率。

模型路由还要看：

1. 能力：模型是否支持 tools、vision、JSON Schema、长上下文；
2. 配额：供应商 Key 是否被限流或余额不足；
3. 经济性：输入、输出、缓存和推理 Token 价格；
4. 亲和性：Prompt Cache 是否依赖稳定路由。

这不等于应该在每次请求里做“智能猜测”。生产路由更适合可解释规则：先过滤能力和权限，再按优先级、权重、健康与成本选择。下一篇 #106 会专门讨论路由决策；本篇只标出普通负载均衡缺少的输入信号。

阶段 6：协议转换远不止改 Header

三类常见原生接口就已经不同：

语义	OpenAI Responses	Claude Messages	Gemini GenerateContent
系统指令	instructions	顶层 system	systemInstruction
输入	input typed items	messages content blocks	contents[].parts[]
工具调用	function-call item + call_id	tool_use + tool_use_id	functionCall part
工具结果	function-call-output item	tool_result block	functionResponse part
输出上限	max_output_tokens	max_tokens	generationConfig.maxOutputTokens
认证	Bearer	x-api-key + version	x-goog-api-key

正确的适配层要：

1. 解析客户端协议；
2. 转成内部标准请求；
3. 验证目标供应商能力；
4. 生成上游原生请求；
5. 把上游错误、流事件和 usage 转回客户端协议；
6. 对无法保真转换的字段明确报错或按公开降级策略处理。

静默丢掉图片、工具或 Schema 是最危险的“兼容”。普通网关可以用 Lambda、WASM 或插件实现转换，但转换器需要理解模型协议，这正是 LLM Gateway 的核心工作量。

阶段 7：能转发 SSE，不等于能理解模型流

OpenAI Responses 使用带类型的语义事件；Claude Messages SSE 包含 message、content block、tool use 和 thinking delta。普通反向代理只要不缓冲，理论上可以转发这些字节。

但只做字节透传时，网关无法可靠完成：

• 统一客户端事件格式；
• 计算首个可见内容的 TTFT；
• 拼接分段工具参数；
• 区分文本、推理、工具调用和 usage；
• 在结束事件到达后结算账单；
• 识别上游在 HTTP 200 流中发送的错误事件。

传输层也要为 LLM 工作负载重新设定参数：关闭响应缓冲，避免 idle timeout 截断长生成，为多模态大请求设置明确上限，并把客户端取消向上游传播，避免用户已经离开而模型仍继续生成和计费。

因此要区分两层：

Transport streaming：保持连接、关闭缓冲、转发字节
Semantic streaming：解析事件、转换类型、聚合 usage、判断完成状态

前者是普通代理能力，后者需要供应商协议适配。

阶段 8：重试最容易制造重复答案和重复副作用

传统网关常按 429、502、503 或连接失败重试。但模型请求可能已经：

• 向客户端输出了一半答案；
• 生成并发送工具调用；
• 触发异步图片或视频任务；
• 在上游产生了计费；
• 写入了会话状态。

一个相对安全的边界是：

建立上游连接失败、尚未有可见输出
→ 可按策略切换渠道

已向客户端发送首个可见 Token 或工具调用
→ 不应透明重放整次请求

这不是绝对规则：有幂等键、可恢复流或明确任务状态机时可以更精细。但“任何 5xx 都重试”不适合模型流。

Nbility 的 Relay 主循环按 RetryTimes 选择渠道，并通过 shouldRetry 结合错误属性、剩余次数和状态码规则判断是否继续；渠道亲和失败还有单独的跳过重试逻辑。文章不把这写成“永不重复”的保证，而是说明为什么模型网关必须把重试与响应状态关联起来。

阶段 9：HTTP 200 之后才知道这次请求多少钱

普通 API Gateway 的常见计量单位是：

• 请求数；
• 数据传输量；
• 方法或套餐；
• 网关处理时间。

模型账单通常由响应 usage 决定：

普通输入 Token
+ 缓存写入 Token × 写入倍率
+ 缓存读取 Token × 读取倍率
+ 输出 Token × 输出倍率
+ 推理 / 音频 / 图片 / 工具附加项

上一篇Prompt Caching 账单回放已经展示，仅把 prompt_tokens 乘单一价格会错过缓存写入和读取。

流式接口更麻烦：usage 可能只在结束事件或额外 Chunk 中出现。网关必须在流结束、客户端断开和上游异常之间保持结算一致性，并保存供应商原始 usage 以便复核。

Nbility 当前计费实现已区分：

• 普通输入与输出；
• OpenAI cached/write Token；
• Claude cache creation/read 及 5m/1h 写入；
• 图片、音频、推理和工具附加项；
• 模型倍率、分组倍率和阶梯表达式；
• 实际请求模型、上游模型、渠道与重试记录。

这类结算并非通用 API Gateway 默认知道的业务语义。

阶段 10：从 Latency 升级为 TTFT、Token 和成本

AWS API Gateway 的官方 CloudWatch 指标包含 Count、4XXError、5XXError、Latency 和 IntegrationLatency。这些对模型 API 仍然有用，但不够回答：

• 用户多久看到第一个 Token？
• 每秒输出多少 Token？
• 哪个模型、渠道和供应商处理了请求？
• 输入、输出、缓存和推理 Token 各是多少？
• 一次重试增加了多少成本？
• 同一个公开模型别名的质量和错误率是否发生漂移？

推荐把观测分三层：

层	指标
HTTP	QPS、4xx/5xx、总延迟、连接错误、响应大小
模型	TTFT、总生成时间、Token/s、停止原因、工具调用、缓存命中
业务	单请求成本、预算消耗、任务成功、重试后成功、用户反馈

LLM Gateway 不应承担任务质量的全部判断，但至少要保留把 HTTP 请求关联到模型与账单的 Trace。

逐阶段代码追踪结果

文章配套脚本输出 10 个阶段：

阶段	普通网关起点	为什么需要模型语义
authenticate	原生	上游凭据与用户 Key 分离
rate_limit	原生	TPM、模型预算和分组策略
parse_request	自定义转换	messages、tools、多模态
map_model	自定义路由	别名、能力和供应商模型
select_channel	负载均衡	配额、价格、缓存亲和性
translate	插件	原生协议不等价
stream	字节转发	事件、工具参数、usage
retry	状态码重试	可见输出和副作用边界
settle_usage	自定义计量	Token 和缓存分项价格
observe	延迟/状态指标	TTFT、模型、渠道和成本

这张表的结论不是“必须购买一个新网关”。它说明：团队要么在现有 Gateway 上构建这些 LLM-aware 组件，要么采用已有实现。架构边界由职责决定，不由产品名字决定。

什么时候普通 API Gateway 就够了

以下情况不必急着增加 LLM Gateway：

• 只调用一家供应商和一个模型；
• 客户端直接使用供应商原生协议；
• 没有按用户做 Token 预算或转售计费；
• 不需要跨供应商转换、故障切换或统一审计；
• 普通网关只负责外围 TLS、认证、WAF 和粗粒度限流；
• 业务服务已经可靠处理 usage、重试和日志。

这时继续使用现有网关更简单。

什么时候独立 LLM Gateway 开始划算

通常在这些信号同时出现时：

• 两家以上供应商或多套凭据；
• 客户端需要一个稳定协议；
• 模型别名与实际供应商需要解耦；
• 要按 Token、缓存或多模态计费；
• 需要模型/渠道级健康、预算和审计；
• 多个团队开始重复开发相同适配器；
• 需要对 429/5xx 做受控故障切换；
• 必须从一条日志重建完整请求成本。

此时 LLM Gateway 是共享的模型接入层，而不是替代 WAF、服务网格或业务后端。

部署时不要强行二选一

常见组合是：

Internet
→ CDN / WAF
→ 普通 API Gateway（身份、TLS、粗限流）
→ LLM Gateway（模型协议、路由、usage、计费）
→ OpenAI / Claude / Gemini / 自托管模型

也可以让一个可扩展网关同时承担两层，只要团队能维护插件与升级边界。Kong 的 AI Proxy 就是在通用 Gateway 上增加模型供应商请求转换、认证、负载均衡、流式、日志和 usage 等 AI 能力的官方例子，证明两种类别并非互斥产品。

评估清单

选择或自建时，别只问“支持多少模型”，而要实际验证：

• 客户端和上游分别支持哪些协议面
• Tools、图片、音频和 JSON Schema 是否保真
• SSE 是否关闭缓冲并能处理供应商错误事件
• 已输出 Token 后是否禁止危险透明重试
• 模型别名是否保留原请求模型与实际上游模型
• 渠道选择是否考虑权限、能力、配额和健康
• usage 是否保留原始字段并可重建账单
• 缓存读取和写入是否分别计价
• 日志是否包含 TTFT、模型、渠道、重试和成本
• 不支持的字段是否明确报错，而非静默丢弃
• 敏感 Prompt 是否默认不进入普通访问日志
• 网关故障时是否有明确的降级和旁路策略

结论

LLM Gateway 不是“专门转发 OpenAI URL 的 Nginx”，普通 API Gateway 也不是“完全不懂 AI 的旧技术”。两者共享大量 HTTP 基础能力，真正的分界是网关是否把模型协议、模型选择、流事件、Token usage 和模型成本作为一等语义。

从一条请求看：

• 前两步认证与粗限流，普通网关已经很好；
• 中间的解析、映射、协议和流事件需要模型适配；
• 末尾的 usage 结算和模型观测决定能否长期运营。

如果你的团队已经在现有网关里维护这些模块，那你实际上已经在构建 LLM Gateway。如果不想重复维护多供应商适配，Nbility 提供统一模型入口、渠道映射、流式转发、重试、用量日志与分项计费；可从 Nbility 查看，或在工单中心申请小额测试额度。

官方资料

• What is Amazon API Gateway?
• API Gateway throttling
• API Gateway CloudWatch metrics
• Envoy HTTP connection management
• Kong AI Gateway
• Kong AI Proxy
• OpenAI streaming responses
• Claude streaming Messages