Transformer z 21 miliardami parametrów uruchamia renderer Doom bez treningu

Cursor Horizon ma teraz nietypowy techniczny punkt odniesienia: transformer z 21 miliardami parametrów, który renderuje Doom bez przechodzenia treningu. Deweloper Rob Porter skompilował algorytm renderowania gry bezpośrednio do wag transformera. Rezultat podważa założenie, że każdy duży transformer nauczył się swojego działania na danych.

Model nie przewiduje, jak powinna wyglądać klatka Doom. Wykonuje przetłumaczony proces renderowania, token po tokenie. Prompt dostarcza geometrię sceny i stan kamery. Wynik zawiera obliczenia pośrednie oraz polecenia rysowania, które niewielki program hosta zamienia na piksele.

To rozróżnienie oddziela projekt od generatywnych eksperymentów z Doom trenowanych na nagraniach rozgrywki. Tworzy też główne napięcie tej historii Cursor Horizon. Inferencja transformera stała się osobliwym celem dla konwencjonalnego oprogramowania, a mimo to powstały program działa drastycznie wolniej niż oryginalna gra.

Publicznie dostępne materiały pozwalają wyjątkowo dokładnie zweryfikować to twierdzenie. Porter udostępnił kompilator, graf renderera, checkpointy, prompt, narzędzia dekodujące i implementację referencyjną. Większość wyników dotyczących wydajności i dokładności nadal pochodzi jednak z własnych testów projektu, a nie z niezależnej replikacji.

Renderer Doom stał się standardowym checkpointem transformera

Najważniejsza zmiana nie polega na tym, że model AI stworzył obraz z Doom. Chodzi o to, że zwykły kod renderujący stał się wagami modelu.

Porter opublikował projekt 13 sierpnia 2026 roku, a następnie zamieścił szczegółowy wpis dla społeczności. Jego opis techniczny przedstawia kompilator o nazwie torchwright. Przekształca on grafy obliczeniowe w wagi mechanizmów uwagi i warstw feed-forward transformera typu decoder-only.

Nie ma tu pętli optymalizacji, zbioru treningowego, aktualizacji gradientowej ani wyuczonego przybliżenia rozgrywki w Doom. Kompilator wylicza wagi checkpointu na podstawie grafu zapisanego w Pythonie. Wagi kodują operacje potrzebne rendererowi podczas wykonania.

Wygenerowany artefakt korzysta ze standardowej architektury Phi3ForCausalLM. To istotne, ponieważ Hugging Face Transformers już potrafi go ładować i wykonywać. Użytkownicy nie potrzebują własnego kodu modelu ani potencjalnie wrażliwego ustawienia trust_remote_code=True.

Flagowy checkpoint zawiera 38 warstw transformera i około 21 miliardów parametrów. Jego shardy wag fp32 zajmują 85,87 GB. Mniejsza wersja 80 na 50 wykorzystuje 70 warstw i 34,09 GB shardów fp32.

Większy checkpoint otrzymuje prompt o długości 3 614 tokenów, reprezentujący scenę. Następnie generuje 53 747 tokenów przed ukończeniem klatki. Łączna sekwencja osiąga 57 361 tokenów.

Tylko część tego wyniku bezpośrednio maluje piksele. Pozostałe tokeny reprezentują operacje renderera, wyliczone wartości, przepływ sterowania i stan tymczasowy. Działają bardziej jak ślad wykonania niż język naturalny.

Opublikowany checkpoint obejmuje konfigurację modelu, tokenizer, prompt, paletę i narzędzia dekodujące. Jego tokenizer używa czytelnych słów dla operacji i wartości. Ten wybór sprawia, że fragmenty śladu wykonania są zrozumiałe bez dekodowania arbitralnych identyfikatorów tokenów.

Program hosta wykonuje celowo wąskie zadanie. Zapamiętuje pozycję kursora, wybiera kolory z palety Doom i maluje żądane ciągi pikseli. Nie oblicza widoczności, geometrii, kolejności ścian, współrzędnych tekstur ani okluzji.

