VLLM助力大模型推理实现多机多卡高效部署

network · 发表于 2025-2-27 21:43:57

VLLM助力大模型推理实现多机多卡高效部署

在人工智能领域，大型语言模型（LLM）的推理速度一直是制约其广泛应用的关键因素。随着模型规模的不断扩大，单台机器的计算资源往往无法满足高效推理的需求。因此，多机多卡分布式部署成为了一种有效的解决方案。本文将深入探讨如何利用VLLM（Vectorized Large Language Model Serving System）框架实现大模型推理的多机多卡分布式本地部署。

一、VLLM框架简介

VLLM是一个专为大规模语言模型设计的高性能推理框架，它支持多GPU和多节点部署，能够显著提高LLM的推理速度并降低显存占用。VLLM的核心优势在于其PagedAttention技术、连续批处理、CUDA核心优化以及分布式推理支持，这些特性使得VLLM在LLM推理领域脱颖而出。

二、环境配置

在实现多机多卡部署之前，我们需要先配置好相应的环境。这包括安装Python、Ray库、VLLM框架，以及确保系统上安装了适合的NVIDIA GPU驱动、CUDA Toolkit和cuDNN。这些组件是运行GPU加速的深度学习模型所必需的。

安装虚拟环境：推荐使用conda或virtualenv来创建虚拟环境，以确保依赖库的隔离和版本控制。
安装依赖库：在虚拟环境中，安装torch、transformers等必要的依赖库。这些库可以通过pip命令进行安装。
配置Ray集群：Ray是一个开源的分布式计算框架，它简化了并行和分布式Python编程。在进行多机部署时，需要设置Ray集群。这可以通过Ray的自动集群管理工具如ray.init()进行简单的单机启动，或者使用Kubernetes、Ray Cluster Launcher等工具来部署多节点集群。

三、VLLM部署步骤

下载VLLM源码：从GitHub等代码托管平台下载VLLM的源码，并解压到本地目录。
配置模型：根据实际需求，配置相应的LLM模型，包括模型路径、参数等。
构建Docker镜像：为了在多机环境中保持一致的运行环境，可以使用Docker来构建镜像。在Dockerfile中，需要指定基础镜像、安装必要的软件包、配置环境变量等。
启动VLLM服务：使用命令行工具启动VLLM服务，并指定监听端口等参数。在多机多卡环境下，需要确保每个节点都能正确加入Ray集群，并分配到相应的GPU资源。
发送推理请求：使用HTTP或gRPC等协议，向VLLM服务发送推理请求，并获取推理结果。

四、实际应用案例

假设我们有一个基于BERT的文本分类模型，需要对大量文本进行分类。使用传统的推理方法，可能需要花费较长时间。但是，通过VLLM的推理加速，我们可以显著提高推理速度，从而更快地完成分类任务。

在这个案例中，我们首先需要将BERT模型加载到VLLM中，并配置好相应的参数。然后，我们使用VLLM提供的API，将待分类的文本发送给VLLM服务。VLLM服务会利用PagedAttention技术、连续批处理等优化手段，对文本进行快速推理，并将结果返回给客户端。最终，我们可以根据返回的结果，对文本进行分类处理。

五、VLLM部署的优势

高效推理：通过多机多卡分布式部署，VLLM能够充分利用计算资源，提高推理速度。
降低显存占用：PagedAttention技术能够减少显存碎片，提高显存利用率。
易于扩展：VLLM支持分布式推理，使得模型能够轻松扩展到更多节点和GPU上。
简单易用：VLLM提供了简洁的API和文档，使得部署和集成变得更加容易。

六、产品关联

在VLLM的部署过程中，千帆大模型开发与服务平台可以作为一个重要的辅助工具。该平台提供了丰富的模型管理和部署功能，能够帮助用户更轻松地实现模型的部署和监控。同时，千帆大模型开发与服务平台还支持与VLLM等推理框架的集成，使得用户能够更加方便地利用这些框架来加速模型的推理过程。

综上所述，VLLM框架为大型语言模型的推理提供了高效、易用的解决方案。通过多机多卡分布式部署，我们能够充分利用计算资源，提高推理速度，并降低显存占用。在未来的发展中，随着模型规模的不断扩大和应用场景的不断拓展，VLLM框架将发挥更加重要的作用。同时，结合千帆大模型开发与服务平台等辅助工具，我们将能够构建更加高效、稳定的AI应用。

支持的模型 | vLLM 中文站 https://vllm.hyper.ai/docs/models/supported-models/

network · 发表于 2025-2-27 22:29:15

如何安全高效地部署大模型？四种工具的全面对比与实践指南

洞见繁华
2025-02-26 15:22
在如今科技迅速发展的时代，本地化大模型的部署已经成为了各种应用和研究的关键。而在这一过程中，众多工具应运而生。其中，Ollama、vLLM、LMStudio和Jan几种工具因其各自的优势和特点，备受用户关注。本文旨在深入分析这四款本地化大模型部署工具，帮助用户在选择和应用时，降低安全风险，确保系统的稳定性和安全性。

一、核心区别与优势 1. Ollama

Ollama作为一款新兴的本地化部署工具，主要以其用户友好的界面和灵活性著称。用户可以非常方便地通过命令行进行操作，同时支持多种模型的快速集成。Ollama 的优势在于其高效的资源管理，能够动态调配系统资源，确保在不同负载下仍能保持优异的运行效果。此外，Ollama具备较强的社区支持，用户可以很方便地获取帮助和查找各类插件。

2. vLLM

相较于Ollama，vLLM是一款强调整体性能的工具。它采用了先进的算法，能够在多线程环境下实现高并发处理，对于大规模数据的处理能力尤为出色。vLLM 的设计理念是为了解决大模型在本地部署过程中的性能瓶颈，从而实现卓越的响应速度和效率。在安全性方面，vLLM也进行了多重加密保护，确保用户数据的安全。

3. LMStudio

LMStudio 以其强大的可视化功能而受到用户喜爱。通过流畅的图形界面，用户可以更直观地进行模型训练和数据管理。这对于不具备深厚技术背景的用户而言，显得尤为友好。同时，LMStudio 还支持多种编程语言，能够与不同的开发环境兼容，为用户提供更多的选择空间。此外，其自动化测试功能可以帮助开发者及时发现问题，提升系统的稳定性。

4. Jan

最后，Jan 则是关注于大模型在本地部署的灵活性和扩展性。许多企业在本地化大模型部署的过程中，往往需要根据不断变化的需求进行调整，而Jan 的设计充分考虑到了这一点。其模块化的结构让用户可以根据业务需求进行针对性的功能扩展，同时，Jan也支持与云计算平台的无缝衔接，为企业提供了丰富的可能性。

