Model rysujący dla RP2040 wykonuje dokładne programy, ale AI pozostaje na hoście

Model rysujący dla RP2040 wygenerował kompaktowe programy dla 12 670 testów sprzętowych, jednak jego transformer z 825 344 parametrami nigdy nie działał na mikrokontrolerze. Zamiast tego komputer hosta tworzył bajtkod rysowania i przesyłał go do Raspberry Pi Pico w celu deterministycznego wykonania.

To rozróżnienie definiuje zarówno wartość projektu, jak i jego ograniczenia. Nie jest to kolejne twierdzenie, że niewielkie urządzenie może lokalnie uruchamiać użyteczny model generatywny. To eksperyment polegający na oddzieleniu niepewnego generowania neuronowego od dokładnego, ograniczonego wykonania.

System podważa typową ścieżkę generowania pikseli. Sprawdza, czy mały transformer potrafi napisać wykonywalny opis, a następnie przekazać go minimalnej maszynie o przewidywalnym działaniu. Wyniki sprzętowe wyglądają wyjątkowo dobrze, podczas gdy zdolność modelu do komponowania nieznanych struktur pozostaje znacznie mniej pewna.

Model rysujący dla RP2040 oddziela generowanie od wykonania

Głównym wynikiem jest podział pracy, a nie neuronowe wnioskowanie na urządzeniu.

Według publicznego repozytorium projektu autoregresyjny transformer z 825 344 parametrami działa na komputerze hosta. Dla każdego przykładu generuje około 100 bajtów bajtkodu rysowania.

Bajtkod to kompaktowy format instrukcji interpretowany przez inny program. W tym przypadku opisuje operacje takie jak przesuwanie wirtualnego pióra, rysowanie linii, obliczanie krzywych, stosowanie transformacji całkowitoliczbowych i powtarzanie ograniczonych sekwencji.

Host przesyła ten program do Raspberry Pi Pico. Niewielka maszyna wirtualna, czyli VM, wykonuje instrukcje na mikrokontrolerze RP2040 w Pico. Następnie przesyła współrzędne geometryczne z powrotem przez UART, standardowy interfejs komunikacji szeregowej.

Końcowy obraz powstaje na podstawie zwróconych współrzędnych. Pico nie przechowuje wag transformera, nie uruchamia wymagającego obliczeń macierzowych wnioskowania neuronowego ani nie potrzebuje środowiska wykonawczego tensorów. Jedynie interpretuje wygenerowany program.

Ta granica ma znaczenie, ponieważ sformułowanie „model na RP2040” sugerowałoby inne osiągnięcie techniczne. Model z 825 344 parametrami mógłby wymagać kilku megabajtów przy konwencjonalnych formatach liczbowych, jeszcze przed uwzględnieniem pamięci środowiska wykonawczego.

Autor projektu wyraźnie unika takiego twierdzenia. Oryginalna dyskusja podaje, że transformer pozostaje na hoście, a Pico przechowuje i wykonuje jego wyjście.

Udostępniony model demonstracyjny obejmuje pięć kategorii: koty, autobusy, kwiaty, żaglówki i rowery. Nie jest przedstawiany jako otwarty system tekst-na-obraz.

Tak wąski zakres ułatwia interpretację wyników. Eksperyment bada reprezentację, generowanie programów i ograniczone wykonanie, nie deklarując szerokiej wiedzy wizualnej.

Model zwraca instrukcje zamiast siatki kolorowych pikseli. Tworzy to użyteczny interfejs między probabilistyczną AI a deterministycznym oprogramowaniem wbudowanym.

Generator pikseli bezpośrednio przesądza o widocznym rezultacie. Generator programów proponuje natomiast sekwencję, którą inny system może zweryfikować, ograniczyć, wykonać lub odrzucić.

Ta różnica tworzy główne napięcie artykułu. Wykonanie sprzętowe wydaje się dokładne i oszczędne, lecz dokładne wykonanie nie gwarantuje, że wygenerowany program przedstawia zamierzony rysunek.

