> ## Documentation Index
> Fetch the complete documentation index at: https://tserjay.club/llms.txt
> Use this file to discover all available pages before exploring further.

# vLLM V1 新增特征

1.优化执行循环（cpu性能瓶颈） 和 API 服务

2.简单灵活的调度器：prefill 和 decoder

3.零开销前缀缓存：使用基于哈希的前缀缓存和基于 LRU 的缓存驱逐。（cache 命中0% 对于性能几乎没有影响，但是当 cache 命中超过50% 、75% 对于性能的提升 2、4 倍 ）

4.清晰的张量并行架构：在 V0 中，为了解决不同进程之间的通信开销，调度器和worker 0位于同一进程中，减少了将输入数据广播到workers时进程的进程开销，这是一种不对称架构设计，增加了复杂性；在V1中，调度器和worker 0在单独的进程中运行，形成了一种对称架构设计，worker 端缓存请求状态并在每个步骤仅传输增量更新（差异）来克服这一点。这种优化最大限度地减少了进程间通信

5.高效的数据输入：V1 实现了 [Persistent Batch](https://github.com/InternLM/lmdeploy) 技术，该技术缓存了输入张量，并且每个步骤仅对其应用差异，并广泛采用了Numpy操作，而不是Python 的原生操作，最大限度减少更新张量时的CPU开销。

朴素批处理与静态批处理：类似cpu单线程处理，整个批次需要等待每个序列处理完毕一起释放资源并返回结果，会导致大量的GPU占用，特别是出现在同一批次中序列长度差异较大的情况，会对吞吐量的影响较大。

Persistent Batch（采用了连续批处理）：

类似 cpu 优化中的流水线 原理，最大可能不让 GPU 闲置。

它采用了迭代级调度，其中批大小根据每次迭代确定。结果是，一旦批中的一个序列完成生成，就可以在其位置插入一个新的序列，从而实现比静态批处理更高的GPU利用率。

  现实情况比这个简化模型更复杂：因为预填充阶段需要计算，并且与生成阶段的计算模式不同，因此它不能很容易地与令牌的生成一起进行批量。连续批处理框架目前通过超参数来管理这个问题：等待已服务比和等待结束序列标记的请求比（waiting\_served\_ratio）

6.torch.compile 和分段 CUDA 图

7.FlashAttention 3

vLLM V1 的最后一块拼图是集成 [FlashAttention 3](https://arxiv.org/abs/2407.08608)。鉴于 V1 中高度的动态性（例如在同一批次中组合预填充和解码），一个灵活且高性能的注意力内核至关重要。FlashAttention 3 有效地满足了这一要求，为广泛的功能提供了强大的支持，同时在各种用例中保持了出色的性能。

8.增强对多模态 LLM 的支持