二、选择部署工具的考虑因素

在选择合适的本地化大模型部署工具时，用户需要考虑多个因素，包括性能、安全性、易用性与扩展性。对于不同规模的企业和开发者，需求也会有所不同。

1. 性能

大模型的训练和推理需要大量的计算资源，因此工具的性能直接影响到工作效率。选择一款在高并发情况下表现出色的工具，能够显著提高业务处理的速度。

2. 安全性

保护用户数据安全是任何系统设计的首要任务。针对各个工具的安全实践进行仔细评估，选择具备多重安全机制的工具尤为重要。

3. 易用性

对于一些没有专业背景的用户，容易上手的工具显得尤为关键。可视化界面和友好的用户体验可以大大减少学习成本，提高工作效率。

4. 扩展性

在技术不断迭代的今天，业务需求也在持续变化，选择具备强大扩展性的工具可以有效应对未来的挑战。

三、实践指导与安全措施

在本地化部署大模型的过程中，安全措施至关重要。以下是一些最佳实践，与用户分享以降低安全风险：

1. 定期更新

保持部署工具的版本更新，以确保获得最新的安全补丁与功能。

2. 数据加密

对重要数据进行加密存储，确保在数据传输过程中不被外部窃取。

3. 控制访问

对工具的使用权限进行严格控制，只允许必要的人员进行操作，避免潜在的内部风险。

4. 备份机制

定期进行数据备份，确保在故障或攻击发生时可迅速恢复，从而降低损失。

四、结论

选择适合的本地化大模型部署工具，是实现安全、高效数据处理的基础。在Ollama、vLLM、LMStudio和Jan这四种工具中，各具特色，用户需要根据自身的需求作出选择。同时，通过合理的安全实践，能够有效降低风险，保护系统的稳定运行。在快速发展的人工智能领域，掌握这些工具的使用和安全措施，必将为用户的工作带来极大的便利与帮助。

network · 发表于 2025-2-27 22:30:28

VLLM 与 Ollama：如何选择合适的轻量级 LLM 框架？
AI论文解读发布于 2025-2-6 14:273721浏览0收藏
VLLM是一款经过优化的推理引擎，在令牌生成速度和内存管理效率上表现出色，是大规模AI应用的理想之选。Ollama则是一个轻量级、易上手的框架，让在本地电脑上运行开源大语言模型变得更加简单。

那么，这两个框架该选哪一个呢？接下来，我们会从性能、易用性、适用场景、替代方案，以及详细的安装步骤等方面进行全面对比，帮助你做出更合适的选择。

一、VLLM和Ollama是什么？基础知识解析
在深入探讨之前，我们先来了解一下这两个框架的核心功能。

什么是VLLM？
VLLM（超大型语言模型）是SKYPILOT开发的推理优化框架，主要用于提升大语言模型在GPU上的运行效率。它的优势体现在以下几个方面：

快速令牌生成：采用连续批处理技术，让令牌生成速度大幅提升。
高效内存利用：借助PagedAttention技术，在处理大上下文窗口时，能有效控制GPU内存消耗。
无缝集成：与PyTorch、TensorFlow等主流深度学习平台兼容，可轻松融入AI工作流程。
VLLM 与 Ollama：如何选择合适的轻量级 LLM 框架？-AI.x社区

VLLM深受AI研究人员和需要大规模高性能推理的企业青睐。

什么是奥拉玛（Ollama）？
Ollama是一个本地大语言模型运行时环境，能简化开源AI模型的部署和使用流程。它具备以下特点：

预打包模型丰富：内置了LLaMA、Mistral、Falcon等多种模型。
硬件适配性强：针对日常使用的硬件进行了CPU和GPU推理优化，无论是MacBook、PC还是边缘设备，都能流畅运行AI模型。
操作便捷：提供简洁的API和命令行界面（CLI），开发人员只需简单配置，就能快速启动大语言模型。
对于想在个人电脑上尝试AI模型的开发人员和AI爱好者来说，Ollama是个不错的选择。

二、性能大比拼：速度、内存与可扩展性
性能是衡量推理框架优劣的关键指标，下面我们从速度、内存效率和可扩展性三个方面，对VLLM和Ollama进行对比。

VLLM 与 Ollama：如何选择合适的轻量级 LLM 框架？-AI.x社区

关键性能指标分析
VLLM借助PagedAttention技术，在推理速度上优势明显，处理大上下文窗口时也能游刃有余。这让它成为聊天机器人、搜索引擎、AI写作辅助工具等高性能AI应用的首选。

Ollama的速度也还不错，但受限于本地硬件配置。在MacBook、PC和边缘设备上运行小型模型时表现良好，不过遇到超大模型就有些力不从心了。

结论：Ollama更适合初学者，而需要深度定制的开发人员则可以选择VLLM。

三、应用场景：VLLM和Ollama分别适用于哪些场景？
VLLM的最佳应用场景
企业AI应用：如客户服务聊天机器人、AI驱动的搜索引擎等。
云端高端GPU部署：适用于A100、H100、RTX 4090等高端GPU的云端大语言模型部署。
模型微调与定制：方便进行模型微调和运行自定义模型。
大上下文窗口需求：适用于对上下文窗口要求较高的应用。
不太适用的场景：个人笔记本电脑、日常AI实验。

Ollama的最佳应用场景
本地设备运行：无需借助云资源，就能在Mac、Windows或Linux系统的设备上运行大语言模型。
本地模型试验：不需要复杂的设置，就能在本地轻松试验各种模型。
简易API集成：开发人员可以通过简单的API将AI功能集成到应用程序中。
边缘计算应用：在边缘计算场景中表现出色。
不太适用的场景：大规模AI部署、高强度GPU计算任务。

总结：VLLM更适合AI工程师，而Ollama则是开发人员和AI爱好者的好帮手。

四、如何上手使用？（分步指南）
VLLM入门教程
安装依赖项：在命令行中输入pip install vllm，按提示完成安装。
在LLaMA模型上运行推理：在Python环境中，输入以下代码：
from vllm import LLM
llm = LLM(model="meta-llama/Llama-2-7b")
output = llm.generate("What is VLLM?")
1.
2.
3.
上述代码中，首先从vllm库中导入LLM类，然后创建LLM对象，并指定使用meta-llama/Llama-2-7b模型。最后，使用generate方法输入问题“What is VLLM?”，就能得到模型的输出结果。

