한줄 요약
8달러 마이크로컨트롤러에서 2,890만 파라미터 LLM을 서버 없이 구동하는 데 성공했다.
단 8달러짜리 ESP32-S3 칩 위에서 2,890만 파라미터 언어 모델이 초당 약 9.5 토큰을 생성한다. 외부 서버에 아무것도 보내지 않는다. 작은 화면에 직접 텍스트를 출력하고, 추론 전체가 칩 안에서 완결된다. 이 프로젝트가 흥미로운 이유는 모델의 언어 능력 때문이 아니라, 극단적으로 제약된 하드웨어에서 대형 모델을 구동하는 아키텍처 접근법 때문이다.
무엇이 달라지나?
기존에 ESP32급 마이크로컨트롤러에서 실행 가능한 언어 모델의 한계는 약 26만 파라미터였다. 이번 프로젝트는 그보다 약 100배 많은 파라미터를 같은 칩에서 돌리는 데 성공했다.
핵심은 메모리 계층 구조를 완전히 다르게 활용한 것이다. ESP32-S3은 고속 SRAM이 512KB에 불과하다. 기존 방식으로는 모델 전체가 이 SRAM 안에 들어가야 했기 때문에 파라미터 수가 심각하게 제한됐다. 이 프로젝트는 구글 Gemma 3n과 Gemma 4에서 도입한 Per-Layer Embeddings(PLE) 기법을 마이크로컨트롤러 환경에 이식해 이 문제를 우회했다.
언어 모델 파라미터의 대부분은 임베딩 테이블에 몰려 있다. 이 테이블은 '계산'보다는 '조회'에 가깝게 쓰인다. 2,890만 파라미터 중 2,500만 개가 이 임베딩 테이블에 해당하고, 이를 느리지만 용량이 큰 플래시 메모리에 올려둔다. 실제 추론 시에는 토큰당 약 450바이트만 플래시에서 읽어온다. 실제 연산을 담당하는 코어는 고속 SRAM에 유지하고, 중간 작업 메모리와 출력 헤드는 PSRAM을 쓴다.
SRAM (고속, 512KB), 추론 코어, 매 토큰마다 사용
PSRAM (중간), 출력 헤드 및 작업 메모리
FLASH (대용량, 저속), 2,500만 파라미터 임베딩 테이블, 토큰당 ~450B 읽기
모델은 4비트 양자화 기준 14.9MB 크기로, 16MB 플래시에 수납된다. 구글이 스마트폰과 GPU를 위해 설계한 아이디어가 마이크로컨트롤러에서 작동한다는 것 자체가 이 프로젝트의 기술적 가치다.
실무에서 어떤 의미인가?
이 프로젝트가 곧바로 프로덕션 AI 제품을 의미하지는 않는다. 모델은 TinyStories 데이터셋으로 훈련됐고, 짧고 단순한 이야기를 생성하는 수준이다. 질문 응답, 명령 수행, 코드 생성, 팩트 조회는 현재 이 모델의 영역 밖이다. 파라미터 수가 늘었어도 실제 추론을 담당하는 코어 부분의 크기는 여전히 제한적이기 때문이다.
그러나 엣지 AI 개발자나 IoT 제품을 설계하는 입장에서 이 결과는 시사점이 크다. 지금까지 "서버 없이는 언어 모델이 불가능하다"는 전제로 설계된 제품 아키텍처가 많다. 이 프로젝트는 그 전제에 균열을 낸다. 클라우드 의존 없이 기기 자체에서 텍스트 생성이 필요한 시나리오, 예컨대 오프라인 환경의 임베디드 UI나 네트워크 없이 동작해야 하는 필드 디바이스에서 PLE 기반 아키텍처가 현실적인 선택지가 될 수 있다.
또한 이 접근법은 외주 개발이나 하드웨어 스타트업 맥락에서도 검토할 만하다. 고가의 NPU나 전용 AI 칩 없이 범용 MCU로 온디바이스 언어 생성을 구현할 수 있다면, 하드웨어 BOM 비용과 시스템 복잡도를 상당히 낮출 수 있다.
도입 전 체크포인트
이 아키텍처가 실제 제품에 적용 가능한지 판단하려면 몇 가지 기준을 먼저 확인해야 한다.
모델 능력의 한계를 명확히 인식해야 한다. 현재 구현은 텍스트 생성에 특화돼 있고, 범용 언어 이해와는 거리가 있다. 제품이 요구하는 언어 기능이 이 수준에서 충족되는지 먼저 검토해야 한다.
플래시 읽기 레이턴시가 병목이 될 수 있다. 토큰당 플래시에서 데이터를 읽어오는 구조이므로, 초당 토큰 수는 플래시 속도에 직접 영향을 받는다. 응답 속도가 UX에 중요한 제품이라면 이 부분의 측정이 선행돼야 한다.
4비트 양자화의 품질 손실을 감수해야 한다. 14.9MB라는 크기 자체가 4비트 양자화의 결과다. 생성 품질이 중요한 사용 사례라면 품질 저하 정도를 실험적으로 확인해야 한다.
