vllm prometheus observability llmops gpu ttft

Метрики інференсу vLLM: від TTFT та TPOT до KV Cache та Goodput

Посібник з використання метрик vLLM Prometheus — показники успішності, відсоткові квантиля затримки, співвідношення вводу/виводу токенів, переривання роботи, попереднє заповнення даних у частинах, DPD та прийом спекулятивного декодування.

Видавець: REACTAPP.TOPДодано на сайт 26 вер. 2026 р.13 хв читання2973 слів

Джерела: A Deep Dive into vLLM Inference Metrics

Обслуговування великих мовних моделей не стикається з тими самими проблемами з огляду на можливість спостереження, що й обслуговування безстанових мікросервісів. Відсоток використання CPU та середнє затримку запитів є слабкими показниками, коли поведінку визначають увага до деталей, безперервне групування запитів та ємність пам’яті HBM. Увага у продакшені змістилася від простої кількості оброблених токенів до goodput — успішного виконання завдань у межах суворих показників якості.

Цей посібник детально розглядає основні показники двигуна vLLM, які слід відображати на панелях Grafana: лічильники надійності, гістограми затримок, економіку токенів, динаміку KV-пам’яті, навантаження на планувальник та варіанти топології, які з’являються лише тоді, коли телеметрія читається правильно.

Узагальнені статистики та стан системи

Двигуни LLM часто виходять з ладу непомітно — із погіршеною якістю генерації та прихованими перервами — а не з чіткими помилками HTTP. Тому для оцінки стану необхідні семантичні причини завершення, а не лише коди статусу.

Рівень успішності та розподіл причин завершення

Рівень успішності — це кількість успішних операцій серед усіх оброблених запитів протягом певного періоду. У vLLM це означає аналіз того, як завершився цикл генерації, а не просто підрахунок коду 200 OK. Стабільні системи зазвичай мають рівень успішності близько 99,5% або вище; постійне зниження до рівня нижче 98% є ознакою критичної ситуації.

Лічильник — це vllm:request_success_total, позначений через finished_reason:

Stop — природне завершення або налаштований рядок для зупинки. Вважається справжнім успіхом.
Length — обрізка через досягнення максимального обсягу контексту або кількості генерацій.
Abort — роз’єднання клієнта або внутрішня перерва.

Хронічне досягнення межи length часто означає, що модель занадто довго обробляє завдання, або ж параметри max_model_len та обмеження на генерацію занадто суворі для стилю запиту. Типова формула PromQL — це співвідношення кількості завершень через досягнення межі до загальної кількості завершень протягом п’ятихвилинного інтервалу.

Пропускна здатність проти конвергенції успішності

Побудуйте графік загальної пропускної здатності запитів поруч із кількістю успішних завершень. При нормальному навантаженні криві мають рухатися паралельно. Збільшення розриву означає, що GPU витрачають ресурси на обробку завдань, які так і не стають успішними — через таймаути (переривання) або порушення обмежень за довжиною тексту. Під час тестів навантаження великі розриви свідчать про погіршення ефективності обробки або про безкінечну генерацію, яка намагається досягти меж довжини.

Збір сміття в Python та пам’ять процесу

Більша частина виконуваних операцій здійснюється в CUDA/C++, проте організація роботи все одно відбувається через Python. Відстежуйте кількість операцій збору сміття разом із обсягом пам’яті процесу (RSS).

Часті виклики процедури очищення пам’яті створюють коливання у часі обробки окремих токенів. Поступове зростання значень RSS вказує на витоки пам’яті у механізмах прив’язки та зрештою призводить до активації механізму зупинки програм через нестачу пам’яті. Контейнери можуть здаватися „у порядку“ щодо використання CPU, незалежно від того, чи вони неактивні, чи працюють; саме у некерованих пулах пам’яті виникає прихована проблема.

Кількісна оцінка затримки та користувацького досвіду

Затримка у генерації має довгий хвост. Середні значення приховують справжні проблеми; обов’язково використовувати показники P50/P90/P99 та інші аналогічні.

Затримка запиту від початку до кінця

