Czego firma potrzebuje do LLM on-premise, od sprzętu po przetestowane odpowiedzi

Kiedy on-premise ma sens, a kiedy wystarczy prywatne konto w chmurze

On-premise ma sens, gdy przepis albo ocena ryzyka mówi, że danych nie może przetwarzać żaden zewnętrzny dostawca, albo gdy systemy, które asystent musi czytać, są dostępne tylko w twojej sieci. Jeśli wymaganie brzmi: dane mają być przetwarzane w UE przez związany umową podmiot przetwarzający i nie mogą służyć do trenowania, to wdrożenie modelu na własnym koncie w chmurze zwykle je spełnia przy dużo mniejszym nakładzie pracy operacyjnej. Zanim wybierzesz, zapisz wymaganie w jednym zdaniu. Z naszego doświadczenia większość późniejszych sporów wraca do wymagania, którego nikt nie zapisał.

Na dzień 7 listopada 2026 obie duże chmury opisują opcje dla UE. Według Microsoftu wdrożenia Data Zone w UE przetwarzają dane w ramach Azure EU Data Boundary, a w przypadku modeli sprzedawanych bezpośrednio przez Azure prompty i odpowiedzi nie są dostępne dla dostawców modeli i nie służą do trenowania modeli bazowych bez twojej zgody. W Amazon Bedrock profile wnioskowania przypisane do obszaru geograficznego, np. UE, utrzymują zapytania międzyregionalne w jego granicach, a ustawienie retencji decyduje, czy AWS może przechowywać prompty i odpowiedzi w celu przeciwdziałania nadużyciom.

Własny hosting AI czy zarządzane API: pełna decyzjaDane w UE z Azure OpenAI i Amazon Bedrock

Warstwy działającego systemu, od serwerów GPU po agentów

Działający system ma sześć warstw, a dane zostają w środku tylko wtedy, gdy żadna z nich nie łączy się z zewnątrz: serwery GPU, silnik serwujący, brama LLM, dostęp do danych i wyszukiwanie, asystent lub agent oraz testy z monitoringiem.

Dwa szczegóły ułatwiają późniejsze zmiany w stosie. vLLM udostępnia API zgodne z OpenAI, w tym chat completions i embeddings, a LiteLLM potrafi kierować ruch do serwera vLLM przez providera hosted_vllm, więc aplikacje rozmawiają z bramą, a nie z konkretnym modelem. Wirtualne klucze LiteLLM oraz budżety i limity na klucz, użytkownika lub zespół wymagają bazy Postgres. Bez niej budżety nie są egzekwowane (dokumentacja vLLM i LiteLLM, stan na 7 listopada 2026).

„Dane nie opuszczają firmy” to właściwość sieci, więc testuj ją jak właściwość sieci. Spisz każde połączenie wychodzące stosu: pobieranie modeli, rejestry kontenerów, mirrory pakietów, telemetrię i raportowanie błędów w każdym komponencie oraz każdą zewnętrzną usługę monitoringu. Potem domyślnie zablokuj ruch wychodzący z hostów silnika i bramy i przepuszczaj tylko to, co jest na liście. Dla nas to punkt kontrolny przed startem. Zdanie w dokumencie architektury nie wystarczy. Wyszukiwanie wymaga tej samej staranności wewnątrz firmy: asystent, który może czytać każdy plik, odpowie każdemu na każde pytanie. Wyniki trzeba więc filtrować według uprawnień osoby pytającej, zanim zobaczy je model.

Co robi brama LLMBezpieczne uruchamianie LiteLLM na produkcjiUprawnienia do dokumentów w RAG

Które modele open-weight są wystarczająco dobre po niemiecku i jak to sprawdzić

Model jest wystarczająco dobry po niemiecku, gdy przechodzi twoje testy akceptacyjne na twoich własnych dokumentach i pytaniach. Naszym zdaniem publiczne rankingi mówią niewiele o niemieckich tekstach biznesowych, więc nadają się co najwyżej do wstępnej selekcji. Dwa filtry daje bezpośrednio karta modelu. Pierwszy to obsługiwane języki: karta Llama 3.3 70B Instruct od Meta wymienia osiem obsługiwanych języków, w tym niemiecki, a karta Mistral Small 3.1 od Mistrala wymienia niemiecki wśród swoich języków. Drugi to licencja: Llama 3.3 korzysta z Llama 3.3 Community License Agreement, a Mistral Small 3.1 z Apache 2.0, i warunki są różne, więc daj licencję do sprawdzenia, zanim zainwestujesz w testy. Te dwa modele podajemy tylko jako przykład tego, co zawierają karty. Na starcie projektu sprawdź aktualne karty.

Potem przetestuj wybrane modele tak, jak później będziesz odbierać cały system:

