跳到内容

英特尔 Gaudi

本页面提供了在英特尔 Gaudi 设备上运行 vLLM 的说明。

警告

此设备没有预构建的 wheel 或镜像，因此您必须从源代码构建 vLLM。

要求

  • 操作系统：Ubuntu 22.04 LTS
  • Python：3.10
  • 英特尔 Gaudi 加速器
  • 英特尔 Gaudi 软件版本 1.18.0

请遵循 Gaudi 安装指南 中提供的说明来设置执行环境。为获得最佳性能，请遵循 优化训练平台指南 中概述的方法。

配置新环境

环境验证

要验证英特尔 Gaudi 软件是否正确安装，请运行

hl-smi # verify that hl-smi is in your PATH and each Gaudi accelerator is visible
apt list --installed | grep habana # verify that habanalabs-firmware-tools, habanalabs-graph, habanalabs-rdma-core, habanalabs-thunk and habanalabs-container-runtime are installed
pip list | grep habana # verify that habana-torch-plugin, habana-torch-dataloader, habana-pyhlml and habana-media-loader are installed
pip list | grep neural # verify that neural_compressor_pt is installed

有关更多详细信息，请参阅 英特尔 Gaudi 软件栈验证。

运行 Docker 镜像

强烈建议使用来自英特尔 Gaudi 存储库的最新 Docker 镜像。有关更多详细信息，请参阅 英特尔 Gaudi 文档。

使用以下命令运行 Docker 镜像

docker pull vault.habana.ai/gaudi-docker/1.18.0/ubuntu22.04/habanalabs/pytorch-installer-2.4.0:latest
docker run \
  -it \
  --runtime=habana \
  -e HABANA_VISIBLE_DEVICES=all \
  -e OMPI_MCA_btl_vader_single_copy_mechanism=none \
  --cap-add=sys_nice \
  --net=host \
  --ipc=host \
  vault.habana.ai/gaudi-docker/1.18.0/ubuntu22.04/habanalabs/pytorch-installer-2.4.0:latest

使用 Python 进行设置

预构建的 Wheels

目前，没有预构建的英特尔 Gaudi wheel 包。

从源代码构建 Wheel

要从源代码构建和安装 vLLM，请运行

git clone https://github.com/vllm-project/vllm.git
cd vllm
pip install -r requirements/hpu.txt
python setup.py develop

目前，最新的功能和性能优化在 Gaudi 的 vLLM-fork 中开发，我们定期将其上游到 vLLM 主仓库。要安装最新的 HabanaAI/vLLM-fork，请运行以下命令

git clone https://github.com/HabanaAI/vllm-fork.git
cd vllm-fork
git checkout habana_main
pip install -r requirements/hpu.txt
python setup.py develop

使用 Docker 进行设置

预构建的镜像

目前，没有预构建的英特尔 Gaudi 镜像。

从源代码构建镜像

docker build -f docker/Dockerfile.hpu -t vllm-hpu-env  .
docker run \
  -it \
  --runtime=habana \
  -e HABANA_VISIBLE_DEVICES=all \
  -e OMPI_MCA_btl_vader_single_copy_mechanism=none \
  --cap-add=sys_nice \
  --net=host \
  --rm vllm-hpu-env

提示

如果您遇到以下错误：docker: Error response from daemon: Unknown runtime specified habana.，请参阅 英特尔 Gaudi 软件栈和驱动程序安装 的“使用容器安装”部分。确保已安装 habana-container-runtime 包，并且已注册 habana 容器运行时。

额外信息

支持的功能

  • 离线推理
  • 通过 OpenAI 兼容服务器 进行在线服务
  • HPU 自动检测 - 无需在 vLLM 中手动选择设备
  • 为英特尔 Gaudi 加速器启用的分页 KV 缓存算法
  • 分页注意力、KV 缓存操作、预填充注意力、均方根层归一化、旋转位置编码的自定义英特尔 Gaudi 实现
  • 多卡推理的张量并行支持
  • 使用 HPU 图 进行推理，以加速低批次延迟和吞吐量
  • 带线性偏置的注意力（ALiBi）
  • INC 量化

不支持的功能

  • 集束搜索
  • LoRA 适配器
  • AWQ 量化
  • 预填充分块（混合批次推理）

支持的配置

以下配置已验证可在 Gaudi2 设备上运行。未列出的配置可能有效，也可能无效。

