Monitoring i observability dla on-prem LLM: co logować i jak

Czas czytania: ok. 8 minut. Klaster: architektura. Autor: Fryderyk.

Odpowiedź najpierw

Observability dla on-prem LLM to nie jeden dashboard z użyciem GPU. To cztery warstwy telemetrii, z których każda odpowiada na inne pytanie: infrastruktura (czy sprzęt daje radę), serwowanie (czy model odpowiada w akceptowalnym czasie), jakość (czy odpowiedzi są dobre i czy retrieval trafia), oraz audyt (kto, kiedy i o co pytał). Pierwsze trzy warstwy budujesz dla siebie, żeby system działał i żeby dało się go stroić. Czwarta warstwa to jednocześnie wymóg regulacyjny: NIS2 oczekuje dziennika zdarzeń, który pozwala odtworzyć, co działo się w systemie, i wykryć incydent. Klucz w tym, żeby logować całą ścieżkę zapytania, ale nie zapisywać bezmyślnie treści promptów i odpowiedzi, bo to samo w sobie tworzy nowy zbiór danych wrażliwych. Ta notatka pokazuje, co logować w każdej warstwie, czego nie zapisywać i jak observability spina się z audit trail wymaganym przez NIS2.

Spis treści

1. Dlaczego observability LLM to dwie potrzeby naraz
2. Cztery warstwy telemetrii: co logować
3. Prompt i completion: co zapisać, a czego nie
4. Tabela: sygnał, warstwa, po co
5. Jak to spina się z audit trail NIS2
6. Trzy błędy, które zobaczysz po incydencie, nie przed
7. FAQ
8. Disclosure i biases
9. Czego tu nie pokrywam
10. Powiązane notatki

Dlaczego observability LLM to dwie potrzeby naraz

Monitoring klasycznej aplikacji odpowiada na pytanie, czy usługa żyje i jak szybko odpowiada. Przy on-prem LLM to nadal potrzebne, ale niewystarczające. Model może odpowiadać szybko i stabilnie, a jednocześnie zwracać treści oderwane od danych źródłowych, jeśli retrieval się psuje. Może też działać poprawnie technicznie, a mimo to nie zostawiać śladu, który po incydencie pozwoli powiedzieć, kto zadał konkretne zapytanie i jakie dokumenty trafiły do kontekstu.

Stąd dwie potrzeby w jednym systemie. Pierwsza jest inżynierska: chcesz widzieć wąskie gardła, regresję jakości i koszt utrzymania, żeby stroić wdrożenie. Druga jest regulacyjna: chcesz dziennik, który obroni się przed audytorem i zasili obsługę incydentu. Dobrze zaprojektowana telemetria obsługuje obie naraz, bo w dużej części opiera się na tych samych zdarzeniach. Zła telemetria obsługuje tylko pierwszą i dopiero audyt pokazuje, że drugiej brakuje.

Cztery warstwy telemetrii: co logować

Warstwa infrastruktury. Wykorzystanie i temperatura GPU, zajętość pamięci akceleratora, przepustowość i opóźnienia sieci między strefami, stan dysków z indeksami. To warstwa, która mówi, czy sprzęt jest wąskim gardłem, i pozwala planować pojemność, zanim kolejka zapytań urośnie.

Warstwa serwowania. Opóźnienie do pierwszego tokenu, liczba tokenów na sekundę, długość kolejki, liczba zapytań na sekundę, wskaźnik błędów i timeoutów. To metryki, po których poznasz, że model dławi się przy szczycie obciążenia, i które pozwalają ustawić sensowne limity i alerty. Bez nich dowiadujesz się o problemie od użytkownika, nie z pulpitu.

