首页 > 其他分享 >vLLM (2) - 架构总览

vLLM (2) - 架构总览

时间:2024-08-17 18:55:54浏览次数:14  
标签:__ vllm vLLM 架构 __. py worker init 总览

系列文章目录

vLLM (1) - Qwen2推理&部署
vLLM (2) - 架构总览


文章目录


前言

上一篇通过Qwen2vllm推理和部署,对vllm有了简单直观的了解,但是我们尚未涉及到它的工作原理。接下来我们将以vllm源码为基础,逐步解析。本篇主要是对vllm架构的总览。


一、官方资料

repo:https://github.com/vllm-project/vllm
文档:https://docs.vllm.ai/en/latest/
论文:https://arxiv.org/abs/2309.06180

二、原理简述

原理部分已经有不少文章已经讲解了,比如这篇文章。此小节的目标是:解释一些重要概念,简述PagedAttention或者vLLM原理,为后续架构和代码的分析做准备,毕竟本系列的侧重点是源码解析。
在这里插入图片描述

  1. KV Cache:这是一种提升推理效率的技术;简单来说就是,每次foward推理生成下一个token时,都要用到之前token对应的keyvalue,因而可以把它们都缓存起来,这样就能节省推理时间;
  2. Prefill & DecodeLLM推理分为PrefillDecode两个阶段;Prefill(预填充)是将prompt的所有token一起喂给模型,这部分由于不需要采样,认为是可以并行的;Decode(解码)是不断采样生成新的token,由于是逐个生成,因此该阶段效率较低;
  3. KV cache性能问题:1)此前很多推理系统是为每一个request申请一块连续内存,此时只能选择所有requests中可能输出的最大长度来预分配KV cache,这显然造成了资源浪费,因为短句用不了这么多KV cache;2)实际情况下可能requests比较多,某一时刻某个request解码尚未完成,但始终完全占据为它预分配的连续内存,其中未使用的部分不能为新的request所用,占着茅坑不拉屎;3)存在内存碎片,非连续内存也没办法被利用起来;
  4. PagedAttention解决性能问题:使用类似虚拟内存分页管理的思想,简单来说就是,将申请的内存按照指定的大小block_size划分成很多个block,这些block可以动态的分配给有需要的request,极大减少了资源浪费;
  5. Physical blocks & Logical blocksPhysical blocks相当于物理内存,Logical blocks相当于虚拟内存,两者之间有映射关系,KV cachePhysical blocks不连续,但是在Logical blocks上是连续的。
    上图是vLLM同时处理两个请求时的KV cache处理,对于一个请求来说,我只管问Logical blocks要内存块,Physical blocks上怎么存储我不管,Physical blocksLogical blocks之间的映射关系会处理这个问题。

三、架构图

在这里插入图片描述
上图来源于vLLM First SF Meetup Slides(官方repo中),它较为直观的展示了vllm的整体架构,让我来简单介绍一下:

  • 直接处理用户请求的类是LLMEngine,它需要完成两部分内容,分别是(多个)请求的调度,以及模型的执行;
  • SchedulerLLMEngine的重要组成部分,它就是根据设定的调度策略,完成对用户请求的调度,以便调高吞吐,更快的响应;
  • Scheduler调度主要用到了虚拟内存分页管理的思想,将显存/内存划分成了很多个block,那么这些block的管理就由BlockSpaceManager完成;
  • 另一边,Worker在模型执行和KV cache缓存上发挥着重要作用,其中ModelRunner主要负责模型加载和执行等,而CacheEngine就负责KV cache的初始化和更新。

四、项目结构

为了让大家更加清晰的理解vllm的架构,我还列出了其项目结构(项目结构能直观反映它的架构),并给出了必要的注释,如下面所示。由于文件比较多,这边只展开到一级子目录。
这其中好些部分是我们暂不涉及的,我在注释中标注了(暂不涉及)字样,这能减轻我们很大的压力。重点关注对象包括core/engine/executor/worker/

