Apple ponownie otwiera spór sprzętowy: retrospektywna inżynieria wsteczna Neural Engine firmy Apple

Neural Engine z układu M1 firmy Apple ponownie znalazł się pod lupą, mimo trzyletniej przerwy w projekcie sterownika Linux stworzonym, by go zrozumieć. Retrospektywna inżynieria wsteczna Neural Engine firmy Apple dokumentuje, dlaczego ten akcelerator świetnie sprawdzał się w starszych sieciach neuronowych, lecz ma trudności ze współczesnymi obciążeniami transformerów.

Eileen Yoon, była współtwórczyni Asahi Linux, wróciła do porzuconej pracy po tym, jak Apple zmieniło kierunek rozwoju sprzętu. M5 umieszcza Neural Accelerator w każdym rdzeniu GPU, zachowując jednocześnie osobny 16-rdzeniowy Neural Engine. To połączenie podważa założenie, że jeden akcelerator o stałej funkcji powinien obsługiwać rosnące obciążenia Apple związane z generatywną AI.

To więcej niż opóźniona analiza sprzętu. Badanie łączy decyzje podjęte dla konwolucyjnych sieci neuronowych z 2017 roku, czyli CNN, z odpowiedzią Apple na współczesne modele językowe. GPU wywierają dziś presję na samodzielny Neural Engine, ponieważ transformery zależą od elastycznego harmonogramowania i ciągłego przesyłania danych w pamięci.

Uśpiony sterownik M1 stał się sekcją sprzętową

Nowa praca zmienia niedokończony sterownik Linux w opis tego, czym według Apple pierwotnie miało stać się uczenie maszynowe.

Yoon wcześniej stworzyła sterownik Linux ANE, który mógł komunikować się z Neural Engine wewnątrz układów M1. Projekt obejmował moduł jądra, bibliotekę przestrzeni użytkownika, testy i powiązania Pythona. Oferował drogę poza publiczną abstrakcją programową Apple, choć nie czynił sprzętu szeroko programowalnym.

Projekt następnie zamilkł na trzy lata. Yoon pisze, że ANE wydawał się zbyt wyspecjalizowany, by uzasadniać dalsze prace nad sterownikiem. Otwarcie jego interfejsu sprzętowego nie zmieniłoby tego, które operacje jego stały przepływ danych może wykonywać wydajnie.

To rozróżnienie ma znaczenie. Konwencjonalny sterownik może udostępniać możliwości, które sprzęt już posiada. Nie może przekształcić zaprojektowanego do określonego celu akceleratora przepływu danych w procesor ogólnego przeznaczenia.

Retrospektywa architektury Yoon zadaje więc inne pytanie niż pierwotny wysiłek związany ze sterownikiem. Zamiast pytać, jak Linux może wysyłać zadania, analizuje tablicę obliczeniową, harmonogram, system pamięci i model wykonania. Te komponenty ujawniają założenia dotyczące obciążeń zakodowane w projekcie M1.

Badanie opisuje 16 rdzeni obliczeniowych rozmieszczonych wokół centralnego bloku pamięci lokalnej. Każdy rdzeń zawiera równoległe jednostki mnożenia z akumulacją, czyli MAC, które mnożą dane wejściowe i dodają wyniki do akumulatorów. Operacje te stanowią podstawę konwolucji, mnożenia macierzy i iloczynów skalarnych używanych przez mechanizmy uwagi.

Jednostki MAC same w sobie nie wyjaśniają specjalizacji Neural Engine. Zarówno CNN, jak i transformery potrzebują mnożenia i akumulacji. Decydująca różnica tkwi w tym, jak wagi i aktywacje docierają do tych jednostek, pozostają dostępne i przemieszczają się przez układ.

Apple wprowadziło pierwszy Neural Engine wraz z A11 Bionic w 2017 roku. W tamtym czasie konsumenckie sieci neuronowe koncentrowały się na klasyfikacji obrazów, analizie twarzy i innych gęstych obciążeniach CNN. Sieci te oferowały regularne kształty tensorów i przewidywalne ponowne wykorzystanie danych.