模型 TP 大小 数据类型 采样
meta-llama/Llama-2-7b 1, 2, 8 BF16 随机 / 贪婪
meta-llama/Llama-2-7b-chat-hf 1, 2, 8 BF16 随机 / 贪婪
meta-llama/Meta-Llama-3-8B 1, 2, 8 BF16 随机 / 贪婪
meta-llama/Meta-Llama-3-8B-Instruct 1, 2, 8 BF16 随机 / 贪婪
meta-llama/Meta-Llama-3.1-8B 1, 2, 8 BF16 随机 / 贪婪
meta-llama/Meta-Llama-3.1-8B-Instruct 1, 2, 8 BF16 随机 / 贪婪
meta-llama/Llama-2-70b 8 BF16 随机 / 贪婪
meta-llama/Llama-2-70b-chat-hf 8 BF16 随机 / 贪婪
meta-llama/Meta-Llama-3-70B 8 BF16 随机 / 贪婪
meta-llama/Meta-Llama-3-70B-Instruct 8 BF16 随机 / 贪婪
meta-llama/Meta-Llama-3.1-70B 8 BF16 随机 / 贪婪
meta-llama/Meta-Llama-3.1-70B-Instruct 8 BF16 随机 / 贪婪

性能调优

执行模式

目前在 vLLM for HPU 中，我们支持四种执行模式，具体取决于所选的 HPU PyTorch Bridge 后端（通过 PT_HPU_LAZY_MODE 环境变量）和 --enforce-eager 标志。

PT_HPU_LAZY_MODE enforce_eager 执行模式
0 0 torch.compile
0 1 PyTorch eager 模式
1 0 HPU 图

警告

在 1.18.0 版本中，所有使用 PT_HPU_LAZY_MODE=0 的模式都处于高度实验阶段，应仅用于验证功能正确性。它们的性能将在后续版本中得到改进。为了在 1.18.0 中获得最佳性能，请使用 HPU 图或 PyTorch lazy 模式。

分桶机制

英特尔 Gaudi 加速器在处理具有固定张量形状的模型时表现最佳。英特尔 Gaudi 图编译器 负责生成优化的二进制代码，以在 Gaudi 上实现给定的模型拓扑。在其默认配置下，生成的二进制代码可能严重依赖于输入和输出张量形状，并且在同一拓扑中遇到不同形状的张量时可能需要重新编译图。虽然生成的二进制文件能够高效利用 Gaudi，但编译本身可能会在端到端执行中引入显著的开销。在动态推理服务场景中，需要最小化图编译的数量并降低在服务器运行时发生图编译的风险。目前通过在 batch_size 和 sequence_length 两个维度上对模型的正向传播进行“分桶”来实现此目的。

注意

分桶可以显著减少所需图的数量，但它不处理任何图编译和设备代码生成——这在预热和 HPUGraph 捕获阶段完成。

分桶范围由 3 个参数决定——min、step 和 max。它们可以分别针对提示和解码阶段以及批处理大小和序列长度维度进行设置。这些参数可以在 vLLM 启动期间的日志中观察到

INFO 08-01 21:37:59 hpu_model_runner.py:493] Prompt bucket config (min, step, max_warmup) bs:[1, 32, 4], seq:[128, 128, 1024]
INFO 08-01 21:37:59 hpu_model_runner.py:499] Generated 24 prompt buckets: [(1, 128), (1, 256), (1, 384), (1, 512), (1, 640), (1, 768), (1, 896), (1, 1024), (2, 128), (2, 256), (2, 384), (2, 512), (2, 640), (2, 768), (2, 896), (2, 1024), (4, 128), (4, 256), (4, 384), (4, 512), (4, 640), (4, 768), (4, 896), (4, 1024)]
INFO 08-01 21:37:59 hpu_model_runner.py:504] Decode bucket config (min, step, max_warmup) bs:[1, 128, 4], seq:[128, 128, 2048]
INFO 08-01 21:37:59 hpu_model_runner.py:509] Generated 48 decode buckets: [(1, 128), (1, 256), (1, 384), (1, 512), (1, 640), (1, 768), (1, 896), (1, 1024), (1, 1152), (1, 1280), (1, 1408), (1, 1536), (1, 1664), (1, 1792), (1, 1920), (1, 2048), (2, 128), (2, 256), (2, 384), (2, 512), (2, 640), (2, 768), (2, 896), (2, 1024), (2, 1152), (2, 1280), (2, 1408), (2, 1536), (2, 1664), (2, 1792), (2, 1920), (2, 2048), (4, 128), (4, 256), (4, 384), (4, 512), (4, 640), (4, 768), (4, 896), (4, 1024), (4, 1152), (4, 1280), (4, 1408), (4, 1536), (4, 1664), (4, 1792), (4, 1920), (4, 2048)]
参数 描述
最小值 确定分桶的最低值。
步长 确定分桶之间的间隔。
最大值 确定分桶的上限。
渐进阶段 在 min 和 step 之间应用的特殊处理阶段
- min 连续乘以 2 的幂，直到达到 step。
- 最大限度地减少小批次大小的资源浪费。
- 允许对大批次进行更大的填充。