Затримка від початку до кінця охоплює період від надходження запиту до отримання останнього токена та його закриття. Відповідно до vLLM, показник vllm:e2e_request_latency_seconds відображається у вигляді гістограми. Для розрахунку квантилів використовується функція histogram_quantile() із лінійною интерполяцією всередині кожного інтервалу. Часті різкі піки значень P99 часто означають, що механізм послідовної обробки запитів не може ефективно поєднувати їх надходження — настав час перевірити роботу планувальника та рівень навантаження на кеш.

P99 часу до отримання першого токена (TTFT)

TTFT — це показник інтерактивності. Рекомендації з HCI передбачають час виконання менше однієї секунди, щоб уникнути розчарування користувача.

На TTFT значний вплив має процес prefill: читання запиту, зосередження уваги та створення початкової кеш-пам’яті KV. Витрати приблизно пропорційні квадрату довжини послідовності помноженому на її ширину — це обчислювально-інтенсивна робота у форматі TFLOPS. Приклад масштабу: заповнення кеш-пам’яті 512 токенами у моделі обсягом близько 70 млрд параметрів вимагає кількох десятків TFLOPS.

PromQL для TTFT P99:

histogram_quantile(0.99, sum(rate(vllm:time_to_first_token_seconds_bucket[5m])) by (le))

У інтерфейсах чату TTFT P99 часто є вирішальним обмеженням. Великі розміри кеш-пам’яті у середньоякісних GPU (наприклад, класу L40S) можуть зробити TTFT неприйнятним, незалежно від методу батчингу — це змушує команди використовувати менші моделі або чипи з вищою продуктивністю у форматі TFLOPS (класу H100).

Час на кожен токен вихідного результату (TPOT) та розбивка етапів інференсу

Після першого токена починається процес decode. TPOT (затримка між токенами) вимірює швидкість обробки наступних токенів.

Декодування зазвичай обмежене шириною пропускної здатності пам’яті: на кожному кроці ваги та історія KV завантажуються з HBM у пристрій обробки даних із низькою арифметичною інтенсивністю (~1 FLOP/байт для щільних маршрутів без MoE).

Корисний розклад:

E2E ≈ TTFT + (N_output − 1) × TPOT

Діаграми розбивки етапів показують співвідношення часу попереднього заповнення та часу декодування:

Високий час попереднього заповнення → довгі запити або низька потужність у TFLOPS.
Високий час декодування → довгі результати або насичена пропускна здатність HBM.

Порівняння TTFT та TPOT при зростанні навантаження — це найшвидший спосіб визначити «глухий кут».

Пропускна здатність токенів та характеристика навантаження

Затримка без обсягу даних не дозволяє оцінити вартість обладнання.

Пропускна здатність токенів та співвідношення вводу/виводу

Розділіть пропускну здатність на кількість токенів у запитах/сек та кількість токенів у результаті/сек. Вищі постійні значення краще компенсують вартість користування GPU.

Співвідношення токенів вхідних даних до токенів результату (кількість токенів запиту до кількості токенів генерації) характеризує роботу:

Високе (~20:1) — довгі вхідні дані, короткі результати: RAG, узагальнення, класифікація. Сильне використання попереднього заповнення.
Низьке — короткі запити, довга генерація: відкритий чат, створення коду. Сильне використання функцій декодування/HBM.

Невідповідність топології цьому співвідношенню призводить до марних витрат: використання RAG у системах, оптимізованих під декодування, або довгих чатів у платформах з обмеженим попереднім заповненням.

Гістограма довжини запиту

Гістограми довжини запитів показують, чи є трафік одномодальним з рівномірним розподілом, чи це суміш дуже коротких та дуже довгих запитів. Сильні відхилення у довжині запитів пояснюють сплески TTFT навіть тоді, коли показник QPS здається невеликим.

Внутрішні механізми двигуна та динаміка кешу

Зовнішня затримка залежить від стану кешу KV та планувальника.

Використання кешу KV GPU

Стежте за тим, наскільки заповнений пул KV. У міру зростання завантаження постійне групування дозволяє обробляти менше послідовностей; після досягнення певного порогу двигун перериває процес.

Швидкість знаходження даних у кеші префіксів та економія ресурсів

