Open-source’owe LLM-y na fali: aktualne nowości w Llama, Mistral i innych modelach do wdrożeń on‑premise

Dlaczego open‑source’owe LLM‑y rosną szybciej niż budżety na chmurę

Od monopolu API do silnych modeli open‑source

Przez pierwsze lata boomu na generatywną AI dominował jeden wzorzec: zamknięte API dużych dostawców (OpenAI, Anthropic, Google). Firmy, które chciały używać modeli językowych, praktycznie nie miały alternatywy – kupowały dostęp do chmurowego API, płaciły za tokeny i godziły się na ograniczoną kontrolę nad tym, jak model działa i gdzie trafiają dane.

Sytuacja zmieniła się, gdy na rynek weszły kolejne generacje open‑source’owych LLM‑ów: Llama 2, Llama 3/3.1/3.2, Mistral, Mixtral, Qwen, DBRX, Phi. Różnice jakościowe między nimi a zamkniętymi modelami top‑tier zaczęły się zacierać, szczególnie w zastosowaniach biznesowych: asystenci wewnętrzni, wyszukiwarki semantyczne, RAG, generowanie dokumentów czy wsparcie developerskie.

Obecnie wiele firm realnie porównuje: „czy opłaca się płacić za chmurowe API, skoro Llama 3 8B lub Mistral 7B na jednym serwerze GPU daje wystarczającą jakość?”. Wraz ze wzrostem jakości modeli open‑source rośnie zainteresowanie wdrożeniami on‑premise, aby mieć pełną kontrolę nad kosztami i danymi.

Główne motywacje firm: koszty, prywatność, regulacje, lock‑in

O przejściu na open‑source’owe LLM‑y on‑premise decyduje kilka powtarzających się motywów:

• Kontrola kosztów – dla stałych, dużych wolumenów zapytań koszt tokenów w chmurze zaczyna przewyższać koszt zakupu i utrzymania własnego sprzętu (szczególnie przy modelach 7B–13B).
• Prywatność i poufność danych – dane medyczne, finansowe, R&D czy dane osobowe nie powinny opuszczać infrastruktury firmy. W niektórych branżach to nie tylko preferencja, ale wymóg prawny lub kontraktowy.
• Zgodność z regulacjami – RODO, DORA, NIS2, regulacje sektorowe (bankowość, ubezpieczenia, administracja publiczna) często wymagają jasnej kontroli nad tym, kto ma dostęp do danych i gdzie są przetwarzane.
• Unikanie vendor lock‑in – firmy nie chcą uzależniać kluczowych procesów od jednego dostawcy; open‑source umożliwia migrację między platformami i samodzielne modyfikacje.
• Elastyczność techniczna – własny model on‑premise można fine‑tunować, modyfikować architekturę inferencji, łączyć z wewnętrznymi systemami w sposób trudny lub niemożliwy w czystym SaaS/API.

W wielu projektach decyzja nie jest zero‑jedynkowa. Typowy scenariusz to hybryda: modele open‑source on‑premise dla danych wrażliwych i powtarzalnych zadań, a zamknięte API chmurowe dla zadań wymagających najwyższej możliwej jakości lub specjalnych funkcji (np. zaawansowanej wizji 2D/3D, mowy).

Kiedy on‑premise ma sens, a kiedy lepiej zostać przy chmurze

On‑premise nie jest złotym środkiem dla każdego. Warto dopasować model wdrożenia do kilku konkretnych parametrów projektu:

• Duża skala i powtarzalne użycie – jeśli asystent wewnętrzny ma obsługiwać tysiące pracowników i setki tysięcy zapytań miesięcznie, lokalny LLM często wyjdzie taniej niż opłata za API per token.
• Bardzo wrażliwe dane – w bankowości, medycynie, sektorze publicznym, R&D farmacji czy produkcji będzie nacisk na to, by dane nie wychodziły poza kontrolowaną infrastrukturę.
• Customizacja i integracje niskopoziomowe – jeśli planowane są głębokie integracje z systemami legacy, autorskimi bazami danych czy złożone pipeline’y RAG, lokalny model daje pełną swobodę.

Z drugiej strony, chmura może być lepszym wyborem, gdy:

• projekt jest na etapie pilotażu / PoC i nie ma pewności, że przetrwa dłużej niż kilka miesięcy,
• brakuje zespołu, który potrafi utrzymać infrastrukturę GPU i oprogramowanie inferencyjne,
• potrzebny jest model z absolutnej czołówki jakości, przewyższający aktualnie dostępne open‑source (np. przy tworzeniu złożonych materiałów marketingowych dla klientów końcowych).

„Chmura własna” vs prawdziwe on‑premise w data center

Pojęcia są często mieszane: wiele zespołów mówi „on‑premise”, podczas gdy realnie hostuje modele w chmurze IaaS u dużego dostawcy. Różnice są istotne, szczególnie dla działów compliance.

Scenariusz 1: własne serwery w data center (on‑prem)
Sprzęt jest własnością organizacji, stoi w jej serwerowni lub data center współdzielonym, ale z dedykowaną infrastrukturą. Pełna kontrola nad tym, kto ma fizyczny dostęp, gdzie są logi, jak wygląda segmentacja sieci. Najwyższy poziom kontroli, ale też największe koszty wejścia i utrzymania.

Scenariusz 2: własne instancje GPU w chmurze publicznej
Firma tworzy „własny” klaster, ale na infrastrukturze dostawcy (AWS, Azure, GCP, OVH itp.). Model jest zarządzany przez zespół firmy, dane spływają do instancji IaaS, jednak wciąż działają polityki i ograniczenia chmurowego provider’a. To często dobry kompromis: łatwość skalowania + częściowa kontrola.