示例（带渐进）

min = 2, step = 32, max = 64
=> ramp_up = (2, 4, 8, 16)
=> stable = (32, 64)
=> buckets = ramp_up + stable => (2, 4, 8, 16, 32, 64)

示例（不带渐进）

min = 128, step = 128, max = 512
=> ramp_up = ()
=> stable = (128, 256, 384, 512)
=> buckets = ramp_up + stable => (128, 256, 384, 512)

在日志记录的场景中，为提示（预填充）运行生成了 24 个分桶，为解码运行生成了 48 个分桶。每个分桶对应于具有指定张量形状的给定模型的单独优化设备二进制文件。每当处理一批请求时，它会在批次和序列长度维度上填充到最小的可能分桶。

警告

如果请求在任何维度上超过最大分桶大小，它将在不进行填充的情况下进行处理，并且其处理可能需要图编译，这可能会显著增加端到端延迟。分桶的边界可通过环境变量进行用户配置，并且可以增加分桶上限以避免这种情况。

例如，如果一个包含 3 个序列、最大序列长度为 412 的请求进入空闲的 vLLM 服务器，它将被填充并作为 (4, 512) 预填充分桶执行，因为 batch_size（序列数）将被填充到 4（最接近且大于 3 的批处理大小维度），最大序列长度将被填充到 512（最接近且大于 412 的序列长度维度）。在预填充阶段之后，它将作为 (4, 512) 解码分桶执行，并将继续作为该分桶，直到批处理维度改变（由于请求完成）——在这种情况下它将变为 (2, 512) 分桶，或者上下文长度增加到超过 512 个 token，在这种情况下它将变为 (4, 640) 分桶。

注意

分桶对客户端是透明的——序列长度维度中的填充永远不会返回给客户端，并且批处理维度中的填充不会创建新请求。

预热

预热是一个可选但强烈推荐的步骤，它在 vLLM 服务器开始监听之前发生。它使用虚拟数据对每个分桶执行一次前向传播。目标是预编译所有图，并在服务器运行时不产生分桶边界内的任何图编译开销。每个预热步骤都会在 vLLM 启动期间记录下来

日志 
INFO 08-01 22:26:47 hpu_model_runner.py:1066] [Warmup][Prompt][1/24] batch_size:4 seq_len:1024 free_mem:79.16 GiB
INFO 08-01 22:26:47 hpu_model_runner.py:1066] [Warmup][Prompt][2/24] batch_size:4 seq_len:896 free_mem:55.43 GiB
INFO 08-01 22:26:48 hpu_model_runner.py:1066] [Warmup][Prompt][3/24] batch_size:4 seq_len:768 free_mem:55.43 GiB
...
INFO 08-01 22:26:59 hpu_model_runner.py:1066] [Warmup][Prompt][24/24] batch_size:1 seq_len:128 free_mem:55.43 GiB
INFO 08-01 22:27:00 hpu_model_runner.py:1066] [Warmup][Decode][1/48] batch_size:4 seq_len:2048 free_mem:55.43 GiB
INFO 08-01 22:27:00 hpu_model_runner.py:1066] [Warmup][Decode][2/48] batch_size:4 seq_len:1920 free_mem:55.43 GiB
INFO 08-01 22:27:01 hpu_model_runner.py:1066] [Warmup][Decode][3/48] batch_size:4 seq_len:1792 free_mem:55.43 GiB
...
INFO 08-01 22:27:16 hpu_model_runner.py:1066] [Warmup][Decode][47/48] batch_size:2 seq_len:128 free_mem:55.43 GiB
INFO 08-01 22:27:16 hpu_model_runner.py:1066] [Warmup][Decode][48/48] batch_size:1 seq_len:128 free_mem:55.43 GiB

