W jednym tygodniu byłem na dwóch spotkaniach o sztucznej inteligencji: w czwartek o komunikacji marki, w piątek o modelach uruchamianych lokalnie. Publiczność i poziom abstrakcji zupełnie inne, a oba wieczory krążyły wokół jednego pytania: jak zmierzyć coś, co za każdym razem zachowuje się inaczej. Brakowało tylko jednego pomiaru, tego, który dla większości firm waży najwięcej.
Czwartek: jak trzy modele oceniają ten sam mail
17 września, Centrum Badawczo-Rozwojowe Rekord SI. „Komunikacja w dobie promptów” z cyklu Upgrade Your Business, organizowane przez Fundację Startup Podbeskidzie. Punkt wyjścia: skoro AI przyspiesza produkcję treści, coraz trudniej odróżnić jedną markę od drugiej.
Paweł Sala, współzałożyciel i były CEO FreshMaila, pokazał coś, czego się nie spodziewałem: jak trzy modele oceniają te same wiadomości i jak bardzo się przy tym różnią.
- Claude wypadł jak analityczny krytyk, który wie, dla kogo ocenia, i dostosowuje priorytety do odbiorcy. Daje kredyt za dobry temat nawet wtedy, gdy treść technicznie zawodzi. Faworyzuje maile istotne dla konkretnej osoby.
- ChatGPT to rzetelny recenzent bez uprzedzeń, równomierny i przewidywalny. Najbardziej zachowawczy z całej trójki: rzadko daje piątkę, rzadko jedynkę. Ocenia jakość komunikatu bardziej niż jego istotność.
- Gemini kategoryzuje, zamiast oceniać. Najbardziej binarny: błąd techniczny to natychmiastowa jedynka, świetna treść natychmiastowa piątka. Surowy egzaminator, albo zdajesz, albo nie.

Ten sam tekst dostaje trzy różne oceny, bo każdy z modeli pyta o co innego. Jeśli dopracujesz mail pod jeden, pozostałe dwa mogą tego w ogóle nie zauważyć. Porada „pisz lepsze maile” takich rzeczy nie obejmuje.
Druga część poszła jeszcze dalej: model czyta wiadomość w kontekście całej skrzynki. Nagła zmiana tonu albo treści u nadawcy, którego znasz, wygląda nienaturalnie i obniża ocenę. Historia działa też w drugą stronę, bo jeśli dostawałeś już sporo wiadomości na jakiś temat, model uznaje, że Cię on interesuje, i kolejną traktuje poważniej.
Najlepiej widać to na ofertach sprzedażowych. Klasyczne „kup do 23:59, bo promocja się kończy” model rozpoznaje od razu, bo widzi, że podobna wiadomość wychodzi co tydzień. Zamiast okazji dostaje wtedy etykietę rutynowej oferty, opisanej niezupełnie rzetelnie. Typowy scam wyłapuje równie łatwo.
Dla nadawcy to niewygodny wniosek: na ocenę pojedynczego maila pracuje wszystko, co wysyłałeś przez ostatnie miesiące.
Tego akurat nie trzeba zgadywać. Konektory pozwalają dziś podłączyć wybranego agenta wprost do własnej skrzynki, więc to samo, co model robi z Twoim mailem u odbiorcy, możesz sprawdzić u siebie, na własnej korespondencji.
Reszta wystąpienia trzymała się klasyki, która działa niezależnie od AI: emocje jako fundament decyzji (za Antoniem Damasio), efekt ramowania, czyli „oszczędzasz 200 zł rocznie” działa silniej niż „to tylko 16 zł miesięcznie”, choć matematycznie wychodzi na jedno, oraz reguła zaangażowania: kto zrobił mały krok, chętniej zrobi następny.
Olga Wilczyńska prowadziła tę samą myśl od strony tekstu. Jej teza: w świecie, w którym każdy może pisać jak ekspert, wygrywa ten, komu ludzie wierzą. Stąd dwie reguły, które zapamiętałem. Nie nazywaj emocji, pokaż sytuację, czyli zamiast „Twoje dziecko ma problemy z matematyką” opisz ten wieczór, który po dwudziestu minutach kończy się płaczem. I nie pisz, co klient dostanie, tylko co z tego ma: „zabieg trwa 40 minut” zmienia się w „możesz zrobić go w piątek i wrócić do pracy bez tłumaczenia wszystkim, co zrobiłaś z twarzą”.
Trzecie wystąpienie, Mateusza Miernikowskiego z Konceptiki, szło pod hasłem „A co, jeśli nie musimy więcej mówić, tylko więcej pytać?”. Zamiast kolejnych porad o pisaniu dostaliśmy zestaw pytań, które firma powinna zadać samej sobie, a potem przepuścić przez model razem z własnymi dokumentami: co naprawdę sprzedajemy, na czym naprawdę zarabiamy, co możemy wiarygodnie obiecać, w czym jesteśmy lepsi od konkurencji i gdzie leży luka między obietnicą a doświadczeniem klienta.
Najciekawsza była dyscyplina wpisana w same prompty. Każdy każe modelowi opierać się wyłącznie na dostarczonych materiałach, wskazywać przy każdym wniosku dokument, który go potwierdza, oddzielać fakty od hipotez i nazywać brakujące dane zamiast je zgadywać. Na tym polega różnica między pytaniem modelu o opinię a użyciem go do analizy, i to jest wzorzec wart skopiowania niezależnie od tego, czym się zajmujesz.
Piątek: dwa sposoby mierzenia modeli
Dzień później, ta sama miejscowość, ten sam Rekord, tym razem przy Kasprowicza 3. Drugie spotkanie bielsko.ai, społeczności AI z Podbeskidzia, prowadzonej przez Tomasza Kielara i Michała Staśkiewicza. Spotkanie weszło do programu festiwalu BBDays4.IT, z dwudniowym hackathonem w planie, i zebrało pełną salę.
Gościem był Przemek Smyrdek, współzałożyciel 10xDevs, z tematem pomiarów modeli i narzędziem 10xBench. Nie było to jego pierwsze wystąpienie w Bielsku: w kwietniu mówił o tym samym na deBBugu, trzeciej edycji meetupu bielskiej społeczności IT prowadzonego przez Artura Dordę, pod tytułem „Jak znaleźć (własnego) najlepszego Agenta AI do programowania?”. Jego teza była prosta i niewygodna:
Publiczne benchmarki nic nie mówią o Twoich zadaniach.

