애플 실리콘에서 온디바이스 LLM을 돌려본 개발자라면 뉴럴 엔진(ANE)의 실제 성능이 사양표만큼 나오지 않는다는 인상을 받았을 것이다. 최근 한 리버스 엔지니어링 분석은 그 원인 중 하나를 구체적으로 짚어냈다. M3 뉴럴 엔진에는 DRAM에서 가중치를 스트리밍하는 처리량이 특정 조건에서 급격히 떨어지는 RTL 성능 결함이 있다는 것이다. 정상 구간에서는 45~60GB/s가 나오는 대역폭이, 코어당 전송하는 가중치 총량이 정확히 1MiB의 정수배가 되는 순간 17~19GB/s로 주저앉는다. 이 조건은 흔하게 발생해서, ANEMLL 프로젝트가 제공하는 15개 모델 중 7개가 영향을 받는다.
재현된 성능 붕괴
분석은 단일 토큰 디코딩 시 DRAM 가중치 스트리밍 처리량을 측정하는 과정에서 시작됐다. N=4096으로 고정하고 텐서 차원 D를 바꿔가며 측정하자, Llama 3.2가 기본으로 쓰는 D=2048이 D=1536보다 거의 3배 느렸다. D=2048에서 16.93GB/s였던 처리량이 D=2016에서는 44.5GB/s로 튀어, 불과 32칸 차이로 27.57GB/s가 갈렸다. 팬리스 M3 에어에서 40회 반복 측정하며 열·부하 조건을 통제하고 레지스터 파일에서 DMA 크기와 주소만 변수로 바꾼 결과였다. D 전체 구간을 훑자 2048마다 반복되는 공진 형태의 대역폭 급락이 드러났고, 붕괴 지점에서 약 256칸만 벗어나면 대역폭은 정상으로 회복됐다. 전송 자체는 정확히 완료되므로 데이터 정합성 버그는 아니다.
원인은 코어도 DRAM 뱅크도 아니었다
처음 의심한 것은 16개 코어가 2의 거듭제곱 스트라이드에서 같은 DRAM 뱅크로 몰리는 앨리어싱이었다. 그러나 활성 코어 수를 1개에서 16개까지 바꿔도 지연은 일정했다. 즉 코어 하나만 켜도 스로틀링이 나타났고, 문제는 코어 단위에 복제되어 있었다. DRAM 공간 상관성을 흔들어보려 가중치를 약 64MiB 영역에 무작위로 뿌려도 기준값 31.37GB/s 대비 32.29GB/s로 겨우 1GB/s 개선에 그쳤다. 약 200%에 이르는 붕괴 폭을 설명하기엔 턱없이 부족했다.
결정적 단서는 붕괴가 정확히 2의 거듭제곱 경계에서 반복된다는 사실이었다. D와 N을 반대로 조정해 코어당 정적 커널 데이터를 1MiB로 고정하자, D·N 조합과 무관하게 처리량이 동일하게 17GB/s로 무너졌다. 문제를 만드는 것은 D 자체가 아니라 코어당 총 바이트 수였던 것이다. 커널 DMA의 64바이트 라인 단위로 환산하면 1MiB는 0x4000, 즉 2의 14제곱 라인이다. 그리고 애플 실리콘의 가상 메모리 페이지 크기가 바로 16KiB(2의 14제곱)다. 주소 하위 14비트는 페이지 오프셋이라 가상-물리 변환에도 바뀌지 않기 때문에, DMA 제어 로직이 14비트 산술로 동작하도록 설계할 유인이 컸다.
빠진 랩(lap) 비트 하나
노치는 정확히 한 페이지 분량의 DMA 라인 폭에서 발생했고, ±256라인 지점에서 회복됐다. 여러 랩(k번의 0x4000 주기)을 겹쳐 보면 각 곡선이 랩 수 k에 비례해 수직으로 스케일됐고, 재정렬하면 하나의 곡선으로 포개졌다. 라인당 3.18·k 마이크로초의 기울기가 R²=0.96~0.99로 선형이었다. 해석하면, 붕괴 상태 자체는 주기 내 상대 위치 x가 결정하고, k는 그 붕괴된 속도로 전송되는 데이터 양이 몇 배인지를 정할 뿐이다. 결국 지목된 범인은 커널 DMA의 투기적 프리페치 링이다. 헤드/테일 주소 산술이 14비트로만 계산되고 랩(에포크)을 구분하는 비트가 빠져 있어서, 0x4000의 정수배 전송은 "한 랩 남음"을 "비었음"으로 오인한다. 프리페처가 선행 요청을 멈추면 전송은 완료되지만 대역폭 제한 스트리밍이 아니라 멈췄다 가는(stop-and-go) 직렬 경로로 전락한다.
실무적 의미와 한계
실용적 결론은 명확하다. 문제 경로를 피하도록 스케줄링만 바꿔도 큰 이득이 나온다. 실제로 Llama 3.2 1B는 초당 10.0토큰에서 24.3토큰으로(DRAM 사용량 24.7→60.0GB/s), Qwen3-8B는 1.36에서 2.97토큰으로(22.4→48.7GB/s) 뛰었다. 하드웨어 수정 없이 컴파일러 단계에서 코어당 커널 DMA가 정확히 1MiB로 떨어지는 작업을 잘게 쪼개면 회피할 수 있다는 뜻이다. ANE로 추론 파이프라인을 튜닝하는 팀이라면 텐서 차원과 전송 총량이 1MiB 배수에 걸리지 않도록 패딩이나 분할을 고려할 만하다.
다만 몇 가지 한계를 분명히 해야 한다. 측정은 팬리스 M3 에어 단일 기기에서 이뤄졌고, 근본 원인은 애플이 확인해준 사양이 아니라 관측 데이터에 기반한 유력한 추정이다. 프리페처의 랩 비트 누락이라는 결론은 회복 위치, k-선형 기울기, 페이지 크기 정합 같은 정황이 강하게 뒷받침하지만 내부 RTL을 직접 확인한 것은 아니다. 또한 이는 M3 세대에 국한된 관찰로, 다른 칩 세대에서도 동일한지는 별도 검증이 필요하다. 그럼에도 사양표상의 100GB/s급 LPDDR-6400 대역폭과 실제 체감 성능 사이의 간극이 어디서 새는지를 라인 단위 산술까지 파고들어 보여준 사례라는 점에서, 온디바이스 추론 성능을 다루는 실무자에게 참고할 가치가 크다.