Jak dobrać model LLM do zadania: macierz rozmiar-koszt-opóźnienie

Regularnie widzimy ten sam wzorzec: firma podpina jeden duży model w chmurze do każdej operacji — od prostego sklejenia adresu po analizę umowy. Działa, dopóki rachunek jest mały. Potem ruch rośnie, opóźnienia się kumulują, a koszt skaluje się liniowo z liczbą zapytań. Problem prawie nigdy nie leży w tym, że model jest „za słaby”. Leży w tym, że ten sam model robi i pracę, do której wystarczyłby model dziesięć razy tańszy, i tę, która faktycznie wymaga mocy. Dobór modelu do zadania to najtańsza dźwignia, jaką ma się w architekturze — i najczęściej pomijana.

Każdy wybór modelu to negocjacja między trzema wielkościami, których nie da się maksymalizować naraz:

• Rozmiar (jakość) — większy model lepiej radzi sobie z niejednoznacznością, wieloetapowym rozumowaniem i długim kontekstem. Ale „lepiej” nie znaczy „potrzebnie lepiej” — przy zadaniu, które ma jedną poprawną odpowiedź, nadmiar mocy to zmarnowany budżet.
• Opóźnienie — większy model odpowiada wolniej. Przy czacie na żywo użytkownik czuje każdą sekundę; przy przetwarzaniu wsadowym w nocy opóźnienie jest bez znaczenia. To, gdzie zadanie działa, zmienia priorytet tej osi całkowicie.
• Koszt inferencji — w chmurze rośnie z liczbą tokenów wejścia i wyjścia oraz z klasą modelu; przy self-hostingu to amortyzacja sprzętu rozłożona na wolumen. Mały model to często różnica rzędu wielkości w rachunku jednostkowym.

Zasada, którą stosujemy: nie pytamy „który model jest najlepszy”, tylko „jaki jest najniższy próg jakości, przy którym zadanie nadal działa poprawnie” — i dobieramy najtańszy model powyżej tego progu.

Większość zadań biznesowych mieści się w kilku archetypach. Poniższa macierz to punkt wyjścia, nie wyrocznia — progi zależą od Waszych danych i wymaganej dokładności. Widełki kosztu są względne (mały model = baza 1×):

Praktyczna obserwacja z wdrożeń: dwa pierwsze wiersze — ekstrakcja i klasyfikacja — to często 60–80% wszystkich wywołań w typowym systemie. Jeśli całość idzie przez duży model, większość rachunku finansuje pracę, która nie potrzebuje tej mocy.

Mały model bywa traktowany jak gorszy wybór „na biedę”. To nieporozumienie. Mały model jest właściwym wyborem, gdy zadanie ma wąsko zdefiniowany cel i weryfikowalny wynik:

• Wynik ma sprawdzalną strukturę. Jeśli oczekujemy JSON-a o znanym schemacie, structured output plus walidacja łapie błędy niezależnie od rozmiaru modelu. Mały model + walidator + jedna naprawa daje wynik tańszy i często równie pewny co duży model bez walidacji.
• Domena jest wąska. Klasyfikacja zgłoszeń do 8 kategorii nie wymaga wiedzy o świecie — wymaga rozróżnienia 8 wzorców. Mały model dostrojony promptem robi to świetnie. Więcej w artykule o klasyfikacji i routingu zgłoszeń.
• Zadanie jest powtarzalne i wsadowe. Przetworzenie 50 tysięcy rekordów małym modelem zamiast dużym to różnica między rachunkiem do zaakceptowania a takim, który zabija projekt.

Gdzie mały model zawodzi: zadania wymagające wnioskowania z kilku przesłanek naraz, utrzymania spójności na długim dokumencie albo radzenia sobie z prawdziwą niejednoznacznością. Tam oszczędność na modelu zwraca się błędami, które ktoś musi naprawiać ręcznie. Granicę wyznacza się pomiarem, nie intuicją — patrz monitoring jakości agenta AI.

To pytanie o ekonomię i o dane, nie o ideologię. Oba mają sens — w różnych warunkach:

