Benchmarking modelu na szerokich rankingach (leaderboardach) mówi ci, jak dobrze radzi sobie on z ciekawostkami i testami standaryzowanymi. Nie mówi ci prawie nic o tym, jak będzie rozumować w obliczu nieuporządkowanych, ograniczonych problemów, z którymi faktycznie mierzą się twoje systemy produkcyjne. Zanim udostępnisz jakikolwiek duży model językowy użytkownikom, potrzebujesz zestawu testowego (harness), który obciąży konkretne wzorce poznawcze wymagane przez twoją aplikację. Benchmarki rozumowania to moment, w którym modele odróżniają się od chatbotów.

Ten przewodnik przeprowadzi cię przez proces budowania skoncentrowanego benchmarku rozumowania od podstaw. Porównasz trzy odrębne architektury: DeepSeek R1 671B MoE, Llama 3.3 70B oraz Qwen 3 32B. Zamiast składać klastry GPU, uruchomisz wszystkie trzy modele za pomocą Oxlo.ai. Do ewaluacji wykorzystasz Kimi K2.6 jako sędziego, który oceni odpowiedzi pod kątem jasności rozumowania, poprawności oraz jakości kodu.

Dlaczego rozumowanie zawodzi jako pierwsze

Awarie produkcyjne rzadko objawiają się jako błędy gramatyczne czy odmowy. Przypominają raczej subtelne błędy logiczne. Model może generować pewny siebie tekst, jednocześnie błędnie interpretując ograniczenie, pomijając krok lub po cichu zmieniając zmienną w trakcie procesu. Publiczne benchmarki często stawiają na szerokość, a nie na głębię, więc model może uzyskać wysoki wynik, nie rozwiązując nigdy trudnego problemu kombinatorycznego.

Ukierunkowany benchmark wymusza rozwiązanie problemu. Przypisuje każdemu modelowi to samo zadanie optymalizacji z ograniczeniami, wymaga możliwego do prześledzenia łańcucha myśli (chain of thought) i mierzy, czy wygenerowane rozwiązanie faktycznie spełnia zasady. Jeśli model nie potrafi konsekwentnie rozumować w zakresie matematyki dyskretnej, nie poradzi sobie również niezawodnie z alokacją zapasów, silnikiem harmonogramowania czy routerem zasobów.

Modele i platforma

DeepSeek R1 671B MoE wykorzystuje architekturę mixture-of-experts. Tylko ułamek jego 671 miliardów parametrów aktywuje się dla danego tokenu, co zmienia krzywą kosztów do wydajności, a czasem nawet charakter jego rozumowania. Llama 3.3 70B to model gęsty (dense), natomiast Qwen 3 32B działa w mniejszej skali, oferując przy tym silne możliwości wielojęzyczne i programistyczne. Porównanie tych trzech modeli powie ci, czy jakość rozumowania koreluje z całkowitą liczbą parametrów, liczbą parametrów aktywnych, czy metodologią trenowania.

Oxlo.ai hostuje te modele za pomocą ujednoliconego API. Nie musisz zarządzać infrastrukturą wnioskowania ani użerać się z oddzielnymi umowami z dostawcami. Platforma stosuje również rozliczenia za zapytanie (per-request), a nie za token (per-token). Systemowy prompt liczący dwa tysiące słów kosztuje dokładnie tyle samo, co lakoniczne zdanie. Ten szczegół ma większe znaczenie, niż się wydaje. Oznacza to, że możesz pisać wyczerpujące instrukcje, zawierać szczegółowe wymagania dotyczące formatowania i osadzać przykłady few-shot, nie obserwując gwałtownego wzrostu kosztów tokenów wejściowych. Płacisz za wywołanie, a nie za gadatliwość.

Będziesz potrzebować Pythona w wersji 3.10 lub nowszej, biblioteki OpenAI Python oraz klucza API Oxlo.ai.

Krok 1: Połączenie z punktem końcowym

