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

当单一节点的算力被榨干，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%的问题。

nginx 复制代码

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 黄金指标

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

4.2 HPA配置示例

yaml 复制代码

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: deepseek-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: deepseek-inference
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Pods
    pods:
      metric:
        name: waiting_queue_size # 自定义指标
      target:
        type: AverageValue
        averageValue: 5 # 目标：每个Pod的等待队列不超过5个

5. 熔断与降级（Circuit Breaking）

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

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

6. 总结

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

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

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