Przy małym lub zmiennym ruchu chmura wygrywa — brak kosztu wejścia, płacisz za to, czego używasz. Przy stałym, dużym obciążeniu albo wrażliwych danych self-hosting zaczyna wygrywać kosztowo i daje pewność, że dane nie opuszczają infrastruktury. Punkt przecięcia zależy od wolumenu, dlatego liczymy go na realnym obciążeniu, a nie na maksymalnym sprzęcie. Wątek danych osobowych rozwijamy w self-hosted LLM a RODO, a wybór bazy pod wyszukiwanie w jak wybrać bazę wektorową.

W praktyce większość dojrzałych wdrożeń jest hybrydowa: mały model lokalny do ekstrakcji i klasyfikacji (tani, prywatny, szybki), flagowy model w chmurze tylko do zadań, które tego naprawdę wymagają. O połączeniu tego z bazą wiedzy piszemy w firmowy GPT na bazie wiedzy.

Zamiast przypisywać model na sztywno, prowadzimy wszystkie wywołania przez jeden router LLM. To pojedyncze wejście do warstwy modeli, które dla każdego zadania decyduje, dokąd je skierować — i daje trzy rzeczy naraz:

1. Dobór modelu do zadania. Klasyfikacja idzie do małego modelu, analiza umowy do dużego. Decyzja jest deklaratywna (macierz zadanie→model), nie rozsiana po kodzie.
2. Fallback i degradacja. Gdy model docelowy jest niedostępny albo przeciążony, router schodzi na model zapasowy zamiast zwracać błąd użytkownikowi.
3. Telemetria i kontrola kosztu. Skoro wszystko przechodzi przez jeden punkt, mierzymy koszt i opóźnienie per zadanie, widzimy gdzie pieniądze realnie idą i możemy ustawić budżety oraz limity przeciążenia.

Router to też naturalne miejsce na maskowanie danych osobowych przed chmurą i na egzekwowanie reguły „structured output zawsze walidowany”. Bez tej warstwy każda zmiana modelu to przepisywanie kodu w wielu miejscach; z nią — zmiana jednej reguły. To dlatego router jest pierwszą rzeczą, którą stawiamy w każdym systemie opartym na wielu modelach, a nie dodatkiem na koniec.

Prościej na starcie, drożej w skali. Jeden duży model do każdej operacji daje rachunek rosnący liniowo z ruchem i wyższe opóźnienia tam, gdzie nie są potrzebne. Router dobierający model do zadania to zwykle największa pojedyncza oszczędność, bo przenosi 60–80% wywołań na model rzędu wielkości tańszy.

Po pomiarze, nie po przeczuciu. Zbieramy zestaw realnych przykładów zadania, puszczamy je przez mały i duży model i porównujemy dokładność na ślepej próbce. Jeśli mały model trzyma próg jakości przy zadaniu o weryfikowalnym wyniku (ekstrakcja, klasyfikacja), wystarcza — a różnica w koszcie i opóźnieniu jest po jego stronie.

Nie. Przy małym lub zmiennym wolumenie chmura jest tańsza, bo nie ma kosztu wejścia — sprzęt do self-hostingu musi się amortyzować na ruchu. Self-hosting wygrywa przy stałym dużym obciążeniu albo gdy dane nie mogą opuścić firmy. Punkt przecięcia liczy się na realnym wolumenie, nie na maksymalnym sprzęcie.

Najprościej deklaratywnie: macierz zadanie→model przypisuje każdy typ zadania do klasy modelu, a router czyta typ z metadanych wywołania. Bardziej zaawansowane warianty oceniają trudność konkretnego zapytania i eskalują do większego modelu tylko trudne przypadki. Zaczynamy od wariantu deklaratywnego — jest przewidywalny i łatwy do audytu.

Jeśli modele są podpięte na sztywno w wielu miejscach — tak. Jeśli wszystko idzie przez router, zmiana modelu to zmiana jednej reguły, a nie refaktor. Dlatego warstwę routera stawiamy od początku: rynek modeli zmienia się szybciej niż Wasza architektura powinna, a router izoluje system od tych zmian.