负载均衡设计：多节点集群下的请求分发与资源调度

当单一节点的算力被榨干，DeepSeek服务的QPS仍无法满足业务需求时，横向扩展（Scale-out）是唯一的出路。构建一个包含数十台甚至上百台昇腾服务器的推理集群，核心在于设计一套高效、可靠的负载均衡（Load Balancing）系统。

这不仅仅是简单的“轮询分发”，在大模型推理场景下，我们需要面对长连接保持、KV Cache复用、故障快速剔除等一系列挑战。

1. 架构分层：流量的漏斗

一个典型的生产级推理集群架构，流量通常经过三层分发，就像一个漏斗，逐层筛选和路由：

1.1 Layer 4: 传输层负载均衡

• 工具：LVS, F5, AWS NLB
• 职责：处理TCP连接，将公网海量流量分发到各个可用区（AZ）的入口。
• 特点：吞吐量极高，但不理解HTTP协议，无法查看请求内容。

1.2 Layer 7: 应用层负载均衡

• 工具：Nginx, HAProxy, Kubernetes Ingress
• 职责：处理HTTP/gRPC请求，解析URL、Header和Body。
• 关键动作：
  • 鉴权（Auth）：验证API Key。
  • 路由（Routing）：根据URL前缀（如/v1/chat/completions）将请求转发到对应的服务集群。
  • 限流（Rate Limiting）：防止恶意DDoS攻击。

1.3 Application Router: 智能调度层

• 工具：自研网关, Istio VirtualService
• 职责：在微服务内部，根据模型ID、用户Tier（VIP/免费用户）或缓存命中情况，将请求转发到具体的推理Pod。

2. 核心挑战与调度算法

大模型推理与传统的Web服务（如查询用户信息）有本质区别，这也决定了我们不能直接照搬传统的调度策略。

2.1 挑战一：请求耗时方差极大

• 请求A：用户问“你好”，输出5个Token，耗时0.1秒。
• 请求B：用户让写一篇小说，输出2000个Token，耗时20秒。

如果使用Round Robin（轮询）算法，可能会导致某台机器运气不好，连续接到了几个“写小说”的长任务，显存和算力被占满；而下一台机器却在处理“打招呼”，处于空闲状态。这就是著名的Head-of-Line Blocking（队头阻塞）。

推荐算法：Peak EWMA (指数加权移动平均)
负载均衡器维护每个后端节点的“未完成请求数”和“响应延迟”。

• 如果节点A处理得快，说明它负载低或算力强，权重自动调高。
• 如果节点B卡住了，权重自动降低。
  这种动态调整机制能让流量像水一样，自动流向阻力最小的地方。

2.2 挑战二：Context Caching与会话保持

DeepSeek支持多轮对话。为了降低Prefill开销，我们希望同一个用户的后续请求能打到同一台机器上，以便复用显存中已经计算好的KV Cache。

解决方案：Consistent Hashing（一致性哈希）

• 提取请求Header中的Session-ID或User-ID。
• 计算 Hash 值，映射到对应的Pod。
• 注意：这与负载均衡有冲突。如果某台机器过热，必须打破亲和性，将新请求调度到空闲机器（虽然会牺牲Prefill性能，但保证了可用性）。

3. Nginx配置实战

对于中小型集群（<50节点），一个配置合理的Nginx就能解决80%的问题。

http { upstream deepseek_cluster { # 策略：最少连接数（比轮询更好） least_conn; # 所有的推理节点 server 192.168.1.101:8000 max_fails=3 fail_timeout=30s; server 192.168.1.102:8000 max_fails=3 fail_timeout=30s; server 192.168.1.103:8000 max_fails=3 fail_timeout=30s; # 保持与后端的长连接，避免频繁握手 keepalive 64; } server { listen 80; location /v1/chat/completions { proxy_pass http://deepseek_cluster; # --- 关键配置开始 --- # 1. 禁用缓冲：支持SSE流式输出 # 如果开启缓冲，Nginx会等后端发完所有数据才一次性推给客户端 proxy_buffering off; # 2. 超时设置：防止长任务被掐断 proxy_read_timeout 600s; proxy_send_timeout 600s; # 3. HTTP/1.1支持：WebSocket和Keep-Alive必需 proxy_http_version 1.1; proxy_set_header Connection ""; # --- 关键配置结束 --- } } }

4. 动态扩缩容（HPA）策略

在Kubernetes环境中，我们希望集群能根据负载自动伸缩（Auto Scaling）。
传统的HPA通常基于CPU利用率。但在推理场景下，CPU往往不是瓶颈（瓶颈是显存或NPU算力），CPU低不代表系统不忙。

最佳实践：基于自定义指标（Custom Metrics）扩容

我们需要安装prometheus-adapter，将业务指标暴露给K8s HPA控制器。

4.1 黄金指标

1. Pending Queue Length（等待队列长度）
   • 最直接的指标。一旦队列里有积压（例如 > 5），说明现有算力已经处理不过来了，必须立即扩容。
2. Average Token Generation Latency（平均生成延迟）
   • 如果生成速度从 50 tokens/s 掉到了 20 tokens/s，说明由于Dynamic Batching导致的并发过大，需要扩容分摊压力。

4.2 HPA配置示例

apiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:deepseek-hpaspec:scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:deepseek-inferenceminReplicas:2maxReplicas:20metrics:-type:Podspods:metric:name:waiting_queue_size# 自定义指标target:type:AverageValueaverageValue:5# 目标：每个Pod的等待队列不超过5个

5. 熔断与降级（Circuit Breaking）

当集群过载时，必须有保护机制，否则会发生雪崩效应。

• 熔断：如果某台节点连续返回500错误或超时，Nginx/网关应在一段时间内（如30秒）不再向其转发请求。
• 降级：
  • 排队：当并发达到上限，新请求进入全局队列等待。
  • 拒绝：当队列也满了，直接返回429 Too Many Requests，保护系统不被压垮。
  • 模型降级：如果是混合部署，可以在高峰期将请求转发给参数量更小、速度更快的模型（如DeepSeek-7B -> DeepSeek-1.3B）。

6. 总结

负载均衡不仅仅是分发请求，更是对计算资源（显存、算力）的精细化调度。

• 在接入层，用Nginx处理长连接和流式响应。
• 在调度层，用Peak EWMA解决长尾任务导致的负载不均。
• 在资源层，用基于队列长度的HPA实现弹性伸缩。

构建这样一套弹性的负载均衡体系，DeepSeek服务才能像自来水一样，无论用户用水量多大，始终保持水流稳定，既不枯竭（拒绝服务），也不爆管（雪崩宕机）。