M4 Apple Neural Engine 내부 탐구, Part 1: 리버스 엔지니어링

• Apple Neural Engine(ANE) 의 내부 구조를 직접 분석해 CoreML을 우회하고 하드웨어에 직접 접근하는 방법을 구현
• CoreML의 추상화 계층을 제거하고 _ANEClient API를 통해 모델 컴파일·로드·실행을 직접 수행
• MIL(Machine Learning Intermediate Language) 과 E5 바이너리 포맷을 분석해 ANE가 고정 연산 프리미티브 기반의 그래프 실행 엔진임을 확인
• IOSurface 공유 메모리를 이용해 GPU↔ANE 간 제로카피 데이터 전송 가능성을 입증
• 이 연구는 M4 ANE의 실제 성능 측정과 학습 가능성을 탐구하는 3부작 중 첫 번째로, Apple 비공개 하드웨어에 대한 최초의 직접 제어 사례로 의미 있음

---

인간–AI 협업을 통한 리버스 엔지니어링 접근

• 연구는 인간 연구자와 Anthropic의 Claude Opus 4.6이 협력해 진행
  • 인간이 탐색 방향을 제시하고, AI가 데이터 분석과 코드 작성 수행
• 목표는 “Apple Neural Engine 위에서 직접 모델을 학습시킬 수 있는가”라는 질문에서 출발
• Apple은 ANE의 ISA, 내부 구조, 직접 프로그래밍 인터페이스를 공개하지 않음
  • CoreML을 통해서만 접근 가능하며, 이는 하드웨어 동작을 이해하기 어렵게 만듦
• 이에 따라 CoreML에서 IOKit 커널 드라이버까지 전체 소프트웨어 스택을 역추적하고, ANE를 직접 제어하는 코드 경로를 확보

Neural Engine의 구조

• ANE는 GPU나 CPU가 아닌 그래프 실행 엔진(graph execution engine) 형태
  • 컴파일된 신경망 그래프 전체를 하나의 원자적 연산으로 실행
• M4 칩의 ANE(코드명 H16G)는 16코어, 127개 요청 큐 깊이, 독립 DVFS 제어, 유휴 시 0mW 전력 차단 기능 보유
• Apple은 A11(2017)에서 2코어 ANE를 처음 도입한 이후 세대별로 확장

기존 연구와 차별점

• 기존 공개 자료:
  • Matthijs Hollemans의 ANE 동작 문서 및 성능 분석
  • mdaiter/ane의 초기 리버스 엔지니어링 샘플
  • Asahi Linux의 리버스 엔지니어드 Linux 드라이버
  • apple/ml-ane-transformers의 공식 트랜스포머 최적화 코드
• 이번 연구의 독자적 성과:
  • CoreML 없이 직접 _ANEClient API 접근 성공
  • MIL 인메모리 컴파일 경로 해독
  • CoreML 오버헤드 제거 후 실제 처리량 측정
  • 추론 전용 하드웨어에서 모델 학습 수행

분석 방법론

• 클래스 탐색: dyld_info -objc 명령으로 AppleNeuralEngine.framework 내부 클래스 목록 추출
• 메서드 스위즐링: CoreML 호출을 가로채 비공개 프레임워크 호출 경로 확인
• 바이너리 분석: 컴파일된 E5 번들을 해독해 프로그램 포맷 파악
• 스케일링 분석: 행렬 크기·그래프 깊이·채널 수를 변화시켜 하드웨어 토폴로지 추론
• 결과적으로 _ANEClient, _ANEModel, _ANERequest, _ANEIOSurfaceObject, _ANEInMemoryModel 등 40개 이상의 비공개 클래스 발견

CoreML 우회: _ANEClient 직접 접근

• _ANEClient를 통해 모델 컴파일 → 로드 → 평가의 전체 파이프라인을 직접 제어 가능
• CoreML은 단순히 이 과정을 감싸는 편의 계층에 불과함
• ANE는 최대 127개의 동시 평가 요청(queue depth) 을 지원, 고처리량 스트리밍 추론에 최적화
• IOSurface 기반 I/O 버퍼를 사용해 GPU와 ANE 간 공유 메모리 전송 가능

MIL: ANE 입력 언어

• CoreML은 ONNX나 protobuf 대신 MIL(Machine Learning Intermediate Language) 을 사용
  • 정적 단일 할당(SSA) 기반, 타입·형상 명시
  • 예시 코드에서 matmul 연산이 명확히 표현됨