此示例使用与 分桶机制 部分相同的分桶。每个输出行对应于单个分桶的执行。当分桶首次执行时，其图被编译并可以在以后重复使用，从而跳过进一步的图编译。

提示

编译所有分桶可能需要一些时间，并且可以通过设置 VLLM_SKIP_WARMUP=true 环境变量来关闭。请记住，如果您这样做，在首次执行给定分桶时，可能会面临图编译。在开发中禁用预热是可以的，但在部署中强烈建议启用它。

HPU 图捕获

HPU 图 目前是英特尔 Gaudi 上 vLLM 性能最高的执行方法。当启用 HPU 图时，执行图将提前（在执行预热后）被跟踪（记录），以便稍后在推理期间重放，从而显著减少主机开销。记录可能需要大量内存，这在分配 KV 缓存时需要考虑。启用 HPU 图将影响可用 KV 缓存块的数量，但 vLLM 提供了用户可配置的变量来控制内存管理。

当使用 HPU 图时，它们与 KV 缓存共享通用内存池（“可用内存”），该内存池由 gpu_memory_utilization 标志（默认为 0.9）确定。在分配 KV 缓存之前，模型权重会加载到设备上，并在虚拟数据上执行模型的前向传播，以估计内存使用情况。仅在此之后，才使用 gpu_memory_utilization 标志——在其默认值下，会将此时 90% 的可用设备内存标记为可用。接下来，分配 KV 缓存，模型进行预热，并捕获 HPU 图。环境变量 VLLM_GRAPH_RESERVED_MEM 定义了为 HPU 图捕获保留的内存比例。在其默认值 (VLLM_GRAPH_RESERVED_MEM=0.1) 下，10% 的可用内存将保留用于图捕获（稍后称为“可用图内存”），其余 90% 将用于 KV 缓存。环境变量 VLLM_GRAPH_PROMPT_RATIO 确定了为预填充图和解码图保留的可用图内存的比例。默认情况下 (VLLM_GRAPH_PROMPT_RATIO=0.3)，两个阶段具有相同的内存约束。较低的值对应于为预填充阶段保留的可用图内存较少，例如 VLLM_GRAPH_PROMPT_RATIO=0.2 将为预填充图保留 20% 的可用图内存，为解码图保留 80% 的可用图内存。

注意

gpu_memory_utilization 不对应于 HPU 的绝对内存使用量。它指定了加载模型并执行性能分析运行后的内存余量。如果设备总内存为 100 GiB，并且在加载模型权重和执行性能分析运行后有 50 GiB 的空闲内存，则 gpu_memory_utilization 在其默认值下会将 50 GiB 的 90% 标记为可用，留下 5 GiB 的余量，无论设备总内存是多少。

用户还可以单独配置用于捕获提示和解码阶段 HPU 图的策略。策略会影响图捕获的顺序。目前实现了两种策略

  • max_bs - 图捕获队列将按批处理大小降序排序。批处理大小相同的分桶按序列长度升序排序（例如 (64, 128), (64, 256), (32, 128), (32, 256), (1, 128), (1,256)），解码的默认策略
  • min_tokens - 图捕获队列将按每个图处理的 token 数量（batch_size*sequence_length）升序排序，提示的默认策略

当有大量请求待处理时，vLLM 调度器会尝试尽快填满解码的最大批处理大小。当一个请求完成时，解码批处理大小会减小。此时，vLLM 将尝试为等待队列中的请求安排一次预填充迭代，以将解码批处理大小填充到其先前的状态。这意味着在满负载场景下，解码批处理大小通常处于最大值，这使得捕获大批处理大小的 HPU 图至关重要，正如 max_bs 策略所反映的。另一方面，预填充将最频繁地以非常小的批处理大小 (1-4) 执行，这反映在 min_tokens 策略中。

注意

VLLM_GRAPH_PROMPT_RATIO 不会为每个阶段（预填充和解码）的图所占用的内存设置硬性限制。vLLM 将首先尝试用完所有可用的预填充图内存（可用图内存 * VLLM_GRAPH_PROMPT_RATIO）来捕获预填充 HPU 图，然后它将尝试对解码图和可用解码图内存池执行相同的操作。如果一个阶段完全捕获，并且可用图内存池中仍有未使用的内存，vLLM 将尝试对另一个阶段进行进一步的图捕获，直到在不超出保留内存池的情况下无法再捕获 HPU 图。该机制的行为可以在下面的示例中观察到。

