10 - 性能与形态代价
本文不给出自测的横向性能数字。文中出现的所有性能数值都是各项目自己的声明，已逐条标注来源。第四节给出一套可复现的压测方法。
前置：02 - 四种形态。本篇是对那四种形态的代价结算。
本篇会用到的词：
| 词 | 意思 |
|---|---|
| RTT | Round-Trip Time，一个网络包往返的时间。同机房通常在 1 毫秒以内，跨区域可能几十毫秒 |
| 序列化 / 反序列化 | 把请求体在「字节流」和「内存对象」之间来回转换。网关要改写请求，就必须先解开再装回去，这是第二块开销的来源 |
| 热路径 | 用户正在等待的那条代码路径。放在热路径上的每一毫秒用户 都能感觉到，所以记账、上报这类事要挪到异步链路 |
| chunk | 流式响应里的一小段数据。网关要逐个处理它们，所以响应越长，这块开销累积得越多 |
| 压测 | 用工具模拟大量并发请求来测量性能。本篇第四节给的是一套可复现的方法，而不是一组结论数字 |
本篇回答：网关到底会让你的请求慢多少？该不该按性能选网关？（结论：绝大多数情况下不该）
一、开销的来源
先把"网关慢"这件事拆开。一次经过网关的 LLM 请求，网关本身贡献的开销只有四块：
关键在于这四块的权重和请求形态强相关：
| 非流式短请求 | 流式长响应 | Realtime WebSocket | |
|---|---|---|---|
| ① 网络跳数 | 占比高 | 摊薄 | 摊薄 |
| ② 协议转换 | 中 | 中（只在首尾） | 低 |
| ③ 策略执行 | 中 | 摊薄 | 摊薄 |
| ④ 流式转发 | 无 | 主导 | 主导 |
一次 30 秒的流式响应里，网关多花 2 毫秒做鉴权毫无意义。但如果它对每个 chunk 都做一次反序列化 + 正则扫描 + 重新序列化，那开销会被输出 token 数直接放大。 这就是为什么 AI 网关的性能问题几乎全部集中在第 ④ 块。
二、LiteLLM 的 Rust 重写
litellm-rust/ 目录已经进了主干。有意思的不是"Python 慢所以换 Rust"这个俗套结论，而是他们只重写了哪部分、以及明确说了不重写哪部分。
官方 README.md 写得很直白：
Python continues to own configuration, retries, routing policy, logging, callbacks, spend tracking, and customer plugins until each Rust path has parity coverage and production evidence.
配置、重试、路由策略、日志、回调、花费追踪、客户插件 —— 全部留在 Python。也就是说 第 03 篇 拆的那六种路由策略、第 04 篇 拆的那套限流，都不在重写范围内。
三个 crate 的分工：
| Crate | 职责 |
|---|---|
litellm-core | Rust 版 SDK：路由入口、类型、provider 转换 、鉴权、实际的 HTTP 调用 |
litellm-ai-gateway | axum 服务器 ＋ WebSocket host，把 HTTP/WS 翻译成 core 的入口调用 |
litellm-python-bridge | PyO3 cdylib，把 Rust 暴露给 Python SDK |
依赖方向是无环的：core ← ai-gateway ← python-bridge。
而 ai-gateway/ARCHITECTURE.md 揭示了第一个被搬走的到底是什么：
The Rust ai-gateway does LLM inference (realtime WebSocket). Spend tracking is an API callback: it POSTs each finished session to the LiteLLM proxy, which records spend and runs the usual callbacks.
Realtime WebSocket。 不是普通的 completion 接口，是那个每秒要转发几十个音频/文本帧、连接一开就是几分钟的实时接口 —— 正好是上一节里第 ④ 块开销占绝对主导的场景。
而且花费统计的处理方式很说明问题：Rust 网关不自己算账，会话结束后 POST 给 Python proxy，让它去记录并跑原有的回调链。
这是一次教科书式的重写：把热路径（每帧都要过的数据搬运）搬到 Rust，把冷路径（每次会话只发生一次的记账）留在 Python 并改成异步回调。既拿到了性能，又没有把五年积累的策略逻辑推倒重来。
对照 crates/python-bridge/src/lib.rs 只有 15 KB —— 桥接层做得很薄，说明边界切得干净。
如果你在做类似的技术决策，这个案例的价值在于它给出了拆分的判据：一次请求里要执行 N 次的逻辑（N 随 token 数增长）搬走，执行 1 次的留下。
三、各项目的性能声明
以下数字全部来自项目方或第三方评测文章，本站未做验证：
| 来源 | 声明 | 类型 |
|---|---|---|
maximhq/bifrost 仓库描述 | "Fastest enterprise AI gateway (50x faster than LiteLLM)" | 项目自述 |
BerriAI/litellm 仓库描述 | "The fastest, litest AI Gateway. Rust core with Python SDK." | 项目自述 |
| 第三方评测文章 | Envoy AI Gateway 转发开销约 1–3 ms | 第三方评测 |
两家都自称最快，这本身就说明这类声明的信息量接近于零。 「50x faster than LiteLLM」没有说明测的是哪条路径 —— 如果测的是非流式短请求的空转吞吐，Go 对 Python 拉开一个数量级毫不意外；但如果测的是一次 30 秒流式响应的端到端延迟，网关开销早被模型推理时间淹没了。
唯一有意义的做法是自己按自己的流量形态测。
四、可复现的压测方法
要让四家可比，必须先把变量控制住。
4.1 不要打真实模型
真实模型的响应时间抖动（几百毫秒到几十秒）会把网关那几毫秒的差异彻底淹没。必须用一个行为可控的假上游：
- 固定 TTFT（比如 50 ms）
- 固定 chunk 间隔（比如 20 ms）和 chunk 数量
- 返回体大小固定
Envoy AI Gateway 仓库里现成就有一个：tests/internal/testupstreamlib/server.go（21 KB），是他们 e2e 测试用的假上游。可以直接拿来当四家共用的基准上游。
4.2 三个必测场景
| 场景 | 参数 | 测什么 |
|---|---|---|
| A. 非流式短请求 | 输入 100 token，输出 50 token，非流式 | 网关固定开销的上限 |
| B. 流式长响应 | 输出 2000 token，20 ms/chunk | 逐 chunk 处理的放大效应 |
| C. 高并发流式 | 场景 B × 500 并发 | 连接管理与内存 |
4.3 三个必测指标
- P50 / P99 额外延迟：
经过网关的耗时 − 直连假上游的耗时。只看 P50 会漏掉 GC 停顿和锁竞争，P99 才是形态差异真正暴露的地方。 - 单位吞吐的内存占用：Python 的每连接开销和 Rust/Go 不在一个量级，场景 C 下差距会很明显。
- 策略开启前后的差值：把限流、鉴权、内容安全逐个打开，看每项各加多少。这一项比总体性能更有决策价值 —— 它告诉你哪个功能不值得开。
4.4 必须同时记录的配置
横向压测最容易犯的错是配置不对等。至少要对齐：
- 是否开启响应体解析（不解析就没法算 token，但会快很多）
- 是否开启访问日志与 tracing（OTel 采样率）
- 连接池大小、keepalive 设置
- LiteLLM 是跑在 Python proxy 还是已经切到 Rust 路径
只要有一条没对齐，得到的就是配置差异而不是形态差异。
五、四种形态的代价小结
回到 第 02 篇 的四种形态，把这一篇的分析叠上去：
| 形态 | 延迟代价 | 真正的代价 |
|---|---|---|
| 库 | 无网络跳数 | 语言绑定；爆炸半径最大（供应链投毒直接落进业务进程） |
| 独立进程 | +1 跳 | 自己就是单点，要做高可用；运维多一个组件 |
| Envoy 扩展 | +1 跳（gRPC 旁路，同机） | 必须有 K8s；问题要在 Envoy / ext_proc / 限流服务三处定位 |
| Wasm 插件 | 代理内，无额外跳 | ABI 受限；跨 VM 协调要自己实现（见 03 篇 的 CAS 租约） |
结论：这四种形态在性能上的差距，远小于它们在运维复杂度和故障模式上的差距。
除非你的场景是 realtime WebSocket 或超高并发流式（也就是 LiteLLM 决定用 Rust 重写的那一类），否则不该按性能选网关。按你的部署环境和团队能维护的复杂度选，然后用第四节的方法验证它没有慢到不可接受 —— 这才是正确的顺序。
全专题结论
| 问题 | 答案 |
|---|---|
| 该选哪种形态？ | 看部署环境，不看性能（02） |
| 路由策略怎么选？ | 后端是外部 API 用最低延迟；是自建 vLLM 集群则都不适用，要做缓存感知路由（03） |
| 多租户怎么做？ | 自研走 Redis Lua，K8s 环境交给 Envoy 限流服务（04） |
| MCP 要不要走网关？ | 后端超过两个就要，工具命名空间和会话聚合自己写代价很高（05） |
| 性能重要吗？ | 只在 realtime / 高并发流式场景重要（本篇） |
一个贯穿全专题的观察：AI 网关正在从"LLM 路由器"变成"Agent 流量控制面"。 四家开源项目里，把 MCP 和 A2A 当一等公民的那两家（agentgateway、Envoy AI Gateway）是最近迭代最快的，而纯 LLM 路由的功能已经基本收敛。
而 Portkey 被 Palo Alto Networks 收购、成为 Prisma AIRS 核心组件这件事（见专题索引），指向的是下一个阶段：这层控制面的价值，正在从"省钱和容错"转向"看得见、管得住、拦得下"。
那正是下一个专题的内容。
← 回到 专题索引 · Agent Infra 板块总览