• 텐서 레이아웃은 NCDHW + Interleave 형식으로 [Batch, Channels, Depth, Height, Width] 구조

E5 바이너리 포맷

• MIL 프로그램은 E5 FlatBuffer 바이너리로 컴파일
  • 1024×1024 행렬 곱: 2,688바이트, 128×128 행렬 곱: 2,680바이트
  • 코드 크기가 거의 동일 → 행렬 연산 알고리듬이 아닌 파라미터화된 구성 정보만 포함
• 이는 ANE가 고정된 연산 프리미티브(Conv, MatMul, Elementwise 등) 를 조합해 그래프를 실행함을 의미

인메모리 컴파일 경로

• _ANEInMemoryModelDescriptor를 이용해 디스크 접근 없이 메모리 내에서 MIL 컴파일 가능
• 주요 문제점 및 해결:
  • milText는 NSString이 아닌 NSData(UTF-8 바이트) 필요
  • weights는 이름–데이터 매핑 딕셔너리 형태
  • 내부적으로 임시 디렉터리 접근 필요 → 쓰기 권한 확보 필수
• Apple 내부 코드에서 Desctiptor 오타 발견

하드웨어 프로파일

• IOKit 분석 결과, ANE는 독립적인 전력·클록 관리(DVFS) 채널 보유
  • ANE_ADCLK_TRIG, ANE_PPT_TRIG 등 다양한 하드웨어/소프트웨어 트리거 존재
• ANECompiler.framework에서 확인된 지원 연산 중 Conv가 핵심 연산 프리미티브
  • Part 2에서 1×1 Conv를 MatMul로 변환 시 3배 성능 향상 확인 예정

IOSurface 프로토콜

• 모든 데이터 입출력은 IOSurface 공유 메모리 객체를 통해 수행
  • GPU 텍스처 공유 메커니즘과 동일
  • GPU↔ANE 제로카피 파이프라인 구성 가능성 존재

컴파일 캐시 구조

• ANE 컴파일러는 E5 바이너리를 디스크에 캐시
  • 경로: ~/Library/Caches/.../com.apple.e5rt.e5bundlecache/.../H16G.bundle/
  • 첫 컴파일 20–40ms, 캐시 히트 시 즉시 실행
  • 추론에는 유리하지만, 학습 시 가중치 변경으로 재컴파일 필요

미탐색 영역

• 아직 분석되지 않은 클래스:
  • _ANEChainingRequest — 여러 모델을 단일 디스패치로 연결 가능성
  • _ANESharedEvents, _ANESharedSignalEvent, _ANESharedWaitEvent — GPU↔ANE 동기화용 펜스/시그널
  • _ANEPerformanceStats — 하드웨어 성능 카운터 가능성
  • _ANEVirtualClient — 멀티프로세스 가상화 접근 가능성
• 미확인 항목:
  • ANE 코어 마이크로아키텍처 및 ISA
  • 그래프 내 연산의 코어 할당 방식
  • 클록 주파수 및 SRAM 구조

향후 계획

• Part 2: 행렬 곱 스케일링, SRAM 병목, Conv와 MatMul 성능 비교, Apple의 “38 TOPS” 수치 검증
• Part 3: ANE에서 신경망 학습 수행
• 모든 코드는 github.com/maderix/ANE의 ane/ 디렉터리에 공개
• 테스트 환경: M4 Mac Mini, macOS 15.x

[mammal]

참고: Asahi Linux out-of-tree ANE 드라이버

[GN⁺]

Hacker News 의견들

• 나는 Xcode 팀에서 여러 해 일했음. Apple이 이런 부분을 의도적으로 어렵게 만들어두는 방식을 잘 알고 있음
  작성자가 정말 훌륭한 일을 해냈다고 생각하며, 3편도 기대 중임
  • 예전에 Xcode 콘솔을 별도 창으로 분리할 수 있었는데, 왜 그 기능을 제거했는지 궁금함