M1 odziedziczył tę linię projektową, gdy Apple wprowadziło własne procesory do Maców. Jego Neural Engine zoptymalizowano pod skompilowane modele, których wymiary i wzorce przemieszczania danych były w znacznym stopniu znane z wyprzedzeniem. Ta specjalizacja zmniejszała opóźnienia i zużycie energii przy obsługiwanych zadaniach.

Retrospektywa nie twierdzi, że Neural Engine w M1 nie może wykonywać operacji transformerów. Dowodzi, że otaczający go przepływ danych sprawia, iż niektóre wzorce transformerów są nieefektywne, zwłaszcza dekodowanie autoregresyjne. Proces ten generuje po jednym tokenie, wielokrotnie odczytując wagi modelu i rosnącą pamięć podręczną uwagi.

To przeformułowanie tworzy centralne napięcie artykułu. Apple zbudowało wydajny silnik, ograniczając ruch danych wokół oczekiwanego obciążenia. Współczesna AI zmieniła dominujące obciążenie szybciej, niż mogła zmienić się stała architektura sprzętowa.

Retrospektywna inżynieria wsteczna Neural Engine firmy Apple ujawnia prawdziwe ograniczenie

Najważniejszym ograniczeniem Neural Engine w M1 nie jest wydajność arytmetyczna, lecz trasa, którą dane muszą pokonać wokół tej arytmetyki.

Poddany inżynierii wstecznej sterownik nigdy nie wysyła bezpośrednio do sprzętu poleceń wysokiego poziomu, takich jak CONV, MATMUL czy RELU. Kompilator Apple już przed rozpoczęciem wykonania przekształcił te operacje neuronowe w deskryptory zadań.

Deskryptor zadania to ustrukturyzowany blok danych konfiguracyjnych. Programuje grupy rejestrów kontrolujące wymiary tensorów, adresy pamięci, funkcje aktywacji, zależności i transfery danych. Sterownik umieszcza deskryptor w pamięci, kieruje do niego menedżer zadań i uruchamia sprzętowy „dzwonek do drzwi”.

Po tym zgłoszeniu Neural Engine kontroluje zadanie aż do ukończenia. Gdy zadanie się kończy, generuje przerwanie. Procesor hosta nie steruje każdą instrukcją matematyczną podczas działania operacji.

Yoon stwierdza, że ANE nie ma zestawu instrukcji w znanym sensie CPU lub GPU. Jego deskryptory zadań konfigurują wyspecjalizowany przepływ danych, zamiast dostarczać dowolny program. Każdy deskryptor reprezentuje jedno przejście przez ten przepływ danych.

Zadanie zaczyna się od załadowania rejestrów konfiguracji. Dedykowane bloki transferowe następnie przenoszą wagi i aktywacje wejściowe z pamięci głównej do oddzielnych magazynów lokalnych. Rdzenie obliczeniowe wykonują redukcje, przetwarzanie końcowe stosuje aktywację, a kolejny blok transferowy zwraca wynik.

Taka sekwencja sprzyja operacjom o przewidywalnym ponownym wykorzystaniu danych. Konwolucja może stosować ten sam niewielki zestaw wyuczonych filtrów w wielu obszarach obrazu. Akcelerator może utrzymywać zajęte swoje ścieżki arytmetyczne bez wielokrotnego pobierania dużego, nowego zestawu wag.

Dekodowanie transformerów zmienia tę równowagę. Każdy nowy token może wymagać przesłania strumieniowo znacznej części parametrów modelu. Arytmetyka pozostaje rozpoznawalna, lecz ruch danych staje się kosztem ograniczającym wydajność.

Układ M1 pogłębia ten problem, ponieważ rozdziela pamięć używaną dla wag od pamięci lokalnej wykorzystywanej dla kafelków aktywacji. Yoon wskazuje, że projekt zawiera około 1 MiB pamięci jądra i 2 MiB pamięci kafelków. Badanie argumentuje, że architektury nie zorganizowano tak, by efektywnie interpretować lokalnie wytworzone tensory jako wagi.

