Што LiteLLM не можа бачыць: стан кантролю GPU, яка працуе пад гэйтвейем

Перахадзка з ручная створанай вораткай FastAPI на цэнтрызаваныя логі запытаў LiteLLM, аблікаванне токенаў і вярчынных ключоў, а таксама скашванне спецыяльнага коду вораткі. Воратка яшчэ ўсё бачыць толькі трафік, який праходзіць через ўсеянае яё межы. Работа ў працэсе выдання сервіса адкрывае цэлую категорыю пытанняў, на якія LiteLLM сама не можа даць адказ — пытанні пра чергі, спосабы падготавкі даных і ўзлагоджэння, перапуск контейнероў і насыцэнне хоста, якія вялічыць, чы роўна 11 секунд трывалася аперацыя і яна была успешной чы застрягла.

Фон

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

Падаючы нижэй за гэтыя межы, звычайныя праблемы стаюць іншымі. Запрос трываласцю ад адзинадцатай секунды можа значыць чаканне ў черзі на перавантажанай вырачвальнай працоўнай ейкасце або стварэнне довгага адпаведзення. З боку шлюза гэтыя ситуацыі выглядаюць аднакова; прычыны ж неаднаковыя. Адночасна вважаць іх аднаковымі показнікамі ведае на спецястаўцаў у неправым напрамку.

Тры слоі, якія знаходзяцца нижэй за шлюзам, кожны з іх патрабуе сваёй справжней інформацыі:

• Час выконання модэлю — тут і вырашаецца павільнасць. Час да першага токена складаецца з чакання ў черзі і падготавкі данных, а не толькі з процеса дэкодавання. Пропускная спроможнасць падготавкі данных і дэкодавання стварае розныя узькія месцы. Гэтыя сигналы надходзяць з самага механізма аддачы данных /metrics (напрыклад, vLLM), а не з шлюза.
• Контейнеры — через cAdvisor: які процес спрацоўвае меморыю, який контейнер перазапускаўся за ноччу.
• Хосты — через node-exporter: загальная колькасць CPU, меморыі і диска на апаратазе, які размешчае вырачвальныя працоўнія ейкасцы.

Чатыры джэралізаваннія маюць значэнне, таму што жадны адзін збіральнік не можа бачыць усія слоі. Логі Gateway без паметак пра час выканання — это частковая картына; паметкі пра час выканання без контексту хоста і кантэйнера не врачунваюць тых прыблудных процэсаў, якія перазапускаюцца о трох гадзінах ранку.

Полны комплект

На аднам серверы з GPU, які знаходзіцца на месцы, два проекты Docker Compose цялэвым чынам раздзеляюць разныя функцыі.

Комплект Gateway: LiteLLM, PostgreSQL для віртуальных ключоў і паказаннях выкарыстання, Redis для кэша лімітаў частоты.

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

Ключовыя рашэнні

1. Неабяром два файлы compose, а не адзін. LiteLLM уже выканалаваў службы для іншых каманд, калі была дадана можлівасць монітарынгу. Адключэнне Prometheus да таго ж compose прывяжаў бы кожную зміну налаштавання scrape-файлу да файлу гэйтвейу для працы. Раздзеленне дазволяе ізолюваць проблемы: можна свабодна перзбудаваць механізмы монітарынгу, а LiteLLM гэта не заўважае. Залежнасці існуюць толькі вярху-вниз. Сетевыя звязкі между разнымі стэкамі є елементам, які неабяром выкалічваецца толькі раз, у працэ пад загрозай шырокага распрабрашчання проблем. Якщо механізмы монітарынгу перестануць працаваць, моделі продовжуюць адпавядаць; якщо гэйтвей перестане працаваць, монітарынг продовжуе фіксаваць стан хоста для аналізу пасля прычыны збою.

2. По штатнае налаштаванне няма postgres-exporter чы редіс-экспортара. Хост можа ў спакойны чын практычваць іх. Але ўсё ж их адкладзілі:

• Калі LiteLLM працуе нормальна, внутрашняя частка базы дадзеных і кэша рэдку калі-небудзь патрабуе дашборд; проблемы спачатку выяўляюцца на гэйтвейзе.

node-exporter, cAdvisor і канцэнтры модэлі /metrics ўжо пакрываюць ключовыя слойвы.

Дадатковыя экспортары — это додатковыя версіі та дапаможная память.

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

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

Выкорыстанне на практыцы

1. Адзначэнне модэляў толькі ў config.yaml было клопачлівае. Модэлі, якія знаходзяцца ў файле, паказваюць абмарківку конфігурацыі ў інтэрфейсе і не падлягаюць рэдагаванню чы выдаленню без змены месца ўстановкі і перзагрузкі актыўнага проксі. Модэлі, зарэгістраваныя через Admin 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 реканструюе, што здарылася пасля адной дзейнасці корыстніка за дапамою розных вызоваў. Агрэгатаванне і реканструяванне ёсць взаімадопамагальныя процесы. Міграцыя гэйтвейу без плана манітарынгу проста перасуне „слепую зону“ на адны слой нижэй.