Pięć poleceń wyjściowych steruje rysowaniem. Dwa ustawiają współrzędne kursora. Dwa wybierają, czy kursor przesuwa się poziomo czy pionowo. Piąte maluje ciąg pikseli o określonym kolorze i szerokości.

Ta granica ma kluczowe znaczenie dla wiarygodności projektu. Model, który jedynie zlecałby zewnętrznemu oprogramowaniu renderowanie Doom, byłby mniej interesujący. Tutaj checkpoint podobno wykonuje zależne od widoku obliczenia renderujące, podczas gdy host mechanicznie stosuje jego instrukcje rysowania.

Checkpoint nie jest pełną grą Doom. Nie implementuje rozgrywki, przeciwników, ogólnych sprite’ów, dźwięku ani sterowania graczem. Implementuje ograniczoną wersję renderera dla scen korzystających ze stałej biblioteki tekstur.

Pełny wynik wykorzystuje rozdzielczość wyświetlania Doom 320 na 200 w trybie niskiej szczegółowości. Renderer oblicza 160 kolumn i wyświetla każdą z nich na szerokości dwóch pikseli. Do modelu skompilowano dziewięć tekstur ścian oraz sześć tekstur podłóg lub sufitów.

Pozycja gracza, kierunek widzenia, geometria mapy, informacje o sektorach i drzewo binarnego podziału przestrzeni trafiają do modelu przez prompt. Drzewo binarnego podziału przestrzeni, czyli drzewo BSP, dzieli mapę, aby efektywnie porządkować widoczność.

Dane wejściowe mogą się zmieniać bez przebudowy checkpointu, pod warunkiem że scena pozostaje w granicach skompilowanych tekstur i konfiguracji. Dodanie nieobsługiwanej tekstury wymaga rekompilacji.

Właśnie dlatego ujęcie Cursor Horizon zasługuje na uwagę. Projekt traktuje checkpoint transformera jako wykonywalny format pakietu, a nie magazyn wyuczonej wiedzy. Jego parametry są materiałem programowym wygenerowanym przez kompilator.

Dlaczego Cursor Horizon podważa model „najpierw trening”

Torwright zamienia architekturę transformera w deterministyczne podłoże obliczeniowe, choć nie oferuje praktycznej alternatywy dla konwencjonalnych procesorów.

Większość dużych modeli językowych nabywa zachowania poprzez trening. Inżynierowie wybierają architekturę, wystawiają ją na dane, mierzą błędy i dostosowują wagi za pomocą spadku gradientowego. Końcowy model zawiera wzorce wyuczone na tych przykładach.

Torwright odwraca ten proces. Deweloper definiuje graf obliczeniowy, a kompilator konstruuje wagi wykonujące jego operacje. Gotowy transformer wciąż przewiduje kolejny token po kolejnym, lecz proces predykcji podąża za zaprojektowanym programem.

To rozróżnienie przypomina różnicę między uczeniem się mnożenia na przykładach a uruchamianiem układu mnożącego. Oba podejścia mogą dać tę samą odpowiedź. Różnią się jednak pochodzeniem wewnętrznym, granicami niezawodności i trybami awarii.

Otwarty kompilator torchwright obsługuje operacje liniowe, wyszukiwania oparte na uwadze, porównania, wybór i mnożenie. Planuje węzły grafu między warstwami transformera oraz przechowuje wyliczone wartości w strumieniu rezydualnym.

Strumień rezydualny to ewoluujący wektor przekazywany przez warstwy transformera. Torchwright przypisuje fragmenty tego wektora wartościom programu. Gdy dana wartość nie jest już potrzebna, inna operacja ją anuluje i ponownie wykorzystuje jej przestrzeń.

W tym układzie uwaga robi więcej niż semantyczne kojarzenie. Pobiera wartości z wcześniejszych tokenów przez dopasowywanie ustrukturyzowanych pól. Pola te mogą reprezentować identyfikator węzła, głębokość drzewa, typ operacji lub współrzędną ekranu.

Warstwy feed-forward implementują operacje nieliniowe. Torchwright oferuje biblioteki operacji zbudowane na aktywacjach ReLU lub SwiGLU. Kompilator przekształca każdą operację grafu w konkretne wiersze wag feed-forward albo głowy uwagi.

