网关容量要用连接数来算
推理网关扛的是一批「打开后长时间不关闭」的流式连接：一次生成可能持续十几秒到几分钟，这段时间连接一直占用着。所以容量口径不是每秒请求数，而是同时驻留的连接数，近似等于请求到达速率乘以平均生成时长。按请求数估算会严重低估需求——同一个每秒请求数，在长生成场景下对应数倍的连接。
基本信息
| 核心口径 | 常驻连接数 ≈ 请求到达速率 × 平均生成时长 |
|---|---|
| 进程上限 | 文件描述符数量限制（ulimit -n） |
| 反向代理上限 | 工作进程数 × 每进程连接数 |
| 上游连接 | 与引擎之间保持的长连接数量 |
| 扩容优先级 | 网关扩容成本远低于引擎，应保证它不是先打满的一环 |
典型使用场景
- 新模型上线前评估：生成时长变化的模型会显著改变网关连接需求
- 流式改造：从一次性返回改为流式返回后，连接驻留时间大幅延长
- 高峰预案：按历史峰值连接数推算需要多少副本与多高的进程上限
- 故障排查：出现连接被拒或超时时，先确认是连接数耗尽还是引擎过载
- 配置审查：核对工作进程数、每进程连接数与上游长连接是否匹配
容量核对
容量核对
ulimit -n # 当前进程文件描述符上限
ulimit -Hn # 硬上限，决定了可调整的天花板
ss -s # 系统级连接统计概览
ss -tn state established '( sport = :443 )' | wc -l # 当前活跃连接数
# 反向代理侧：连接容量上限 = 工作进程数 × 每进程连接数
# 常驻连接估算：平均生成时长（秒）× 到达速率（每秒请求数）
# 上游长连接数应与引擎可接受的并发保持同一量级口径对比
| 口径 | 适用场景 | 低估风险 |
|---|---|---|
| 每秒请求数 | 短请求、一次性返回 | 长生成场景下严重低估连接需求 |
| 常驻连接数 | 流式长连接 | 需要准确的生成时长分布支撑 |
| 并发生成数 | 引擎侧容量规划 | 与网关连接数口径不同，不能直接互换 |
| 文件描述符上限 | 单进程资源边界 | 达到上限后新连接被拒，表现为随机失败 |
| 上游长连接数 | 网关到引擎的链路 | 过少会频繁重建连接，过多会超出引擎承受范围 |
文件描述符上限要同时看软限制与硬限制：只调软限制会被硬限制挡住，容器环境下还要确认运行时对上限的处理方式。
网关扩容成本远低于引擎：先保证网关不先于引擎打满，出现连接被拒时优先横向增加副本并放宽进程限制。