正文

请到「今天看啥」查看全文

• 适用场景：单卡或 Neuron环境

（4）external_launcher：ExecutorWithExternalLauncher

• 适用场景：想要用自定义的外部工具（例如Slurm）来做分布式管理

注意：以上的“适用场景”描述的是一般情况，更具体的细节，请参见“决定executor类型”的相关代码。

在本文中，我们将以mp: MultiProcExecutor进行讲解，并假设这里的分布式配置仅用了tp，其余的细节留给用户自行阅读。

二、Executor -> Workers

2.1 整体架构-官网版

我们先来看下官方给出的Executor-Workers架构图。

https://blog.vllm.ai/2025/01/27/v1-alpha-release.html

上图右侧刻画了V1的架构：

• Scheduler和Executor都位于EngineCoreProc所在的进程上 。如本文第一章offline batching的流程图所示，Scheduler决定单次调度步骤中要送去推理的请求，并将这些请求发送给Executor。
• 一个Executor下管理着若干workers，每个workers位于独立的进程上 ，可以理解成一个workers占据着一张卡
• Executor负责把请求broadcast到各个workers上
• 各个workers接收到请求，负责执行实际的推理过程，并将推理结果返回给Executor。

相比于V0，V1这种架构设计的优势在于 ：在V0中，worker0既要负责调度和数据分发、又要负责实际的推理计算。如此一来， 各个workers间存在负载不均的问题，而worker0将成为性能的瓶颈。而V1通过拆分【调度】和【计算】过程解决了这个问题 。

2.2 整体架构-细节版

现在我们已经通过vllm官方的示例图，初步了解了V1下Executor-Workers的架构，现在我们扩展这张架构图，来看更多的细节， 为了画图简明，这里我们只展示了其中1个worker，没有画出全部workers ：

上图展示的是使用 MultiprocExecutor 下的架构，如前文所说，该类型的Executor常被用于单机多卡的推理场景，我们按照 从上到下，从左到右 的顺序来解读上图。

1、MultiprocExecutor和Scheduler都位于EngineCoreProc所在的进程中 。 Scheduler负责决定单次调度步骤中，要送去推理的reqs，并将这些reqs传递给MultiprocExecutor。

2、在MultiprocExecutor上，我们将创建一个rpc_broadcast_mq队列 ：

• 该队列存储着Executor要broadcast给各个workers的【小数据(<=10MB)】，而【大数据(>10MB)】则不会进入此队列，而是通过zmq socket进行传输

• 每条数据可以被粗糙理解成是(method, data)的形式，data = 数据本身，method=你期望worker上调用什么样的方法来处理这条数据。

• 针对这个队列、以及大小数据的传输细节，我们将在本文第三部分详细介绍。

3、在MultiProcExecutor上，通过make_worker_process创建子进程：

• 每个进程占据一张卡，每个进程上运行着一个worker实例
• 在创建每个子进程时，我们会将rpc_broadcast_mq_handler，也就是输入队列的句柄也传递给子进程，这里你可以粗糙将“handler（句柄）”理解成是一个“地址”，有了这个地址，每个子进程才知道要去哪里找到并【连接】这个队列，以此读到队列中的数据。相关细节我们同样在后文给出。

请到「今天看啥」查看全文