Ponieważ Oxlo.ai udostępnia API kompatybilne z OpenAI, integracja jest prosta. Skieruj OpenAI SDK na adres URL bazowy Oxlo, podaj swój klucz API i zweryfikuj połączenie za pomocą lekkiego zapytania do DeepSeek R1. Nie pomijaj testu poprawności (sanity check). Potwierdź opóźnienie (latency), sprawdź, czy identyfikator modelu jest rozpoznawany i upewnij się, że twoje środowisko potrafi strumieniować lub buforować format odpowiedzi, który zamierzasz przechowywać. Gdy nawiązanie połączenia (handshake) zadziała, będziesz mieć jednego klienta, który może odwoływać się do wszystkich trzech modeli poprzez zmianę jednego ciągu znaków.

Krok 2: Projektowanie zadania

Wybierz problem, który wymaga logicznego myślenia krok po kroku i posiada obiektywnie mierzalną odpowiedź. Problem pakowania do pojemników (bin-packing) sprawdza się wyjątkowo dobrze. Jest to problem NP-trudny, co oznacza, że heurystyki zachłanne zawodzą w przewidywalny sposób, a model jest zmuszony do śledzenia wielu ograniczeń jednocześnie. Przedmioty o różnych rozmiarach muszą zmieścić się w pojemnikach o stałej pojemności, nie przekraczając limitów.

Sformułuj prompt tak, aby model musiał zrobić dwie rzeczy: opisać swój proces rozumowania, a następnie dostarczyć działający kod Python rozwiązujący dany przypadek. Użyj promptu systemowego, który wyraźnie wymaga od modelu pokazania łańcucha myśli (chain-of-thought) przed napisaniem jakiegokolwiek kodu. Jest to szczególnie ważne w przypadku DeepSeek R1, który jest zoptymalizowany pod kątem rozbudowanych ścieżek rozumowania. Chcesz sprawdzić, czy model faktycznie analizuje sprawdzenia pojemności, czy jedynie dopasowuje wzorce do danych treningowych. Dobre zadanie powinno być na tyle konfrontacyjne (adversarial), aby odpowiedzi szablonowe zawiodły.

Krok 3: Uruchomienie benchmarku

Przekaż ten sam prompt modelom DeepSeek R1, Llama 3.3 70B oraz Qwen 3 32B. Zapisz pełne odpowiedzi tekstowe, a nie tylko końcowe bloki kodu. Przechowuj je wraz ze znacznikami czasu i identyfikatorami modeli. Ponieważ Oxlo.ai nalicza opłaty za każde zapytanie, nie musisz skracać promptu ani usuwać instrukcji doprecyzowujących, aby oszczędzić pieniądze. Możesz pozwolić sobie na precyzję. Ta stabilność pozwala na iterowanie nad projektem promptu bez obaw o koszty, co prowadzi do czystszych eksperymentów i bardziej powtarzalnych wyników.

Uruchom każdy model wielokrotnie, jeśli Twój budżet na to pozwala. Modele rozumujące (reasoning models) mogą różnić się w zależności od stochastycznej natury generowania odpowiedzi, a Ty chcesz wiedzieć, czy wysoki wynik oznacza stałą kompetencję, czy jedynie szczęśliwy traf.

Krok 4: Ocena za pomocą sędziego LLM

Ręczne ocenianie nie skaluje się, ale same numeryczne rubryki pomijają niuanse. Złotym środkiem jest sędzia LLM. W tym przypadku użyjesz Kimi K2.6. Przekaż mu oryginalny problem, rubrykę ocen oraz każdą z odpowiedzi kandydatów. Poproś go o ocenę trzech konkretnych wymiarów:

  • Jasność rozumowania: Czy wyjaśnienie faktycznie śledzi logikę, czy jedynie operuje ogólnikami?
  • Poprawność: Czy zaproponowane rozwiązanie spełnia wszystkie określone ograniczenia?
  • Jakość kodu: Czy kod Python jest czysty, możliwy do uruchomienia i wolny od oczywistych błędów?