vllm/
├── attention/                 # 注意力
│   ├── backends/              # 注意力各种后端实现,比如flash attention
│   ├── ops/
│   ├── layer.py
│   ├── selector.py   
│   └── __init__.py
├── core/                      # 核心,vllm最关键的部分
│   ├── block/                 # 块,为指定的序列管理物理块
│   ├── block_manager_v1.py    # 块管理器v1,管理逻辑块和物理块之间的映射关系等
│   ├── block_manager_v2.py    # 块管理器v2
│   ├── embedding_model_block_manager.py     # 针对embedding模型的块管理器
│   ├── evictor_v1.py          # 驱逐器v1,驱逐长时间未使用的物理块缓存,腾出空间
│   ├── evictor_v2.py          # 驱逐器v2
│   ├── interfaces.py
│   ├── policy.py              # 调度策略,比如fcfs(first come first serve)
│   ├── scheduler.py           # 调度器,当多个请求到来时,需要调度以高效的方式完成推理,给到用户响应
│   └── __init__.py
├── distributed/               # 分布式设备相关内容(暂不涉及)
│   ├── device_communicators/
│   ├── communication_op.py
│   ├── parallel_state.py 
│   ├── utils.py
│   └── __init__.py
├── engine/                    # 推理引擎
│   ├── output_processor/      # 输出处理器,后处理
│   ├── arg_utils.py           # 管理输入参数
│   ├── async_llm_engine.py    # 异步llm_engine,用于部署,不支持batch推理
│   ├── llm_engine.py          # llm_engine,线下推理,可以batch
│   ├── metrics.py             # 指标,记录kv_cache的使用,延迟等
│   └── __init__.py
├── entrypoints/               # 部署server相关(暂不涉及)
│   ├── openai/
│   ├── api_server.py
│   ├── llm.py 
│   └── __init__.py
├── executor/                         # 执行器
│   ├── cpu_executor.py               
│   ├── distributed_gpu_executor.py
│   ├── executor_base.py              # 执行器基类
│   ├── gpu_executor.py               # gpu执行器,比如我们使用的Nvidia单卡gpu
│   ├── multiproc_gpu_executor.py
│   ├── multiproc_worker_utils.py
│   ├── neuron_executor.py
│   ├── ray_gpu_executor.py 
│   ├── ray_utils.py
│   ├── tpu_executor.py
│   └── __init__.py
├── logging/                          # 日志
│   ├── formatter.py
│   └── __init__.py
├── lora/                             # lora相关(暂不涉及)
│   ├── fully_sharded_layers.py
│   ├── layers.py
│   ├── lora.py
│   ├── models.py 
│   ├── punica.py
│   ├── request.py
│   ├── utils.py
│   ├── worker_manager.py 
│   └── __init__.py
├── model_executor/                   # 模型执行器,主要是管理模型相关部分的          
│   ├── guided_decoding.py 
│   ├── layers.py
│   ├── models.py
│   ├── custom_op.py
│   ├── pooling_metadata.py 
│   ├── sampling_metadata.py          # 采样元数据
│   ├── utils.py 
│   └── __init__.py
├── multimodal/                       # 多模态部分(暂不涉及)
│   ├── base.py
│   ├── image.py
│   ├── registry.py 
│   ├── utils.py 
│   └── __init__.py
├── sepc_decode/                      # 投机采样(暂不涉及)
│   ├── batch_expansion.py
│   ├── interfaces.py
│   ├── metrics.py
│   ├── multi_step_worker.py 
│   ├── ngram_worker.py
│   ├── proposer_worker_base.py
│   ├── spec_decode_worker.py
│   ├── top1_proposer.py 
│   ├── utils.py 
│   └── __init__.py
├── transformers_utils/               # transformers相关的工具
│   ├── configs/ 
│   ├── tokenizers/
│   ├── tokenizer_group/
│   ├── config.py
│   ├── detokenizer.py 
│   ├── image_processor.py 
│   ├── tokenizer.py 
│   └── __init__.py
├── usage/
│   ├── usage_lib.py 
│   └── __init__.py
├── worker/                           # worker,是executor的重要组成部分
│   ├── cache_engine.py 
│   ├── cpu_model_runner.py
│   ├── cpu_worker.py
│   ├── embedding_model_runner.py
│   ├── model_runner.py               # 负责加载和执行模型,准备输入张量等
│   ├── neuron_model_runner.py 
│   ├── neuron_worker.py 
│   ├── tpu_model_runner.py 
│   ├── tpu_worker.py 
│   ├── worker.py                     # worker,使用的是gpu
│   ├── worker_base.py                # worker基类
│   └── __init__.py
├── block.py             # 块(逻辑块,物理块)定义
├── config.py            # 配置,输入参数按照功能区分构成多个配置
├── envs.py              # 环境变量相关
├── inputs.py            # 输入类定义
├── logger.py            # 日志
├── outputs.py           # 输出类定义
├── pooling_params.py     
├── py.typed
├── sampling_params.py   # 采样参数类定义
├── sequence.py          # 序列Sequence和序列组SequenceGroup等的定义
├── utils.py
├── version.py           # vllm版本
├── _C.abi3.so
├── _custom_ops.py
├── _moe_C.abi3.so
├── _punica_C.abi.so
└── __init__.py

总结

