大模型推理接口限流，防止算力资源耗尽

知识分享

2026-09-21 10:00

6 阅读

大模型推理接口如果没有任何限流，单个用户或脚本就可能占满 GPU 显存和计算队列，导致其他请求全部超时。
本文面向零基础运维，以 Nginx 和常见推理服务为例，说明如何通过限流规则保护算力资源，步骤可直接在测试环境复现。

先确认推理服务的部署方式和瓶颈点

动手限流之前，需要先搞清楚请求是怎么到达模型的。
常见架构有两种：

客户端直接请求推理服务端口，例如 vLLM 或 TGI 默认监听的 8000 或 8080。
客户端请求 Nginx，再由 Nginx 转发到后端推理服务。

如果是第一种，限流要尽量在推理服务自身参数或前置代理上做。推荐统一加一层 Nginx 反向代理，因为 Nginx 的限流模块成熟、配置直观，也方便后续加鉴权。

确认当前架构的命令：

# 查看推理服务监听端口
ss -lntp | grep -E '8000|8080|5000'

# 查看 Nginx 是否在运行
systemctl status nginx

如果 ss 输出显示推理服务直接暴露在公网 IP 上，建议先调整为只监听 127.0.0.1，再通过 Nginx 对外提供服务。

用 Nginx 限制请求速率和并发连接

Nginx 提供两个核心限流能力：limit_req 控制请求速率，limit_conn 控制并发连接数。
下面给出一个可执行的配置片段，路径通常为 /etc/nginx/conf.d/llm-proxy.conf。

# 定义限流区域，按客户端 IP 区分
limit_req_zone $binary_remote_addr zone=llm_req:10m rate=5r/s;
limit_conn_zone $binary_remote_addr zone=llm_conn:10m;

server {
    listen 80;
    server_name your-domain.com;

    location /v1/chat/completions {
        limit_req zone=llm_req burst=10 nodelay;
        limit_conn llm_conn 3;
        limit_req_status 429;
        limit_conn_status 429;

        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

关键参数解释：

rate=5r/s 表示每个 IP 每秒最多 5 个请求，超出进入排队或拒绝。
burst=10 允许短时突发 10 个请求，避免正常波动被误杀。
nodelay 让突发请求立即处理，而不是匀速排队，适合对话类接口。
limit_conn 3 限制单个 IP 同时最多 3 个连接，防止长连接占满后端。

修改后先检查语法再重载：

nginx -t
systemctl reload nginx

如果 nginx -t 报错，优先检查 limit_req_zone 是否写在 http 块内，而不是 server 或 location 内。

推理服务自身也要设上限

Nginx 限流只能挡住 HTTP 层，如果攻击者使用多个 IP 或代理，仍然可能压垮 GPU。推理服务自身的并发和队列限制是最后一道防线。

以 vLLM 为例，启动时可以通过参数控制并发：

python -m vllm.entrypoints.openai.api_server \
  --model /data/models/your-model \
  --max-num-seqs 16 \
  --max-model-len 4096 \
  --gpu-memory-utilization 0.85

--max-num-seqs 限制同时处理的序列数，超过的请求会排队或返回错误。
--gpu-memory-utilization 控制显存占用比例，避免 OOM 导致服务崩溃。

对于 TGI，对应参数是 --max-concurrent-requests 和 --max-input-length。
具体参数名和默认值可能随版本变化，建议以官方文档或 --help 输出为准。

避坑：限流阈值不是越严越好

限流配置最容易踩的坑是阈值设置过紧，导致正常用户也被拦截。
以下几点需要特别注意：

先观察再设限。上线前记录一段时间的正常 QPS 和并发数，通常可以用 tail -f /var/log/nginx/access.log 配合简单统计。
区分接口类型。对话接口通常耗时较长，限流应该更关注并发连接数；而向量化或分类接口响应快，可以放宽速率限制。
429 状态码要返回明确信息。客户端看到 429 后应退避重试，而不是立即重发，否则会加剧拥堵。
不要只依赖 IP 限流。如果服务面向公网，建议配合 API Key 鉴权，按 Key 而不是按 IP 限流，效果更稳定。

如果发现限流后后端仍然被打满，优先检查 Nginx 是否真的生效：

# 查看 Nginx 错误日志中的限流记录
grep 'limiting requests' /var/log/nginx/error.log

有类似输出说明限流已触发；
如果没有，检查 location 路径是否匹配实际请求路径。

验证限流是否生效

配置完成后，用压力工具模拟高频请求，观察是否返回 429 以及后端 GPU 利用率是否平稳。

# 使用 ab 或 wrk 发起测试，注意替换为实际接口地址
ab -n 200 -c 20 -p payload.json -T application/json http://your-domain.com/v1/chat/completions

预期结果：

部分请求返回 429 Too Many Requests。
后端推理服务日志没有出现 OOM 或崩溃。
nvidia-smi 显示的 GPU 利用率不会持续 100% 导致其他请求完全无响应。

如果所有请求都成功且 GPU 仍然被打满，说明限流阈值过松，需要降低 rate 或 burst 值再测试。

常见疑问

限流后正常用户感觉变慢怎么办？

可以适当提高 burst 值，或者按 API Key 做分级限流，给付费用户更高的配额。

Nginx 限流和推理服务限流需要同时开吗？

建议同时开启。
Nginx 挡住大部分异常流量，推理服务自身限制作为兜底，防止代理层被绕过。

如何知道当前限流值是否合适？

观察一周内的 429 比例，如果正常业务请求中 429 占比超过 1%，说明阈值偏紧；
如果 GPU 仍然频繁打满，说明偏松。

限流的目标不是完全禁止高频请求，而是让算力资源在可控范围内分配。
先按本文步骤在测试环境验证，再根据实际业务量调整阈值，就能有效防止大模型推理接口被单个用户耗尽算力。

本地大模型部署失败，算力机器环境排错

多机分布式大模型部署，算力集群搭建教程