Poleć sędziemu zwracanie wyników w formacie JSON. Ustrukturyzowany wynik sprawia, że porównywanie (diffing) rezultatów, wykresy trendów i zasilanie automatyzacji w dalszych etapach staje się banalnie proste. Trzymaj się rygorystycznego promptu dla sędziego. Jeśli dasz mu niejasną instrukcję, taką jak „oceń odpowiedź”, otrzymasz niejasne wyniki. Zamiast tego zdefiniuj, co stanowi poprawne rozwiązanie problemu bin-packing. Pojemności nie mogą zostać przekroczone. Każdy element musi zostać przypisany. Kod musi być poprawny składniowo. Im bardziej konkretne będą Twoje kryteria, tym bardziej wiarygodne staną się oceny.

Zawsze dokonuj kontroli sędziego. Jeśli Kimi K2.6 konsekwentnie zawyża ocenę jednego modelu ze względu na powierzchowną estetykę, Twój benchmark jest wadliwy. Mała warstwa ludzkiego audytu zapobiega błędowi typu „garbage-in-garbage-out” (śmieci na wejściu, śmieci na wyjściu).

Krok 5: Budowa raportu

Agreguj wyniki JSON i łącz je z fragmentami surowych odpowiedzi modeli. Umieść wszystko w jednym pliku w swoim repozytorium. Gdy zaktualizujesz wersję modelu lub zmodyfikujesz prompt, różnica (diff) w Twoim pull requeście pokaże dokładnie, jak zmieniło się zachowanie. Dobrze utrzymywany benchmark staje się żywą dokumentacją. Uzasadnia on, dlaczego Twój potok produkcyjny korzysta z jednego modelu zamiast innego, i wyłapuje ciche regresje, zanim dotrą one do użytkowników.

Skonstruuj raport tak, aby współpracownik mógł go przeczytać bez uruchamiania kodu. Uwzględnij treść problemu, szablon promptu, wyniki oraz reprezentatywne cytaty z procesu rozumowania każdego modelu. Przejrzystość ma znaczenie. Jeśli DeepSeek R1 uzyska wysoki wynik, ale zhalucynuje ograniczenie, chcesz, aby było to widoczne w fragmencie tekstu, a nie ukryte w średniej.

Automatyzacja potoku

Benchmark, który istnieje tylko na Twoim laptopie, zostanie zapomniany w ciągu tygodnia. Przenieś go do nocnego zadania CI. Co noc środowisko testowe (harness) uruchamia się, odpytuje aktualne wersje modeli na Oxlo.ai, wykonuje zadanie bin-packing, ocenia wyniki i zatwierdza (commit) rezultaty. Jeśli aktualizacja modelu spowoduje spadek poprawności o dziesięć punktów, dowiesz się o tym szybciej niż Twoi użytkownicy.

Gdy podstawowe środowisko będzie stabilne, rozszerz je. Testuj warianty z długim kontekstem, wypełniając prompt nieistotnymi dokumentami, a następnie umieszczając pytanie o bin-packing na samym końcu. Duże okna kontekstowe są bezużyteczne, jeśli rozumowanie załamuje się pod wpływem szumu. Sprawdź, które modele zachowują dyscyplinę logiczną, gdy sygnał jest pogrzebany w dziesięciu tysiącach tokenów rozpraszających informacji.

Kluczowy wniosek

Publiczne rankingi (leaderboards) mierzą ogólną wiedzę. Twoja aplikacja mierzy coś węższego i trudniejszego. Proste, powtarzalne środowisko testowe, które zmusza modele do rozumowania w ramach optymalizacji z ograniczeniami, ocenia je według spójnych kryteriów i wersjonuje wyniki w systemie git, dostarczy Ci bardziej praktycznych informacji niż jakikolwiek zagregowany wynik. Zbuduj benchmark dopasowany do Twojego problemu, uruchom go na architekturach, które Cię interesują, i pozwól, aby wyniki dyktowały Twój wybór produkcyjny.

Źródło: DeepSeek R1 Model Architecture and Benchmarks

Społeczność: GyaanSetu AI na Telegramie