Scenariusz 3: czyste API LLM jako usługa
Firma wysyła tokeny z zapytaniami do API LLM (np. OpenAI, Mistral AI, Cohere) i płaci za użycie. Zero kontroli nad tym, jak i gdzie dokładnie działa inferencja, pełna zależność od SLA i zmian w cenniku.

W praktyce wielu klientów, gdy mówi o „modelu lokalnym”, ma na myśli model zarządzany samodzielnie, niezależnie od tego, czy stoi on na fizycznym serwerze w piwnicy, czy na instancji GPU w dużej chmurze. Z punktu widzenia architektury aplikacji i kosztów ma to często większe znaczenie niż fizyczna lokalizacja serwera.

Krótkie odświeżenie pojęć: LLM, SLM, parametry, kontekst, tokeny

Parametry modeli: 7B, 13B, 70B i co z tego wynika

Liczba parametrów (np. 7B, 8B, 70B) to rozmiar modelu, który bezpośrednio przekłada się na wymagania sprzętowe i typowe zastosowania. Uproszczony obraz wygląda tak:

• Modele 3B–8B – lekkie, szybkie, sensowne do pojedynczego serwera GPU lub nawet CPU (po quantyzacji). Dobre do prostszych Q&A, asystentów wewnętrznych, lekkiego RAG.
• Modele 13B–34B – środek skali: lepsza jakość, mocniejsze rozumienie, nadal możliwe do uruchomienia na jednym mocnym serwerze (1–2 GPU 40–80 GB) po odpowiedniej optymalizacji.
• Modele 70B+ – wysoka jakość, ale też wysokie wymagania sprzętowe. Zwykle potrzebują wielu GPU z NVLink/InfiniBand i dobrze zaprojektowanego klastra.

Większy model zwykle znaczy wyższą jakość, ale przy wdrożeniach on‑premise trzeba równolegle liczyć: koszt serwera, pobór mocy, opóźnienia, liczbę równoległych użytkowników. Czasem dobrze dostrojony model 7B daje biznesowo lepszy wynik niż 70B, jeśli jest uruchomiony blisko aplikacji, szybko odpowiada i został dopasowany do domeny.

LLM vs SLM: kiedy mniejszy model ma przewagę

Coraz częściej pojawia się pojęcie SLM (Small Language Model). To nie inna technologia, lecz świadomy wybór mniejszej architektury (często 1B–7B), zoptymalizowanej na wydajność i lokalne wdrożenia zamiast maksymalnej jakości ogólnej.

SLM sprawdza się szczególnie, gdy:

• liczy się czas odpowiedzi (sub‑sekundowe odpowiedzi dla prostych zapytań biznesowych),
• infrastruktura jest ograniczona (mało GPU, starsze karty, edge computing),
• model ma być ściśle zawężony do domeny i otoczony dobrym RAG (wtedy nie potrzebuje „wiedzieć wszystkiego”).

Wiele współczesnych modeli, takich jak Phi‑3, Llama 3.2 w mniejszych wariantach czy Qwen‑1.5 4B, wpisuje się w kategorię SLM i jest projektowanych konkretnie z myślą o wdrożeniach lokalnych i aplikacjach mobilnych.

Kontekst, długość sekwencji i okno kontekstowe

Okno kontekstowe (context window) określa, ile tokenów model może „widzieć” jednocześnie. Typowe wartości dla open‑source’owych LLM‑ów to 4k, 8k, 32k, 128k tokenów. W praktyce:

• 4k–8k tokenów wystarczy do krótkich dialogów, prostych Q&A i generowania tekstu,
• 32k tokenów umożliwia analizę większych dokumentów (np. kilkudziesięciostronicowe PDF‑y),
• 128k tokenów i więcej jest użyteczne przy pracy na całych bazach dokumentów, logach czy długich transkrypcjach.

Dłuższy kontekst kosztuje więcej pamięci i czasu. Każde wydłużenie okna kontekstowego zwykle wymaga albo większej ilości VRAM, albo bardziej agresywnych optymalizacji (kv‑cache, quantyzacja, techniki atencjonalne). W lokalnych wdrożeniach rozsądniej jest łączyć średnie okno kontekstowe (np. 8k–16k) z dobrze zaprojektowanym RAG niż ślepo gonić za 128k.

Tokeny, znaki i konsekwencje dla kosztów

Modele liczą tekst w tokenach, a nie w znakach czy słowach. 1000 tokenów to mniej więcej 700–800 słów po polsku, ale zależy to od konkretnego tokenizera. Ma to znaczenie:

• w chmurze – bo płaci się zwykle per 1k lub 1M tokenów,
• on‑premise – bo liczba tokenów wpływa na zużycie pamięci (im więcej tokenów w kontekście, tym większy kv‑cache) i wydajność.

Przy projektowaniu systemu on‑premise opłaca się wprowadzić mechanizmy kontrolujące długość promptów i odpowiedzi: limity tokenów, skracanie historii rozmowy, podsumowywanie poprzednich interakcji. Bez tego nawet szybki model będzie stopniowo zwalniał wraz z rozrostem kontekstu.

Llama – flagowiec open‑source i ostatnie ważne aktualizacje

Od Llama 2 do Llama 3/3.1/3.2: istotne zmiany dla wdrożeń

Rodzina Llama od Meta stała się de facto standardem w świecie open‑source’owych LLM‑ów. Ewolucja kolejnych generacji przyniosła kilka kluczowych zmian istotnych z perspektywy wdrożeń on‑premise:

• Llama 2 – pierwsza szeroko adoptowana generacja z sensowną licencją komercyjną; modele 7B, 13B, 70B; warianty base i chat/instruct; dobre wyniki w zadaniach ogólnych.
• Llama 3 – wyraźny skok jakościowy, szczególnie w generowaniu kodu, rozumowaniu i językach innych niż angielski; wprowadzenie nowych rozmiarów i lepszego alignementu konwersacyjnego.
• Llama 3.1 / 3.2 – dalsze doszlifowanie jakości, wydłużone okna kontekstowe, wersje zoptymalizowane pod specyficzne zadania (np. kod), modele jeszcze lepiej dopasowane do realnych zastosowań biznesowych.

Najważniejsza zmiana z punktu widzenia praktyka: modele 8B i 70B Llama 3.x zaczęły osiągać jakość, która dla wielu zadań jest zupełnie wystarczająca, by zastąpić zamknięte API w aplikacjach wewnętrznych. To otwiera drogę do szerokiego wykorzystania Llama w firmach średniej i dużej wielkości.

Dostępne rozmiary i typowe zastosowania w organizacji

Llama występuje w kilku wariantach rozmiarowych. Ich dobór można zgrubnie mapować na typowe scenariusze:

• Llama 3.x 7B/8B – lokalny asystent dla zespołów, proste RAG w działach wsparcia, podsumowywanie dokumentów, generowanie maili, pierwsza linia wsparcia dla deweloperów.
• Llama 3.x 13B–34B (gdzie dostępne) – bardziej wymagające Q&A, praca na dłuższych dokumentach, lepsze rozumienie kontekstu, generowanie kodu w bardziej złożonych scenariuszach.
• Llama 3.x 70B – zadania wymagające wysokiej jakości odpowiedzi: analizy prawne, raporty zarządcze, generowanie rozbudowanej dokumentacji technicznej, asystenci dla klientów zewnętrznych.

Licencjonowanie Llama a projekty komercyjne

Meta udostępnia Llama na licencji zbliżonej do open source, ale z istotnymi warunkami. Dla wdrożeń on‑premise nie chodzi tylko o technikę – trzeba też przeanalizować, czy licencja nie kłóci się z modelem biznesowym firmy.

Kilka kluczowych punktów, które zwykle sprawdza dział prawny:

• Próg przychodowy – w przypadku Llama istnieją zapisy wymagające dodatkowych uzgodnień dla bardzo dużych podmiotów (np. powyżej określonego poziomu przychodów). Dla większości średnich firm nie jest to bariera, ale korporacje muszą to przejść świadomie.
• Użycie do treningu innych modeli – licencja z reguły ogranicza wykorzystanie Llama jako materiału treningowego dla konkurencyjnych modeli. Dla typowego wdrożenia (inferencja + ewentualny fine‑tuning na własne potrzeby) nie ma to znaczenia, lecz dla vendorów AI już tak.
• Reselling i usługi oparte na Llama – jeśli firma buduje produkt SaaS z Llama pod spodem i sprzedaje go szerokiemu rynkowi, zakres licencji trzeba czytać bardzo dokładnie i często skonsultować z Meta.

W większości projektów „LLM jako komponent wewnętrzny” (asystenci pracowników, RAG na dokumentach, wyszukiwarki semantyczne) licencja Llama jest akceptowalna i nie wymaga dodatkowych zgód. Problem zaczyna się dopiero przy budowaniu własnej platformy LLM jako usługi dla osób trzecich.

Fine‑tuning i adaptery: jak dopasować Llama do własnej domeny

Surowa Llama 3.x jest mocna ogólnie, ale w poważnych wdrożeniach biznesowych i tak dochodzi etap dopasowania modelu. W praktyce typowy scenariusz to nie pełen fine‑tuning, tylko lekkie dostrajanie:

• LoRA / QLoRA – najczęściej używana technika adapterów. Aktualizujemy niewielki podzbiór wag, trzymając resztę modelu w spokoju. Zużycie VRAM jest wtedy zdecydowanie niższe, a efekt często wystarczający.
• Instruction tuning – model uczy się, jak odpowiadać w ramach konkretnej roli: asystent księgowy, konsultant HR, agent helpdesku. Zbiór danych może mieć kilkanaście–kilkadziesiąt tysięcy przykładów dialogów.
• Dopasowanie do stylu firmy – ton komunikacji, zakazane odpowiedzi, preferowane zwroty. To można częściowo osiągnąć prompt engineeringiem, ale przy większej skali lepiej zamknąć to w samym modelu.

Przykładowy przepływ w średniej firmie wygląda tak: wybór Llama 3.1 8B jako bazy, zebranie 5–10 tys. par pytanie–odpowiedź z działu wsparcia, lekkie dostrojenie QLoRA na jednym GPU 48–80 GB i wdrożenie modelu z RAG na bazie wiedzy firmy. Z punktu widzenia użytkownika różnica jakościowa względem surowej Llama jest zwykle bardzo wyraźna.

Mistral i spółka – lekkie, szybkie modele do biznesu

Ekosystem Mistral: od 7B do Mixtral

Francuski Mistral AI postawił od początku na efektywność. Modele są kompaktowe, dobrze zoptymalizowane i w wielu benchmarkach wypadają powyżej swojej „wagi parametrycznej”. Dla wdrożeń on‑premise ma to znaczenie, bo oznacza mniejszy klaster przy zachowaniu sensownej jakości.

Najczęściej spotykane modele z rodziny Mistral:

• Mistral 7B / 7B Instruct – kompaktowy model do ogólnych zadań, sprawny w Q&A, prostym kodzie, streszczeniach. Dobrze działa na pojedynczej karcie 24–40 GB, a po quantyzacji także na słabszym sprzęcie.
• Mixtral 8x7B / 8x22B – mixture‑of‑experts (MoE): fizycznie większy model, ale przy jednej inferencji aktywna jest tylko część ekspertów. To daje połączenie jakości większego modelu z kosztem zbliżonym do średniego.
• Mistral Nemo, Codestral i kolejne warianty – modele wyspecjalizowane, np. pod kod lub krótkie odpowiedzi. Dobre, gdy LLM ma być głównie narzędziem deweloperskim.