Pico może perfekcyjnie wykonać słaby program rysujący rower. Może też niezawodnie odrzucić niepoprawną lub zbyt długą sekwencję, jeśli VM egzekwuje odpowiednie ograniczenia.

Innymi słowy, poprawność wykonania i poprawność generowania to odrębne właściwości. Projekt mierzy obie, a ich wyniki wskazują różne kierunki.

Dokładne wykonanie jest najsilniejszym wynikiem

Pico konsekwentnie odpowiadało interpreterowi referencyjnemu, chociaż pomiary pochodzą z własnych artefaktów testowych projektu.

Autor informuje, że podczas testów sprzętowych wykonano 12 670 wygenerowanych programów. Każda zwrócona ścieżka dokładnie odpowiadała referencyjnej VM w Pythonie.

Ścieżka to uporządkowana geometria wytworzona przez program. Dokładne dopasowanie oznacza, że urządzenie i implementacja referencyjna zwróciły identyczne współrzędne, a nie jedynie obrazy wyglądające podobnie.

Zapis eksperymentu projektu raportuje równość bez tolerancji dla wszystkich 12 670 ścieżek. Wymienia również 120 ze 120 programów zgodności, które przeszły testy względem bazowego QEMU.

Są to wyniki pochodzące od autora, a nie niezależna replikacja. Mimo to repozytorium zawiera interpreter, strukturę testów, zapisane ścieżki i dokumentację potrzebną do technicznej inspekcji.

Interpreter C ma podobno zajmować 1 862 bajty pamięci flash. Liczba ta obejmuje wyłącznie VM, z wyłączeniem pamięci na bajtkod i otaczającej infrastruktury transmisji.

Implementacja nie używa statycznie przydzielonej pamięci RAM na stan VM. Szczytowe wykorzystanie stosu osiągnęło 492 bajty w zmierzonej konfiguracji.

Przy celowo obniżonym taktowaniu RP2040 do 12 MHz raportowana średnia wyniosła 7 334 cykle na rysunek. Odpowiada to około 0,611 milisekundy dla zmierzonych programów QuickDraw.

Autor podaje również 1,959 cyklu na wykonaną instrukcję. Pomiary dotyczą pracy interpretera, a nie czasu potrzebnego do wygenerowania programu na hoście.

Nie obejmują też czasu transmisji między hostem a urządzeniem ani pracy wyświetlania. Czytelnicy nie powinni traktować 0,611 milisekundy jako opóźnienia generatywnego od początku do końca.

RP2040 to dwurdzeniowy mikrokontroler Arm Cortex-M0+ z 264 kB pamięci SRAM na chipie. Raspberry Pi podaje maksymalne taktowanie 133 MHz w swojej dokumentacji RP2040.

Układ nie ma sprzętowej jednostki zmiennoprzecinkowej. Ograniczenie to często komplikuje kod graficzny, ponieważ krzywe i transformacje zwykle korzystają ze współrzędnych ułamkowych.

Ta VM unika arytmetyki zmiennoprzecinkowej dzięki reprezentacji stałoprzecinkowej. Stały przecinek przechowuje wartości ułamkowe jako skalowane liczby całkowite, zapewniając przewidywalne wyniki w różnych implementacjach.

Ewaluator krzywych wykorzystuje liczbę kroków będącą potęgą dwójki. Przy tym ograniczeniu odpowiednie współczynniki sześciennej krzywej Béziera można przedstawić jako ułamki binarne o znanym mianowniku.

Implementacja wybiera wystarczającą liczbę bitów części ułamkowej, aby zachować te wartości podczas obliczeń całkowitoliczbowych. Ten projekt eliminuje różnice w zaokrąglaniu między platformami ze ścieżki mierzonej geometrii.

Deterministyczna arytmetyka sprawia również, że porównanie jest wyjątkowo rygorystyczne. Test nie wymaga wskaźnika podobieństwa obrazów ani tolerancji wokół każdego wierzchołka.

Implementacja referencyjna i urządzenie albo emitują tę samą ścieżkę, albo nie. Taki binarny wynik łatwiej audytować niż subiektywną ocenę podobieństwa wizualnego.