Podejście to ma akademickich poprzedników. RASP wprowadził język programowania, którego prymitywy mapują się na operacje transformera. Badanie DeepMind Tracr kompilowało programy RASP do wag transformera na potrzeby eksperymentów z interpretowalnością.

Torwright rozwija ten kierunek w stronę zwykłych grafów obliczeniowych Pythona oraz standardowego formatu wyjściowego Phi-3. Cel jest znaczący, ponieważ istniejące oprogramowanie inferencyjne może załadować wynik bez rozumienia jego nietypowego pochodzenia.

Ta kompatybilność tworzy prowokującą możliwość. Standardowy checkpoint może zawierać wyuczone zachowanie statystyczne, celowo skompilowaną logikę albo mieszankę obu. Sama struktura pliku nie ujawniłaby, która ścieżka wytworzyła jego wagi.

Dla deweloperów zmienia to sposób interpretowania artefaktów modeli. Liczba parametrów zwykle służy jako przybliżony sygnał wyuczonej pojemności i kosztu inferencji. Tutaj 21 miliardów parametrów odzwierciedla przede wszystkim wyjątkowo nieefektywny cel kompilacji.

Ta liczba nie oznacza, że checkpoint posiada szeroką wiedzę językową. Nie potrafi odpowiadać na ogólne pytania ani improwizować scen Doom poza obsługiwanym rendererem. Jego wagi implementują ograniczony program, a nie otwarty model językowy.

Cursor Horizon uchwytuje więc szerszy problem granic. Ekosystem transformerów zapewnia dziś mechanizmy ładowania, akceleratory, sharding, narzędzia wdrożeniowe i standaryzowane klasy modeli. Kompilator może wykorzystać tę infrastrukturę dla oprogramowania, które nigdy nie było trenowane.

Nie czyni to transformerów lepszymi od CPU. Pokazuje, że ich mechanika wykonawcza jest wystarczająco ogólna, by obsługiwać jawnie skonstruowane algorytmy. Ogólność, wydajność i użyteczność pozostają odrębnymi kwestiami.

Najmocniejszy wkład projektu jest koncepcyjny, a nie komercyjny. Uwidacznia różnicę między architekturą a treningiem. Transformer jest strukturą matematyczną. LLM to jedno znane zastosowanie zbudowane przez trenowanie tej struktury na języku.

Model Portera usuwa proces uczenia, zachowując znane zachowanie inferencyjne. Przyjmuje tokeny, stosuje warstwy uwagi i feed-forward, wybiera następny token i powtarza proces. Pętla wygląda zwyczajnie, nawet jeśli obliczenia w jej wnętrzu takie nie są.

Ta właściwość oferuje również kontrolowane środowisko badawcze. Ponieważ każda waga pochodzi ze znanych operacji grafu, badacze mogą prześledzić, dlaczego pojawia się dana wartość. Wyraźnie różni się to od interpretowania modelu, którego wewnętrzne cechy wyłoniły się podczas treningu.

Checkpoint Doom jest jednak znacznie większy niż typowe modele testowe do badań interpretowalności. Jego skala pokazuje, że skompilowane konstrukcje mogą osiągać współczesną infrastrukturę modeli. Sprawia też, że inspekcja i niezależne odtworzenie są kosztowne.

Transformer wykonuje Doom token po tokenie

Renderer działa przez przekształcenie mutowalnego stanu wykonania Doom w historię tokenów typu append-only, którą uwaga może przeszukiwać.

Renderer Doom przechodzi drzewo BSP od bliskich regionów do dalekich. Rzutuje ściany na kolumny ekranu, śledzi obszary już zakryte i pomija geometrię ukrytą za bliższymi powierzchniami.

Konwencjonalny kod aktualizuje zmienne i struktury danych w pamięci. Generowanie autoregresyjne nie może modyfikować wcześniejszych tokenów. Każdy nowy token dołącza do sekwencji typu append-only, która pozostaje dostępna dla późniejszych przebiegów transformera.

