DeepSpeed-FastGen 深度解析基于 MII 与 DeepSpeed-Inference 的 LLM 高吞吐推理服务系统【免费下载链接】DeepSpeedDeepSpeed is a deep learning optimization library that makes distributed training and inference easy, efficient, and effective.项目地址: https://gitcode.com/GitHub_Trending/de/DeepSpeed本文基于 DeepSpeed 官方博客《DeepSpeed-FastGen通过 MII 和 DeepSpeed-Inference 实现 LLM 高吞吐量文本生成》整理扩充完整讲解 DeepSpeed-FastGen 的两大核心技术——分块 KV 缓存Blocked KV Cache与动态分割融合Dynamic SplitFuse——并结合当前 DeepSpeed 仓库中deepspeed/inference/v2的实际源码说明其分块 KV 缓存与模型适配层的落地实现。读完本文你将理解 LLM 推理服务中提示处理/生成抢占问题的成因、动态 SplitFuse 的调度原理与性能依据并掌握从安装、非持久管道到持久化 GRPC 服务的完整部署路径。1. 引言交互式文本生成为何成为推理吞吐瓶颈GPT-4 和 LLaMA 这样的大型语言模型LLM已在各个层次上成为集成 AI 的主流服务应用——从常规聊天模型到文档摘要从自动驾驶到软件各层的 Copilot 功能模型部署与服务需求正在迅速增长。DeepSpeed、PyTorch 等框架可以在 LLM 训练期间实现良好的硬件利用率但交互式应用的开放式文本生成计算强度arithmetic intensity相对较低现有系统往往在推理吞吐量上遇到瓶颈。由 PagedAttention 驱动的 vLLM 以及 Orca 等系统显著提升了 LLM 推理性能但在长提示long prompt工作负载下仍难以提供稳定的服务质量QoS。随着越来越多的模型和系统如 DeepSpeed Ulysses支持数万个令牌的上下文窗口长提示工作负载变得越来越重要。问题的根源在于LLM 文本生成天然包含两个阶段——提示处理把用户输入批处理成令牌并构建注意力 KV 缓存与令牌生成向缓存追加单个令牌并产生新令牌。当系统把两者视为不同阶段时生成阶段会被提示处理抢占preempt从而可能破坏服务级别协议SLA。DeepSpeed-FastGen 提出的解决方案是动态 SplitFuse通过动态拆解提示令牌并与生成令牌统一组合保持每次前向传递forward pass的大小一致从而提供比 vLLM 等高出现代系统最高 2.3 倍的有效吞吐量。快速开始安装最新的 DeepSpeed-MII 发行版即可pip install deepspeed-mii使用最简单的非持久管道部署并生成文本from mii import pipeline pipe pipeline(mistralai/Mistral-7B-v0.1) output pipe([Hello, my name is, DeepSpeed is], max_new_tokens128) print(output)2. 现有 LLM 服务技术分块 KV 缓存与连续批处理单序列文本生成工作负载包含两个阶段提示处理prompt processing系统高效处理用户文本将其转换为令牌批次构建注意力机制的键值KV缓存令牌生成token generation向该缓存中追加单个令牌并生成新令牌。生成一段完整文本的过程中系统会对模型进行多次前向调用。文献与现有系统中已有两项关键技术分别针对这两个阶段的瓶颈2.1 分块 KV 缓存Blocked KV CachingvLLM 指出大型单体 KV 缓存导致的内存碎片化显著降低了 LLM 服务系统的并发性并提出了分页注意力Paged Attention机制底层存储不再是大小不一的连续内存块而是固定大小的块blocks/pages。分块 KV 缓存通过消除 KV 缓存引起的内存碎片增加了潜在的序列并发量从而提升系统总吞吐量。HuggingFace TGI 与 NVIDIA TensorRT-LLM 也实现了非连续 KV 缓存。2.2 连续批处理Continuous Batching过去动态批处理服务器等待多个请求以同步处理被用来提高 GPU 利用率但缺点明显通常需要将输入填充padding到相同长度或让系统停顿以构建更大的批次。Orca 提出的迭代级调度iteration-level scheduling即连续批处理在模型的每次前向传递时作出独立的调度决策允许请求按需加入/离开批次从而消除填充请求的需要。除 Orca 外NVIDIA TRT-LLM、HuggingFace TGI 和 vLLM 也实现了连续批处理。当前系统实现连续批处理主要有两种方法系统策略问题TGI / vLLM生成阶段被抢占以执行提示处理TGI 中称为 infill之后再继续生成长提示处理期间生成被暂停Orca不区分两个阶段只要总序列数未达固定上限就把提示加入运行中的批次长提示仍以完整长度在批次中运行两种方法都在不同程度上需要暂停生成以处理长提示。为了解决这些缺点DeepSpeed 提出了动态 SplitFuse 策略。3. 动态 SplitFuse新颖的提示与生成组合策略DeepSpeed-FastGen 与 TRT-LLM、TGI、vLLM 一样利用连续批处理和非连续 KV 缓存提升数据中心 LLM 服务的硬件利用率与响应速度在此基础上SplitFuse 利用动态提示/生成分解与统一进一步改善连续批处理和系统吞吐。3.1 三个关键性能见解动态 SplitFuse 的设计建立在三个性能观察之上见解 1哪些因素影响单个 LLM 的前向传递前向传递中序列的组成批次内的序列数量对性能的影响可以忽略不计真正主导性能的是前向传递中的令牌总数。这意味着高效调度器只需围绕单一信号——前向传递的令牌数——来构建。见解 2模型吞吐量与令牌数量的关系LLM 有两个关键运行区间且过渡相对陡峭令牌数量较少时GPU 瓶颈在于从内存读取模型权重吞吐量随令牌数增加而上升令牌数量足够多时模型受GPU 计算能力限制吞吐量近乎恒定饱和区间。因此若能让所有前向传递都保持在吞吐量饱和区间模型运行效率最高。见解 3如何跨多个前向传递调度一组令牌观察表明对于对齐良好的输入令牌吞吐量曲线是凹函数二阶导数 ≤ 0。设 $f(x)$ 为给定模型的延迟-吞吐凹函数则$$0 \geq f(x h) - 2f(x) f(x - h) \quad\Rightarrow\quad 2f(x) \geq f(x h) f(x - h)$$即对于给定的2x个总令牌均匀分割到两个批次是最大化吞吐量的方式。更一般地若系统需要在 F 个前向传递中处理 P 个令牌最理想的分区方案就是均匀分配。3.2 动态分割融合Dynamic SplitFuse的两大行为动态 SplitFuse 是一种用于提示处理与令牌生成的新型令牌组合策略通过从提示中取出部分令牌并与生成过程结合使模型保持一致的前向传递大小forward size。具体执行两个关键行为拆分长提示Split将长提示分解成更小的块调度到多个前向传递迭代中只有在最后一个传递中才执行生成融合短提示Fuse短提示被组合以精确填满目标令牌预算。即使是短提示也可能被拆分以确保预算被精确满足、前向传递大小保持良好对齐。这带来三方面具体收益更好的响应性长提示不再需要极长的前向传递客户端延迟更低同一时间窗口内执行的前向传递更多更高的效率短提示融合到更大的令牌预算使模型持续运行在高吞吐量状态更低的波动与更好的一致性前向传递大小一致而前向传递大小是性能的主要决定因素因此每次前向传递的延迟比竞争系统更一致由于无需抢占或长时间运行提示生成频率也更低延迟、更稳定。其效果是DeepSpeed-FastGen 以允许快速持续生成的速率从入站提示中消耗令牌同时向系统添加令牌以提高利用率为所有客户端提供更低延迟、更高吞吐的流式生成。4. 性能评估DeepSpeed-FastGen 利用分块 KV 缓存与动态分割融合连续批处理提供了先进的 LLM 服务性能。官方博客在 NVIDIA A100、H100 和 A6000 上对 Llama-2 7B、13B 和 70B 的 vLLM 与 DeepSpeed-FastGen 进行了对比评估。4.1 基准测试方法论采用两种主要定量方法1吞吐量-延迟曲线模拟多个客户端132 个同时向服务器发送请求总计 512 个。每个请求的结果延迟在端点测量吞吐量通过完成实验的端到端时间测量。2有效吞吐量Effective Throughput针对聊天类交互应用的 SLA 框架覆盖聊天场景的三个环节——用户发送提示、系统处理并返回首令牌、后续令牌流式传输。由于提示与生成文本长度差异显著SLA 设定为提示延迟 SLA |提示中的令牌数| / 512 秒即 512 令牌/秒生成延迟 SLA 指数移动平均EMA下 2、4 或 6 令牌/秒。满足这些 SLA 的请求被视为成功成功请求的吞吐量即为有效吞吐量。4.2 吞吐量-延迟分析DeepSpeed-FastGen 在吞吐量和延迟两个维度上均优于 vLLM相同延迟下吞吐量更大相同吞吐量下响应延迟更小。以 Llama-2 70B 运行于 4×A100-80GB张量并行为例相同延迟9 秒下吞吐量最高达 2 倍1.36 rps 对比 0.67 rps相同吞吐量1.2 rps下延迟最高降低 50%7 秒对比 14 秒。Llama-2 13B 的评估呈现相同趋势提示/生成长度均取均值 1200/2600 与 128/60、30% 方差的正态分布。4.3 有效吞吐量分析在同时考虑首令牌延迟与生成速率的有效吞吐量分析下DeepSpeed-FastGen 的吞吐量比 vLLM 高出最多 2.3 倍。随着客户端数量扩大有效吞吐量先上升但当客户端数量接近系统容量时延迟显著增加、大量请求未能满足 SLA有效吞吐量随之饱和或下降——曲线最高点即最优服务点。关键对比在 4 令牌/秒 SLA 下vLLM 峰值有效吞吐量为 0.63 查询/秒约 28% 的请求未满足 SLA因其抢占正在进行的生成时生成延迟明显增加相同 SLA 下 DeepSpeed-FastGen 达到 1.42 查询/秒不到 1% 的请求未满足 SLA约为 vLLM 的 2.3 倍。4.4 令牌级时间分析生成过程的 P50、P90、P95 延迟对比显示vLLM 与 DeepSpeed-FastGen 的 P50 延迟相近但 vLLM 的 P90、P95 显著更高。原因正是 vLLM 抢占正在进行的生成以处理新提示时生成延迟出现显著尖峰而 DeepSpeed-FastGen 通常同时处理之前请求的提示与生成生成延迟更加一致。4.5 负载均衡可扩展性DeepSpeed-FastGen 提供副本级负载均衡将请求均匀分布在多个服务器上。在 8 个节点16 个副本每副本 4 个 A100 GPU 运行 Llama 2 70B上单副本吞吐量为 1.46 查询/秒16 副本达到 23.7 查询/秒呈现接近线性的 16 倍增长。4.6 其他硬件平台在 H100 与 A6000 上观察到的性能趋势与 A100 一致验证了该调度策略在不同 GPU 平台上的普适性。5. DeepSpeed-FastGen软件实现与使用指南DeepSpeed-FastGen 是DeepSpeed-MII前端 API 与服务框架与DeepSpeed-Inference后端推理引擎的协同组合。两者共同提供系统的各个组成部分前端 API、使用动态 SplitFuse 调度批次的主机与设备基础设施、优化的内核实现以及构建新模型实现的工具。入门最快方式是pip install deepspeed-mii该命令会一并安装依赖的 DeepSpeed-Kernels 预编译内核库。5.1 支持的模型架构当前 alpha 版本支持以下模型架构LLaMA 与 LLaMA-2MistralOPTFalconMixtralPhi-2Qwen所有模型通过HuggingFace API提供模型权重与对应的分词器。从当前仓库源码结构看后端推理实现deepspeed/inference/v2/model_implementations/__init__.py已导出 LLaMA-2、OPT、Mistral、Mixtral、Falcon、Phi、Phi-3、Qwen、Qwen2、Qwen2-MoE、Exaone4 等模型族实现说明该模型适配层在博客发布后持续扩展与博客路线图更广泛的模型支持一致。5.2 部署选项非持久管道 vs 持久部署安装后有两种部署方式1非持久管道Non-persistent pipeline适合快速入门与临时交互式会话只需几行代码非持久模型只在运行的 Python 脚本期间存在。from mii import pipeline pipe pipeline(mistralai/Mistral-7B-v0.1) output pipe([Hello, my name is, DeepSpeed is], max_new_tokens128) print(output)2持久部署Persistent deployment适合长时间运行与生产应用使用轻量级 GRPC 服务器两行代码即可创建import mii mii.serve(mistralai/Mistral-7B-v0.1)该服务器得益于 DeepSpeed-MII 内置的负载均衡器可同时被多个客户端查询。创建客户端同样只需两行client mii.client(mistralai/Mistral-7B-v0.1) output client.generate(Deepspeed is, max_new_tokens128) print(output)不再需要时可终止持久部署client.terminate_server()5.3 高级安装信息为显著减少许多框架所需的冗长编译时间DeepSpeed 通过DeepSpeed-Kernels库分发覆盖大部分自定义内核的预编译 Python wheel。该库在 NVIDIA GPU 计算能力 8.0Ampere、CUDA 11.6 与 Ubuntu 20 的环境中具有良好可移植性。大多数情况下无需感知该库的存在——它是 DeepSpeed-MII 的依赖项会随之自动安装如需手动编译内核可参考 DeepSpeed-Kernels 的源码安装文档。6. 仓库源码佐证分块 KV 缓存在 DeepSpeed-Inference 中的落地博客所述 DeepSpeed-FastGen 的后端能力分块 KV 缓存、模型适配工具链在当前 DeepSpeed 仓库的deepspeed/inference/v2模块中留下了清晰的实现足迹可以作为理解博客技术主张的源码级依据分块 KV 缓存BlockedKVCache 以 6D 张量(num_caches, num_blocks, block_size, 2, num_heads, head_size)作为所有 KV 缓存的后备存储配合BlockedAllocator按固定大小的块分配/跟踪缓存——这正是第 2.1 节固定大小块而非变长连续内存描述的落地形态序列状态管理DSStateManager 维护系统中所有序列的描述符_seqs与块 ID 跟踪表all_block_ids并配有 host 侧影子副本用于同步支撑动态加入/离开批次的调度需求模型适配层deepspeed/inference/v2/model_implementations 提供DSInferenceModelBase等基类及各模型族实现llama_v2、opt、mistral、mixtral、falcon、phi、phi3、qwen、qwen_v2、qwen_v2_moe、exaone4 等并附有 AddingAModel.md 指引新增模型的构建方式对应博客构建新模型实现的工具优化内核deepspeed/inference/v2/kernels/ragged_ops/linear_blocked_kv_rotary 提供了与分块 KV 布局融合的 QKV 投影与旋转位置编码内核体现优化内核实现与博客致谢中提及的 FlashAttention、FasterTransformer 内核路线。需要注意的适用前提博客中的性能对比数据产生于其 alpha 版本的评测环境A100/H100/A6000、Llama-2 系列、对比 vLLM复现结论时应以该环境为准当前仓库的推理引擎inference v2在 API 与模型覆盖上已演进与博客描述的 MII alpha 版本细节可能存在差异使用前建议以仓库内现有文档和代码为准。7. 小结与后续方向DeepSpeed-FastGen 的核心贡献在于把 LLM 推理服务中的提示处理 vs 生成矛盾转化为一个令牌预算调度问题三个性能见解序列组成无关、吞吐饱和区间、凹函数均匀分配共同推导出动态 SplitFuse 的两类行为——拆分长提示、融合短提示——从而在不抢占生成的前提下同时改善延迟一致性与系统吞吐量最终取得对 vLLM 最高 2.3 倍的有效吞吐优势与近乎线性的副本级扩展能力。博客公布的路线图包括性能改进、更广泛的模型支持、通过合作伙伴支持新硬件后端、以及发布博客中图表所依赖的性能测试套件。相关技术演进可在仓库中继续追踪推理后端见 deepspeed/inferenceUlysses 序列并行见 blogs/deepspeed-ulysses/README.md以及本博客的后续更新 2024-01-19 模型扩展公告新增 Mixtral、Phi-2、Falcon 支持。【免费下载链接】DeepSpeedDeepSpeed is a deep learning optimization library that makes distributed training and inference easy, efficient, and effective.项目地址: https://gitcode.com/GitHub_Trending/de/DeepSpeed创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
DeepSpeed-FastGen 深度解析：基于 MII 与 DeepSpeed-Inference 的 LLM 高吞吐推理服务系统
DeepSpeed-FastGen 深度解析基于 MII 与 DeepSpeed-Inference 的 LLM 高吞吐推理服务系统【免费下载链接】DeepSpeedDeepSpeed is a deep learning optimization library that makes distributed training and inference easy, efficient, and effective.项目地址: https://gitcode.com/GitHub_Trending/de/DeepSpeed本文基于 DeepSpeed 官方博客《DeepSpeed-FastGen通过 MII 和 DeepSpeed-Inference 实现 LLM 高吞吐量文本生成》整理扩充完整讲解 DeepSpeed-FastGen 的两大核心技术——分块 KV 缓存Blocked KV Cache与动态分割融合Dynamic SplitFuse——并结合当前 DeepSpeed 仓库中deepspeed/inference/v2的实际源码说明其分块 KV 缓存与模型适配层的落地实现。读完本文你将理解 LLM 推理服务中提示处理/生成抢占问题的成因、动态 SplitFuse 的调度原理与性能依据并掌握从安装、非持久管道到持久化 GRPC 服务的完整部署路径。1. 引言交互式文本生成为何成为推理吞吐瓶颈GPT-4 和 LLaMA 这样的大型语言模型LLM已在各个层次上成为集成 AI 的主流服务应用——从常规聊天模型到文档摘要从自动驾驶到软件各层的 Copilot 功能模型部署与服务需求正在迅速增长。DeepSpeed、PyTorch 等框架可以在 LLM 训练期间实现良好的硬件利用率但交互式应用的开放式文本生成计算强度arithmetic intensity相对较低现有系统往往在推理吞吐量上遇到瓶颈。由 PagedAttention 驱动的 vLLM 以及 Orca 等系统显著提升了 LLM 推理性能但在长提示long prompt工作负载下仍难以提供稳定的服务质量QoS。随着越来越多的模型和系统如 DeepSpeed Ulysses支持数万个令牌的上下文窗口长提示工作负载变得越来越重要。问题的根源在于LLM 文本生成天然包含两个阶段——提示处理把用户输入批处理成令牌并构建注意力 KV 缓存与令牌生成向缓存追加单个令牌并产生新令牌。当系统把两者视为不同阶段时生成阶段会被提示处理抢占preempt从而可能破坏服务级别协议SLA。DeepSpeed-FastGen 提出的解决方案是动态 SplitFuse通过动态拆解提示令牌并与生成令牌统一组合保持每次前向传递forward pass的大小一致从而提供比 vLLM 等高出现代系统最高 2.3 倍的有效吞吐量。快速开始安装最新的 DeepSpeed-MII 发行版即可pip install deepspeed-mii使用最简单的非持久管道部署并生成文本from mii import pipeline pipe pipeline(mistralai/Mistral-7B-v0.1) output pipe([Hello, my name is, DeepSpeed is], max_new_tokens128) print(output)2. 现有 LLM 服务技术分块 KV 缓存与连续批处理单序列文本生成工作负载包含两个阶段提示处理prompt processing系统高效处理用户文本将其转换为令牌批次构建注意力机制的键值KV缓存令牌生成token generation向该缓存中追加单个令牌并生成新令牌。生成一段完整文本的过程中系统会对模型进行多次前向调用。文献与现有系统中已有两项关键技术分别针对这两个阶段的瓶颈2.1 分块 KV 缓存Blocked KV CachingvLLM 指出大型单体 KV 缓存导致的内存碎片化显著降低了 LLM 服务系统的并发性并提出了分页注意力Paged Attention机制底层存储不再是大小不一的连续内存块而是固定大小的块blocks/pages。分块 KV 缓存通过消除 KV 缓存引起的内存碎片增加了潜在的序列并发量从而提升系统总吞吐量。HuggingFace TGI 与 NVIDIA TensorRT-LLM 也实现了非连续 KV 缓存。2.2 连续批处理Continuous Batching过去动态批处理服务器等待多个请求以同步处理被用来提高 GPU 利用率但缺点明显通常需要将输入填充padding到相同长度或让系统停顿以构建更大的批次。Orca 提出的迭代级调度iteration-level scheduling即连续批处理在模型的每次前向传递时作出独立的调度决策允许请求按需加入/离开批次从而消除填充请求的需要。除 Orca 外NVIDIA TRT-LLM、HuggingFace TGI 和 vLLM 也实现了连续批处理。当前系统实现连续批处理主要有两种方法系统策略问题TGI / vLLM生成阶段被抢占以执行提示处理TGI 中称为 infill之后再继续生成长提示处理期间生成被暂停Orca不区分两个阶段只要总序列数未达固定上限就把提示加入运行中的批次长提示仍以完整长度在批次中运行两种方法都在不同程度上需要暂停生成以处理长提示。为了解决这些缺点DeepSpeed 提出了动态 SplitFuse 策略。3. 动态 SplitFuse新颖的提示与生成组合策略DeepSpeed-FastGen 与 TRT-LLM、TGI、vLLM 一样利用连续批处理和非连续 KV 缓存提升数据中心 LLM 服务的硬件利用率与响应速度在此基础上SplitFuse 利用动态提示/生成分解与统一进一步改善连续批处理和系统吞吐。3.1 三个关键性能见解动态 SplitFuse 的设计建立在三个性能观察之上见解 1哪些因素影响单个 LLM 的前向传递前向传递中序列的组成批次内的序列数量对性能的影响可以忽略不计真正主导性能的是前向传递中的令牌总数。这意味着高效调度器只需围绕单一信号——前向传递的令牌数——来构建。见解 2模型吞吐量与令牌数量的关系LLM 有两个关键运行区间且过渡相对陡峭令牌数量较少时GPU 瓶颈在于从内存读取模型权重吞吐量随令牌数增加而上升令牌数量足够多时模型受GPU 计算能力限制吞吐量近乎恒定饱和区间。因此若能让所有前向传递都保持在吞吐量饱和区间模型运行效率最高。见解 3如何跨多个前向传递调度一组令牌观察表明对于对齐良好的输入令牌吞吐量曲线是凹函数二阶导数 ≤ 0。设 $f(x)$ 为给定模型的延迟-吞吐凹函数则$$0 \geq f(x h) - 2f(x) f(x - h) \quad\Rightarrow\quad 2f(x) \geq f(x h) f(x - h)$$即对于给定的2x个总令牌均匀分割到两个批次是最大化吞吐量的方式。更一般地若系统需要在 F 个前向传递中处理 P 个令牌最理想的分区方案就是均匀分配。3.2 动态分割融合Dynamic SplitFuse的两大行为动态 SplitFuse 是一种用于提示处理与令牌生成的新型令牌组合策略通过从提示中取出部分令牌并与生成过程结合使模型保持一致的前向传递大小forward size。具体执行两个关键行为拆分长提示Split将长提示分解成更小的块调度到多个前向传递迭代中只有在最后一个传递中才执行生成融合短提示Fuse短提示被组合以精确填满目标令牌预算。即使是短提示也可能被拆分以确保预算被精确满足、前向传递大小保持良好对齐。这带来三方面具体收益更好的响应性长提示不再需要极长的前向传递客户端延迟更低同一时间窗口内执行的前向传递更多更高的效率短提示融合到更大的令牌预算使模型持续运行在高吞吐量状态更低的波动与更好的一致性前向传递大小一致而前向传递大小是性能的主要决定因素因此每次前向传递的延迟比竞争系统更一致由于无需抢占或长时间运行提示生成频率也更低延迟、更稳定。其效果是DeepSpeed-FastGen 以允许快速持续生成的速率从入站提示中消耗令牌同时向系统添加令牌以提高利用率为所有客户端提供更低延迟、更高吞吐的流式生成。4. 性能评估DeepSpeed-FastGen 利用分块 KV 缓存与动态分割融合连续批处理提供了先进的 LLM 服务性能。官方博客在 NVIDIA A100、H100 和 A6000 上对 Llama-2 7B、13B 和 70B 的 vLLM 与 DeepSpeed-FastGen 进行了对比评估。4.1 基准测试方法论采用两种主要定量方法1吞吐量-延迟曲线模拟多个客户端132 个同时向服务器发送请求总计 512 个。每个请求的结果延迟在端点测量吞吐量通过完成实验的端到端时间测量。2有效吞吐量Effective Throughput针对聊天类交互应用的 SLA 框架覆盖聊天场景的三个环节——用户发送提示、系统处理并返回首令牌、后续令牌流式传输。由于提示与生成文本长度差异显著SLA 设定为提示延迟 SLA |提示中的令牌数| / 512 秒即 512 令牌/秒生成延迟 SLA 指数移动平均EMA下 2、4 或 6 令牌/秒。满足这些 SLA 的请求被视为成功成功请求的吞吐量即为有效吞吐量。4.2 吞吐量-延迟分析DeepSpeed-FastGen 在吞吐量和延迟两个维度上均优于 vLLM相同延迟下吞吐量更大相同吞吐量下响应延迟更小。以 Llama-2 70B 运行于 4×A100-80GB张量并行为例相同延迟9 秒下吞吐量最高达 2 倍1.36 rps 对比 0.67 rps相同吞吐量1.2 rps下延迟最高降低 50%7 秒对比 14 秒。Llama-2 13B 的评估呈现相同趋势提示/生成长度均取均值 1200/2600 与 128/60、30% 方差的正态分布。4.3 有效吞吐量分析在同时考虑首令牌延迟与生成速率的有效吞吐量分析下DeepSpeed-FastGen 的吞吐量比 vLLM 高出最多 2.3 倍。随着客户端数量扩大有效吞吐量先上升但当客户端数量接近系统容量时延迟显著增加、大量请求未能满足 SLA有效吞吐量随之饱和或下降——曲线最高点即最优服务点。关键对比在 4 令牌/秒 SLA 下vLLM 峰值有效吞吐量为 0.63 查询/秒约 28% 的请求未满足 SLA因其抢占正在进行的生成时生成延迟明显增加相同 SLA 下 DeepSpeed-FastGen 达到 1.42 查询/秒不到 1% 的请求未满足 SLA约为 vLLM 的 2.3 倍。4.4 令牌级时间分析生成过程的 P50、P90、P95 延迟对比显示vLLM 与 DeepSpeed-FastGen 的 P50 延迟相近但 vLLM 的 P90、P95 显著更高。原因正是 vLLM 抢占正在进行的生成以处理新提示时生成延迟出现显著尖峰而 DeepSpeed-FastGen 通常同时处理之前请求的提示与生成生成延迟更加一致。4.5 负载均衡可扩展性DeepSpeed-FastGen 提供副本级负载均衡将请求均匀分布在多个服务器上。在 8 个节点16 个副本每副本 4 个 A100 GPU 运行 Llama 2 70B上单副本吞吐量为 1.46 查询/秒16 副本达到 23.7 查询/秒呈现接近线性的 16 倍增长。4.6 其他硬件平台在 H100 与 A6000 上观察到的性能趋势与 A100 一致验证了该调度策略在不同 GPU 平台上的普适性。5. DeepSpeed-FastGen软件实现与使用指南DeepSpeed-FastGen 是DeepSpeed-MII前端 API 与服务框架与DeepSpeed-Inference后端推理引擎的协同组合。两者共同提供系统的各个组成部分前端 API、使用动态 SplitFuse 调度批次的主机与设备基础设施、优化的内核实现以及构建新模型实现的工具。入门最快方式是pip install deepspeed-mii该命令会一并安装依赖的 DeepSpeed-Kernels 预编译内核库。5.1 支持的模型架构当前 alpha 版本支持以下模型架构LLaMA 与 LLaMA-2MistralOPTFalconMixtralPhi-2Qwen所有模型通过HuggingFace API提供模型权重与对应的分词器。从当前仓库源码结构看后端推理实现deepspeed/inference/v2/model_implementations/__init__.py已导出 LLaMA-2、OPT、Mistral、Mixtral、Falcon、Phi、Phi-3、Qwen、Qwen2、Qwen2-MoE、Exaone4 等模型族实现说明该模型适配层在博客发布后持续扩展与博客路线图更广泛的模型支持一致。5.2 部署选项非持久管道 vs 持久部署安装后有两种部署方式1非持久管道Non-persistent pipeline适合快速入门与临时交互式会话只需几行代码非持久模型只在运行的 Python 脚本期间存在。from mii import pipeline pipe pipeline(mistralai/Mistral-7B-v0.1) output pipe([Hello, my name is, DeepSpeed is], max_new_tokens128) print(output)2持久部署Persistent deployment适合长时间运行与生产应用使用轻量级 GRPC 服务器两行代码即可创建import mii mii.serve(mistralai/Mistral-7B-v0.1)该服务器得益于 DeepSpeed-MII 内置的负载均衡器可同时被多个客户端查询。创建客户端同样只需两行client mii.client(mistralai/Mistral-7B-v0.1) output client.generate(Deepspeed is, max_new_tokens128) print(output)不再需要时可终止持久部署client.terminate_server()5.3 高级安装信息为显著减少许多框架所需的冗长编译时间DeepSpeed 通过DeepSpeed-Kernels库分发覆盖大部分自定义内核的预编译 Python wheel。该库在 NVIDIA GPU 计算能力 8.0Ampere、CUDA 11.6 与 Ubuntu 20 的环境中具有良好可移植性。大多数情况下无需感知该库的存在——它是 DeepSpeed-MII 的依赖项会随之自动安装如需手动编译内核可参考 DeepSpeed-Kernels 的源码安装文档。6. 仓库源码佐证分块 KV 缓存在 DeepSpeed-Inference 中的落地博客所述 DeepSpeed-FastGen 的后端能力分块 KV 缓存、模型适配工具链在当前 DeepSpeed 仓库的deepspeed/inference/v2模块中留下了清晰的实现足迹可以作为理解博客技术主张的源码级依据分块 KV 缓存BlockedKVCache 以 6D 张量(num_caches, num_blocks, block_size, 2, num_heads, head_size)作为所有 KV 缓存的后备存储配合BlockedAllocator按固定大小的块分配/跟踪缓存——这正是第 2.1 节固定大小块而非变长连续内存描述的落地形态序列状态管理DSStateManager 维护系统中所有序列的描述符_seqs与块 ID 跟踪表all_block_ids并配有 host 侧影子副本用于同步支撑动态加入/离开批次的调度需求模型适配层deepspeed/inference/v2/model_implementations 提供DSInferenceModelBase等基类及各模型族实现llama_v2、opt、mistral、mixtral、falcon、phi、phi3、qwen、qwen_v2、qwen_v2_moe、exaone4 等并附有 AddingAModel.md 指引新增模型的构建方式对应博客构建新模型实现的工具优化内核deepspeed/inference/v2/kernels/ragged_ops/linear_blocked_kv_rotary 提供了与分块 KV 布局融合的 QKV 投影与旋转位置编码内核体现优化内核实现与博客致谢中提及的 FlashAttention、FasterTransformer 内核路线。需要注意的适用前提博客中的性能对比数据产生于其 alpha 版本的评测环境A100/H100/A6000、Llama-2 系列、对比 vLLM复现结论时应以该环境为准当前仓库的推理引擎inference v2在 API 与模型覆盖上已演进与博客描述的 MII alpha 版本细节可能存在差异使用前建议以仓库内现有文档和代码为准。7. 小结与后续方向DeepSpeed-FastGen 的核心贡献在于把 LLM 推理服务中的提示处理 vs 生成矛盾转化为一个令牌预算调度问题三个性能见解序列组成无关、吞吐饱和区间、凹函数均匀分配共同推导出动态 SplitFuse 的两类行为——拆分长提示、融合短提示——从而在不抢占生成的前提下同时改善延迟一致性与系统吞吐量最终取得对 vLLM 最高 2.3 倍的有效吞吐优势与近乎线性的副本级扩展能力。博客公布的路线图包括性能改进、更广泛的模型支持、通过合作伙伴支持新硬件后端、以及发布博客中图表所依赖的性能测试套件。相关技术演进可在仓库中继续追踪推理后端见 deepspeed/inferenceUlysses 序列并行见 blogs/deepspeed-ulysses/README.md以及本博客的后续更新 2024-01-19 模型扩展公告新增 Mixtral、Phi-2、Falcon 支持。【免费下载链接】DeepSpeedDeepSpeed is a deep learning optimization library that makes distributed training and inference easy, efficient, and effective.项目地址: https://gitcode.com/GitHub_Trending/de/DeepSpeed创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