Testy fizyczne ujawniły co najmniej jedną klasę problemów, których nie wychwyciła symulacja na hoście. Dokumentacja projektu opisuje wyścigi podczas inicjalizacji zegara peryferiów w trakcie uruchamiania bare-metal.

Ta obserwacja wspiera decyzję o testowaniu na rzeczywistym krzemie. Interpreter może być poprawny matematycznie, podczas gdy jego transmisja lub sekwencja startowa pozostaje zawodna na rzeczywistej płytce.

Obecne dowody mają jednak wyraźne granice. Autor nie zmierzył energii na rysunek, ponieważ stanowisko testowe nie miało odpowiedniego sprzętu do pomiaru prądu.

Repozytorium nie zawiera również wytrenowanego checkpointu. Użytkownicy mogą uruchomić VM i odtworzyć zapisane przechwycenia, ale generowanie przez model na żywo wymaga osobno pozyskanego checkpointu.

Ograniczenia te nie przekreślają wyniku dotyczącego wykonania. Określają, co zewnętrzni recenzenci mogą natychmiast odtworzyć, a co nadal zależy od materiałów autora.

Programy oferują kontrolę, której nie zapewniają piksele

Wykonywalne wyjście przekształca zachowanie modelu w coś, co ograniczone środowisko wykonawcze może sprawdzać i kontrolować.

Program rysujący ujawnia operacje, przepływ sterowania i strukturę geometryczną. Obraz rastrowy ujawnia jedynie końcowy układ pikseli.

Różnica ma znaczenie na małych urządzeniach. Środowisko wykonawcze może narzucić limit paliwa, czyli maksymalną liczbę instrukcji dozwolonych przed zakończeniem.

Może również ograniczać zagnieżdżenie pętli, głębokość wywołań, głębokość transformacji, zakresy współrzędnych i liczbę danych wyjściowych. Ograniczenia te sprawiają, że wygenerowane zachowanie jest skończone, nawet gdy model tworzy błędną sekwencję.

VM projektu przesyła wierzchołki strumieniowo, zamiast przechowywać cały rysunek. Zmniejsza to presję na pamięć roboczą i odpowiada sposobowi działania urządzenia przeznaczonego do sterowania w czasie rzeczywistym.

Podejście przypomina inne systemy oddzielające planowanie od wykonania. Większa maszyna przeprowadza kosztowne wnioskowanie, a mniejszy kontroler realizuje kompaktową reprezentację pośrednią.

Ten wzorzec występuje już w robotyce, komputerowym sterowaniu numerycznym, ploterach i interfejsach wbudowanych. Nietypowym elementem jest tutaj użycie transformera z mniej niż milionem parametrów do tworzenia programu pośredniego.

Bajtkod rysowania szczególnie dobrze nadaje się do tego eksperymentu. Linie, krzywe i powtarzalne motywy dają widoczne rezultaty, a ich wykonanie pozostaje prostsze niż w przypadku języka programowania ogólnego przeznaczenia.

Niepoprawne przewidywanie obrazu daje nieatrakcyjny obraz. Niepoprawny program rodzi dodatkowe pytania dotyczące zakończenia, poprawności i bezpieczeństwa środowiska wykonawczego.

VM odpowiada na część tych pytań za pomocą celowo ograniczonego zestawu instrukcji. Nie oferuje dowolnego dostępu do pamięci ani ogólnych usług systemu operacyjnego.

To zbliża system do języka specyficznego dla domeny niż do zwykłego generowanego kodu. Język specyficzny dla domeny obsługuje wąskie zadanie, oferując mniej niebezpiecznych lub niejednoznacznych operacji.

Rezultatem jest ograniczony kontrakt. Model proponuje rysunek, a interpreter decyduje, co te bajty oznaczają zgodnie ze stałymi regułami.

Taki kontrakt stwarza możliwości wykraczające poza szkice. Podobny układ mógłby reprezentować ścieżki narzędzi, polecenia dla plotera piórowego, wzory LED, proste animacje lub ograniczone układy interfejsu.