vLLM 服务器会记录每个描述的步骤，如下所示（负值表示内存被释放）

日志 
INFO 08-02 17:37:44 hpu_model_runner.py:493] Prompt bucket config (min, step, max_warmup) bs:[1, 32, 4], seq:[128, 128, 1024]
INFO 08-02 17:37:44 hpu_model_runner.py:499] Generated 24 prompt buckets: [(1, 128), (1, 256), (1, 384), (1, 512), (1, 640), (1, 768), (1, 896), (1, 1024), (2, 128), (2, 256), (2, 384), (2, 512), (2, 640), (2, 768), (2, 896), (2, 1024), (4, 128), (4, 256), (4, 384), (4, 512), (4, 640), (4, 768), (4, 896), (4, 1024)]
INFO 08-02 17:37:44 hpu_model_runner.py:504] Decode bucket config (min, step, max_warmup) bs:[1, 128, 4], seq:[128, 128, 2048]
INFO 08-02 17:37:44 hpu_model_runner.py:509] Generated 48 decode buckets: [(1, 128), (1, 256), (1, 384), (1, 512), (1, 640), (1, 768), (1, 896), (1, 1024), (1, 1152), (1, 1280), (1, 1408), (1, 1536), (1, 1664), (1, 1792), (1, 1920), (1, 2048), (2, 128), (2, 256), (2, 384), (2, 512), (2, 640), (2, 768), (2, 896), (2, 1024), (2, 1152), (2, 1280), (2, 1408), (2, 1536), (2, 1664), (2, 1792), (2, 1920), (2, 2048), (4, 128), (4, 256), (4, 384), (4, 512), (4, 640), (4, 768), (4, 896), (4, 1024), (4, 1152), (4, 1280), (4, 1408), (4, 1536), (4, 1664), (4, 1792), (4, 1920), (4, 2048)]
INFO 08-02 17:37:52 hpu_model_runner.py:430] Pre-loading model weights on hpu:0 took 14.97 GiB of device memory (14.97 GiB/94.62 GiB used) and 2.95 GiB of host memory (475.2 GiB/1007 GiB used)
INFO 08-02 17:37:52 hpu_model_runner.py:438] Wrapping in HPU Graph took 0 B of device memory (14.97 GiB/94.62 GiB used) and -252 KiB of host memory (475.2 GiB/1007 GiB used)
INFO 08-02 17:37:52 hpu_model_runner.py:442] Loading model weights took in total 14.97 GiB of device memory (14.97 GiB/94.62 GiB used) and 2.95 GiB of host memory (475.2 GiB/1007 GiB used)
INFO 08-02 17:37:54 hpu_worker.py:134] Model profiling run took 504 MiB of device memory (15.46 GiB/94.62 GiB used) and 180.9 MiB of host memory (475.4 GiB/1007 GiB used)
INFO 08-02 17:37:54 hpu_worker.py:158] Free device memory: 79.16 GiB, 39.58 GiB usable (gpu_memory_utilization=0.5), 15.83 GiB reserved for HPUGraphs (VLLM_GRAPH_RESERVED_MEM=0.4), 23.75 GiB reserved for KV cache
INFO 08-02 17:37:54 hpu_executor.py:85] # HPU blocks: 1519, # CPU blocks: 0
INFO 08-02 17:37:54 hpu_worker.py:190] Initializing cache engine took 23.73 GiB of device memory (39.2 GiB/94.62 GiB used) and -1.238 MiB of host memory (475.4 GiB/1007 GiB used)
INFO 08-02 17:37:54 hpu_model_runner.py:1066] [Warmup][Prompt][1/24] batch_size:4 seq_len:1024 free_mem:55.43 GiB
...
INFO 08-02 17:38:22 hpu_model_runner.py:1066] [Warmup][Decode][48/48] batch_size:1 seq_len:128 free_mem:55.43 GiB
INFO 08-02 17:38:22 hpu_model_runner.py:1159] Using 15.85 GiB/55.43 GiB of free device memory for HPUGraphs, 7.923 GiB for prompt and 7.923 GiB for decode (VLLM_GRAPH_PROMPT_RATIO=0.3)
INFO 08-02 17:38:22 hpu_model_runner.py:1066] [Warmup][Graph/Prompt][1/24] batch_size:1 seq_len:128 free_mem:55.43 GiB
...
INFO 08-02 17:38:26 hpu_model_runner.py:1066] [Warmup][Graph/Prompt][11/24] batch_size:1 seq_len:896 free_mem:48.77 GiB
INFO 08-02 17:38:27 hpu_model_runner.py:1066] [Warmup][Graph/Decode][1/48] batch_size:4 seq_len:128 free_mem:47.51 GiB
...
INFO 08-02 17:38:41 hpu_model_runner.py:1066] [Warmup][Graph/Decode][48/48] batch_size:1 seq_len:2048 free_mem:47.35 GiB
INFO 08-02 17:38:41 hpu_model_runner.py:1066] [Warmup][Graph/Prompt][12/24] batch_size:4 seq_len:256 free_mem:47.35 GiB
INFO 08-02 17:38:42 hpu_model_runner.py:1066] [Warmup][Graph/Prompt][13/24] batch_size:2 seq_len:512 free_mem:45.91 GiB
INFO 08-02 17:38:42 hpu_model_runner.py:1066] [Warmup][Graph/Prompt][14/24] batch_size:1 seq_len:1024 free_mem:44.48 GiB
INFO 08-02 17:38:43 hpu_model_runner.py:1066] [Warmup][Graph/Prompt][15/24] batch_size:2 seq_len:640 free_mem:43.03 GiB
INFO 08-02 17:38:43 hpu_model_runner.py:1128] Graph/Prompt captured:15 (62.5%) used_mem:14.03 GiB buckets:[(1, 128), (1, 256), (1, 384), (1, 512), (1, 640), (1, 768), (1, 896), (1, 1024), (2, 128), (2, 256), (2, 384), (2, 512), (2, 640), (4, 128), (4, 256)]
INFO 08-02 17:38:43 hpu_model_runner.py:1128] Graph/Decode captured:48 (100.0%) used_mem:161.9 MiB buckets:[(1, 128), (1, 256), (1, 384), (1, 512), (1, 640), (1, 768), (1, 896), (1, 1024), (1, 1152), (1, 1280), (1, 1408), (1, 1536), (1, 1664), (1, 1792), (1, 1920), (1, 2048), (2, 128), (2, 256), (2, 384), (2, 512), (2, 640), (2, 768), (2, 896), (2, 1024), (2, 1152), (2, 1280), (2, 1408), (2, 1536), (2, 1664), (2, 1792), (2, 1920), (2, 2048), (4, 128), (4, 256), (4, 384), (4, 512), (4, 640), (4, 768), (4, 896), (4, 1024), (4, 1152), (4, 1280), (4, 1408), (4, 1536), (4, 1664), (4, 1792), (4, 1920), (4, 2048)]
INFO 08-02 17:38:43 hpu_model_runner.py:1206] Warmup finished in 49 secs, allocated 14.19 GiB of device memory
INFO 08-02 17:38:43 hpu_executor.py:91] init_cache_engine took 37.92 GiB of device memory (53.39 GiB/94.62 GiB used) and 57.86 MiB of host memory (475.4 GiB/1007 GiB used)
  • 我们建议在 Gaudi 2 上以 BF16 数据类型运行推理时，将 block_size 设置为 128。使用默认值 (16, 32) 可能会导致矩阵乘法引擎利用率不足，从而导致次优性能（参见 Gaudi 架构）。
  • 为了在 Llama 7B 上获得最大吞吐量，我们建议在启用 HPU 图的情况下，以 128 或 256 的批处理大小和 2048 的最大上下文长度运行。如果遇到内存不足问题，请参阅故障排除部分。

