Прапорці vllm serve з розумними стартовими значеннями

vLLM — один з основних рушіїв для роздачі великих мовних моделей, передусім завдяки пропускній здатності та тому, як PagedAttention керує пам'яттю. Зазвичай ним керують із командного рядка: через vllm serve або стару форму python -m vllm.entrypoints.openai.api_server. Нижче одна конкретна команда, а потім огляд прапорців, які ви змінюватимете найчастіше, з розумним стартовим значенням для кожного.

Стартова команда

Ця команда роздає модель середнього розміру на машині з кількома GPU. Вона написана для PowerShell, тому перенесення рядків зроблені зворотними апострофами:

vllm serve meta-llama/Llama-3.1-8B-Instruct `
  --host 0.0.0.0 `
  --port 8000 `
  --tensor-parallel-size 2 `
  --gpu-memory-utilization 0.90 `
  --max-model-len 8192 `
  --max-num-seqs 256 `
  --dtype bfloat16 `
  --served-model-name llama3-8b `
  --api-key $env:VLLM_API_KEY

Кожен прапорець із неї розібрано нижче, плюс кілька додаткових, про які варто знати.

Вибір моделі й точності

model — позиційний аргумент: ID моделі на Hugging Face або локальний шлях до ваг. Це єдине, що треба вказати обов'язково. Решта параметрів має значення за замовчуванням, але в продакшені вони рідко підходять.

dtype задає числову точність ваг і активацій. Звичайні варіанти — auto, float16, bfloat16 і float32. На GPU класу Ampere й новіших беріть bfloat16. Він чисельно стійкіший за float16, практично нічого не коштує щодо пропускної здатності й обходить проблеми з переповненням, на які деякі архітектури натрапляють у float16.

trust-remote-code дозволяє vLLM запускати власний код моделювання з репозиторію моделі на Hugging Face. Деяким архітектурам він потрібен, щоб узагалі завантажитися. Тримайте прапорець вимкненим, якщо в картці моделі не сказано інакше: увімкнувши його, ви виконуєте довільний код із цього репозиторію.

quantization обирає схему стиснення, наприклад awq, gptq або fp8, і зменшує витрату пам'яті ціною певної втрати якості. Задавайте його, лише якщо завантажуєте вже квантизовані ваги або пам'яті GPU інакше не вистачає. Якщо запас є, краще bfloat16 або повна точність.

Бюджет пам'яті GPU і контексту

gpu-memory-utilization — частка пам'яті GPU, яку vLLM може забрати під ваги, активації та KV-кеш. На стабільність і пропускну здатність вона впливає сильніше майже за будь-яке інше налаштування. Почніть з 0.90. Якщо підняти набагато вище, інші процеси на карті можуть спричинити помилки браку пам'яті. Якщо опустити нижче, ви втрачаєте місце під KV-кеш, а це обмежує, скільки запитів можна обслуговувати одночасно.

max-model-len обмежує суму токенів промпту й генерації на один запит. Стеля — довжина контексту, на якій навчали модель, але можна поставити менше й заощадити пам'ять кешу. Підженіть його під реальні потреби застосунку. Якщо модель підтримує 128K токенів, а у вас лише короткі репліки в чаті, резервувати все це немає сенсу. Менше значення звільняє місце для більшої кількості одночасних послідовностей.

max-num-seqs обмежує, скільки запитів збирається в один батч, тобто керує паралельністю. Для багатьох навантажень підходить 256. Піднімайте, якщо є вільна пам'ять GPU і щільний трафік, і знижуйте, якщо довгі контексти тиснуть на пам'ять.

block-size — кількість токенів в одному блоці KV-кешу PagedAttention. Більші блоки означають менше обліку, але більше втраченого місця для коротких послідовностей. Значення за замовчуванням 16 підходить для більшості конфігурацій, і чіпати його доведеться рідко.

swap-space резервує оперативну пам'ять CPU, у гігабайтах на кожен GPU, куди за браку пам'яті можна вивантажити блоки KV-кешу замість того, щоб відхиляти запити. Почніть з 4. Якщо сплески трафіку призводять до помилок, а не до охайної черги, збільште.

Розподіл моделі між кількома GPU

tensor-parallel-size — на скільки GPU ділиться кожен шар. Це рішення, коли модель не вміщається на одну карту, а заразом спосіб на машинах із кількома GPU обміняти трохи затримки на пропускну здатність. Ставте його рівним кількості GPU у вузлі, віддаючи перевагу степеням двійки (1, 2, 4, 8), бо кількість голів уваги зазвичай на них ділиться без остачі.

pipeline-parallel-size задає кількість стадій конвеєра, зазвичай у поєднанні з тензорним паралелізмом, коли модель доводиться розтягувати на кілька вузлів. Залиште 1, якщо тільки модель не завелика для самого тензорного паралелізму всередині одного вузла.

Як відкрити сервер назовні

host і port визначають, де слухає API-сервер. Використовуйте 0.0.0.0, якщо до нього мають звертатися інші машини, або 127.0.0.1 для доступу лише локально. Звичний порт — 8000.

served-model-name — ім'я, яке клієнти вказують у запитах до API, і воно може відрізнятися від ID на Hugging Face. Це зручно, щоб дати розгортанню чисту версіоновану мітку. Оберіть щось коротке й стабільне, щоб застосунки далі по ланцюжку не були прив'язані до конкретного шляху до ваг.

api-key змушує клієнтів надсилати bearer-токен. Без нього запити може слати будь-хто, хто має доступ до порту. Задавайте його для всього, що виходить за межі локальних експериментів, і читайте зі змінної середовища, а не зашивайте в скрипти й не лишайте в історії shell.

enforce-eager вимикає захоплення CUDA-графів і запускає PyTorch в eager-режимі. Ви жертвуєте частиною пропускної здатності заради швидшого старту й зручнішого налагодження. У продакшені залиште прапорець вимкненим: CUDA-графи зазвичай дають відчутне прискорення. Вмикайте його тимчасово, коли шукаєте причину падіння, бо в eager-режимі стек-трейси зрозуміліші.

Як налаштовувати

Основна робота — баланс трьох величин відносно доступної пам'яті GPU: довжини контексту через max-model-len, паралельності через max-num-seqs і точності через dtype та quantization. Почніть обережно з gpu-memory-utilization, виміряйте реальну пропускну здатність і затримку під реалістичним навантаженням і підлаштовуйте далі, а не вгадуйте цифри заздалегідь.