Aplikacje te wymagałyby jednak własnej walidacji. Dokładna geometria na Pico nie dowodzi bezpiecznego ruchu silników ani niezawodnego sterowania fizyczną maszynerią.

Domena docelowa określałaby też, które błędy mają znaczenie. Lekko zniekształcony kwiat jest nieszkodliwy, podczas gdy błędna ścieżka aktuatora może uszkodzić sprzęt.

Najsilniejsza przenośna idea projektu ma zatem charakter architektoniczny. Generowanie probabilistyczne może pozostawać poza granicą zaufanego wykonania.

Komponent wbudowany może pozostać mały, testowalny i deterministyczny. Nie musi dziedziczyć złożoności modelu, który zaproponował program.

To rozdzielenie zmienia również sposób, w jaki deweloperzy mogą debugować awarie. Mogą sprawdzać wygenerowane bajty, odtwarzać je w Pythonie, porównywać ścieżki i izolować zachowanie specyficzne dla urządzenia.

Potok pikselowy często ukrywa strukturę wewnątrz aktywacji neuronowych. Potok programowy pozostawia artefakt o jawnym znaczeniu operacyjnym.

Artefakt ten można rejestrować i wersjonować. Można go również sprawdzać względem znanych reguł, zanim urządzenie go otrzyma.

Dla zespołów inżynieryjnych przypomina to raczej potok kompilatora niż generator obrazów. Model działa jako niepewny front end, podczas gdy VM pełni rolę rygorystycznego back endu wykonawczego.

Nie należy jednak zbyt daleko posuwać tej analogii. Tradycyjne kompilatory tłumaczą dobrze zdefiniowany tekst źródłowy, podczas gdy ten transformer próbuje programy z wyuczonego rozkładu.

Mimo to granica jest wartościowa. Daje konwencjonalnemu komponentowi oprogramowania władzę nad tym, co wygenerowane wyjście może zrobić.

Generowanie programów przez mały model wciąż zawodzi przy kompozycji

Interpreter wykonuje program dokładnie, ale transformer nie generuje niezawodnie dokładnych, nieznanych wcześniej relacji.

Eksperymenty projektu pokazują, że niska strata predykcyjna nie przekłada się automatycznie na niezawodne programy generowane przez próbkowanie. Ta luka jest głównym powodem, by traktować tę pracę jako badania, a nie ukończony system.

Bazowy płaski model autoregresyjny osiągnął zbieżną stratę testową na poziomie 489,2 bitu na rysunek. Strata testowa mierzy niepewność predykcyjną, a nie to, czy wylosowany rysunek spełnia pożądaną relację geometryczną.

Autor przetestował kilka reprezentacji przy tym samym ogólnym budżecie parametrów. Obejmowały one bajty, pojedyncze bity, tokeny typowane oraz względne przyrosty współrzędnych.

W syntetycznym korpusie programów reprezentacja bitowa wypadła mniej więcej tak samo dobrze jak bajty. Raportowana różnica wyniosła minus 0,67 bitu na rysunek, z niepewnością plus minus 0,77 bitu.

Wynik zmienił się w przypadku szkiców ludzi pochodzących z danych Google Quick, Draw data. Tam modelowanie na poziomie bitów wiązało się z raportowaną karą 11,58 bitu na rysunek, z niepewnością plus minus 0,60 bitu.

Bity wydłużyły też sekwencje ewaluacyjne ośmiokrotnie. Eksperyment przetworzył 254 miliony tokenów bitowych, wobec 32 milionów tokenów bajtowych.

Raportowany czas ewaluacji wzrósł z czterech minut dla bajtów do 48 minut dla bitów. W udokumentowanej konfiguracji oznacza to ponad ośmiokrotne spowolnienie.

Kontrast ten podważa proste twierdzenie, że mniejszy słownik zawsze pomaga małemu modelowi. Dwusymbolowy alfabet obniża koszty embeddingów, ale zmusza sieć do odtworzenia granic bajtów i struktury pól.