环境变量

诊断和性能分析控制

  • VLLM_PROFILER_ENABLED: 如果为 true，则启用高级分析器。生成的 JSON 跟踪可在 perfetto.habana.ai 中查看。默认为 false。
  • VLLM_HPU_LOG_STEP_GRAPH_COMPILATION: 如果为 true，则在发生任何图编译时，记录每个 vLLM 引擎步骤的图编译情况。强烈建议与 PT_HPU_METRICS_GC_DETAILS=1 一起使用。默认为 false。
  • VLLM_HPU_LOG_STEP_GRAPH_COMPILATION_ALL: 如果为 true，则始终记录每个 vLLM 引擎步骤的图编译情况，即使未发生。默认为 false。
  • VLLM_HPU_LOG_STEP_CPU_FALLBACKS: 如果为 true，则在发生任何 CPU 回退时，记录每个 vLLM 引擎步骤的 CPU 回退情况。默认为 false。
  • VLLM_HPU_LOG_STEP_CPU_FALLBACKS_ALL: 如果为 true，则始终记录每个 vLLM 引擎步骤的 CPU 回退情况，即使未发生。默认为 false。

性能调优控制

  • VLLM_SKIP_WARMUP: 如果为 true，将跳过预热，默认为 false

  • VLLM_GRAPH_RESERVED_MEM: 专用于 HPUGraph 捕获的内存百分比，默认为 0.1

  • VLLM_GRAPH_PROMPT_RATIO: 专用于提示图的保留图内存百分比，默认为 0.3

  • VLLM_GRAPH_PROMPT_STRATEGY: 确定提示图捕获顺序的策略，min_tokens 或 max_bs，默认为 min_tokens

  • VLLM_GRAPH_DECODE_STRATEGY: 确定解码图捕获顺序的策略，min_tokens 或 max_bs，默认为 max_bs

  • VLLM_{phase}_{dim}_BUCKET_{param} - 配置分桶机制范围的 12 个环境变量集合

    • {phase} 为 PROMPT 或 DECODE

    • {dim} 为 BS, SEQ 或 BLOCK

    • {param} 为 MIN, STEP 或 MAX

    • 默认值