W praktyce Mistral 7B to częsty „pierwszy wybór” tam, gdzie budżet GPU jest minimalny, a firma chce szybko zobaczyć prototyp lokalnego asystenta. Mixtral 8x7B bywa sensowną alternatywą dla monolitycznych modeli 30B+, jeśli architektura klastra obsłuży MoE (komunikacja między ekspertami, odpowiedni runtime).

Licencja Mistral: otwartość z kilkoma gwiazdkami

Modele Mistral są udostępniane na różnych licencjach (Apache 2.0, własne warianty), co ma realne skutki przy wdraŜaniu. Ogólnie:

• Modele open‑weight (np. Mistral 7B, Mixtral 8x7B) – można je hostować lokalnie i komercyjnie wykorzystywać, o ile wypełnione są warunki licencji. Dla większości klasycznych wdrożeń B2B jest to wystarczające.
• Dodatkowe ograniczenia przy budowaniu usług konkurencyjnych (np. API podobne do Mistral AI). Zespół prawny powinien to osobno przeanalizować, gdy firma planuje platformę LLM dla innych podmiotów.

W standardowym scenariuszu: model na własnym GPU, dostępny tylko dla pracowników lub w ramach produktu, który nie jest „czystym API LLM” – licencje Mistral nie są blokadą.

Mistral w praktyce on‑prem: kiedy wybrać zamiast Llama

Wybór między Llama a Mistral często wynika nie z „wyniku w benchmarku”, lecz z warunków brzegowych projektu:

• Mało pamięci GPU – Mistral 7B i jego quantyzowane warianty potrafią działać płynnie tam, gdzie Llama 8B jest już ciasna. Dla małych zespołów IT to realna różnica.
• Preferencje językowe – Llama 3.x jest bardzo mocna w wielu językach, ale niektóre wersje Mistral dobrze radzą sobie z europejskimi językami „szerokiego użycia”. W konkretnych domenach (np. prawo, finanse) i tak trzeba testować na własnych danych.
• Szybkie prototypowanie – Mistral inwestuje sporo w gotowe integracje (vLLM, TGI, OpenAI‑compatible server). Jeśli zespół korzysta z tych runtime’ów, przepięcie z chmurowego API Mistral na lokalny model bywa banalne.

Przykładowo: zespół devops w firmie produkcyjnej postawił Mixtral 8x7B na dwóch kartach 80 GB z vLLM i wystawił interfejs kompatybilny z OpenAI. Aplikacje, które wcześniej uderzały w zewnętrzne API, przełączono niemal wyłącznie zmieniając URL i klucz – bez przepisywania logiki.

Inne znaczące open‑source LLM‑y do on‑prem: Qwen, DBRX, Phi, lokalne GPT‑y

Qwen: ofensywa z Chin

Modele Qwen (grupa Alibaba) stały się jednym z najciekawszych ekosystemów poza Llama i Mistral. Dostępne są w wielu rozmiarach (od 0.5B do 110B), z wariantami base, instruct, a także wyspecjalizowanymi modelami do kodu czy wizji.

Kilka cech istotnych dla wdrożeń on‑premise:

• Szerokie spektrum rozmiarów – Qwen‑1.5 4B / 7B nadają się do lekkich asystentów, Qwen‑14B / 32B do poważniejszych zadań analitycznych, Qwen‑72B i większe – gdy priorytetem jest maksymalna jakość.
• Wersje wielojęzyczne – modele są mocno trenowane na chińskim i angielskim, ale sensownie radzą sobie też z innymi językami. Dla firm działających w regionie APAC Qwen bywa naturalnym wyborem.
• Przyjazna licencja – wiele wariantów Qwen jest udostępnionych na licencjach zezwalających na komercyjne użycie, z ograniczeniami podobnymi do innych modeli big‑techowych; szczegóły trzeba jednak każdorazowo weryfikować.

Qwen zwraca też uwagę świetnym stosunkiem jakości do rozmiaru. W licznych testach Qwen‑1.5 7B wypada porównywalnie lub lepiej niż starsze modele 13B przy mniejszym zużyciu VRAM.

DBRX: model open‑source o ambicjach „enterprise”

DBRX od Databricks to przykład modelu, który od razu celuje w zastosowania korporacyjne. Główne założenia: dobra jakość rozumowania, stabilność i integracja z narzędziami data‑engineeringowymi.

Kilka aspektów, które wyróżniają DBRX:

• Architektura MoE – podobnie jak Mixtral, DBRX wykorzystuje mixture‑of‑experts, dzięki czemu część wag pozostaje nieaktywna podczas pojedynczej inferencji. Pozwala to utrzymać koszty na rozsądnym poziomie przy wysokiej jakości.
• Silna integracja z ekosystemem Databricks – dla organizacji, które już używają Lakehouse, Delta Lake i Spark, wdrożenie DBRX do zadań typu RAG na hurtowniach danych bywa prostsze niż w przypadku innych modeli.
• Nastawienie na governance – dokumentacja i tooling są projektowane z myślą o audytowalności, logowaniu, śledzeniu eksperymentów i kontroli wersji, co ułatwia rozmowy z działami ryzyka i compliance.

DBRX najlepiej czuje się na większych klastrach GPU. Jeśli firma dopiero zaczyna przygodę z LLM‑ami i ma jeden serwer z pojedynczą kartą, ten model nie będzie pierwszym wyborem. Dla dużych zespołów data/ML, które chcą zintegrować LLM bezpośrednio z jeziorem danych, może być jednak naturalnym kandydatem.

Phi: mały model o dużym ego

