Rust 打造全球最快 AI 网关：Antirion 性能实测与架构解析

为什么 AI 网关的速度如此重要

当 LLM 功能从原型走向生产，问题往往从一个 .env 里的 OpenAI key 开始：团队想接入 Claude、周五下午 OpenAI 宕机却没有 fallback、财务追问每个团队的支出、法务担心客户数据泄露到 prompt 里。AI 网关正是为此而生——它站在应用与模型供应商之间，负责路由、降级、限额、预算、护栏与日志。

问题在于，网关位于每一次调用的必经之路上。如果它增加了 20ms 延迟，那么公司每一笔请求都会永远多出 20ms。开源网关 Antirion 的作者正是基于这个前提，用 Rust 从头构建了一个号称全球最快的 AI 网关，并在相同 4 vCPU 机器上与 Go 编写的 Bifrost 进行了对比测试。

AI 网关架构概念图

基准测试：在 5,000 req/s 下的性能差距

作者在简单聊天场景、5,000 req/s 的负载下测试了两款网关：

指标	Antirion	Bifrost 2.2.4	差距
开销 p50	0.53 ms	19.7 ms	低 37 倍
开销 p99	0.95 ms	95.2 ms	低 100 倍
单请求 CPU	247 µs	717 µs	少 2.9 倍
峰值内存	215 MiB	1,389 MiB	少 6.5 倍
空闲内存	41 MiB	498 MiB	少 12 倍
最高持续吞吐	14,000 req/s	3,500 req/s	高 4 倍

在同一测试中，LiteLLM 在该速率下每一个请求都失败了。更值得关注的是负载升高时的表现：在 10,000 req/s 下，Bifrost 虽然仍能响应，但请求开始排队，中位请求等待时间达到 12 秒；而 Antirion 的 p99 仍保持在 2ms 以内。64 并发连接下，Antirion 达到 21,512 req/s，Bifrost 为 6,568 req/s。

作者也坦承公平性：在 1,000 req/s 的轻负载下两者接近——Bifrost p50 为 0.72ms，Antirion 为 0.76ms，属于噪声范围内的平手。差距是在负载增长时才显现的，而这恰恰是网关真正发挥作用的时刻。

九个让性能成立的设计决策

1. 每 CPU 一线程，替代工作窃取

Tokio 默认的多线程运行时会在线程间迁移任务，导致缓存失效和跨线程同步。Antirion 改为每个 CPU 一个数据线程，各自运行单线程运行时：Linux 上每个线程通过 SO_REUSEPORT 组独立监听，内核负责分发连接；一个客户端连接及其派生的任务、到供应商的 HTTP/1.1 连接都停留在同一线程，出站连接池按线程划分，请求从始至终不会唤醒其他线程。

管理层（控制台、Admin API、后台任务）运行在独立的多线程运行时上，不抢占热路径。HTTP/2 是这一模型的薄弱点——单连接可承载数百并发请求，因此 HTTP/2 连接的请求会在数据线程间轮流分散。

工作窃取（Work Stealing） 是 Tokio 等多线程异步运行时的默认调度策略：每个工作线程维护自己的任务队列，空闲线程会从其他线程的队列尾部“窃取”任务执行。这种策略能较好地实现负载均衡，但代价是任务可能在不同 CPU 核心间迁移，导致 L1/L2 缓存失效，并且跨线程的任务转移需要原子操作和同步原语。对于网关这类每请求只做少量计算、却对尾延迟高度敏感的场景，缓存失效和同步开销会被放大。Antirion 的单线程每核模型牺牲了部分动态均衡能力，换取请求全程绑定在同一核心、无跨线程唤醒的确定性，这正是其 p99 开销能压到亚毫秒级的关键之一。

SO_REUSEPORT 是 Linux 3.9 引入的套接字选项，允许多个套接字绑定到同一 IP 与端口，内核在接收连接时按四元组哈希将新连接分发给其中一个监听套接字。配合“每 CPU 一个监听套接字、每个套接字由独立线程处理”，即可实现内核级的连接分流，避免传统 accept 惊群和单点分发瓶颈。

2. 不复制请求体

长上下文 prompt 轻易达到数百 KB，而网关通常只需修改一两个字段（比如重写 model）。作者写了一个小型的 JSON 解析器，一趟完成严格校验（深度限制、重复键、带行列的错误信息）和成员位置记录。出站时请求体由客户端原始字节切片组成，每个片段作为独立帧发送；当供应商与客户端方言一致时，请求体从不被复制。

零拷贝（Zero-copy） 在网络代理中指避免将载荷在用户态缓冲区之间反复复制。典型网关读取完整请求体到内存、反序列化为结构化对象、修改字段后再序列化写出，大 prompt 下会产生多次全量拷贝和额外内存占用。Antirion 的做法是仅用自定义解析器记录各 JSON 成员在原始字节中的偏移，出站时把原始字节按片段（slice）直接作为独立帧写出；只有在需要改写字段时才替换对应片段。这样请求体在方言一致时从不被整体复制，既降低内存带宽压力，也减少因大对象分配带来的延迟抖动。

3. 方言翻译，且不尝试不可能的事

