← 최신 논문
🤖 machine learning

What actually runs: a measurement study of language model placement and decode speed on the Apple Neural Engine

애플 뉴럴 엔진(Apple Neural Engine)에서의 언어 모델 배치 및 디코딩 속도에 관한 엄격한 측정 연구를 통해, 저자는 모델 아키텍처 자체보다는 계산적 표현(computational expression)과 가중치 인코딩(weight encoding)이 가속기 상주(accelerator residency)와 성능을 결정한다는 것을 입증하며, 이는 훨씬 더 작고 빠른 삼진 모델(ternary models)을 달성하기 위해 인코딩 효율성을 우선시하는 설계 절차로 이어진다.

원저자: Shahir M A

게시일 2026-08-25✓ Author reviewed
📖 4 분 읽기☕ 가벼운 읽기

원저자: Shahir M A

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

스마트폰이 대화를 이해하려고 노력하는 모습을 상상해 보십시오. 이를 위해 스마트폰은 기기 자체에서 거대한 디지털 두뇌인 언어 모델을 실행해야 합니다. 이것이 매끄럽게 작동하려면, 스마트폰은 일반적인 용도의 메인 두뇌 대신 오직 이런 종류의 사고를 위해 특별히 설계된 초고속 프로세서를 사용해야 합니다. 문제는 이 특수 프로세서가 매우 까다롭다는 점입니다. 이 프로세서는 특정 유형의 계산만을 실행하며, 수학적으로는 동일하더라도 다른 방식의 계산은 실행하기를 거부합니다. 수년 동안 개발자들은 어떤 계산이 작동할지, 그리고 어떻게 하면 빠르게 만들 수 있을지 추측하기 위해 노력해 왔으며, 종종 틀린 것으로 판명되는 경험칙에 의존해 왔습니다. 그들은 모델이 충분히 작다면 빠른 프로세서에서 실행될 것이라거나, 숫자를 작게 만드는 것이 항상 도움이 될 것이라고 가정해 왔습니다. 하지만 아무도 프로세서를 실제로 관찰하여 그것이 실제로 무엇을 하고 있는지 보거나, 모델의 크기와 숫자를 저장하는 방식이 속도를 어떻게 변화시키는지 정확하게 측정하지 않았습니다.

샤히르 M A(Shahir M A)라는 연구자는 추측하는 것을 멈추고 관찰하기로 했습니다. 그는 M1 칩이 탑재된 애플 컴퓨터를 사용하여, 언어 모델이 스마트폰의 특수 프로세서인 뉴럴 엔진(Neural Engine)에서 실행될 때 정확히 어떤 일이 발생하는지 확인하기 위한 일련의 실험을 구축했습니다. 그는 단순히 소프트웨어가 무엇을 할 것이라고 '말하는' 것만을 본 것이 아니라, 칩을 통해 흐르는 실제 전기와 데이터의 움직임을 측정하여 실제로 무슨 일이 일어나고 있는지 확인했습니다. 그는 동일한 수학적 연산을 구현하는 수십 가지의 서로 다른 방법을 테스트했고, 다양한 크기의 실제 모델을 훈련시켰으며, 표준 정밀도부터 매우 압축된 저정밀도 형식에 이르기까지 모델 내부의 숫자를 저장하는 방식을 변경했습니다. 그들의 목표는 단순했습니다. 무엇이 모델을 빠른 프로세서 위에서 실제로 구동하게 만드는지, 그리고 일단 구동되면 얼마나 빨리 말할 수 있는지를 알아내는 것이었습니다.

그들이 발견한 첫 번째 사실은, 프로세서는 계산이 무엇을 의미하는지에는 관심이 없으며 오직 그것이 어떻게 쓰였는지에만 관심이 있다는 것이었습니다. 그들은 특정 유형의 정규화(normalization)—모델이 숫자를 안정적으로 유지하도록 돕는 단계—를 한 가지 방식으로 작성하면 프로세서가 즉시 받아들이고 풀 스피드로 실행한다는 것을 발견했습니다. 하지만 정확히 같은 수학적 단계를 약간 더 복잡한 일련의 명령어를 사용하여 작성하면, 프로세서는 그것을 만지기를 거부하고 스마트폰이 더 느린 일반 용도 두뇌를 사용하도록 강제했습니다. 이는 마치 프로세서가 특정 수학 방언을 사용하는 것과 같습니다. 만약 당신이 올바른 방언을 사용한다면 프로세서는 귀를 기울이지만, 의미가 같더라도 다른 방형을 사용한다면 프로세서는 자리를 떠나버립니다. 이는 개발자가 코드를 작성하는 방식이 수학 그 자체만큼 중요하다는 것을 의미합니다.

