动机
目前,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
其他事项。
- 无响应*
3条答案
按热度按时间quhf5bfb1#
在gRPC之外,ZMQ可能是一个已经用于vLLM内部的轻量级替代方案:
vllm/requirements-common.txt
第24行中的6a1e25b
| | pyzmq |
参考初始PR使用情况:#6183
bgtovc5b2#
在gRPC之外,ZMQ可能是一个已经用于vLLM内部的轻量级替代方案:
vllm/requirements-common.txt
第24行中的6a1e25b
| | pyzmq |
参考初始PR使用情况:#6183
+1,值得进行一些基准测试。python_grpc isn't that performant。
Triton Inference Server使用共享内存进行通信。
编辑:实际上,Triton Inference Server已经从grpc转移到了shm:triton-inference-server/python_backend#42
xtupzzrd3#
听起来不错。我们正在制作一个原型,并将测量
在原型中更换协议应该不会太困难,因为它非常简单