Człowiek, którego kod napędza nasze wideo, kompresuje SMS-y modelem językowym

Fabrice Bellard mieszka pod Paryżem i od ćwierć wieku robi to samo: bierze brutalnie trudny problem, rozwiązuje go sam i oddaje kod. Ostatnio wziął na warsztat coś, co dotyka wprost pytania zadawanego w każdej kancelarii: czy duży model językowy musi mieszkać w cudzej chmurze. U Bellarda nie musi - jego narzędzia LLM działają lokalnie, na zwykłym sprzęcie, bez centrum danych za oceanem.

Aktualne na 2026-06-11. To nie sylwetka geniusza. To głos w sporze, który prawnik prowadzi co tydzień: gdzie naprawdę musi leżeć AI, żeby zadziałało.

Kto to jest

Większość ludzi, którzy oglądali w tej dekadzie cokolwiek na ekranie, korzystała z kodu Fabrice'a Bellarda, nie znając jego nazwiska. W 2000 roku napisał FFmpeg - bibliotekę, która dekoduje praktycznie każdy format audio i wideo, obecną dziś w VLC, przeglądarkach i telefonach. W 2003 roku stworzył QEMU, emulator maszyn, na którym oparta jest wirtualizacja u największych dostawców chmury. Do tego napisał TCC - kompilator C tak mały, że kompiluje jądro Linuksa w kilkanaście sekund - oraz JSLinux, czyli komputer uruchamiający Linuksa w przeglądarce, w czystym JavaScripcie.

Bellard nigdy nie przeprowadził się do Doliny Krzemowej i nie zbierał rund od inwestorów. Jego strona to płaska lista projektów bez grafiki: same tytuły i linki. W 2012 roku współzałożył Amarisoft i do dziś jest jej CTO, budując programowe stacje bazowe 4G i 5G. Za każdym razem ten sam wzorzec: jeden człowiek, trudny problem, działający kod.

Dlaczego piszemy o tym tutaj

Bo jego ostatnie projekty trafiają dokładnie w nasz temat. Na stronie Bellarda widnieją dziś, jego własnymi słowami:

  • ts_zip - „a practical text compression utility using a large language model" (kompresja tekstu dużym modelem językowym),
  • ts_sms - „short message compression using a large language model" (kompresja krótkich wiadomości dużym modelem językowym),
  • TextSynth Server - „a web server proposing a REST API to large language models" (serwer udostępniający duże modele językowe przez REST API),
  • Micro QuickJS - „a Javascript engine for microcontrollers" (silnik JavaScript na mikrokontrolery).

To nie są zabawki konferencyjne, tylko działające narzędzia, w których duży model językowy nie jest usługą po drugiej stronie świata, lecz składnikiem programu uruchamianego u siebie. Dokładnie to powtarzamy kancelariom od dawna: model językowy to oprogramowanie, które można postawić lokalnie.

Jest też wątek bliski nam zawodowo. To na FFmpeg renderujemy materiały wideo MateMatic. Narzędzie Bellarda napędza nasz własny warsztat, a jego autor przy okazji pokazuje na kodzie tezę, na której zbudowaliśmy produkt.

Czego to NIE dowodzi

Tu trzeba być uczciwym, bo łatwo z podziwu zrobić nadinterpretację. Po pierwsze, „lokalnie" u Bellarda nie znaczy „na zegarku". Jego narzędzia LLM nadal potrzebują realnego modelu i realnej mocy; mały silnik na mikrokontroler to osobny projekt niż kompresja tekstu modelem językowym i nie należy tych dwóch rzeczy sklejać w jeden cudowny nagłówek.

Po drugie, Bellard to inżynier rozwiązujący problemy dla samej elegancji rozwiązania, a nie dostawca dla sektora regulowanego. Z tego, że da się uruchomić model u siebie, nie wynika, że spełnia to wymogi RODO, tajemnicy zawodowej czy AI Act - to osobne pytania, na które odpowiada architektura wdrożenia, nie sam fakt lokalności.

Po trzecie, jeden człowiek robiący rzeczy pozornie niemożliwe to inspiracja, nie metoda skalowania. Podziw dla rzemieślnika nie zwalnia z pytania, jak utrzymać i rozwijać taki system w kancelarii, która nie ma własnego Bellarda.

Co to znaczy dla kancelarii

Tyle, że dominująca narracja - „poważne AI mieszka w chmurze hyperscalera, lokalnie odpalisz najwyżej prostą zabawkę" - jest opowieścią handlową, nie stanem techniki. Bellard jest tego najczystszym zaprzeczeniem: na zwykłym sprzęcie robi rzeczy, do których rzekomo trzeba serwerowni za miliony.

Dla prawnika płynie z tego konkret. Pytanie „czy nasze dokumenty muszą wyjść do cudzej chmury, żeby AI mogło je przeczytać" nie dotyczy granic technologii, tylko jej projektu. Skoro coraz częściej nie muszą, to wybór między chmurą a własną maszyną wraca tam, gdzie jego miejsce: do decyzji o ryzyku, tajemnicy (art. 6 prawa o adwokaturze, art. 3 ustawy o radcach prawnych) i powierzeniu danych (art. 28 RODO), a nie do rzekomej konieczności technicznej.

Bellard niczego nie obiecuje kancelariom. Pokazuje tylko, że pytanie „czy AI musi wyjść do chmury" ma odpowiedź „nie musi". Co z nią zrobić, to już decyzja, nie technika.

Werdykt

Nie napiszemy, że Micro QuickJS zmieni pracę kancelarii, bo nie zmieni - to projekt dla świata wbudowanego, nie dla obiegu akt. Wart odnotowania jest mechanizm, nie produkt: pojedynczy inżynier pod Paryżem pokazuje na działającym kodzie, że duży model językowy bywa składnikiem programu uruchamianego u siebie, a nie wyłącznie usługą w cudzym centrum danych. To nie powód do triumfu, raczej do spokoju. Kto traktuje lokalne AI jak fanaberię, ten czyta marketing dostawców chmury. Kto chce zobaczyć, dokąd zmierza technika, niech zajrzy na stronę Fabrice'a Bellarda.

Co MateMatic wnosi

Lokalne AI dla kancelarii: sprawdzamy, co naprawdę da się uruchomić u Ciebie

Projektujemy architekturę, w której akta nie opuszczają kancelarii - z modelem językowym i wyszukiwaniem uruchamianymi lokalnie, na własnej maszynie. Bez obietnic z folderu, na konkretnym sprzęcie i realnym obiegu dokumentów.

Skontaktuj się →
Wiesław Mazur - MateMatic
Bezpieczna architektura AI dla kancelarii · matematicsolutions.com
#Fabrice-Bellard #lokalne-AI #zero-cloud #model-lokalny #LLM #FFmpeg #QuickJS #suwerennosc-danych #tajemnica-zawodowa #LegalTech

Źródła

Oceny w tej aktualności są stanowiskiem MateMatic, nie zastępują doradztwa prawnego i nie stanowią stanowiska PUODO, NRA ani KRRP. Opisy projektów Fabrice'a Bellarda przytaczamy w jego własnym brzmieniu ze strony bellard.org; nie weryfikowaliśmy parametrów technicznych poszczególnych narzędzi poza tym, co podaje autor.