Rodzina Phi od Microsoftu (Phi‑2, Phi‑3 w różnych rozmiarach) to podręcznikowy przykład SLM‑u. Modele 3B–7B potrafią zaskoczyć jakością, szczególnie w zadaniach logicznych i kodowaniu, przy bardzo ograniczonym śladzie sprzętowym.

Dlaczego Phi jest interesujący dla on‑premise?

• Działanie na słabym sprzęcie – quantyzowany Phi‑3 Mini mieści się na jednej karcie 8–12 GB, często też na CPU z akceptowalnym czasem odpowiedzi dla prostych zadań.
• Użycie w aplikacjach mobilnych i edge – mały ślad pamięciowy i rozsądna jakość powodują, że Phi pojawia się w scenariuszach, gdzie inferencja odbywa się bliżej użytkownika (lokalnie na urządzeniu, w mikrousługach na brzegu sieci).
• Dobre dopasowanie do RAG – model nie musi wiedzieć wszystkiego; świetnie działa jako „silnik językowy” nad dobrze przeszukaną bazą wiedzy.

W firmach, które chcą zbudować dziesiątki małych agentów (np. w wewnętrznych narzędziach low‑code), Phi bywa ciekawszym rozwiązaniem niż duże LLM. Zamiast jednego masywnego modelu dla wszystkich przypadków użycia, można wdrożyć kilka wyspecjalizowanych instancji Phi, każdą z własnym kontekstem.

Lokalne GPT‑y i modele zamknięte z opcją on‑prem

Oprócz „czystych” open‑source’owych LLM‑ów są jeszcze modele zamknięte, które da się uruchomić w infrastrukturze klienta, lecz nie da się ich swobodnie modyfikować. Przykłady:

• Azure OpenAI on‑prem / „air‑gapped” – wybrane instancje GPT‑4/4.1/4o uruchomione w wydzielonej infrastrukturze w ramach chmury lub w modelu hybrydowym. Wymagają umów enterprise, ale rozwiązują część problemów compliance.
• Anthropic Claude w wariantach prywatnych – niekiedy oferowane w modelach zbliżonych do dedykowanej instancji, choć pełne on‑prem nie jest jeszcze standardem.

Tych modeli nie można nazwać open source, bo dostęp do wag bywa ograniczony lub żaden. Z punktu widzenia działu prawnego i bezpieczeństwa są jednak dla wielu organizacji bliższe on‑prem niż klasyczne publiczne API. Przy porównywaniu z Llama czy Mistral trzeba więc uwzględnić nie tylko otwartość kodu, lecz także miejsce i sposób inferencji.

Jak wybrać model do własnej infrastruktury: praktyczne kryteria

Parametry infrastruktury: VRAM, przepustowość, budżet energetyczny

Pierwszy filtr to twarde ograniczenia sprzętowe. Jeśli wiadomo, że firma ma do dyspozycji dwa serwery z kartami 24 GB, to wybór 70B bez quantyzacji odpada z definicji. Przy ocenie:

• VRAM na jedną instancję – określa, jaki rozmiar modelu w ogóle się zmieści. Approx: LLM 7B w 4‑bitach z kontekstem 8k zwykle wejdzie w 8–12 GB VRAM; 13B w 4‑bitach – w 16–24 GB; 70B wymaga już wielu kart.
• Przepustowość pamięci i interconnect – NVLink/InfiniBand mocno poprawiają skalowanie modeli większych niż pojedynczy GPU. Bez tego duże modele będą działały, ale wolno.

Wielkość modelu vs. charakter obciążenia

Sam fakt, że model „się mieści” na GPU, nie oznacza jeszcze, że jest sens go używać. Drugi filtr to profil ruchu i typ zadań:

• Wysoka równoległość, proste zapytania – chatbot helpdeskowy, krótkie podsumowania, proste klasyfikacje. Tu częściej wygrywają modele 3B–8B, bo liczy się liczba żądań na sekundę, a nie absolutne maksimum jakości.
• Mniejsza liczba żądań, złożone zadania – generowanie dłuższych dokumentów, zaawansowane analizy, refaktoryzacja kodu. W takich scenariuszach można zaakceptować niższe QPS, a postawić na 14B–70B.
• Obciążenie szczytowe vs. średnie – jeśli system ma krótkie „piki” (np. raporty generowane raz dziennie), lepiej mieć mniejszy model, ale dobrze zintegrowany z batchowaniem i kolejkowaniem niż przewymiarowany kolos, który większość dnia się nudzi.

W praktyce często kończy się na dwupoziomowej architekturze: mały, tani model obsługuje większość prostych pytań, a trudniejsze przypadki eskaluje do większego LLM lub do człowieka.

Bezpieczeństwo, prywatność i klasy danych

Przy wyborze modelu do on‑prem duże znaczenie ma nie tylko technologia, lecz także profil danych, które będą przez ten model „przepływać”. Dobrze jest jawnie skatalogować klasy danych:

• Dane publiczne – np. dokumentacja produktowa, instrukcje obsługi.
• Dane wewnętrzne niejawne – polityki firmowe, wewnętrzne procedury.
• Dane wrażliwe/prawnie chronione – dane osobowe, informacje medyczne, tajemnice przedsiębiorstwa.

Jeśli model ma mieć kontakt z trzecią kategorią, lista kandydatów się zawęża:

• Model musi działać w pełni w obrębie sieci kontrolowanej przez organizację (on‑prem lub prywatna chmura), bez wysyłania promptów do podmiotów zewnętrznych.
• Przydaje się łatwość audytu i logowania: możliwość zapisu promptów, odpowiedzi, metadanych, a także wersji modelu, na którym zadziałała inferencja.
• Dział ryzyka zwykle oczekuje jasnej historii pochodzenia modelu (dataset card, model card, opis procesu trenowania), aby oszacować ryzyka prawne.