Ollama入门教程
安装Ollama（Mac/Linux系统）：在终端中输入brew install ollama，等待安装完成。
下载并运行模型：在终端输入ollama run mistral，即可下载并运行Mistral模型。
调用Ollama的API：在Python环境中，使用以下代码调用API：
import requests
response = requests.post("http://localhost:11434/api/generate", jsnotallow={"model": "mistral", "prompt": "Tell me a joke"})
print(response.json())
1.
2.
3.
上述代码中，首先导入requests库，然后使用requests.post方法向本地的Ollama API发送请求，请求地址为http://localhost:11434/api/generate，并在请求中指定使用的模型为mistral，输入的提示内容为“Tell me a joke”。最后，打印API返回的结果。

总结：Ollama安装更简单，而VLLM的定制性更强。

本文转载自柏企科技圈，作者：柏企

network · 发表于 2025-2-28 06:05:17

尝试基于vLLM+Ray多机部署满血DeepSeek-R1
JJJJerry
JJJJerry
山东大学计算机科学技术硕士在读
关注他
15 人赞同了该文章
参考教程：

https://mp.weixin.qq.com/s/kUwgNtDN16qm82h8FWu31g

https://docs.vllm.ai/en/latest/serving/distributed_serving.html

在部署如满血DeepSeek-R1 671B这种很大的模型时，单机的显存往往是不够的。即使是8*80G的显卡也不够（除非是8卡H20）。所以需要用到多机部署，把显存聚集起来。

尝试多机部署Qwen2.5-72B-Instruct
为了验证我们的服务器多机部署是否可行，我们先尝试多机部署一下Qwen2.5-72B-Instruct。这个模型用vllm部署差不多只需要150G显存左右。

环境准备
我这里的环境是两台8*A800（cuda 12.2）的服务器，两台服务器网络互通，文件系统共享。

我准备每台机器4卡，共8卡来部署Qwen2.5-72B-Instruct。

1.两台机器拉取vllm最新docker镜像
我这时最新的vllm是v0.7.2

docker pull vllm/vllm-openai
# docker pull docker.1ms.run/vllm/vllm-openai # 若因网络问题拉取失败可尝试这个
2.编写run_cluster.sh
#!/bin/bash

