Autor: Jakub Rusinowski · Ostatnia aktualizacja 2026-08-04 · Wartości sprzętowe wyliczone naszym silnikiem VRAM
Publiczne benchmarki mówią, które modele z czołówki prowadzą; nie mówią, czy Devstral-2 22B bije Qwen 3.6 27B na twoim monorepo w TypeScripcie, bo wyniki są mocno pythonowe, a każda liczba zakłada konkretny harness agenta. Zbuduj zamiast tego małą ewaluację: dwadzieścia prawdziwych zadań z własnej historii gita, każde z deterministyczną kontrolą zaliczenia, uruchamiane po trzy razy na konfigurację. Weekend przygotowań i każda późniejsza decyzja o modelu czy harnessie opiera się na dowodach.
Dwa pytania wracają bez przerwy, a publiczną odpowiedź ma tylko jedno. „Który otwarty model jest najmocniejszy?” — tym zajmują się rankingi benchmarków, a krajobraz śledzi nasz datowany Raport #2. „Czy ten model wykona *moją* pracę?” — na to nie odpowiada nic z publikowanych rzeczy, a przepaść między tymi dwoma pytaniami to źródło większości rozczarowań lokalnymi agentami kodującymi.\n\nTa przepaść ma trzy przyczyny. Benchmarki są mocno przechylone w stronę Pythona i w stronę jednego określonego rodzaju zadań naprawczych. Każdy wynik powstaje w konkretnym harnessie, a te same wagi punktują zupełnie inaczej pod innym — co dokładnie tłumaczy, dlaczego harness warto inżynierować. No i przebiegi benchmarków zakładają długość kontekstu i kwantyzację, które mogą nie mieć nic wspólnego z tym, co serwuje twoja karta.
Warto wiedzieć, żeby czytać je poprawnie, a nie odrzucać.\n\n| Benchmark | Co robi | Co mówi lokalnie |\n|---|---|---|\n| SWE-bench Verified | Prawdziwe zgłoszenia z GitHuba; łatka musi doprowadzić testy repozytorium do zieleni | Najlepszy pojedynczy predyktor przydatności agentowej — ale mocno pythonowy i zależny od harnessu |\n| SWE-bench Pro | Trudniejszy wariant o dłuższym horyzoncie | Porządkuje czołówkę; modele z lokalnych progów ściskają się przy dolnej krawędzi |\n| Terminal-Bench | Zadania w prawdziwym środowisku terminalowym | Najbliższy odpowiednik pracy agenta terminalowego; czuły na jakość wywoływania narzędzi |\n| HumanEval / MBPP | Uzupełnianie samodzielnych funkcji | Niemal wysycone i w kontekście agentów mało informatywne. Do tego celu pomiń |\n| Aider polyglot | Trzymanie się formatów edycji w wielu językach | Nietypowo istotny lokalnie — mierzy, czy model potrafi wyprodukować dający się nałożyć diff |\n\nDwie zasady czytania. Zawsze sprawdzaj, jaki harness dał daną liczbę — wynik na karcie modelu to wynik modelu razem z rusztowaniem, a podmiana rusztowania go przesuwa. Dyskontuj na kwantyzację i kontekst: publikowane liczby to zwykle pełna precyzja i hojne okna, a ty pracujesz na Q4 przy 16–32K. Ta różnica jest zwykle niewielka przy prostej pracy i rośnie przy długich zadaniach na wielu plikach.\n\nRozsądny użytek z rankingów to wybranie dwóch albo trzech kandydatów na swój próg. Decyzja przychodzi z twojej własnej ewaluacji.
Twoja historia gita to oetykietowany zbiór danych, którego nikt inny nie ma: każdy commit naprawiający błąd jest zadaniem ze znanym dobrym rozwiązaniem, a jeśli masz testy — również z wbudowanym weryfikatorem.
1 · Wykop zadania. Wybierz 20 commitów, które coś naprawiły i dotknęły od jednego do trzech plików. Preferuj te, w których razem z poprawką zmienił się test — ten test jest twoją kontrolą.
git log --oneline --no-merges --grep='^fix' -n 60 --format='%h %s'
git show --stat <sha> # zostaw te dotykające 1-3 plików2 · Zamień każdy w zadanie. Dla każdego commita zapisz: SHA rodzica (stan wyjściowy), jednoakapitowy opis zadania napisany tak, jakbyś wprowadzał w nie kolegę — *bez* nazywania samej poprawki — oraz polecenie kontrolne, które ma potem przejść.
tasks/
001-null-user-session/
base.sha # parent commit
prompt.md # "Sessions for anonymous users crash on refresh. Fix it."
verify.sh # pytest tests/test_session.py -q3 · Uwzględnij nudny środek. Dwadzieścia zadań, z których każde jest trudne, powie ci tylko „nie”. Celuj mniej więcej w 8 łatwych (jeden plik, oczywiste), 8 średnich (dwa albo trzy pliki, trzeba poszukać) i 4 trudne (przecinające wiele miejsc). Ten rozkład powinien wyglądać jak twój prawdziwy tydzień.
4 · Dołóż zadania-pułapki. Dwa albo trzy, w których właściwą odpowiedzią jest „to jest niedookreślone” albo w których poprawka wymagałaby ruszenia pliku zakazanego przez reguły. Modele, które z przekonaniem robią złą rzecz, są gorsze od modeli, które się zatrzymują — a żaden publiczny benchmark tego nie mierzy.
#!/usr/bin/env bash
# eval.sh — przepuść każde zadanie przez jedną konfigurację, 3 ziarna
CONFIG="$1" # etykieta, np. devstral22b-aider-16k
for task in tasks/*/; do
for seed in 1 2 3; do
git worktree add -f /tmp/ev -b ev-tmp "$(cat "$task/base.sha")" >/dev/null
( cd /tmp/ev && timeout 900 run-agent.sh "$task/prompt.md" )
( cd /tmp/ev && bash "../../$task/verify.sh" ) && r=PASS || r=FAIL
echo "$CONFIG,$(basename "$task"),$seed,$r" >> results.csv
git worktree remove -f /tmp/ev; git branch -D ev-tmp
done
doneZasady, dzięki którym wyniki są porównywalne:
Sam odsetek zaliczeń ukrywa różnice, które decydują o tym, czy zostaniesz przy danej konfiguracji.\n\n- Pass@1 w podziale na koszyki trudności. Model, który zalicza wszystkie zadania łatwe i żadnego trudnego, wciąż jest użytecznym modelem — do zadań łatwych. To wniosek, na którym da się działać; zagregowana liczba nim nie jest.\n- Mediana tur do zieleni. Najlepszy przybliżony obraz tego, jak się z tym *pracuje*. Dwa modele o tym samym odsetku zaliczeń i różnicy 3 kontra 9 tur to nie są porównywalne narzędzia.\n- Wskaźnik zepsutych wywołań narzędzi. Powyżej mniej więcej jednego na dwadzieścia napraw konfigurację, zanim uwierzysz w cokolwiek innego, co pokazuje ewaluacja (tool calling).\n- Rozmiar diffa wobec ludzkiej poprawki. Lokalne modele często zaliczają, zmieniając zdecydowanie za dużo. Dwustuwierszowy diff na sześciowierszową poprawkę to porażka na przeglądzie, nawet gdy zestaw testów jest zielony.\n- Wskaźnik oszukiwania. Jak często edytował testy, dopisywał any albo pomijał asercje. Puszczaj git diff --stat -- tests/ na każdym wyniku; to liczba, która dzieli agenta użytecznego od efektownego.\n- Czas na zegarze na zadanie. Na lokalnym sprzęcie to on decyduje, czego naprawdę będziesz używać.
Wnioski powtarzające się na tyle często, że można się ich spodziewać:\n\n1. Zmiany w harnessie biją zmiany modelu, do pewnego momentu. Podniesienie serwowanego kontekstu, dodanie pliku z regułami i danie agentowi polecenia testowego rutynowo przesuwają odsetek zaliczeń mocniej niż przeskok o próg modelu — i nie kosztują ani gigabajta VRAM-u. Te eksperymenty rób pierwsze.\n2. Próg niżej, niż zakładasz, często wystarcza. Wiele zespołów odkrywa, że ich prawdziwy rozkład to 80% zadań łatwych i średnich, gdzie model 16 GB dorównuje temu z 24 GB przy dwukrotnie wyższym tempie.\n3. Kwantyzacja waży mniej niż kontekst. Q4 kontra Q5 zwykle mieści się w szumie tego rodzaju ewaluacji; 8K kontra 32K już nie.\n4. Koszyk trudny to miejsce, w którym lokalne się wypłaszcza. Zadania przecinające wiele miejsc to obszar, gdzie modele z czołówki wciąż odjeżdżają — co dokładnie mówi ci, gdzie hybrydowe zejście awaryjne zarabia na siebie i jak często faktycznie byś z niego korzystał.\n5. Twoja ewaluacja się starzeje. Puszczaj ją ponownie, gdy pojawia się nowy model albo gdy zmieniasz harness. Gdy raz istnieje, zajmuje godzinę i zamienia „nowy model wydaje się lepszy” w liczbę.
Jeśli dwadzieścia zadań to na start za dużo, pięć to nie jest zero. Weź pięć ostatnich commitów naprawczych, napisz prompty, jako kontroli użyj istniejących testów, uruchom każde trzy razy na swojej obecnej konfiguracji i zapisz odsetek zaliczeń oraz medianę tur. Ta jedna liczba mówi już o twoim repozytorium więcej niż jakikolwiek ranking — a przy okazji daje ci punkt odniesienia, co jest tu najważniejsze. Każda kolejna zmiana konfiguracji staje się porównaniem zamiast zgadywanki.
Puszczenie tej samej ewaluacji na modelu, którego twoja karta nie udźwignie, to najczystszy sposób, żeby sprawdzić, czy wymiana sprzętu ma sens. Wynajmij większe GPU na wieczór, puść dwadzieścia zadań i niech zdecyduje odsetek zaliczeń.
Pełna lista w katalogu chmurowej AI.