Warstwa jakości. Trafność retrievalu, czyli czy do kontekstu trafiają właściwe fragmenty, udział odpowiedzi bez pokrycia w źródłach, wskaźnik odmów, sygnały zwrotne od użytkowników. Ta warstwa jest najtrudniejsza, bo jakość LLM nie sprowadza się do jednej liczby, ale nawet proste metryki retrievalu wychwytują regresję po zmianie chunkingu czy modelu embeddingów. Pisałem o samym retrievalu w notatce o RAG on-prem, tu wystarczy zapamiętać, że jakość trzeba mierzyć w czasie, a nie oceniać na oko raz na kwartał.

Warstwa audytu. Kto zadał zapytanie, kiedy, z jakiej tożsamości i przez którą aplikację, jakie dokumenty weszły do kontekstu, jaka wersja modelu i promptu systemowego obsłużyła żądanie. To warstwa, której inżynier sam z siebie nie zbuduje, bo do działania systemu nie jest potrzebna. Jest potrzebna audytorowi i zespołowi reagującemu na incydent.

Prompt i completion: co zapisać, a czego nie

Największa pułapka observability LLM to odruch, żeby logować pełną treść każdego promptu i każdej odpowiedzi. Wygląda to na najbogatszy możliwy zapis, a w praktyce tworzy nowy, gęsty zbiór danych wrażliwych, często wrażliwszy niż same źródła, bo zawiera to, o co ludzie faktycznie pytają. Ten log staje się celem sam w sobie i podlega tym samym wymogom ochrony co dane, które on-prem miał trzymać wewnątrz organizacji.

Rozsądny domyślny wybór to logować metadane zdarzenia zawsze, a treść tylko warunkowo. Zawsze zapisujesz identyfikator zapytania, tożsamość, znacznik czasu, wersję modelu i promptu, identyfikatory pobranych dokumentów oraz metryki wykonania. Treść promptu i odpowiedzi zapisujesz w formie skróconej lub pseudonimizowanej, a pełny zapis włączasz wybiórczo: na próbce do oceny jakości albo na czas diagnozy konkretnego problemu, z krótką retencją i osobną kontrolą dostępu. Dzięki temu masz pełną ścieżkę zdarzenia dla audytu i reakcji na incydent, nie mnożąc kopii danych wrażliwych bez potrzeby.

Tabela: sygnał, warstwa, po co

Sygnał	Warstwa	Po co go zbierasz
Wykorzystanie i pamięć GPU	Infrastruktura	Planowanie pojemności, wykrycie wąskiego gardła sprzętu
Opóźnienie pierwszego tokenu, tokeny na sekundę	Serwowanie	Dotrzymanie SLA, alert przy szczycie obciążenia
Trafność retrievalu, odsetek odpowiedzi bez pokrycia	Jakość	Wykrycie regresji po zmianie modelu lub chunkingu
Tożsamość, czas, wersja modelu, ID dokumentów	Audyt	Dziennik zdarzeń dla NIS2 i reakcji na incydent

Wydrukuj tę tabelę i sprawdź, którą linię twój obecny stack faktycznie zbiera. Zwykle brakuje warstwy jakości i połowy warstwy audytu.

Jak to spina się z audit trail NIS2

Art. 21 ustawy o krajowym systemie cyberbezpieczeństwa wymaga środków adekwatnych do ryzyka między innymi w obsłudze incydentów oraz w ocenie skuteczności zabezpieczeń. Żaden przepis nie każe logować konkretnego pola, bo lista jest technologicznie neutralna. Ale obsługa incydentu jest pusta, jeśli po zdarzeniu nie umiesz odpowiedzieć, kto i o co pytał model i jakie dane trafiły do odpowiedzi. Warstwa audytu jest właśnie tym dowodem.

Praktyczna konsekwencja jest taka, że dziennik zdarzeń LLM powinien wpadać do tego samego systemu zbierania logów co reszta infrastruktury krytycznej, z tą samą polityką retencji i ochroną przed modyfikacją. Log, który da się po cichu nadpisać, nie jest dowodem. Warto też, żeby granice, przez które przechodzi ruch, były logowane spójnie z modelem izolacji sieci, o którym pisałem osobno, bo połączenie diagramu stref z dziennikiem połączeń to artefakt, który audytor rozumie od razu. Pełną listę dokumentów, które i tak wytwarzasz przed audytorem, zebrałem w notatce o audit readiness, a observability jest tym, co te dokumenty zasila danymi.

