Що не може бачити LiteLLM: моніторинг роботи GPU під гейтвеєм

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

Предісторія

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

Під цим порогом зображення ситуації стає різним. Запит тривалістю одинадцять секунд може означати очікування у черзі на перевантаженому GPU або створення довгої відповіді. Для шлюза це виглядає однаково; проте способи вирішення проблем різні. Розглядати їх як один показник веде операторів служби підтримки у неправильному напрямку.

На три рівні нижче шлюзу кожен потребує власних показників:

• Час виконання моделі – саме тут визначається затримка. Час до отримання першого токена включає як очікування у черзі, так і попереднє заповнення, а не лише декодування. Пропускна здатність під час попереднього заповнення та декодування обмежується по-різному. Ці дані надходять з власного каналу /metrics двигуна обробки запитів (наприклад, vLLM), а не від шлюза.
• Контейнери – через cAdvisor: який процес споживає пам’ять, який контейнер було перезапущено протягом ночі.
• Хости – через node-exporter: загальна кількість CPU, пам’яті та диску на пристрої, який містить GPU.

Чотири джерела інформації є важливими, тому що жоден окремий збирач даних не бачить усіх аспектів. Журнали Gateway без метрик часу виконання — це лише часткова картина; метрики часу виконання без контексту хоста та контейнера не враховують фактори, як-от сусідні процеси, що перезапускалися о третій годині ночі.

Повний комплекс

На одному сервері з GPU в локальній інфраструктурі два проекти Docker Compose навмисно розділяють функції.

Компоненти Gateway: LiteLLM, PostgreSQL для обробки віртуальних ключів та операцій з коштами, Redis для кешу обмежень швидкості.

Компоненти моніторингу: Prometheus, Grafana, node-exporter, cAdvisor. Процеси vLLM часто запускаються на хості поза обома комплексами — по одному процесу на кожну оброблювану модель. Prometheus збирає дані з чотирьох джерел, які охоплюють метрики, пов’язані з Gateway та безпосередньо з моделями. Такий розподіл не є естетичним вибором — це спосіб збереження опційної інфраструктури як такої.

Ключові рішення

1. Два файли compose, а не один. LiteLLM вже обслуговував інші команди ще до додавання функції моніторингу. Якби Prometheus було об’єднано з тим самим файлом compose, кожна зміна конфігурації скрапінгу призводила б до змін у файлі гейтвею для продакшену. Розділення дозволяє ізолювати проблеми: можна вільно перебудувати систему моніторингу, а LiteLLM цього не помітить. Залежності існують лише в одному напрямку. Мережеве з’єднання між компонентами є одноразовою витратою порівняно з постійним ризиком поширення проблем. Якщо система моніторингу зламається, моделі все одно будуть відповідати; якщо зламається гейтвей, моніторинг все одно буде фіксувати стан хоста для аналізу після несправності.

2. За замовчуванням немає postgres-exporter чи redis-exporter. Хост може без проблем їх запускати. Проте їх використання все одно відкладено:

• Поки LiteLLM працює належним чином, внутрішні механізми бази даних та кешу рідко потребують панелі керування; проблеми спочатку проявляються у гейтвеї.

node-exporter, cAdvisor та кінцеві точки моделі /metrics вже охоплюють критичні шари.

Додаткові експортери — це додаткові версії та операційна пам’ять.

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

3. Підтримка Langfuse. LiteLLM об’єднує можливості моніторингу запитів, проте одна дія продукту часто передбачає багато викликів моделей: отримання даних, узагальнення, подальші дії. Спільні ідентифікатори сеансів дозволяють групувати виклики в LiteLLM, але трасування користувацького досвіду та збереження користувачів відрізняється. Журнали гейтвею не призначені для безкінечного зберігання даних. Старіші записи використовуються для оцінки можливостей заміни моделей та допомагають у виправленні проблем, виявлених у попередні тижні. Метрики агрегуються; записи трасування відновлюють повну картину. Жодна з цих систем не може повністю замінити іншу — саме тому вони залишаються разом.

Використання на практиці

1. Оголошення моделей лише в файлі config.yaml було складним. Моделі, які знаходяться у файлі, позначаються спеціальним значком у інтерфейсі та не дозволяють їх редагувати чи видаляти без зміни параметрів підключення та перезавантаження проксі. Моделі, зареєстровані через API адміністратора, зберігаються в PostgreSQL та залишаються доступними після перезавантаження:

curl -X POST <http://localhost:4000/model/new> \
  -H "Authorization: Bearer$LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model_name": "CHAT_MODEL",
    "litellm_params": {
      "model": "openai/CHAT_MODEL",
      "api_base": "<http://host.docker.internal:8001/v1>",
      "api_key": "dummy"
    }
  }'

Краще використовувати конфігурацію для налаштувань та базу даних для каталогу моделей. Такий підхід дозволяє операторам додавати експериментальні моделі, не впливаючи на процес гейтвею, який використовують інші команди.

2. Панель керування Node-Exporter майже не використовувалась. Після того, як навантаження стабілізувалося та процеси розгортання сповільнилися, загальні показники хостів більше не давали корисної інформації. Збережіть механізм збору даних; не інвестуйте занадто багато у невикористовувані панелі. Панелі cAdvisor та vLLM привертали більше щоденної уваги, оскільки вони відображають латентність, видиму для користувача.

3. Корисні початкові налаштування Grafana

• Панелі керування спільноти vLLM (наприклад, публічна панель на grafana.com з номером 23991)
• cAdvisor (14282)
• Node Exporter Full (1860)

Імпортуйте їх як базові налаштування, а потім видаліть панелі, які ніколи не відкриваються.

Підсумок

Очевидною проблемою є відсутність сповіщень: показники існують, але сторінка не активується при перевищенні порогів. Підключення API електронної пошти додатку до хостів GPU поєднує різні проблеми; оберіть безпечніший шлях сповіщень у майбутньому. Концептуально Prometheus та Grafana відповідають на запитання, які вже є відомими; Langfuse реконструює наслідки дій користувача через послідовні виклики. Агрегація та реконструкція є взаємодоповнюваними. Міграція гейтвею без плану моніторингу лише переміщує „сліпу зону“ на один рівень нижче.