A.1 Nginx 负载均衡详细配置
A.1.1 当前生产配置
upstream vllm_backend {
least_conn;
server 10.255.254.44:8000;
server 10.255.254.44:8001;
server 10.255.254.44:8002;
server 10.255.254.44:8003;
}
server {
listen 0.0.0.0:2196;
server_name _;
location /v1/ {
proxy_pass http://vllm_backend;
proxy_set_header Host host;
proxy_set_header X-Real-IP remote_addr;
proxy_set_header X-Forwarded-For proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto scheme;
proxy_connect_timeout 600s;
proxy_send_timeout 600s;
proxy_read_timeout 600s;
proxy_buffering off;
proxy_socket_keepalive on;
}
location / {
return 444;
}
}
A.1.2 配置逐行说明
|---------------------------------|------------------|-------------------------------------------|
| 配置项 | 值 | 作用 |
| least_conn | --- | 最少连接调度：将请求发给当前活跃连接数最少的后端实例，确保负载均匀 |
| server 10.255.254.44:8000~8003 | 4 个后端 | 4 个 vLLM TP=2 实例，每个实例占用 2 张 4090 |
| listen 0.0.0.0:2196 | 公网 2196 端口 | 对外暴露统一 API 入口 |
| proxy_set_header 系列 | 透传客户端信息 | 让后端 vLLM 看到真实客户端 IP |
| proxy_*_timeout 600s | 600 秒 | 匹配 vLLM 长生成时间，避免 Nginx 提前断开 |
| proxy_buffering off | 关闭缓冲 | 流式响应实时返回，不等待完整响应 |
| proxy_socket_keepalive on | 开启 TCP Keepalive | 维持长连接，减少 TCP 握手开销 |
| location / { return 444; } | 静默拒绝 | 拦截非法扫描请求（如漏洞探测），不返回任何内容 |
A.1.3 负载均衡策略对比
|---------------------|-------------|---------------------|-----------------------|
| 策略 | 配置 | 适用场景 | 本测试表现 |
| ip_hash | ip_hash; | 会话保持（同一 IP 固定到同一后端） | ❌ 单实例过载，其余空闲 |
| round_robin | 默认 | 简单轮询 | ⚠️ 请求长度不均时可能负载不均 |
| least_conn | least_conn; | 长连接/异构请求 | ✅ 最优，4 实例均匀负载 |
| least_time | 需第三方模块 | 响应时间敏感 | --- 未测试 |
本测试选择 least_conn 的原因： - vLLM 请求处理时间长（10-30s），属于长连接场景 - 不同请求生成 token 数不同（200-300），处理时间异构 - least_conn 能动态将新请求发给当前最空闲的实例
A.1.4 后端实例架构
客户端请求
↓
Nginx (2196端口, least_conn)
↓
├─→ vLLM-8000 (GPU 0+1, TP=2)
├─→ vLLM-8001 (GPU 2+3, TP=2)
├─→ vLLM-8002 (GPU 4+5, TP=2)
└─→ vLLM-8003 (GPU 6+7, TP=2)
- 每个实例独立进程，互不影响
- 实例故障时 Nginx 自动剔除（需配合健康检查）
- 单实例重启不影响其他实例服务
A.1.5 健康检查建议（生产增强）
当前配置无主动健康检查，建议增加：
upstream vllm_backend {
least_conn;
server 10.255.254.44:8000 max_fails=3 fail_timeout=30s;
server 10.255.254.44:8001 max_fails=3 fail_timeout=30s;
server 10.255.254.44:8002 max_fails=3 fail_timeout=30s;
server 10.255.254.44:8003 max_fails=3 fail_timeout=30s;
}
或使用 nginx_upstream_check_module 做主动健康检查：
upstream vllm_backend {
least_conn;
server 10.255.254.44:8000;
check interval=3000 rise=2 fall=3 timeout=1000 type=http;
check_http_send "GET /health HTTP/1.0\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;
}
A.2 百分位延迟（P50 / P90 / P99）说明
A.2.1 什么是百分位延迟？
百分位延迟是衡量请求延迟分布的统计指标，比"平均延迟"更能反映真实用户体验。
|-------------|-----------------|-------------------------------|
| 指标 | 定义 | 通俗理解 |
| P50 | 50th Percentile | 中位数：50% 请求比它快，50% 比它慢 |
| P90 | 90th Percentile | 90% 请求 ≤ 这个值，10% 更慢 |
| P99 | 99th Percentile | 99% 请求 ≤ 这个值，仅 1% 更慢 |
A.2.2 为什么不能用"平均延迟"？
平均延迟有欺骗性：
10 个请求的延迟：1s, 1s, 1s, 1s, 1s, 1s, 1s, 1s, 1s, 100s
平均延迟 = 10.9s ← 看起来"还行"
P99 延迟 = 100s ← 有一个用户等了 100 秒！
平均延迟掩盖了尾部用户的痛苦。
A.2.3 百分位延迟的计算方法
将 N 个请求的延迟从小到大排序：
排序后: 18s, 19s, 19s, 20s, 20s, 21s, 21s, 22s, 23s, 100s
↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑
P10 P20 P30 P40 P50 P60 P70 P80 P90 P100
- P50 = 第 5 个值 = 20s（中位数）
- P90 = 第 9 个值 = 23s（90% 用户 ≤ 23s）
- P99 = 第 9.9 个值 ≈ 100s（99% 用户 ≤ 100s）
A.2.4 本测试中的百分位延迟数据
4090 测试结果（健康系统）
|-----|-----|-------|-------|-------|-------------|--------|
| 并发 | 请求数 | P50 | P90 | P99 | P99-P50 | 状态 |
| 1 | 50 | 19.2s | 19.2s | 19.2s | 0ms | ✅ 完全均匀 |
| 10 | 50 | 20.5s | 20.5s | 20.5s | 0ms | ✅ 完全均匀 |
| 20 | 50 | 19.8s | 19.8s | 19.8s | 0ms | ✅ 完全均匀 |
| 50 | 50 | 20.7s | 20.7s | 20.7s | 0ms | ✅ 完全均匀 |
| 100 | 50 | 20.4s | 20.4s | 20.4s | 0ms | ✅ 完全均匀 |
| 100 | 100 | 20.9s | 20.9s | 20.9s | 0ms | ✅ 完全均匀 |
| 200 | 150 | --- | --- | 21.5s | --- | ✅ 尾部稳定 |
| 250 | 250 | --- | --- | 22.2s | --- | ✅ 尾部稳定 |
特征：P50 = P90 = P99
B60 参考结果（压力系统）
|-----|------|------|------|-------------|---------|
| 并发 | P50 | P90 | P99 | P99-P50 | 状态 |
| 150 | 110s | 112s | 112s | 2s | ⚠️ 轻微尾部 |
| 200 | 151s | 164s | 184s | 33s | ❌ 尾部恶化 |
特征：P99 >> P90 >> P50
A.2.5 百分位差距的含义
|----------------|-----------------|-------------------|
| P99-P50 差距 | 系统状态 | 说明 |
| < 1s | ✅ 健康 | 调度公平，资源充足，所有请求一致 |
| 1-5s | ⚠️ 轻度压力 | 10% 请求开始变慢，调度轻微不均 |
| 5-20s | ❌ 中度瓶颈 | 尾部请求明显饥饿，队列堆积 |
| > 20s | ❌ 严重瓶颈 | 系统过载，部分请求长时间等待 |
A.2.6 本测试结论
4090 + vLLM 表现 ： - 并发 250 以内，P99-P50 ≈ 0-3s - 说明 vLLM continuous batching 调度器工作完美 - 无请求被"饿死"，所有用户获得一致体验 - GPU 算力是瓶颈，但调度器不是瓶颈
对比 B60 ： - B60 并发 200 时 P99-P50 = 33s （尾部恶化 22%） - 4090 并发 250 时 P99-P50 ≈ 3s（零恶化）
4090 的调度公平性远超 B60。
A.2.7 生产环境的 P99 承诺
|--------|-----------------|---------------|
| 业务类型 | 建议 P99 目标 | 理由 |
| 实时客服 | < 5s | 用户不能等，超时即流失 |
| 在线 API | < 30s | 多数应用可接受，需进度提示 |
| 批处理/后台 | < 120s | 容忍度高，但需监控 |
| SLA 合同 | 必须写 P99 | 平均延迟无法作为法律承诺 |
A.2.8 如何解读本测试报告中的延迟数据
并发=200, 请求=150:
平均延迟: 22.3s
P50: --- | P90: --- | P99: 21.5s
解读：
- 平均延迟 22.3s 与 P99 21.5s 接近 → 分布均匀，无异常值
- 如果平均 >> P99，说明有少量请求极慢（被平均拉高了）
- 本测试中平均 ≈ P99 → 所有请求处理时间一致 ✅
A.3 配置与监控命令速查
查看 Nginx 配置
cat /etc/nginx/conf.d/vllm_lb.conf
重载 Nginx
sudo nginx -t && sudo systemctl reload nginx
查看后端连接分布
sudo ss -tnp | grep -E "8000|8001|8002|8003" | grep ESTAB | awk '{print $4}' | sort | uniq -c
查看 vLLM 实例日志
sudo journalctl -u vllm-8000 -f --no-pager | grep -E "chat.completions|Engine.*throughput"
查看 GPU 利用率
nvidia-smi --query-gpu=index,utilization.gpu,memory.used,temperature.gpu --format=csv