Dla części organizacji kompromisem jest użycie modelu zamkniętego z gwarancją, że wszystkie dane są przetwarzane w ściśle określonym regionie lub w wydzielonej infrastrukturze (np. air‑gapped cluster u dostawcy).

Języki, domena i możliwość dostrojenia

Jeśli projekt ma ostrą specyfikę domenową (prawo, medycyna, przemysł), ogólny benchmark przestaje być głównym kryterium. To, czy model „rozumie” polski, niemiecki czy czeski, jest istotne, lecz równie ważne jest:

• Zachowanie w zadaniach domenowych – np. poprawne rozpoznawanie terminologii z umów, kodów PKD, ICD, nazw leków, skrótów używanych tylko w danym sektorze.
• Odporność na halucynacje – zamiast ogólnej kreatywności liczy się skłonność do „przyznania się do niewiedzy” albo odwołania do zewnętrznego źródła (RAG).
• Możliwość fine‑tune’u – dostępność narzędzi i licencji pozwalających na dalsze trenowanie na danych wewnętrznych.

Modele takie jak Llama, Mistral, Qwen czy Phi są stosunkowo przyjazne dla fine‑tune’u metodami LoRA/QLoRA. Przy wyborze warto więc sprawdzić, czy:

• istnieją już dobre, przygotowane instancje domenowe (np. do kodu, medycyny),
• model ma aktywną społeczność publikującą adaptery, skrypty szkoleniowe i przykłady konfiguracji.

Częstą praktyką jest wzięcie średniego modelu (7B–14B), lekkie dostrojenie go do wewnętrznej terminologii i połączenie z RAG. Daje to zaskakująco dobry efekt przy niewielkich kosztach.

Ekosystem, tooling i krzywa uczenia zespołu

Przy technicznie zbliżonych modelach zwykle wygrywa ten, dla którego zespół ma lepsze narzędzia i kompetencje. Kilka pytań porządkuje sytuację:

• Czy model działa „od ręki” w wybranym runtime (vLLM, TGI, ollama, LM Studio, Jan)?
• Czy są gotowe kontenery referencyjne (Docker, Helm chart), które można szybko uruchomić na Kubernetesie lub bare‑metal?
• Czy istnieją SDK i klienci w językach używanych w organizacji (Python, Java, .NET, JS)?
• Czy vendor/community oferuje sensowną dokumentację i przykładowe playbooki (monitoring, skalowanie, upgrade’y modeli)?

Zespół, który ma doświadczenie z ekosystemem Databricks, szybciej „posadzi” DBRX niż dowolny inny model; zespół przyzwyczajony do API OpenAI łatwiej przełączy się na Llama/Mistral wystawione przez vLLM z kompatybilnym interfejsem.

Model kosztów: CAPEX, OPEX i TCO wdrożenia

Z perspektywy finansów mniej istotna jest liczba parametrów, bardziej – całkowity koszt posiadania (TCO). Ten zaś zależy od kilku składników:

• CAPEX sprzętowy – zakup GPU, serwerów, przełączników, pamięci masowej.
• OPEX infrastrukturalny – energia, chłodzenie, utrzymanie, wymiany sprzętu.
• Koszt zespołu – kompetencje MLOps, SRE, inżynierów danych, czas spędzony na strojenia i debugowaniu.
• Koszty licencyjne – ewentualne opłaty za komercyjne warianty modeli, rozszerzone wsparcie, rozwiązania hybrydowe.

Jeśli organizacja nie ma jeszcze zaplecza w postaci własnej serwerowni z GPU, często opłacalniejszy jest model hybrydowy: krótkoterminowo wynajęte GPU na czas eksperymentów i trenowania, a dopiero później inwestycja w stałą infrastrukturę albo długoterminowe rezerwacje w chmurze.

Przykładowy wzorzec: firma przez kilka miesięcy testuje 3–4 modele w chmurze, liczy średni koszt inferencji na zapytanie i dopiero na tej podstawie decyduje, czy budować własny klaster i który model tam finalnie uruchomić.

Aktualne trendy techniczne: kontekst, kv‑cache, zarządzanie pamięcią i prędkością

Rosnące okna kontekstu: 4k, 8k, 128k i dalej

Jednym z najszybciej rozwijających się obszarów jest długość kontekstu. LLM‑y z 2k–4k tokenów stopniowo odchodzą do lamusa, standardem stają się:

• 8k–16k tokenów – wygodne dla większości klasycznych zastosowań biurowych.
• 32k–128k tokenów – analizy dokumentów, długie wątki czatu, przetwarzanie logów.
• „Million‑token context” – wczesne próby pracy z ogromnymi, strumieniowymi wejściami (logi, repozytoria kodu, dane telemetryczne).

Rozszerzenie kontekstu zwiększa użyteczność, ale ma też skutki uboczne dla on‑prem:

• wzrasta zapotrzebowanie na pamięć (więcej pozycji w kv‑cache),
• wydłuża się czas pierwszej odpowiedzi, jeśli model musi „przetrawić” duży prompt,
• rosną wymagania co do przepustowości pamięci i interconnectu przy pracy wielogpu.

Większość nowych wersji Llama, Mistral, Qwen czy Phi wprowadza albo natywne długie konteksty, albo techniki do ich skutecznego rozszerzania (sliding window, attention sinking, dynamiczne skracanie historii).

KV‑cache: fundament wydajnej inferencji

Podczas generowania dłuższych odpowiedzi największym kosztem nie jest sama liczba parametrów, lecz rosnący koszt atencji dla kolejnych tokenów. Tu w grę wchodzi kluczowa optymalizacja – kv‑cache.

