张家驹-释放生成式 AI 推理潜力：分布式 LLM 基础设施与 llm-d 实践.pdf

1、释放生成式AI推理潜力：分布式LLM 基础设施与llm-d实践张家驹目录01020304背景与问题vLLM：单节点LLM 推理优化llm-d:分布式推理结论与行动呼吁01背景与问题CPU 与GPU 不同的编程模型Source:https:/ 推理面临的挑战在生产环境中运行大语言模型，会面临一系列工程和运维层面的挑战，这些问题直接影响延迟、可扩展性和资源利用效率。随着模型规模增大、并发量提升以及实时响应需求增强，这些挑战会愈发突出。高延迟：自回归式解码在 70 亿参数以上的模型中，每生成一个 token 可能会带来 200600 毫秒的延迟。资源利用低效：在突发流量下，批处理效率下降，GPU 空

2、闲时间增加，导致整体算力浪费。巨大的 KV 缓存需求：在长上下文窗口（4k16k tokens）下，单个请求的 KV 缓存占用可超过 1012GB。复杂的分布式调度：跨节点的推理复制需要复杂的编排、动态的自动扩缩容机制以及资源调优策略。LLM 基础设施功能概览02单节点LLM 推理优化PagedAttention&KV Cache问题：KV 缓存挑战 在推理过程中，键值缓存（Key-Value Cache）相当于大语言模型的“记忆”，其大小会随着上下文长度线性增长。传统系统中常出现严重的内存碎片化问题，甚至触发 GPU 显存溢出（OOM）错误。这导致显存利用率极低实际有效使用率往往只有分配空间

3、的 20%40%，严重限制批处理规模并推高成本。解决方案：PagedAttention 借鉴虚拟内存的设计理念，PagedAttention 将 KV 缓存拆分为多个固定大小的小块进行管理。它将逻辑序列与 GPU 物理内存解耦，消除了内存碎片问题，并支持灵活的显存分配。PagedAttention 还能在不同请求之间动态共享缓存块，这对于多轮对话和复杂的解码策略至关重要。连续批处理Naive BatchingContinuous Batching问题：静态批处理（Static Batching）传统的批处理机制会等待固定数量的请求到达后，才开始执行前向计算。在真实业务场景中，这种方式会导致 G

4、PU 大量空闲、算力浪费严重。同时，请求需要排队等待下一个批次填满，进一步增加了响应延迟。解决方案：连续批处理（Continuous Batching）动态地将新到达的请求即时加入当前批次进行处理。通过让请求随时进入 GPU 管线，保持 GPU 长时间“满负荷”工作。这种机制有效消除了排队延迟，大幅提升了 GPU 利用率和整体吞吐性能。推测解码其他特性模型优化（Model Optimization）：采用 FP8 量化等技术，在保持精度的同时减少模型规模和延迟，更高效地利用 GPU 资源。张量并行（Tensor Parallelism）：将超大模型拆分到单节点的多张 GPU 上协同运行，实现大

5、模型的高效推理。兼容 OpenAI API（OpenAI API Compatibility）：提供标准化接口，方便开发者无缝集成到现有工具和应用中。03分布式推理vLLM 推理的局限高成本、非均匀且有状态的请求LLM 推理每个请求的计算成本比传统应用高 69 个数量级，输入输出长度差异巨大且存在关键状态依赖。资源盲目负载均衡传统 Kubernetes 的轮询或随机路由无法感知 AI 特性，忽略了 GPU 负载、队列深度、提示复杂度和 KV 缓存状态，导致 GPU 利用率低下和延迟峰值。资源利用低效在同一实例上同时处理计算密集的 prefill 阶段和内存密集的 decode 阶段效率低下，尤

6、其在长序列推理中，浪费了宝贵的 GPU 计算周期。优化机会错失缺乏 KV 缓存和前缀感知路由，使得重复提示被当作冷启动处理，无法利用缓存计算来降低延迟。可扩展性瓶颈单体部署限制了推理组件的独立扩缩容，在动态、突发流量下难以满足服务等级目标（SLO）。Kubernetes 生态下GenAI 工作负载的使能在过去的十年里，Kubernetes 已成为云原生应用的事实标准，但生成式 AI（GenAI）工作负载带来了独特的挑战。社区正在致力于让 Kubernetes 在核心层面变得“AI 感知”。标准化基准测试：社区项目正在开发评估模型和加速器配置的标准，将部署决策从经验猜测转向数据驱动。AI 感知负