Było to rozsądne założenie dla modeli, które Apple miało na celu w 2017 roku. Wnioskowanie CNN zwykle traktuje wyuczone wagi jako stałe jądra, a aktywacje jako dane przepływające między warstwami. Uwaga transformerów zaciera to rozróżnienie, ponieważ wartości wytwarzane podczas wykonania mogą zasilać późniejsze operacje macierzowe.

Problem ilustruje pamięć podręczna klucz-wartość. Przechowuje ona reprezentacje wcześniejszych tokenów, aby model mógł ponownie wykorzystywać je podczas generowania. Jej zawartość rośnie wraz z długością rozmowy lub dokumentu, przez co wydajny dostęp do pamięci staje się coraz ważniejszy.

Stałe wymiary tensorów nie są główną przeszkodą. Skompilowane zadanie może wykonywać pętlę dla zmieniającej się długości pamięci podręcznej, a narzut zgłaszania zadań może pozostać niewielki. Trudniejszą kwestią jest wielokrotne zasilanie danych ścieżkami zaprojektowanymi wokół ponownego wykorzystania danych przez CNN.

Dlatego surowe wartości liczby operacji na sekundę oferują niepełne porównanie. Szczytowa przepustowość arytmetyczna opisuje, jak szybko tablica MAC może pracować w sprzyjających warunkach. Nie ujawnia, jak często te jednostki czekają na wagi, aktywacje lub wyniki pośrednie.

Niezależne badania doszły do zgodnego wniosku z innej perspektywy. Artykuł badawczy Orion z 2026 roku opisuje 20 ograniczeń napotkanych podczas programowania ANE przez prywatne interfejsy. Jego autorzy wskazują kompilację, układ pamięci i zachowanie numeryczne jako praktyczne bariery.

Orion mimo to raportuje znaczące wyniki dla transformerów. Na M4 Max system osiągnął ponad 170 tokenów na sekundę dla GPT-2 z 124 milionami parametrów. Wytrenował także model ze 110 milionami parametrów przez 1000 kroków w 22 minuty.

Pomiary te pokazują, że ANE może uruchamiać obciążenia modeli językowych. Nie dowodzą, że jest najlepszym celem dla każdego dużego modelu ani dla każdego etapu wnioskowania. Rozróżnienie między techniczną możliwością a dopasowaniem architektonicznym pozostaje kluczowe.

Publiczne oprogramowanie Apple utrzymuje sprzęt na dystans

Deweloperzy mogą korzystać z Neural Engine przez Core ML, ale Apple nadal kontroluje sposób kompilowania, dzielenia i wysyłania obciążeń.

Apple udostępnia Neural Engine przede wszystkim przez Core ML, swój publiczny framework do wdrażania modeli uczenia maszynowego. Deweloperzy dostarczają zgodny model, a framework decyduje, czy poszczególne operacje powinny korzystać z CPU, GPU czy Neural Engine.

Kontrole jednostek obliczeniowych Apple pozwalają aplikacji zezwolić na kombinacje tych procesorów. Deweloper może dopuścić wszystkie dostępne jednostki albo wykluczyć GPU lub Neural Engine. Publiczny interfejs nie oferuje bezpośredniego programowania deskryptorów zadań ANE.

Model ten chroni przenośność między urządzeniami Apple. Aplikacja może opisać potrzebną predykcję bez kodowania układu rejestrów jednej generacji układu. Apple może zmieniać kompilatory i zasady harmonogramowania, utrzymując stabilny interfejs aplikacji.

Kompromisem jest ograniczona widoczność. Deweloperzy nie mogą polegać na Core ML w kwestii umieszczania każdej obsługiwanej operacji w określonym silniku. Nie mogą też analizować końcowego programu niskiego poziomu z kontrolą oczekiwaną od API obliczeń GPU.

Apple wyjaśnia, że wykonywanie Core ML może korzystać z CPU, GPU i Neural Engine, jednocześnie zmniejszając zużycie pamięci i energii. To podejście jest odpowiednie dla aplikacji poszukujących wydajnego wnioskowania na urządzeniu bez strojenia specyficznego dla sprzętu.

Jest ono mniej satysfakcjonujące dla badaczy analizujących granice architektury. Test porównawczy może przejść awaryjnie na inny procesor, podzielić graf między procesory albo napotkać transformacje kompilatora zaciemniające zachowanie bazowego sprzętu.