W uproszczeniu: zamiast na każdym kroku ponownie przeliczać wewnętrzne reprezentacje (klucze i wartości) wszystkich wcześniejszych tokenów, model przechowuje je w pamięci i dokleja tylko nowy fragment. Ma to kilka konsekwencji:

• znacząco przyspiesza generowanie, zwłaszcza przy dłuższych odpowiedziach,
• podnosi zużycie VRAM na sesję – im dłuższa rozmowa, tym więcej pamięci zajmuje cache,
• wymusza strategie zarządzania „historią” – co i kiedy wyrzucać z pamięci.

Nowoczesne runtime’y (vLLM, TGI, Text Generation Inference, TensorRT‑LLM) wprowadzają coraz bardziej zaawansowane algorytmy:

• PagedAttention – traktowanie kv‑cache jak wirtualnej pamięci stronowanej, co ogranicza fragmentację i poprawia wykorzystanie VRAM.
• Shared kv‑cache między wątkami i żądaniami – ważne przy batchowaniu i równoległej obsłudze wielu użytkowników.
• Efektywne czyszczenie sesji – natychmiastowe zwalnianie pamięci po zakończeniu rozmowy, co ma znaczenie zwłaszcza w środowiskach multi‑tenant.

Przy projektowaniu on‑prem co najmniej równie ważne jak sam wybór modelu jest dobranie runtime’u obsługującego te optymalizacje. Ten sam model potrafi działać kilkukrotnie szybciej lub wolniej, w zależności od implementacji kv‑cache.

Batchowanie, kolejkowanie i SLA odpowiedzi

Aby utrzymać sensowne koszty, trzeba maksymalnie wykorzystać GPU. Oznacza to batchowanie wielu zapytań w jednym przebiegu modelu. Technicznie jest to złożone:

• zapytania różnią się długością, więc trzeba je wyrównać (padding) lub stosować algorytmy mieszania.
• użytkownicy oczekują interaktywnej odpowiedzi, a nie czekania, aż batch się zapełni.

Nowoczesne serwery LLM stosują dynamiczne batchowanie: żądania są krótkotrwale odkładane do kolejki, a następnie łączone tak, aby minimalizować średni czas oczekiwania przy maksymalnym wykorzystaniu GPU. W praktyce konfiguracja:

• maksymalnej wielkości batcha,
• maksymalnego czasu oczekiwania w kolejce,
• priorytetów dla poszczególnych typów zadań

jest jednym z głównych pokręteł, które decydują o tym, czy system jest „odczuwany” jako szybki. Przykładowo: chatbot pracowników HR dostaje wyższy priorytet niż batchowa analiza logów, mimo że oba zadania korzystają z tego samego modelu.

Quantyzacja: 8‑bit, 4‑bit i mniejsze

Quantyzacja to technika redukcji precyzji wag i/lub aktywacji, tak aby model zajmował mniej pamięci i działał szybciej. Dla on‑prem jest kluczowa, bo:

• umożliwia uruchomienie większych modeli na tańszym sprzęcie,
• zwiększa gęstość obciążenia na GPU (więcej równoległych sesji),
• czasem pozwala przejść z GPU na CPU w scenariuszach o niskich wymaganiach czasowych.

Popularne schematy to m.in. INT8, INT4 (np. GPTQ, AWQ, GGUF w świecie llama.cpp). Dobrze dobrana quantyzacja potrafi ograniczyć spadek jakości do poziomu niemal niezauważalnego w zastosowaniach biznesowych, przy kilkukrotnej redukcji wymagań VRAM.

Trzeba jednak liczyć się z kilkoma zjawiskami:

• Heterogeniczna jakość – niektóre modele znoszą quantyzację lepiej niż inne; bywa, że 4‑bit na jednym modelu jest praktycznie „bezstratny”, a na innym psuje logikę i kod.
• Wpływ na fine‑tune – klasyczny trening wymaga zwykle pełnej precyzji lub przynajmniej mieszanej (mixed precision); quantyzacja bywa stosowana dopiero po treningu.
• Optymalizacja pod konkretny runtime – quantyzowany model w formacie GGUF może osiągać świetne wyniki z llama.cpp, ale niekoniecznie w TensorRT‑LLM lub vLLM.

Przy planowaniu wdrożenia sensowne jest przygotowanie dwóch–trzech wariantów quantyzacji tego samego modelu i zmierzenie realnych różnic: czasu odpowiedzi, przepustowości, zużycia pamięci oraz jakości odpowiedzi na typowych zadaniach.

Strukturyzacja długiej historii: buforowanie, skracanie, RAG

Najczęściej zadawane pytania (FAQ)

Co to jest open‑source LLM i czym różni się od zamkniętych modeli typu OpenAI czy Anthropic?

Open‑source LLM to duży model językowy, którego wagi i kod inferencji są publicznie dostępne na licencjach pozwalających na własne wdrożenia, modyfikacje i często komercyjne użycie. Przykłady to Llama 3, Mistral, Mixtral, Qwen, DBRX czy Phi.

W przeciwieństwie do zamkniętych modeli (dostępnych wyłącznie przez API dostawcy), open‑source można uruchomić na własnej infrastrukturze, fine‑tunować pod swoje dane i łączyć z dowolnymi systemami wewnętrznymi. Zamknięte API zwykle oferuje nieco wyższą średnią jakość i mniej kłopotów operacyjnych, ale kosztem mniejszej kontroli nad kosztami, danymi i zależnością od jednego dostawcy.

Kiedy opłaca się wdrażać LLM on‑premise zamiast korzystać z chmurowego API?

On‑premise ma sens przede wszystkim przy dużej, powtarzalnej skali użycia (asystent dla setek czy tysięcy pracowników, automatyzacja procesów, intensywne RAG), gdzie koszt tokenów w chmurze przewyższa w pewnym momencie koszt serwera GPU i jego utrzymania. Kluczowa jest też wrażliwość danych – w bankowości, medycynie, administracji czy R&D często nie można akceptować wypływu danych poza ściśle kontrolowaną infrastrukturę.

