推理网关的限流策略直接决定了显卡是稳定输出还是频繁掉线，核心结论是：在请求到达显卡之前，用队列和并发控制把流量“削峰填谷”，才能让GPU始终工作在安全水位线上。
显卡为什么总在深夜宕机
后端显卡被压垮,多数时候不是算力不够，而是流量到达的方式太粗暴，想象一下，上千个推理请求同时打到一张A100上，显存瞬间被占满，计算单元排队排到死锁，驱动直接报错重启，业内专家指出，这种“暴冲式”流量是显卡故障的头号诱因。
具体表现有三层：
- 显存撑爆：每个请求都要分配KV Cache，并发数一上去，显存直接OOM
- 算力挤兑：矩阵运算单元被切得七零八落，单个请求延迟飙升三到五倍
- 雪球效应：显卡忙不过来，客户端疯狂重试，反而把新请求继续灌进来
限流不是限制业务，而是保护显卡的呼吸节奏。
推理网关限流是什么
推理网关夹在客户端和GPU算力池之间,干的活就是交通警察，它不计算具体业务，只看“当前显卡还能接多少活”，每张显卡的显存总量、剩余算力、当前排队的任务数，网关心里都要有本账。
全局限流与单卡限流的区别
全局限流管的是网关入口,比如每秒最多放进来200个请求，单卡限流管的是每张卡的负载，比如每张A100最多同时跑8个推理任务，场景不同，侧重点也不同：
| 场景 | 合适的限流方式 | 原因 |
|---|---|---|
| 单卡服务一个模型 | 全局限流 | 不需要关心卡间调度 |
| 多卡负载均衡 | 双层限流 | 防止某张卡被打满其余闲置 |
| 多模型混部 | 按模型限流+全局限流 | 防止一个模型抢占全部显存 |
行业共识认为,生产环境至少要配两层限流，单层策略在流量波动大的时候基本扛不住。
排队机制比直接拒绝更体面
限流不等于丢弃请求,网关收到超出显卡能力的请求，先放进队列排队，设置一个合理的超时时间，比如排队超过3秒就返回“繁忙”提示，而不是让客户端无限等待。
排队参数有三个必须调：
- 队列长度：过长会导致下游延迟爆炸，一般建议不超过并发数的两倍
- 等待超时：大模型单次推理往往在秒级，等待超时建议设在3到5秒
- 队头阻塞处理：长请求后面全是短请求会互相拖累，需要按预估耗时分级
大模型推理性能优化方案中的限流阈值怎么定
显卡的承受能力不是拍脑袋编出来的,得通过压测摸清底数，具体操作路径如下：
- 拿单张显卡跑基准测试,记录不同并发下的平均时延和P99延迟
- 找到“拐点”继续增加并发，延迟开始指数级上升的那个点
- 把拐点并发数乘以0.7作为生产环境的并发上限，留出30%缓冲
- 按每路请求的显存占用（KV Cache大小）反推最大并发：显存总量除以单路占用
比如一张24GB显存的显卡,单路请求占用2.5GB，那理论上最多跑9路左右，再扣掉模型权重占用的空间，实际安全并发可能在6到7路。
QPS与并发数是两回事
QPS高不等于并发高，如果单次推理耗时300毫秒，每秒能处理的请求数（吞吐）其实是并发数除以单次耗时，也就是说，6路并发撑满，QPS大概在20左右，算网关限流阈值时，先确定并发上限，再换算QPS，顺序不能反过来。
动态限流更省显卡
固定阈值简单,但浪费资源，显卡空闲的时候多放请求进来，快撑不住的时候收紧入口，这比死板的限流策略好用得多。
- 每隔5秒采集一次显卡利用率
- 利用率低于60%，限流阈值上调20%
- 利用率高于85%，限流阈值下调一半
- 连续3次采样都超过90%，直接进入拒绝模式
动态限流适合负载波动大的线上服务,比如白天业务高峰、凌晨明显回落的情况，能把显卡的利用率拉高不少。
多卡场景下的限流协同
VLLM这类推理框架支持多卡推理,但网关默认是按“总并发数”限流的，这在实际部署中会出问题。
举例：4张显卡组成一个实例，网关限流设置为并发32，按说每卡分配8路，但实际调度时，有些卡可能分到12路，有些卡才4路，不均衡的负载照样会把单卡打崩。
正确的做法是：
- 网关侧按“每卡并发”配置限流，而不是按实例总并发
- 给推理框架传
--max_num_seqs参数，从框架层面兜底 - 框架内部的调度策略和网关限流策略要联动,不然两层策略互相打架
有个容易踩的坑：配了网关限流但是忘了配框架内部的并发参数，导致网关放进来30个请求，框架一次性全部加载到显存里，显卡照样崩。
显卡OOM排查与限流的关系
显卡OOM（显存不足）往往不是显存真的“用完”，而是请求并发瞬间超出预期，排查的时候不要光盯着显存监控，还要看网关是否生效：
- 查询网关日志里是否出现“upstream_connect_error”或“429”状态码
- 看推理框架日志有没有“CUDA out of memory”字样同时出现
- 对比网关放行量和框架接收量,如果二者不一致说明限流没生效
限流触发后的表现要符合预期
限流挡下来的请求,返回的错误码和响应超时时间必须提前约定好，客户端写代码的时候通常会区分“服务不可用”和“系统繁忙”两种状态，语义不清楚会导致客户端反复重试，反而加重网关负担。
推荐的做法是：
- 限流返回503,并带上
Retry-After: 5请求头 - 客户端收到503后做指数退避重试,而不是立即重连
- 网关侧记录被限流的请求数,方便后续调参
单机部署的限流配置实例
单机跑开源大模型的人越来越多,硬件规格参差不齐，选显卡的时候，大模型推理性能优化方案显卡价格差异很大，从几千块的消费级卡到几万块的涡轮卡都有，但无论什么卡，限流配置的逻辑是通用的。
以一台配备4张显卡、显存总量96GB的服务器为例：
- 模型加载占掉40GB,剩余50GB作为KV Cache
- 单路请求KV Cache占用2GB，则最大并发25
- 预留10%显存余量，安全并发设为22
- 网关配置单卡并发5到6,总并发上限20
这类配置在大多数情况下跑得稳,前提是压测验证过。
限流参数的调优路径
第一次上线,不确定参数是否合理，可以按以下步骤操作：
- 将并发限流设置为压测拐点的60%，观察一周
- 显卡平均利用率高于70%且无OOM，则上调10个百分点
- 出现OOM或者P99延迟超过500毫秒,回调10个百分点
- 每周观察一次趋势,持续优化一个月
调参的时候要记变化,不然改来改去容易乱。
与负载均衡配合
网关限流配合轮询或最小连接数策略,能够做到流量均匀分发，遇到单个实例异常时，网关还要能自动摘除该实例，避免请求继续往坏掉的显卡上打。
健康检查建议做两层：
- Liveness探针：每30秒检查进程是否存活
- Readiness探针：每10秒检查显卡是否还能接受新任务，显存占用超过阈值就标记不健康
限流背后的运维保障
限流只能防过载,不能防硬件故障，显卡在长时间高负载下，温度会逐步爬升，显存颗粒老化和散热性能衰减，都是客观规律，需要额外安排的是：
- 每天检查显存报错（通过
nvidia-smi查看ECC错误计数） - 每周记录一次显卡功耗和温度基线
- 关注供电模块温度,超过85度就该考虑降频保护
低成本场景的限流思路
预算有限,显卡本身性能不足，花大价钱买企业版网关管理软件完全没必要，开源的Nginx + Lua脚本、Apache APISIX、Traefik都能实现基础的并发限制功能。
以Nginx为例,配置一个基础的连接数限制：
limit_req_zone $binary_remote_addr zone=llm_limit:10m rate=20r/s;再加一层上游最大连接数限制：
upstream gpu_backend {
server 192.168.1.10:8001 max_conns=6;
server 192.168.1.11:8001 max_conns=6;
}两层配合,能把即时并发控制在12路以内，对单卡场景够用。
常见问题与排查思路
推理网关限流后后端显卡频繁OOM如何排查
先查网关配置的并发上限是否大于模型实际可承载的并发,很多OOM是因为限流数值配得过高，再把网关日志和显卡日志按时间戳对齐，看OOM的时间点有没有超过限流阈值的请求被放进来，出一条排查命令：grep -E "OOM|429|503" /var/log/gateway.log | tail -100，能快速定位是被限流还是漏放行。
大模型推理性能优化方案中限流对显卡寿命的影响
合理限流降低了热循环频率,有助于延长显卡寿命，长期跑在满载边缘的显卡，故障率远高于工作在60%到80%负载的显卡，限流本质上是在保护硬件，而不是降低性能，只要阈值设置合理，吞吐损失通常在10%以内，换来的稳定性收益远大于这部分性能让步。
显卡OOM多卡推理混部时怎么分配限额
按模型优先级分配,核心业务模型分配60%的显存配额和70%的并发额度，次要模型限制在20%以内，剩余作为缓冲，用网关的多租户限流功能，给每个模型配置独立的并发上限，避免次要模型占用全部资源后核心模型被挤掉。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/623855.html