{阶段} 参数 环境变量 值表达式
提示 最小批处理大小 VLLM_PROMPT_BS_BUCKET_MIN 1
提示 批处理大小步长 VLLM_PROMPT_BS_BUCKET_STEP min(最大序列数, 32)
提示 最大批处理大小 VLLM_PROMPT_BS_BUCKET_MAX min(最大序列数, 64)
提示 最小序列长度 VLLM_PROMPT_SEQ_BUCKET_MIN block_size
提示 序列长度步长 VLLM_PROMPT_SEQ_BUCKET_STEP block_size
提示 最大序列长度 VLLM_PROMPT_SEQ_BUCKET_MAX max_model_len
解码 最小批处理大小 VLLM_DECODE_BS_BUCKET_MIN 1
解码 批处理大小步长 VLLM_DECODE_BS_BUCKET_STEP min(最大序列数, 32)
解码 最大批处理大小 VLLM_DECODE_BS_BUCKET_MAX max_num_seqs
解码 最小序列长度 VLLM_DECODE_BLOCK_BUCKET_MIN block_size
解码 序列长度步长 VLLM_DECODE_BLOCK_BUCKET_STEP block_size
解码 最大序列长度 VLLM_DECODE_BLOCK_BUCKET_MAX max(128, (最大序列数*最大模型长度)/块大小)

此外，还有影响 vLLM 执行的 HPU PyTorch Bridge 环境变量

  • PT_HPU_LAZY_MODE: 如果为 0，将使用 Gaudi 的 PyTorch Eager 后端；如果为 1，将使用 Gaudi 的 PyTorch Lazy 后端。默认为 1。
  • PT_HPU_ENABLE_LAZY_COLLECTIVES: 对于使用 HPU 图进行张量并行推理，必须设置为 true

故障排除：调整 HPU 图

如果您遇到设备内存不足问题或想尝试更高批处理大小的推理，请尝试按以下方式调整 HPU 图

  • 调整 gpu_memory_utilization 控制。它将减少 KV 缓存的分配，为捕获更大批处理大小的图留下一些余量。默认情况下，gpu_memory_utilization 设置为 0.9。它尝试在短时性能分析运行后，将 HBM 剩余的约 90% 分配给 KV 缓存。请注意，减小此值会减少您可用的 KV 缓存块数量，从而降低您在给定时间可以处理的有效最大 token 数。
  • 如果此方法效率不高，您可以完全禁用 HPUGraph。禁用 HPU 图后，您将牺牲较低批处理的延迟和吞吐量，以换取较高批处理的潜在更高吞吐量。您可以通过向服务器添加 --enforce-eager 标志（用于在线服务）或向 LLM 构造函数传递 enforce_eager=True 参数（用于离线推理）来实现。