Praca z zakresu inżynierii wstecznej usuwa część tej niepewności. Analizuje deskryptory zadań, zapisy rejestrów, kolejki, przerwania i ścieżki pamięci poniżej Core ML. Ten widok pomaga odróżnić ograniczenia narzucone przez oprogramowanie od ograniczeń wynikających z krzemu.

Prywatne interfejsy tworzą jednak własną niepewność. Nie mają publicznych gwarancji kompatybilności Apple i mogą zmienić się wraz z aktualizacją systemu operacyjnego. Kod badawczy działający dziś może przestać działać po zmianie kompilatora, formatu modelu lub usługi wykonawczej.

Ta luka stawia Apple w nietypowej pozycji. Firma dostarcza dedykowany sprzęt do uczenia maszynowego w telefonach, tabletach, Macach i zestawach nagłownych. Mimo to niezależni deweloperzy mają ograniczoną kontrolę nad jednym z najbardziej charakterystycznych bloków wewnątrz tych procesorów.

Dla aplikacji głównego nurtu ograniczenie to może być celowym wyborem produktowym. Apple optymalizuje całe urządzenie i decyduje, gdzie uruchamiana jest każda operacja. Większość deweloperów odnosi większą korzyść z przewidywalnego wdrożenia niż z bezpośredniego dostępu do rejestrów.

Deweloperzy generatywnej AI często potrzebują czegoś przeciwnego. Eksperymentują z formatami kwantyzacji, jądrami uwagi, układami pamięci podręcznej i łączonymi operacjami. Porównują także wydajność między szybko zmieniającymi się architekturami modeli.

GPU-y umożliwiają takie eksperymentowanie, ponieważ ich modele programowania udostępniają bardziej ogólne możliwości obliczeniowe. Programiści mogą implementować nowe kernele bez czekania na dedykowaną ścieżkę kompilatora. Kosztem jest większa odpowiedzialność za synchronizację, dostęp do pamięci i strojenie wydajności.

Samodzielny Neural Engine reprezentuje drugi koniec tego spektrum. Jego kompilator i stały przepływ danych mogą zapewnić wydajne wykonywanie, gdy model się w nich mieści. Gdy charakter obciążenia się zmienia, specjalizacja staje się ograniczeniem zamiast przewagą.

Strategia programowa Apple uniemożliwia programistom bezpośrednie rozwiązanie tego napięcia. Core ML może ukrywać różnice sprzętowe, ale nie sprawi, że system pamięci zorientowany na CNN zacznie działać jak elastyczny GPU. Inżynieria wsteczna odsłania granicę, którą framework zwykle ukrywa.

M5 czyni GPU głównym rywalem

Apple M5 nie usuwa samodzielnego Neural Engine, ale daje GPU bardziej bezpośrednią rolę w planie rozwoju AI firmy.

Apple zapowiedziało M5 w październiku 2025 roku jako układ z 10-rdzeniowym GPU zawierającym Neural Accelerator w każdym rdzeniu. Chip zachował także ulepszony 16-rdzeniowy Neural Engine. Taka konstrukcja umieszcza wyspecjalizowany sprzęt macierzowy po obu stronach architektonicznego sporu.

Według zapowiedzi układu M5 od Apple, nowy GPU zapewnia ponad czterokrotnie wyższą szczytową wydajność obliczeniową AI niż GPU M4. Apple zwiększyło również przepustowość zunifikowanej pamięci do 153GB/s, czyli o niemal 30 procent względem M4.

Są to pomiary kontrolowane przez Apple, a szczegóły obciążenia determinują rzeczywistą wydajność aplikacji. Mimo to lokalizacja nowych akceleratorów mówi więcej niż liczba z nagłówka. Apple umieściło je wewnątrz programowalnych rdzeni GPU, zamiast polegać wyłącznie na oddzielnym Neural Engine.

GPU łączy wyspecjalizowane wykonywanie obliczeń macierzowych ze środowiskiem już dostosowanym do zmieniających się algorytmów. Apple twierdzi, że programiści mogą programować Neural Accelerators za pośrednictwem tensorowych API w Metal 4. Zapewnia to publiczną ścieżkę do obciążeń AI opartych na GPU, bez ujawniania prywatnego formatu poleceń samodzielnego ANE.

