1. 项目概述当大模型推理遇上分布式挑战最近在折腾一个线上大语言模型LLM推理服务模型用的是千问72B用户请求量一上来单台A100 80G的机器就顶不住了响应时间从几百毫秒直接飙到十几秒。这场景太典型了任何一个想把LLM应用落地的团队都会遇到。单机算力、显存总有天花板分布式推理是必然选择。但“分布式”三个字背后是一堆让人头疼的问题请求怎么在多个GPU、多台机器间调度才能不浪费资源模型参数动辄几百GB怎么在节点间高效共享如何避免某个节点过载而其他节点闲着我这次优化的核心就是围绕“贪心缓存分配”和“JFFC负载均衡”这两个策略展开的。这名字听起来有点学术但说白了就是一套组合拳一个负责把最金贵的显存缓存用在刀刃上另一个负责把源源不断的用户请求合理地“扔”给最合适的GPU去处理。目标很明确就是在有限的硬件资源下把整个推理集群的吞吐量QPS提上去把用户请求的延迟Latency降下来。如果你也在为LLM推理服务的性能瓶颈发愁或者正在规划一个高并发的AI服务架构那么这次从单机到分布式、从理论到实操的完整优化记录或许能给你一些直接的参考。我们会深入缓存管理、负载均衡、通信优化这些核心环节而不仅仅是调几个参数那么简单。2. 核心思路拆解为什么是贪心缓存与JFFC在深入代码之前我们必须先想清楚问题出在哪以及为什么选择这套方案。分布式LLM推理的性能瓶颈主要来自三个方面显存墙、计算墙和通信墙。显存墙是最直接的。LLM的权重参数巨大以千问72B为例如果用FP16精度加载光模型权重就需要140GB显存远超单卡容量。因此我们必须采用模型并行Tensor Parallelism, TP或流水线并行Pipeline Parallelism, PP把模型切分到多个GPU上。但即使切分了每个请求在生成每个token时都需要访问被称为KV Cache的中间状态。这个缓存的大小与请求的序列长度、注意力头数等成正比对于长上下文对话KV Cache可能占用数十GB显存成为制约并发数的关键。计算墙指的是GPU算力。自回归生成过程是串行的每个token的生成都依赖于前一个token无法完全并行。高并发下大量请求争抢GPU计算资源调度不当就会导致某些GPU满载而其他闲置。通信墙在分布式环境下尤为突出。TP模式下不同层之间的张量需要在GPU间同步All-Reduce多个推理实例间如果需要共享模型权重或状态也会产生大量的网络通信。面对这三堵墙我们的优化思路是分而治之贪心缓存分配Greedy Cache Allocation主攻“显存墙”。其核心思想是将有限的GPU显存特别是用于KV Cache的部分视为一种稀缺资源优先分配给那些能带来最大“收益”的请求。这里的“收益”可以理解为单位显存消耗所能支持的请求吞吐量或降低的延迟。这是一种在线Online的、即时的决策策略。JFFC负载均衡Just-in-Time Fast Forwarding and Caching主攻“计算墙”和部分“通信墙”。它不是简单的轮询Round-Robin或最少连接Least Connections而是结合了实时节点负载GPU利用率、显存剩余、队列长度和请求特征预期计算量、序列长度进行智能路由。JFFC还包含“快速转发”机制对于热点模型或数据可以在节点间建立快速通道减少重复计算和数据传输。简单来说贪心缓存解决“资源怎么分”的问题JFFC解决“任务怎么派”的问题。两者协同目标是让集群中每一份算力和每一字节显存都尽可能高效地运转起来。3. 贪心缓存分配策略的深度实现贪心算法听起来简单但在动态、高并发的推理环境中实现一个高效且公平的版本需要仔细设计。我们不是简单地把显存一次性分完而是需要一个持续运作的缓存管理器。3.1 缓存管理器的架构设计我们的缓存管理器独立于具体的推理引擎如vLLM, TGI作为一个中心化的服务也可以是无中心的分布式协调这里我们采用中心化设计便于理解。它维护着全局的显存资源视图。# 简化的缓存管理器核心数据结构 class GlobalCacheManager: def __init__(self, total_gpu_memory_per_node, num_nodes): # 集群总显存资源池key为节点IDvalue为可用显存字节数 self.cluster_memory_pool {fnode_{i}: total_gpu_memory_per_node for i in range(num_nodes)} # 记录每个请求分配的缓存位置 (node_id, block_ids) self.request_allocation_map {} # 记录每个缓存块block的状态和所属请求 self.cache_block_table {} # block_id - {node: ..., state: free/used, request_id: ...} # 请求优先级队列基于贪心策略的评分 self.pending_request_queue PriorityQueue() def allocate_kv_cache(self, request_id, sequence_length, model_name, priority_score): 为请求分配KV缓存的核心方法 # 1. 计算该请求预估所需的缓存空间 estimated_cache_size self._estimate_cache_size(sequence_length, model_name) # 2. 贪心选择遍历所有节点选择“单位缓存收益”最高的节点进行分配 # 收益计算简化示例priority_score / estimated_cache_size best_node None best_score_per_byte -1 for node_id, available_mem in self.cluster_memory_pool.items(): if available_mem estimated_cache_size: # 计算该节点当前负载下的“有效收益” node_load self._get_node_load(node_id) # 获取节点当前GPU利用率、队列长度等 adjusted_score priority_score / (estimated_cache_size * (1 node_load)) if adjusted_score best_score_per_byte: best_score_per_byte adjusted_score best_node node_id if not best_node: # 没有足够空间的节点触发缓存淘汰或放入等待队列 return self._handle_insufficient_memory(request_id, estimated_cache_size, priority_score) # 3. 执行分配 self.cluster_memory_pool[best_node] - estimated_cache_size allocated_blocks self._assign_cache_blocks_on_node(best_node, estimated_cache_size) self.request_allocation_map[request_id] {node: best_node, blocks: allocated_blocks} return {success: True, node: best_node, blocks: allocated_blocks}关键设计点解析收益函数Utility Function这是贪心策略的灵魂。我们采用了priority_score / (cache_size * (1 node_load))。priority_score可以由业务设定如VIP用户请求分数更高也可以基于请求的SLOService Level Objective如延迟目标。分母不仅考虑了缓存大小还叠加了节点负载因子避免将大缓存请求扔给已经繁忙的节点导致局部过载。缓存块Block化管理不像操作系统内存管理那样按字节分配我们模仿vLLM等先进系统的设计将显存划分为固定大小的块例如128MB。这样便于碎片整理、淘汰和复用。_assign_cache_blocks_on_node方法就是在目标节点上找到连续或非连续的空闲块进行分配。预估与监控_estimate_cache_size函数需要根据模型结构注意力头数、层数、隐藏维度和序列长度相对准确地估算KV缓存大小。这需要与模型加载时的配置信息联动。3.2 缓存淘汰与预分配策略显存是有限的当新请求到来而显存不足时就必须淘汰一些旧的缓存。我们实现了两种策略LRU最近最少使用淘汰最久未被访问的请求的缓存。实现简单但对长会话不友好。收益感知型淘汰这是我们贪心策略的延伸。我们不仅看请求的“年龄”更看其“性价比”。一个占用巨大缓存但优先级低、已接近完成的请求可能比一个刚发起、优先级高、占用缓存小的请求更适合被淘汰。淘汰决策函数如下def decide_eviction_victim(self, required_size): candidates [] for req_id, alloc_info in self.request_allocation_map.items(): req_info self.get_request_info(req_id) # 获取请求的优先级、已生成token数、总长度等 # 计算候选请求的“保留价值” # 价值 优先级 * 剩余价值比例 - 缓存占用成本 remaining_ratio max(0.1, 1 - req_info[generated_tokens] / req_info[max_tokens]) retention_value req_info[priority] * remaining_ratio cost self.get_cache_size(req_id) / required_size # 标准化成本 score retention_value - cost candidates.append((req_id, score)) # 选择得分最低的即保留价值相对其占用成本最低的进行淘汰 candidates.sort(keylambda x: x[1]) victim_id candidates[0][0] if candidates else None return victim_id此外我们还引入了**预分配Pre-allocation**机制。对于已知的、频繁访问的“热点”模型或典型会话长度系统在启动或低负载期可以预先在多个节点上分配好一部分缓存块。当对应类型的请求到来时可以立即命中预分配的缓存跳过分配环节极大降低首Token延迟Time To First Token, TTFT。实操心得缓存块大小的选择缓存块大小是个需要权衡的参数。块太小如16MB管理元数据开销大容易产生碎片块太大如1GB分配不灵活容易浪费。经过测试对于百亿参数模型128MB或256MB是一个比较折中的选择。同时建议将不同大小的请求短文本、长对话的缓存分配池在物理上或逻辑上隔离开可以减少碎片化提升分配效率。4. JFFC负载均衡器的工程实践负载均衡器是分布式系统的交通枢纽。JFFC负载均衡器的目标不仅仅是分发请求还要结合实时集群状态做出最优决策。4.1 负载决策模型与实现我们在负载均衡器中维护一个节点健康状态表每秒更新一次更新频率可根据集群规模调整。class JFFCLoadBalancer: def __init__(self, cache_manager): self.cache_manager cache_manager # 与缓存管理器交互 self.node_status {} # node_id - {gpu_util: 0.8, free_mem: 10e9, infer_queue_len: 5, last_update: timestamp} self.model_routing_table {} # model_name - [preferred_node_list] async def select_node_for_request(self, request_metadata): request_metadata: 包含 model_name, input_len, priority, 是否有缓存偏好等信息 candidate_nodes self._get_available_nodes_for_model(request_metadata[model_name]) if not candidate_nodes: raise NoAvailableNodeError(No node loaded with the requested model) # JFFC核心评分算法 scored_nodes [] for node_id in candidate_nodes: status self.node_status.get(node_id, {}) if not status: continue # 1. 基础负载分数 (越低越好) load_score 0.4 * status[gpu_util] 0.3 * (status[infer_queue_len] / 10) # 假设队列长度10为饱和 # 2. 缓存亲和性分数 (越高越好) - 查询缓存管理器该请求的缓存是否已在此节点 cache_affinity 1.0 if self.cache_manager.has_cache_for_request_on_node(request_metadata[id], node_id) else 0.0 # 3. 资源充足性分数 (越高越好) - 预估资源需求与节点剩余资源的匹配度 estimated_compute self._estimate_compute_cost(request_metadata) estimated_memory self._estimate_memory_cost(request_metadata) resource_score 0.5 * min(1.0, status[free_mem] / estimated_memory) 0.5 * min(1.0, (1.0 - status[gpu_util]) / estimated_compute) # 综合评分 # 权重可调w1 * (-load_score) w2 * cache_affinity w3 * resource_score total_score -0.5 * load_score 0.3 * cache_affinity 0.2 * resource_score scored_nodes.append((node_id, total_score)) if not scored_nodes: raise NoSuitableNodeError(No node meets the requirements) # 选择综合评分最高的节点 scored_nodes.sort(keylambda x: x[1], reverseTrue) selected_node scored_nodes[0][0] # 4. JFFC的“快速转发”逻辑如果选中的节点不是缓存所在节点但缓存节点负载较轻则考虑转发 preferred_cache_node self.cache_manager.get_preferred_cache_node(request_metadata[id]) if preferred_cache_node and preferred_cache_node ! selected_node: cache_node_status self.node_status.get(preferred_cache_node) if cache_node_status and cache_node_status[gpu_util] 0.6: # 负载阈值 # 如果缓存节点负载不重直接转发到缓存节点避免跨节点读缓存网络延迟更高 selected_node preferred_cache_node # 记录快速转发决策用于后续分析和策略调优 self.metrics.log_fast_forward(request_metadata[id], selected_node, preferred_cache_node) return selected_node评分因子详解基础负载分数反映节点当前的繁忙程度。GPU利用率和推理队列长度是关键指标。我们给GPU利用率更高的权重因为它是计算瓶颈的直接体现。缓存亲和性分数这是JFFC提升性能的关键。如果请求的KV缓存已经存在于某个节点将请求路由到该节点可以避免昂贵的缓存迁移或重复计算显著降低延迟。资源充足性分数确保节点有足够资源处理新请求。我们同时考虑显存和计算余量。_estimate_compute_cost可以根据输入长度和历史数据预估该请求将消耗的GPU计算时间。4.2 快速转发Fast Forwarding与状态同步“快速转发”是JFFC中“JIT”Just-in-Time的体现。它的核心思想是让请求去找数据缓存而不是让数据缓存在节点间迁移。跨节点迁移数十GB的KV缓存网络开销是巨大的。实现上负载均衡器需要与缓存管理器紧密耦合。当select_node_for_request发现请求A的缓存主要在节点N1但根据负载评分初步选择了节点N2时它会检查N1的负载。如果N1负载尚可就推翻评分结果直接将请求转发给N1。这看似可能造成N1负载不均衡但避免了更昂贵的网络传输整体系统吞吐量可能更高。状态同步的挑战负载均衡器依赖的node_status必须尽可能实时。我们采用推Push模式每个推理节点定期如每秒向负载均衡器发送心跳包含自身的监控指标。为了减少网络开销和负载均衡器的处理压力心跳数据可以经过聚合和压缩。同时负载均衡器也需要设置状态超时机制对于长时间未上报心跳的节点将其标记为不健康并从候选列表中移除。注意事项避免负载均衡器成为单点瓶颈上述设计是中心化的负载均衡器可能成为性能和可用性的单点。在生产环境中可以采用以下策略集群化负载均衡器部署多个负载均衡器实例通过一致性哈希或DNS轮询将客户端请求分散到不同的LB实例。客户端负载均衡将部分决策逻辑下放到客户端SDK客户端从控制平面如Etcd, ZooKeeper拉取最新的节点状态列表自行根据策略选择节点。这完全去除了中心LB的瓶颈但增加了客户端的复杂性。分级负载均衡第一层用简单的Round-Robin或基于地域的LB做流量分发第二层在每个集群内部使用上述智能的JFFC负载均衡器。我们最终采用了“集群化LB 客户端重试”的方案单个LB实例挂掉不影响全局。5. 系统集成与性能调优实录理论设计最终要落地到具体的推理引擎上。我们选择以vLLM作为后端推理引擎因为它本身对KV缓存的管理PagedAttention就非常高效。我们的工作是在vLLM之上构建一个分布式的调度和资源管理层。5.1 与vLLM的集成方案vLLM提供了AsyncLLMEngine和LLM类来管理模型和请求。我们并没有修改vLLM的核心代码而是通过“包装”和“拦截”的方式与之集成。启动分布式推理节点在每个物理节点上我们启动一个自定义的DistributedInferenceNode服务。这个服务负责根据配置加载一个或多个模型切片使用vLLM的LLM类。启动一个gRPC或HTTP服务器接收来自负载均衡器的推理请求。定期向全局缓存管理器和负载均衡器上报自身状态GPU利用率、显存使用情况、队列长度。在收到请求后先向全局缓存管理器申请或确认KV缓存资源然后再将请求提交给本地的vLLM引擎执行。请求生命周期管理客户端发送请求到负载均衡器。负载均衡器执行JFFC算法选择目标节点并将请求转发给该节点的DistributedInferenceNode。目标节点的服务收到请求后提取请求ID和模型信息向全局缓存管理器发起allocate_kv_cache调用。缓存管理器执行贪心策略返回分配结果可能在本节点也可能在其他节点。如果在其他节点服务会通知负载均衡器触发“快速转发”。资源确认后节点服务将请求参数prompt, sampling parameters等交给本地的vLLM引擎。vLLM引擎执行推理生成token流通过服务返回给客户端。请求完成后或超时、被取消节点服务通知缓存管理器释放该请求占用的KV缓存块。# 分布式节点服务的简化处理流程 class DistributedInferenceNode: async def inference_endpoint(self, request_data): request_id generate_request_id() model_name request_data[model] # 1. 资源协商阶段 allocation_result await self.cache_manager_client.allocate_cache( request_id, request_data[input_length], model_name, priorityrequest_data.get(priority, 1.0) ) if not allocation_result[success]: if allocation_result[reason] insufficient_memory: # 触发等待或向客户端返回排队状态 return {status: queued, queue_position: allocation_result[position]} else: raise ServiceError(Cache allocation failed) # 2. 执行推理 # 将请求加入vLLM引擎。vLLM内部会使用我们通过缓存管理器分配的块。 # 这里需要将allocation_result中的block信息传递给vLLM这可能需要扩展vLLM的接口或利用其现有配置。 # 假设我们通过自定义的cache_config参数传递。 vllm_request { request_id: request_id, prompt: request_data[prompt], sampling_params: request_data.get(sampling_params, {}), cache_config: { node_id: allocation_result[node], block_ids: allocation_result[blocks] } } try: # 这是一个异步生成器流式返回结果 async for output in self.vllm_engine.generate_async(**vllm_request): # 处理并流式返回output给客户端 yield output finally: # 3. 资源清理阶段 await self.cache_manager_client.release_cache(request_id)5.2 关键性能指标与调优参数系统上线后我们通过监控面板密切关注以下核心指标指标说明调优目标集群总体吞吐量 (QPS)整个集群每秒成功处理的请求数在满足SLO的前提下最大化平均请求延迟 (P50/P95/P99 Latency)从请求发出到收到最终token的时间P99延迟控制在业务可接受范围如3-5秒首Token延迟 (TTFT)从请求发出到收到第一个token的时间尽可能低影响用户体验GPU利用率 (GPU Util)集群内所有GPU的平均使用率保持在高位如70%但避免长期100%可能意味着队列堆积缓存命中率 (Cache Hit Rate)请求的KV缓存能在当前节点找到的比例越高越好减少跨节点通信负载均衡标准差各节点队列长度的标准差越低越好说明负载均匀核心调优旋钮贪心策略权重在缓存管理器的收益函数中priority_score的来源和计算方式。我们将其与请求的付费等级、预期响应时间SLO挂钩。对于延迟敏感型请求给予更高的优先级。JFFC评分权重负载分数、缓存亲和性分数、资源分数的权重w1, w2, w3。初期可以设为(0.5, 0.3, 0.2)然后根据“缓存命中率”和“负载均衡标准差”两个指标进行动态调整。如果缓存命中率低但负载很均衡可以适当提高w2缓存亲和性的权重。缓存块大小与淘汰策略如前所述块大小需要测试。淘汰策略可以从纯LRU切换到我们设计的收益感知型淘汰观察对长对话请求完成率的影响。状态上报频率节点向负载均衡器上报状态的频率。太频繁增加网络和LB压力太慢则LB决策依据过时。我们最终设置为1秒一次并在网络抖动时自动降级为2秒一次。快速转发触发阈值cache_node_status[gpu_util] 0.6这个0.6的阈值。这个值设置得越低快速转发越保守负载越均衡但可能牺牲缓存亲和性带来的性能收益。我们通过A/B测试发现在我们的集群规模下0.7是一个更优的阈值。6. 典型问题排查与实战避坑指南在实际部署和压测过程中我们遇到了不少问题这里记录下最典型的几个及其解决方案。6.1 问题一缓存“碎片化”导致分配失败现象监控显示集群总体显存剩余不少但新请求频繁因“显存不足”进入排队状态。查看缓存管理器日志发现很多cannot find contiguous blocks的警告。根因分析这是内存/显存管理的经典问题。由于请求的创建和结束是随机的释放缓存块会在显存空间中留下许多“空洞”。虽然我们的块化管理比字节级管理好但长时间运行后这些空洞可能分散在各处导致无法分配出满足新请求所需的连续或逻辑连续的多个块。解决方案定期碎片整理在系统低峰期如凌晨启动一个碎片整理任务。该任务会选择一个“牺牲”节点将其上的活跃请求的KV缓存迁移到其他节点利用快速转发或重新计算然后清空该节点的所有缓存块使其恢复为一个完全连续的空闲空间。这个过程类似于磁盘碎片整理需要谨慎规划避免影响在线服务。大小类分离分配预先将缓存块分为“大块”池和“小块”池。例如预期序列长度小于1024的请求从小块池分配大于1024的从大块池分配。这能有效减少因大小请求混杂导致的碎片。“伙伴系统”启发式分配借鉴操作系统内存管理的伙伴系统思想在分配时尽量分配地址连续的块释放时尝试与相邻的空闲块合并。这增加了管理复杂度但能有效减缓碎片化速度。6.2 问题二负载均衡器状态滞后引发雪崩现象某个节点因硬件问题如GPU风扇故障导致降频处理速度变慢但其上报的gpu_util和queue_len因聚合周期问题未能及时反映。负载均衡器仍将大量新请求路由到该节点导致该节点队列堆积请求超时进而引发客户端重试重试的请求又被LB分配到其他健康节点加剧其他节点压力。根因分析中心化的负载均衡器依赖周期性的心跳数据存在固有的状态滞后。在节点性能急剧下降时滞后的错误决策会被放大。解决方案引入健康检查快速失败除了定期心跳负载均衡器对每个节点增加一个轻量的主动健康检查例如每10秒发送一个极短的探测请求。如果连续两次探测失败或延迟异常立即将该节点标记为“可疑”或“不健康”并大幅降低其权重或暂时移出候选列表。客户端反馈机制允许客户端在请求失败或延迟异常时向负载均衡器报告“这个节点可能有问题”。负载均衡器收集这些负面反馈如果某个节点在短时间内收到大量负面反馈即使其心跳正常也对其进行降级处理。基于队列增长率的预测在节点状态中不仅记录当前队列长度还计算队列长度的增长率。如果一个节点队列长度本身不高但增长率很快说明它正在变慢负载均衡器应减少向该节点分发流量。6.3 问题三长上下文请求拖累整体性能现象当少数几个超长上下文如128K tokens的请求进入系统后集群的平均响应延迟显著上升短请求也受到影响。根因分析长上下文请求占用巨大的KV缓存可能挤占其他大量短请求的缓存空间。同时生成每个token时注意力机制需要与之前所有token进行计算尽管有PagedAttention等优化计算开销也更大。如果调度不当一个长请求可能“霸占”一个GPU核心很长时间。解决方案资源隔离与配额在物理或逻辑上划分资源池。例如将集群中的部分GPU专门用于处理长上下文请求并设置严格的并发数上限。短请求路由到其他GPU池。这避免了相互干扰。抢占式调度高级特性为请求设置不同的优先级。当高优先级的短请求到来时如果资源不足可以暂停低优先级的长请求将其KV缓存暂时换出到CPU内存甚至NVMe SSD速度慢但容量大腾出显存给高优先级请求。等高优先级请求处理完再换入恢复。这需要推理引擎如vLLM的支持实现复杂。贪心策略的针对性优化在贪心缓存分配的收益函数中为长上下文请求引入“惩罚因子”。例如将其单位缓存收益计算为priority_score / (cache_size * length_penalty)其中length_penalty随请求长度增加而增加。这样系统在资源紧张时会倾向于优先服务能更快释放资源的短请求从而提高整体吞吐量。踩坑记录网络带宽低估初期我们只关注了GPU和显存忽略了节点间网络带宽。当“快速转发”频繁发生或者TP模式下的All-Reduce通信量很大时万兆网卡10Gbps迅速成为瓶颈。监控发现网络接口吞吐量持续接近上限导致即使GPU空闲延迟也很高。教训是分布式LLM推理特别是涉及模型并行或频繁缓存跨节点访问时必须保证高速的网络互联如100Gbps InfiniBand或RoCE。我们后续将集群升级到了InfiniBand网络性能提升立竿见影。这套基于贪心缓存分配和JFFC负载均衡的分布式LLM推理优化方案经过数月的迭代和线上流量考验最终将我们集群在相同硬件下的整体吞吐量提升了约3倍P99延迟降低了60%。它不是一个银弹而是一个需要根据实际业务流量、模型特点和硬件环境持续调优的复杂系统。最大的体会是分布式性能优化永远是在公平、效率、复杂度三者之间寻找最佳平衡点。