Skompilowany renderer rozwiązuje tę niezgodność, reprezentując każdą zmianę stanu jako kolejny token. Późniejsze operacje wykorzystują uwagę, aby znaleźć najnowszy istotny rekord lub połączyć wiele wcześniejszych rekordów.

Rekurencyjne przechodzenie drzewa zwykle opiera się na stosie wywołań. Model zamiast tego emituje rekordy śladów podczas schodzenia w dół. Gdy dociera do liścia, uwaga pobiera właściwy ślad i określa, gdzie wykonanie powinno zostać wznowione.

Pokrycie ścian wymaga innej strategii. Doom przechowuje zakryte zakresy poziome w mutowalnej strukturze o nazwie solidsegs. Zakresy te pomagają unikać rysowania ścian już ukrytych przez bliższą geometrię.

Transformer nie może scalać ani nadpisywać wcześniejszych rekordów zakresów. Dopisuje każdy nowo zakryty zakres. Kolejne operacje odpytują skumulowaną historię, aby ustalić, czy kolumna jest zakryta i gdzie kończy się zakryty przedział.

Podłogi i sufity działają według pokrewnego schematu. Przebieg ścian rejestruje ich widoczne granice dla każdej kolumny ekranu. Późniejszy przebieg pobiera te rekordy i emituje poziome ciągi rysowania.

Wynik jest sekwencją tokenów pełniącą kilka ról. Jest strumieniem instrukcji, pamięcią roboczą, stosem wywołań, dziennikiem stanu i protokołem wyjściowym. Mechanizm uwagi zapewnia odwołania łączące te role.

Długie obliczenia są również dzielone między generowane tokeny. Warstwa transformera może wykonać jedynie ograniczoną ilość pracy sekwencyjnej, zanim przekaże dalej swój strumień rezydualny. Dłuższe łańcuchy zależności wymagałyby większej liczby warstw.

Renderer czasem emituje wynik pośredni i wykorzystuje go podczas późniejszego kroku dekodowania. Ta strategia zużywa więcej tokenów, aby zmniejszyć głębokość potrzebną dla każdego kroku.

Projekcja ścian ilustruje ten kompromis. Model oblicza kąty świata, przekształca je w kąty względem kamery, a następnie rzutuje punkty końcowe na ekran. Pośrednie tokeny kątów rozdzielają te zależne etapy.

Ten projekt utrzymuje flagowy model na poziomie 38 warstw. Przyczynia się też do konieczności wykonania rolloutów o długości 53 747 tokenów dla jednej klatki. Każde dodatkowe pośrednie przekazanie wymaga kolejnego pełnego przebiegu modelu.

Źródło renderera ujawnia ten potok. Moduły obsługują dane wejściowe sceny, przechodzenie po grafie, projekcję, rasteryzację, tekstury i protokół wyjściowy. Oddzielny renderer Python służy jako wzorzec poprawności.

Model generuje tokeny zachłannie, co oznacza, że wybiera najwyżej oceniony kolejny token bez próbkowania. Losowość byłaby nieodpowiednia, ponieważ checkpoint ma wykonywać deterministyczną logikę.

Słowo kluczowe Cursor Horizon staje się tu użyteczne jako metafora granicy stanu modelu. Jego kursor wyjściowy przesuwa się po renderowanym obrazie, podczas gdy horyzont uwagi sięga wstecz przez historię wykonania.

Mechanizm jest jednak bardziej dosłowny niż poetycki. Każda nowa operacja może sprawdzać wcześniejsze fakty dotyczące sceny i wygenerowane rekordy. Nic w tym procesie nie wymaga semantycznej elastyczności kojarzonej z modelami konwersacyjnymi.

Prompt działa jak pamięć tylko do odczytu. Zawiera niezależne od widoku fakty o mapie oraz pozycję i kierunek gracza. Wygenerowana część działa jako pamięć robocza tylko do dopisywania dla obliczeń zależnych od widoku.

Host interpretuje później tokeny rysowania za pomocą 256-kolorowej palety Doom. Przesuwa programowy kursor i maluje żądane odcinki. Minimalna demonstracja Portera implementuje tę stronę w 43 liniach Pythona.