Yoon interpretuje tę zmianę jako początek końca samodzielnego NPU, czyli jednostki przetwarzania neuronowego. To sformułowanie jest celowo prowokacyjne, a decyzje produktowe Apple nie potwierdzają jeszcze faktycznego wycofania tej jednostki.

M5 nadal zawiera oddzielny Neural Engine. Apple opisuje go jako szybszy i wiąże go z funkcjami systemowymi, w tym przetwarzaniem zdjęć oraz generowaniem przestrzennych Person. Zadania te przypominają ograniczone, przewidywalne obciążenia inferencyjne, z którymi dedykowane akceleratory radzą sobie dobrze.

Bardziej uzasadniony wniosek jest węższy. Apple traktuje obecnie GPU jako główny cel dla wymagających generatywnych obciążeń AI, podczas gdy Neural Engine zachowuje rolę w wydajnej inferencji systemowej.

Taki podział odpowiada dowodom z inżynierii wstecznej. GPU może łączyć akcelerację macierzową z elastycznymi operacjami pamięciowymi, ogólnymi kernelami i bezpośrednim dostępem dla programistów. NPU o stałej funkcji może minimalizować narzut dla stabilnych grafów o znanych wzorcach wykonywania.

Żadna z tych konstrukcji nie wygrywa w każdym obciążeniu. Procesor ogólnego przeznaczenia zużywa powierzchnię układu i energię na obsługę elastyczności, której stały potok unika. Wyspecjalizowany silnik traci zdolność adaptacji, gdy modele wymagają nowych wzorców przepływu danych.

M5 sugeruje, że Apple chce obu rozwiązań. Oddzielny Neural Engine może obsługiwać ugruntowane funkcje działające na urządzeniu, podczas gdy GPU Neural Accelerators są przeznaczone dla modeli, których operatory i zachowanie pamięci nadal się zmieniają.

Ta hybrydowa strategia wywiera również presję na stos programowy Apple. Core ML musi wybierać między coraz bardziej wydajnymi procesorami. Metal musi zapewnić programistom wystarczającą kontrolę, by mogli wykorzystać nowe jednostki GPU. Kompilator musi unikać tak częstego przenoszenia danych między procesorami, by koszty transferu nie niwelowały przyspieszenia.

Presja nie dotyczy zatem po prostu Nvidia kontra Apple ani macOS kontra Linux. To rywalizacja wewnątrz własnego krzemu Apple między wydajnością stałych funkcji a programowalną akceleracją.

Ta rywalizacja rozpoczęła się na długo przed generatywną AI. Układy Apple już dzielą pracę między CPU, GPU, silniki multimedialne, procesory obrazu i sprzęt zabezpieczający. Różnica polega teraz na tym, że projektowanie modeli AI zmienia się w tempie, które czyni długie cykle planowania sprzętu szczególnie ryzykownymi.

Zaprojektowanie i zweryfikowanie dedykowanego bloku może zająć lata. Architektury transformatorów, warianty attention i techniki kwantyzacji mogą zmieniać się w ciągu miesięcy. Umieszczenie bardziej adaptowalnej akceleracji w GPU zmniejsza koszt błędnego przewidywania.

Inżynieria wsteczna nie dowodzi, że Neural Engine jest skończony

Retrospektywa wyjaśnia niedopasowanie architektoniczne, ale nie może ustalić przyszłego planu produktowego Apple ani zmierzyć każdej nowszej implementacji ANE.

Najgłębsze ustalenia dotyczą generacji M1. Apple wypuściło od tego czasu kilka rodzin procesorów, a wewnętrzne szczegóły mogą się zmieniać bez publicznej dokumentacji. Wnioski dotyczące późniejszych chipów wymagają bezpośrednich pomiarów, a nie wizualnego podobieństwa ani nazw marketingowych.

Yoon przyznaje, że część analizy układu fizycznego pozostaje niepewna. Obrazy matrycy układu mogą ujawnić główne bloki pamięci i powtarzalne struktury obliczeniowe, ale nie wyjaśniają każdej decyzji dotyczącej trasowania. Niektóre wnioski pozostają świadomymi interpretacjami.

