大模型服务调度困局LLM 推理集群的负载均衡策略与架构实践一、Token 洪峰与推理延迟的双重挤压LLM 服务负载均衡的核心痛点当企业将大语言模型LLM从实验阶段推向生产环境时最先暴露的往往不是模型精度问题而是服务层的调度瓶颈。一个典型的场景线上对话系统在晚高峰迎来请求洪峰GPU 集群中部分节点因 KV Cache 占满而排队另一部分节点却因模型版本不同而处于空闲状态——请求在错误的节点上堆积用户面对的却是超时和降级。传统微服务的负载均衡策略轮询、加权轮询、最少连接数在 LLM 推理场景下几乎全部失效。原因在于 LLM 推理具有三个独特特征第一请求的算力消耗与输入输出 Token 数强相关而非简单的连接数第二推理过程分为 Prefill预填充和 Decode解码两个阶段两阶段对 GPU 资源的占用模式截然不同第三不同模型实例可能承载不同规格的模型算力异构性极大。如果仍然用连接数最少来路由请求结果就是一个正在处理长上下文请求的实例被持续分配新请求最终 OOM 崩溃。这正是 LLM 服务负载均衡需要独立架构设计的根本原因。本文将从推理引擎的底层调度机制出发逐步构建一套面向生产环境的 LLM 负载均衡方案。二、从 Prefill 到 DecodeLLM 推理调度的底层机制与路由模型要设计合理的负载均衡策略必须先理解 LLM 推理引擎内部的资源消耗模型。以 vLLM 为例其核心调度机制基于 PagedAttention将 KV Cache 分页管理每个请求的 KV Cache 占用量与序列长度成正比。flowchart TB subgraph 请求生命周期 A[客户端请求] -- B[API Gateway] B -- C{负载均衡路由决策} C --|策略1: Token感知| D[推理实例 A] C --|策略2: 队列深度| E[推理实例 B] C --|策略3: 模型匹配| F[推理实例 C] end subgraph 推理实例内部 D -- G[Prefill 阶段] G -- H[Decode 阶段] H -- I[KV Cache 释放] end subgraph 资源监控 D -- J[GPU 利用率] D -- K[KV Cache 使用率] D -- L[请求队列深度] J K L -- M[指标上报至路由中心] M -- C end上图展示了 LLM 请求从入口到路由再到推理实例的完整链路。关键点在于路由决策不能仅依赖静态权重而必须结合实例的实时资源状态。Prefill 阶段是计算密集型的需要一次性处理所有输入 TokenGPU 计算利用率瞬间拉满。Decode 阶段则是访存密集型的每次只生成一个 Token但需要反复读取 KV CacheGPU 计算利用率反而较低。这意味着如果一个实例正在执行 Prefill此时再分配一个 Prefill 请求GPU 显存带宽将成为瓶颈而如果分配一个 Decode 请求两者可以一定程度上复用计算资源。因此理想的调度策略应该感知每个实例当前所处的推理阶段实现 Prefill 与 Decode 请求的交错调度。这种策略被称为阶段感知路由Phase-Aware Routing是 LLM 负载均衡区别于传统负载均衡的核心差异。三、生产级负载均衡实现Token 感知与阶段感知的路由策略下面给出一个基于 Java 实现的 LLM 推理集群负载均衡器。该实现融合了 Token 感知、KV Cache 使用率感知和请求阶段感知三种策略并支持优雅降级。/** * LLM 推理实例的健康状态与资源快照 * 每个实例定期上报路由器基于此做决策 */ public class InferenceNodeSnapshot { private final String nodeId; private final String modelId; // GPU 资源指标 private final double gpuUtilization; // GPU 计算利用率 0~1 private final double kvCacheUsage; // KV Cache 使用率 0~1 private final int availableKvBlocks; // 可用 KV Cache 分页数 // 请求队列指标 private final int pendingPrefillCount; // 排队中的 Prefill 请求 private final int activeDecodeCount; // 正在执行的 Decode 请求 private final int waitingQueueSize; // 等待队列总长度 // 延迟指标滑动窗口均值 private final double avgPrefillLatencyMs; private final double avgDecodeTpsPerToken; // 每 Token 解码延迟 private final long timestamp; // 快照时间戳 /** * 计算该实例的负载评分分数越低越适合接收新请求 * 综合考虑 KV Cache 余量、队列深度和 GPU 利用率 */ public double calculateLoadScore(RequestPhase incomingPhase) { // KV Cache 余量权重最高防止 OOM double kvCachePenalty (1.0 - kvCacheUsage) * 40.0; // 队列深度惩罚 double queuePenalty waitingQueueSize * 5.0; // Prefill 请求的交错调度若实例正在 Prefill降低优先级 double phasePenalty 0.0; if (incomingPhase RequestPhase.PREFILL pendingPrefillCount 0) { phasePenalty 30.0; // 避免多个 Prefill 同时竞争 GPU } // GPU 利用率过高时降权 double gpuPenalty gpuUtilization 0.85 ? (gpuUtilization - 0.85) * 100.0 : 0.0; return kvCachePenalty queuePenalty phasePenalty gpuPenalty; } /** * 判断实例是否可以接受新请求 * KV Cache 使用率超过阈值时拒绝防止 OOM 导致实例崩溃 */ public boolean isAcceptable() { return kvCacheUsage 0.90 waitingQueueSize 100; } } /** * 请求阶段枚举Prefill首 Token 生成前与 Decode流式解码中 */ public enum RequestPhase { PREFILL, // 预填充阶段计算密集 DECODE // 解码阶段访存密集 } /** * LLM 推理集群负载均衡路由器 * 基于 Token 感知与阶段感知的加权最少负载策略 */ public class LlmLoadBalancer { private final MapString, InferenceNodeSnapshot nodeSnapshots new ConcurrentHashMap(); private final ScheduledExecutorService healthChecker Executors.newSingleThreadScheduledExecutor(); // 降级策略当所有节点指标过期时回退到加权轮询 private final AtomicInteger roundRobinIndex new AtomicInteger(0); public LlmLoadBalancer() { // 每 2 秒检查一次节点健康状态过期节点标记为不可用 healthChecker.scheduleAtFixedRate(this::pruneStaleNodes, 2, 2, TimeUnit.SECONDS); } /** * 更新节点快照由各推理实例定期上报调用 */ public void updateSnapshot(InferenceNodeSnapshot snapshot) { nodeSnapshots.put(snapshot.getNodeId(), snapshot); } /** * 核心路由方法为给定请求选择最优推理实例 * * param modelId 目标模型标识 * param inputTokens 输入 Token 数用于估算 Prefill 资源需求 * param phase 请求阶段 * return 选中的节点 ID */ public String route(String modelId, int inputTokens, RequestPhase phase) { // 筛选模型匹配 可接受新请求 快照未过期 ListInferenceNodeSnapshot candidates nodeSnapshots.values().stream() .filter(s - s.getModelId().equals(modelId)) .filter(InferenceNodeSnapshot::isAcceptable) .filter(s - System.currentTimeMillis() - s.getTimestamp() 5000) .collect(Collectors.toList()); // 降级无可用节点时回退到加权轮询 if (candidates.isEmpty()) { return fallbackRoundRobin(modelId); } // 按负载评分排序选择评分最低负载最轻的节点 candidates.sort(Comparator.comparingDouble(s - s.calculateLoadScore(phase))); InferenceNodeSnapshot selected candidates.get(0); // 二次校验输入 Token 数是否超出该节点剩余 KV Cache 容量 // 估算每个 Token 约占用 1 个 KV Block简化模型实际需按模型维度计算 if (selected.getAvailableKvBlocks() inputTokens) { // 容量不足尝试次优节点 if (candidates.size() 1) { selected candidates.get(1); } else { throw new LlmRoutingException( 所有候选节点 KV Cache 不足以承载请求inputTokens inputTokens); } } return selected.getNodeId(); } /** * 降级策略加权轮询 * 当所有节点指标过期时使用保证服务可用性 */ private String fallbackRoundRobin(String modelId) { ListString modelNodes nodeSnapshots.values().stream() .filter(s - s.getModelId().equals(modelId)) .map(InferenceNodeSnapshot::getNodeId) .collect(Collectors.toList()); if (modelNodes.isEmpty()) { throw new LlmRoutingException(无可用推理节点modelId modelId); } int index roundRobinIndex.getAndIncrement() % modelNodes.size(); return modelNodes.get(index); } /** * 清理过期节点快照防止路由到已下线实例 */ private void pruneStaleNodes() { long now System.currentTimeMillis(); nodeSnapshots.entrySet().removeIf( e - now - e.getValue().getTimestamp() 10000 ); } }上述实现的关键设计决策有三点。第一负载评分以 KV Cache 余量为核心权重因为 LLM 推理的 OOM 风险远高于 CPU 饱和。第二阶段感知机制在实例已有 Prefill 请求时降低新 Prefill 请求的优先级避免 GPU 计算资源争抢。第三降级策略保证在指标采集链路异常时系统仍可运行这是生产环境的基本要求。四、KV Cache 争抢与冷启动延迟负载均衡策略的架构权衡任何架构决策都有代价。Token 感知与阶段感知的负载均衡策略同样存在必须正视的边界条件。第一指标采集的时效性开销。路由决策依赖每个推理实例的实时快照这意味着实例需要以 12 秒的频率上报 GPU 利用率、KV Cache 使用率等指标。在高并发场景下指标上报本身会占用推理实例的 CPU 和网络带宽。实测数据显示在 A100 集群上vLLM 的 metrics 端点每次采集约增加 0.30.5ms 的延迟开销。当实例数量超过 50 个时集中式路由器的指标聚合也可能成为瓶颈。第二KV Cache 容量估算的不确定性。代码中简化了 Token 到 KV Block 的映射关系但实际场景中不同模型的 KV Cache 占用量差异极大。例如Llama-3-70B 的每个 Token 约占用 128KB 的 KV Cache而 Qwen-2-7B 仅需约 16KB。如果路由器维护的容量模型不准确可能导致请求被错误地路由到看似有余量但实际不足的实例引发运行时 OOM。第三冷启动与模型加载延迟。当集群需要水平扩容时新实例加载模型权重到 GPU 显存通常需要 30~120 秒取决于模型大小和存储带宽。在此期间新实例无法接收请求而路由器可能已经将其纳入候选池。必须在快照中加入模型就绪状态位否则会引发大量路由失败。适用边界总结该策略适用于请求量相对稳定、模型规格统一的推理集群。对于多模型混部、请求量剧烈波动的场景需要额外引入预测性扩缩容和请求优先级队列机制复杂度将显著上升。五、总结LLM 推理服务的负载均衡本质上是在 GPU 显存约束与请求延迟约束之间寻找最优解。传统微服务的负载均衡策略忽略了推理过程的阶段差异和 KV Cache 的资源竞争直接套用会导致请求堆积与实例崩溃。本文提出的 Token 感知与阶段感知路由策略通过实时采集推理实例的 KV Cache 使用率、GPU 利用率和请求队列深度结合请求阶段进行差异化调度在保证实例稳定性的前提下提升了集群整体吞吐。降级到加权轮询的设计则确保了指标链路异常时的服务可用性。落地路线建议第一步在现有推理集群上部署指标采集 Agent验证 KV Cache 使用率与实际负载的相关性第二步实现基于 KV Cache 余量的最简路由策略灰度上线观察第三步引入阶段感知和 Token 感知逻辑逐步提升调度精度第四步建立容量预测模型为水平扩缩容提供决策依据。