Ranking, w którym model X bije model Y, powstał na czyimś zestawie zadań. Twój projekt ma swój stack, swoje konwencje i swoje pułapki, i dopiero na nich widać, który model faktycznie dowozi.
Dla mnie akurat nie było to odkrycie, bo 10xBench poznałem właśnie na tamtym kwietniowym deBBugu, jeszcze zanim zacząłem kurs 10xDevs. Ale ta wiedza praktycznie nie wychodzi poza wąskie grono. W środowisku, w którym się obracam, mierzenie modeli na własnych zadaniach jest oczywistością, a poza nim wybór modelu wciąż najczęściej sprowadza się do tego, co ktoś napisał w sieci albo co akurat wyszło w czyimś rankingu. Dlatego warto to spisać.
10xBench służy do tego, żeby to zmierzyć: puszczasz ten sam zestaw zadań przez kilka modeli i porównujesz cztery rzeczy, czyli czas, liczbę pomyłek, liczbę trafień i koszt. Nie darmo, bo sensowny przebieg przez kilkanaście modeli z OpenRoutera to wydatek rzędu 100-200 dolarów. Tyle że płacisz raz, a odpowiedź odcinasz kuponami przez kolejne miesiące.
Publiczne wyniki zespołu Przeprogramowanych są dostępne na 10xbench.ai: szesnaście rodzin modeli, od GPT i Claude’a przez Gemini po DeepSeeka, Qwena i Kimi, każdy w kilku podejściach do tego samego zadania, oceniany po tym, czy projekt się zbudował, czy trzyma się zadanego stacku, czy jest responsywny i czy ma zrobione SEO. Zadaniem referencyjnym jest zbudowanie strony Przeprogramowani.pl w Astro, Reactcie i Tailwindzie na Cloudflare.
Zabawny zbieg okoliczności, bo to prawie dokładnie stack, na którym stoi strona, którą właśnie czytasz. A teza Przemka i tak się broni, bo nawet benchmark zbudowany na moim stacku mierzy cudzy projekt, z cudzymi konwencjami i cudzymi pułapkami. Dobry punkt wyjścia i na tym koniec.
Jedno zastrzeżenie do tamtych kwietniowych wyników: część modeli wyszła kilka dni przed spotkaniem albo w jego dniu, więc po prostu nie zdążyła wejść do testu. To zresztą samo w sobie pokazuje, na czym polega problem z rankingami: zestawienie starzeje się szybciej, niż zdąży się rozejść.
Z tego, co wtedy wyszło, zapamiętałem dwie rzeczy. Pierwsza: Codex bardzo dobrze radzi sobie z konkretnym, nazwanym stackiem, czyli Astro, React, Laravel, i pisze od razu nowoczesny front, bez dopowiadania w prompcie, o którą wersję chodzi. Druga, ważniejsza: dobry wynik na froncie nie przekłada się na backend. To są dwie osobne umiejętności i mierzyć trzeba je osobno.
Z własnych pomiarów wychodzą rzeczy, których żaden publiczny ranking nie pokaże. Droższy model bywa gorszy, model z większym oknem kontekstu też. Zdarza się, że mimo wyraźnego polecenia w prompcie nie wykonuje instrukcji do końca albo pomija testy. Sam GPT-5.6 występuje w kilku wariantach o różnej cenie, a średnia ocena z tego samego zestawu zadań wychodzi im zauważalnie różnie.
Wiek danych treningowych boli najbardziej
Jest jeszcze jedna rzecz, której ranking nie pokaże, a która w praktyce kosztuje najwięcej czasu: model zna tę wersję frameworka, na której go wytrenowano. U mnie widać to najwyraźniej na Astro i na FilamentPHP, bo obydwa zmieniają API szybciej, niż domykają się cykle treningowe. Efekt jest zawsze taki sam: kod wygląda sensownie, a nie działa, bo odwołuje się do przestrzeni nazw i funkcji, których w bieżącej wersji już nie ma. Potem idzie kilka rund poprawiania tego samego.
Zamiast walczyć z tym promptem, trzymam u siebie osobne pliki reguł dla takich frameworków, na przykład dla Filamenta w wersji 5, z wypisanymi zmianami przestrzeni nazw względem trójki i czwórki. Model dostaje to do kontekstu, zanim zacznie pisać, i przestaje zgadywać na podstawie tego, co pamięta z treningu. Raz porządnie spisana wiedza wygrywa z poprawianiem w kółko tego samego błędu.
Wybór modelu zaczyna się więc od tego, jaki masz stack, a kończy na tym, ile pracy włożysz w kontekst i precyzję poleceń. Ranking leży gdzieś po drodze i znaczy niewiele. Z moich obserwacji na froncie z nowym stackiem prowadzi dziś GPT, a przy zadaniach bardziej specyficznych bywa różnie. Z modeli chińskich coraz lepsze opinie zbiera Kimi i mam go na liście do sprawdzenia.
Ile tokenów na sekundę daje jedno urządzenie

