손톱만 한 8달러짜리 칩에서 언어 모델이 스스로 문장을 만들어낸다. 개발자 slvDev가 공개한 esp32-ai 프로젝트는 2,890만 파라미터 규모의 언어 모델을 ESP32-S3 마이크로컨트롤러 위에서 직접 구동한다. 서버로 아무것도 보내지 않고 칩 자체에서 연산이 이뤄지며, 칩에 연결된 작은 화면에 초당 약 9토큰 속도로 단어를 하나씩 써 내려간다. 이전까지 이런 급의 칩에서 돌린 언어 모델은 26만 파라미터 수준이었으니, 규모가 약 100배로 뛴 셈이다. 흥미로운 지점은 모델이 무엇을 말하느냐가 아니라, 이렇게 큰 모델이 어떻게 이토록 작은 칩에 들어갈 수 있었느냐다.
왜 지금까지는 작을 수밖에 없었나
마이크로컨트롤러의 근본적 제약은 빠른 메모리가 극히 적다는 데 있다. ESP32-S3가 제공하는 SRAM은 512KB에 불과하다. 통상적인 추론 방식에서는 모델 전체가 이 빠른 메모리에서 접근 가능해야 하고, 그래서 실을 수 있는 모델 크기가 SRAM 용량에 묶여버린다. 26만 파라미터라는 이전 기록은 기술적 게으름의 결과가 아니라 이 물리적 한계에서 나온 숫자였다. 아무리 압축하고 양자화해도 모델 전체를 512KB 안에 넣어야 한다는 전제 자체를 깨지 않으면 벽을 넘을 수 없었다.
이 프로젝트가 택한 해법은 전제를 뒤집는 것이다. 즉 모델을 애초에 빠른 메모리에 올리지 않는다. 언어 모델의 파라미터 대부분은 임베딩 테이블에 몰려 있는데, 이 부분은 모델이 계산에 쓰는 것이 아니라 단지 읽어 오는 참조 데이터에 가깝다. 그래서 2,500만 행에 달하는 이 거대한 테이블을 느린 플래시 메모리에 그대로 남겨두고, 토큰 하나를 처리할 때 필요한 몇 개 행, 약 450바이트만 뽑아 온다. 실제 연산을 담당하는 작은 부분만 빠른 메모리에 상주시키는 것이다. 결과적으로 큰 모델은 실행 비용이 거의 들지 않는다. 대부분을 아예 로드하지 않은 채 플래시에 놔두고 조금씩만 샘플링하기 때문이다.
구글 Gemma의 아이디어를 칩 크기로 옮기다
이 발상은 구글이 Gemma 3n과 Gemma 4에서 도입한 'Per-Layer Embeddings'라는 설계에서 왔다. 원래는 스마트폰이나 GPU의 메모리 구조를 겨냥한 기법인데, 이번에는 그것을 마이크로컨트롤러의 메모리 레이아웃 위에서 구현했다. 개발자 본인의 확인으로는 이만큼 작은 칩에 이 기법을 적용한 시도는 지금까지 없었다. 요약하면 큰 모델을 작은 칩에 넣을 수 있게 한 것은 Per-Layer Embeddings이고, 그 위에서 학습이 가능하도록 뒷받침한 것은 데이터셋 선택이다.
학습에는 마이크로소프트 리서치의 Ronen Eldan과 Yuanzhi Li가 만든 TinyStories(arXiv:2305.07759)가 쓰였다. 작은 모델도 일관성 있는 글쓰기를 배울 수 있을 만큼 단순하게 합성된 짧은 이야기 모음이다. 그 덕에 이 모델은 짧고 단순한 이야기를 쓰며 대체로 앞뒤가 맞는 문장을 이어간다. 또한 이런 종류의 초소형 언어 모델을 순수 C 코드로 학습하고 구동할 수 있다는 믿음 자체가 안드레이 카파시의 llama2.c에서 비롯됐고, 이 프로젝트도 그 계보 위에서 자라났다고 저자는 밝힌다.
실무자가 기대치를 어디에 둬야 하는가
한계는 분명하다. 이 모델은 질문에 답하거나 지시를 따르거나 코드를 쓰지 못하고 사실 지식도 갖고 있지 않다. 이 제약은 실제 추론을 담당하는 작은 부분의 용량에서 오는 것이며, 메모리 기법으로는 바뀌지 않는다. 다시 말해 Per-Layer Embeddings는 임베딩 테이블을 값싸게 다루게 해줄 뿐, 모델의 '생각하는' 능력 자체를 키우지는 않는다. 온디바이스 AI를 검토하는 실무자라면 이 구분을 명확히 새겨야 한다. 파라미터 수가 100배로 늘었다는 헤드라인이 곧 100배 똑똑해진 모델을 뜻하지는 않는다.
그럼에도 이 작업이 던지는 실무적 함의는 작지 않다. 임베딩처럼 '읽기 전용에 가까운' 파라미터와 실제 연산에 관여하는 파라미터를 분리해, 전자는 저렴한 대용량 저장소에, 후자는 값비싼 고속 메모리에 배치하는 계층화 전략은 극단적으로 제약된 엣지 환경 설계에 그대로 응용할 수 있다. 메모리가 병목인 IoT·임베디드 환경에서 모델 크기의 상한을 SRAM이 아니라 플래시 용량으로 옮겨 놓는다는 발상 자체가 참고할 만하다.
검증 가능성 측면에서도 이 저장소는 눈여겨볼 만하다. 저자는 파라미터 집계에서 스스로 발견한 버그와, 그것을 수정한 뒤 나온 정정된 수치를 커밋 히스토리에 일부러 남겨두었다고 밝혔다. 초기 숫자가 어떻게 부풀려졌고 어디서 어떻게 바로잡혔는지를 커밋 기록과 RESULTS.md에서 추적할 수 있다. 펌웨어와 배선, 플래싱 절차는 firmware/esp32_llm/README.md에, 학습·어블레이션·양자화 코드는 src/와 experiments/에 정리돼 있어, 관심 있는 엔지니어가 방법론과 온칩 측정치를 직접 확인하고 재현해 볼 수 있는 형태로 공개돼 있다.