Co LiteLLM nie może zobaczyć: monitorowanie serwowania GPU pod bramką.

Przechodzimy od ręcznie tworzonego bramy FastAPI na centralne logi zapytań LiteLLM, zarządzanie tokenami i kluczami wirtualnymi oraz redukcję kodu własnej bramy. Brama nadal widzi jedynie ruch przechodzący przez jej granice. Serwowanie w środowisku produkcyjnym rodzi całą gamę pytań, na które LiteLLM sam nie może odpowiedzieć – pytania dotyczące kolejek, metody prefill w porównaniu z decode, restartów kontenerów oraz przeciążenia hosta, które decydują o tym, czy połączenie trwające jedenaście sekund było prawidłowe, czy utknęło.

Tło

LiteLLM znajduje się na granicy przychodzących zapytań. Rejestruje, że nadeszło połączenie, który model je obsłużył, liczbę tokenów, który klucz wirtualny został użyty oraz wynik operacji – sukces czy niepowodzenie. Do codziennego śledzenia kosztów to właśnie to jest najważniejsze dla działu finansowego i zespołu produktowego.

Poniżej tej granicy obraz sytuacji się różni. Prośba trwająca jedenaście sekund może oznaczać czekanie w kolejce na przeciążonym GPU lub prawidłową generację długiej odpowiedzi. Z perspektywy bramy te przypadki wyglądają identycznie; rozwiązania jednak nie. Traktowanie ich jako jednej miary kieruje osoby odpowiedzialne w niewłaściwym kierunku.

Trzy warstwy poniżej bramy wymagają posiadania własnych danych rzeczywistych:

• Czas działania modelu, w którym określa się opóźnienie. Czas do pierwszego tokena obejmuje zarówno czekanie w kolejce, jak i wcześniejsze uzupełnianie danych, a nie tylko ich dekodowanie. Przepustowość przy wcześniejszym uzupełnianiu i dekodowaniu jest ograniczana w różny sposób. Te dane pochodzą z własnego interfejsu /metrics silnika serwowania (na przykład vLLM), a nie z bramy.
• Kontenery, za pośrednictwem cAdvisor: który proces zużywa pamięć, który kontener został restartowany w nocy.
• Hosty, za pośrednictwem node-exporter: całkowita ilość CPU, pamięci i dysku na serwerze, który hostuje GPU.

Cztery źródła są ważne, ponieważ żaden pojedynczy kolektor nie widzi wszystkich warstw. Logi Gateway bez metryk czasu działania przedstawiają jedynie część obrazu sytuacji; metryki czasu działania bez kontekstu hosta i kontenera pomijają elementy zakłócające, takie jak urządzenie, które zostało ponownie uruchomione o trzeciej nad ranem.

Pełny zestaw narzędzi

Na jednym lokalnym serwerze z GPU dwa projekty Docker Compose celowo oddzielają różne funkcje.

Gateway compose: LiteLLM, PostgreSQL do przechowywania kluczy wirtualnych i informacji o wydatkach, Redis do buforowania ograniczeń szybkości.

Narzędzia do monitoringu: Prometheus, Grafana, node-exporter, cAdvisor. Procesy vLLM często działają na hostzie, poza oboma zestawami narzędzi, po jednym procesie na każdy obsługiwany model. Prometheus pobiera dane z czterech źródeł, które obejmują metryki związane z Gateway oraz te specyficzne dla modeli. Taki podział nie jest kwestią estetyki – to sposób na to, by opcjonalna infrastruktura pozostała faktycznie opcjonalna.

Kluczowe decyzje

1. Używaj dwóch plików compose, a nie jednego. LiteLLM już obsługiwał inne zespoły, gdy dodano funkcję monitoringu. Połączenie Prometheus z tym samym plikiem compose spowodowałoby powiązanie każdej zmiany w konfiguracji scrape z plikiem bramy produkcyjnej. Taka separacja umożliwia izolację awarii: można swobodnie odbudować system monitoringu – LiteLLM tego nie zauważy. Zależności działają w jednym kierunku. Sieciowanie między poszczególnymi komponentami wiąże się z jednorazowym kosztem w porównaniu do ciągłego ryzyka poważnych skutków awarii. Jeśli monitoring przestanie działać, modele nadal odpowiadają; jeśli zepsuje się brama, monitoring nadal rejestruje stan hosta w celach analizy po awarii.