Ten niewielki host nie dowodzi, że każde obliczenie renderowania znajduje się w checkpointcie. Publiczne źródło umożliwia jednak sprawdzenie granicy. Recenzenci mogą przeanalizować konstrukcję promptu, moduły grafu, dekodowanie wyjścia i porównanie referencyjne.

Projekt raportuje kontrole piksel po pikselu względem swojego renderera Python. Dla flagowej klatki zmierzono pełne pokrycie pikseli, 99,9 procent zgodności w ramach dozwolonych opcji kolorów oraz 96,7 procent dokładnej zgodności.

Liczby te nieznacznie różnią się od zaokrąglonych 97 procent użytych w pierwotnym artykule. Kanoniczny plik faktów repozytorium przypisuje najnowsze pomiary renderowi produkcyjnemu z 9 sierpnia.

Checkpoint o niższej rozdzielczości miał podobno osiągnąć pełne pokrycie, pełną zgodność kolorów w ramach opcji i 93,9 procent dokładnej zgodności. Jego klatka zawierała 3964 porównywane piksele.

Są to pomiary raportowane przez projekt. Niezależne testy nie ustaliły jeszcze, czy te same wyniki utrzymują się w różnych środowiskach, promptach lub wariantach sceny.

Prawdziwym wynikiem jest 35 klatek dziennie

Projekt odnosi sukces jako demonstracja kompilatora właśnie dlatego, że tak dramatycznie zawodzi jako praktyczny renderer Doom.

Oryginalny Doom celował w 35 klatek na sekundę na sprzęcie z początku lat 90. Pełny checkpoint Portera generuje około 0,0004 klatki na sekundę na akceleratorze Nvidia B200.

Zachłanne dekodowanie zajęło 2383,5 sekundy podczas raportowanego przebiegu produkcyjnego. Ładowanie modelu i inne narzuty zwiększyły czas od początku do końca do 2528,1 sekundy, czyli 42,1 minuty.

Daje to około 35 klatek dziennie, przy założeniu ciągłej pracy i podobnego czasu wykonania. To porównanie stało się najbardziej zapamiętywanym żartem projektu. Ujawnia również podstawowy koszt kompilowania zwykłego oprogramowania do inferencji autoregresyjnej.

Każdy emitowany token wymaga kolejnego przebiegu przez model z 21 miliardami parametrów. Narysowanie klatki obejmuje dziesiątki tysięcy takich przebiegów. Architektura serializuje operacje, które konwencjonalny sprzęt wykonuje za pomocą zwartych instrukcji i równoległych potoków.

Przebieg na B200 miał podobno rezerwować w szczycie 151 GiB pamięci. Sam checkpoint zajmuje niemal 80 GiB, gdy mierzy się go w binarnych gibibajtach. Nie jest to program, który większość czytelników może przetestować na desktopowym GPU.

Konsumencki checkpoint zmniejsza rozdzielczość do 80 na 50 pikseli. Generuje rollout o długości 7007 tokenów i podobno dekoduje się w 338,3 sekundy na jednym A100 z 80 GB pamięci.

Jego checkpoint o rozmiarze 34,09 GB można również rozdzielić między dwa konsumenckie GPU z 32 GB pamięci za pomocą automatycznego mapowania urządzeń. Ta wersja ułatwia replikację, choć wciąż pozostaje ekstrawagancka jak na niewielką klatkę.

Precyzja tworzy kolejne ograniczenie. Opublikowane modele używają wag fp32. Konwencjonalne wdrożenia LLM często zmniejszają zużycie pamięci i obliczeń dzięki formatom o niższej precyzji lub kwantyzacji.

Kwantyzacja jest tu ryzykowna, ponieważ błędy numeryczne nie tylko osłabiają prawdopodobieństwa językowe. Mogą uszkodzić stan programu, porównania, wyszukiwania przypominające adresowanie oraz kompensację w strumieniu rezydualnym.

Dokumentacja kompilatora Torwright przyznaje, że niektóre konstrukcje nieliniowe wykorzystują aproksymacje odcinkowo-liniowe. Jej testy mierzą granice błędów dla poszczególnych operacji i porównują skompilowane węzły grafu z bezpośrednią ewaluacją.