Кешування префіксів дозволяє повторно використовувати KV для спільних префіксів запитів (системні запити, заголовки RAG). Швидкість знаходження даних та кількість заощаджених ресурсів допомагають визначити, чи справді дизайн запитів та їх маршрутизація використовують спільні префікси, чи випадково кожен запит стає унікальним.

Стан схемувальника та ефективність системи

Слідкуйте за кількістю запущених та очікуючих операцій. Зростання кількості очікуваних операцій при стабільній кількості запущених зазвичай означає обмеження через KV або параметр max_num_seqs, а не „зайнята CPU“.

Стан схемувальника та частота переривань

Коли KV не може зберігати вектори наступного токена, vLLM передчасно припиняє обробку. Показник vllm:num_preemptions_total є лімітним контролером: ненульове значення, що зберігається протягом тривалого часу, вимагає більше VRAM, більшої кількості реплік або зниження максимального значення max_num_seqs.

Ефективність системи та час у черзі запитів

Ефективність системи порівнює швидкість обробки зі швидкістю надходження запитів. Значення близькі до 1,0 означають, що запити обробляються швидко; значення, що опускаються нижче ~0,7, свідчать про те, що черга очікування зростає швидше, ніж її можуть обробити GPU.

Ця проблема проявляється через показник vllm:request_queue_time_seconds — час, який витрачається на очікування перед початком корисної обробки. Збільшення часу в черзі призводить до затримок у всьому процесі навіть при відсутності оброблених токенів.

Класичні методи регулювання на основі CPU тут не ефективні. Підключіть показники vllm:num_requests_waiting та часу в черзі через адаптер Prometheus, щоб механізм регулювання масштабувався залежно від глибини черги (наприклад, при наявності багатьох запитів у очікуванні), а не від ілюзорних показників CPU.

Інфраструктура, балансування навантаження та складні топології

Сигнали програмного забезпечення мають відповідати реальності апаратного забезпечення.

Балансування навантаження та використання апаратного забезпечення

Тривалість обробки запитів LLM сильно варіюється — хвилини для довгого генерування проти миттєвих коротких відповідей. Тому метод «колесо жеребкування» призводить до дисбалансу в роботі систем. Краще використовувати балансувальники, які враховують глибину обробки запитів.

Перевірте за допомогою DCGM:

Використання GPU — бажаним показником є високе використання при низьких чергах; високе використання при довгих чергах означає насичення.
Використана VRAM — підтверджує, що vLLM зарезервував необхідну кількість пам’яті на початку роботи.

Вирішення конфлікту між попереднім заповненням та декодуванням

Великий обсяг обчислень, необхідний для попереднього заповнення в мішаній партії, може монополізувати тензорні ядра та зупинити всі поточні процеси декодування — що призводить до різких змін TPOT та переривчастості потоків даних.

Домінують два підходи до зменшення впливу проблем: часткове попереднє заповнення та розділене попереднє заповнення/декодування.

Часткове попереднє заповнення

Величезні запити діляться на фіксовані частини (наприклад, по 512 токенів), а ці частини чергуються з кроками декодування інших запитів. Час виконання для новачків зростає трохи; час виконання для всіх інших залишається стабільним. Показники ефективності: більш плавні гістограми ITL, помірна вартість P50 за часом TTFT та значне покращення стабільності потоку при P99.

Розділене попереднє заповнення та декодування (DPD)

У більш масштабних сценаріях етапи виконання розміщуються на різних пристроях: попереднє заповнення відбувається на GPU з високою продуктивністю у форматі TFLOPS, а декодування — на GPU з великою кількістю пам’яті типу HBM; після попереднього заповнення дані KV передаються по мережі. Слідкуйте за часами та кількістю переданих байтів у метриках типу NIXL (або еквівалентних) — наприклад, vllm:nixl_xfer_time_seconds_sum та vllm:nixl_bytes_transferred_sum. Підхід DPD є ефективним лише тоді, коли час передачі даних менший за рівень втручань, які він усуває; якість технологій RDMA/NCCL визначає цей критерій.

Математика спекулятивного декодування

Спекулятивне декодування прискорює процес, обмежений обсягом пам’яті, за допомогою невеликої пробної моделі, яка пропонує токени, та цільової моделі, яка перевіряє їх усі за один проходження. Перевірка кількох токенів може коштувати приблизно одного кроку генерації, що дозволяє обійти обмеження HBM у разі, коли пробні версії є ефективними.