2. Domyślnie nie ma postgres-exporter ani redis-exporter. Host mógłby je bez problemu uruchomić. Mimo to ich wdrożenie zostało odroczone:

• Dopóki LiteLLM funkcjonuje prawidłowo, wewnętrzne elementy bazy danych i pamięci cache rzadko wymagają panelu kontrolnego; awarie pojawiają się najpierw na poziomie bramy.

node-exporter, cAdvisor oraz punkty końcowe modelu /metrics już obejmują kluczowe warstwy.

Dodatkowe eksporterzy to dodatkowe wersje i zasoby pamięci operacyjnej.

Nie używane panele kontrolne generują koszty konserwacyjne bez żadnych korzyści. Przeanalizuj je ponownie, gdy błędy połączenia z PostgreSQL staną się regularne, autoryzacja za pomocą kluczy wirtualnych spowolni się z powodu konfliktów zapytań, lub presja pamięci w Redis stanie się realnym problemem — wtedy dodaj eksporterów jeszcze w tym tygodniu. Zapisz kryteria odwołania, aby pominięcie tych działań pozostało decyzją, a nie efektem amnezji.

3. Utrzymanie Langfuse. LiteLLM integruje możliwości obserwacji zapytań, jednak jedna operacja produktu często polega na wielu wywołaniach modelu: pobieraniu danych, ich podsumowywaniu czy dalszym działaniach. Wspólne identyfikatory sesji mogą grupować te wywołania w LiteLLM, ale śledzenie doświadczenia użytkownika i retencji różni się. Logi bramy nie są przeznaczone jako archiwa trwałe. Starsze zapisy służą do tworzenia zestawów oceny przy zmianie modeli oraz pomagają w analizie raportów z poprzednich tygodni. Metryki agregują dane, natomiast zapisy rekonstruują sytuację. Żadna ilość danych z pierwszej kategorii nie może w pełni zastąpić tych z drugiej – dlatego obie pozostają.

Rozwiązanie w praktyce

1. Deklarowanie modeli wyłącznie w pliku config.yaml było uciążliwe. Modeli przechowywane w plikach mają specjalną ikonę konfiguracji w interfejsie i nie dają się edytować ani usunąć bez zmiany sposobu ich podłączenia oraz ponownego załadowania aktywnego proxya. Modele zarejestrowane przez Admin API przechowywane są w PostgreSQL i przetrwają restarty systemu:

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"
    }
  }'

Zaleca się używanie konfiguracji do ustawień oraz bazy danych dla katalogu modeli. Taki podział umożliwia operatorom dodawanie modeli eksperymentalnych bez ingerencji w proces bramy, który jest wykorzystywany przez inne zespoły.

2. Panel Node-Exporter był mało wykorzystywany. Gdy obciążenia stabilizowały się, a procesy wdrażania zwalniały, ogólne dane dotyczące hostów przestały dawać odpowiedzi na istotne pytania. Zachowaj funkcję pobierania danych; nie inwestuj zbyt wiele w nie używane panele. Panele cAdvisor i vLLM przyciągały większą codzienną uwagę, ponieważ pokazują opóźnienia widoczne dla użytkowników.

3. Przydatne punkty wyjścia dla Grafany

• Panele społeczności vLLM (na przykład publiczny panel na grafana.com o numerze 23991)
• cAdvisor (14282)
• Node Exporter Full (1860)

Importuj je jako punkty odniesienia, a następnie usuń panele, które nigdy nie są otwierane.

Podsumowanie

Największą lukią jest brak skutecznego powiadamiania: metryki istnieją, ale żadna strona nie reaguje po przekroczeniu progów. Łączenie API poczty aplikacji z serwerami GPU miesza różne aspekty; wybierz następnym razem bezpieczniejszą metodę powiadamiania. Koncepcyjnie Prometheus i Grafana odpowiadają na pytania, które są już znane; Langfuse natomiast odtwarza skutki danej akcji użytkownika poprzez serię wywołań. Agregacja i odtwarzanie są wzajemnie uzupełniające. Migracja bramy bez planu monitoringu jedynie przesuwa ten „ślepy punkt” o jeden poziom niżej.