• 오픈소스 소프트웨어에서 Neural Engine이 언제 작동하는지 이해가 안 됨
  나는 주로 lightgbm, sklearn, xgboost 같은 Python ML 라이브러리와 numpy를 사용함
  이런 연산들이 Apple 하드웨어에서 가속되는지, 간단히 벤치마크할 방법이 있는지 궁금함
  대부분의 벤치마크는 C 함수 수준이라, 고수준 라이브러리에서는 효과가 있는지 모르겠음
  ChatGPT가 Intel Mac과 Apple Silicon을 비교하라 해서 웃겼음. 이런 이유로 사람들이 여전히 AI를 싫어하는 것 같음
  • 대부분의 오픈소스에서는 NPU가 거의 활용되지 않음
    이유는 NPU가 제조사별로 특화되어 있어, 오픈소스 개발자들이 지원하기 어렵기 때문임
    Apple ANE도 예외가 아니며, 이번 연구는 그 문제를 Apple ANE에 한정해 해결하려는 시도로 보임
• 2편에는 벤치마크가 포함되어 있음
  Inside the M4 Apple Neural Engine 글에 따르면 6.6 FLOPS/W 성능을 내며, 사용하지 않을 때는 완전히 꺼져서 0W 소비라고 함
  • 하지만 Apple이 주장하는 38 TOPS 수치는 실제와 다름
    Apple은 “38 TOPS INT8”을 FP16 19 TFLOPS × 2로 계산했지만, 실제 하드웨어는 INT8 연산을 두 배 속도로 수행하지 않음
    이런 계산 방식을 따르는 건 Apple답지 않게 과장된 표현처럼 느껴짐
• 글에서 “우리”가 maderix(사람)와 Claude Opus 4.6(Anthropic)이 협업한 것이라 했는데, 솔직히 믿기 어려움
  LLM은 전문가도 속일 만큼 그럴듯한 허위 정보를 만들 수 있음
  모든 사실을 수동으로 검증했는지 의심스러움. 이런 면에서 미리 경고해줘서 오히려 읽지 않아도 돼서 다행임
  • Claude는 사용자가 좋은 결과만 보게끔 벤치마크를 숨기는 경향이 있음
    글에서도 그런 이상한 벤치마크들이 보임
  • 인간도 예전부터 그럴듯한 거짓 연구를 써왔음
    LLM 이전에도 학계에는 조작된 논문과 재현 불가능한 연구가 많았음
    결국 이런 분석은 더 많은 엔지니어가 검증해야 신뢰할 수 있음
• 나도 이런 실수를 하지만, 댓글 대부분이 “Apple 관련 아무거나”로 새는 것 같음
  주제와 상관없는 이야기들이 많음
• ANE의 소스 코드가 MLX 팀에도 비공개라는 게 놀라움
  아마도 MLX 프로젝트 책임자 Awni가 Apple을 떠난 이유 중 하나일 것 같음
• M1/M2 ANE의 Asahi Linux 문서를 통해 기본적인 내용은 이미 알려져 있었음
  하지만 이번 글은 그 내용을 더 깊이 확인하고 확장한 점이 좋음
  CoreML이 대형 matmul 연산에서는 거의 오버헤드가 없다고 하니, 로컬 AI 프레임워크에서 ANE를 prefill용으로 활용할 여지가 많음
  다만 decode 단계는 메모리 대역폭에 제한을 받으며, matmul을 1x1 convolution으로 바꾸는 과정이 비효율적이라 명확한 이득은 아님
• 최근 소식에 따르면 Apple이 Core ML을 대체할 새로운 프레임워크를 준비 중임
  이름은 Core AI로, 서드파티 LLM을 앱에 더 쉽게 통합할 수 있게 한다고 함
  관련 기사: Bloomberg 뉴스레터
• 이 글은 분명 사람이 썼지만, 몇몇 문장에서 LLM 특유의 표현이 보임
  그래도 매우 유익하고 흥미롭게 읽었음
  글에서 언급된 Github 저장소도 함께 참고할 만함
  • 앞으로 1년쯤 지나면, 사람들이 매일 LLM과 상호작용하면서 AI의 문체가 인간 언어에 스며드는 현상이 생길 것 같음
  • ‘Prior Art’ 섹션을 보면 “documenting”, “providing insight into” 같은 불필요한 반복 동사가 많음
    이 부분은 확실히 AI가 작성한 흔적이 있음
• 소프트웨어 엔지니어의 현재가 이미 미래 수준임
  ANE 리버스 엔지니어링보다 중요한 건, Manjeet이 AI의 도움으로 자신의 엔지니어링 역량을 얼마나 확장했는가임
  지금이 바로 AI가 개발자의 생산성을 가속하는 시대임