토큰 생성 속도를 정하는 건 연산이 아니라 대역폭이다

결론부터. 기기에서 LLM을 돌릴 때 속도를 정하는 건 연산 성능이 아니라 메모리 대역폭이다. 그래서 "신경망 전용 칩"인 Apple Neural Engine이 LLM에서는 GPU보다 느리다. 이번에 실측 숫자가 나왔다.

숫자

M1 ANE를 역공학한 분석에서 나온 전송 속도다.

• ANE 가중치 읽기 경로: 약 38 GB/s
• ANE 입력 읽기 경로: 약 59 GB/s
• GPU: 약 78 GB/s

여기에 조건이 하나 붙는다. 두 경로를 함께 써도 전송 시간이 겹치지 않고 더해진다.

(원문)

연산기가 모자란 게 아니다. M1 ANE에는 코어 16개와 FP16 MAC 레인 2,048개가 있고 트랜스포머에 필요한 계산을 수행할 수 있다. 문제는 주변 구조다.

주변 구조는 같은 가중치를 반복 사용하는 이미지 처리용 신경망(CNN)에 맞춰져 있다. LLM이 토큰을 하나씩 생성할 때는 큰 모델의 가중치를 계속 읽어야 하므로, 최대 연산 성능보다 메모리에서 데이터를 얼마나 빨리 가져오는지가 속도를 좌우한다.

ANE는 2017년 A11 시절의 워크로드 가정 위에 설계됐다. CNN은 같은 커널을 이미지 전체에 재사용하니 가중치를 한 번 올려두고 계속 쓴다. 자기회귀 디코딩은 그 재사용 패턴을 깨뜨린다. 토큰 하나 만들 때마다 모델 가중치를 통째로 훑어야 한다.

무엇이 바뀌나

"NPU 쓰면 빠르겠지"는 LLM에서 틀렸다. 맥에서 로컬 모델을 돌린다면 ANE가 아니라 GPU 경로를 쓰는 게 맞고, 이제 그 이유를 숫자로 말할 수 있다. 드라이버가 열리든 연산 성능이 올라가든 이 병목은 풀리지 않는다.

최적화 방향이 달라진다. 토큰 생성 속도를 올리려면 읽어야 할 바이트를 줄여야 한다. 양자화가 효과적인 이유가 여기 있다. 연산량이 줄어서가 아니라 초당 읽어야 할 가중치가 줄어서다. 벤치마크를 돌려보기 전에 대역폭 산수로 대략의 상한을 먼저 계산할 수 있다는 뜻이기도 하다.

프롬프트 처리와 토큰 생성은 다른 문제다. 긴 프롬프트를 밀어 넣는 구간은 병렬이라 연산이 병목이고, 답을 뱉는 구간은 순차라 대역폭이 병목이다. "느리다"고 느낄 때 어느 구간인지 먼저 봐야 한다. 둘의 처방이 반대 방향이다.

실무에서 만날 수 있는 함정 하나

누산기 범위 실험 결과가 구체적이다.

동일한 값 256개를 더했을 때 256 × 127.9375 = 32752는 정상 출력되는데, 256 × 128 = 32768은 +∞가 된다. 32768은 FP16으로 표현 가능한 값이다. 출력 형식의 오버플로가 아니라 소수부 16비트를 쓰는 부호 있는 32비트 누산기의 범위 한계다. 음수 쪽은 −32768까지 정상이라 경계가 비대칭이다.

커스텀 연산을 ANE에 올릴 일이 있다면 기억해둘 만한 경계다.

추측과 모르는 것

추측: 원문은 M5에서 ANE 코어를 GPU 코어 안에 통합한 변화를 독립형 NPU 쇠퇴의 시작일 수 있다고 본다. 그럴듯하다고 보지만 이건 해석이다. 통합의 이유는 여러 가지일 수 있고 발표된 것만으로 방향을 단정할 수는 없다.

모르는 것: 이 측정은 M1 기준이다. M3·M4·M5에서 대역폭이 얼마나 달라졌는지는 원문에 없고 나도 모른다. 로컬 추론을 진지하게 최적화한다면 자기 칩에서 직접 재는 것이 순서다. 위 숫자는 "왜 이 방향으로 재야 하는가"를 알려주지 "내 기계가 얼마인가"를 알려주지 않는다.