Mały wyspecjalizowany model AI vs duży LLM

Firma z branży finansowej pyta, czy może zastąpić duży model ogólny mniejszym, wyspecjalizowanym, i zaoszczędzić 70% kosztu inferencji. Firma logistyczna pyta odwrotnie: czy mały model poradzi sobie z zapytaniami klientów w czterech językach. Obydwa pytania brzmią jak kwestia techniczna, ale odpowiedź zależy przede wszystkim od struktury zadań, wolumenu wywołań i wymagań regulacyjnych.

Ten artykuł systematyzuje wybór. Nie ma tu jednej poprawnej odpowiedzi. Jest za to rama, dzięki której podejmiesz decyzję z danymi, nie z przeczuciem.

Parametry modelu to tylko jedna oś. W 2026 r. granice przesunęły się: model 7B po agresywnej kwantyzacji Q4 mieści się w 4–5 GB VRAM i działa na laptopie. Model 70B skwantyzowany do Q4 wymaga ~40 GB VRAM. Model klasy GPT-4 to setki miliardów parametrów, dostępny wyłącznie przez API chmurowe.

Ważniejsza niż liczba parametrów jest gęstość specjalizacji: ile danych domenowych, w jakiej jakości i jaką techniką weszło w wagi. Model 7B po dobrym fine-tuningu na wyspecjalizowanym korpusie medycznym może w zadaniach klasyfikacji klinicznej pobić model 70B ogólny. Nie pobije go w swobodnym rozumowaniu poza domeną.

Trzy wymiary, które naprawdę definiują wybór:

• Koszt na token: mniejszy model na własnej infrastrukturze to ułamek kosztów API dużego modelu chmurowego.
• Latencja: model 7B odpowiada 3–10× szybciej niż 70B przy tej samej warstwie sprzętowej.
• Jakość na zadaniu: zależy od stopnia specjalizacji, nie od rozmiaru parametrów per se.

Wąskie, powtarzalne zadania produkcyjne. Klasyfikacja intencji w obsłudze klienta, tagowanie dokumentów, OCR post-processing, anonimizacja PII: to zadania z ograniczoną przestrzenią wyjść. Model 7B wytrenowany na Waszych danych i Waszych etykietach osiągnie F1 > 0,90 na tych zadaniach, gdzie model ogólny 70B osiągnie 0,85 przy pięciokrotnie wyższym koszcie.

Wysoki wolumen wywołań. Gdy system wykonuje 500 000 wywołań miesięcznie na jednym zadaniu, różnica kosztów na token staje się linia budżetowa, nie abstrakcja. Mały model self-hosted na własnym GPU spłaca się w ciągu kilku miesięcy. Policz swój przypadek w kalkulatorze inferencji.

Wymagania data-residency i regulacje. AI Act, RODO i sektorowe regulacje bankowe często wymagają, żeby dane nie opuszczały Unii lub wewnętrznej infrastruktury firmy. Mały model self-hosted spełnia to wymaganie strukturalnie. Duże modele chmurowe wymagają szczegółowych umów DPA z dostawcą i audytu przepływów danych.

Deterministyczne wymagania formatu. Gdy wyjście musi mieć ściśle określoną strukturę (np. JSON Schema, XML dla systemu ERP) i model musi to utrzymywać przez dziesiątki tysięcy wywołań, mały model po fine-tuningu z structured output jest bardziej przewidywalny niż duży model ogólny z promptem.

Różnorodne, nieprzewidywalne zapytania. Asystent wewnętrzny dla pracowników, który odpowiada zarówno na pytania prawne, jak i techniczne, kadrowe i sprzedażowe, potrzebuje szerokiego rozumowania. Mały model wyspecjalizowany w jednej domenie będzie się mylił poza nią. Duży model ogólny obsługuje przekrój zapytań bez retreningu.