OpenAI SDK 客户端可以调用 Claude，反之亦然。中间层是一个中间表示：每种客户端方言有解码器，每个供应商有编码器。最有价值的技巧是：编码在路由前先做一次 dry run，结果按部署缓存。如果某部署无法服务该请求（比如目标端没有等价特性），它会在首次尝试前就被排除，避免 fallback 浪费一次往返才发现注定失败。

方言（Dialect） 在此指不同模型供应商 API 的请求/响应格式差异，例如 OpenAI 的 /v1/chat/completions 与 Anthropic 的 /v1/messages 在消息结构、系统提示位置、工具调用表达、流式事件类型上都不同。网关通过中间表示（IR）解耦：客户端方言解码为 IR，再由目标供应商编码器转为该供应商格式。

Dry run 预检 指在真正发起上游调用前，先用编码器试算一次，判断某部署能否完整表达该请求（例如目标端不支持某类多模态输入或某参数）。若不能，该部署在路由阶段即被剔除，而不是等 fallback 发出后收到错误再重试。这避免了为“注定失败”的请求浪费一次网络往返，在有多供应商 fallback 链时对尾延迟尤为关键。

4. 带提交点的流式传输与字节有界队列

在第一个字节到达客户端之前，上游失败或护栏拦截时仍可切换供应商；之后则不能。因此响应会保持到提交点。此后由专用任务通过按字节（而非按消息）有界的队列中继事件，慢客户端会向上游施加背压，而不是在网关堆积内存。

5. 不可变配置，按代际切换

整个配置（YAML、Admin API 或控制台）针对 JSON Schema 校验，每次变更生成新代际：编译后的快照在阻塞线程上构建、持久化后一次性替换。快照存放在 ArcSwap 中，每个请求在开始时加载一次并持有到结束，配置变更永远不会在一笔请求中途生效，热路径也从不与写配置者争锁。

6. 每笔请求精确计费一次

限额与预算在准入时基于 token 估算进行预留，请求结束时用真实用量精确结算一次，每次上游调用写一行账本。关键细节：每个请求运行在受跟踪的任务上，不绑定连接。客户端中途断开时请求不会被取消，供应商已生成的部分成本仍被计入；任务 panic 时预留会被退还。

7. 规范化键的缓存与单飞

精确缓存以请求体的规范化形式（按 RFC 8785 做 JSON 规范化）为键，键顺序或空白永远不会导致未命中。多个相同请求同时未命中时，只有一个发往供应商，其余等待其结果。

8. 构建系统强制约束的架构

代码分为 8 层共 28 个 crate，每个 crate 只能依赖其下方层级，cargo xtask layers 检查在 CI 中运行，违反规则即构建失败。

9. 不欺骗自己的测量方法

作者指出，代理基准测试最常见的错误是闭环负载：生成器等每个响应回来才发下一个，代理卡顿时生成器随之减速，排队永远不会体现在延迟里（协调遗漏）。测试框架采用开环调度，延迟从计划发出时间算起；生成器和 mock 上游运行在独立机器上；开销通过同一速率下经过网关与直连 mock 的差值计算；三种网关每轮交替运行，取五次中位数；并设定有效性规则剔除不合格的重复。

一个意外发现：自测要求生成器到 mock 的 p99 为 50µs，但在 AWS 上从未通过——同一 placement group 内两台机器之间的裸 TCP 连接 p99 已达 0.5 到 0.8ms。由于开销是减去各重复自身的直连结果，这不影响对比，但说明网络对亚毫秒级数字的影响有多大。

协调遗漏（Coordinated Omission） 由 Gil Tene 提出，指闭环负载生成器中，当被测系统变慢时生成器也同步放慢发送节奏，导致系统本应承受的请求从未被发出，排队延迟在统计中被系统性低估。开环调度则按固定时间表发送请求，无论响应是否返回，延迟从“计划发出时刻”起算，因而能把排队时间如实计入。这是评估网关、数据库等中间件尾延迟时最常被忽视的方法论陷阱。

开环与闭环 的区别可概括为：闭环是“收到响应再发下一个”，贴近部分真实用户行为但会掩盖过载；开环是“按固定速率发”，能暴露系统在压力下的排队与拒绝行为。生产环境流量更接近开环，因此网关基准应以开环为主，闭环仅作补充。

两分钟上手与当前状态

只需要 Docker 和一个 OpenAI 或 Anthropic key，无需配置文件：

docker run -p 8080:8080 -p 8081:8081 \
  -v antirion-data:/var/lib/antirion eliasbiondo/antirion

首次启动会打印控制台 URL 和 admin token。打开 http://localhost:8081/ui/，添加供应商、创建一个名为 chat 的 Model、创建 API key，然后把任意 OpenAI SDK 指向 http://localhost:8080/v1 即可。请求日志会显示每条请求的路由、token、延迟和成本。

Antirion 采用 Apache-2.0 开源协议，当前版本 v0.1.1，仍有粗糙之处。作者在文末提出了几个开放问题：你现在用什么网关，最困扰你的是什么？流式响应应该保持到提交点，还是尽早发出首字节而放弃 fallback？基准测试方法中有什么可以质疑的地方？对这些问题的回答，或许比性能数字更能决定一个网关项目的走向。