Syntetyczne wzorce najwyraźniej sprawiły, że takie odtworzenie było możliwe do opanowania. Bardziej zróżnicowane szkice ludzi nie przyniosły tego samego rezultatu.

Tokeny typowane wprowadziły kolejny kompromis. Jawniej wiążą opcode'y z rolami operandów, lecz ich większy słownik pochłania znaczną część niewielkiego budżetu parametrów.

W jednym szerokim modelu tablica embeddingów zajmowała 22 procent wszystkich parametrów. Ta konfiguracja osiągnęła wynik gorszy o 4,87 bitu na rysunek niż wariant porównawczy.

Głęboki, wąski model skuteczniej uwzględnił koszt słownika. Sugeruje to, że reprezentacja i architektura silnie oddziałują na siebie w skali poniżej miliona parametrów.

Najbardziej wymowne porażki dotyczyły powtarzalnej geometrii. Model nauczył się przewidywalnych powtórzeń w zakresie obecnym podczas treningu.

Jego zaskoczenie spadło o 74 procent po napotkaniu drugiej kopii znanego motywu. W jednej raportowanej konfiguracji wskaźnik odtworzenia osiągnął 0,807.

Jednak przy piątej kopii wyniki załamały się — dokładnie przy jednym powtórzeniu więcej niż maksymalna liczba w danych treningowych. Model najwyraźniej nauczył się rozkładu liczby powtórzeń, a nie abstrakcyjnej reguły pętli.

Projekt przetestował również zgodność geometryczną w warunkach teacher forcing. Teacher forcing ocenia kolejny poprawny element po dostarczeniu prawdziwej wcześniejszej sekwencji.

W tej konfiguracji zgodne kontynuacje otrzymały wyraźną przewagę 4,28 bitu na docelowy bajt. Raportowany skorygowany poziom istotności wyniósł 0,001.

Swobodne próbkowanie przyniosło zupełnie inny wynik. Dokładne ukończenie powiodło się jedynie w około jednym procencie przypadków dla testowanych złożonych kształtów.

Sukces w prostszych przypadkach płaskich kroków mieścił się w przedziale od siedmiu do 13 procent. Model potrafił rozpoznać zgodną kontynuację, gdy pokazano mu kontekst, lecz rzadko sam konstruował całą kontynuację.

To rozłączenie jest kluczowe dla współczesnego modelowania generatywnego. Preferencja na poziomie tokenów może wyglądać przekonująco, podczas gdy niewielkie lokalne błędy kumulują się podczas autonomicznego próbkowania.

Każdy wygenerowany wynik staje się częścią kontekstu następnej predykcji. Jedna błędna współrzędna, opcode lub decyzja dotycząca długości może odsunąć sekwencję od warunków spotykanych podczas treningu.

RP2040 nie może naprawić tej semantycznej porażki. Potrafi wykonać wynikowy program dokładnie, ale dokładne wykonanie zachowuje błąd.

Hierarchiczne planowanie poprawia długość lepiej niż prawdopodobieństwo

Dodanie jawnej struktury poprawiło zakończenie, ale sprawiło, że rysunki były mniej prawdopodobne według głównej metryki straty projektu.

Autor porównał płaski transformer z projektami hierarchicznymi przy tym samym budżecie 825 344 parametrów. Systemy te najpierw przewidywały podsumowania pociągnięć, a następnie generowały szczegółowy bytecode dla każdego pociągnięcia.

Jeden planer wykorzystywał autoregresję. Drugi stosował dyfuzję, która stopniowo przekształca szum w uporządkowaną predykcję poprzez wielokrotne kroki odszumiania.

Oba warianty hierarchiczne uzyskały wynik gorszy od płaskiego modelu o około 40–55 bitów na rysunek. Dokładna kara różniła się zależnie od typu planera i budżetu obliczeniowego.

Eksperyment odrzucił zatem hipotezę, że hierarchiczne planowanie poprawi prawdopodobieństwo przy dopasowanej skali. Bardziej jawna struktura niosła ze sobą mierzalny koszt modelowania.

