"고정 기능 블록은 한 가지 일을 10분의 1 전력으로 해. 값은 한 가지 일만 한다는 거고."
폰 칩엔 왜 전문가가 가득한지
범용 코어는 뭐든 할 수 있어. 느리고 비싸게. 한 가지 일을 위해 만든 블록, 그러니까 비디오 스트림 디코드, 컨볼루션 실행, 키 보관은 그 일을 에너지의 몇 분의 일로 해. 몇 시간 비디오를 재생해야 하고 눈 깜짝할 새 잠금을 풀어야 하는 폰은 범용 코어의 값을 감당 못 해. 그래서 A 시리즈는 다이를 전문가로 채웠고, M 시리즈는 그걸 하나도 빠짐없이 물려받았어. 이 퀘스트에 중요한 건 셋이야.
뉴럴 엔진
M3 티어 전부가 16코어 뉴럴 엔진을 실어. M3 Ultra는 다이가 둘이라 32코어로 적혀. Core ML로 닿아. 모델을 Core ML 형식으로 컴파일하고, 연산 유닛으로 뉴럴 엔진을 요청하면, 프레임워크가 실제로 거기서 뭘 돌릴지 정해. 애플 자체 온디바이스 언어 모델이 대표 세입자야. 2024년 Foundation Models 보고서는 "약 30억 파라미터 온디바이스 언어 모델"과 "우리 뉴럴 엔진에서의 효율적인 Key-Value(KV) 캐시 갱신"을 설명해. 애플의 ANE 위 트랜스포머 연구는 2022년까지 거슬러 올라가.
그런데도 맥의 언어 모델 런타임 중 이걸 쓰는 건 거의 없어. 솔직한 이유는 Llama 3.1 실행에 대한 애플 자체 Core ML 글에 있어. 그런 모델은 "보통 메모리 대역폭에 제약"되니까 그 글은 GPU를 겨냥해. 대역폭에 묶인 디코드는 더 빠른 고정 기능 곱셈기한테서 얻을 게 없고, 판을 지배하는 런타임들인 MLX, llama.cpp, PyTorch는 프로그래밍 가능한 커널, 동적 형태, 자라는 캐시를 원해. Metal은 그걸 주고, 뉴럴 엔진의 컴파일된 그래프 모델은 안 줘. 특정 기기에서 애플 자체 온디바이스 모델이 어느 연산 유닛에서 도는지는 문서화돼 있지 않아. 이 집에서 뉴럴 엔진에 조금이라도 닿는 앱은 하나뿐이고, 그것도 간접적으로야. Core ML 위에 만든 온디바이스 음성 인식 엔진인데, 언어 모델링이 아니라 전력 프로필 때문에 골랐어.
미디어 엔진
하드웨어 H.264, HEVC, ProRes 인코드와 디코드, 그리고 AV1 디코드가 M3 티어 전부에. Max는 인코드 엔진 둘과 ProRes 엔진 둘, Ultra는 각각 넷에 디코더 둘. 또 다이 둘이야. 팬 없는 노트북이 비디오를 편집하게 만드는 블록이고, 워커가 라이브러리를 트랜스코딩할 때 이 집의 미디어 파이프라인이 기대는 블록이야. 전문가 집합으로서의 SoC를 제일 깔끔하게 보여주는 것이기도 해. 트랜스코딩을 돌려도 CPU는 거의 안 움직여.
Secure Enclave
자기 메모리와 자기 부트 체인을 가진 별도 프로세서야. 디스크를 여는 키와 주인을 인증하는 키를 들고 있어. 애플 실리콘에서 FileVault가 체감 비용 하나 없는 이유고, 훔친 로직 보드가 벽돌인 이유야. 이 퀘스트에서 역할은 작지만 정확해. SoC에서 격리 자체가 핵심인 유일한 부분이고, 하필 경계를 없앤 게 정의적 특징인 다이 위에 있어.
직접 세어봐
macOS의 장치 트리는 인스턴스마다 이름을 붙여. 코드 블록은 M3 맥 세 대에서 ssh로 그걸 읽어. Air는 ane, avd, ave를 보고해. 하나씩, 번호 없이. M3 Max는 ane0, avd0, ave0, ave1. M3 Ultra는 ane0 ane1, avd0 avd1, ave0 ave1 ave2 ave3. 애플의 스펙 표, 그러니까 16/32코어 뉴럴 엔진, 디코더 하나 또는 둘, 인코더 하나, 둘, 넷을 하드웨어에서 되읽은 거고, 1번 트랙의 다이 개수가 운영체제 눈에 보이게 된 거야.