动机

目前，OpenAI API服务器和AsyncLLMEngine共享相同的asyncio事件循环。这意味着API服务器和AsyncLLMEngine的CPU组件争夺相同的资源。以下是我们在H100上运行ShareGPT的Llama-3-8B的图表，QPS=10。
我们可以看到时间被分为三个部分：

• 浅蓝色 → 这是重叠的GPU执行时间(调用execute_model)
• 橙色 → 这是LLM引擎中的CPU执行时间
• 其他所有内容 → 这是API服务器时间

• execute_model 不会阻塞asyncio事件循环，因为它在run_in_executor中运行

vllm/vllm/executor/gpu_executor.py
第143行 in d92b3c5
| | output=awaitmake_async(self.driver_worker.execute_model |
因此，我们认为当前已经有一些GPU时间与API服务器重叠

建议的更改

通过将API服务器和AsyncLLMEngine通过多进程进行更好的重叠，通过gRPC与protobufs通信来实现。这大致是TGI(尽管TGI服务器中的项目比我们在这里提议的要多)使用的架构。

初始目标

• 编写protobuf API,使其与AsyncLLMEngine generate()方法大致匹配，将API服务器分成单独的进程并测量加速效果
• 将排除LogitsProcessors - 我们同意这些不属于SamplingParams。相反，我们将包括相应的外部API参数，例如用于引导解码的参数
• 可以是gRPC流响应，它很好地Map到此方法返回的流。取消可以Map到请求中止

后续行动

将当前在AsyncLLMEngine中运行的项目移动到API服务器中，以便更好地与GPU重叠

• 在引擎内部进行必要的更改，以允许完整的token-id/token-id输出，以便可以调用这样的输出，而无需进行令牌化/去令牌化操作 - 您已经可以传递令牌ID,但有些地方无条件地进行令牌化/去令牌化操作，例如对提示进行去令牌化以返回
• 将LogitsProcessor构造与OpenAI API代码分离 - 从顶级参数创建它们的层/实用程序。然后可以从gRPC API层调用它来构建完整的SamplingParams
• 分离增量去令牌化逻辑，以便也可以在API服务器进程中使用
• API服务器进程还可以拦截/处理任何停止字符串，并根据需要中止请求

反馈期

• 无响应*

CC列表。

@simon-mo@njhill@dsikka@joerunde

其他事项。

• 无响应*