Qwen vs Gemma? To złe pytanie. Oto jak naprawdę wybrać LLM do home-labu

Co jakiś czas ktoś mnie pyta: „Qwen czy Gemma — co lepsze?". I najuczciwsza odpowiedź brzmi: „to zależy". Wiem, brzmi jak wykręt. Ale zaraz pokażę Ci, jak zamienić to „zależy" w twardą liczbę — Twoją liczbę.

Leaderboardy Cię okłamią (przynajmniej dla Twojego przypadku)

Publiczne rankingi mierzą uśrednione, akademickie zadania — wiedza ogólna, matma, testy wyboru. Fajnie. Tylko Ty raczej nie odpalasz sobie MMLU w domu. Ty robisz coś konkretnego: wołasz narzędzia z modelu (tool-calling), gonisz agenta w pętli, generujesz po polsku, na SWOIM kwancie, ze SWOIM promptem.

Model, który króluje w rankingu, potrafi się rozłożyć na Twoim realnym zadaniu — bo Twojego zadania w benchmarku nie było. Ranking odpowiada na pytanie „który model jest średnio najlepszy dla wszystkich". A Ciebie interesuje „który jest najlepszy dla MNIE". To dwa różne pytania.

Gdzie która rodzina błyszczy

Punkt startowy z praktyki (nie werdykt — punkt startowy):

• Qwen — mocny w tym, co „robocze": tool-calling, agentic, kod, multilingual (polski trzyma dobrze), długi kontekst. Po prostu jest budowany pod narzędzia i agentów. Jak automatyzujesz i model ma wołać funkcje w pętli — to Twój pierwszy strzał.
• Gemma — błyszczy w naturalności języka, wiedzy ogólnej, czystym czacie, a nowsze wersje dokładają multimodal (obrazy). Jak potrzebujesz ładnego tekstu albo drugiego, „gładszego" głosu — jest w grze.

Reguła kciuka: automatyzacja / agenci / kod → Qwen. Pisanie / czat / vision → Gemma w grze. Ale traktuj to jak hipotezę do sprawdzenia, nie jak wyrok.

Jak zmierzyć u siebie (mięso)

Tu się zaczyna robota. Cztery kroki:

1. Zbierz SWÓJ test-suite. 10–20 realnych zadań, które faktycznie odpalasz: Twój typowy tool-call, Twój polski prompt, jeden krok Twojego agenta. To jest Twój prywatny benchmark i wart jest więcej niż wszystkie rankingi razem wzięte.

2. Ustandaryzuj warunki. Ten sam kwant, ten sam KV cache, ta sama temperatura, ten sam seed, ten sam prompt. Zmienisz dwie rzeczy naraz — mierzysz szum, nie model. Podstawowa higiena eksperymentu, a i tak większość ją olewa.

3. Mierz to, co dla CIEBIE ważne. Nie „czy mądry", tylko konkrety: - tool-calling success rate — czy poprawnie woła narzędzie z dobrymi argumentami - format adherence — czy JSON się parsuje, czy trzyma schema - jakość polskiego — na Twoich realnych tekstach - tok/s i VRAM — czy się mieści i czy nie muli

4. Zautomatyzuj to. Skrypt, który przełącza modele (u mnie przez llama-swap), przepuszcza cały test-suite i zrzuca metryki do CSV. Bo po trzecim ręcznym przeklikaniu tego samego sam wiesz, że tak się nie da pracować.

Gotchas, które rozwalą Ci pomiar (i produkcję)

Kilka min, na których łatwo wylecieć:

• Sampling params trują tool-calling. presence_penalty, repetition_penalty i spółka potrafią rozłożyć structured output na łopatki. Model, który „nagle zgłupiał" przy narzędziach, często wcale nie zgłupiał — po prostu skopiowałeś komuś parametry samplera. Do toolów trzymaj je przy zerze.
• Chat template musi się zgadzać z modelem. Zły template = pozorna głupota. Zanim ogłosisz, że model jest słaby, sprawdź, czy w ogóle gada w swoim formacie.
• Za niski kwant degraduje tool-calling szybciej niż czat. Model potrafi ładnie gawędzić na Q4 i jednocześnie sypać niepoprawnym JSON-em. Structured output jest wrażliwszy na kwantyzację niż zwykła rozmowa — testuj to osobno.

Werdykt: mierz, nie wróż

Nie dam Ci tu gołych score'ów „Qwen 8.4, Gemma 7.9" — i to jest cała pointa. Mój wynik, na moim sprzęcie, na moich zadaniach, to NIE Twój wynik. Gdybym wcisnął Ci swoje liczby jako Twoją prawdę, robiłbym dokładnie to, co zarzucam leaderboardom.

Zbuduj swój test-suite raz. Potem każdy nowy model — Qwen, Gemma, cokolwiek wyjdzie za miesiąc — przepuszczasz przez ten sam młynek. I nagle „co lepsze" przestaje być opinią z forum, a staje się liczbą. Twoją liczbą, na Twoich zadaniach.

To jest różnica między wróżeniem a inżynierią.