Filip Brodka z CSHARK-a zaprezentował NVIDIA DGX Spark: model Qwen3.8-27B liczył na żywo, na sprzęcie stojącym w sali, bez żadnego API w tle. To model dense o 27,8 miliarda parametrów, natywnie multimodalny, na licencji Apache 2.0.
Najważniejsze zdanie całego wieczoru dotyczyło arytmetyki:
Sufit tokenów na sekundę = przepustowość pamięci ÷ rozmiar wag.
Przy przepustowości 273 GB/s daje to twardą granicę, której nie przeskoczy żadna konfiguracja. Ta sama maszyna, ten sam model, cztery warianty kwantyzacji:
| Wariant | Rozmiar wag | Tokeny na sekundę |
|---|---|---|
| BF16 | 55,6 GB | 4,9 |
| FP8 | 30,9 GB | 8,8 |
| NVFP4 | 25,7 GB | 10,6 |
| Q4_K_M | 17,1 GB | 16,0 |
Różnica między najcięższym a najlżejszym wariantem to ponad trzykrotność prędkości i wynika wprost z tego, ile bajtów trzeba przeczytać na każdy token.
Ten rachunek okazał się zaskakująco trafny. Przewidywał około trzynastu tokenów na sekundę i dokładnie tyle zmierzył sprzęt. To dobra wiadomość dla każdego, kto rozważa taki zakup, bo wydajność da się oszacować, zanim wyda się pieniądze. Liczyć ręcznie zresztą nie trzeba, bo jest do tego llmfit.
Gorsza wiadomość brzmi tak, że arytmetyka wyznacza dopiero podłogę. Po włączeniu jednej techniki programowej ten sam model na tym samym sprzęcie dał ponad cztery razy więcej. Rachunek mówi więc, czego na pewno można się spodziewać, a o resztę trzeba zapytać oprogramowanie i sprawdzić u siebie.
Cała konfiguracja, skrypty i wszystkie liczby z tej prelekcji są publiczne: github.com/fifeek0/bielskoAI.
Co z tego wynika dla firmy
Jedna taka maszyna wystarcza do prostszych zadań. Przy większych trzeba łączyć maszyny, a wtedy rachunek kosztowy przestaje się spinać, chyba że stawiasz to w centrum danych i zależy Ci na zamkniętym systemie offline, bo dane nie mogą wyjść na zewnątrz. Wtedy zaczyna to być realna opcja.
Dochodzi do tego trend, który zmienia ten rachunek bardziej, niż widać po samych cennikach: najmocniejsze modele albo drożeją, albo dostają limity. Dostęp do najlepszego wariantu coraz częściej bywa reglamentowany, a nie po prostu drogi, wystarczy spojrzeć na plany w rodzaju Codeksa 20x, gdzie płaci się za wyższy sufit zużycia.
I tu własny sprzęt zaczyna wyglądać inaczej. Przy zwykłym użyciu API nadal wychodzi taniej, ale własny sprzęt daje dwie rzeczy, których nie kupisz w abonamencie: nie ma na nim licznika i dane nie wychodzą poza budynek. Jeśli reglamentacja najmocniejszych modeli będzie się zaostrzać, ten rachunek przechyli się w stronę własnej maszyny szybciej, niż wynikałoby z porównania samych stawek.
Czego nikt nie zmierzył
Wszyscy czterej prelegenci mierzyli w gruncie rzeczy to samo, tylko w różnych skalach: maila na tle całej skrzynki, model na tle konkretnego projektu, sprzęt na tle przepustowości pamięci, firmę na tle jej własnych dokumentów.
Brakowało jednego pomiaru, a jest to ten, z którym prędzej czy później zmierzy się każda firma: co te systemy odpowiadają, kiedy ktoś z zewnątrz pyta o kogoś takiego jak Ty. Sam test zajmuje pięć minut. Zapytaj asystenta o swoją usługę dokładnie tak, jak zrobiłby to Twój klient, i sprawdź, czy się pojawiasz.
Wynik bywa nieprzyjemny, a przyczyna zwykle leży poza samą stroną. O tym, czy firma w ogóle wchodzi do zestawienia, decyduje to, czy pisze o niej ktoś poza nią: katalogi, rankingi, cudze relacje. Miejsca, których się nie kontroluje, i dlatego właśnie się liczą.
Olga mówiła, że wygrywa ten, komu ludzie wierzą. Dorzuciłbym do tego jedno zdanie: żeby ktoś Ci uwierzył, musi Cię najpierw zobaczyć.
Dobrze, że to się dzieje tutaj
Bielsko ma swoją scenę IT od dawna: meet.js zbiera ludzi od lat, BBDays4.IT wraca co roku, a firmy z branży mają tu siedziby. Nowe są spotkania poświęcone wyłącznie AI, i to w takiej liczbie, że da się chodzić regularnie zamiast raz na kwartał: deBBug ruszył wiosną, bielsko.ai latem. Staram się bywać na bieżąco, bo to stamtąd, a nie z rankingów w sieci, biorę większość rzeczy, które potem wchodzą mi do pracy.
Efekt tego tygodnia: usłyszałem, jak trzy modele oceniają te same maile, i zobaczyłem model liczący na sprzęcie stojącym dwa metry ode mnie. Po godzinach, dziesięć minut od domu.
Dzięki dla Fundacji Startup Podbeskidzie za czwartek, dla Tomasza Kielara i Michała Staśkiewicza za bielsko.ai oraz dla Artura Dordy za deBBug, od którego u mnie zaczęła się cała ta historia. Dzięki też dla prelegentów za to, że przywieźli liczby zamiast slajdów o rewolucji.
Jeśli jesteś z okolicy: zapisy na kolejne spotkania bielsko.ai idą przez Lumę, społeczność żyje na Discordzie, a w planach są hackathony. Warto wpaść, choćby posłuchać. Sala jest programistyczna, ale nikt tam nie sprawdza legitymacji.




