AI 中转站搭建需要什么服务器？网关配置、并发与带宽估算
区分 API 请求转发与本地模型推理，按平均在途请求、内存增量、连接数和字节量估算服务器需求，附模拟上游验收步骤与瓶颈判断表。
只把请求转发给远端模型的 API 网关，通常不需要为了“AI”购买 GPU；真正运行模型推理的机器则要另算模型、上下文和并行请求的资源。先画清楚这条边界，再决定服务器配置，比直接照抄“几核几 G 支持多少人”更可靠。
本文讨论容量估算与验收，不推荐固定云服务器套餐。所有数字都是假设算例，不是某中转站或某台机器的实测结果。
1. 先确认模型到底在哪台机器运行
| 部署方式 | 这台机器主要承担什么 | 选配置时先看什么 |
|---|---|---|
| 网关调用远端 API | HTTPS、鉴权、路由、请求转发、计费与日志 | CPU、内存、连接数、数据库和网络 |
| 网关与本地模型部署在同机 | 上述工作，加上模型加载与推理 | 模型运行时要求、内存或显存、上下文与并行度 |
| 网关、数据库、模型分开部署 | 各层独立工作，经网络互相调用 | 每一层的容量和连接，不能只看网关机器 |
纯转发本身不要求 GPU。如果还在网关机器上做本地嵌入、重排、图片处理或其他推理，就不能再按“只转发”估算。能否只用 CPU 推理、需要多少显存，也取决于模型和运行时，不能把 GPU 当成所有本地模型的绝对要求。
Ollama 官方 FAQ 说明，并行请求和上下文长度会影响所需内存；这属于推理层成本，不能拿网关程序的内存占用替代它。[1]
2. 把“用户人数”换成请求负载
先记录四个数：每秒进入的请求数、请求从进入到结束的平均停留时间、单次请求和响应的字节数、同时进行的请求数。人数不能直接代替负载：一个后台任务可能连续调用，很多注册用户也可能同时闲置。
在流量稳定、没有持续积压的统计窗口内，可以用下面的关系估算平均在途请求数：
平均在途请求数 ≈ 每秒请求数 × 平均停留秒数。
假设每秒 2 个请求，每次平均持续 30 秒，平均约有 60 个在途请求。如果上游变慢到 60 秒，而入口仍然每秒进入 2 个请求，稳态下会变成约 120 个。这个数既不是最高并发，也不是容量保证；突发、重试和长尾请求还需要单独观察。若队列一直增长，当前测量窗口就不能当作稳态。
流式请求应计到流结束或取消，不是收到第一个 Token 就算完成。首字出现得快，连接仍可能保持很久。不要把 p95 延迟代入平均值公式，再称其为精确的“p95 并发”。
3. 按四类资源分别找瓶颈
CPU：看网关实际做了多少工作。 TLS、JSON 转换、压缩、鉴权和日志处理都会消耗 CPU。异步转发等待上游时不等于一直占满 CPU，因此低 CPU 也不能证明还有足够容量：连接、内存或数据库可能先达到上限。
内存：区分固定占用与每个在途请求的增量。 先测空闲基线，再在同一请求大小和响应模式下分档提高并发，记录进程或容器实际使用量。不要把累计分配字节当作当前驻留内存，也不要把多次实验使用的不同指标混在一起。
假设网关基线为 100 MiB，在某一受控测试区间内每个在途请求的增量约 0.35 MiB：60 个请求时估算为 121 MiB，120 个时为 142 MiB。这只是该区间的线性近似，未包含操作系统、数据库、其他服务和额外安全余量；不能据此购买 142 MiB 内存的机器。大请求、完整响应聚合、重试副本或数据库写入可能打破线性关系。
连接与文件描述符：不是一个请求永远只占一条连接。 在简单 HTTP/1.1 代理、没有复用的假设下，一个活跃请求可能同时占用客户端到代理、代理到上游两段连接。NGINX 的 worker_connections 包含上游连接，也受打开文件数限制。[2] HTTP/2 多路复用、连接池和多层网关都会改变对应关系，因此不能直接把配置值当作可服务人数。
网络与磁盘：按字节和保留时间算。 假设每个请求体 100 KiB、响应体 20 KiB，每秒 2 次；若两段转发都经过同一机器网卡，则出站应用数据约为 120 × 1024 × 2 = 245,760 字节/秒，即约 1.97 Mbps。入站还会有对应流量；TLS、HTTP 头、重试和其他服务未计入。云平台按哪一方向计费、是否有限速，要单独看套餐规则。这里 KiB 为 1024 字节，Mbps 使用十进制。
日志和数据库的磁盘占用还取决于记录内容与保留天数。不要为了压测把完整提示词、响应和密钥都写进日志。
4. 先用本地模拟上游做阶梯验收
不必一开始就向付费模型发送大量请求。可在受控测试环境让模拟上游返回固定大小的假数据，并设置响应持续时间、分块间隔、错误和中断场景。测试客户端也应在自己控制的环境中运行，不把第三方服务当压测目标。
建议按下面顺序执行，每档都使用预先约定的请求上限、时长和停止条件：
- 空闲时记录网关、数据库和系统基线，确认当前进程及连接限制。
- 从较低并发开始逐档提高；明确压测工具限制的是并发数还是请求到达速率，不把两种负载混为一谈。
- 固定小请求验证基础转发，再单独增加请求大小、响应持续时间和流式分块，不一次改变所有变量。
- 记录实际到达率、完成率、平均及长尾耗时、在途数、队列等待、内存、CPU、连接数、数据库延迟与错误数。
- 测试客户端取消、慢客户端和上游中断后资源是否释放；停止发请求后，观察在途数和队列是否回落。
- 一旦出现持续排队、内存不断增长、连接耗尽或不可接受的错误，停止加压并保存该档数据。
NGINX 响应缓冲开启时，响应可能留在内存缓冲区，超过相关缓冲能力的部分还可能写入临时文件；关闭缓冲会改变转发行为，并不等于整个应用完全不占缓冲内存。[3] 保持测试配置与计划上线配置一致，才能比较结果。
模拟上游只能验证本地链路，不能证明真实上游的可用率、账户额度或模型速度。本教程的算例已做本地算术与离散请求模拟核对；没有提供云服务器跑分，也没有执行真实付费 API 压测。
5. 根据现象决定升级哪一层
| 观察到的现象 | 优先核查 | 不能直接下的结论 |
|---|---|---|
| CPU 不高，排队不断增长 | 应用并发上限、上游耗时、数据库池或连接限制 | 不能认定加 CPU 一定有效 |
| 长请求越多，内存越高 | 缓冲、历史消息副本、慢客户端、取消后的清理 | 不能只按短请求测试配置 |
| 连接报错，但还有空闲内存 | 代理连接上限、文件描述符、连接池 | 不能无限增大上限而不测资源 |
| 只有真实上游返回 429 | 上游账户、模型或渠道限制 | 本地升级不能直接提升上游配额 |
| 流式总在类似空闲间隔后中断 | 各层读取超时、心跳和缓冲 | 不能只看整个请求总时长 |
例如 NGINX 的 proxy_read_timeout 约束的是两次读取之间的间隔，不是整个响应总时长。[3] 延长超时也可能让在途请求保留更久，应重新检查容量，而不是只修改一个数字。
只有测量表明本地资源是瓶颈，才决定增加 CPU、内存、带宽，或者把数据库与推理拆开。容量预算仍需为波动留余量；没有适用于所有网关的固定余量比例或“几核支持多少并发”结论。
延伸阅读：429 与并发控制、流式输出中断排查、正式上线前检查清单。这些步骤分别处理上游限制、协议问题和上线边界，不替代本机容量验收。
官方资料与适用范围
- [1] Ollama FAQ：并发请求与模型内存。仅用于说明本地推理资源与并行度的关系，不泛化为其他运行时的固定参数。
- [2] NGINX 核心模块：worker_connections 与 worker_rlimit_nofile。
- [3] NGINX 代理模块：响应缓冲与读取超时。
资料核对日期：2026-10-10。具体网关实现、操作系统、协议和部署拓扑不同，需要重新测量。