
LLM 추론을 RAM 내부에서 직접 수행하여 메모리 벽(Memory Wall) 문제 해결하기
요약
LLM 추론 시 발생하는 메모리 대역폭 문제를 해결하기 위해 RAM 내부에서 직접 연산을 수행하는 CaSA 기술을 소개합니다. 1-bit 및 ternary 모델을 활용하여 가중치가 메모리 버스를 통과하지 않고 DIMM 내부에서 연산되도록 설계되었습니다.
핵심 포인트
- 메모리 벽(Memory Wall) 문제를 해결하기 위한 PIM(Processing-in-memory) 접근 방식
- 가중치를 이동시키지 않고 RAM 내부에서 직접 추론을 수행하여 대역폭 한계 극복
- 1-bit/ternary 양자화 모델을 통해 일반 DDR4 메모리에서 엔드 투 엔드 실행 가능
- 데이터 이동 최소화로 열 발생 및 배터리 소모 문제 완화 기대
PrismML의 1-bit/ternary Bonsai 모델을 둘러싼 열기는 스마트폰 거대 기업들, 특히 Apple이 엣지 디바이스(edge devices)에서 LLM을 어떻게 구현할지에 대해 업계가 긴밀히 주시하게 만들고 있습니다. AI를 온디바이스(on-device)로 이동시키는 것은 매우 영리하고 필수적인 전략입니다. 이는 EU 규정에 부합하는 절대적인 사용자 프라이버시를 보장하고, 비용이 많이 드는 클라우드 추론(cloud inference)으로부터 경제적 구조를 근본적으로 전환하며, 사용자들이 진정한 AI 성능을 갖춘 실리콘을 찾게 함으로써 상당한 하드웨어 업그레이드 슈퍼사이클(supercycle)의 길을 열어줍니다. 스마트한 온디바이스 "시맨틱 라우터(Semantic Router)"를 만들기 위해서는 모델이 아마도 27B 이상의 파라미터 규모에 도달해야 할 것입니다. 이를 휴대폰에서 구현하려면 PrismML의 ternary 가중치(weights)와 같은 극단적인 양자화(quantization)가 필요합니다. 하지만 소프트웨어 세계에서 종종 간과되는 중요한 하드웨어 현실은 가중치를 RAM에 담는 것이 그것을 이동시키는 것과 동일하지 않다는 점입니다. 표준 LPDDR에서 27B ternary 모델을 실행하면 가혹한 메모리 대역폭(memory bandwidth) 한계에 부딪힙니다. 생성되는 모든 토큰마다 모든 가중치가 SoC 버스(bus)를 통과해야 하기 때문입니다. 토큰당 기가바이트 단위의 데이터 이동은 열 스로틀링(thermal throttling)과 배터리 소모를 의미합니다. 이는 FLOPs의 문제가 아니라 버스(bus)의 문제입니다. 여기서 질문이 생깁니다: 왜 우리는 여전히 데이터를 연산 장치로 이동시키고 있는가? 왜 가중치가 이미 존재하는 곳에서 추론을 실행하지 않는가? 대부분의 PIM(Processing-in-memory) 결과물은 기본 요소(primitives), 시뮬레이터, 또는 커스텀 테스트 실리콘 단계에서 멈춥니다. SAFARI 그룹의 오픈 소스인 DRAM Bender와 전하 공유(charge-sharing) 문헌을 기반으로, 저는 기존 연구들이 다 해결하지 못한 질문에 답하기 위해 CaSA를 구축했습니다: 완전한 LLM — 즉, 모든 가중치-행렬 곱셈(weight-matrix multiplication) — 이 오늘날 구매 가능한 일반 DDR4 스틱 위에서 실행될 수 있는가? 가능합니다. ternary 및 1-bit 모델(BitNet-2B, Bonsai-1.7B)은 전하 공유 다수결(charge-sharing majority votes) 방식을 통해 수정되지 않은 DIMM 내부에서 모든 선형 레이어(linear layers)가 실행되며 엔드 투 엔드(end-to-end)로 작동합니다. 가중치는 메모리 버스를 절대 통과하지 않으며, 오직 활성화 값(activations)과 결과값만이 이동합니다.
https://github.com/pcdeni/CaSA 속도에 대한 투명한 공개: 프로토타입은 PCIe를 통해 호스트에 의해 오케스트레이션(orchestrated)되고 왕복 지연 시간(round-trip latency)이 지배적이기 때문에 답변당 몇 분이 걸릴 정도로 느립니다. DRAM 연산 자체는 마이크로초(microseconds) 단위로 수행됩니다. 우리는 그 격차를 계속 좁혀나가고 있습니다 (현재 스택은 베이스라인 대비 -64.7% 차이가 나며, FPGA는 이제 호스트 왕복 없이 여러 번의 반복 연산 루프를 실행하여 정확한 결과를 반환합니다). 하지만 이 길의 정직한 종착지는 두 단계로 이루어져 있습니다. 단기적으로는: 범용 메모리 컨트롤러(commodity memory controllers)는 명령 수준의 제어(command-level control)를 노출하지 않으므로, 현재는 FPGA가 루프에 포함되어야 합니다. SoC 메모리 컨트롤러 지원은 팹(fab)의 변경이 아닌 펌웨어 및 컨트롤러의 결정 사항입니다. 하지만 완벽한 컨트롤러 통합이 이루어지더라도, 어레이 내부의 모든 투표(in-array vote) 결과는 여전히 카운트되기 위해 전체 행(full row) 단위로 LPDDR 버스를 통과해야 합니다. 이를 NPU와 경쟁할 수 있을 정도로 진정으로 빠르게 만들기 위해서는 다이(die) 수준의 한 가지 추가 사항이 필요합니다: 즉, in-DRAM 팝카운트/누적(popcount/accumulate) 회로입니다. 이를 통해 결과가 킬로바이트(kilobyte) 단위의 행이 아닌 몇 바이트의 데이터로 다이를 떠날 수 있게 됩니다. 우리는 이미 버스의 FPGA 측에서 해당 카운팅 회로를 프로토타입으로 제작했습니다. 이를 다이 내부로 옮기는 것은 제조사의 단계이며, DRAM 제조는 독점적(proprietary)입니다. 이것이 범용화된 엣지 AI(edge AI)를 위한 남은 병목 구간입니다. 장치:
/u/pcdeni [link] [comments]AI 자동 생성 콘텐츠
본 콘텐츠는 r/LocalLLaMA의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기