Wieloetapowe rozumowanie i agenci. Zadania wymagające planowania, dekompozycji na podzadania, korzystania z narzędzi (tool-use) i oceny własnych wyników: tutaj duże modele mają istotną przewagę. Modele 7B–13B w trybie agentowym często tracą kontekst po kilku krokach lub generują niepoprawne wywołania narzędzi.

Wielojęzyczność bez dodatkowego treningu. Model ogólny klasy 70B+ obsługuje kilkadziesiąt języków z wysoką jakością. Mały model wytrenowany na polskich danych obsłuży polski dobrze, ale angielski, niemiecki i ukraiński już nie na tym samym poziomie. Sprawdź wzorzec z wielojęzycznym asystentem AI.

Szybki start bez danych treningowych. Pilotaż można uruchomić w tygodnie z dużym modelem przez RAG i promptem. Mały wyspecjalizowany model wymaga zebrania danych, treningu i ewaluacji. Co to oznacza w praktyce, opisuje artykuł kiedy fine-tuning ma sens.

Większość firm nie powinna wybierać jednego rozmiaru modelu. Wzorzec routera modeli pozwala kierować ruch do właściwego modelu na podstawie złożoności zapytania:

1. Klasyfikator wstępny ocenia zapytanie: proste pytanie z katalogu FAQ, zapytanie wymagające rozumowania, czy zapytanie wykraczające poza domenę.
2. Prosty, tani model obsługuje powtarzalne zapytania (klasyfikacja, ekstrakcja danych, proste FAQ).
3. Duży model otrzymuje tylko te zapytania, które tego naprawdę wymagają: wieloetapowe rozumowanie, nieznane tematy, eskalacje.

Efekt: 60–80% ruchu trafia do taniego modelu, a jakość na trudnych zapytaniach nie spada. Koszt całkowity jest ułamkiem kosztu routowania wszystkiego do dużego modelu.

Router wymaga monitoringu: sprawdzaj, czy klasyfikator błędnie kieruje trudne zapytania do małego modelu (fałszywie proste) i czy eskalacje nie rosną ponad próg (sygnał dryfu).

Małe modele wyspecjalizowane mają inne profile ryzyka niż duże modele ogólne. Kilka faktów, które warto znać przed wdrożeniem:

Mały model po agresywnym fine-tuningu bywa mniej odporny na prompt injection niż duży model ogólny, który widział tysiące przykładów ataków w pretrainingu. Guardrails po stronie aplikacji (filtr wejścia, filtr wyjścia, human-gate dla akcji nieodwracalnych) są obowiązkowe niezależnie od rozmiaru modelu.

Mały model może nie rozumieć polecenia „nie wiem" równie dobrze jak duży. Jeśli zadano pytanie spoza domeny treningu, model może generować odpowiedź brzmiącą przekonująco, ale niepoprawną. Należy zaimplementować human-handoff: gdy pewność odpowiedzi spada poniżej progu, system eskaluje do człowieka zamiast halucynować.

Dla systemów wysokiego ryzyka według AI Act (Załącznik III: rekrutacja, scoring kredytowy, infrastruktura krytyczna) wymagana jest dokumentacja modelu, uzasadnialność decyzji i ślad audytowy, niezależnie od rozmiaru. Małe modele nie zwalniają z tych obowiązków; niekiedy trudniej je spełnić, gdy dokumentacja oryginalnego modelu bazowego jest skromniejsza niż dla dużych modeli chmurowych.

Małe modele self-hosted mają naturalną przewagę regulacyjną: dane nie opuszczają Waszej infrastruktury. Ale self-hosting to nie tylko serwer. Wymagania:

• Zarządzanie wersjami modelu: każdy checkpoint ze znacznikiem danych treningowych i wyników ewaluacji.
• Szyfrowanie w spoczynku i w tranzycie: wagi modelu to aktywa firmy, traktuj je jak kod źródłowy.
• Audyt dostępu: kto i kiedy uruchamiał inferencję, z jakimi danymi wejściowymi.
• Plan aktualizacji: mały model dryfuje względem rosnącej bazy faktów; ustal politykę retreningu lub uzupełnienia RAG.