Trzy błędy, które zobaczysz po incydencie, nie przed

Pierwszy: monitoring kończy się na GPU i uptime. System wygląda zdrowo na pulpicie, a jednocześnie od tygodni zwraca gorsze odpowiedzi, bo nikt nie mierzy jakości retrievalu. Regresję wychwytuje dopiero użytkownik.

Drugi: pełne logowanie treści bez polityki retencji i kontroli dostępu. Zamiast dowodu powstaje drugi zbiór danych wrażliwych, który sam staje się ryzykiem i przedmiotem pytań audytora, dlaczego trzymasz go dłużej, niż potrzeba.

Trzeci: logi LLM żyją w osobnej wysepce, poza centralnym zbieraniem logów. Przy incydencie trzeba je zszywać ręcznie, a część zdążyła się już zrotować. Dziennik, którego nie da się skorelować z resztą infrastruktury, obroni się słabo.

FAQ

Czy NIS2 wymaga logowania treści promptów?

Nie. Ustawa nie wskazuje konkretnych pól. Wymaga środków adekwatnych do ryzyka w obsłudze incydentów, a to sprowadza się do możliwości odtworzenia zdarzenia. W większości wdrożeń metadane zdarzenia wystarczą, a pełną treść zapisujesz wybiórczo i na krótko.

Czy wystarczy monitorować GPU i uptime?

Nie. To pokrywa tylko warstwy infrastruktury i serwowania. Bez warstwy jakości nie zauważysz regresji odpowiedzi, a bez warstwy audytu nie obsłużysz incydentu ani nie obronisz się przed audytorem.

Jak długo trzymać logi LLM?

Retencja powinna wynikać z twojej polityki i analizy ryzyka, spójnie z resztą infrastruktury krytycznej, nie z domyślnych ustawień narzędzia. Metadane zdarzeń zwykle trzyma się dłużej niż ewentualną pełną treść, którą ogranicza się do krótkiego okna.

Czym observability LLM różni się od klasycznego APM?

APM dobrze pokrywa infrastrukturę i serwowanie, ale nie mierzy jakości odpowiedzi ani nie zbiera z automatu tego, jakie dokumenty trafiły do kontekstu. Te dwie warstwy trzeba dołożyć świadomie.

// disclosure i biasesDisclosure i biases

Piszę z perspektywy osoby pracującej nad rozwiązaniami AI uruchamianymi poza chmurą publiczną, więc akcentuję wątki kontroli danych i śladu audytowego. Starałem się oddzielić wymóg regulacyjny od preferencji technicznej. Ten tekst nie jest opinią prawną ani projektem systemu monitoringu dla konkretnej organizacji. Podział na cztery warstwy to uproszczenie robocze, pomocne do rozmowy, a nie jedyny poprawny model.

// co tu nie pokrywamCzego tu nie pokrywam

Nie wskazuję konkretnych narzędzi observability ani stacków logowania, bo wybór zależy od tego, co już masz. Pomijam szczegóły metryk ewaluacyjnych jakości LLM, bo zasługują na osobną notatkę. Nie wchodzę w konfigurację alertów pod danego dostawcę ani w observability warstwy treningu i fine-tuningu, bo skupiam się na inferencji produkcyjnej. Nie omawiam też szczegółów prawnych retencji, które warto potwierdzić z zespołem compliance.

Powiązane notatki

• AI on-prem w europejskiej produkcji 2026: kompletny przewodnik architektoniczny
• RAG on-prem: architektura, chunking, retrieval i co naprawdę wpływa na jakość
• Network isolation dla on-prem AI: minimalne wymagania NIS2
• Audit readiness NIS2 plus AI: 7 dokumentów, które wytwarzasz przed audytorem