1. 大语言模型分阶段推理的核心挑战大语言模型(LLM)推理过程中的预填充(prefill)和解码(decode)阶段具有截然不同的计算特性。预填充阶段需要并行处理所有输入token属于计算密集型操作而解码阶段则通过自回归方式逐个生成输出token属于内存密集型操作。这种差异导致传统将两个阶段部署在同一GPU上的方案面临诸多挑战。1.1 计算资源争用问题在colocated(同置)部署模式下预填充和解码阶段共享同一GPU的计算资源。当两个阶段的任务同时运行时预填充阶段会占用大量计算单元(如CUDA cores)导致解码阶段的矩阵运算被延迟解码阶段需要频繁访问高带宽内存(HBM)这会干扰预填充阶段的内存访问模式共享的L2缓存和内存控制器成为瓶颈造成资源争用实测数据显示在A100 GPU上单个预填充请求混入解码批次时TPOT(每输出token时间)会恶化达47%。这种干扰在长上下文场景中尤为明显因为KV缓存大小与序列长度平方成正比。1.2 内存容量限制KV缓存在推理过程中必须全程驻留GPU内存。对于70B参数的LLM处理2048长度的序列时每层KV缓存约占用2×2×2048×4096×2(bytes) ≈ 134MB按80层计算总缓存达134MB × 80 ≈ 10.7GB批量处理32个请求时需要10.7GB × 32 ≈ 342GB显存这远超当前单卡GPU的内存容量(如A100 80GB)导致频繁的缓存逐出和重计算。分阶段推理通过专用解码GPU可以缓解此问题但引入了KV缓存传输开销。1.3 能效瓶颈LLM推理的能耗主要来自总能耗 ∫(GPU功率 CPU功率 内存功率)dt其中GPU功率占主导遵循P_GPU ≈ C×V²×f P_staticC为电容V为电压f为频率。在colocated模式下GPU频率需同时满足TTFT和TPOT的SLO(服务等级目标)往往导致能效次优。2. 分阶段推理架构设计2.1 系统架构比较分阶段推理(disaggregated serving)将预填充和解码分配到独立GPU主要实现方式包括架构类型KV传输路径带宽(GB/s)延迟(μs)适用场景GPU直连NVLink300-6005-10同节点多GPUPCIe桥接PCIe P2P32-6420-50同节点多GPUCPU卸载CPU内存10-20100-200跨节点/异构GPU磁盘卸载NVMe SSD3-71000冷启动/存档实测数据显示对于3B参数的Llama模型处理2048长度输入NVLink传输耗时占总推理时间约3%PCIe传输使TTFT增加15-20msCPU卸载导致TPOT恶化达35%2.2 KV缓存传输优化KV缓存传输是分阶段推理的关键路径优化手段包括压缩传输# 使用CacheGen的块稀疏压缩 compressed_cache apply_block_sparsity(kv_cache, ratio0.5) # 50%稀疏 send_compressed(compressed_cache)流水线传输将KV缓存按层分块预填充完成第N层即开始传输解码GPU边接收边计算位置无关缓存(PIC)def pic_reuse(query, cached_blocks): matched position_independent_match(query, cached_blocks) if matched: return fused_attention(query, matched) else: return full_attention(query)2.3 资源分配策略分阶段推理需要精细的资源配比预填充GPU高计算能力(如H100)解码GPU大内存带宽(如A100)传输通道根据SLO选择TTFT100ms必须NVLinkTTFT300ms可用PCIeTTFT500ms考虑CPU卸载实测表明处理混合负载时预填充与解码GPU的最佳数量比为1:2到1:3之间。3. 能效优化技术3.1 动态电压频率调节(DVFS)通过DVFS构建Pareto前沿离线分析不同频率下的性能freqs [0.21, 0.51, 0.81, 1.11, 1.41] # GHz perf_data [] for f in freqs: set_gpu_freq(f) ttft, tpot, power benchmark_run() perf_data.append((f, ttft, tpot, power))在线服务时选择最优频率def select_freq(slo_ttft, slo_tpot): feasible [p for p in perf_data if p[1]slo_ttft and p[2]slo_tpot] return min(feasible, keylambda x: x[3])[0]实测显示DVFS可为colocated部署节省15-20%能耗但对分阶段推理的增益有限(约5-8%)。3.2 KV缓存复用技术前缀匹配def prefix_match(new_request, cached_requests): for cr in cached_requests: if new_request.tokens[:cr.length] cr.tokens: return cr.kv_cache[:cr.length] return None语义缓存使用小型模型(如BERT)提取请求语义特征构建特征向量相似度索引(如FAISS)相似请求直接复用解码结果在RAG场景下KV缓存复用可降低30-50%的计算开销。3.3 混合精度计算精度模式内存占用计算速度质量损失FP321x1x0%FP160.5x2-3x0.5%INT80.25x4-5x1-2%INT40.125x6-8x3-5%推荐配置预填充阶段FP16保证精度解码阶段INT8平衡速度与质量4. 性能与能效实测分析4.1 延迟对比测试在2×A100节点上测试不同架构批量大小co-2gpus TTFT(ms)dis-gpu TTFT(ms)co-2gpus TPOT(ms)dis-gpu TPOT(ms)8126158453816217285473932409532624164内存溢出892内存溢出44关键发现小批量时colocated延迟更低大批量时分阶段避免内存溢出解码性能始终优于colocated4.2 能效对比架构类型能耗(J/token)相对值co-2gpus0.811.0xdis-gpu1.121.38xdis-cpu1.451.79xdis-disk1.872.31x虽然分阶段推理能耗更高但其吞吐量优势在特定场景下可抵消能耗劣势def break_even_point(): co_throughput 1200 # tokens/s dis_throughput 1800 co_energy 0.81 dis_energy 1.12 # 计算单位时间能耗比 return (dis_energy/dis_throughput) / (co_energy/co_throughput) # ≈0.934.3 优化技术收益优化技术延迟降低能耗降低DVFS0%15-20%KV复用25-40%30-50%混合精度50-70%60-75%流水线传输10-15%5-8%5. 工程实践建议5.1 部署选型决策树if 批量大小 16 and 内存充足: 选择colocated elif 有NVLink且TTFT SLO严格: 选择dis-gpu elif 请求有大量共享上下文: 选择dis-cpuKV复用 else: 保持colocated5.2 典型配置示例实时聊天场景deployment_type: dis-gpu gpu_config: prefill: H100×1 (FP16) decode: A100×2 (INT8) transfer: NVLink optimizations: - kv_reuse: prefix_match - pipeline_transfer: true slo: ttft: 200ms tpot: 50ms文档批处理场景deployment_type: dis-cpu gpu_config: prefill: A100×2 (FP16) decode: A100×4 (INT8) transfer: CPU内存 optimizations: - kv_reuse: semantic_cache - dvfs: enabled slo: ttft: 500ms tpot: 100ms5.3 避坑指南NVLink兼容性检查nvidia-smi topo -m确认GPU连接拓扑避免跨NUMA节点传输CPU卸载陷阱# 错误做法直接使用pickle序列化 import pickle pickle.dump(kv_cache) # 产生高CPU负载 # 正确做法使用零拷贝内存 import cupy host_buf cupy.asnumpy(kv_cache, streamnon_blocking_stream)DVFS调优要点频率步进建议0.1GHz间隔需要关闭GPU Boost每个频率点至少测试5次取中值KV缓存管理# LRU策略可能不适合LLM class SemanticAwareCache: def evict(self): # 优先淘汰低相似度的缓存 return max(self.entries, keylambda x: x.semantic_distance)在实际部署中我们观察到分阶段推理最适合具有以下特征的负载批量大小16序列长度1024TTFT与TPOT SLO差异2:1存在可复用的KV缓存模式对于通用场景建议从colocated开始通过性能剖析逐步评估是否需要分阶段。