Domyślna decyzja przy większości wdrożeń brzmi: bierzemy największy dostępny model, bo będzie najlepszy. Rzadko kiedy jest to decyzja — częściej brak decyzji.
Bywa słuszna. Ale przy zadaniach, które w praktyce stanowią większość ruchu w produkcji — klasyfikacja, ekstrakcja danych, rozpoznanie intencji, routing — duży model to płacenie wielokrotności za zdolności, których nikt nie używa.
Co właściwie daje rozmiar
Rozmiar mierzy się liczbą parametrów, czyli wyuczonych wag. Więcej parametrów oznacza w praktyce trzy rzeczy: szerszą wiedzę o rzadkich tematach, lepsze radzenie sobie z rozumowaniem wielokrokowym oraz wyższą jakość w językach słabiej reprezentowanych w danych — a więc również w polskim.
Trzeba to jednak zestawić z tym, co ustaliliśmy w artykule o treningu: dwa modele o zbliżonym rozmiarze potrafią zachowywać się zupełnie inaczej, bo różni je skład danych i dostrojenie. Rozmiar to jeden z wymiarów, nie ranking.Mniejszy model trenowany na właściwym materiale bywa lepszy w konkretnym zadaniu niż większy ogólny — i to jest teza całego tego artykułu.
Trzy różne rzeczy, które nazywa się „mniejszym modelem”
W rozmowach o wdrożeniach mylone są praktycznie zawsze, a to trzy odrębne decyzje o różnych konsekwencjach.
Mniejszy model z rodziny. Inny model, wytrenowany od zera z mniejszą liczbą parametrów. Ma własną wiedzę, własne zdolności i własne ograniczenia. To najczystszy wybór i najłatwiejszy do oceny.
Kwantyzacja. Ten sam model, ale wagi zapisane z mniejszą precyzją liczbową. Nie zmienia się liczba parametrów ani to, czego model się nauczył — zmienia się dokładność zapisu każdej wartości. Model zajmuje mniej pamięci i liczy się szybciej, bo mniej danych trzeba przenosić.
Destylacja. Trenowanie nowego, mniejszego modelu tak, żeby naśladował większy. Powstaje inny model, o innej liczbie parametrów, uczony nie na surowym tekście, lecz na zachowaniu nauczyciela.
Różnica między drugim a trzecim jest zasadnicza: kwantyzacja zmienia sposób zapisu tych samych wag, destylacja tworzy nowe wagi. To operacje na zupełnie innym poziomie i nie zastępują się nawzajem — można zresztą zdestylowany model dodatkowo skwantyzować.
Co traci kwantyzacja
Spadek jakości bywa zaskakująco mały przy umiarkowanej redukcji precyzji i rośnie gwałtownie przy agresywnej. Nie rozkłada się jednak równomiernie i to jest najważniejsza rzecz do zapamiętania.
Cierpią najbardziej: rozumowanie wielokrokowe, długie łańcuchy zależności, trzymanie się ścisłego formatu wyjścia oraz języki słabiej reprezentowane w danych treningowych.
Ostatni punkt ma dla nas znaczenie szczególne. Spadek jakości dla polszczyzny bywa wyraźniejszy, niż sugerują benchmarki anglojęzyczne — a to na nich opiera się większość publikowanych porównań modeli skwantyzowanych. Wniosek jest prosty i wraca w tej serii regularnie: mierz na swoich danych, po polsku.
Zachowane zostaje za to zaskakująco dużo: prosta klasyfikacja, streszczanie, odpowiadanie na pytania z dostarczonego kontekstu. To są właśnie zadania, które w produkcji generują największy wolumen.
Kiedy warto zejść niżej
Gdy dane nie mogą opuścić infrastruktury. Najczęstszy powód sięgnięcia po model lokalny i zwykle niepodlegający negocjacji. Dokumentacja medyczna, dane osobowe, materiały objęte umową o poufności.
Gdy potrzebny jest przewidywalny koszt. Model lokalny ma koszt sprzętu i prądu, nie koszt za token. Przy dużym, stałym wolumenie krzywe się przecinają — i to bywa szybciej, niż zakłada intuicja.
Gdy liczy się opóźnienie. Mały model na własnym sprzęcie odpowiada szybciej niż wywołanie sieciowe do dużego, choćby ten drugi liczył się błyskawicznie.
Gdy zadanie jest wąskie. Rozpoznanie intencji, wyciągnięcie pięciu pól z formularza, sklasyfikowanie zgłoszenia do jednej z ośmiu kategorii. Duży model zrobi to lepiej o kilka punktów procentowych i drożej o rząd wielkości.
Praktyczny wzorzec, który łączy jedno z drugim, to kaskada: mały model obsługuje typowy ruch, a przypadki, w których nie jest pewny albo które rozpozna jako trudne, przekazuje wyżej. Większość zapytań nigdy nie dociera do drogiego modelu.
Ostrzeżenie dla agentów
Tu jest miejsce, w którym łatwo się przeliczyć — i wraca powód z artykułu o samplingu.
Agent nie wykonuje jednego zadania. Wykonuje ciąg kroków, z których każdy wymaga precyzyjnego wyboru narzędzia i poprawnie zbudowanych argumentów. A to są dokładnie te zdolności, które cierpią przy zmniejszaniu modelu jako pierwsze.
Do tego dochodzi efekt kumulacji: model o dziewięćdziesięciopięcioprocentowej skuteczności na pojedynczym kroku wykona bezbłędnie dziesięciokrokowe zadanie w około sześćdziesięciu procentach przypadków. Kilka punktów procentowych mniej na kroku zamienia się w istotną różnicę na całej trajektorii.
Dlatego model o mniejszych wymaganiach warto oceniać na całych przebiegach, nie na pojedynczych odpowiedziach— czyli metodą opisaną w artykule o ewaluacji trajektorii. Benchmark odpowiedzi niewiele tu powie.
Dlaczego rankingi nie odpowiedzą za ciebie
Publiczne benchmarki mają trzy problemy, o których warto wiedzieć, zanim oprze się na nich decyzję.
Kontaminacja. Zbiory testowe krążą po internecie i trafiają do danych treningowych. Model może znać odpowiedzi, zamiast umieć je wyprowadzić.
Uśrednianie. Ranking ogólny miesza dziesiątki zadań. Model wysoko w średniej może być przeciętny akurat w tym, czego potrzebujesz.
Anglocentryczność. Większość benchmarków jest po angielsku. Dla polskich zastosowań mówią mniej, niż się wydaje.
Odpowiedź na wszystkie trzy jest ta sama i jest robotą na jedno popołudnie: własny zestaw testowy z kilkudziesięcioma realnymi przypadkami z twojej produkcji, z zapisanym oczekiwanym wynikiem. Raz zbudowany, służy przy każdej zmianie modelu i przy każdej aktualizacji po stronie dostawcy.
Jak to sprawdzić u siebie
Poniższy kod to szkielet takiego zestawu. Zamiast wierzyć rankingom, mierzy dwa modele na twoim zadaniu — skuteczność i czas.
import time
from transformers import pipeline
przypadki = [
("Zamówienie 4471 nie dotarło, minęły dwa tygodnie.", "reklamacja"),
("Czy wysyłacie do Niemiec i ile to trwa?", "pytanie"),
("Proszę o fakturę do zamówienia z marca.", "dokumenty"),
("Chcę zwrócić buty, są za małe.", "zwrot"),
("Kiedy będzie dostępny rozmiar 42?", "pytanie"),
]
szablon = ("Sklasyfikuj zgłoszenie jako jedno słowo: reklamacja, pytanie, "
"dokumenty albo zwrot.\nZgłoszenie: {}\nKategoria:")
for nazwa in ["Qwen/Qwen2.5-0.5B-Instruct", "Qwen/Qwen2.5-1.5B-Instruct"]:
gen = pipeline("text-generation", model=nazwa)
trafienia, start = 0, time.time()
for tekst, oczekiwane in przypadki:
wynik = gen(szablon.format(tekst), max_new_tokens=5,
do_sample=False, return_full_text=False)[0]["generated_text"]
if oczekiwane in wynik.lower():
trafienia += 1
czas = time.time() - start
print(f"{nazwa:34} {trafienia}/{len(przypadki)} {czas:.1f}s")Podstaw własne przypadki — im bliżej realnego ruchu, tym lepiej. Pięć to za mało na decyzję, ale wystarczy, żeby zobaczyć mechanikę; do wyboru modelu weź kilkadziesiąt.
Warto zrobić trzy przebiegi: mniejszy model, większy model i ten sam większy w wersji skwantyzowanej. Jeśli różnica w skuteczności okaże się niewielka, a różnica w czasie kilkukrotna, właśnie znalazłeś oszczędność, o której benchmark by ci nie powiedział.
I jedna uwaga metodologiczna: mierz na tych samych przypadkach, tym samym promptem i bez losowości. Inaczej porównujesz szum.
Co dalej
Zajmowaliśmy się dotąd modelami, które odpowiadają od razu. Osobną kategorią są takie, które przed odpowiedzią generują długi wywód dla samych siebie — kosztujący tokeny, których nigdy nie zobaczysz.
O tym jest artykuł jedenasty: Modele rozumujące — czym różni się „thinking” i kiedy za nie przepłacasz.
