英特爾 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)

環境變數¶

診斷和效能分析控制

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 引數（用於離線推理）來實現。