摘要

  • vLLM 在常见场景下的速度与 DeepSpeed-FastGen 持平，而在处理较长输出时则更胜一筹。
  • 由于采用了 Dynamic SplitFuse 优化，DeepSpeed-FastGen 仅在长 Prompt（提示词）和短输出的场景下优于 vLLM。该优化已列入 vLLM 的开发路线图中。
  • vLLM 的使命是构建最快、最易于使用的开源 LLM 推理和提供服务的引擎。它采用 Apache 2.0 协议并由社区所有，提供广泛的模型和优化支持。

DeepSpeed 团队最近发表了一篇博客文章，声称通过利用 Dynamic SplitFuse 技术，其吞吐量比 vLLM 提高了 2 倍。我们很高兴看到开源社区的技术进步。在本篇博客中，我们将展示 Dynamic SplitFuse 技术具有优势的具体场景，并指出这些情况相对有限。对于大多数工作负载，vLLM 的速度比 DeepSpeed-FastGen 更快（或性能相当）。

性能基准测试

我们发现 vLLM 和 DeepSpeed-FastGen 在性能优化方面存在两个关键差异：

  1. DeepSpeed-FastGen 采用了保守/非最优的内存分配方案，这在输出长度较大时会浪费内存。
  2. DeepSpeed-FastGen 的 Dynamic SplitFuse 调度仅在 Prompt 长度远大于输出长度时才能带来加速。

因此，当工作负载持续为长 Prompt 和短输出时，DeepSpeed-FastGen 表现更优。而在其他场景下，vLLM 表现出更卓越的性能。

我们在配备 NVIDIA A100-80GB GPU 的环境下，使用 LLaMA-7B 模型对这两个系统进行了以下场景的基准测试：

场景 1：长 Prompt 长度，短输出

在这种情况下，DeepSpeed-FastGen 的 Dynamic SplitFuse 调度预计会表现出色。然而，我们观察到的性能提升并没有达到 2 倍那么显著。

场景 2：其他情况

在这些情况下，vLLM 比 DeepSpeed-FastGen 快达 1.8 倍。

vLLM 的未来：一个真正的社区项目

我们致力于将 vLLM 打造为融合社区最佳模型、优化和硬件的最佳开源项目。源自加州大学伯克利分校 Sky Computing 实验室，我们正以 Apache 2.0 协议在真正的开源环境中构建 vLLM。

vLLM 团队优先考虑协作，我们努力保持代码库的高质量并使其易于贡献。我们正在积极优化系统性能，并开发 LoRA、推测解码（Speculative Decoding）和更好的量化支持等新功能。此外，我们正与 AMD、AWS Inferentia 和 Intel Habana 等硬件供应商合作，将 LLM 带给最广泛的社区。

专门针对 Dynamic SplitFuse 优化，我们正在积极研究合适的集成方式。如果您有任何问题或建议，欢迎通过 GitHub 与我们联系。我们还在此处发布了基准测试代码。

附录：功能对比

DeepSpeed-FastGen 目前提供基础功能，仅支持三种模型类型，且缺乏停止字符串（stop strings）和并行采样（如束搜索 beam search）等热门功能。我们确实期待 DeepSpeed-FastGen 能够奋起直追，我们也欢迎市场上的创造性创新！

  vLLM DeepSpeed-FastGen
运行时 Python/PyTorch Python/PyTorch
模型实现 HuggingFace Transformers 自定义实现 + HF 模型转换器
服务器前端 用于演示目的的简单 FastAPI 服务器 基于自定义 gRPC 的服务器
调度 连续批处理 (Continuous batching) Dynamic SplitFuse
Attention 算子 (Attention kernel) PagedAttention & FlashAttention PagedAttention & FlashAttention
自定义算子（针对 LLaMA） Attention, RoPE, RMS, SILU Attention, RoPE, RMS, SILU, Embedding
KV 缓存分配 接近最优 非最优/保守
支持的模型 16 种不同的架构 LLaMA, Mistral, OPT
采样方法 随机采样、并行采样、束搜索 随机采样
停止准则 停止字符串、停止 Token、EOS EOS