Apple, 하드웨어 논쟁을 다시 불러오다: Apple Neural Engine의 사후 리버스 엔지니어링
Apple의 M1 Neural Engine은 이를 이해하기 위해 만들어진 Linux 드라이버 프로젝트가 3년간 멈춰 있었음에도 다시 주목받고 있다. Apple Neural Engine의 사후 리버스 엔지니어링은 이 가속기가 초기 신경망에서는 뛰어난 성능을 보였지만, 오늘날의 트랜스포머 워크로드에서는 어려움을 겪는 이유를 기록한다.
전 Asahi Linux 기여자인 Eileen Yoon은 Apple이 하드웨어 방향을 바꾼 뒤 중단됐던 작업으로 돌아왔다. M5는 별도의 16코어 Neural Engine을 유지하면서 모든 GPU 코어 안에 Neural Accelerator를 배치한다. 이 조합은 하나의 고정 기능 가속기가 Apple의 확장되는 생성형 AI 워크로드를 감당해야 한다는 생각에 의문을 제기한다.
이는 단순히 늦어진 하드웨어 분해 분석이 아니다. 이 조사는 2017년 무렵의 합성곱 신경망, 즉 CNN을 위해 내린 선택을 현대 언어 모델에 대한 Apple의 대응과 연결한다. 트랜스포머는 유연한 스케줄링과 지속적인 메모리 이동에 의존하기 때문에, GPU는 이제 독립형 Neural Engine에 압박을 가하고 있다.
잠들어 있던 M1 드라이버가 하드웨어 부검으로 바뀌다
새 작업은 미완성 Linux 드라이버를 Apple이 본래 머신러닝의 미래를 어떻게 예상했는지에 대한 기록으로 바꾼다.
Yoon은 이전에 M1 칩 내부 Neural Engine과 통신할 수 있는 Linux ANE driver를 만들었다. 이 프로젝트에는 커널 모듈, 사용자 공간 라이브러리, 테스트, Python 바인딩이 포함됐다. 하드웨어를 폭넓게 프로그래밍 가능하게 하지는 않았지만, Apple의 공개 소프트웨어 추상화를 우회할 수 있는 경로를 제공했다.
이후 프로젝트는 3년간 조용했다. Yoon은 ANE가 추가 드라이버 작업을 정당화하기에는 지나치게 특수화돼 보였다고 썼다. 하드웨어 인터페이스를 열더라도 고정된 데이터 경로가 효율적으로 실행할 수 있는 연산의 종류는 바뀌지 않는다.
이 차이는 중요하다. 일반적인 드라이버는 하드웨어가 이미 가진 기능을 노출할 수 있다. 그러나 특정 목적의 데이터플로 가속기를 범용 프로세서로 바꿀 수는 없다.
따라서 Yoon의 아키텍처 회고는 원래의 드라이버 작업과는 다른 질문을 던진다. Linux가 작업을 어떻게 제출할 수 있는지가 아니라, 컴퓨팅 어레이, 스케줄러, 메모리 시스템, 실행 모델을 살핀다. 이 구성 요소들은 M1 설계에 내재된 워크로드 가정을 드러낸다.
조사는 중앙의 로컬 메모리 블록을 중심으로 배치된 16개의 컴퓨팅 코어를 설명한다. 각 코어에는 병렬 곱셈-누산 유닛, 즉 MAC이 있으며, 입력을 곱한 뒤 결과를 누산기에 더한다. 이러한 연산은 합성곱, 행렬 곱셈, 그리고 어텐션 메커니즘에 쓰이는 내적의 기반이다.
그러나 MAC 유닛만으로 Neural Engine의 특수화를 설명할 수는 없다. CNN과 트랜스포머 모두 곱셈과 누산이 필요하다. 결정적인 차이는 가중치와 활성화 값이 이 유닛에 도달하고, 계속 사용 가능하게 유지되며, 칩 내부를 이동하는 방식에 있다.
Apple은 2017년 A11 Bionic과 함께 첫 Neural Engine을 도입했다. 당시 소비자용 신경망은 이미지 분류, 얼굴 분석 및 기타 고밀도 CNN 워크로드에 집중돼 있었다. 이 네트워크들은 규칙적인 텐서 형태와 예측 가능한 재사용 특성을 제공했다.
Apple이 자체 프로세서를 Mac에 도입하면서 M1은 이러한 설계 계보를 물려받았다. 그 Neural Engine은 차원과 이동 패턴이 사전에 상당 부분 알려진 컴파일 모델에 최적화됐다. 이 특수화는 지원되는 작업의 지연 시간과 에너지 소비를 줄였다.
이 회고는 M1 Neural Engine이 트랜스포머 연산을 실행할 수 없다고 주장하지 않는다. 대신 주변 데이터플로가 일부 트랜스포머 패턴, 특히 자기회귀 디코딩을 비효율적으로 만든다고 주장한다. 이 과정은 한 번에 하나의 토큰을 생성하면서 모델 가중치와 증가하는 어텐션 캐시를 반복적으로 읽는다.
이러한 재구성은 글의 핵심 긴장을 만든다. Apple은 예상된 워크로드에 맞춰 데이터 이동을 제한함으로써 효율적인 엔진을 만들었다. 현대 AI는 고정된 하드웨어 아키텍처가 변화할 수 있는 속도보다 더 빠르게 지배적인 워크로드를 바꿨다.
Apple Neural Engine의 사후 리버스 엔지니어링이 드러낸 진짜 제약
M1 Neural Engine의 결정적 한계는 연산 능력이 아니라 데이터가 그 연산 장치를 따라 이동해야 하는 경로다.
리버스 엔지니어링된 드라이버는 CONV, MATMUL, RELU 같은 고수준 명령을 하드웨어에 직접 보내지 않는다. Apple의 컴파일러는 실행이 시작되기 전에 이미 이러한 신경망 연산을 작업 디스크립터로 변환한다.
작업 디스크립터는 구조화된 구성 데이터 블록이다. 이는 텐서 차원, 메모리 주소, 활성화 함수, 종속성 및 데이터 전송을 제어하는 레지스터 그룹을 프로그래밍한다. 드라이버는 디스크립터를 메모리에 배치하고, task manager가 이를 가리키도록 한 뒤 하드웨어 "doorbell"을 울린다.
이 제출 이후 작업이 완료될 때까지 Neural Engine이 작업을 제어한다. 작업이 끝나면 인터럽트를 발생시킨다. 호스트 프로세서는 연산이 실행되는 동안 각각의 수학 명령을 직접 지시하지 않는다.
Yoon은 ANE에 익숙한 CPU나 GPU의 의미에서 명령어 집합이 없다고 결론 내린다. 작업 디스크립터는 임의의 프로그램을 제공하는 것이 아니라 도메인 특화 데이터 경로를 구성한다. 각 디스크립터는 해당 데이터 경로를 한 번 통과하는 과정을 나타낸다.
작업은 구성 레지스터를 로드하면서 시작된다. 전용 전송 블록은 이후 메인 메모리의 가중치와 입력 활성화 값을 별도의 로컬 저장소로 옮긴다. 컴퓨팅 코어가 리덕션을 수행하고, 후처리는 활성화를 적용하며, 또 다른 전송 블록이 결과를 반환한다.
이 순서는 예측 가능한 재사용이 있는 연산에 유리하다. 합성곱은 같은 소형 학습 필터 세트를 수많은 이미지 영역에 적용할 수 있다. 가속기는 대규모의 새로운 가중치 세트를 반복적으로 가져오지 않고도 연산 레인을 계속 가동할 수 있다.
트랜스포머 디코딩은 이 균형을 바꾼다. 새 토큰마다 모델 파라미터의 상당 부분을 스트리밍해야 할 수 있다. 연산 자체는 익숙하지만, 데이터 이동이 제한 비용이 된다.
M1 레이아웃은 가중치에 쓰이는 메모리와 활성화 타일에 쓰이는 로컬 메모리를 분리하기 때문에 이 문제를 더욱 키운다. Yoon은 이 설계에서 약 1 MiB의 커널 메모리와 2 MiB의 타일 메모리를 확인했다. 이 조사는 아키텍처가 로컬에서 생성된 텐서를 효율적으로 가중치로 재해석하도록 구성되지 않았다고 주장한다.
이는 Apple이 2017년에 겨냥한 모델에는 합리적인 가정이었다. CNN 추론은 일반적으로 학습된 가중치를 고정된 커널로, 활성화 값을 레이어 간에 흐르는 데이터로 취급한다. 트랜스포머 어텐션은 실행 중 생성된 값이 이후 행렬 연산에 투입될 수 있기 때문에 이러한 구분을 흐린다.
키-값 캐시는 이 문제를 잘 보여준다. 캐시는 모델이 생성 과정에서 재사용할 수 있도록 이전 토큰의 표현을 저장한다. 대화나 문서가 길어질수록 그 내용이 커지므로 효율적인 메모리 접근이 점점 더 중요해진다.
고정된 텐서 차원이 핵심 장애물은 아니다. 컴파일된 작업은 변화하는 캐시 길이에 맞춰 루프를 돌 수 있고, 작업 제출 오버헤드도 작게 유지될 수 있다. 더 어려운 문제는 CNN 재사용을 중심으로 설계된 경로를 통해 데이터를 반복적으로 공급하는 일이다.
이 때문에 초당 연산 수 수치만으로는 불완전한 비교가 된다. 최고 연산 처리량은 유리한 조건에서 MAC 어레이가 얼마나 빠르게 작동할 수 있는지를 설명한다. 하지만 가중치, 활성화 값 또는 중간 결과를 기다리며 해당 유닛이 얼마나 자주 멈추는지는 보여주지 않는다.
독립 연구도 다른 방향에서 이와 양립하는 결론에 도달했다. 2026년 Orion research paper는 비공개 인터페이스를 통해 ANE를 프로그래밍하면서 마주한 20가지 제약을 설명한다. 저자들은 컴파일, 메모리 레이아웃, 수치적 동작을 실질적인 장벽으로 꼽는다.
그럼에도 Orion은 의미 있는 트랜스포머 결과를 보고한다. M4 Max에서 이 시스템은 파라미터 1억 2,400만 개의 GPT-2에 대해 초당 170개 이상의 토큰을 생성했다. 또한 파라미터 1억 1,000만 개 모델을 22분 동안 1,000스텝 학습했다.
이 측정치는 ANE가 언어 모델 워크로드를 실행할 수 있음을 보여준다. 하지만 이것이 모든 대형 모델이나 모든 추론 단계에 가장 적합한 대상이라는 점을 입증하지는 않는다. 기술적 가능성과 아키텍처 적합성의 구분은 여전히 핵심이다.
Apple의 공개 소프트웨어는 하드웨어를 일정 거리에서 유지한다
개발자는 Core ML을 통해 Neural Engine을 요청할 수 있지만, Apple은 여전히 워크로드가 컴파일되고 분할되며 디스패치되는 방식을 통제한다.
Apple은 머신러닝 모델 배포를 위한 공개 프레임워크인 Core ML을 통해 Neural Engine을 주로 제공한다. 개발자는 호환되는 모델을 제공하고, 프레임워크는 개별 연산이 CPU, GPU 또는 Neural Engine을 사용할지 결정한다.
Apple의 compute-unit controls를 사용하면 애플리케이션이 이 프로세서들의 조합을 허용할 수 있다. 개발자는 사용 가능한 모든 유닛을 허용하거나 GPU 또는 Neural Engine을 제외할 수 있다. 공개 인터페이스는 ANE의 작업 디스크립터를 직접 프로그래밍하는 기능을 제공하지 않는다.
이 모델은 Apple 기기 전반의 이식성을 보호한다. 애플리케이션은 특정 칩 세대의 레지스터 레이아웃을 인코딩하지 않고도 필요한 예측을 설명할 수 있다. Apple은 애플리케이션 인터페이스를 안정적으로 유지하면서 컴파일러와 스케줄링 정책을 수정할 수 있다.
그 대가는 가시성이다. 개발자는 Core ML이 지원되는 모든 연산을 특정 엔진에 배치할 것이라고 기대할 수 없다. 또한 GPU 컴퓨팅 API에서 기대하는 수준의 제어로 최종 저수준 프로그램을 검사할 수도 없다.
Apple은 Core ML execution이 메모리 소비와 전력 사용을 줄이면서 CPU, GPU, Neural Engine을 활용할 수 있다고 설명한다. 이 접근 방식은 하드웨어별 튜닝 없이 효율적인 온디바이스 추론을 원하는 애플리케이션에 적합하다.
아키텍처의 한계를 조사하는 연구자에게는 덜 만족스럽다. 벤치마크는 다른 프로세서로 폴백하거나, 그래프를 여러 프로세서에 나누거나, 기반 하드웨어 동작을 가리는 컴파일러 변환을 마주할 수 있다.
리버스 엔지니어링 작업은 이러한 불확실성의 일부를 제거한다. Core ML 아래에서 작업 디스크립터, 레지스터 쓰기, 큐, 인터럽트, 메모리 경로를 조사한다. 이 관점은 소프트웨어가 부과한 제한과 실리콘이 만든 제약을 구분하는 데 도움이 된다.
그러나 비공개 인터페이스 자체도 불확실성을 만든다. 이는 Apple의 공개 호환성 보장을 받지 못하며, 운영체제 업데이트로 변경될 수 있다. 오늘 작동하는 연구 코드는 컴파일러, 모델 형식 또는 런타임 서비스가 바뀐 뒤에는 실패할 수 있다.
이 간극은 Apple을 독특한 위치에 놓는다. 이 회사는 휴대폰, 태블릿, Mac, 헤드셋 전반에 전용 머신러닝 하드웨어를 탑재한다. 하지만 독립 개발자가 이러한 프로세서 내부의 가장 독특한 블록 중 하나를 제어할 수 있는 범위는 제한적이다.
주류 애플리케이션에는 이 제한이 의도적인 제품 선택일 수 있다. Apple은 전체 기기를 최적화하고 각 연산이 어디에서 실행될지 결정한다. 대부분의 개발자는 직접 레지스터에 접근하는 것보다 예측 가능한 배포에서 더 큰 이점을 얻는다.
생성형 AI 개발자에게는 흔히 반대가 필요하다. 이들은 양자화 형식, 어텐션 커널, 캐시 레이아웃, 융합 연산을 실험한다. 또한 빠르게 변화하는 모델 아키텍처 전반에서 성능을 비교한다.
GPU는 더 범용적인 연산 기능을 노출하는 프로그래밍 모델을 제공하기 때문에 이러한 실험을 수용할 수 있다. 개발자는 전용 컴파일러 경로를 기다리지 않고도 새 커널을 구현할 수 있다. 그 대가로 동기화, 메모리 접근, 성능 튜닝에 더 큰 책임을 져야 한다.
독립형 Neural Engine은 이 스펙트럼의 반대편에 있다. 컴파일러와 고정 데이터 경로는 모델이 잘 맞을 때 효율적인 실행을 제공할 수 있다. 워크로드가 바뀌면 특화 설계는 장점이 아니라 제약이 된다.
Apple의 소프트웨어 전략은 개발자가 이 긴장을 직접 해소하지 못하게 한다. Core ML은 하드웨어 차이를 감출 수 있지만 CNN 중심 메모리 시스템을 유연한 GPU처럼 동작하게 만들 수는 없다. 리버스 엔지니어링은 프레임워크가 보통 감추는 경계를 드러낸다.
M5, GPU를 주된 경쟁자로 만들다
Apple의 M5는 독립형 Neural Engine을 없애지는 않지만, 회사의 AI 로드맵에서 GPU에 더 직접적인 역할을 부여한다.
Apple은 2025년 10월, 각 코어에 Neural Accelerator를 탑재한 10코어 GPU를 포함하는 M5를 발표했다. 이 칩은 개선된 16코어 Neural Engine도 유지했다. 이 설계는 특화된 행렬 하드웨어를 아키텍처 경쟁의 양쪽에 배치한다.
Apple의 M5 칩 발표에 따르면, 새 GPU는 M4 GPU보다 4배 이상 높은 최대 AI 연산 성능을 제공한다. Apple은 통합 메모리 대역폭도 153GB/s로 높였으며, 이는 M4보다 약 30% 높은 수준이다.
이는 Apple이 통제한 측정치이며, 실제 애플리케이션 성능은 워크로드 세부 사항에 따라 달라진다. 그럼에도 새 가속기의 위치는 헤드라인 수치보다 더 많은 것을 보여준다. Apple은 별도 Neural Engine에만 의존하는 대신, 이를 프로그래밍 가능한 GPU 코어 내부에 배치했다.
GPU는 특화된 행렬 실행 기능과 변화하는 알고리즘에 이미 적합한 환경을 결합한다. Apple은 개발자가 Metal 4의 텐서 API를 통해 Neural Accelerators를 프로그래밍할 수 있다고 설명한다. 이는 독립형 ANE의 비공개 명령 형식을 노출하지 않으면서 GPU 기반 AI 워크로드로 나아갈 수 있는 공개 경로를 제공한다.
Yoon은 이 변화를 독립형 NPU, 즉 신경망 처리 장치의 종말이 시작되는 신호로 해석한다. 이 표현은 의도적으로 도발적이며, Apple의 제품 결정이 실제 퇴출을 아직 확인해 주는 것은 아니다.
M5에는 여전히 별도 Neural Engine이 포함된다. Apple은 이를 더 빨라졌다고 설명하며, 사진 처리와 공간 Persona 생성 등을 포함한 시스템 기능과 연결한다. 이러한 작업은 전용 가속기가 잘 처리하는 제한적이고 예측 가능한 추론 워크로드와 닮아 있다.
더 타당한 결론은 범위를 좁혀야 한다. Apple은 이제 까다로운 생성형 AI 워크로드의 주요 실행 대상으로 GPU를 취급하는 한편, Neural Engine은 효율적인 시스템 추론에서 역할을 유지한다.
이 구분은 리버스 엔지니어링 증거와도 맞아떨어진다. GPU는 행렬 가속에 유연한 메모리 연산, 범용 커널, 개발자의 직접 접근을 결합할 수 있다. 고정 기능 NPU는 실행 패턴이 알려진 안정적인 그래프에서 오버헤드를 최소화할 수 있다.
어느 설계도 모든 워크로드에서 승리하지는 않는다. 범용 프로세서는 고정 파이프라인이 피하는 유연성 지원에 면적과 에너지를 사용한다. 특화 엔진은 모델이 새로운 데이터 이동 패턴을 요구할 때 적응력을 잃는다.
M5는 Apple이 둘 다 원한다는 점을 시사한다. 별도 Neural Engine은 확립된 온디바이스 기능을 지원할 수 있고, GPU Neural Accelerators는 연산자와 메모리 동작이 계속 변화하는 모델을 겨냥한다.
이 하이브리드 전략은 Apple의 소프트웨어 스택에도 압박을 가한다. Core ML은 갈수록 강력해지는 프로세서들 중에서 선택해야 한다. Metal은 개발자가 새 GPU 유닛을 활용할 수 있도록 충분한 제어권을 제공해야 한다. 컴파일러는 프로세서 간 데이터를 지나치게 자주 이동시켜 전송 비용이 가속 효과를 상쇄하지 않도록 해야 한다.
따라서 이 압박은 단순히 Nvidia 대 Apple, 또는 macOS 대 Linux의 문제가 아니다. 이는 고정 기능 효율성과 프로그래밍 가능한 가속 사이에서 벌어지는 Apple 자체 실리콘 내부의 경쟁이다.
이 경쟁은 생성형 AI보다 훨씬 이전에 시작됐다. Apple의 칩은 이미 CPU, GPU, 미디어 엔진, 이미지 프로세서, 보안 하드웨어에 작업을 분산한다. 지금의 차이는 AI 모델 설계가 긴 하드웨어 계획 주기를 특히 위험하게 만들 정도로 빠르게 변한다는 점이다.
전용 블록은 설계와 검증에 수년이 걸릴 수 있다. Transformer 아키텍처, 어텐션 변형, 양자화 기법은 수개월 안에 바뀔 수 있다. GPU에 더 적응력 있는 가속 기능을 내장하면 잘못된 예측의 비용을 줄일 수 있다.
리버스 엔지니어링이 Neural Engine의 종말을 증명하지는 않는다
이 회고적 분석은 아키텍처 불일치를 설명하지만, Apple의 미래 제품 계획을 확정하거나 모든 최신 ANE 구현을 측정할 수는 없다.
가장 심층적인 발견은 M1 세대에 관한 것이다. Apple은 이후 여러 프로세서 제품군을 출시했으며, 내부 세부 사항은 공개 문서 없이도 달라질 수 있다. 이후 칩에 대한 결론에는 외형적 유사성이나 마케팅 명칭이 아니라 직접적인 측정이 필요하다.
Yoon은 물리적 레이아웃 분석 일부에 불확실성이 있음을 인정한다. 다이 이미지는 주요 메모리 블록과 반복되는 연산 구조를 드러낼 수 있지만, 모든 라우팅 결정을 설명하지는 않는다. 일부 결론은 근거를 갖춘 해석에 머문다.
이 조사는 포괄적인 애플리케이션 벤치마크보다 하드웨어 구조에 초점을 맞춘다. 메모리 이동이 특정 워크로드를 제한해야 하는 이유를 보여주지만, 동일한 전력 제한에서 ANE, GPU, CPU 전반의 모든 모델을 비교하지는 않는다.
Orion은 유용한 최신 측정치를 제공하지만, 비공개 API와 연구용 소프트웨어를 사용한다. GPT-2와 TinyStories 실험은 현재 대규모 언어 모델을 위한 광범위한 프로덕션 준비 상태가 아니라 접근성과 성능 가능성을 보여준다.
또 다른 오픈 프로젝트는 리버스 엔지니어링된 비공개 인터페이스를 통한 직접 학습을 보고했다. 해당 프로젝트의 M4 측정치는 FP16 처리량을 초당 약 18.6조 연산, INT8 처리량을 초당 약 35.1조 연산으로 제시한다. 이 수치는 선택된 컨볼루션 구성에 따라 달라지며, 전체 모델에 일반화해서는 안 된다.
소프트웨어 성숙도는 하드웨어만큼 중요하다. 고도로 최적화된 컴파일러는 그래프를 재구성하고, 연산을 융합하며, 전송을 줄일 수 있다. 연구용 드라이버는 엔진을 올바르게 노출하면서도 상당한 성능을 활용하지 못할 수 있다.
반대의 위험도 있다. 최대 마이크로벤치마크는 이상적인 조건에서 연산 유닛을 계속 바쁘게 유지하면서 실제 모델 병목을 감출 수 있다. 종단 간 지연 시간, 메모리 사용량, 에너지 소비, 컴파일 시간은 가속기가 애플리케이션에 도움이 되는지를 결정한다.
Apple은 제품명을 유지하면서도 독립형 Neural Engine을 재설계할 수 있다. 더 큰 공유 메모리, 수정된 데이터 경로, 새로운 작업 형식은 M1에서 발견된 한계를 해결할 수 있다. M5 발표는 그 수준의 세부 사항을 공개하지 않는다.
보안 역시 통제된 접근이 필요한 또 다른 이유다. Apple은 보호된 생체인증 워크플로에서 Neural Engine 하드웨어를 사용한다. Apple의 플랫폼 보안 문서는 최신 시스템에서 안전한 Neural Engine 작동을 위한 상태 재설정과 메모리 제어를 설명한다.
이 역할은 동일한 하드웨어를 임의의 Linux 워크로드에 개방할 필요가 없음을 뜻한다. 또한 블록이 계속 존재하는 이유가 소비자용 언어 모델을 넘어선 시스템 아키텍처에 있을 수 있음을 의미한다.
전력 효율성은 여전히 비교에서 빠진 또 다른 요소다. 자기회귀 디코딩은 프로그래밍 가능한 GPU 하드웨어에서 더 자연스럽게 실행될 수 있지만, 전용 엔진은 비전, 오디오, 분류 작업에서는 여전히 이를 능가할 수 있다. Apple은 이러한 절감 효과가 중요한 배터리 구동 기기를 판매한다.
따라서 신뢰할 수 있는 주장은 Neural Engine이 사라졌다는 것이 아니다. 원래의 설계 가정이 전략적으로 중요한 AI 워크로드의 전체 범위를 더는 포괄하지 못한다는 것이다.
이 구분은 Retrospectively Reverse-Engineering Apple's Neural Engine을 증거에 기반하도록 한다. 이 프로젝트는 아키텍처의 갈림길을 조명하며, Apple의 제품 출시는 회사가 어느 경로를 얼마나 멀리 따를지를 결정할 것이다.
어떤 아키텍처가 승리할지 보여줄 세 가지 신호
Apple의 다음 API, 벤치마크, 칩 레이아웃은 M1 Neural Engine이 지속 가능한 템플릿이었는지, 아니면 특화된 분기였는지를 드러낼 것이다.
첫 번째 신호는 M5 GPU의 Neural Accelerators에 대한 개발자 접근성이다. Metal 4는 연구자들이 또 다른 블랙박스를 마주할 정도로 스케줄링을 과도하게 감추지 않으면서 유용한 텐서 연산을 노출해야 한다.
실용적인 도구는 Apple이 빠르게 변화하는 모델을 위해 프로그래밍 가능한 GPU 가속을 선택했다는 해석을 강화할 것이다. 제한적인 API나 좁은 연산자 지원은 이 해석을 약화시키고 Core ML이 관리하는 하드웨어의 더 큰 역할을 유지할 것이다.
두 번째 신호는 대표적인 Transformer 워크로드 전반의 종단 간 성능이다. 유용한 비교에는 프롬프트 처리, 토큰 생성, 긴 컨텍스트에서의 메모리 동작, 에너지 사용량, 모델 로딩 시간이 포함돼야 한다.
마이크로벤치마크만으로는 이 문제를 결론지을 수 없다. 프로세서는 행렬 처리량에서 앞서면서도 가중치 전송, 캐시 이동, 그래프 컴파일에 시간을 잃을 수 있다. 측정은 각 연산을 어떤 연산 유닛이 실행했는지도 식별해야 한다.
M5 애플리케이션의 결과는 특히 중요할 것이다. 로컬 언어 모델과 확산 소프트웨어는 Apple이 명시적으로 강조한 워크로드에서 새 GPU 가속기를 시험할 수 있다. 일관된 성능 향상은 프로그래밍 가능한 코어 내부 가속으로의 전환을 뒷받침할 것이다.
세 번째 신호는 Apple의 차세대 독립형 Neural Engine 아키텍처다. Apple은 16코어라는 표기를 유지하면서도 그 아래의 메모리 크기, 인터커넥트, 스케줄링, 지원 정밀도를 바꿀 수 있다.
재설계된 로컬 메모리 시스템은 독립형 블록이 종말에 가까워지고 있다는 주장에 이의를 제기할 것이다. 최소한의 변화와 더 큰 GPU 투자가 결합되면 Yoon의 해석을 뒷받침할 것이다.
Linux의 진전은 부차적인 검증 경로를 제공한다. Asahi 커뮤니티는 클린룸 관찰과 실험을 통해 Apple silicon을 문서화한 풍부한 경험을 보유하고 있다. 이들의 리버스 엔지니어링 작업은 이미 다른 문서화되지 않은 블록용 오픈 드라이버를 만들어 냈다.
사용 가능한 ANE 드라이버가 등장하면 연구자들은 Core ML의 선택을 직접 작업 제출과 비교할 수 있다. 또한 Apple의 공개 프레임워크가 접근하지 못하게 하는 성능을 대체 컴파일러가 회복할 수 있는지도 드러낼 수 있다.
그러나 Linux 지원을 주요 상업적 결과로 오해해서는 안 된다. 드라이버가 중요한 이유는 숨겨진 하드웨어 동작을 검증 가능한 증거로 바꾸기 때문이다. Apple 자체 기기, 프레임워크, 워크로드가 이 아키텍처의 미래를 결정할 것이다.
개발자는 Apple이 새로운 공개 프로그래밍 가능성을 어디에 배치하는지 지켜봐야 한다. 또한 이론적 처리량과 완전한 애플리케이션 성능을 구분해야 한다. 가장 큰 헤드라인 수치를 가진 프로세서가 반드시 모델 데이터를 가장 효율적으로 이동시키는 것은 아니다.
유사한 기술 조사를 수행하는 팀에는 실험, 레지스터 발견 사항, 벤치마크, 기각된 가설을 지속적으로 기록할 수 있는 체계가 필요하다. 검색 가능한 엔지니어링 지식 기반은 도구와 칩 세대가 바뀌어도 그러한 증거를 연결해 둘 수 있다.
Retrospectively Reverse-Engineering Apple's Neural Engine은 궁극적으로 오래된 실리콘이 새로운 전략을 설명하는 드문 순간을 포착한다. M1은 CNN 가정을 하드웨어에 고정했을 때의 이점과 비용을 보여준다. M5는 특화 설계를 즉시 포기하지 않으면서 유연성을 더하는 Apple의 선택을 보여준다.
다음 질문은 구체적이다. 미래의 Apple 칩은 프로그래밍 가능한 GPU 가속을 확장하면서 Neural Engine을 안정적인 시스템 작업에 남겨 둘 것인가, 아니면 Apple이 Transformer를 위해 독립형 블록을 재구축할 것인가? TOPS 수치만이 아니라 API와 메모리 동작을 지켜봐야 한다.
