Rynek modeli językowych zmienił się w ciągu ostatniego roku tak radykalnie, że stare podejście — wybrać jeden model frontier i zostawić go do wszystkiego — przestaje działać. Dziś masz do dyspozycji modele open-weight z milionowym oknem kontekstu, cloud API z cenami bliskimi zeru, lokalne wdrożenia na jednym serwerze oraz dziesiątkomiliardowe architektury MoE, które są mniejsze, niż wyglądają. Jednocześnie wybór modelu bez ram decyzyjnych to loteria — nie ze względu na jakość modeli, lecz dlatego że większość decyzji podejmowana jest bez jasno określonych wymagań.
Ten artykuł dostarcza konkretnych ram decyzyjnych. Cztery wymiary — zadanie, infrastruktura, koszt i prywatność — oraz dla każdego z nich seria filtrów, które skracają listę kandydatów do dwóch lub trzech pretendentów. Konkretne liczby pochodzą z weryfikowanych źródeł; tam gdzie dane są niepewne, powiemy o tym wprost.
Krok 1 — Zdefiniuj, co model robi (i czego nie robi)
Przed wyborem modelu trzeba wiedzieć, jaki typ zadania ma rozwiązywać. Modele językowe nie są jednakowo silne we wszystkich obszarach, a model, który wygrywa na arytmetyce, może przegrywać przy długich dokumentach.
Trzy podstawowe kategorie zadań:
- Ekstrakcja i klasyfikacja: Wyciąganie danych ze skanów, etykietowanie ticketów, sumaryzacja. Wystarczą mniejsze modele. Latencja i przepustowość są ważniejsze niż surowa inteligencja.
- Generacja i reasoning: Pisanie raportów, analiza umów, kodowanie, planowanie. Tu liczy się jakość benchmarkowa — preferuj modele frontier albo silne modele open-weight z rodziny Llama, Qwen lub Mistral.
- Długi kontekst: Analiza rozległej dokumentacji, firmowych archiwów, sumaryzacja protokołów. Tu modele różnią się dramatycznie — nie wszystkie równie dobrze radzą sobie z retrieval w środku megabajtów tekstu, nawet jeśli nominalnie mają duże okno kontekstu.
Gdy znasz typ zadania, wiesz, na co zwracać uwagę w benchmarkach: MMLU, HumanEval i GSM8K dla ogólnego reasoningu i kodu; IFEval dla śledzenia instrukcji; RULER lub testy needle-in-a-haystack dla długiego kontekstu. Czytaj jednak benchmarki ostrożnie — mierzą specyficzne warunki, nie produkcyjną rzeczywistość. Więcej na ten temat w artykule Jak czytać benchmarki LLM.
Krok 2 — Open-weight vs cloud API: to jest rzeczywista oś decyzji
Nie „który model", lecz „gdzie działa". Ta decyzja determinuje 80% pozostałych parametrów.
Cloud API (Anthropic, OpenAI, Google, Mistral, DeepSeek)
Zalety: - Zerowe koszty infrastruktury — płacisz za tokeny, nie za GPU - Najwyższa wydajność we wszystkich kategoriach (modele frontier prowadzą w benchmarkach) - Okna kontekstu bez ograniczeń własnego VRAM - SLA i dostępność zapewnia dostawca
Ograniczenia: - Twoje dane i prompty opuszczają Twoją infrastrukturę - Ceny są zmienne; przy dużych wolumenach miesięczne koszty mogą sięgać pięciu cyfr - Sektory regulowane (ochrona zdrowia, prawo, finanse) mają surowe ograniczenia dotyczące data egress
Orientacyjne ceny w 2026 roku: modele frontier (Claude Opus, GPT-5.x) kosztują rzędu 3–25 USD za milion tokenów wejściowych w zależności od tier. DeepSeek i podobne modele z chińskich rodzin przez API są zazwyczaj 10–30 razy tańsze niż US frontier. Ceny w ciągu ostatniego roku znacząco spadły, więc stare kalkulacje nie obowiązują.
On-prem / wdrożenie lokalne (modele open-weight)
Zalety: - Dane nie wychodzą z sieci — jedyna droga dla operacji wrażliwych pod kątem GDPR lub niejawnych - Przewidywalne koszty (sprzęt + energia) po początkowej inwestycji - Pełna kontrola nad modelem, logami promptów, wersjami
Ograniczenia:
- Jednorazowa inwestycja w GPU i koszty IT
- Niższa wydajność niż frontier modele w chmurze (różnica się zmniejsza, ale istnieje)
- Potrzebna warstwa serving — vLLM, SGLang lub Ollama (dla produkcyjnego servingu wyklucz Ollama, więcej poniżej)
Jeśli chcesz podejść do tej decyzji systematycznie, przeczytaj szczegółową analizę w Lokalne LLM vs cloud. Dla sektorów regulowanych obowiązują dodatkowe warunki — lokalne wdrożenie eliminujące data egress nie wystarczy do compliance bez logów audytowych i zarządzanych dostępów, co omawia On-prem LLM dla sektorów regulowanych.
Krok 3 — Rozmiar modelu: większy nie zawsze znaczy lepszy
Rynek open-weight w 2026 roku pełen jest architektur MoE (Mixture of Experts). Co to oznacza w praktyce: model o nazwie „400B parametrów" może przy jednym żądaniu inference aktywować zaledwie ~17 miliardów. Liczba parametrów a aktywne parametry to dwie różne liczby.
Praktyczne konsekwencje dla wyboru:
- Modele MoE (np. Llama 4 Maverick, warianty Qwen 3.x MoE, Mixtral, DeepSeek V3): Mniejszy compute przy inference, ale na dysk i VRAM trzeba załadować cały model. Duże modele MoE mają setki miliardów parametrów, z których przy każdym tokenie aktywna jest tylko ułamkowa część — VRAM jednak potrzebny jest na cały model. Naiwne patrzenie wyłącznie na „aktywowane parametry" zaniża zatem wymagania sprzętowe.
- Modele dense (Gemma 3, Phi-4, starsze Llama 3.x): Prostszy deployment; liczba parametrów ≈ compute. Phi-4 lub mniejsze modele Gemma 3 sprawdzają się doskonale w wdrożeniach edge i przypadkach embedded.
Orientacyjne zapotrzebowanie na VRAM (bez KV cache) dla typowych rozmiarów:
- Model 7–9B: format Q4_K_M ≈ 5–7 GB VRAM; FP16 ≈ 16–19 GB
- Model 13B: Q4_K_M ≈ 8 GB; FP16 ≈ 26 GB
- Model 70B: Q4_K_M ≈ 35–40 GB; FP16 ≈ 140–168 GB
Kwantyzacja (GGUF Q4_K_M, AWQ 4-bit) nie jest automatycznie zła — na większości benchmarków różnica od jakości FP16 wynosi do 5–8%. Wyraźna degradacja następuje dopiero przy Q2 i niżej. Więcej o technikach i ich różnicach w Kwantyzacja LLM (GGUF, AWQ, GPTQ).
Dla większości przypadków użycia B2B: dobrze dostrojony model 13B pokona ogólny model 70B w wąskiej domenie. Przed decyzją o rozmiarze warto rozważyć, czy jest wystarczająco dużo danych do fine-tuningu — omawia to RAG vs fine-tuning.
Krok 4 — Latencja i przepustowość: kto jest Twoim użytkownikiem?
Dwa skrajnie różne profile z odmiennymi wymaganiami:
Interaktywny (user-facing) chat lub copilot: Latencja jest krytyczna. Pierwszy token powinien dotrzeć w ciągu 1–2 sekund. Tu istotny jest TTFT (Time to First Token). Mniejszy model, który odpowiada szybko, jest lepszy niż duży, który czeka.
Przetwarzanie wsadowe (batch): Przepustowość jest krytyczna. Liczy się liczba tokenów na sekundę w całej partii. Tu opłaca się większy model kosztem wyższej latencji na żądanie, ponieważ przetwarzasz dziesiątki tysięcy dokumentów naraz.
Dla infrastruktury serving: vLLM jest produkcyjnym wyborem dla większości wdrożeń NVIDIA — PagedAttention radykalnie redukuje fragmentację KV cache (z typowych 60–80% marnotrawstwa do poniżej 4%) a continuous batching podnosi przepustowość 2–3-krotnie w porównaniu ze statycznym batchowaniem. SGLang jest silniejszy przy workloadach z dużym udziałem prefiksu (RAG, agenci, multi-turn) — benchmarki pokazują ~29% wyższą przepustowość na H100 i ~23% szybszy TTFT w porównaniu z vLLM.
Ollama nadaje się dla jednego dewelopera na desktopie, nie do produkcyjnych wdrożeń wieloużytkownikowych. Przy wielu równoległych użytkownikach przepustowość jest znacznie niższa niż przy vLLM.
Krok 5 — Koszt: gdzie naprawdę się płaci
Rynek cloud LLM API jest dziś znacznie korzystniejszy cenowo niż rok temu. Ale nadal istnieją pułapki.
Okno kontekstu ≠ tańsze rozwiązanie. Kontekst 1M tokenów nie oznacza, że zawsze wysyłasz milion tokenów — płacisz za każdy wysłany token. KV cache rośnie liniowo z długością sekwencji. Na przykład model 70B przy kontekście 128K potrzebuje ~40 GB samego KV cache; dla czterech równoległych żądań przy 128K to ~160 GB ponad sam model. Okno kontekstu to pojemność, nie stała.
Prompt caching jest ważnym narzędziem obniżania kosztów przy powtarzających się systemowych promptach. Orientacyjnie: przy dobrym workloadzie zaoszczędzisz 50–70% kosztów na tokenach wejściowych. Jednak tokeny zapisu cache są na niektórych platformach 1,25–2 razy droższe niż zwykłe — oszczędność pojawia się dopiero przy wielokrotnym odczycie tego samego prefiksu. Workloady z unikalnymi długimi promptami nie korzystają z cachowania. Więcej w Prompt caching i koszty.
Routing (wywołanie taniego modelu dla prostych pytań, drogiego tylko dla złożonych) może przy dobrze skalibrowanym ustawieniu zachować 95% jakości przy ułamku kosztów. Badania z Berkeley wykazały, że przy odpowiednim routerze 75–90% wywołań trafia na mniejszy model. Jest to łatwe do wdrożenia, ale wymaga bazowych evals — bez pomiaru nie wiesz, gdzie leży granica.
Krok 6 — Licencje i warunki użytkowania
To jest zaniedbywane, dopóki nie staje się problemem.
Modele open-weight nie są automatycznie wolne do dowolnego użytku:
- Llama 4 (Meta): Niestandardowa licencja Meta. Ograniczenie przy wdrożeniach z ponad 700 milionami miesięcznych aktywnych użytkowników. Dla większości wdrożeń korporacyjnych B2B ograniczenie nie jest istotne, ale licencję należy przeczytać.
- Qwen 3.x: Apache 2.0 — komercyjne użycie, modyfikacja, dystrybucja bez opłat. Mistral: mniejsze modele (np. Mistral Small) są na Apache 2.0, większe (Mistral Large) mają własną licencję Mistral — przy konkretnym modelu zweryfikuj.
- DeepSeek V3: Licencja MIT — maksymalna swoboda, w tym fine-tuning i dalsza dystrybucja.
- Gemma 3 (Google): Własna licencja Gemma — zezwala na użytek komercyjny, ale nie jest licencją open-source zatwierdzoną przez OSI. Uważnie przeczytaj warunki.
- Phi-4 (Microsoft): MIT.
Dla zamkniętych modeli cloud API (Claude, GPT-5.x, Gemini) warunki określają SLA i terms of service — zwróć uwagę na politykę przechowywania danych i opt-out z danych treningowych.
Sektory regulowane powinny mieć podpisaną DPA (Data Processing Agreement) przed pierwszym produkcyjnym wywołaniem.
Krok 7 — Okno kontekstu: kiedy 1M pomaga, a kiedy nie
Niemal każdy flagowy model w 2026 roku ma okno kontekstu co najmniej 128K tokenów. Llama 4 Scout ma nawet 10M. Claude (wyższe tiery), Gemini 2.5 i Llama 4 Maverick oferują 1M; DeepSeek V3 ma 128K.
Pytanie nie brzmi „który ma większy kontekst", lecz „czy go potrzebuję?".
Badania pokazują, że modele z rosnącym kontekstem wykazują „context rot" — dokładność retrieval spada, gdy istotna treść otoczona jest dużą ilością nieistotnego tekstu. Dotyczy to zwłaszcza pytań multi-hop, gdzie trzeba połączyć informacje z różnych miejsc dokumentu.
Praktyczna zasada: Jeśli Twój przypadek użycia obejmuje długie dokumenty (umowy, instrukcje techniczne, archiwa), ale zapytania mają ukierunkowany charakter, RAG będzie ekonomiczniejszy i dokładniejszy niż bezpośrednie umieszczanie całego dokumentu w kontekście. Długi kontekst ma sens tam, gdzie naprawdę potrzebujesz, żeby model czytał cały dokument naraz — generowanie abstraktu ze 200-stronicowego raportu, analiza bazy kodu.
Praktyczne drzewo decyzyjne
Ten proces zawęzi Ci pole w praktyce do dwóch lub trzech kandydatów:
- 1.Czy dane mogą opuścić Twoją sieć? → Nie: open-weight + lokalny serving. Tak: kontynuuj.
- 2.Czy przepustowość lub latencja są krytyczne i zużycie duże? → Tak: rozważ lokalny serving. Nie: cloud API.
- 3.Jakie jest zadanie? → Prosta ekstrakcja/klasyfikacja: mniejszy model (7–13B lub tanie API). Złożony reasoning: frontier lub silny 70B+.
- 4.Czy masz konkretną domenę z wystarczającą ilością danych? → Rozważ fine-tuning mniejszego modelu przed zakupem większego.
- 5.Jaka jest licencja? → Filtruj według Apache 2.0 / MIT dla produkcyjnych wdrożeń komercyjnych bez obciążeń prawnych.
Najczęstsze pytania
Który model open-weight jest dziś najlepszy?
Nie ma jednej prawidłowej odpowiedzi. W 2026 roku w różnych benchmarkach prowadzą modele takie jak Llama 4 Maverick, Qwen 3.x, DeepSeek i Mistral Large — zależy od zadania. Do kodu i reasoningu silne są modele z rodziny Qwen; w długim kontekście wyróżnia się Llama 4 Scout (okno kontekstu 10M). Zawsze testuj na własnych danych, nie tylko na publicznych benchmarkach.
Czy DeepSeek jest wiarygodny do wdrożeń w Europie?
DeepSeek oferuje otwarte wagi z licencją MIT — możesz pobrać model i uruchomić go lokalnie, bez żadnych wywołań na chińskie serwery. Z perspektywy GDPR lokalne wdrożenie DeepSeek jest tak samo „czyste" jak Llama czy Mistral. Wersja cloud API przez serwery DeepSeek to inna kwestia — tu obowiązują te same rozważania dotyczące data egress co przy dostawcach US.
Czym jest MoE i czy muszę się tym zajmować przy wyborze?
MoE (Mixture of Experts) to architektura, w której model aktywuje tylko część parametrów przy każdym tokenie. Praktyczna konsekwencja: niższy compute przy inference, ale wyższy całkowity footprint VRAM. Przy wdrożeniu lokalnym musisz załadować cały model do pamięci, nawet jeśli przy każdym tokenie używana jest tylko ułamkowa część. Dla cloud API ten szczegół nie ma znaczenia — płacisz za aktywne parametry.
Czy fine-tuning opłaca się zamiast większego modelu?
W wielu przypadkach tak — ale tylko jeśli masz wystarczającą ilość danych dobrej jakości i jasno zdefiniowaną domenę. Dobrze dostrojony model 13B może pobić ogólny model 70B w wąskim zadaniu przemysłowym. Jeśli nie masz wystarczająco danych (dla SFT potrzebujesz rzędu tysięcy dobrej jakości przykładów), fine-tuning raczej zaszkodzi niż pomoże. O wyborze między RAG a fine-tuningiem piszemy w RAG vs fine-tuning.
Jak sprawdzić, czy wybrałem właściwie?
Właściwy wybór weryfikuje się evaluacjami na własnych danych i przypadkach użycia — nie tylko porównywaniem benchmarków. Zdefiniuj 50–100 przypadków testowych z oczekiwanym wynikiem, uruchom na kandydatach, porównaj. Ten proces opisujemy szczegółowo w Jak mierzyć jakość aplikacji LLM.
*W MP Industrial Solutions pomagamy firmom przejść przez wybór modelu w sposób ustrukturyzowany — od mapowania przypadków użycia przez testowanie kandydatów aż po produkcyjne wdrożenie na własnej infrastrukturze. Jeśli stoisz przed tą decyzją i chcesz uniknąć kosztownych ślepych zaułków, chętnie porozmawiamy.*