Badanie koncentruje się także na strukturze sprzętu, a nie na kompleksowym benchmarku aplikacyjnym. Pokazuje, dlaczego przemieszczanie pamięci powinno ograniczać niektóre obciążenia. Nie porównuje każdego modelu na ANE, GPU i CPU przy identycznych limitach energetycznych.

Orion dostarcza przydatnych nowszych pomiarów, ale korzysta z prywatnych API i oprogramowania badawczego. Jego eksperymenty z GPT-2 i TinyStories demonstrują dostęp oraz możliwości, a nie szeroką gotowość produkcyjną dla obecnych dużych modeli językowych.

Inny otwarty projekt zgłosił bezpośrednie trenowanie za pośrednictwem odtworzonych prywatnych interfejsów. Jego pomiary M4 wskazują przepustowość FP16 na poziomie około 18,6 biliona operacji na sekundę, a przepustowość INT8 na około 35,1 biliona operacji na sekundę. Dane te zależą od wybranych konfiguracji konwolucji i nie powinny być uogólniane na kompletne modele.

Dojrzałość oprogramowania ma równie duże znaczenie jak sprzęt. Wysoce zoptymalizowany kompilator może restrukturyzować grafy, scalać operacje i ograniczać transfery. Sterownik badawczy może poprawnie udostępniać silnik, jednocześnie pozostawiając niewykorzystaną znaczną część wydajności.

Obowiązuje też przeciwne ryzyko. Szczytowe mikrobenchmarki mogą utrzymywać jednostki arytmetyczne w ciągłej pracy w idealnych warunkach, jednocześnie ukrywając rzeczywiste wąskie gardła modeli. Opóźnienie end-to-end, wykorzystanie pamięci, zużycie energii i czas kompilacji decydują o tym, czy akcelerator pomaga aplikacji.

Apple może również przeprojektować samodzielny Neural Engine, zachowując jego nazwę produktową. Większa współdzielona pamięć, zmienione ścieżki danych lub nowe formaty zadań mogłyby rozwiązać ograniczenia wykryte w M1. Zapowiedź M5 nie ujawnia szczegółów na tym poziomie.

Bezpieczeństwo stanowi kolejny powód kontrolowanego dostępu. Apple wykorzystuje sprzęt Neural Engine w chronionych procesach biometrycznych. Dokumentacja bezpieczeństwa platformy opisuje resetowanie stanu i kontrolę pamięci dla bezpiecznego działania Neural Engine w nowszych systemach.

Ta rola nie wymaga otwierania tego samego sprzętu na dowolne obciążenia Linux. Oznacza też, że dalsza obecność tego bloku może wynikać z architektury systemu wykraczającej poza konsumenckie modele językowe.

Efektywność energetyczna pozostaje kolejnym brakującym porównaniem. Dekodowanie autoregresyjne może działać bardziej naturalnie na programowalnym sprzęcie GPU, lecz dedykowany silnik nadal może przewyższać go w zadaniach związanych z wizją, dźwiękiem i klasyfikacją. Apple sprzedaje urządzenia zasilane bateriami, gdzie takie oszczędności mają znaczenie.

Wiarygodne twierdzenie nie brzmi więc, że Neural Engine umarł. Chodzi o to, że jego pierwotne założenia projektowe nie obejmują już pełnego zakresu strategicznie istotnych obciążeń AI.

To rozróżnienie utrzymuje Retrospectively Reverse-Engineering Apple's Neural Engine w granicach dowodów. Projekt oświetla architektoniczne rozwidlenie, podczas gdy premiery produktów Apple zdecydują, jak daleko firma podąży każdą z tych dróg.

Trzy sygnały pokażą, która architektura wygra

Kolejne API, benchmarki i układy chipów Apple pokażą, czy Neural Engine M1 był trwałym wzorcem, czy wyspecjalizowaną odnogą.

Pierwszym sygnałem będzie dostęp programistów do Neural Accelerators w GPU M5. Metal 4 musi udostępniać użyteczne operacje tensorowe, nie ukrywając przy tym tak dużej części harmonogramowania, że badacze staną przed kolejną czarną skrzynką.

