요즘 로컬 AI (Local AI) 구동에 대해 이야기할 때, 대화는 보통 RTX Spark와 같은 미니 PC를 중심으로 돌아가거나, 홈 서버 및 터무니없이 비싼 전문가용 GPU에 대한 아쉬운 상상으로 흘러가곤 합니다. 그런데 제 생각에, 꽤 오랫동안 본 가장 인상적인 AI 하드웨어 트릭은 방금 괜찮은 버거 하나 값도 안 되는 실리콘 조각 위에서 일어났습니다. 지난주, GitHub에서 'slvDev'라는 이름으로 활동하는 우크라이나 개발자 Slava S가 ESP32-AI라는 프로젝트를 공개했습니다. 이것은 여러분이 생각하는 바로 그것입니다. 그는 2,890만 파라미터(parameter) 규모의 언어 모델을 ESP32-S3 마이크로컨트롤러(microcontroller) 상에서 완전히 온디바이스(on-device)로 로컬 구동하는 데 성공했습니다.

저희의 이전 보도 내용을 읽어보지 않으셨다면 말씀드리자면, 이 작은 칩인 ESP32-S3 보드는 컴퓨팅 세계 전체에서 가성비가 가장 뛰어난 제품 중 하나입니다. 미국에서는 보호 케이스가 포함된 제품을 20달러 미만으로 온라인에서 구할 수 있으며, 대부분의 지역에서 베어 보드(bare boards)는 10달러 미만으로 쉽게 구할 수 있습니다. 이토록 저렴한 칩에서 예상할 수 있듯이, 성능이 강력하지는 않습니다. 이 변형 모델인 S3의 경우, 정확히 512KB의 SRAM, 8MB의 PSRAM, 그리고 16MB의 플래시 메모리(flash memory)를 제공하는데, 이는 전혀 많은 양의 메모리가 아닙니다. 그렇다면 스마트폰으로 찍은 원본 사진 한 장보다도 주 저장 공간이 적은 칩에 어떻게 거의 3,000만 파라미터에 달하는 모델을 밀어 넣을 수 있었을까요?

일반적으로 LLM (Large Language Model)을 구동하려면, 프로세서가 다음 단어를 생성하기 위해 모든 파라미터(parameter)를 대상으로 끊임없이 연산을 수행해야 하므로 모델 전체가 시스템의 빠른 메모리(fast memory)에 위치해야 합니다. 만약 2,900만 파라미터 모델을 ESP32에서 일반적인 방식으로 실행하려고 한다면, 즉시 빠른 RAM (Random Access Memory)이 부족해질 것입니다. X에서 Slava가 직접 지적했듯이, 이와 같은 칩의 이전 기록은 Dave Bennett라는 인물이 달성한 약 260,000 파라미터였습니다.

A diagram showing that the same architecture from big Google AI models can be used on a low-end machine.

Slava의 기술은 메모리 효율성을 획기적으로 개선하기 위해 Google이 자신의 "빅 아이언 (big iron)" 서버에서 사용하는 것과 동일한 방법을 사용합니다. (이미지 출처: Slava S./X)

이 영리한 해커는 Google의 Gemma에서 사용되는 Per-Layer Embeddings라는 뛰어난 아키텍처 트릭을 빌려와 이 병목 현상을 해결했습니다. 그는 모델을 4비트(4-bit)로 양자화(quantization)하여 전체 파일 크기를 단 14.9MB로 줄였고, 데이터가 저장되는 위치를 변경했습니다. 모델 전체를 아주 작은 512KB SRAM (Static Random Access Memory)이나 그보다 약간 더 큰 8MB PSRAM (Pseudo Static Random Access Memory)에 억지로 밀어 넣는 대신, 2,500만 파라미터의 임베딩 테이블(embedding table)을 상대적으로 느린 16MB 플래시 메모리(Flash memory)에 저장했습니다. 이 특정 모델 아키텍처는 토큰당 이 테이블에서 단 몇 개의 행(row)만 가져오면 되기 때문에, 플래시 메모리 고유의 느린 속도가 프로세서를 저해하지 않으며, 결과적으로 512KB의 빠른 SRAM은 실제 추론 가중치(reasoning weights)인 "사고 핵심 (thinking core)"만을 위해 비워둘 수 있게 되었습니다.

잠시만 속도를 늦춰봅시다. 누군가는 벌써 자신의 서버를 8달러짜리 칩으로 교체할 수 있을지 궁금해하고 있을 테니까요. 그가 사용한 모델은 TinyStories 데이터셋으로 학습되었으며, 이는 사실 소형 언어 모델 (SLM, Small Language Model), 혹은 솔직히 말해

솔직히 말해서, 우리가 "AI"에 대해 이야기할 때, 모든 것은 당신이 무엇을 달성하려고 하는지에 달려 있습니다. 간단히 말해, 작업 부하 (workload)를 명시하지 않고 로컬 AI를 위해 얼마나 많은 하드웨어가 필요한지 묻는 것은, 목적이 무엇인지 말하지 않고 어떤 탈것이 필요한지 묻는 것과 같습니다. 자전거, 세단, 픽업트럭, 세미트레일러, 그리고 기차는 모두 "A 지점에서 B 지점으로 이동"하게 해주지만, 이들은 근본적으로 다른 작업을 위해 만들어졌습니다. AI도 정확히 마찬가지입니다. 당신이 AI로 무엇을 하느냐가 필요한 하드웨어의 양을 결정합니다.

Screenshots of Dragon Warrior and Final Fantasy for the 8-bit NES showing character names generated by AI.

이미지로 시연하기는 어렵지만, 여기 Dragon Warrior (왼쪽)와 Final Fantasy (오른쪽) 스크린샷에 등장하는 캐릭터 이름들은 NES에서 직접 AI로 생성되었습니다. (이미지 출처: erodola / GitHub)

(https://github.com/erodola/bigram-nes)

이 점을 설명하기 위해, 작년에 또 다른 개발자가 NES의 오리지널 _Dragon Warrior_와 Final Fantasy 게임에 AI 언어 모델(바이그램(bigram) 이름 생성기)을 밀어 넣은 프로젝트를 공개했습니다. 네, 닌텐도 엔터테인먼트 시스템 (NES) 말입니다. 개발자 Emanuele Rodolà는 전체 모델 가중치 테이블(729 바이트)과 추론 (inference) 코드(직접 작성한 어셈블리 약 140 바이트)를 오리지널 게임 ROM에 집어넣어, 새로운 캐릭터 이름을 즉석에서 생성하는 데 성공했습니다. 이것이 바로 1975년으로 거슬러 올라가는 실리콘 조각인 MOS 6502 프로세서에서 실행되는 진짜 AI입니다.

slvDev 프로젝트가 주는 궁극적인 시사점은 Per-Layer Embeddings (계층별 임베딩) 기술이 대부분의 사람들이 상상했던 것보다 훨씬 더 낮은 사양까지 확장 가능하다는 것이며, 이는 AI 서버를 위한 계층형 저장 매체로서 최근 고대역폭 플래시 (High-Bandwidth Flash)에 대한 열풍에 신빙성을 더해줍니다. 이것이 흥미로운 이유는 ESP32가 여러분의 데스크톱 GPU를 대체한다는 의미가 아니라, 동일한 아키텍처 아이디어가 아주 작은 임베디드 장치부터 데이터센터 가속기(datacenter accelerators)에 이르기까지 하드웨어의 전 범위에 걸쳐 AI를 극적으로 더 실용적으로 만들 수 있음을 시사하기 때문입니다.