Chmurowe API bywa lepszym wyborem przy krótkich pilotażach, małej skali, braku zespołu od infrastruktury GPU albo gdy biznes wymaga modeli absolutnie topowych jakościowo (np. do zaawansowanego content marketingu czy analiz multimodalnych), których odpowiedników open‑source jeszcze nie ma.

Jakie są główne powody, dla których firmy przechodzą na open‑source’owe LLM‑y on‑premise?

Najczęściej powtarzają się cztery grupy motywacji: kontrola kosztów (przy stałym, dużym wolumenie zapytań), prywatność i poufność danych, wymagania regulacyjne oraz unikanie vendor lock‑in. Dodatkowo ważna jest elastyczność techniczna – możliwość własnego fine‑tuningu, customowych pipeline’ów RAG i niskopoziomowych integracji z systemami legacy.

Przykładowo: bank może zdecydować, że wszystkie zapytania dotyczące danych klientów obsługuje lokalny model Llama 3 8B na własnym serwerze GPU, a tylko sporadyczne zadania kreatywne marketingu kierowane są do zamkniętego API w chmurze.

Czym różni się „prawdziwe” on‑premise od hostowania LLM na instancjach GPU w chmurze?

„Prawdziwe” on‑premise oznacza własne serwery (np. z GPU) w data center należącym do organizacji lub w wydzielonej serwerowni współdzielonego DC. Firma kontroluje fizyczny dostęp, segmentację sieci, logi i pełen łańcuch przetwarzania danych. To daje najwyższy poziom kontroli, ale wymaga inwestycji w sprzęt i kompetencje operacyjne.

Hostowanie na instancjach GPU w chmurze (IaaS) to pośrednia opcja: model jest zarządzany przez zespół firmy, ale stoi na infrastrukturze AWS/Azure/GCP/OVH itd. Łatwiej się skaluje, część obowiązków administracyjnych przejmuje dostawca, jednak nadal obowiązują jego zasady, jurysdykcja i ograniczenia. Z perspektywy architektury aplikacji oba warianty często traktuje się podobnie jako „model lokalny”, bo kluczowa jest własna kontrola nad instancją, a nie fizyczne położenie serwera.

Jak dobrać rozmiar modelu LLM (7B, 13B, 70B) do wdrożenia on‑premise?

Rozmiar modelu (liczba parametrów) przekłada się bezpośrednio na wymagania sprzętowe, koszt i opóźnienia. Modele 3B–8B zwykle mieszczą się na pojedynczym, względnie tanim serwerze GPU lub nawet na CPU po quantyzacji, nadając się do prostszych Q&A, asystentów wewnętrznych i lekkiego RAG. Modele 13B–34B dają lepszą jakość i zrozumienie kontekstu kosztem wyższych wymagań (1–2 mocne GPU). 70B+ to już klasa „ciężka” – wymagają klastra GPU z szybką siecią.

Jeśli projekt wymaga krótkich czasów odpowiedzi i obsługi dużej liczby równoległych użytkowników, lepiej sprawdza się dobrze dostrojony, mniejszy model uruchomiony blisko aplikacji, niż bardzo duży model dławiący się na przeciążonym klastrze. Zwykle sensowny proces doboru to: zacząć od 7B/8B, zmierzyć jakość i dopiero przy realnej potrzebie skakać wyżej.

Czym jest SLM (Small Language Model) i kiedy lepszy jest mały model niż duży LLM?

SLM to po prostu mniejszy model językowy (zwykle 1B–7B parametrów), zaprojektowany pod kątem wydajności, niskich kosztów i lokalnych wdrożeń, a nie maksymalnej możliwej jakości na ogólnych benchmarkach. Do tej kategorii należą m.in. Phi‑3, mniejsze warianty Llama 3.2 czy Qwen‑1.5 4B.

Małe modele wygrywają tam, gdzie priorytetem jest szybkość (sub‑sekundowe odpowiedzi), ograniczona infrastruktura (mało GPU, edge, urządzenia brzegowe) lub silne zawężenie domeny przy dobrym RAG. Jeśli aplikacja odpowiada tylko na pytania o procedury wewnętrzne i ma dostęp do dobrze zindeksowanych dokumentów, to dobrze zestrojony SLM często da wystarczającą jakość przy ułamku kosztu dużego LLM.

Czy lepiej postawić wszystko na open‑source on‑premise, czy używać hybrydy z chmurą?

W praktyce najczęściej sprawdza się podejście hybrydowe. Open‑source’owy model on‑premise obsługuje zapytania o dane wrażliwe, powtarzalne zadania i scenariusze, w których liczy się przewidywalny koszt. Równolegle wybrane procesy można kierować do zamkniętych modeli w chmurze – np. tam, gdzie kluczowa jest najwyższa dostępna jakość, specyficzne funkcje (zaawansowana wizja, mowa) lub gdy obciążenie jest bardzo zmienne i trudno je z góry oszacować.

Takie połączenie ogranicza ryzyko vendor lock‑in, pozwala stopniowo rozwijać własne kompetencje on‑premise, a jednocześnie korzystać z innowacji dostawców chmurowych tam, gdzie daje to realną przewagę biznesową.

Źródła

• Llama 3 Model Card. Meta AI (2024) – Parametry, zastosowania i ograniczenia modeli Llama 3/3.1/3.2
• Mistral 7B Technical Report. Mistral AI (2023) – Opis architektury, wydajności i zastosowań Mistral 7B
• Qwen Technical Report. Alibaba Cloud (2023) – Parametry i wyniki benchmarków rodziny modeli Qwen