Działające narzędzia wzmocnią argument, że Apple wybrało programowalną akcelerację GPU dla szybko zmieniających się modeli. Ograniczone API lub wąskie wsparcie operatorów osłabiłyby tę interpretację i zachowały większą rolę dla sprzętu zarządzanego przez Core ML.

Drugim sygnałem będzie wydajność end-to-end w reprezentatywnych obciążeniach transformatorowych. Użyteczne porównania muszą obejmować przetwarzanie promptów, generowanie tokenów, zachowanie pamięci dla długiego kontekstu, zużycie energii i czas ładowania modelu.

Same mikrobenchmarki nie rozstrzygną kwestii. Procesor może prowadzić pod względem przepustowości macierzowej, a jednocześnie tracić czas na transferach wag, przemieszczaniu danych w cache lub kompilacji grafu. Pomiary powinny również wskazywać, która jednostka obliczeniowa wykonała każdą operację.

Wyniki z aplikacji M5 będą szczególnie ważne. Lokalne modele językowe i oprogramowanie do dyfuzji mogą testować nowe akceleratory GPU w obciążeniach, które Apple wyraźnie podkreślało. Spójne wzrosty wydajności potwierdziłyby zwrot ku akceleracji wewnątrz programowalnych rdzeni.

Trzecim sygnałem będzie architektura kolejnego samodzielnego Neural Engine Apple. Apple może zachować oznaczenie 16 rdzeni, zmieniając jednocześnie wielkość pamięci, połączenia międzykomponentowe, harmonogramowanie i obsługiwaną precyzję pod tą etykietą.

Przeprojektowany lokalny system pamięci podważyłby tezę, że samodzielny blok zbliża się do końca. Minimalne zmiany połączone z większymi inwestycjami w GPU wspierałyby interpretację Yoona.

Postępy Linux oferują dodatkową ścieżkę weryfikacji. Społeczność Asahi ma duże doświadczenie w dokumentowaniu Apple silicon poprzez obserwację clean-room i eksperymenty. Jej prace nad inżynierią wsteczną już zaowocowały otwartymi sterownikami dla innych nieudokumentowanych bloków.

Użyteczny sterownik ANE pozwoliłby badaczom porównać wybory Core ML z bezpośrednim zgłaszaniem zadań. Mógłby także ujawnić, czy alternatywne kompilatory potrafią odzyskać wydajność, do której publiczny framework Apple nie zapewnia dostępu.

Wsparcia Linux nie należy jednak mylić z głównym wynikiem komercyjnym. Sterownik ma znaczenie, ponieważ przekształca ukryte zachowanie sprzętu w testowalne dowody. To własne urządzenia, frameworki i obciążenia Apple zdecydują o przyszłości architektury.

Programiści powinni obserwować, gdzie Apple umieszcza nową publiczną programowalność. Powinni także oddzielać teoretyczną przepustowość od pełnej wydajności aplikacji. Procesor z największą liczbą w nagłówku niekoniecznie jest tym, który najwydajniej przenosi dane modelu.

Zespoły prowadzące podobne badania techniczne potrzebują trwałego rejestru eksperymentów, ustaleń dotyczących rejestrów, benchmarków i odrzuconych hipotez. Przeszukiwalna baza wiedzy inżynierskiej może utrzymać te dowody w spójnej formie, gdy zmieniają się narzędzia i generacje chipów.

Retrospectively Reverse-Engineering Apple's Neural Engine ostatecznie uchwyca rzadki moment, w którym starszy krzem wyjaśnia nową strategię. M1 pokazuje korzyści i koszty wpisania założeń CNN w sprzęt. M5 pokazuje, że Apple dodaje elastyczność, nie porzucając od razu specjalizacji.

Kolejne pytanie jest konkretne: czy przyszłe układy Apple rozbudują programowalną akcelerację GPU, pozostawiając Neural Engine stabilnym zadaniom systemowym, czy też Apple przebuduje samodzielny blok dla transformatorów? Obserwuj API i zachowanie pamięci, nie tylko wskaźnik TOPS.