Jeśli dane wejściowe zawierają dane osobowe, wykonaj DPIA przed wdrożeniem. Dotyczy to też małych modeli działających lokalnie. Fakt, że dane nie wychodzą na zewnątrz, nie zwalnia z obowiązku oceny ryzyka.

Przed podjęciem decyzji odpowiedz na pięć pytań:

1. Jak wąskie jest zadanie? Jedno zadanie, spójne wyjście: mały model. Wiele różnych zadań: duży model lub router.

2. Jaki jest miesięczny wolumen wywołań? Poniżej 50 000 wywołań miesięcznie różnica kosztów jest relatywnie mała. Powyżej 200 000 mały model self-hosted zaczyna się opłacać finansowo.

3. Czy masz dane treningowe? Bez co najmniej 500 jakościowych par wejście-wyjście mały model nie osiągnie potencjału. Sprawdź to w ocenie gotowości.

4. Jakie są wymagania latencji? Interakcja głosowa lub czat w czasie rzeczywistym wymaga < 500 ms. Przetwarzanie dokumentów w tle toleruje 3–10 sekund.

5. Jakie są wymagania regulacyjne? Data-residency, AI Act high-risk, RODO: wstępna analiza tych wymogów często przesądza wybór szybciej niż metryki techniczne.

Szablon odpowiedzi na te pytania znajdziesz w blueprint agenta lub omów swój przypadek przez kontakt.

Opisz swój przypadek użycia. Model oceni, czy mały wyspecjalizowany model, duży ogólny, czy router jest właściwym wyborem (playground: PII maskowane, zero retencji):

Nie. Mały model wyspecjalizowany w konkretnej domenie poradzi sobie lepiej niż ogólny duży model w tej jednej domenie, ale tylko w niej. Dla zadań poza domeną treningu jakość drastycznie spada. Dlatego decyzja o modelu powinna być decyzją o architekturze: jedno zadanie lub wzorzec routera dla wielu zadań.

Model 7B skwantyzowany do Q4 potrzebuje 4–6 GB VRAM i działa na karcie konsumenckiej RTX 3090 lub RTX 4090. Model 13B skwantyzowany wymaga 8–10 GB VRAM. To sprawia, że self-hosting małych modeli jest dostępny finansowo dla średnich firm. Szczegółowe zestawienia sprzętu zawiera artykuł lokalne LLM: jaki sprzęt i GPU.

Router wprowadza dodatkową warstwę architektury, ale przy dobrym projekcie koszt utrzymania jest niski. Kluczowe jest monitorowanie błędów routingu: gdy klasyfikator kieruje trudne zapytania do taniego modelu, jakość spada bez oczywistego alarmu. Minimalny monitoring to śledzenie współczynnika eskalacji i próbkowanie odpowiedzi małego modelu. Wzorzec monitoringu opisuje monitoring jakości agenta AI.

Dodaj guardrail wejściowy: classifier ocenia, czy zapytanie mieści się w domenie. Jeśli nie, kieruje do dużego modelu lub zwraca komunikat o braku kompetencji i eskaluje do człowieka (human-handoff). Nigdy nie polegaj wyłącznie na tym, że model „sam przyzna, że nie wie". Małe modele nie są w tym niezawodne.

Zacznij od pilota z dużym modelem przez RAG — to tygodnie, nie miesiące, i pozwala zebrać realne dane o wolumenie, typach zapytań i jakości odpowiedzi. Po 4–8 tygodniach masz dane do decyzji: czy ruch jest na tyle jednorodny, żeby opłacał się mały model, i czy wolumen uzasadnia inwestycję w self-hosting. Narzędzie kalkulator ROI pozwala przeliczyć scenariusze przed wejściem w projekt.