• Zbierz prawdziwe pytania od przyszłych użytkowników razem z dokumentami, których by potrzebowali, także długimi i źle sformatowanymi
• Nazwij istotne typy błędów i ich wagę: błędna liczba, zmyślone źródło, odpowiedź po angielsku, niewłaściwa forma zwracania się, zepsuty JSON w wywołaniu narzędzia
• Uruchom każdego kandydata w precyzji, w której będziesz go serwować na produkcji, bo model skwantyzowany może zachowywać się inaczej niż pełny
• Niech niemieckojęzyczni eksperci dziedzinowi oceniają odpowiedzi, nie wiedząc, który model je napisał
• Uruchom każdy przypadek więcej niż raz, bo ten sam prompt może dać różne odpowiedzi
• Zachowaj przypadki: ten sam zestaw rozstrzyga o każdej późniejszej zmianie modelu

Z naszego doświadczenia różnice między kandydatami widać raczej w kilku konkretnych typach błędów, np. przy liczbach z tabel albo odpowiedziach o długich dokumentach, niż w średnim wyniku. Dlatego podawaj odsetek zaliczeń dla każdego typu błędu zamiast jednej liczby.

Sprawdzanie jakości modelu po kwantyzacjiKryteria akceptacji systemów AI

Dobór sprzętu bez kupowania niewłaściwych maszyn

Dobieraj sprzęt na podstawie pomiarów własnego obciążenia na wybranym modelu. Sama liczba użytkowników niewiele mówi: ta sama liczba osób może potrzebować zupełnie innego sprzętu w zależności od tego, jak długie są ich zapytania i ile przychodzi naraz. Oto czynniki, od których zależą pamięć i koszt:

• Rozmiar modelu i precyzja. Wagi zajmują mniej więcej liczbę parametrów razy liczbę bajtów na parametr. Karta Mistrala podaje na przykład, że Mistral Small 3.1 z 24 miliardami parametrów potrzebuje około 55 GB pamięci GPU w bf16 lub fp16, a po kwantyzacji mieści się na jednej karcie RTX 4090
• Długość kontekstu i współbieżność. KV cache rośnie z liczbą tokenów w każdym zapytaniu i liczbą zapytań obsługiwanych jednocześnie, więc długie dokumenty i agenci niosący historię zużywają większość pamięci
• Szczytowa współbieżność zamiast łącznej liczby użytkowników: policz zapytania obsługiwane jednocześnie w najbardziej obciążonej godzinie
• Redundancja: tyle mocy, żeby dalej obsługiwać ruch przy jednym wyłączonym serwerze
• Inne modele: modele embeddingów i rerankingu do wyszukiwania też potrzebują pamięci
• Zasilanie, chłodzenie, miejsce w szafie rack i ludzie, którzy utrzymują maszyny

Zmierz, zanim zamówisz. Wynajmij typ GPU, który rozważasz, uruchom wybrany model w vLLM w planowanej precyzji i długości kontekstu i odtwórz realistyczne zapytania. Na dzień 7 listopada 2026 vLLM ma polecenie benchmarku vllm bench serve do mierzenia przepustowości serwowania online, a endpoint /metrics raportuje vllm:num_requests_waiting, vllm:kv_cache_usage_perc i vllm:num_preemptions. Przewodnik vLLM po strojeniu wyjaśnia, że gdy brakuje miejsca w KV cache, zapytania są wywłaszczane i liczone ponownie później, co pogarsza opóźnienia. Jako rozwiązanie podaje więcej pamięci na cache albo mniej równoległych sekwencji na serwer. Ustal obciążenie, które jeden serwer wytrzymuje przy docelowym opóźnieniu, podziel przez nie szczyt i dodaj serwer zapasowy.

Planowanie mocy GPU, z przykładem obliczeń

Czego wymaga utrzymanie po starcie

Po starcie utrzymujesz usługę, więc ktoś musi odpowiadać za aktualizacje, monitoring, testy regresji i indeks dokumentów i mieć na to czas. On-premise oznacza, że wszystko to jest po twojej stronie: nikt inny nie załata silnika serwującego ani nie będzie pilnował GPU.

Sprawdzają się trzy modele utrzymania: wewnętrzny zespół platformowy, który już utrzymuje Kubernetes, dział IT z wyznaczonym właścicielem usługi AI albo zewnętrzny partner z pisemną umową o utrzymanie. Z naszego doświadczenia zawodzą systemy, których nikt nie dostał pod opiekę, gdy zespół projektowy przeszedł do innych zadań.

Testy regresji aplikacji LLMKto odpowiada za system AI po pilotażu

Ochrona danych, rada zakładowa i EU AI Act

Jeśli sam utrzymujesz model, nie potrzebujesz dla niego zewnętrznego podmiotu przetwarzającego. Inspektor ochrony danych, rada zakładowa i AI Act i tak pytają, co system robi z danymi osobowymi. Poniżej jest lista kontrolna do tych rozmów. To nie jest porada prawna, więc aktualne brzmienie przepisów sprawdź w oficjalnych źródłach podlinkowanych niżej.

Ochrona danych

