Iluzja lokalnego AI: dlaczego modele open weight przegrywają z chmurą
Pomimo rosnącego entuzjazmu wokół generatywnej sztucznej inteligencji, uruchamianie asystentów programistycznych w pełni na własnym komputerze w profesjonalnych zastosowaniach wciąż dla wielu deweloperów mija się z celem. Jak wskazują wprost prowadzący branżowy podcast Patoarchitekci (Szymon i Łukasz), chociaż modele open weight stają się z miesiąca na miesiąc coraz potężniejsze i coraz bardziej dostępne, to twarde bariery sprzętowe na komputerach osobistych czynią z nich w najlepszym razie jedynie ciekawostkę, a nie główne narzędzie w codziennej inżynierii. Wybór środowisk chmurowych okazuje się nie tylko wygodniejszy, ale przede wszystkim wymuszony przez brutalną matematykę fizycznych komponentów.
Brutalna matematyka Apple M5 Max
Chociaż najnowsze laptopy dla profesjonalistów agresywnie reklamowane są jako stacje robocze gotowe na zaawansowaną sztuczną inteligencję, codzienność bezwzględnie weryfikuje te obietnice marketingowe. Uruchamianie modeli takich jak Qwen 3 8 czy DeepSeek na potężnym sprzęcie klasy Apple M5 Max zapewnia zadowalającą wydajność rzędu zaledwie 20–30 tokenów na sekundę.
Przy pojedynczym, izolowanym zapytaniu o krótkim oknie taka prędkość mogłaby wydawać się akceptowalna. Poważny problem ujawnia się jednak natychmiast z pełną mocą przy pracy z nowoczesnymi środowiskami programistycznymi, które wymagają ciągłej i jednoczesnej pracy wielu niezależnych agentów w równoległych sesjach (np. równoczesne czytanie tysięcy linii bazy kodu, sugerowanie poprawek i generowanie testów z asercjami). Przy skali takiej architektury, wydajność rzędu 20-30 tokenów na sekundę to, jak to ujęto w podcaście, po prostu "tyle co nic".
Ogromnym, zazwyczaj przemilczanym wąskim gardłem jest tutaj wolne zapełnianie kontekstu (czyli faza tzw. prefill). Współczesne, wysoce zoptymalizowane pod kątem przepustowości karty serwerowe u zewnętrznych dostawców radzą z tym sobie nieporównywalnie lepiej niż wbudowana pamięć zunifikowana. W efekcie lokalne instalacje z modelami nadają się obecnie co najwyżej do realizowania relatywnie prostego, wstępnego routingu zadań — cała faktyczna ciężka praca programistyczna operująca na ogromnym kontekście i tak musi trafiać bezwzględnie do chmury. Przez rynek przetaczają się w prawdzie różne głośne nazwy od Qwen aż po Metowe Muse, ale ostatecznie nie przeskakują one w cudowny sposób ograniczeń prędkości w samej maszynie na biurku.
"Slop factories" zamiast czwartego poziomu autonomii
Niskie osiągi to jednak nie tylko problem czasu oczekiwania. Branża zaczęła bezrefleksyjnie wchodzić w trend określany przez gospodarzy Patoarchitektów mianem "slop factories" — fabryk produkujących niskiej jakości kod w porażających ilościach, ale z całkowitym zrzuceniem nadzoru na maszynę. Automatyzacja tworzenia wyprzedziła automatyzację jej sprawdzania, co przy lokalnych, wolniejszych iteracjach prowadzi do kompletnego paraliżu pracy projektowej.
Jak brutalnie punktuje to sam Szymon: „Realnie nie robisz review kodu. Przy tej ilości nie masz opcji, żeby to zrobić”. Takie zjawisko powoduje, że autonomiczni agenci nie rozwiązują problemów na wymarzonym czwartym poziomie, a wręcz zaczynają generować absurdalne wyzwania architektoniczne. Przypomniano tu zresztą anegdoty rzucające doskonałe światło na ułomność wspierania debugowania algorytmami: błędy kosztujące Linusa 18 kolejnych rebootów z rzędu w trakcie pracy nad kernelem czy dotkliwe awarie i dramaty przy security review, w wyniku których u Omarchy DHH po prostu "wylało szambo".
Nowa ekonomia IT: wielkie budżety i znikający juniorzy
Marzenie społeczności zafascynowanej autonomiczną inżynierią, potocznie określane jako "tokenmaxxing", najwyraźniej już spełniło swoją funkcję hype'ową i obecnie ulega brutalnym prawom ekonomii. Organizacje technologiczne radykalnie odchodzą od rekrutacji najsłabiej doświadczonych kadr, ponieważ ich pracę z powodzeniem zastępują drogie usługi SaaS. Budżety stanowiskowe zmieniają proporcje – w miejsce rekrutacji asystentów wchodzi na sztywno 300–500 dolarów miesięcznie, przyznawane poszczególnym seniorom.
Ta kwota służy dziś do finansowania ciężkiej infrastruktury chmurowej, z pominięciem lokalnego sprzętu. Rynek doskonale to dostrzega, czego świadectwem jest trwająca zaciekła konsolidacja narzędzi deweloperskich. Przykładem jest tu potężny OpenRouter wykupiony przez finansowego giganta Stripe za astronomiczne sumy szacowane na 7-8 miliardów dolarów. Na horyzoncie z chmury korzysta masowo modny edytor Cursor, przy którym wdrożeniu eksperymentuje nawet ekipa Elona Muska (co rodzi słuszne obawy o to, komu finalnie firma zgodzi się powierzyć tak olbrzymi zasób kodu źródłowego na cudzych serwerach).
Walka o przestrzeń w chmurze przybiera formy twardych konfliktów – od wstrząsów i formalnych głosowań w obrębie konserwatywnego systemu Debian, po otwarte dramy konsumenckie i cywilne pozwy przeciwko dostawcom usług nakładającym milczące, restrykcyjne limity obciążeń 5x czy 20x. W ostatecznym starciu o prymat wydajności kluczowym graczem pozostaje jednak umysł człowieka zarządzającego cloudową potęgą. Jak dosadnie podsumowują to najnowsze inżynieryjne benchmarki branżowe: „juniorzy z AI-em - zwalnia, seniorzy z AI-em - przyspiesza”. I to właśnie do tego drugiego trafiają dzisiaj budżety zarezerwowane na wsparcie ze strony inteligentnych maszyn.