Planery mimo to dokładniej kontrolowały długość wyniku. Błąd rozkładu długości wynosił od 1,8 do 3,5 bajta, zależnie od konfiguracji.

Odpowiadająca mu luka dla płaskiego modelu mieściła się w zakresie od 7,0 do 13,6 bajta. Model częściej kończył zbyt wcześnie lub kontynuował aż do maksymalnej dozwolonej długości.

To nie jest drobny szczegół implementacyjny. Wygenerowane programy muszą kończyć się w sensownych granicach, zanim staną się użytecznymi poleceniami.

Model o lepszym średnim prawdopodobieństwie nadal może tworzyć niewygodne próbki, jeśli przypisuje zbyt wysokie prawdopodobieństwo przedwczesnemu zakończeniu. Może też generować długie, powtarzalne ogony.

Hierarchia oddzieliła liczbę pociągnięć od lokalnej konstrukcji pociągnięcia. Ta jawna decyzja poprawiła rozkład generowanych długości, nawet gdy całkowite prawdopodobieństwo spadło.

Dyfuzja nie zapewniła wyraźnej przewagi nad planerem autoregresyjnym dla wspólnej reprezentacji podsumowań. Zysk w zakresie zakończenia wynikał z hierarchii, a nie z odszumiania.

Późniejsze eksperymenty z zestawem instrukcji przyniosły podobny wzorzec. Jawne operacje powtórz-i-przekształć zapewniły ograniczoną bezpośrednią kompresję, ponieważ model już przewidywał powtarzalną geometrię z niskim zaskoczeniem.

Krótsze sekwencje poprawiły jednak wykorzystanie kontekstu i zakończenie. Raportowane błędy długości generowanych wyników spadły do zakresu od dziewięciu do 11 procent.

Porównywalne płaskie modele wykazały błędy od 41 do 112 procent. Są to eksperymentalne pomiary własne autorów, ale pokazują istotne napięcie projektowe.

Reprezentacja może pomagać w generowaniu, nie wygrywając pod względem konwencjonalnej straty testowej. I odwrotnie, niższa strata nie gwarantuje dobrze uformowanych programów podczas próbkowania.

To napięcie powinno kształtować przyszłą ewaluację. Badacze potrzebują metryk poprawności, dokładnego domykania relacji, zakończenia, nowości i zachowania podczas wykonania.

Jakość wizualna pozostaje istotna, ale nie może być jedynym kryterium. Dwa rysunki mogą wyglądać podobnie, choć ich programy znacząco różnią się długością, strukturą lub możliwością ponownego wykorzystania.

Memoryzacja jest kolejną nierozwiązaną kwestią. Mały model może odtwarzać znane motywy bez nauczenia się przekształceń, które je generują.

Repozytorium dokumentuje kontrole pozycji, bliskości, częstotliwości i zbiorów współrzędnych. Kontrole te wzmacniają eksperyment relacyjny, lecz nie rozstrzygają kwestii nowości w całym korpusie treningowym.

Silniejsze wydanie obejmowałoby checkpointy, manifesty treningowe, wygenerowane próbki, analizy najbliższych sąsiadów oraz powtarzalne skrypty end-to-end.

Wiele niezależnych ziaren treningowych wyjaśniłoby również, które zachowania utrzymują się po zmianie inicjalizacji. Niektóre wyniki powtórzeń poza rozkładem już zauważalnie różniły się między ziarnami.

Obecny projekt raportuje negatywne wyniki zamiast je ukrywać. To wartościowe, ponieważ porażki wskazują, gdzie kompaktowe modele przestają zachowywać się jak rozumujące systemy symboliczne.

Co należy zweryfikować w następnej kolejności

Kolejnym kamieniem milowym nie jest większa galeria, lecz dowód, że jawne relacje poprawiają generowanie nieznanych wcześniej programów.

Obecny kierunek projektu dodaje akcję copy-or-emit. Model może albo tworzyć zwykłe bajty, albo odwołać się do wcześniejszego zakresu źródłowego z transformacją afiniczną.