Te zabezpieczenia dostarczają dowodów, ale nie matematycznej pewności dla każdego pełnego wykonania. Granice błędów dla pojedynczych operacji nie sumują się automatycznie w długich łańcuchach. Kompilator opiera się więc na szerszych sondach grafu i porównaniach wyników.

Publiczna dyskusja projektu na Reddit podniosła tę obawę bezpośrednio. Porter powiedział, że oczekiwałby uszkodzonego wyjścia po nieostrożnej kwantyzacji, a nie obrazu o niższej jakości. Zauważył też, że nie testował tego scenariusza.

Kolejne ograniczenie dotyczy ogólności. Checkpoint obsługuje wybrany region, stałą rozdzielczość oraz tekstury potrzebne wokół początkowego obszaru E1M1. Nie odtwarza całego renderera dla całej zawartości Doom.

Sprite’y pozostają niezaimplementowane. Broń i pasek stanu są na stałe ustawione na stan początkowy z pistoletem. Model renderuje scenę, a nie interaktywną pętlę gry z normalnymi systemami rozgrywki.

Prompt mapy projektu również przechodzi przygotowanie przed inferencją. Kod po stronie hosta przycina poziom do stałego regionu w przestrzeni świata i koduje statyczne fakty jako tokeny. Repozytorium opisuje tę granicę jako porównywalną z ładowaniem poziomu.

Krytycy mogą zasadnie pytać, czy nadal można uznać to za Doom działający wewnątrz transformera. Najbardziej uzasadniona odpowiedź jest węższa: logika renderowania zależna od widoku działa wewnątrz skompilowanego checkpointu dla ograniczonej sceny Doom.

Twierdzenie, że sam Doom stał się LLM, byłoby nieprecyzyjne. Checkpoint nie ma wyuczonej zdolności językowej i nie implementuje kompletnej gry. „Renderer hostowany przez transformera” jest trafniejszym określeniem.

Perspektywa Cursor Horizon powinna zachować to rozróżnienie. Projekt poszerza zakres tego, co może reprezentować standardowy plik modelu, ale nie pokazuje konkurencyjnej nowej drogi dla obliczeń graficznych.

Projekt nie otrzymał też szerokiej niezależnej weryfikacji. Repozytorium udostępnia kod, wagi, prompty, pomiary i narzędzia porównawcze. Odtworzenie flagowego wyniku nadal wymaga kosztownego sprzętu i znacznej przepustowości pobierania.

Reakcje społeczności odzwierciedlają obie strony. Deweloperzy chwalili pomysł kompilatora i śmiali się z jego wydajności. Inni pytali, czy równoległe wyjścia, alternatywne architektury lub systemy dyfuzyjne renderowałyby klatki wydajniej.

Te sugestie pomijają część celowego ograniczenia projektu. Porter chciał standardowego modelu generowania tekstu, który mogłyby ładować zwykłe klasy Hugging Face. Ten wybór powiązał renderer z nieefektywną pętlą jednego tokenu na krok.

Zmiana architektury mogłaby zwiększyć szybkość, osłabiając jednocześnie demonstrację. Projekt jest interesujący, ponieważ akceptuje ograniczenia klasycznego przyczynowego transformera i mimo to kończy proces renderowania.

Co Cursor Horizon powinien obserwować dalej

Kolejnym testem nie jest następny imponujący zrzut ekranu. Jest nim to, czy osoby z zewnątrz potrafią odtworzyć, skompresować i uogólnić skompilowane wykonanie.

Pierwszym sygnałem jest niezależne odtworzenie. Strona trzecia powinna uruchomić udostępniony checkpoint o niskiej rozdzielczości, porównać jego wynik z rendererem referencyjnym oraz opublikować szczegóły sprzętowe i programowe.

Udana replikacja wzmocniłaby twierdzenie, że standardowy checkpoint wykonuje udokumentowany graf. Rozbieżne wyjście ujawniłoby wrażliwość na wersje transformera, jądra numeryczne, rozmieszczenie urządzeń lub zachowanie zmiennoprzecinkowe.

