性能与容量规划
AISIX AI 网关的数据面是编译型 Rust 代理，因此自身给请求增加的延迟很低。本页给出了参考机器上的实测代理延迟和吞吐量，并提供一个用于按流量估算 CPU 的公式。
这些 数据采用与 Kong、LiteLLM 和 TensorZero 公开基准相同的测试模式，便于横向参考。测试中，AISIX 在专用 AWS c7i.4xlarge 上固定使用 4 vCPU，代理兼容 OpenAI 的 /v1/chat/completions 请求，请求包含约 1000 Token 的提示词。上游是接近零延迟的 mock 服务，且未启用流量控制策略。因此，报告的延迟基本就是网关自身开销。
实测网关延迟
在低到中等负载下，网关自身处理延迟保持在亚毫秒级；随着 CPU 使用率升高，延迟也会增长。由于测试上游约 0.07 ms 即返回，下表中的网关延迟可以视为 AISIX 叠加到真实上游调用上的额外开销：
| 输入负载 | 吞吐量（req/s） | 网关延迟 p50 / p95 / p99 |
|---|---|---|
| 轻负载（20%） | 5,700 | 0.31 / 0.51 / 0.59 ms |
| 中等负载（40%） | 11,300 | 0.52 / 0.89 / 1.04 ms |
| 繁忙负载（60%） | 17,000 | 0.82 / 1.37 / 1.69 ms |
| 高负载（80%） | 22,600 | 1.12 / 2.14 / 2.54 ms |
| 饱和 | 28,300 | — |
也可以通过减去同速率下直连上游的延迟来隔离网关开销。按这种方式计算，轻负载下 p50 开销为 0.24 ms，高负载下为 0.99 ms。真实 LLM 调用通常需要数百毫秒到数秒， 因此端到端看，这部分网关开销可以忽略不计。
吞吐量与 CPU
在 4 vCPU 上，单个 AISIX 实例可以为该工作负载支撑约 28,300 req/s。CPU 使用率几乎随请求速率线性增长：
CPU% ≈ 14 + 0.0144 × (req/s) # 每个实例，以单个 vCPU 的百分比表示
这大约等价于每个请求消耗 0.14 ms 的单核 CPU 时间，再叠加少量固定运行时成本。该线性拟合适用于测试中的 20-80% 负载区间。
接近饱和时，曲线会受到 4 vCPU 上限影响而变平。28,300 req/s 峰值约消耗 383% CPU，而不是朴素外推得到的约 421%。这也是容量规划应低于饱和点的原因之一。吞吐量可以水平扩展：可以给实例增加 vCPU，也可以在负载均衡器后增加副本。
流式响应
对于基于服务器发送事件（SSE）的流式响应，AISIX 会在上游返回 Token 时立即转发给客户端，而不是缓冲完整响应。首 Token 时间的额外开销约为 0.65 ms，总流持续时间与上游一致。网关不会持有流。
规划部署规格
可以用以下公式估算单个实例在目标请求速率 Q（req/s）下所需的 vCPU：
vCPUs ≈ (14 + 0.0144 × Q) / 100
| 目标吞吐量 | vCPU（约） |
|---|---|
| 5,000 req/s | ~0.9 |
| 10,000 req/s | ~1.6 |
| 25,000 req/s | ~3.7 |
| 50,000 req/s | ~7.3 |
| 100,000 req/s | ~14.5 |
请结合以下建议使用该估算结果：
- 预留余量。按约 70-80% 饱和度规划，而不是按 100% 饱和度规划，这样突发流量下延迟仍能保持较低水平。
- 通过扩容保障高可用和总吞吐。在负载均衡器后运行多个副本；增加副本时，单实例开销仍保持稳定。
- 考虑流量控制成本。上述数据是纯代理基线。认证、限流、安全护栏、缓存和请求日志都会增加每个请求的处理工作。请在启用实际策略集后重新测量。
- 使用有代表性的请求形态做基准测试。更大的提示词和响应体会增加单请求成本；流式和非流式也不同。确定容量前，请使用有代表性的流量做基准测试。
测试环境
参考机器是专用 AWS c7i.4xlarge（16 vCPU）。AISIX 固定运行在 4 vCPU 上，负载生成器和接近零延迟的 mock 上游运行在独立 CPU 核上。这样的隔离可以避免上游和负载生成器成为瓶颈。报告的延迟是在未附加策略的情况下，给定速率下网关自身的开销。实际结果会随硬件、请求形态和已启用策略而变化。