Ключовий показник: швидкість прийняття пробних версій (vllm:spec_decode_draft_acceptance_rate). Очікувана кількість прийнятих токенів на крок утворює геометричну прогресію з ймовірністю прийняття α. Якщо α опускається нижче ~0,5, додаткові витрати на пробні версії можуть перевищити економію ресурсів та уповільнити роботу системи.

Оцінюйте пробні версії за умов режиму виробництва. У режимі жадібності (T=0) значення α може становити приблизно 0,8, тоді як у творчому режимі T=1,0 це ж значення знижується до приблизно 0,4 — що перетворює оптимізацію на регресію.

Архітектура телеметрії Prometheus з багатопроцесним підходом

Сервер vLLM, сумісний з OpenAI, використовує багатопроцесну обробку. Прості клієнти Prometheus не функціонують належним чином між робочими процесами через обмеження GIL та розділену пам’ять.

Рішенням є використання prometheus_client.multiprocess разом із параметром PROMETHEUS_MULTIPROC_DIR: кожен робочий процес додає зміни до файлів, мапованих у пам’ять; збір дань відбувається через MultiProcessCollector, який об’єднує результати OpenMetrics. Вимогливі запити PromQL (histogram_quantile, rate) залишаються у Prometheus, а не на шляху обробки даних — тому вимірювання затримок не стає причиною додаткових затримок.

Разом ці показники — причини успіху чи невдачі, квантилі TTFT/TPOT/E2E, структура вводу-виводу токенів, заповненість KV-пам’яті, переривання обробки, час очікування у черзі, а також статистика передачі даних та спекулятивні показники, характерні для конкретної топології — створюють замкнений цикл від користувацьких KPI до фізичних параметрів GPU. Саме цей цикл перетворює vLLM з демонстраційного сервера на функціональну платформу для обробки даних.

Тримайте письмовий посібник, у якому кожен критичний показник прив’язаний до першої дії: зростання кількості переривань → скоротити max_num_seqs або додати VRAM; лише TTFT P99 → скоротити запити, підвищити значення TFLOPS або увімкнути кеш префіксів; різкий зростання TPOT при повному використанні KV → зменшити тиск під час декодування або усунути перешкоди від попереднього заповнення; колапс спекулятивного α → скоригувати параметри проектування та температуру. До кожної зміни потужності додавайте графіки продуктивності до/після на одному графіку, щоб витрати на обладнання були пов’язані з досягненням цілей SLO, а не лише з кількістю операцій за секунду. Переглядайте панелі керування співвідношенням вводу/виводу щоразу, коли змінюється склад продукту — запуск функцій типу RAG та довгометражних контентів миттєво переміщують узгодження процесів між попереднім заповненням та декодуванням, і пороги автомасштабування вчора стають причиною безшумних черг сьогодні. Нарешті, розглядайте каталоги показників багатопроцесорної роботи як частину життєвого циклу підсистеми: порожні або з порушеними правами шляхи PROMETHEUS_MULTIPROC_DIR виглядають як „здорові“ дані з нулями, тоді як користувачі вже відчувають проблеми.

перерву у роботі.

Під час впровадження нового чекпоїнта моделі необхідно заморозити профіль навантаження (співвідношення довжини запиту, співвідношення довжини вихідних даних, конкурентність) та порівняти ті самі панелі PromQL перед тим, як почати направляти трафік. Чекпоїнт, який має кращі показники за середню кількість токенів/секунду, але гірші показники за TTFT P99 чи коефіцієнт випередження, не є кандидатом на використання у інтерактивних API.

Під час впровадження нового чекпоїнта моделі необхідно заморозити профіль навантаження (співвідношення довжини запиту, співвідношення довжини результату, конкурентність) та порівняти ті самі панелі PromQL перед тим, як почати направляти трафік. Чекпоїнт, який має кращі показники за середню кількість токенів/секунду, але гірші показники за TTFT P99 чи коефіцієнт випередження, не є кандидатом на використання в інтерактивних API.

← Усі статті Надіслати бриф