Transformacja afiniczna może przesuwać, obracać, odbijać lub skalować geometrię przy zachowaniu linii prostych. W tym systemie obsługiwane operacje pozostałyby oparte na liczbach całkowitych i wykonywalne przez istniejący styl VM.

Propozycja ta bezpośrednio celuje w lukę ujawnioną przez teacher forcing. Model już wydaje się wrażliwy na zgodny kontekst relacyjny, ale swobodne próbkowanie rzadko domyka tę relację dokładnie.

Jawna akcja mogłaby zmniejszyć liczbę oddzielnych decyzji potrzebnych do odtworzenia przekształconego motywu. Jedna poprawna relacja mogłaby zastąpić wiele kruchych predykcji współrzędnych.

Pierwszym sygnałem, który należy obserwować, jest skuteczność w przypadku nieznanych kombinacji. Model powinien generować dokładne relacje wykluczone z treningu, a nie jedynie kompresować znane powtarzalne kształty.

Ewaluacja powinna porównywać płaską emisję z zachowaniem copy-or-emit przy dopasowanych budżetach parametrów i treningu. Dokładny sukces swobodnego generowania ma większe znaczenie niż sama preferencja wymuszona przez teacher forcing.

Jeśli domykanie nieznanych relacji wzrośnie wyraźnie ponad raportowany poziom jednego procenta, mechanizm zyska wiarygodność. Jeśli poprawi się wyłącznie prawdopodobieństwo, centralny problem generowania pozostanie nierozwiązany.

Drugim sygnałem jest niezależne odtworzenie testów sprzętowych. Projekt udostępnia kod źródłowy i zarejestrowane artefakty, ale obecnie nie dołącza checkpointu modelu.

Zewnętrzny deweloper powinien móc odbudować interpreter, uruchomić zestaw testów zgodności, wysłać wygenerowane programy do Pico i odtworzyć bitowo identyczne ślady wykonania.

Proces ten powinien raportować ustawienia kompilatora, konfigurację zegara, narzut transportu oraz pełne rozliczenie pamięci. Powinien rozróżniać pamięć flash interpretera od całkowitego rozmiaru firmware'u.

Udane odtworzenie wzmocniłoby twierdzenie dotyczące wykonania. Rozbieżność pomogłaby ustalić, czy wynik zależy od toolchainu, rewizji płytki czy nieudokumentowanych szczegółów konfiguracji.

Trzecim sygnałem jest pomiar zasobów end-to-end. Obecna wartość 0,611 milisekundy obejmuje wykonanie VM przy 12 MHz, a nie inferencję hosta ani transfer szeregowy.

Praktyczna demonstracja powinna oddzielać czas generowania, czas walidacji, czas transferu, czas wykonania i czas renderowania. Pomiary energii wyjaśniłyby również koszt etapu wbudowanego.

Pomiary te nie przekształciłyby projektu w AI działające na urządzeniu. Pokazałyby, czy architektura podzielona oferuje użyteczny kompromis systemowy.

Szersza lekcja wydaje się już wiarygodna, nawet przed tymi testami. Małe modele generatywne mogą tworzyć wykonywalne reprezentacje pośrednie, podczas gdy niewielkie deterministyczne środowiska wykonawcze egzekwują wąskie reguły operacyjne.

Nadal nie wiadomo, czy model potrafi generować właściwą strukturę poza znanymi kombinacjami. Dokładność sprzętowa rozwiązuje jedynie ostatni etap tego problemu.

Deweloperzy oceniający model rysowania dla RP2040 powinni zatem zadać dwa odrębne pytania. Czy Pico wykonuje każdą poprawną instrukcję dokładnie i czy transformer niezawodnie zapisuje zamierzony program?

Dostępne dowody dają mocną odpowiedź własną autorów na pierwsze pytanie. Na drugie udzielają znacznie bardziej ostrożnej odpowiedzi.

Warto obserwować eksperyment copy-or-emit, wydanie powtarzalnych checkpointów oraz niezależny test Pico. Te trzy testy zadecydują, czy stanie się to wzorcem projektowym do ponownego wykorzystania, czy pozostanie pouczającym prototypem badawczym.