API 网关和负载均衡器（Load Balancer）是企业 IT 里最常被搞混的两个东西。一个"横评"纵览，先把它们的本质关系摆清楚，再用六个维度逐项展开。
一句话本质区别
- 负载均衡器：在多台"长得一样的服务器"之间均匀分发请求
- API 网关：在多种"长得不一样的服务/供应商"之间按策略路由请求
一个是"分流量"，一个是"分任务"。
五张图认清两者关系
图 1：分层位置
客户端 ↓ [ 负载均衡器 L4 ] ← 网络层，按 IP/端口/连接分发 ↓ [ 负载均衡器 L7 ] ← 应用层，按 URL/Header/Cookie 分发 ↓ [ API 网关 ] ← 业务层，按用户/项目/凭据/路由策略分发 ↓ 后端服务 / 供应商 API两个层次不重叠、不替代，可以并存也可以独立存在。
图 2：治理对象
| 设备 | 看得到的信息 | 看不懂的信息 |
|---|---|---|
| 负载均衡器 | URL、IP、端口、连接数 | 用户身份、业务语义、调用配额 |
| API 网关 | 上面所有 + 用户身份 + 业务语义 + 调用配额 + Token | 服务器物理状态 |
图 3：典型产品对照
| 类目 | 经典产品 | 用途 |
|---|---|---|
| 硬件负载均衡器 | F5 BIG-IP、A10 | 运营商、银行、传统大企业 |
| 软件负载均衡器 | LVS、Nginx、HAProxy | 互联网主流方案 |
| 云负载均衡器 | AWS ALB/NLB、阿里云 SLB | 云上业务入口 |
| 服务网格负载均衡 | Envoy、Istio Sidecar | 服务间流量 |
| 传统 API 网关 | Kong、APISIX、Spring Cloud Gateway | 微服务入口治理 |
| AI 网关 | MAI Gateway、LiteLLM、NewAPI | 大模型 API 治理 |
图 4：典型部署形态
只用负载均衡器（轻量场景）：
客户端 → Nginx → [服务器A, 服务器B, 服务器C]负载均衡器 + API 网关（典型企业架构）：
客户端 → 云负载均衡器 → API 网关 → [服务A, 服务B, 服务C]全栈（大型企业）：
客户端 → CDN → 边缘负载均衡 → 云负载均衡 → API 网关 → 后端服务 ↓ 服务网格（内部）图 5：判断"该用哪个"决策树
问 1：要分发的后端是不是"一样的服务器"？ ├─ 是 → 负载均衡器 └─ 否 → 问 2 问 2：要不要按用户/身份/业务规则分发？ ├─ 是 → API 网关 └─ 否 → 问 3 问 3：要计费、按 Token 计量、按供应商路由？ ├─ 是 → AI 网关 └─ 否 → 普通 API 网关或服务网格六维度对照表
| 维度 | 负载均衡器 | API 网关 |
|---|---|---|
| 治理对象 | 网络包 / TCP 连接 / HTTP 请求 | 业务请求（含身份、语义、配额） |
| 层次 | OSI 4 层（TCP）或 7 层（HTTP） | OSI 7 层之上的"业务层" |
| 路由依据 | IP、端口、URL、连接数 | URL + 用户 + 角色 + 项目 + 策略 |
| 状态保持 | 通常无状态（少数场景 session 保持） | 通常有状态（配额、会话、限流窗口） |
| 凭据管理 | 通常不做 | 必须做（API Key / JWT / OAuth） |
| 协议适配 | 透传 | 转换（gRPC↔HTTP、REST↔GraphQL 等） |
关键观察：负载均衡器是"网络设备视角"，API 网关是"业务治理视角"——一个管"流量分布"，一个管"业务规则"。
API 网关能做到而负载均衡器做不到的六件事
- 按用户身份路由（“张三是客服，转到客服模型”）
- 按项目配额限流（“项目 A 本月预算 ¥30000，超了拒绝”）
- 按 Token 计费（“这次调用 850 Token × ¥0.012/1K = ¥0.01”）
- 按业务规则改请求（“客服场景去掉 system prompt 中的 JSON 输出要求”）
- 聚合多服务调用（“一次查询合并调 5 个后端”）
- 按业务维度留痕（“项目A × 用户B × GPT-4 × 输入摘要”）
负载均衡器能做到而 API 网关不需要做的四件事
- 服务器健康检查（ping/tcp/http）
- 长连接管理（HTTP keep-alive、连接复用）
- SSL 卸载（终结客户端 TLS 连接）
- DDoS 防护（连接数限制、CC 攻击拦截）
观察：负载均衡器擅长的是"网络连接级"的工作，API 网关擅长的是"业务请求级"的工作，两者天然互补。
实际架构：两者通常并存
大部分企业生产环境的真实形态：
客户端 ↓ (TLS 终结) [ 云负载均衡器 ] ← 处理 SSL、连接复用、健康检查 ↓ [ API 网关 ] ← 处理鉴权、配额、路由、计量 ↓ [ 后端服务集群 ]两者不是竞争关系，是分层关系——负载均衡器在前负责"网络入口"，API 网关在后负责"业务入口"。
AI 时代的新关系
在大模型调用场景下，这个分层进一步细化：
客户端 ↓ [ 云负载均衡器 ] ← 网络层 ↓ [ AI 网关 ] ← 业务层 + Token 计量 + 多供应商路由 ↓ [ 供应商负载均衡 ] ← 跨多家供应商的分发（部分网关内嵌此能力） ↓ [ GPT / Claude / DeepSeek / 自研模型 ]AI 网关在自身内部就包含了多供应商的负载均衡——既是 API 网关，也是供应商级 LB。两个角色合一是 AI 时代的新特征。
一句话总结
负载均衡器管"流量分布"，API 网关管"业务规则"。两个层次不同、对象不同、能力不同，现实中通常并存而非互斥。
MAI Gateway 作为 AI 网关产品，在传统 API 网关的"业务规则"之上多承担了"供应商级负载均衡"和"Token 计量"两件事——这三个职责收敛到同一层，是大模型时代入口层演化的明确方向。