Drugim sygnałem jest wykonanie z niższą precyzją. Zweryfikowana wersja bf16, fp16 lub skwantyzowana obniżyłaby barierę sprzętową projektu. Sprawdziłaby również, czy torchwright potrafi zarządzać kompensacją rezydualną i porównaniami przy obniżonej precyzji.

Sukces ułatwiłby badanie i dystrybucję skompilowanych transformerów. Niepowodzenie wyjaśniłoby, że dokładne zachowanie numeryczne pozostaje głównym ograniczeniem tego modelu programowania.

Trzecim sygnałem jest szersza obsługa scen. Ten sam checkpoint powinien renderować wiele pozycji, kierunków i zgodnych regionów mapy bez ponownej kompilacji. Opublikowane porównania powinny obejmować więcej niż flagowy widok E1M1.

Ten test oddzieliłby implementację ogólnego renderera od wysoce zoptymalizowanej ścieżki demonstracyjnej. Pokazałby również, jak mechanizm stanu tylko do dopisywania zachowuje się przy zmianach geometrii i liczby tokenów.

Równoległość pozostaje ważnym pytaniem długoterminowym. Obecny projekt Portera wykorzystuje jeden wygenerowany token dla każdego ograniczonego kroku obliczeniowego. System emitujący kilka bezpiecznych operacji na przebieg mógłby zmniejszyć ogromne obciążenie dekodowania.

Ta zmiana musi jednak zachować centralne twierdzenie projektu. Przeniesienie obliczeń geometrii lub decyzji o widoczności do kodu hosta poprawiłoby wydajność przez relokację renderera, a nie przez ulepszenie skompilowanego wykonania transformera.

Przyszłe przykłady torchwright mogą okazać się bardziej pouczające niż szybsze klatki Doom. Deterministyczne parsery, walidatory protokołów, kalkulatory i przejrzyste moduły algorytmiczne lepiej pasują do mocnych stron kompilatora niż grafika czasu rzeczywistego.

Skompilowaną logikę można również połączyć z wyuczonymi komponentami. Wyuczony model mógłby obsługiwać niejednoznaczny język, podczas gdy skonstruowana podsieć wymuszałaby obliczenie lub protokół. Ta możliwość pozostaje spekulatywna i technicznie trudna.

Badacze bezpieczeństwa powinni również obserwować standardowe formaty checkpointów. Istniejące skanery modeli często koncentrują się na serializowanym kodzie, niebezpiecznym ładowaniu lub podejrzanych plikach. Bezpośrednio skonstruowane wagi wprowadzają zachowanie bez dostarczania konwencjonalnego kodu wykonywalnego.

Nie czyni to torchwright złośliwym. Jego źródło i intencje są wyjątkowo otwarte. Szersza lekcja brzmi: „brak niestandardowego kodu” nie oznacza „braku zaprogramowanego zachowania”.

Deweloperzy powinni również powstrzymać się od traktowania liczby parametrów jako miary inteligencji. Ten checkpoint ma 21 miliardów parametrów, ponieważ jego kompilator mapuje renderer na niewygodną architekturę. Sam rozmiar niewiele mówi o wyuczonej wiedzy lub użytecznym rozumowaniu.

Dla czytelników Cursor Horizon praktycznym wnioskiem jest precyzyjniejszy model mentalny transformerów. Trenowanie to jeden ze sposobów ustawiania ich wag. Kompilacja jest drugim, nawet jeśli wynik jest skrajnie nieefektywny.

Projekt jest najcenniejszy jako wykonywalny argument. Pokazuje, że znana infrastruktura modelowa może przenosić deterministyczne programy, a nie tylko wspomnienia statystyczne. Pokazuje również, dlaczego konwencjonalne komputery wciąż są wyjątkowo dobre w konwencjonalnych obliczeniach.

Spróbuj prześledzić wykonanie, przeanalizować graf kompilatora albo odtworzyć mniejszy punkt kontrolny. Następnie zadaj pytanie ważniejsze niż samo Doom: które algorytmy rzeczywiście zyskują na wykonaniu natywnym dla transformera, a które stają się jedynie kosztowną ciekawostką?