Pozorny charakter otwartości: modele open weight a prawdziwy open source

W branży technologicznej od dawna debatuje się nad dostępnością zaawansowanych systemów sztucznej inteligencji, jednak rzeczywistość wyraźnie pokazuje, że modele open weight rzadko oferują transparentność, jakiej można by oczekiwać. Jak zauważają Szymon i Łukasz w podcaście Patoarchitekci, dostawcy technologii chętnie wykorzystują hasła sugerujące pełną swobodę, lecz za tymi deklaracjami kryją się bardzo istotne ograniczenia. Dyskusja o tym, na którym poziomie ewolucji oprogramowania naprawdę jesteśmy, boleśnie obnaża fundamentalne braki w przejrzystości najpopularniejszych współczesnych rozwiązań.

Iluzja otwartości i dominacja rynkowa Chin

W segmencie modeli określanych jako otwarte brakuje rzeczywistych rozwiązań open source. Użytkownikom udostępnia się wyłącznie gotowe wagi, które można uruchomić w środowiskach takich jak TensorFlow, opierając się na udostępnionym przez dostawcę podstawowym kodzie w języku Python. Brakuje w tym jednak kluczowego filaru rzetelnej otwartości: twórcy nie zapewniają żadnego wglądu w oryginalne zbiory treningowe ani w sam proces uczenia sieci. Ekosystem otrzymuje więc model wysoce zoptymalizowany, ale pod względem wiedzy o jego powstaniu – całkowicie zamknięty.

W tym swoistym wyścigu o deweloperów, jak podkreślają prowadzący podcast, najsilniejszą pozycję budują obecnie podmioty z Chin, wprowadzając na rynek popularne modele takie jak Qwen. Konkurencją na Zachodzie są z kolei korporacyjne wdrożenia, m.in. Metowe Muse, które jednak również bazuje na podobnym, ograniczonym do samych parametrów udostępnianiu. Europejską próbą odpowiedzi na zagraniczne portfolio są rozwijane modele open-weight Mistrala, choć cała ta kategoria AI wciąż wymaga od użytkownika sporych nakładów zaufania do niewidocznych dla niego danych.

„Slop factories” i brutalna matematyka sprzętu

Brak dostępu do kodu trenującego to zaledwie wierzchołek góry lodowej. Łukasz ocenia aktualny stan branży mianem „slop factories”, przeciwstawiając go wizjom potężnych, autonomicznych struktur programistycznych. Wynika to w dużej mierze ze ściany hardware'owej, na którą trafia lokalne odpalanie modeli. Patoarchitekci bezlitośnie obnażają matematykę sprzętu: nawet najmocniejszy układ M5 Max wyciąga zaledwie 20-30 tokenów na sekundę. Przy jednoczesnej pracy chmary równoległych agentów generujących kod jest to wynik dalece niewystarczający do płynnego działania zespołów.

Skutkiem takiej architektury jest to, że weryfikacja wyrzucanego masowo kodu staje się całkowitą iluzją. „Realnie nie robisz review kodu. Przy tej ilości nie masz opcji, żeby to zrobić” – to zdanie z podcastu dobrze podsumowuje zagrożenia dla bezpieczeństwa. Jako przykłady problemów wynikających z automatyzacji podano przypadek twórcy frameworka Ruby on Rails. Znanemu pod pseudonimem Omarchy DHH programiście w zautomatyzowanym security review „po prostu wylało szambo”. Nawet najbardziej doświadczeni deweloperzy stają w obliczu nieprzewidzianych barier – Linus musiał debugować kernel z asystentami przez 18 rebootów, a w ogromnym społecznościowym projekcie Debian odbyło się specjalne głosowanie, które miało zdefiniować na nowo zasady przyjmowania kodu wytworzonego mechanicznie.

Znikający juniorzy i wyścig na przejęcia

Automatyzacja procesów za sprawą takich asystentów uderza najmocniej w młodych deweloperów. Znikający z rynku juniorzy IT to efekt rosnącej opłacalności narzędzi – organizacje udostępniają jawne budżety rzędu 300-500 dolarów na developera na wykupienie stosownych asystentów. Potwierdzają to statystyki rynkowe; jak pokazują benchmarki, implementacja sztucznej inteligencji doprowadza do sytuacji opisywanej słowami: „juniorzy z AI-em - zwalnia, seniorzy z AI-em - przyspiesza”. Technika znana jako tokenmaxxing w tym kontekście już umarła, ponieważ doskonale spełniła przypisaną jej rolę marketingową, a firmy skupiły się na faktycznej efektywności zatrudnionych seniorów.

W tle tych wydarzeń rozgrywają się ogromne przetasowania kapitałowe, pompowane przez wyścig na IPO i straszenie „ucieczkami LLM-ów”. Platforma OpenRouter została niedawno przejęta przez finansowego giganta Stripe za sumę od 7-8 miliardów. Z kolei popularny edytor programistyczny Cursor znajduje się obecnie u inwestora, którym jest Elon, i walczy z pozwami o mylące limity wynoszące 5x i 20x. Te gigantyczne sumy pokazują brutalną prawdę: biznes na modelach pozbawionych otwartego kodu uczącego ma się na razie doskonale, ale jego pełna użyteczność kończy się tam, gdzie zaczyna się realna weryfikacja bezpieczeństwa i praw autorskich.