온디바이스 AI의 가능성과 딜레마
학습 차원에서 틈틈이 해외 전문가들이 블로그나 미디어 그리고 책에서 쓴 글을 번역 또는 요약 정리하고 있습니다. 이번 포스팅도 그중 하나고요. 거칠고 오역된 부분이 있을 수 있습니다. 제대로 번역되지 않은 부분은 확인 주시면 반영토록 하겠습니다. 번역 과정에서 의미 전달이 애매한 일부 문장은 삭제했습니다. 이번 글은세미어낼리시스에 올라온 글을 정리한 것입니다.
AI 업계에서 가장 많이 논의되는 부분은 거대 기술 기업만이 개발할 수 있는 거대 언어 모델들을 추구하는 것이다. 이들 모델을 학습하는 데는 많은 비용이 들지만, 배포하는 것은 어떤 면에서 훨씬 더 어렵다. 실제로 오픈AI GPT-4는 매우 크고 컴퓨팅 집약적이어서 추론을 실행하는 것만으로도 각각 8개 GPU, 대용량 메모리, 엄청난 고속 네트워킹을 갖춘 약 25만달러짜리 서버 여러 대가 필요하다. 구글도 비슷한 접근 방식을 취하고 있는데, 풀사이즈 PaLM 모델을 실행하려면 64개 TPU와 16개 CPU가 필요하다. 2021년 메타의 가장 큰 추천 모델에는 사용자에게 서비스를 제공하기 위해 128개 GPU를 필요로 했다.
AI에 초점을 맞춘 클라우드와 기업 LLM 개발 및 배포를 지원하는 모자이크ML(MosaicML)과 같은 ML 운영 회사들이 등장하면서 보다 강력한 모델들은 계속 확산될 것이지만, 규모가 크다고해서 항상 좋은 것은 아니다.
AI 업계에는 대규모 컴퓨팅을 거부하는 완전히 다른 세계가 있다. 클라이언트 기기에서 실행할 수 있는 소형 모델들 대한 오픈소스 진영의 움직임은 아마 업계에서 두 번째로 많이 논의되는 부분일 것이다. 메모리 벽( the memory wall) 때문에 5년 이상 하드웨어가 발전했음에도 GPT-4 또는 전체 PaLM 규모 모델은 노트북과 스마트폰에서 실행하는 것은 바랄 수 없었지만 온디바이스 추론에 초점을 맞춘 모델 개발 생태계가 번성하고 있다.
이번 글에선 노트북이나 휴대폰과 같은 클라이언트 사이드 디바이스에서 이러한 소규모 모델들에 대해 다뤄본다. 추론 성능 게이팅 요소( gating factors), 모델 크기의 근본적인 한계, 그리고 앞으로 하드웨어 개발이 디바이스 기반 모델 분야 개발 경계를 어떻게 설정할 것인지에 초점을 맞출 것이다.
왜 로컬 모델들이 필요한가
온디바이스 AI를 활용할 수 있는 잠재적인 사례들은 광범위하고 다양하다. 사람들은 거대 기업들이 모든 데이터를 소유하는 것에서 벗어나고 싶어한다. AI 업계 상위 5개 업체 중 4개 업체인 구글, 메타, 바이두, 바이트댄스는 기본적으로 회사 전체 수익이 사용자 데이터를 사용해 광고를 타겟팅하는 것에 기반하고 있다.
이들 기업에게 개인정보 보호의 부재가 얼마나 중요한지 IDFA 소동( IDFA kerfuffle)만 봐도 알 수 있다. 온디바이스 AI는 이러한 문제를 해결하는 동시에 사용자별 맞춤 설정 및 튜닝을 통해 기능을 향상시킬 수 있다.
소규모 언어 모델들에 이전 세대 대규모 모델 성능을 제공하는 것은 지난 몇 달 동안 AI 분야 가장 중요한 발전들 중 하나다.
간단하고 쉽게 해결된 예로 온디바이스 음성 텍스트 변환을 들 수 있다. 음성 텍스트 변환은 현재 동급 선도 제품인 구글 픽셀 스마트폰에서도 상당히 나쁜 수준이다. 클라우드 기반 모델로 전환할 때 지연 시간도 자연스러운 사용에 매우 불편하며 인터넷 연결 상태에 따라 크게 달라진다. 모바일 기기에서 오픈AI 위스퍼(OpenAI Whisper)와 같은 모델이 실행되면서 온디바이스 음성-텍스트 변환 세계는 빠르게 바뀌고 있다. (구글 IO는 이러한 기능들 곧 대규모로 업그레이드될 수 있음을 보여줬다.)
보다 큰 사례로는 개인 비서로서는 매우 끔찍한 시리(Siri), 알렉사(Alexa) 등이 있다. 자연스러운 음성 합성 AI 도움과 함께 대규모 언어 모델은 훨씬 더 인간적이고 지능적인 AI 비서가 여러분 삶을 지원할 수 있다.
캘린더 이벤트 생성부터 대화 요약, 검색에 이르기까지 모든 디바이스에서 다중 모드(multi-modal ) 언어 모델을 기반으로 한 개인 비서들이 등장할 것이다. 이들 모델은 이미 시리(Siri), 구글 어시스턴트, 알렉사, 빅스비 등보다 이미 뛰어나다. 그리가 아직 초기 단계에 있다.
여러 측면에서 생성 AI는 빠르게 대규모 기본 모델과 클라이언트 디바이스에서 실행할 수 있는 훨씬 더 작은 모델을 갖춘 바이모달( bimodal) 배포가 확산되고 많은 투자를 끌어모으고 있다. 그 사이에 캐즘도 크다.
온디바이스 추론의 근본적인 한계
온디바이스 AI의 가능성은 의심할 여지 없이 매력적이지만, 로컬 추론을 예상보다 더 어렵게 만드는 몇 가지 근본적인 한계들도 있다. 대부분의 클라이언트 디바이스들에는 전용 GPU가 없으며 앞으로도 없을 것이므로 이들 모든 과제들은 SoC에서 해결해야 한다. 주요 우려 사항 중 하나는 GPT 스타일 모델들에 필요한 상당한 메모리 공간과 연산 능력이다. 연산 요구 사항들은 향후 5년 동안 보다 전문화된 아키텍처, 3nm/2nm로 무어의 법칙 확장, 칩 3D 스태킹(3D stacking)으로 빠르게 해결될 문제들이다.
최고급 클라이언트 모바일 디바이스에는 인텔, AMD, 애플, 구글, 삼성, 퀄컴, 미디어텍과 같은 회사에서 진행 중인 아키텍처 혁신으로 인해 약 500억개 트랜지스터와 온디바이스 AI에 충분한 TFLOP/s 이상이 제공될 것이다. 분명한 것은 기존 클라이언트 AI 가속기는 트랜스포머에 적합하지 않지만, 몇 년 안에 상황이 바뀔 것이다 디지털 로직 측면에서 칩의 이러한 발전은 컴퓨팅 문제를 해결할 수 있지만 메모리 벽과 데이터 재사용이라는 근본적인 문제를 해결할 수는 없다.
GPT 스타일 모델들은 이전 토큰이 주어지면 다음 토큰(~= 단어)을 예측하도록 훈련된다. 텍스트를 생성하려면 프롬프트를 입력하고 다음 토큰을 예측하도록 요청하고, 생성된 토큰을 프롬프트에 추가한 뒤 다음 토큰을 예측하도록 요청하고, 계속 진행한다. 이렇게 하려면 다음 토큰을 예측할 때마다 모든 매개 변수를 램(RAM)에서 프로세서로 보내야 한다. 첫 번째 문제는 이러한 모든 매개변수를 가능한 컴퓨팅 부분에 가깝게 저장해야 한다는 것이다. 또 다른 문제는 이러한 파라미터들을 필요할 때 정확하게 컴퓨팅 부분 칩으로 로드할 수 있어야 한다는 것이다.
메모리 계층 구조에서 자주 액세스하는 데이터를 칩에 캐싱하는 것은 대부분 워크로드들에서 일반적이다. 온디바이스 LLM에 대한 이 접근 방식의 문제는 매개변수를 캐싱하는 작업이 너무 많은 메모리 공간을 차지한다는 것이다. FP16 또는 BF16과 같은 16비트 숫자 형식으로 저장된 파라미터는 2바이트입니다. 가장 작으면서 '괜찮은'(decent)은 범용 거대 언어 모델들도 최소 70억개 매개변수가 있는 LLAMA입니다. 더 큰 버전은 훨씬 더 높은 품질을 제공한다. 이 모델을 간단하게 실행하려면 16비트 정밀도로 최소 14GB 메모리가 필요합니다. 전이 학습, 스파스화, 양자화( transfer learning, sparsification, and quantization) 등 메모리 용량을 줄일 수 있는 다양한 기술이 있지만, 이들은 기술은 무료로 제공되지 않으며 모델 정확도에도 영향을 미친다.
게다가 14GB는 다른 애플리케이션, 운영 체제 및 활성화/kv 캐시와 관련된 기타 오버헤드는 간과한다. 따라서 클라이언트 엔드포인트에 필요한 계산 능력이 있다고 가정하더라도 개발자가 온디바이스 AI를 배포하는 데 사용할 수 있는 모델 크기에 즉각적인 제한이 생긴다. 클라이언트 측 프로세서에 14GB 파라미터를 저장하는 것은 물리적으로 불가능하다. 가장 일반적인 온칩 메모리 유형은 SRAM으로, TSMC 3nm에서도 100mm^2당 0.6GB에 불과하다.
참고로, 이는 곧 출시될 아이폰 15 프로에 탑재된 A17 프로세서와 거의 동일한 크기 칩이며, 곧 출시될 M3보다 약 25% 작다. 이 수치는 또 어시스트 회로(assist circuity , 어레이 비효율성(array inefficiency), NoC(Network-on-Chip) 등으로 인한 오버헤드가 없는 수치다. 로컬 SRAM은 대규모로 클라이언트 추론에 사용할 수 없다. FeRAM 및 MRAM과 같은 새로운 메모리가 희망을 주기는 하지만 기가바이트 규모로 제품화되기에는 아직 멀었다.
다음 게층은 DRAM으로 내려 간다. 최고급 아이폰인 14 프로맥스에는 6GB RAM이고 하이엔드 PC는 16GB 이상이지만, 신규로 판매되는 제품 대부분은 8GB RAM이다. 일반적인 클라이언트 디바이스들 FP16으로 정량화된 70억개 파라미터 모델을 실행할 수 없다.
그러면 묻게 된다. 계층 구조에서 다른 계층으로 내려갈 수 없는 이유는 무엇일까? 이러한 모델을 RAM이 아닌 낸드 기만 SSD에서 실행할 수 있을까? 안타깝게도 SSD는 너무 느리다. FP16에서 70억개 매개변수를 가진 모델은 토큰 1개(약 4자)를 생성하기 위해 가중치를 스트리밍하는 데만 14GB/s IO가 필요하다! 가장 빠른 PC 스토리지 드라이브는 기껏해야 6GB/s이지만, 대부분 휴대폰과 PC들은 1GB/s에도 못미친다. 4비트 양자화에서 1GB/s로 실행할 수 있는 가장 큰 모델은 여전히 약 20억개 매개변수 범위에 불과하며, 이는 다른 사용 사례는 고려하지 않고 하나의 애플리케이션에만 SSD를 최대로 고정했을 때다. 평균적인 기기에서 반 단어가 만들어 질때까지 7초를 기다리는 것을 원하지 않는 한, 매개 변수를 스토리지에 저장하는 것은 옵션이 아닙니다. 램에 저장해야 한다.
모델 크기 제한
평균적으로 사람은 분당 250단어를 읽는다. 좋은 사용자 경험을 위한 하한선으로, 온디바이스 AI는 초당 8.33개, 즉 120ms에 한 번씩 토큰을 생성해야 한다. 숙련된 속독자는 분당 1,000단어에 도달할 수 있으므로 상한선의 경우, 온디바이스 AI는 초당 33.3토큰, 즉 30ms에 한 번씩 생성할 수 있어야 한다.
AI가 아닌 일반 애플리케이션과 활성화/kv 캐시가 전체 대역폭 절반을 소비한다고 보수적으로 가정하면, 아이폰에서 14에서 실현 가능한 최대 모델 크기는 약 10억개 FP16 파라미터 또는 약 40억개 int4 파라미터다. 이것이 스마트폰 기반 LLM의 근본적인 한계다. 이보다 더 크면 설치된 것들 상당 부분이 제외되기 때문에 적용할 수 없을 것이다.
이것이 로컬 AI가 얼마나 크고 강력해질 수 있는지에 대한 근본적인 한계다. 애플과 같은 회사가 이를 활용해 보다 첨단 AI가 탑재된 더 새롭고 비싼 휴대폰향 판매할 수도 있겠지만, 아직은 먼 미래의 일이다. 위와 같은 가정 아래 PC에서 인텔 최고급 13세대 i9 CPU와 애플 M2는 약 30억~40억개 파라미터로 제한된다.
일반적으로 이는 소비자 디바이스 하한선일 뿐이다. 다시 한 번 얘기하지만 실제로는 달성되지 않는 이론적 IO 속도나 단순화를 위해 활성화/kv 캐시를 사용하는 등 여러 요소는 무시했다. 이러한 요소들은 BW 요구 사항을 더욱 높이고 모델 크기를 더욱 제한할 뿐이다. 내년에 출시될 혁신적인 하드웨어 플랫폼이 환경을 재편하는 데 도움이 될 수 있지만, 메모리 벽은 현재와 미래 대부분의 디바이스에서도 제약으로 작용할 것이다.
서버사이드 AI가 승리하는 이유
생성 AI는 메모리 용량과 대역폭 요구 사항이 매우 크기 때문에 이전 다른 어떤 애플리케이션보다 메모리 벽의 영향을 더 많이 받는다. 클라이언트 추론에서 생성 텍스트 모델의 배치 크기는 거의 항상 1입니다. 후속 토큰마다 이전 토큰/프롬프트를 입력해야 하므로 메모리에서 칩으로 파라미터를 로드할 때마다 생성된 토큰 1개에 대해서만 파라미터 로드 비용이 상각된다. 이 병목 현상을 분산시킬 다른 사용자는 없습니다. 메모리 월은 서버 측 컴퓨팅에도 존재하지만, 매개변수가 로드될 때마다 여러 사용자를 위해 생성된 여러 토큰(배치 크기)에 걸쳐 상각할 수 있다.
우리 데이터에 따르면 HBM 메모리는 H100 또는 TPUv5와 같은 서버급 AI 칩 제조 비용의 거의 절반에 불과하다. 클라이언트 사이드 컴퓨팅은 훨씬 저렴한 DDR 및 LPDDR 메모리(GB당 약 4배)를 사용할 수 있지만, 이러한 메모리 비용은 여러 번 동시 추론에 걸쳐 상각할 수 없다. 배치 크기를 무한대로 늘릴 수 없는 이유는 단일 토큰이 결과를 추가하고 새 토큰을 생성하기 전에 다른 모든 토큰이 처리될 때까지 기다려야 한다는 또 다른 어려운 문제가 발생하기 때문이다.
이 문제는 모델을 여러 개 칩으로 분할해 해결한다. 편리하게도 PaLM 모델은 64개 칩에서 256개 배치 크기로 추론을 실행해 초당 6.67개 토큰, 즉 분당 200단어라는 최소 실행 가능 목표에 도달한다. 즉, 매개변수가 로드될 때마다 256개 서로 다른 추론에 활용된다.
메모리 벽이 완화되고 있는 만큼, 배치 크기가 증가함에 따라 FLOPS 활용도가 향상된다. 지연 시간은 더 많은 칩에 작업을 분할해야만 합리적인 수준으로 끌어올릴 수 있다. 하지만 이 경우에도 FLOPS의 40%만 사용된다. 구글은 PaLM 추론에서 85.2초 지연 시간으로 76% FLOPS 활용도를 보여 주었으므로 메모리 벽은 여전히 큰 요인임이 분명하다. 그렇다면 서버 사이드가 훨씬 더 효율적이지만 로컬 모델은 어디까지 확장할 수 있을까?
클라이언트 사이드 모델 아키텍처의 진화 및 하드웨어 발전
클라이언트 사이드 모델이 사용할 수 있는 파라미터 수를 늘리기 위한 다양한 기술들이 잇다., 특히 애플과 AMD에서 흥미로운 하드웨어 개발이 이루어지고 있으며, 이는 향후 확장에 도움이 될 수 있다.
