O czym jest ten film
- Premiera Claude 5 (Opus 5) to okazja, by pokazać, jak producenci modeli manipulują sposobem prezentacji benchmarków.
- Skala logarytmiczna i dobór korzystnych wykresów sprawiają, że ogromne różnice w cenie wyglądają na małe, a małe różnice w jakości — na duże.
- Kluczowa teza: rzadko potrzebujemy „najmocniejszego modelu na świecie” — potrzebujemy właściwego modelu do konkretnego zadania.
- Trzy wymiary decyzji, na które warto patrzeć razem: inteligencja, szybkość (tokeny/s) i koszt na zadanie.
- Autor 80% pracy wykonuje na lokalnym modelu Qwen (27 mld parametrów) na karcie RTX 5090 — szybko, prywatnie i stabilnie.
- Szybkość ma realne znaczenie: powolne modele zmuszają do zrównoleglania pracy, co przeciąża umysł i obniża produktywność.
- Dobór modelu zależy od zadania: badania (biologia, cyberbezpieczeństwo) bez zbyt silnych „guard rails”, pisanie z własnym głosem, kodowanie.
- Modele lokalne dają suwerenność, prywatność i — co ważne — stabilność, której brak modelom chmurowym, ciągle „podkręcanym” przez dostawców.
- Autor świadomie nie używa modeli Anthropic z powodów światopoglądowych (walka z open source, zbyt silne ograniczenia).
- Praktyczna rada: przed zakupem sprzętu przetestuj model (np. przez OpenRouter), a modeli chmurowych używaj tylko tam, gdzie naprawdę są potrzebne.
Redakcyjne tłumaczenie
Premiera Claude 5 i narracja wokół benchmarków
Claude 5 jest już dostępny. To duża wiadomość i jest o czym mówić. W tym materiale chcę podzielić się swoimi przemyśleniami o samym modelu, ale przede wszystkim o narracjach, które towarzyszą takim premierom. Porównajmy go z GPT-5.6, a także z kilkoma alternatywami — zarówno chmurowymi, jak i lokalnymi.
Zacznijmy od strony producenta i od benchmarków. Widać, że w wielu obszarach nowy model jest znacznie lepszy od Fable 5, w niektórych konkretnych zadaniach słabszy, ale ogółem wypada świetnie. A potem dochodzimy do kodowania agentowego — i tu akurat GPT-5.6 jest lepszy. To jeden z najważniejszych parametrów. Można by się spodziewać, że powiedzą to głośno i wprost: „w najważniejszej części, czyli w kodowaniu agentowym, GPT-5.6 jest lepszy”. Zamiast tego stworzono narrację w stylu: „no tak, jest ta różnica, ale nie skupiajmy się na niej, bo ważne jest to, co zaznaczyliśmy na czerwono”.
To jest brak transparentności i wprowadzanie w błąd. A przecież nie ma nic złego w uczciwości: „tu jesteśmy dzisiaj i będziemy się poprawiać” — zwłaszcza że w wielu rzeczach naprawdę są lepsi. Ale na to się nie zdobyli.
Jak skala logarytmiczna ukrywa różnice w cenie
Jest jeszcze wykres „kodowanie agentowe wg poziomu wysiłku” — dość ważna metryka. I znowu narracja robi swoje. Popatrzcie na oś: 1 dolar, 150 dolarów, a potem 50 centów, 3 dolary, 20, 30 dolarów. To jest skala logarytmiczna. To znaczy, że odstępy o tej samej szerokości oznaczają zupełnie różne wartości. Różnica, która na wykresie wygląda na malutką, w rzeczywistości bywa ogromna, a inna, która wygląda na wielką, jest w istocie niewielka.
(Informacja dodatkowa: na skali logarytmicznej równe odległości na osi odpowiadają równym mnożnikom, nie równym różnicom — dlatego wizualne „odległości” mylą, gdy porównujemy ceny.)
I tu jest ta „maszyna do wprowadzania w błąd”. Robią to wszyscy — OpenAI dokładnie tak samo. Szukają benchmarku, na którym wypadają fantastycznie. Popatrzcie na indeks „Artificial Analysis Coding Agent Index v1.1”. OpenAI chce pokazać, jak drogi jest Fable 5: jego wynik indeksu to 77,2. Idziemy do Luna Max — wynik 74,6. Różnica w jakości minimalna. Różnica w cenie — gigantyczna, wręcz absurdalna. Każdy przepycha własną narrację. Każdy próbuje naginać rzeczywistość.
Szukanie uczciwego punktu odniesienia
Można pomyśleć: wejdźmy na jakiś niezależny serwis i znajdźmy coś prawdziwego. Nawet tam nie da się w pełni zrozumieć całości, ale przynajmniej nie tworzą tego sami producenci, więc mamy inną perspektywę.
Patrząc na inteligencję: 61 dla jednego z modeli, 60 dla Fable, 59 dla GPT-5.6. To są małe kroki, nic rzucającego się w oczy. Niżej różnice robią się większe, ale wciąż jest blisko. Są modele — jak Kim K3 — które nie odstają daleko, a mają zupełnie inny model biznesowy.
Inteligencja to nie wszystko, bo te dwa punkty czy jeden punkt różnicy przekładają się na cenie na ogromną przepaść. Fable 5 to 2,75 dolara na zadanie, Opus 5 — 23 dolary, GPT — ok. 154, a Kim K3 — zaledwie 0,72. Zobaczcie, o ile tańszy jest ten model i jak niewiele odstaje jakością.
Trzeci wymiar: szybkość
To nadal nie cała historia, bo liczy się też szybkość, mierzona w tokenach na sekundę. Kim K3 jest tu najwolniejszy — 32 tokeny/s, ok. 53 z Opusa, 58 z Grocka, GPT-5.6 daje 77, co jest już poważną różnicą. Ale są modele dużo szybsze — podoba mi się GLM 5.2 z wynikiem 217. Różnica w inteligencji nie jest duża, a w szybkości — kolosalna. A koszt takiego modelu to 0,32. To po prostu szaleństwo.
Dlaczego to ważne? Bo najczęściej nie potrzebujemy najpotężniejszego AI na świecie. Potrzebujemy właściwego AI do właściwego zadania. Do większości zadań Fable, Opus 5 czy GPT-5.6 nie są potrzebne — są potrzebne tylko w określonych przypadkach.
Gdzie plasują się modele lokalne
Na tym poziomie inteligencji znajdziemy głównie modele, które muszą działać na maszynach w chmurze. MiniMax 3 i inne da się uruchomić lokalnie, ale wymaga to naprawdę mocnego sprzętu.
Dodałem do zestawienia model Qwen 3.6 o 27 mld parametrów, którego używam na własnym sprzęcie na co dzień — nim wykonuję 80% pracy. Pod względem inteligencji plasuje się na poziomie 37, dużo niżej niż modele frontierowe. Ale co ciekawe: na karcie RTX 5090, z kwantyzacją Q6, działa z prędkością 110 tokenów/s — czyli szybciej niż którykolwiek z modeli frontierowych. Pracując z nim, ma się poczucie obcowania z oprogramowaniem premium, bo jest szybkie.
(Informacja dodatkowa: kwantyzacja Q6 to kompresja wag modelu do ok. 6 bitów — zmniejsza zużycie pamięci i przyspiesza działanie kosztem niewielkiego spadku jakości.)
Dlaczego szybkość jest tak ważna
Modele frontierowe wykonują ogromną ilość „myślenia”, co oznacza mnóstwo tokenów. Mnóstwo tokenów przy takiej prędkości wymaga dużo czasu. A czas zaczyna być odczuwalny i istotny, bo jest różnica między czymś zrobionym w kilka sekund, kilka minut a kilka godzin.
Gdy odpowiedź nie przychodzi dość szybko, zaczynamy optymalizować i pracować równolegle. Prowadzę więc kilka projektów jednocześnie, a to znaczy, że muszę przełączać uwagę między nimi. To duży wysiłek — zwłaszcza gdy jest ich wiele, a część zaczyna sprawiać problemy. Wtedy człowiek jakby paraliżuje się, bo złożoność rośnie. Klucz to powrót do prostoty, bo przynajmniej ja nie radzę sobie z taką złożonością. Kończy się na tym, że pracuję nad sześcioma projektami, mam mętlik w głowie i z poczucia ogromnej produktywności na początku dnia przechodzę do wrażenia, że zmarnowałem dzień, bo muszę przebrnąć przez zaległy katalog problemów. Dlatego szybkość jest istotna.
Trzy najważniejsze elementy to inteligencja, szybkość i koszt na zadanie. Doceniam, że ten niezależny serwis stawia je na pierwszym planie, dając uczciwy przegląd.
Kolejne modele lokalne, które warto znać
Dodam jeszcze Qwen 3.6 (35 mld) z reasoningiem. Wybrałem go, bo to dobry model, który wiele osób jest w stanie uruchomić. Plasuje się na poziomie 32 — jest mniej inteligentny niż wersja 27 mld, ale wciąż w niezłej pozycji.
Wiele osób używa Gemma 4 (31 mld) albo 26 mld — nawet niżej. Ufają im, bo to Google i bo są multimodalne, więc potrafią rzeczy, które robią wrażenie. Ale z mojego doświadczenia — a zaczynałem właśnie od nich — modele Qwen są zauważalnie lepsze.
Dobór modelu do zadania
Nie zawsze potrzebujemy modelu frontierowego. Myślenie zero-jedynkowe — „albo 100% chmura, albo 100% lokalnie, albo jeden konkretny model” — to zły sposób podejścia. Najpierw trzeba zrozumieć, jaki problem chcesz rozwiązać i jakiego przepływu pracy szukasz.
- Badania naukowe (np. biologia, cyberbezpieczeństwo): najlepszy bywa Kim K3, bo nie ma zabezpieczeń, które blokują tego typu badania. Modele frontierowe od OpenAI i Anthropic mają „guard rails”, które utrudniają rzetelną pracę na tych tematach.
- Pisanie: musisz znaleźć model, którego głos do ciebie przemawia. Bardziej inteligentny nie znaczy lepszy. Chmurowy model, który lubię, to GLM 5.2 — szybki, inteligentny, dobrze pisze, a że nie jest jednym z najpopularniejszych, daje pewną oryginalność. Nie pisze jak Opus ani jak GPT-5.5.
(Informacja dodatkowa: „guard rails” to wbudowane zabezpieczenia modelu, które odmawiają odpowiedzi na wrażliwe tematy; bywają pomocne, ale mogą też blokować legalne badania.)
Kodowanie: modele zbliżają się do siebie
Przy kodowaniu historia wygląda inaczej — modele są sobie znacznie bliższe, różnice mniejsze. Dlaczego? Bo do kodowania trenuje się je na najlepszym, wyselekcjonowanym kodzie. Materiał treningowy jest bardzo dobry i efektywny, więc modele są w tym naprawdę dobre. Kolejny najbardziej prawdopodobny token jest dobrym tokenem — mniej potrzeba „myślenia” i mniej potrzeba bardzo mocnego modelu. Popatrzcie na Sonnet — nie odstaje daleko. Albo Luna Max — praktycznie jak Sonnet 5, ta sama jakość, a koszt niższy. Niektóre modele, choć znacznie mniejsze, wciąż są efektywne.
Czym naprawdę jest „sztuczna inteligencja”
Musimy się rozprawić z pewnym nieporozumieniem. Nazywamy to sztuczną inteligencją, ale w rzeczywistości to nie jest inteligencja. To raczej bardzo dobrzy aktorzy. Grają w określony sposób — tak dobrze i precyzyjnie, że rzeczywisty wynik nadaje się do użycia w realnym świecie. Nie zawsze, ale często. Ale to gra aktorska, więc nie można jej bezgranicznie ufać. Nie rozmawiamy z AI, które rozumie — ono niczego nie rozumie, nie ma tam inteligencji, jest bardzo dobry aktor.
Skoro tak działają, możemy określić wymagany „poziom gry” do zadania: czy potrzebuję ekstremalnie wysokiego poziomu, czy nie — bo od tego zmienia się koszt i szybkość. Jeśli chcesz optymalizować, chodzi o dobranie właściwego modelu do właściwego zadania. Jeśli potrzebujesz szybkości — szukasz szybkiego modelu (może to być GLM 5.2: bardzo inteligentny, ekstremalnie szybki, bardzo tani). Jeśli zależy ci na prywatności — potrzebujesz modelu lokalnego, np. Qwen 3.6 (27 mld), a czasem nawet mniejszego, bo znów: nie chodzi o samą inteligencję, tylko o to, czy model wykonuje zadanie.
Praca agentowa a kodowanie na modelach lokalnych
Zanim przeszedłem na wersję 27 mld, używałem Qwen 35 mld (A3B). W niektórych zadaniach jest odrobinę z tyłu. W pracy agentowej różnica jest zauważalna — zwłaszcza w kodowaniu wersja 27 mld wypada wyraźnie lepiej niż 35 mld. W ogólnej inteligencji różnica jest mniejsza, a w indeksie agentowym znów bardziej widoczna.
Z mojego doświadczenia: do prowadzenia Hermesa ten model działał bez problemu, robił, o co prosiłem. Jako osobisty asystent — wystarczająco dobry. W kodowaniu widać już lukę. I mimo to używam go do 80% swojej pracy.
(Informacja dodatkowa: Hermes to lokalne środowisko/asystent autora, w którym uruchamia i testuje modele.)
Pozostałe 20%: trzy subskrypcje chmurowe
Pozostałe 20% to modele chmurowe. Mam trzy subskrypcje — dzielę się tym dla transparentności, nie po to, by je polecać. Mówię, czego używam i dlaczego.
- OpenAI: za 20 dolarów masz dostęp do modeli frontierowych. Możesz używać Luna Max, by wykonać dużo pracy za ułamek ceny — mniej więcej 17–80 razy taniej niż Fable 5 i znacznie taniej niż GPT-5.6. To działa, bo za każdego dolara, który dajesz w subskrypcji, dostawca dokłada z własnej kieszeni — płacą, by utrzymać niskie ceny tokenów.
- Kim K3: pozwala mi realnie testować podatności oprogramowania. To konkretny scenariusz użycia — dla mnie i pewnie dla wielu innych. Czasem wystarczy plan za 20 dolarów albo API na żądanie.
- MiniMax: kupiłem go, zanim nabyłem własny sprzęt. Jest szybki i dobry. Ale spójrzcie: MiniMax M3 w porównaniu z Qwen 3.6 (27 mld) nie odstaje daleko — a to właśnie jest niesamowite w tym modelu Qwen. Jest ekstremalnie mocny jak na swój rozmiar (27 mld), podczas gdy MiniMax to prawdopodobnie 3–400 mld, a modele frontierowe idą w biliony parametrów.
Jeśli widzicie takie różnice, powinny wam pokazać, czego się spodziewać. Model lokalny nie zrobi wszystkiego, ale zrobi bardzo wiele. Gdy nie da rady — masz pozostałe modele.
Praca równoległa i zarządzanie sprzętem
MiniMax kupiłem przed sprzętem. Teraz używam go, gdy mój sprzęt jest zajęty. Z modelem lokalnym możesz uruchomić jedną lub więcej instancji tego samego modelu równolegle. Na jednej karcie 5090 uruchomię jedną instancję, jeśli potrzebuję długiego okna kontekstu, albo do czterech, jeśli okno jest małe. Kiedy interaktywnie rozmawiam z modelem, potrzebuję całego okna kontekstu — wtedy mieści się tylko jedna instancja. Gdy chcę pracy równoległej, dokładam MiniMax, Kim K3, starszy GPT-5.6 oraz OpenRouter.
Dlaczego nie używam modeli Anthropic
Powiem, dlaczego nie używam modeli Anthropic. To firma, która aktywnie próbuje powstrzymać modele open source. Z tego powodu nie mogę z nimi pracować. Nie twierdzę, że OpenAI jest lepsze — może odrobinę lepsze, odrobinę inne. Kiedyś to OpenAI było „tym złym w pokoju”. Teraz to Anthropic zdobył tę niechlubną palmę. Stawiam więc granicę: Anthropic jest dla mnie nieużywalny z powodów światopoglądowych — wartości, alignmentu. Nie są zgodne z moimi zasadami.
Chyba że jesteś zmuszony przez biznes czy inne wymagania — wtedy tak, korzystaj. Zrozum jednak, że żadna decyzja nie jest idealna. Zawsze jest jakiś problem: przy modelach lokalnych to kwestia kosztu (sprzętu), przy większych — kwestia wartości i środowiska. Wszyscy oni próbują zbudować AI, które zastąpi ludzi — to już samo w sobie dobry powód, by ich nie używać. Do tego zabezpieczenia Anthropic są dla mnie zbyt silne. Z Opusem 5 nieco je poluzowano, ale wciąż są mocniejsze niż w OpenAI, a w zasadzie nieobecne w modelach lokalnych.
Suwerenność, prywatność i — przede wszystkim — stabilność
Dlaczego mam obsesję na punkcie modeli lokalnych? Po pierwsze, lubię suwerenność, jaką dają. Lubię prywatność. Ale lubię też stabilność — a to niemały element. Stabilność oznacza, że gdy raz skonfiguruję i zoptymalizuję system, zostaje on zoptymalizowany dokładnie tak, jak go zaprojektowałem.
Przy modelach chmurowych — dowolnych — dostawcy nieustannie majstrują przy sprzęcie i modelach, by optymalizować koszt, zużycie i równoległość, obsługując tym samym modelem mnóstwo różnych ludzi. Sama optymalizacja oznacza, że zmieniają elementy wewnątrz modeli. Efekt: jako użytkownik masz system, który nie jest stabilny. W poprzednim filmie mówiłem o tym — potrafiłem wykonać z GPT coś skrajnie złożonego jednego dnia, a następnego stawało się to niemożliwe. To doprowadzało mnie do szału. To właśnie ta niestabilność. Wszystkie modele frontierowe w jakimś stopniu na to cierpią. Jeśli jesteś ze sobą szczery i korzystałeś z AI dostatecznie długo, wiesz, że tak jest — czujesz, że wyniki wahają się z dnia na dzień.
Te eksperymenty bywają prowadzone lokalnie — na przykład w jednym kraju testują jedno, w innym coś innego, i prawdopodobnie na mniej istotnych rynkach robią bardziej skrajne eksperymenty niż gdzie indziej, żeby mniej ryzykować u najważniejszych klientów. Ale dzieje się to wszędzie i z tego powodu mamy ciągłą niestabilność.
W przypadku modelu lokalnego to ja decyduję, kiedy zmienić ustawienia. Jestem tego świadomy, mogę sprawdzić wynik i na jego podstawie dostroić cały system. Panuję nad tym. Przy modelach frontierowych — nie. Czasem inteligencja przekracza próg wymagany do twojego zadania, czasem nie. Raz uszczęśliwisz klienta, bo gwarantujesz określony wynik, innego dnia nie. Dlatego praca z tymi firmami jest ekstremalnie ryzykowna.
Moje rozwiązanie to budowanie poziomu suwerenności i stabilności, który nie wymaga, by ktoś inny kontrolował twój biznes. Budowanie firmy na kimś, kto może zmienić moc twojego modelu, dostęp do niego czy jego cenę, to budowanie na czymś skrajnie kruchym. Osobiście wybieram eksperymentowanie w tym kierunku. Niestety, to nie wystarcza, by zrobić wszystko, czego potrzebuję. Dla niektórych wystarczy, dla innych jest zupełnie nieużywalne. To decyzja, którą każdy musi podjąć sam.
Jak podjąć decyzję: testuj przed zakupem
Jak podjąć tę decyzję? Trzeba przetestować model, zanim się go „kupi”. Jeśli sądzisz, że potrzebujesz sprzętu do uruchomienia modelu takiego jak mój Qwen 3.6 (27 mld) — w mojej ocenie, jeśli wystarcza ci okno kontekstu 131 000 tokenów, to 5090 jest najlepszym wyborem. Jeśli chcesz większego okna, potrzebujesz czegoś większego albo więcej niż jednej karty. Jeśli chcesz uruchomić mocniejszy, większy model, musisz pomyśleć o innym sprzęcie i liczyć się z tym, że model będzie działał wolniej.
Ale decyzję podejmuje się przez test przed zakupem. Ja poszedłem na OpenRouter, uruchomiłem Qwen 3.6 (27 mld) w moim Hermesie i testowałem przez kilka dni, sprawdzając, czy ten model jest wart kosztu sprzętu i czy wykona dla mnie dużo pracy. Jeśli nie jest wystarczająco dobry — to wiesz, że go nie potrzebujesz. Jeśli jest — możesz policzyć, czy się opłaca.
Jeśli korzystasz z chmury i tych potężnych modeli, zrozum, że nie musisz używać ich cały czas — to marnowanie tokenów. Możesz zaoszczędzić pieniądze i czas, po prostu dobierając model do zadania. A jeśli chcesz modelu lokalnego — przed zakupem jakiegokolwiek sprzętu przetestuj model i sprawdź, jaki najlepszy model uruchomisz na danym sprzęcie.
(Informacja dodatkowa: OpenRouter to serwis, przez który można korzystać z wielu modeli przez jedno API — wygodny do testów przed inwestycją we własny sprzęt.)
Dostępny jest też odpowiednik DGX Spark od ASUS — GX10. GX10 dobrze uruchamia Qwen 3.6 (35 mld) z 3 mld aktywnych parametrów, z prędkością ok. 60–70 tokenów/s — szybciej lub podobnie jak część modeli frontierowych — i jest dość sprytny, by prowadzić Hermesa. Świetnie nadaje się do kodowania, choć zależy to od tego, jakie kodowanie wykonujesz.
Przepływ pracy w kodowaniu: od pomysłu do implementacji
Przy kodowaniu najpierw trzeba spojrzeć na sam projekt — planowanie, koncepcję. Gdy masz pomysł, trzeba go spisać, rozpakować, rozwinąć, zanim w ogóle zaczniesz pisać kod. Ten etap wymaga długiego okna kontekstu i modelu, który rozumie wyzwania.
Możesz burzę mózgów przeprowadzić z mniejszym modelem — zadawać pytania i odpowiadać — a potem złożyć wszystko w dokument. Kolejny krok to przekazanie modelowi frontierowemu (największemu, na jaki cię stać) zaplanowania całego oprogramowania: spisania wszystkich specyfikacji i szczegółów. Wszystko, co opisałeś, trzeba zamienić w porządny proces, którego AI użyje do napisania kodu. Do tego potrzebujesz potężnego modelu — takiego, który wejdzie w każdy szczegół i wychwyci słabości, których nie wziąłeś pod uwagę.
Gdy masz plan, możesz pójść dalej: użyć innego modelu, by go zakwestionować, znaleźć słabości i poprawić. To zależy od tego, jak duża i złożona jest rzecz.
Następny krok to napisanie kodu. Niektóre duże modele frontierowe napiszą wszystko za jednym razem — zajmie to czas i mnóstwo tokenów, ale dadzą radę. To zadanie możesz im delegować, np. komendą typu „slash go”: „zaczynaj, zaimplementuj wszystko i nie przerywaj, dopóki nie skończysz”. Do tego znów użyłbym jednego z bardzo mocnych modeli — może być nawet Luna Max w większości scenariuszy.
Gdy masz już cały system spisany — czego również nie oczekuj, że będzie idealny — jest wystarczająco dobry, by zacząć pracować i ulepszać. Od tego momentu resztę może wykonać i poprawić nawet twój lokalny, mniejszy model, bo trudna część została już napisana. Teraz chodzi o drobne poprawki. Jeśli natomiast coś jest zepsute, znów potrzebujesz modelu, który rozumie dlaczego — taka praca wymaga znacznie większego zrozumienia. Najlepszy w tym scenariuszu może być Opus 5, Fable 5, GPT-5.6 albo Kim K3 — ten ostatni ma nad innymi (obciążonymi zabezpieczeniami) tę przewagę, że sprawdza się w naprawianiu i wyszukiwaniu podatności.
Podsumowanie
Scenariusz nie jest zero-jedynkowy. Sugeruję podejście mieszane. Każdy musi sam ocenić, jaki hybrydowy układ chce stosować i w jakich proporcjach. W moim przypadku to 80% lokalnie, 20% w chmurze — a chmura zależy od zadania, które mam do wykonania.
Dziękuję, że obejrzeliście do końca. Zostawcie „lubię to”, zasubskrybujcie i do zobaczenia w następnym filmie. Ciao.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Benchmarki producentów są narracją, nie prawdą
Na czym polega: Twórcy modeli dobierają wykresy i skale (zwłaszcza logarytmiczne) tak, by ich model wyglądał najlepiej, a niewygodne parametry — jak przewaga konkurencji w kodowaniu agentowym — ukryć lub zbagatelizować.
Jak stosować: Zawsze sprawdzaj, jaka jest oś (liniowa czy logarytmiczna) i którą metrykę producent eksponuje. Zestawiaj dane z niezależnymi serwisami (np. Artificial Analysis), a nie tylko z materiałami producenta.
Na co uważać: Nawet niezależne serwisy nie dają pełnego obrazu i mają własne metodologie. Na skali logarytmicznej mała wizualna różnica w cenie może oznaczać kilkukrotny mnożnik — nie oceniaj „na oko”.
2.Patrz na trzy wymiary naraz: inteligencja, szybkość, koszt na zadanie
Na czym polega: Sam ranking inteligencji jest mylący, bo 1–2 punkty różnicy potrafią oznaczać wielokrotność ceny i kolosalną różnicę w szybkości.
Jak stosować: Przy wyborze modelu porównuj jednocześnie wynik jakości, tokeny/s i koszt na zadanie. Jeśli tańszy model traci minimalnie na jakości, a wygrywa wielokrotnie na cenie i szybkości — często jest lepszym wyborem.
Na co uważać: Proporcje ważności tych trzech wymiarów zależą od zadania — do researchu liczy się jakość, do interaktywnej pracy szybkość, do masowych zadań koszt.
3.Nie używaj modelu frontierowego do wszystkiego
Na czym polega: Do większości zadań najmocniejsze modele są zbędne — to marnowanie tokenów i pieniędzy. Potrzebny jest właściwy model do właściwego zadania, nie najlepszy.
Jak stosować: Zmapuj swoje typowe zadania i przypisz do każdego najtańszy model, który je „domyka”. Modele premium zostaw na planowanie architektury, trudny debugging i zadania wymagające głębokiego rozumienia.
Na co uważać: Kuszące jest domyślne sięganie po najmocniejszy model „na wszelki wypadek” — to właśnie generuje niepotrzebne koszty i spowalnia pracę.
4.Szybkość modelu wprost przekłada się na twoją produktywność
Na czym polega: Powolne, „dużo myślące” modele zmuszają do zrównoleglania projektów, co przeciąża umysł przełączaniem kontekstu i paradoksalnie obniża efektywność.
Jak stosować: Do zadań interaktywnych wybieraj szybkie modele (wysoki wynik tokenów/s), by zachować liniowy, prosty przepływ pracy zamiast żonglowania sześcioma wątkami naraz.
Na co uważać: Zrównoleglanie ma granicę wydolności poznawczej — gdy kilka wątków zacznie się sypać, „zamrożenie” i utrata dnia są realne. Prostota bije złożoność.
5.Model lokalny może obsłużyć większość pracy
Na czym polega: Autor 80% pracy wykonuje na Qwen 3.6 (27 mld) na RTX 5090 — model niepozorny w rankingach inteligencji, ale bardzo szybki (110 tok/s przy kwantyzacji Q6) i „premium” w odczuciu.
Jak stosować: Rozważ dobry, kompaktowy model lokalny jako konia roboczego do asystowania, drobnego kodowania i zadań rutynowych, rezerwując chmurę na 20% najtrudniejszych przypadków.
Na co uważać: „Mniejszy” model ma zauważalną lukę w kodowaniu i pracy agentowej — sprawdź, czy twoje kluczowe zadania mieszczą się w jego możliwościach, zanim na nim polegniesz.
6.Dobieraj model do rodzaju zadania, nie do rankingu
Na czym polega: Do badań (biologia, cyberbezpieczeństwo) liczy się brak nadmiernych zabezpieczeń (np. Kim K3), do pisania — głos i oryginalność (np. GLM 5.2), do prywatności — model lokalny.
Jak stosować: Zdefiniuj priorytet zadania (jakość / szybkość / prywatność / brak guard rails / styl) i pod niego dobierz model, zamiast wybierać ten z najwyższym ogólnym wynikiem.
Na co uważać: Modele z mocnymi zabezpieczeniami potrafią blokować legalne badania; z kolei modele bez zabezpieczeń wymagają większej własnej odpowiedzialności za zastosowanie.
7.Stabilność modeli chmurowych jest złudna
Na czym polega: Dostawcy ciągle optymalizują modele pod koszt i przepustowość, więc zachowanie tego samego modelu waha się z dnia na dzień — coś możliwego wczoraj bywa niemożliwe jutro.
Jak stosować: Jeśli budujesz proces zależny od powtarzalnego wyniku, testuj go regularnie i nie zakładaj, że raz zestrojony prompt zostanie stabilny. Model lokalny daje pełną kontrolę nad tym, kiedy coś się zmienia.
Na co uważać: Budowanie biznesu na chmurowym modelu oznacza, że dostawca może zmienić jego moc, cenę lub dostęp — to realne ryzyko operacyjne, nie teoria.
8.Testuj model przed inwestycją w sprzęt
Na czym polega: Zanim autor kupił sprzęt, uruchomił docelowy model przez OpenRouter i testował go kilka dni, sprawdzając, czy jest wart kosztu i wykona realną pracę.
Jak stosować: Przed zakupem GPU/serwera odpal ten sam model przez usługę API (np. OpenRouter) na swoich rzeczywistych zadaniach. Dopiero po walidacji policz zwrot z inwestycji.
Na co uważać: Parametry sprzętu (np. okno kontekstu 131 tys. tokenów na 5090, liczba równoległych instancji) mocno zależą od karty — większy kontekst lub większy model oznacza wolniejsze działanie lub więcej sprzętu.
9.Traktuj AI jak bardzo dobrego aktora, nie jak rozumny byt
Na czym polega: Model nie „rozumie” — odtwarza najbardziej prawdopodobne tokeny tak precyzyjnie, że wynik jest użyteczny, ale nie można mu bezgranicznie ufać.
Jak stosować: Ustaw wymagany „poziom gry” pod zadanie — nie każde wymaga maksymalnego myślenia. Weryfikuj wyniki, zwłaszcza tam, gdzie odpowiadasz przed klientem.
Na co uważać: Wysoka pewność i płynność odpowiedzi nie są dowodem poprawności; im ważniejsze zadanie, tym bardziej potrzebna kontrola wyjścia.
10.Optymalny jest układ hybrydowy: lokalnie + chmura wg zadania
Na czym polega: Zamiast myślenia „albo–albo” autor łączy model lokalny (80%) z kilkoma subskrypcjami chmurowymi (20%), dobieranymi do konkretnego zadania — plus workflow kodowania od planowania (duży model) po drobne poprawki (mały model).
Jak stosować: Zbuduj własną proporcję lokalne/chmura, przypisując ciężkie planowanie i debugging do modeli mocnych, a implementację i drobne zmiany do tańszych. W kodowaniu: najpierw rozpisz plan mocnym modelem, potem deleguj wykonanie, a poprawki oddaj modelowi lokalnemu.
Na co uważać: Każdy wybór ma wadę — lokalny to koszt sprzętu, chmurowy to koszt wartości, środowiska i zależności. Decyzję o rezygnacji z danego dostawcy (jak autor z Anthropic) podejmuj świadomie i z uwzględnieniem wymagań biznesowych, które mogą ją unieważnić.