Art. 35 RODO wymaga oceny skutków dla ochrony danych przed przetwarzaniem, zwłaszcza z użyciem nowych technologii, które może powodować wysokie ryzyko naruszenia praw lub wolności osób. Spodziewaj się pytań inspektora ochrony danych: jakie dane osobowe trafiają do promptów, indeksowanych dokumentów i logów, jak długo przechowujesz logi i kto ma do nich dostęp, oraz jak żądanie usunięcia danych dociera zarówno do indeksu, jak i do logów.

Rada zakładowa

Jeśli działasz w Niemczech, zgodnie z § 87 ust. 1 pkt 6 niemieckiej ustawy o ustroju zakładów pracy (BetrVG) rada zakładowa współdecyduje o wprowadzeniu urządzeń technicznych przeznaczonych do monitorowania zachowania lub wydajności pracowników. Federalny Sąd Pracy w postanowieniu z 16 lipca 2024 (1 ABR 16/23) powtórzył, że urządzenie jest przeznaczone do monitorowania, jeśli obiektywnie się do tego nadaje, niezależnie od zamiaru pracodawcy. W naszej ocenie brama, która zapisuje prompty z przypisaniem do użytkownika, spełnia ten warunek. Zaplanuj wcześnie porozumienie zakładowe i zaprojektuj logi pod nie: pseudonimizowane identyfikatory użytkowników, krótka retencja, imiennie wskazane osoby z dostępem i pisemna zasada, że logi nie służą do oceny wydajności.

EU AI Act

Na dzień 7 listopada 2026 AI Act, czyli rozporządzenie (UE) 2024/1689, jest zmieniony przez Digital Omnibus w zakresie AI, rozporządzenie (UE) 2026/1744 z 8 lipca 2026. Według harmonogramu Rady obowiązki dla samodzielnych systemów wysokiego ryzyka obowiązują teraz od 2 grudnia 2027, a dla systemów wysokiego ryzyka wbudowanych w produkty od 2 sierpnia 2028. Zmieniony art. 4 wymaga od dostawców i podmiotów stosujących podejmowania działań wspierających kompetencje w zakresie AI, bez obowiązku zagwarantowania konkretnego poziomu każdej osobie. W naszej ocenie wewnętrzny asystent do dokumentów zwykle nie jest systemem wysokiego ryzyka, ale jeśli ma przygotowywać decyzje dotyczące pracowników lub kandydatów, poproś prawnika, żeby przed budową sprawdził go względem listy wysokiego ryzyka w załączniku III.

Od pierwszego przypadku użycia do produkcji, krok po kroku

Przeprowadź jeden przypadek użycia do produkcji w ustalonej kolejności. Każdy krok daje to, czego potrzebuje następny: zapisane wymaganie, zestaw testów, zmierzony model, dobraną platformę i przetestowany system.

1. 1

   Wybierz jeden przypadek użycia i zapisz wymaganie dotyczące danych

   Wybierz zadanie z jasno określonymi użytkownikami i dokumentami i zapisz w jednym zdaniu, gdzie wolno przetwarzać jego dane. To zdanie rozstrzyga między on-premise a prywatnym kontem w chmurze.

2. 2

   Najpierw zbuduj zestaw testów

   Zbierz prawdziwe zapytania, oczekiwane zachowanie i typy błędów z wagą i wymaganym odsetkiem zaliczeń, uzgodnione z osobami, które będą odbierać system.

3. 3

   Wybierz i przetestuj modele

   Odfiltruj modele według licencji i obsługi niemieckiego, a potem uruchom kandydatów w docelowej precyzji na wynajętych GPU na zestawie testów.

4. 4

   Zmierz wydajność i dobierz sprzęt

   Przeprowadź benchmark wybranego modelu na realistycznym ruchu przy docelowym opóźnieniu, a potem dobierz sprzęt na szczyt plus jeden serwer zapasowy.

5. 5

   Zbuduj platformę z zablokowanym ruchem wychodzącym

   Postaw silnik serwujący, bramę, wyszukiwanie z filtrami uprawnień i monitoring, a potem zablokuj ruch wychodzący i przepuszczaj tylko to, co masz na liście.

6. 6

   Uzgodnij ochronę danych i sprawy z radą zakładową

   Dokończ ocenę skutków, uzgodnij projekt logów i porozumienie zakładowe oraz zaplanuj działania budujące kompetencje w zakresie AI, zanim pojawią się prawdziwi użytkownicy.

7. 7

   Przeprowadź testy akceptacyjne, potem ograniczone wdrożenie

   Wypuść system dopiero wtedy, gdy każde kryterium jest spełnione. Zacznij od jednej grupy użytkowników i obserwuj metryki oraz zgłaszane błędy.

8. 8

   Przekaż utrzymanie

   Wskaż właściciela, spisz runbooki i ustal rytm aktualizacji, testów regresji i przeglądów wydajności.

Budujemy i utrzymujemy takie systemy na własnych serwerach klienta albo na jego własnym koncie w chmurze, od warstwy serwowania na GPU po testy akceptacyjne przed startem.

AI on-premisevLLM na KubernetesPlatforma LLM i agentów