두 번째이자 아마도 가장 놀라운 발견은, 모델의 크기가 빠른 프로세서에서 실행될 수 있는지를 결정하는 유일한 요소가 아니라는 점이었습니다. 연구진은 표준 정밀도로 작성된 약 2,600만 개의 파라미터를 가진 모델이 특수 프로세서에서 실행되기에는 너무 작다는 것을 발견했습니다. 그 모델은 느린 두뇌에서 실행되도록 강제되었고, 단어 하나를 생성하는 데 1초 이상이 걸렸습니다. 그러나 연구진이 정확히 동일한 모델을 가져와 내부의 숫자를 더 적은 비트를 사용하도록 압축하자, 프로세서는 갑자기 이를 받아들였습니다. 압축된 버전은 빠른 프로세서에서 실행되어 1초 미만에 단어를 생성했습니다. 사실, 작은 모델들의 경우, 숫자를 압축하는 것이 그들을 빠른 프로세서에 올릴 수 있는 유일한 방법이었습니다. 프로세서에는 숨겨진 규칙이 있었습니다. 작은 모델은 압축되지 않으면 실행하지 않겠다는 것이었습니다. 이는 큰 모델일수록 빠른 프로세서가 필요하다는 일반적인 가정을 뒤집었습니다. 여기서 작은 모델들은 문 안으로 들어오기 위해 압축이 필요했던 것입니다.

모델이 빠른 프로세서 내부로 들어간 후에는, 수학이 얼마나 복잡한가가 아니라 얼마나 많은 데이터가 이동해야 하는지에 의해 속도가 결정되었습니다. 연구진은 데이터의 흐름을 측정했고, 모델이 단어를 생성할 때마다 자신의 지식을 구성하는 숫자들인 가중치(weights) 전체를 프로세서로 스트리밍해야 한다는 것을 발견했습니다. 이는 대화가 얼마나 길어지든 상관없이 매 단어마다 발생했습니다. 이 때문에 속도는 가중치에 포함된 비트 수와 직접적으로 연결되었습니다. 2비트 숫자를 사용하는 모델은 표준 숫자를 사용하는 모델보다 데이터를 훨씬 적게 이동시켰기 때문에 약 3배 더 빨랐습니다. 모델이 어텐션(attention)에 집중하든 컨볼루션(convolution)에 집중하든, 사용된 수학의 유형은 이미 프로세서에서 실행 중일 때 속도에 거의 영향을 미치지 않았습니다. 중요한 것은 오직 이동하는 데이터의 크기뿐이었습니다.

연구진은 스마트폰을 위한 언어 모델을 만드는 가장 좋은 방법은 크기가 아니라 압축부터 시작하는 것이라고 결론지었습니다. 큰 모델을 만든 다음 그것을 줄이려고 노력하는 대신, 가장 압축된 형식을 먼저 선택하고, 사용 가능한 메모리 예산에 맞춰 파라미터를 추가해야 합니다. 연구진은 특정 유형의 압축된 수학을 사용하는 2,500만 개의 파라미터를 가진 모델이 단 10메가바이트의 공간에 들어갈 수 있으며, 약 0.6밀리초 만에 단어를 생성할 수 있다는 것을 발견했습니다. 이는 개발자들이 보통 시작하는 표준적인 미압축 모델보다 거의 10배 작고 3배 더 빨랐습니다. 이 연구는 기기 내 언어 모델을 빠르게 만드는 경로가 모델을 더 크게 만들거나 복잡하게 만드는 것이 아니라, 수학을 쓰는 올바른 방법과 숫자를 저장하는 올바른 방법을 선택하는 데 있음을 보여주었습니다. 실제 데이터의 흐름을 측정함으로써, 그들은 속도의 핵심이 단순히 빠른 프로세서를 갖는 것이 아니라, 그것에게 어떻게 먹이를 주어야 하는지 정확히 아는 것임을 증명했습니다.

연구 분야의 논문에 파묻히고 계신가요?

연구 키워드에 맞는 최신 논문의 일일 다이제스트를 받아보세요 — 기술 요약 포함, 당신의 언어로.

Digest 사용해 보기 →