Przez jakiś miesiąc próbowałem dorównać naszym firmowym modelom modelami open-weight.
Nie w skali całej firmy — tylko w maszynowni. OwlMeans to pipeline rozwoju oparty na AI: opisujesz, czego chcesz, w formie historyjek użytkownika, a zespół wyspecjalizowanych ról AI zamienia je w pełnowymiarową aplikację, która jest Twoja. Pod maską każda z tych ról wywołuje model językowy. Dziś to kombinacja modeli Anthropic i OpenAI — Claude wykonuje większość ciężkiej roboty, a OpenAI dochodzi do gry przy konkretnych rolach. To zestaw, któremu ufam. Ma też swoją cenę.
Zrobiłem więc oczywisty eksperyment. Modele open-weight miały bardzo głośny rok — do połowy 2025 najlepsze open-weightowe LLM-y wychodziły z Chin, a GLM, Kimi, Qwen i DeepSeek wymieniały ciosy z firmową czołówką w codingu. Kosztują ułamek tamtej ceny. Gdyby udało mi się uruchomić mój pipeline na open weights bez pogorszenia wyników, matematyka była nie do odrzucenia.
Spędziłem miesiąc na podłączaniu ich, benchmarkowaniu i strojeniu. Oto co się naprawdę wydarzyło — łącznie z częścią, której się nie spodziewałem, a która okazała się sednem całej sprawy.
Zakład: pipeline powinien sprawić, że model jest wymienny
Oto rzecz, przez którą w ogóle uwierzyłem, że to zadziała.
OwlMeans nie podaje modelowi mglistego prompta i nie modli się o efekt. Rozbija projekt na bardzo małe, ściśle zakresowe zadania, z których każde działa na bardzo niewielkim kontekście — pojedyncza historyjka użytkownika, pojedyncza poprawka, zmiana w obrębie jednego pliku. Rola analityka biznesowego ramuje pracę, architekt ją projektuje, rola developera implementuje jeden plasterek, a fixer porządkuje. Nikt nie prosi jednego modelu, żeby „zbudował aplikację”. Prosi się go, żeby zrobił jedną małą, dobrze wyspecyfikowaną rzecz.
Ten projekt ma cichy efekt uboczny: im mniejsze i bardziej wyspecyfikowane zadanie, tym mniej ma znaczenia wybór modelu. Kiedy kontekst jest maleńki, a instrukcja precyzyjna, niemal każdy kompetentny model ląduje mniej więcej w tym samym miejscu. Mniej tu miejsca na błyskotliwość i mniej miejsca na zboczenie z drogi. To również dlatego nasze koszty tokenów pozostają rozsądne — badania nad pętlami agentowymi mówią wprost, że koszt tokenów rośnie z kwadratem kontekstu, który ponownie naliczasz na każdym kroku, więc utrzymanie małych zadań to różnica między rachunkiem do udźwignięcia a takim, który wymyka się spod kontroli.
Moja hipoteza była więc prosta: skoro pipeline już utowarawia zadanie, powinien utowarowić też model. Podmień firmowy model na GLM, a aplikacja, która wyjdzie na drugim końcu, powinna być w zasadzie tą samą aplikacją.
W większości miałem rację. I nie miało to znaczenia w taki sposób, w jaki liczyłem.
Co popsuło się jako pierwsze: modele, które myślą za dużo
Ścieżka open-weight nie poszła gładko.
Pierwszą ścianą były modele „myślące”. GLM, Kimi, Qwen — domyślnie rozumują. Brzmi świetnie, dopóki nie nałożysz twardego limitu na output, a model nie przepali całego budżetu na ciche rozumowanie i nie zwróci niczego. Pustą treść. Rola codera odpalała, model dochodził myśleniem aż do sufitu tokenów i oddawał pusty string. Pipeline krztusił się na nie-odpowiedzi.
Ustawiłem effort: none. Zostało po cichu zignorowane. Model dalej myślał.
To nie jest moja prywatna dziwactwo — to brudny sekret modeli rozumujących na produkcji. Reasoning effort jest, jak ujmuje to jeden dobry tekst, pokrętłem kosztu, a nie pokrętłem jakości: podkręć go, a potroisz tokeny myślenia za kilka punktów w benchmarku, a w zamian dostaniesz niespodzianki na rachunku i puste outputy, kiedy rozumowanie zjada miejsce, w którym miała mieszkać odpowiedź. Rozwiązanie było mało efektowne: twardy, absolutny limit tokenów rozumowania na rolę, strojony model po modelu, żeby myślenie nie głodziło outputu. Coderzy dostają krótką smycz na rozumowanie; role planujące dostają więcej luzu. Nie ma uniwersalnego ustawienia. Każdy model chciał własnego.
Drugą ścianą był structured output. Mój pipeline opiera się na tym, że modele zwracają czysty, zgodny ze schematem JSON, by kolejny etap mógł na nim działać. Firmowe API są w tym dziś bardzo dobre — tryb strict structured output od OpenAI sprowadza błędy formatu poniżej 0,1%. Wiele modeli open-weight, u wielu dostawców, jeszcze tam nie jest. Produkują zniekształcony JSON w sporej części odpowiedzi, zwłaszcza przy długich outputach i zagnieżdżonych schematach. Przestałem więc wymuszać JSON na chwiejnych modelach i pozwoliłem im zamiast tego korzystać z tool calls, a obsługę źródeł przepisałem tak, by agent wyłuskiwał tylko istotne fragmenty i nakładał patch-diffy zamiast przepisywać całe pliki. Mniejszy kontekst, mniej okazji do złamania formatu. Ta jedna zmiana zrobiła dla niezawodności open-weight więcej niż jakakolwiek podmiana modelu.
Trzecią ścianą byli sami dostawcy. Ten sam otwarty model zachowuje się różnie w zależności od tego, kto go hostuje — szybkość, niezawodność, a nawet to, czy structured output w ogóle działa. Przebenchmarkowałem ich stos. Niektórzy byli świetni. Niektórzy nie przechodzili walidacji schematu przy każdym wywołaniu. Niektórzy ucinali. Część po prostu nie potrafiła obsłużyć modeli, których potrzebowałem. Skończyło się na routowaniu przez OpenRouter, który rozkłada każdy model na ponad szesnastu–dwudziestu dostawców pod spodem i przełącza się między nimi przy awarii — i oparłem się na jego wariancie :nitro, który sortuje dostawców według surowej przepustowości, żeby odzyskać trochę szybkości. Pod koniec mogłem przerzucić cały pipeline między presetem open-weight a firmowym jedną flagą i przepuścić dokładnie ten sam projekt przez oba.
To właśnie ten przełącznik pozwolił mi w końcu porównać je uczciwie. A porównanie to moment, w którym zrobiło się ciekawie.
Niespodzianka: output był w zasadzie taki sam
Spodziewałem się, że modele otwarte wyprodukują widocznie gorszy kod. Nie zrobiły tego.
Ponieważ pipeline rozbija wszystko na drobne zadania, wynik końcowy wychodził niemal identyczny niezależnie od modelu. Ta sama struktura, to samo zachowanie, ta sama aplikacja. Różnice były drobne i niemal estetyczne — głównie jakość CSS i okazjonalne ozdobniki. I tu jest część, którą uważam za naprawdę zabawną: gorszymi recydywistami były modele bardziej zaawansowane. Daj czołowemu modelowi małe, precyzyjne zadanie, a robi się kreatywny — dorzuca do UI fajerwerk, o który nikt nie prosił, decyduje, że Twojemu formularzowi brakowało animacji. Haiku po prostu robi swoje. Im mądrzejszy model, tym większa szansa, że zacznie improwizować dokładnie wtedy, gdy improwizacja to ostatnie, czego chcesz.
Pytanie o jakość — to, o które wszyscy biją się na benchmarkowych leaderboardach — w większości się więc rozpłynęło. Zostałem ze wzrokiem wbitym w dwie osie, i tylko dwie: cenę i szybkość.
I twierdziłbym, że to uczciwe miejsce, w którym cała ta branża powinna wylądować. Neutralne pracownie danych już rozdzielają modele dokładnie wzdłuż tych linii — inteligencja, szybkość i cena jako trzy osobne kolumny — bo gdy inteligencja jest „wystarczająco dobra” do zadania, to z szybkością i ceną faktycznie się żyje.
Gdzie tanie modele przestają być tanie
Na papierze open weights wygrywają cenę z miażdżącą przewagą. Kosztują ułamek tego, co preset Anthropic-i-OpenAI w przeliczeniu na token. To cały powód, by w ogóle się za to brać.
Ale cena za token to pułapka, i wszedłem w nią prosto z marszu.
Po stronie firmowej większość obciążenia dźwigają modele Anthropic — a Sonnet i Haiku popełniają mniej błędów i inferują szybciej niż to, co dostaję przez OpenRouter, nawet z włączonym Nitro. Na pojedyncze żądanie różnica w szybkości nie jest dramatyczna. Ale się sumuje. A błędy to prawdziwy podatek: przy presecie open-weight agent musi częściej się zatrzymywać i poprawiać. Zły zwrot JSON tu, pomylony diff tam, retry, ponowne zaplanowanie. Każde z tego to więcej tokenów i więcej czasu na zegarze.
To matematyka, której nikt nie umieszcza na stronie z cennikiem. Model pięciokrotnie tańszy za token, ale wymagający retry, nie jest w praktyce pięciokrotnie tańszy — 20-procentowy wskaźnik porażek na krok mniej więcej podwaja rachunek za tokeny, a w pętli agentowej te porażki kumulują się przez kolejne kroki. Cała branża po cichu uczy się na nowo, że tańsze tokeny wyprodukowały większe rachunki, bo retry zjadają oszczędności żywcem.
Dokładnie to obserwowałem. Przewaga cenowa na liczniku została schrupana przez pętlę zatrzymaj-i-popraw. A kiedy zsumowałem wszystko razem — wolniejszą inferencję, dodatkowe retry, ponowne planowanie — realna różnica między moim firmowym presetem a presetem open-weight wyszła w okolicach 5x. Nie na benchmarku. Na faktycznej robocie, od początku do końca.
Żeby było jasne, czego nie twierdzę: to nie jest „open weights są słabe”. To open weights, w moim pipelinie, dziś, u dostawców, których testowałem, przy strojeniu, które jak dotąd wykonałem. Co prowadzi mnie do części, której jestem najmniej pewny.
Dlaczego sam jeszcze nie ufam swoim liczbom
Oto niewygodne wyznanie. Mam liczbę 5x. Nie ufam jej do końca i uważam, że Ty też nie powinieneś — nie dlatego, że jest błędna, ale ze względu na to, jak takie rzeczy zwykle się mierzy.
Era benchmarków rozpada się na naszych oczach. Standardowe benchmarki codingu są nasycone i skażone; branża spędziła 2025 na patrzeniu, jak tabela wyników przestaje odzwierciedlać realne umiejętności. A leniwy skrót, po który wszyscy sięgają — kazać mocnemu modelowi ocenić output — sam jest niewiarygodny: LLM-as-judge wykazuje dużą, wrażliwą na kolejność wariancję w zadaniach codingowych. Pytanie jednego czołowego modelu, czy kod innego modelu jest dobry, nie jest dowodem. To vibe z przedziałem ufności.
Moim następnym krokiem nie jest więc kolejny benchmark. To przyjrzenie się rzeczywistemu kodowi, który te modele wyvibe’owały, własnymi oczami i z prawdziwymi metrykami — czy się buduje, czy przechodzi testy, czy jest utrzymywalny, czy chciałbym go mieć na własność. Jest całkiem możliwe, że GLM i Kimi okażą się dawać lepsze ogólne wyniki, kiedy zacznę oceniać prawdziwy artefakt zamiast syntetycznego wyniku. Możliwe też, że modele otwarte po prostu nie są jeszcze dobrze nastrojone — budżety rozumowania i tuzin drobnych pokręteł niemal na pewno wymagają regulacji model po modelu, a ja ledwie to musnąłem. Moje szczere oczekiwanie: w momencie, gdy zejdziesz z syntetycznych benchmarków i zaczniesz porównywać realne outputy, cały obraz robi się mętniejszy, a nie czytelniejszy.
Będę drążył dalej. Ale ten miesiąc już nauczył mnie rzeczy, która naprawdę się liczy — i nie jest nią model.
Lekcja warta więcej niż wynik
Cofnij się na chwilę od leaderboardu.
Wszystko, co uczyniło open weights używalnymi w moim pipelinie — limity rozumowania na model, by myślenie nie głodziło outputu, fallback na tool-calling przy chwiejnym JSON-ie, wyłuskiwanie fragmentów i patch-diffy, które ścieśniają kontekst, failover dostawców i routing po przepustowości, przypisania modeli do ról — nic z tego nie jest modelem. To struktura wokół modelu. To miesiąc mało efektownej inżynierii, która siedzi między „istnieją tanie tokeny” a „dostarczyłeś działające oprogramowanie”.
To w gruncie rzeczy cały produkt. Agent codingowy to agent codingowy — a nie zespół deweloperski. Model jest towarem; możesz go podmienić jutro, a po tym miesiącu mogę Ci dokładnie powiedzieć, ile ta podmiana faktycznie daje. Wartością nigdy nie był model. Wartością jest pipeline, który sprawia, że dowolny model produkuje kod, który możesz mieć na własność i utrzymywać — i który wchłania retry, błędy formatu, strojenie model po modelu, żebyś nie płacił za nie swoimi weekendami.
To ta sama obietnica, którą OwlMeans składa klientom, a ja właśnie spędziłem miesiąc na udowodnieniu jej sobie od środka: OwlMeans to zespół wokół agenta. Opisujesz swój produkt jako historyjki użytkownika. Pipeline rozbija je na części, uruchamia, poprawia i oddaje Ci typowane monorepo, które jest Twoje — kod, który dalej rozwijasz z dowolnym agentem, jaki lubisz. Koszt jest przewidywalny na historyjkę, bo to pipeline czyni go przewidywalnym.
Możesz pominąć mój miesiąc
Oto więc uczciwa oferta, i złożę ją tak, jak sam chciałbym, żeby złożono ją mnie.
Jeśli vibe-codujesz prawdziwy produkt, staniesz przed dokładnie tym pytaniem — który model, który dostawca, jak utrzymać rachunek w ryzach, żeby output się nie rozpadł. Możesz zrobić to, co ja: spędzić tygodnie na okablowywaniu presetów, odkrywaniu, że effort: none to kłamstwo, patrzeniu, jak Twoje tanie tokeny wyparowują w retry, i uczeniu się model po modelu, co jest naprawdę prawdą. Mnie się opłaciło, bo budowanie tego silnika jest moją robotą.
To nie jest Twoja robota.
Możesz pozwolić, żeby pipeline, który już stoczył tę walkę, zrobił to za Ciebie — dobrał ekonomię modeli, wchłonął retry, wyegzekwował strukturę i oddał Ci kod, który możesz mieć na własność i utrzymywać, z kosztem przewidywalnym na historyjkę. To jest oferta. Spaliłem miesiąc i mnóstwo tokenów, żeby znaleźć to 5x. Ty możesz po prostu dostać pipeline.
Jeśli problemem jest oszczędzanie czasu i tokenów na vibe-codingu, to najtańszy miesiąc R&D, którego nigdy nie będziesz musiał przeprowadzić.
OwlMeans to pipeline rozwoju oparty na AI: opisujesz, czego chcesz, w formie historyjek użytkownika, a dostajesz pełnowymiarowe aplikacje, chatboty, agentów AI i pipeline’y danych — typowane, gotowe na SSO i Twoje, by rozwijać je dalej z dowolnym agentem. Zobacz, co potrafi →