if [ $# -lt 2 ]; then
echo "Usage: $0 head_node_address --head|--worker [additional_args...]"
exit 1
fi

HEAD_NODE_ADDRESS="$1"
NODE_TYPE="$2"
shift 2

ADDITIONAL_ARGS=("$@")

if [ "${NODE_TYPE}" != "--head" ] && [ "${NODE_TYPE}" != "--worker" ]; then
echo "Error: Node type must be --head or --worker"
exit 1
fi

cleanup() {
if [ -e /var/lib/docker/containers/vllm ]; then
      docker stop vllm
      docker rm vllm
fi
}
trap cleanup EXIT

RAY_START_CMD="ray start --block"
if [ "${NODE_TYPE}" == "--head" ]; then
RAY_START_CMD+=" --head --port=6379"
else
RAY_START_CMD+=" --address=${HEAD_NODE_ADDRESS}:6379"
fi
# 执行docker命令
docker run -itd \
--privileged \
--entrypoint /bin/bash \
--network host \
--name vllm \
--shm-size 10000000g \
--gpus all \
-v /xxx/Qwen2.5-72B-Instruct/:/mnt \
"${ADDITIONAL_ARGS[@]}" \
-e CUDA_VISIBLE_DEVICES=1,2,4,5 \
docker.1ms.run/vllm/vllm-openai:latest \
-c "${RAY_START_CMD}"

我看参考教程中说，需要根据网络接口来修改容器里的环境变量NCCL_SOCKET_IFNAME、GLOO_SOCKET_IFNAME 和 TP_SOCKET_IFNAME。

我通过ip link show指令查询服务器网络连接情况，发现里面没有eth0或是ibp25s0这种网络接口（我对这个不懂），就没有设置NCCL_SOCKET_IFNAME、GLOO_SOCKET_IFNAME 和 TP_SOCKET_IFNAME这些环境变量。

关键参数解释：

-v /xxx/Qwen2.5-72B-Instruct/:/mnt # 将Qwen2.5-72B-Instruct挂载到/mnt目录
-e CUDA_VISIBLE_DEVICES=1,2,4,5 # 指定显卡
3.容器启动
随便选一台机器作为head结点，另一台作为worker节点。

这里我选择gpu10作为head节点，gpu11作为worker节点。我针对显卡情况对run_cluster.sh更改了一下docker run里的-e CUDA_VISIBLE_DEVICES。

head结点容器启动

bash run_cluster_gpu10.sh 10.102.34.62 --head

worker结点容器启动

bash run_cluster_gpu11.sh 10.102.34.62 --worker

检查是否连接上了ray集群

docker exec -it vllm /bin/bash # 随便在哪个节点上进入vllm容器

## 进入容器后
ray status # 查看ray集群情况

发现有两个节点，说明没问题。

4.进入容器启动vllm服务
# 在随便一个节点的vllm容器内
vllm serve /mnt --tensor-parallel-size 8 --trust-remote-code --gpu-memory-utilization 0.8 --max-model-len 30720 --enforce-eager --served-model-name qwen72B

vllm常用启动参数解释

vllm serve是启动命令
--tensor-parallel-size 8 # 和卡的数量对应
--trust-remote-code # 是否信任huggingface上的代码
--gpu-memory-utilization 0.8 # 设置每张卡显存占用率
--max-model-len 30720 # 模型上下文长度（包含prompt+response）
--enforce-eager # 禁用CUDA图，节约显存。
--served-model-name # 指定openai格式API中需要填写的model字段
发现模型在加载了，说明没有问题。

下面这样就说明部署好了

注：API服务地址为启动Vllm服务的那个容器所在机器的地址。

5.性能测试
多机部署的话肯定比单机同显卡配置要慢一些，为此我用EvalScope对API服务进行一下压力测试。

下图来自qwen官方性能测试结果https://qwen.readthedocs.io/zh-c ... peed_benchmark.html

我这里对单并发和5并发分别做了测试：

单并发

5并发

总体来看结果和qwen测的差不多（我这里是多机8卡A800，qwen官方测试是4卡A100），我的配置明显好一些，但性能却相近，说明多机通讯还是对速度有一定影响。

尝试多机部署满血DeepSeek-R1
基本操作和上面多机部署Qwen2.5-72B-Instruct一样，只不过需要用到16张卡。

注：必须用能被128整除的数量的卡。

改一下run_cluster.sh，更改挂载路径为deepseek-r1的，同时更改-e CUDA_VISIBLE_DEVICES为全部8卡。

#!/bin/bash

if [ $# -lt 2 ]; then
echo "Usage: $0 head_node_address --head|--worker [additional_args...]"
exit 1
fi

HEAD_NODE_ADDRESS="$1"
NODE_TYPE="$2"
shift 2

ADDITIONAL_ARGS=("$@")

if [ "${NODE_TYPE}" != "--head" ] && [ "${NODE_TYPE}" != "--worker" ]; then
echo "Error: Node type must be --head or --worker"
exit 1
fi

cleanup() {
if [ -e /var/lib/docker/containers/vllm ]; then
      docker stop vllm
      docker rm vllm
fi
}
trap cleanup EXIT

RAY_START_CMD="ray start --block"
if [ "${NODE_TYPE}" == "--head" ]; then
RAY_START_CMD+=" --head --port=6379"
else
RAY_START_CMD+=" --address=${HEAD_NODE_ADDRESS}:6379"
fi
# 执行docker命令
docker run -itd \
--privileged \
--entrypoint /bin/bash \
--network host \
--name vllm \
--shm-size 10000000g \
--gpus all \
-v /xxx/DeepSeek-R1/:/mnt \
"${ADDITIONAL_ARGS[@]}" \
-e CUDA_VISIBLE_DEVICES=0,1,2,3,4,5,6,7 \
docker.1ms.run/vllm/vllm-openai:latest \
-c "${RAY_START_CMD}"
机器1：

bash run_cluster.sh 10.102.34.62 --head

机器2：

bash run_cluster.sh 10.102.34.62 --worker

docker exec -it vllm /bin/bash
# 进入容器内

# 启动vllm服务
vllm serve /mnt --tensor-parallel-size 16 --trust-remote-code --gpu-memory-utilization 0.9 --max-model-len 103520 --enforce-eager --enable-reasoning --reasoning-parser deepseek_r1 --served-model-name deepseek-r1

启动vllm服务指令中，几个参数的解释：

--enable-reasoning # 输出思考内容
--reasoning-parser deepseek_r1 # 思考的格式

模型开始加载了，预计3个小时加载完。

加载速度应该和磁盘有关，我们服务器磁盘是比较老的机械盘，加载速度很慢。

模型权重在一张卡上占42.5G，16张卡就是42.5*16就是680G,说明模型权重加载需要680G显存。

最后报错了，原因是A100、A800系列显卡不支持FP8。而如果把模型权重转成fp16的话需要双倍的显存，则需要24张A800 80G，共三台机器，资源需要的太多了，而且看网上说输出速度也才3token/s，就没有往后试了。

单机部署DeepSeek-R1-AWQ
满血的部署不起来，可以试试单机部署量化后的。

模型网址：https://huggingface.co/cognitivecomputations/DeepSeek-R1-AWQ

使用vLLM镜像部署：

docker exec -it vllm /bin/bash
# 进入容器
VLLM_WORKER_MULTIPROC_METHOD=spawn vllm serve /mnt --host 0.0.0.0 --port 12345 --max-model-len 16384 --max-num-batched-tokens 16384 --trust-remote-code --tensor-parallel-size 8 --gpu-memory-utilization 0.97 --dtype float16 --enable-reasoning --reasoning-parser deepseek_r1 --served-model-name deepseek-reasoner  --enforce-eager

加载模型时遇到奇怪的一点，说不支持MLA。

但是https://huggingface.co/cognitivecomputations/DeepSeek-R1-AWQ说的是已经支持MLA的AWQ量化了，目前不知道是vllm镜像没更新到最新版本的问题，还是我启动参数没设置对。

不过最后还是部署成功了，虽然速度有点慢。

API测试：

import requests
import json
if __name__ == "__main__":
api_url = "http://xxx/v1/chat/completions"
data = {
      "model": "deepseek-reasoner",
      "messages": [
         {
            "role": "user", "content": "'street'里有几个e？"
         },
      ],
      "tools": [],
      "temperature": 0.6,
      "top_p": 0.5,
      "n": 1,
      "max_tokens": 4096,
      "stream": False,
}
response = requests.post(url=api_url, data=json.dumps(data))
print('response.status_code: ',response.status_code)
print(response.json())
目测生成速度为5token/s，和网上说的差距很大，有可能是因为没支持MLA的AWQ量化的原因。

回复：

{
"id": "chatcmpl-fc94c4a0bba34fe1b2cc0984998325f2",
"object": "chat.completion",
"created": 1739975275,
"model": "deepseek-reasoner",
"choices": [
      {
         "index": 0,
         "message": {
            "role": "assistant",
            "reasoning_content": "\n嗯，用户问的是“'street'里有几个e？”。首先，我需要确认单词的正确拼写。让我先写下这个词：s-t-r-e-e-t。然后逐个字母检查。第一个字母是s，接着是t，然后是r，接下来是第四个字母e，第五个字母e，最后是t。所以中间的字母是e、e，也就是有两个e。\n\n不过，可能用户会混淆字母的位置，或者有没有重复的字母。比如，有时候可能有人会误以为中间的e只出现一次，或者可能数错位置。比如，拼写是否正确？比如，street的正确拼写确实是s-t-r-e-e-t，对吗？是的，没错。所以第四和第五个字母都是e，所以总共有两个e。\n\n再仔细检查一遍：s（1），t（2），r（3），e（4），e（5），t（6）。没错，第4和第5位都是e，所以两个e。有没有可能用户输入的是其他变体？比如大小写或者其他符号？不过问题里是纯小写的，所以应该没问题。\n\n有没有可能用户其实想问的是发音中的e音，比如音标中的/e/，但问题明确是问字母e的数量，所以应该直接数字母。所以答案应该是两个e。\n",
            "content": '\n\n单词 "street" 中有 **2 个字母 e**。\n\n具体拆分：  \ns - t - r - **e** - **e** - t  \n（第4、5个字母均为 e）',
            "tool_calls": [],
         },
         "logprobs": None,
         "finish_reason": "stop",
         "stop_reason": None,
      }
],
"usage": {
      "prompt_tokens": 10,
      "total_tokens": 324,
      "completion_tokens": 314,
      "prompt_tokens_details": None,
},
"prompt_logprobs": None,
}
编辑于 2025-02-20 13:37・IP 属地山东

network · 发表于 2025-2-28 06:06:18

docker部署ray集群-多机单卡启动vllm-qwen2
JasonZhu
JasonZhu
AIGC工程化
关注
13 人赞同了该文章

目录
收起
运行环境：
安装：
部署集群：
遇到的问题：
docker 的 ray 集群中部署 vllm，两个机器使用的是不同型号显卡

运行环境：
硬件：

head node: A800 * 1

worker node: Quadro RTX 6000 * 1

软件环境

vllm==0.5.5

ray==2.21.0

安装：
vllm 环境：vllm 环境的安装可以参考 vllm 官网，镜像是自己封装的，可以使用官网的 vllm 对应的镜像

模型文件：可以提前封装在镜像里，也可以通过挂载的方式实现，我这里是直接封装的镜像内部，所以没有挂载，也可以进行挂载。

部署集群：
在两台机器上分别启动两个容器，一个容器为 head 节点，一个为 worker 节点

1）ray集群启动脚本如下：

head 和 worker 节点都需要执行：根据自己的需要修改相关的参数，-e 参数参考问题答疑部分-显卡通信问题

# head + worker
docker run -it \
--privileged \
--entrypoint /bin/bash \
--network host \
--name ray_header5.6 \
--shm-size 10.24g \
--gpus all \
-e NCCL_SOCKET_IFNAME=^lo,eno2,eth1,eth2,eth3,docker0,flannel.1,cni0,veth,br- \
-e NCCL_DEBUG=TRACE \
-v "/data/home/llm_models/gpu/qwen:/home/Models" \
vllm-0.5.5-ray-release:v13

# 如果需要挂载，挂载到容器内的/home/Models目录下
-v "/home/zhuzs/projects/gitlab/vllm_server/Models:/home/Models"
分别进入两个节点的容器内，手动执行，根据自己的 ip 地址进行修改，将 node1 换为对应的节点的 ip，如：127.0.0.1

# head节点
ray start --head --port=6379  --dashboard-host='0.0.0.0'

# worker节点
ray start --address='node1:6379'
dashboard 是 ray 查看集群状态的接口，设置为 0.0.0.0，可以通过主机:端口访问，默认端口是 8265，ray 命令相关的参数，可以通过 ray --help查看

2）集群正常启动日志如下：

# head 节点
root@:/home# ray start --head --port=6379  --dashboard-host='0.0.0.0'
Usage stats collection is enabled. To disable this, add `--disable-usage-stats` to the command that starts the cluster, or run the following command: `ray disable-usage-stats` before starting the cluster. See https://docs.ray.io/en/master/cluster/usage-stats.html for more details.

--------------------
Ray runtime started.
--------------------

Next steps
  To add another node to this Ray cluster, run
ray start --address='nodeip:6379'

  To connect to this Ray cluster:
import ray
ray.init()

  To submit a Ray job using the Ray Jobs CLI:
RAY_ADDRESS='http://nodeip:8265' ray job submit --working-dir . -- python my_script.py

  See https://docs.ray.io/en/latest/cl ... bmission/index.html
  for more information on submitting Ray jobs to the Ray cluster.

  To terminate the Ray runtime, run
ray stop

  To view the status of the cluster, use
ray status

  To monitor and debug Ray, view the dashboard at
nodeip:8265

  If connection to the dashboard fails, check your firewall settings and network configuration.

# worker节点
root@:/home# ray start --address='headnodeip:6379'
Local node IP: worknodeip
[2024-09-23 10:35:14,900 W 7358 7358] global_state_accessor.cc:459: Retrying to get node with node ID b9e82c8a305dbf307bc4a0915dd0c5b27add6f9df6747305c652b45d

--------------------
Ray runtime started.
--------------------

To terminate the Ray runtime, run
  ray stop
3）集群状态查看，在任意节点的容器内上执行 ray status，可以看到集群中的状态

root@gpu6959:/home# ray status
======== Autoscaler status: 2024-09-23 10:35:48.208468 ========
Node status
---------------------------------------------------------------
Active:
1 node_7ef076c140177f676448e42588af50b528a13b7de328ccac1a30c151
1 node_b9e82c8a305dbf307bc4a0915dd0c5b27add6f9df6747305c652b45d
Pending:
(no pending nodes)
Recent failures:
(no failures)

Resources
---------------------------------------------------------------
Usage:
0.0/88.0 CPU
0.0/2.0 GPU
0B/724.51GiB memory
0B/19.46GiB object_store_memory

Demands:
(no resource demands)
可视化界面：web上输入headip:8265

ray集群的deashboard界面

4）启动模型：使用 vllm serve 启动

模型文件可以提前封装在镜像里，也可以通过挂载的方式实现，我这里

vllm serve /home/Qwen2-7B-Instruct-GPTQ-Int4 \
--tensor-parallel-size 2 \
--gpu-memory-utilization 0.4 \
--quantization gptq \
--max-model-len 128 \
--max-num-seqs 1 \
--served_model_name qwen-base \
--trust-remote-code \
--port 8009
启动成功结果

启动模型成功日志
curl请求测试可用，使用 openai 的接口模式， mode是启动时配置的model_name

curl http://10.1.68.67:8009/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
"model": "qwen-base",
"messages": [
   {
      "role": "user",
      "content": "Hello!"
   }
]
请求结果

{"id":"chat-4d6cfe70695b464081ab55548d3e7860","object":"chat.completion","created":1724922331,"model":"qwen-base","choices":[{"index":0,"message":{"role":"assistant","content":"Hello there! How can I assist you today?","tool_calls":[]},"logprobs":null,"finish_reason":"stop","stop_reason":null}],"usage":{"prompt_tokens":20,"total_tokens":31,"completion_tokens":11}}
遇到的问题：
1）同一台机器启动两个容器

每个容器一张卡，不允许这样执行，容器能启动，分布式状态正确，但是无法启动模型，其实也正常，同一台机器直接使用 vllm 单独启动即可，不用集群

查看了NCCL的详细日志说是不能这样执行

使用环境变量追踪日志，可以定位详细的错误问题，当出现WARN时可能会有问题，也可以在容器启动时配置环境变量：

# 容器启动时配置
-e NCCL_DEBUG=TRACE

# 手动配置
export NCCL_DEBUG=TRACE
2）网络通信问题

通过 ray status 查看集群状态正常，打开nccl日志追踪

https://www.w3xue.com/exp/article/20244/89111.html

查找相关的文档说是要过滤掉虚拟网卡的ip

解决方案：

正确的应该是用^后面过滤掉所有不用的，两台机器的都写在里面，比如我想用 eth0，也就是节点上的物理网卡名字是这个，

两边都需要配置环境变量，在启动docker时添加环境变量

# docker启动
-e NCCL_SOCKET_IFNAME=^lo,eno2,eth1,eth2,eth3,docker0,flannel.1,cni0,veth,br-

# 手动
export NCCL_SOCKET_IFNAME=^lo,eno2,eth1,eth2,eth3,docker0,flannel.1,cni0,veth,br-
比如在 node 上执行 ifconfig，会显示很多网卡，下面截取了一部分

docker0 Link encap:Ethernet  HWaddr
      inet addr:  Bcast:  Mask:
      inet6 addr:

eth0    Link encap:Ethernet  HWaddr
      inet addr:  Bcast:  Mask:
      inet6 addr:
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:1984235723 errors:0 dropped:2320 overruns:31638 frame:0

eth1    Link encap:Ethernet  HWaddr
      UP BROADCAST MULTICAST  MTU:1500  Metric:1
      RX packets:0 errors:0 dropped:0 overruns:0 frame:0
      TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
比如想用 eth0，节点的物理网卡，就把其他网卡全部屏蔽掉，只留下需要的export NCCL_SOCKET_IFNAME=^lo,eth1,docker0

由于我的服务器上 tmp 不一定够，可能会出现tmp不足的问题，会影响性能，但不影响运行

但只要显存够，能正常启动

3）vllm serve 启动时卡柱，一直在加载，未出现 Uvicorn running 字样

tensor-parallel-size=2 改成 pipeline-parallel-size=2，能正常启动，可能是由于我这里使用的是两张不同的显卡，会导致卡主

参考目录：

vllm 分布式：Distributed Inference and Serving — vLLM

vllm 启动 openai 的接口：OpenAI Compatible Server — vLLM

分布式网卡通信问题：deepspeed 训练多机多卡报错 ncclSystemError Last error - 技术经验 - W3xue

发布于 2024-09-23 11:

network · 发表于 2025-2-28 06:07:05

Ray+vLLM+LLaMA-Factory多机部署大模型
JJJJerry
JJJJerry
山东大学计算机科学技术硕士在读
关注他
3 人赞同了该文章
当我们使用vllm多机部署大模型时，可以使用vLLM提供的API服务。

但由于使用的是vLLM的代码，想往API里加入一些自己自定义的一些功能（比如自定义的鉴权方式、api参数的缺省值设置）比较困难，能否把vLLM的多机推理剥离出来？

比如LLaMA-Factory里也集成了vllm，而且代码易于自己更改，如果能用LLaMA-Factory+Ray+vLLM部署模型就很好了。

原理说明
我们已知vllm中，使用类似于下面的命令是可以多机部署大模型的（前提是已经连上了ray集群）。

python -m vllm.entrypoints.openai.api_server --host 0.0.0.0 --port 8080 --max-model-len 32768 --trust-remote-code --tensor-parallel-size 16 --gpu-memory-utilization 0.9 --dtype float16 --model Qwen/Qwen2.5-72B-Instruct

从https://github.com/vllm-project/ ... penai/api_server.py可以看出，vLLM官方的服务用到的加载模型方式是AsyncLLMEngine，说明这个加载方式是可以支持多机部署的。

我尝试了一下，把两台机器都先连接到一个ray集群上，然后在一台机器上加载一个AsyncLLMEngine，看看能不能用到两台机器的卡。

测试
先将两台机器连接到同一ray集群下，需要文件系统共享，网络互通，vllm版本最好一致。

先编写启动ray的脚本命令。

start_ray.sh

HEAD_NODE_ADDRESS="$1"
NODE_TYPE="$2"

RAY_START_CMD="ray start --block"
if [ "${NODE_TYPE}" == "--head" ]; then
RAY_START_CMD+=" --head --port=6379"
else
RAY_START_CMD+=" --address=${HEAD_NODE_ADDRESS}:6379"
fi

# 执行命令
eval "$RAY_START_CMD
head节点（假如IP是10.102.33.3，指定两张卡）：

CUDA_VISIBLE_DEVICES=1,2 bash start_ray.sh 10.102.33.3 --head
worker节点（指定两张卡）：

CUDA_VISIBLE_DEVICES=3,4 bash start_ray.sh 10.102.33.3 --worker

随便在哪个节点上，查看集群连接情况：

ray status

连接上集群后，便可以开始测试。

测试代码如下：

from vllm import AsyncEngineArgs, AsyncLLMEngine, SamplingParams
from transformers import AutoTokenizer
import uuid
import asyncio
async def main():
engine_args = {
      "model": "/xxx/Qwen/Qwen2.5-32B-Instruct",
      "trust_remote_code": True,
      "max_model_len": 4096,
      "tensor_parallel_size": 4,
      "gpu_memory_utilization": 0.8,
      "enforce_eager": True,
}
model = AsyncLLMEngine.from_engine_args(AsyncEngineArgs(**engine_args))
tokenizer = AutoTokenizer.from_pretrained("/xxx/Qwen/Qwen2.5-32B-Instruct")
sampling_params = SamplingParams()
request_id = f"chatcmpl-{uuid.uuid4().hex}"
conversation=[[
      {
         "role": "user", "content": "你好"
      },
]]
prompt_ids=tokenizer.apply_chat_template(conversation=conversation,add_generation_prompt=True)[0]
# print(prompt_ids)
# print(tokenizer.batch_decode(prompt_ids))
generator = model.generate(
      {"prompt_token_ids": prompt_ids},
      sampling_params=sampling_params,
      request_id=request_id)
async for request_output in generator:
      final_output = request_output
for output in final_output.outputs:
      print(output)
if __name__ == '__main__':
asyncio.run(main())

看到如下显示就说明vllm连上ray了。

而https://github.com/hiyouga/LLaMA ... chat/vllm_engine.py中，也是用的AsyncLLMEngine来加载vLLM的，所以应该也可以多机部署服务。

使用Ray+vLLM+LLaMA-Factory多机部署
大致和前面测试基本上一样，步骤如下：

1.先将两台机器连接上Ray集群
同上。

2.用llamafactory启动API服务。
需要对https://github.com/hiyouga/LLaMA ... chat/vllm_engine.py里AsyncLLMEngine的初始化参数做一下更改。

原来是这样：

engine_args = {
         "model": model_args.model_name_or_path,
         "trust_remote_code": model_args.trust_remote_code,
         "download_dir": model_args.cache_dir,
         "dtype": model_args.infer_dtype,
         "max_model_len": model_args.vllm_maxlen,
         "tensor_parallel_size": get_device_count() or 1,
         "gpu_memory_utilization": model_args.vllm_gpu_util,
         "disable_log_stats": True,
         "disable_log_requests": True,
         "enforce_eager": model_args.vllm_enforce_eager,
         "enable_lora": model_args.adapter_name_or_path is not None,
         "max_lora_rank": model_args.vllm_max_lora_rank,
      }
需要把tensor_parallel_size手动改为多机总共使用的卡数。

engine_args = {
         "model": model_args.model_name_or_path,
         "trust_remote_code": model_args.trust_remote_code,
         "download_dir": model_args.cache_dir,
         "dtype": model_args.infer_dtype,
         "max_model_len": model_args.vllm_maxlen,
         "tensor_parallel_size": 4,
         "gpu_memory_utilization": model_args.vllm_gpu_util,
         "disable_log_stats": True,
         "disable_log_requests": True,
         "enforce_eager": model_args.vllm_enforce_eager,
         "enable_lora": model_args.adapter_name_or_path is not None,
         "max_lora_rank": model_args.vllm_max_lora_rank,
      }

启动服务：

VLLM_WORKER_MULTIPROC_METHOD=spawn CUDA_VISIBLE_DEVICES=0,1 DISABLE_VERSION_CHECK=1 python src/api.py --model_name_or_path /xxx/Qwen2.5-32B-Instruct/ --template qwen --infer_backend vllm --vllm_enforce_eager True --vllm_gpu_util 0.9 --vllm_maxlen 16384 --max_new_tokens 16384
发布于 2025-02-22 19:49・IP 属地山东

network · 发表于 2025-2-28 06:07:31

在此前的大模型技术实践中，我们介绍了加速并行框架Accelerate、DeepSpeed及Megatron-LM。得益于这些框架的助力，大模型的分布式训练得以化繁为简。

然而，企业又该如何将训练完成的模型实际应用部署，持续优化服务吞吐性能？我们不仅要考量模型底层的推理效率，还需从请求处理的调度策略上着手，确保每一环节都能发挥出最佳效能。

本期内容，优刻得将为大家带来vLLM[1]，一款高性能推理服务框架的相关内容。vLLM于近期推出了0.6.0版本[2]。那么，相比旧版本推出了什么新功能，又做了哪些优化呢？

优刻得模型服务平台UModelVerse现已同步上线vLLM0.6.0。仅需几步，即刻畅享新版vLLM带来的极速推理体验。文末为您带来详细的使用教程。

01

API服务端-推理引擎进程分离

推理服务框架需要考虑服务部署的两个要素：面向客户请求的服务端，以及背后的模型推理端。在vLLM中，分别由API服务端 (API Server)和模型推理引擎 (vLLM Engine)执行相应任务。1.1 进程共用 vs. 进程分离根据旧版vLLM设计，负责处理请求的API服务端与负责模型推理的推理引擎，共用同一个python进程；0.6.0版本将API服务端和推理引擎分离，分别由两个python进程运行。进程之间的信息交互由ZeroMQ socket进行传输 [3]。

上：API服务端与推理引擎共用同一个python进程；

下：API服务端与推理引擎各自独用python进程。

API服务端需要承担一系列处理HTTP请求等任务。通过对旧版本的性能分析，vLLM团队发现API服务端消耗大量CPU资源。举个例子，在推理引擎端，轻负载下使用Llama3 8B模型推理生成1个token的耗时约为13ms；而相对应地，API服务端需要能够每秒处理76个token才能跟上推理引擎的速度。由于python GIL的存在，推理引擎还会与服务端争抢CPU资源。CPU端负载巨大无法及时处理计算，则会使得GPU端因等待CPU而产生空闲，无法充分利用性能[3]。

在0.6.0版本中，将API服务端与推理引擎端分离为两个进程后，两个进程可以各自专注于份内职责，而不会受GIL的影响。而在分离后，团队后续可以更好地对两端分别进行更细致的性能优化和打磨。

1.2 TTFT、TPOT和ITL

在进入测试对比前，先了解一下衡量语言模型服务推理效率通常参照的三个指标，即：

首个token响应时长 (Time to first token, TTFT）

每个token输出时长 (Time per output token, TPOT)

跨token延迟 (Inter-token latency, ITL)

TTFT顾名思义，就是从客户端发出请求后开始计时，直到服务端返回第一个输出token的耗时。过程中，由服务端收到请求后着手处理，交由调度器准备推理。推理引擎需要完成prefill任务。基于prefill得到的kv值，decode得到第一个输出token后返回。

而TPOT和ITL概念相对接近，表达的都是后续一连串decode的耗时。根据vLLM测试代码 [4]，我们定义如下：TPOT是在一个请求从发出后，不纳入TTFT的耗时 (主要是为了排除prefill耗时)，到所有token全部decode完成并返回的整体耗时除以一共返回的token数量，即每个token输出的平均时长；而ITL是在计算每次请求返回部分token时所需的时长，即服务端每次decode后返回一个或一批token所需的时长。

举个例子，如果每次服务端返回1个token，则ITL耗时应与TPOT接近；而当每次服务端返回5个token，则ITL耗时应接近于5倍的TPOT耗时 (因为ITL计算单次的时长，而TPOT计算单token的时长)。

1.3 测试&对比

在优刻得云主机上开展对比测试。利用vLLM官方提供的benchmark_serving基准测试，我们可以模拟真实的客户端请求，从而对比vLLM 0.6.0与旧版vLLM (0.5.5)在进程分离上的优化导致的性能差异。关闭其他优化方法后，在保持其他参数不变的情况下，在opt-125m模型上开展测试。在服务端，我们分别在0.6.0和旧版本上使用以下的参数：

#vLLM 0.5.5（共用进程）
vllm serve facebook/opt-125m \
--max-model-len 2048 \
--use-v2-block-manager

#vLLM 0.6.0（分离进程）
vllm serve facebook/opt-125m \
--max-model-len 2048 \
--use-v2-block-manager \
--disable-async-output-proc #关闭0.6.0的新优化方法：异步输出处理。下文有详解～

而在客户端，我们统一采用以下脚本。我们模拟100个请求同时发出，请求数据随机取自ShareGPT v3数据集。

python vllm/benchmarks/benchmark_serving.py \
--backend vllm \
--model facebook/opt-125m \
--tokenizer facebook/opt-125m \
--request-rate inf \ #所有请求无间隔同时发送
--num-prompts 100 \ #共100条请求发出
--dataset-name sharegpt \
--dataset-path dataset/ShareGPT_V3_unfiltered_cleaned_split.json \
--sharegpt-output-len 1024 \
--seed 42 #固定种子控制变量

经过测试，结果如下 (左旧版本0.5.5；右新版本0.6.0)：

进程分离以牺牲TTFT指标为代价 (笔者推测进程间ZeroMQ通信带来开销)，测试整体时长(Benchmark duration)比进程共用快近14秒，提速约40%。该模型参数量较小，GPU压力较小，瓶颈主要在于CPU。进程分离消除了CPU争抢造成的开销。

02

多步调度（Multi-step scheduling）

在请求调度层面，vLLM 0.6.0的更新中引入了多步调度 (Multi-step scheduling)的方法 [2]，使得请求处理的调度更高效。为了更好地理解多步调度的意义，我们简单了解一下vLLM调度器。

2.1 调度器 (Scheduler)

vLLM推理引擎LLMEngine中存在调度器 (Scheduler)的概念。调度器控制来自服务端的输入请求会以什么顺序送入模型执行推理。对于一个输入请求，我们需要首先对输入的句子执行prefill计算，并基于prefill得到的kv值开展decode计算，即预测下一个token。而调度器的职责就是以合理的调度策略，安排模型执行prefill或是decode的顺序 (篇幅限制，具体调度细节这里不展开)。

2.2 单步调度 vs. 多步调度在旧版vLLM中，每次调度器只会为下一次的模型推理安排优先顺序，即每次调度对应一次模型推理。该方法被称为单步推理；0.6.0引入多步推理，每次调度器调度会安排接下来的多次模型推理，即每次调度对应n次推理。多步推理可以减少调度次数，降低CPU开销，从而让模型推理充分利用GPU资源，尽量保持运行。

上：一次调度后执行1步推理；下：一次调度后执行3步推理。据vLLM团队测试，4张H100环境下运行Llama 70B，多步推理的吞吐量比单步推理提升了28%[3]。

2.3 测试&对比利用上述基准测试，对比单步调度与多步调度的性能差异。这次我们统一使用0.6.0版本。在保持其他设置相同的情况下，设置服务端启动参数分别如下。而客户端方面设置与上文相同，在此不再赘述。 #单步/多步调度

vllm serve facebook/opt-125m \

--max-model-len 2048 \

--use-v2-block-manager \

--disable-async-output-proc \ #关闭异步输出处理

--num-scheduler-steps 1/10 #每次调度1步/10步

以下为测试结果(左单步调度，右多步调度step=10)：

多步调度(step=10)的情况下，基准测试仅耗时7.69秒；而单步调度耗时21.68秒，整体速度上快近3倍。（由于opt-125m模型的参数量较小，计算瓶颈主要位于CPU端，因此对CPU端的优化效果极其显著；对于更大规模的模型，瓶颈位于GPU端，加速效果相对没有这么明显。）使用NVIDIA Nsight systems [5]进一步分析profile (NVTX中绿色块表明执行调度)。多步调度中每个绿色块之间有10组CPU epoll_pwait和read，即执行10次GPU上的模型推理，并读取结果；而单步推理中每个绿色块之间仅有1组epoll_pwait和read，即1次模型推理。

多步调度(step=10)

单步调度(step=1)细心的同学可能发现了，上述测试中，尽管多步调度的整体耗时降低了很多，但是ITL远大于单步调度。这是因为多步调度(step=10)将10步推理整合到了一起。因此，ITL(69.87秒)正好约为10倍TPOT(7.41秒)。增加一场多步调度(step=5)的测试进行验证，可以看到ITL约为41.76秒，约5倍于TPOT的8.79秒。

多步调度(step=5)

03

异步输出处理（ASync output processing）

在旧版vLLM中，GPU端模型推理输出token后，必须在CPU端对输出token进行处理并判断是否符合停止条件 (stopping criteria），从而决定是否继续推理，这个操作会产生时间开销；新版vLLM引入了异步输出处理，使得模型推理和输出处理异步进行，从而重叠计算的时间[3]。3.1 异步输出处理在异步输出处理中，我们把模型输出从GPU端取到CPU端进行停止条件判定时，并不会让模型停止推理，等待判定结果从而导致空闲。在CPU端对第n个输出进行处理并判定是否停止的同时，我们在GPU端假设第n个输出尚不符合停止条件，并继续推理预测第n+1个输出。这样的设计可能会使得每条请求都多了一次推理，造成些许耗时，但与GPU空闲等待所浪费的时间相比就显得很划算了。

上：不启用异步输出处理；下：启用异步输出处理。据vLLM团队测试，4张H100环境下运行Llama 70B，异步输出处理的TPOT指标比禁用快了8.7%[3]。

3.2 测试&对比我们对比启用和禁用异步输出处理的性能差异。在保持其他设置相同的情况下，设置服务端启动参数分别如下。vLLM 0.6.0中默认启用该功能，可以通过设置参数--disable-async-output-proc来手动关闭。#禁用/启用异步输出处理 vllm serve facebook/opt-125m \

--max-model-len 2048 \

--use-v2-block-manager \

--disable-async-output-proc #移除该参数则默认启用以下为测试结果(左禁用异步输出处理，右启用异步输出处理)：

异步输出处理可以获得一些细微的性能提升，主要体现在TPOT和ITL上，约5%左右，基本符合预期。

04
在优刻得UModelVerse体验新版vLLM

4.1创建并启动服务打开UCloud控制台(https://console.ucloud.cn/)，登录账号。点击左上角的“全部产品”，从中找到“模型服务平台 UModelVerse”。

点击进入后，点击左侧栏目中的“服务部署”，并点击“创建服务”。

进入界面后，设置想要使用的模型并添加服务名称后，在右侧选择合适的支付方式，并点击“立即购买”，系统自动跳转到支付页面。

完成支付后，页面回到“服务部署”。可以看到我们购买的服务正处于“部署中”的状态，稍作等待......

待状态转为“已上线”后，即可点击“访问”打开网页图形界面，或通过API调用。

4.2 使用服务4.2.1 通过网页图形界面点击“访问”即可进入与chatbot的图形对话页面：

4.2.2 通过API接口当然，我们也可以通过API接口进行对话。以下是调用代码样例。调用的API参数可以在服务列表中找到。其中：• API_KEY：即API Key• BASE_URL：为API地址• MODEL：为模型的名称

Python
from openai import OpenAI

API_KEY = 'aDZ39J204akIPPhmqQtLuf64CBA7ZbyQ0Ov88VzlPuBRjdvP' # API Key
BASE_URL = 'https://ai.modelverse.cn/uminfer-14e3pxj9lnfc/v1' # 模型URL
MODEL = "meta-llama/Meta-Llama-3.1-8B-Instruct" # 模型名

client = OpenAI(
api_key=API_KEY,
base_url=BASE_URL
)

# 调用模型生成文本
response = client.chat.completions.create(
model=MODEL, # 选择模型
temperature=0.5, # 温度，模型输出结果的随机性
max_tokens=512, # 最大tokens长度
messages=[
{"role": "user", "content": "你好呀，可以给我讲个笑话嘛？"},
]
)

# 获取并打印 AI 生成的回复
print(response.choices[0].message.content)

【相关资料】

[1]vLLM: https://github.com/vllm-project/vllm

[2] vLLM Highlights: https://github.com/vllm-project/vllm/releases/v0.6.0

[3] vLLM v0.6.0: 2.7x Throughput Improvement and 5x Latency Reduction: https://blog.vllm.ai/2024/09/05/perf-update.html

[4] vLLM benchmark source code: https://github.com/vllm-project/ ... equest_func.py#L283

[5] NVIDIA Nsight Systems: https://developer.nvidia.com/nsight-systems

编辑于 2024-11-07 11:40・IP 属地上海
内容所属专栏
大U的技术课堂
大U的技术课堂
“UCloud技术”公众号：ucloud_tech
订阅专栏
模型推理
AI大模型
推理框架

账号		自动登录	找回密码
密码			注册