加权轮询本身不感知GPU，需将GPU算力、显存、实测QPS等差异映射为合理weight值，并配合健康检查、后端限流与连接管理实现真实负载均衡。
加权轮询本身不感知GPU，它只按配置的 weight 值分发HTTP/TCP请求。要让Nginx对GPU服务器集群实现“有意义的加权”，关键不是修改Nginx算法，而是把GPU算力差异映射为合理的weight值，并配合后端服务协同保障真实负载均衡。
GPU服务器权重怎么设才合理
不能凭空拍权重。需结合实际硬件与业务特征综合评估：
-
单卡算力比：比如 A服务器是4×A100（每卡312 TFLOPS FP16），B是2×V100（每卡125 TFLOPS），理论峰值比 ≈ (4×312) : (2×125) = 1248 : 250 ≈ 5 : 1 → weight可设为
server gpu-a:8000 weight=5、server gpu-b:8000 weight=1 - 显存容量比：大模型推理常受显存瓶颈限制。若A有80GB×4=320GB总显存，B为32GB×2=64GB，则显存比≈5:1，权重参考同上
-
实测吞吐校准：用相同模型+相同batch size压测各节点QPS（如 LLaMA-3-8B + vLLM），若A达120 req/s、B达30 req/s，直接按 120:30 = 4:1 设
weight=4和weight=1
必须配套的后端改造
仅靠Nginx加权轮询无法避免GPU过载，因为Nginx不检查GPU显存/利用率。务必补充：
-
健康检查 + 动态剔除：在
upstream中启用max_fails=2 fail_timeout=15s，并让后端提供/health?gpu=0接口返回显存使用率；用Nginx Plus或自研脚本调用该接口，自动更新upstream配置（或配合consul等服务发现） - 请求级限流兜底：在GPU服务入口（如vLLM/FastAPI）开启并发限制，例如每个实例最多处理8个推理请求，超时排队而非OOM崩溃
-
避免长连接堆积：GPU推理耗时波动大，禁用
keepalive或缩短proxy_http_version 1.1+proxy_set_header Connection ''，防止一个慢请求阻塞整个连接池
典型配置示例
假设三台GPU服务，已通过压测确定QPS能力比为 6 : 3 : 1：
upstream gpu_cluster {server 192.168.5.10:8000 weight=6 max_fails=2 fail_timeout=10s;
server 192.168.5.11:8000 weight=3 max_fails=2 fail_timeout=10s;
server 192.168.5.12:8000 weight=1 max_fails=2 fail_timeout=10s;
}
server {
listen 80;
location /v1/chat/completions {
proxy_pass http://gpu_cluster;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_http_version 1.1;
proxy_set_header Connection '';
}
}
