Skip to main content
TserJay个人博客 home page
Search...
⌘K
Dashboard
Dashboard
Search...
Navigation
概览
vLLM V1 新增特征
首页
学习记录
学习资源
temp
概览
vLLM V1 新增特征
CUDA算子
Reduce算子
Flash-Atten
vllm
第一节
vLLM V1 新增特征
概览
vLLM V1 新增特征
Copy page
Copy page
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
技术,该技术缓存了输入张量,并且每个步骤仅对其应用差异,并广泛采用了Numpy操作,而不是Python 的原生操作,最大限度减少更新张量时的CPU开销。
朴素批处理与静态批处理:类似cpu单线程处理,整个批次需要等待每个序列处理完毕一起释放资源并返回结果,会导致大量的GPU占用,特别是出现在同一批次中序列长度差异较大的情况,会对吞吐量的影响较大。
Persistent Batch(采用了连续批处理):
类似 cpu 优化中的流水线 原理,最大可能不让 GPU 闲置。
它采用了迭代级调度,其中批大小根据每次迭代确定。结果是,一旦批中的一个序列完成生成,就可以在其位置插入一个新的序列,从而实现比静态批处理更高的GPU利用率。
现实情况比这个简化模型更复杂:因为预填充阶段需要计算,并且与生成阶段的计算模式不同,因此它不能很容易地与令牌的生成一起进行批量。连续批处理框架目前通过超参数来管理这个问题:等待已服务比和等待结束序列标记的请求比(waiting_served_ratio)
6.torch.compile 和分段 CUDA 图
7.FlashAttention 3
vLLM V1 的最后一块拼图是集成
FlashAttention 3
。鉴于 V1 中高度的动态性(例如在同一批次中组合预填充和解码),一个灵活且高性能的注意力内核至关重要。FlashAttention 3 有效地满足了这一要求,为广泛的功能提供了强大的支持,同时在各种用例中保持了出色的性能。
8.增强对多模态 LLM 的支持
Was this page helpful?
Yes
No
Suggest edits
Raise issue
Reduce算子
⌘I