本篇通过原理简述、架构图和项目结构展示这几个部分对vllm原理和架构做了解析,相信大家对vllm有了更深入的认识,也为后续源码分析清楚了一些障碍。

标签:__,vllm,vLLM,架构,__.,py,worker,init,总览
From: https://blog.csdn.net/daihaoguang/article/details/141284561

相关文章

  • 软件架构风格
    RESTfulRESTful架构的主要特点包括:资源识别:每个URI代表一种资源,可以使用HTTP方法(GET,POST,PUT,DELETE)对资源进行操作。无状态:每个请求都包含执行操作所需的所有信息,服务器不保留客户端的状态。可缓存:响应结果可以被缓存以提高性能。统一接口:使用标准的HTTP......
  • 基于flask+vue框架的基于B_S架构的兰州市旅游网站的设计与实现[开题+论文+程序]-计算
    本系统(程序+源码+数据库+调试部署+开发环境)带论文文档1万字以上,文末可获取,系统界面在最后面。系统程序文件列表开题报告内容研究背景随着互联网的飞速发展和普及,旅游业作为全球经济的重要支柱之一,正经历着前所未有的变革。兰州市,作为甘肃省的省会城市,不仅拥有丰富的历史文......
  • Android架构组件中的MVVM
    Android架构组件中的MVVM(Model-View-ViewModel)模式是一种广泛应用的设计模式,它通过将应用程序分为三个主要部分(Model、View、ViewModel)来分离用户界面和业务逻辑,从而提高代码的可维护性、可扩展性和可测试性。下面将详细介绍MVVM模式在Android开发中的实战应用,包括基本概念......
  • Jetpack架构组件学习(5)——Hilt 注入框架使用
    原文:Jetpack架构组件学习(5)——Hilt注入框架使用-Stars-One的杂货小窝本篇需要有Kotlin基础知识,否则可能阅读本篇会有所困难!介绍说明实际上,郭霖那篇文章已经讲得比较明白了(具体参考链接都贴在下文了),这里简单总结下:如果按照之前我们的MVC写法,我们可以直接在activ......
  • 深度优化Nginx负载均衡策略,携手Keepalived打造高可用服务架构新纪元
     作者简介:我是团团儿,是一名专注于云计算领域的专业创作者,感谢大家的关注 座右铭:   云端筑梦,数据为翼,探索无限可能,引领云计算新纪元 个人主页:团儿.-CSDN博客目录前言:让我们首先来谈谈容灾与备份策略:实验目标:七台虚拟机集群利用Nginx负载均衡与Keepalived共筑高可用......
  • 架构设计(3)Lambda 架构在生鲜网购平台中的应用
     Lambda架构在生鲜网购平台中的应用:电商行业案例分析摘要本文结合在生鲜网购平台项目中的实际经验,探讨Lambda架构在大数据处理中的应用,尤其是针对电商行业的数据处理需求。生鲜网购平台面临高并发和海量数据的挑战,需要实时数据处理和准确的历史数据分析。作为系统架构师,......
  • 微前端架构下的应用版本回退策略与实践
    微前端架构通过将复杂的前端应用拆分为多个小型、独立的子应用,提高了开发效率和应用的可维护性。然而,随着应用的迭代更新,可能会遇到新版本发布后出现的问题,这时版本回退成为了确保应用稳定性的关键策略。本文将详细介绍在微前端架构下如何实现应用的版本回退,包括版本控制、......
  • 微前端架构下的应用SEO优化:策略与实践
    微前端架构通过将大型前端应用拆分为多个小型、自治的子应用,提供了更高的灵活性和可维护性。然而,这种架构也给搜索引擎优化(SEO)带来了挑战。本文将详细介绍在微前端架构下如何实现应用的SEO优化,包括SEO的基本原则、微前端架构下的SEO挑战、优化策略和最佳实践。SEO的基本原......
  • 微前端架构下的响应式设计实现策略
    微前端架构通过将一个庞大的前端应用拆分成多个小型、自治的子应用,提高了开发效率和应用可维护性。然而,这种架构也给实现统一的响应式设计带来了挑战。本文将探讨在微前端架构下如何实现应用的响应式设计,确保应用在不同设备和屏幕尺寸上都能提供良好的用户体验。响应式设计......
  • 微前端架构下子应用的性能优化策略
    微前端架构通过将大型前端应用拆分成多个小型、独立的子应用,提供了更高的灵活性和可维护性。然而,这种架构也带来了一些性能挑战。本文将深入探讨微前端架构中子应用性能优化的策略,包括代码分割、懒加载、缓存利用、服务端渲染等关键技术,并提供实际代码示例。微前端架构的性......