slvDev/esp32-ai 딥다이브
— 8달러짜리 마이크로컨트롤러 위에서 28.9M 파라미터 LLM을 돌리는 법

1프로젝트 한 줄 요약

스마트폰의 두뇌인 SoC조차 버거워하는 LLM을, 이 프로젝트는 냉장고 온도 센서에나 들어갈 법한 $8짜리 칩 ESP32-S3 위에서 돌린다. 모델은 TinyStories라는, 3~4세 아이도 이해할 수준의 짧은 영어 동화 데이터로 학습됐다. 그래서 이 모델은 질문에 답하거나 지식을 말하거나 코드를 쓰지는 못한다. 대신 "옛날 옛적에…"로 시작하는 짧고 일관성 있는 이야기를 스스로 지어낸다.

중요한 건 모델이 무슨 말을 하느냐가 아니라, 어떻게 그 큰 덩치가 그 작은 칩에 들어갔느냐다. ESP32-S3의 빠른 내부 메모리(SRAM)는 고작 512KB. 보통은 모델 전체가 여기에 들어와야 하니 지금까지 이런 칩에 올린 모델은 26만 파라미터가 한계였다. 이 프로젝트는 그 벽을 "모델을 빠른 메모리에 다 넣지 않는다"는 발상으로 넘어, 2,890만 파라미터를 앉혔다.

2왜 주목받는가 — 물리 한계를 우회하는 발상

"작은 칩에 큰 모델"이라는 주제는 늘 인기지만, 이 레포가 트렌딩에 오른 건 단순한 데모가 아니라 진짜 과학이기 때문이다. 네 가지 결이 겹친다.

① 물리적 한계를 정면돌파가 아니라 '우회'로 뚫었다

더 빠른 칩을 사거나 모델을 무조건 줄이는 대신, 메모리의 성질이 저마다 다르다는 점을 이용했다. 언어모델 파라미터의 대부분은 계산에 쓰이는 게 아니라 단순히 찾아보는 표(embedding table)다. 그 표는 토큰마다 딱 몇 줄만 읽으면 되니, 굳이 빠른 메모리에 둘 필요가 없다. "느린 flash에 둬도 되는 것"과 "빠른 SRAM에 꼭 둬야 하는 것"을 가른 것이 이 프로젝트의 전부다.

② 정직한 과학 — 자기 실수까지 커밋에 남겼다

주장을 검증하는 방식이 놀랍도록 성실하다. PLE가 baseline보다 나은지 2개 시드로 재현했고, 4-bit로 압축해도 이득이 살아남는지 따로 측정했으며, C로 짠 추론기가 PyTorch 원본과 3만 2768개 logit 전부에서 최대오차 0.00001로 일치함을 하드웨어에 올리기 전에 확인했다. 심지어 저자는 초기 파라미터 계산 버그로 숫자를 부풀렸던 이력과 그걸 고친 결과를 일부러 저장소에 남겨 뒀다.

③ "$8 칩" 서사 — 엣지 AI의 상상력을 자극한다

클라우드도, GPU도, 인터넷 연결도 없이 몇 달러짜리 부품이 스스로 문장을 만든다는 그림은 완전한 오프라인·프라이버시 보존 AI의 원형을 보여준다. 데이터가 칩 밖으로 한 바이트도 나가지 않는다. 이 서사가 개발자 커뮤니티(특히 임베디드·IoT 진영)를 자극했다.

④ Karpathy llama2.c의 계보 — "plain C로 돌린다"는 감성

저자는 Andrej Karpathy의 llama2.c(순수 C로 작은 LLM을 돌리는 프로젝트)가 "작은 언어모델을 직접 학습해 C로 돌릴 수 있다"는 믿음을 준 계기였다고 밝힌다. 무거운 프레임워크 없이 바닥부터 직접 짠다는 이 문화적 계보가, 같은 감성을 공유하는 개발자들에게 매력적으로 다가온다. (단, 저자는 코드·방법이 llama2.c에서 파생된 건 아니라고 명확히 선을 긋는다 — 비교 맥락일 뿐이다.)

3기술 스택 전체 지도

이 저장소는 완전히 다른 두 파이프라인이 한 몸으로 붙어 있다. 하나는 데스크톱에서 모델을 학습·양자화·검증하는 Python(PyTorch) 세계이고, 다른 하나는 그 결과물을 칩 위에서 실제로 돌리는 C(Arduino) 세계다. 둘을 잇는 다리가 export.py가 뽑는 납작한 바이너리(model.bin)와, 호스트와 칩에서 같은 코드가 도는 단일 헤더 llm.h다.

학습 쪽 의존성 (pyproject.toml — Python 3.12, uv 패키지 매니저)

# name = "esp32-llm"  ·  requires-python = ">=3.12"
numpy      >=2.5.1     # 토큰 bin(memmap) 처리
requests   >=2.34.2    # TinyStories 데이터 다운로드
tokenizers >=0.23.1    # BPE 토크나이저 학습
torch      >=2.13.0    # 모델 학습/양자화/golden 생성
tqdm       >=4.69.0    # 진행 표시

4아키텍처 심화 분석 — 3단 메모리 회계와 PLE

이 프로젝트의 모든 것은 파라미터를 세 종류로 나누는 것에서 출발한다. 기준은 "얼마나 빠른가"가 아니라 "어떻게 접근되는가(access pattern)"다. 이 3단 분류가 칩의 3단 메모리(SRAM·PSRAM·flash)에 그대로 대응된다.

왼쪽이 하드웨어, 오른쪽이 모델이다. 셋을 짝지은 게 설계의 전부다. 여기서 제일 반직관적인 결정은 출력 head를 'core'에서 뺀 것이다. head는 매 토큰마다 전부 읽히지만 처음부터 끝까지 순차로 훑을 뿐이라, 용량이 아니라 대역폭만 잡아먹는다. 이걸 core에 넣어버리면 큰 어휘(vocab)가 감당 불가로 보이지만, 사실은 "느릴 뿐"이다. 이 구분이 큰 어휘 → 값싼 표라는 전체 전략을 가능하게 한다.

PLE(Per-Layer Embeddings)가 실제로 하는 일

PLE는 구글이 Gemma 3n / Gemma 4에서 쓴 기법이다. 보통 트랜스포머는 토큰을 입력에서 한 번만 임베딩하지만, PLE는 레이어마다 그 토큰 전용의 추가 정보를 주입한다. 그 "레이어별 추가 정보"가 바로 flash에 사는 거대한 표(ple_table)에서 온다. 토큰이 정해지면 각 레이어에 뿌릴 조각을 표에서 꺼내(랜덤 읽기 몇 줄), 레이어 내부에서 곱셈으로 게이팅한다.

// src/model.py — PLE 입력 조립 (설명용으로 단순화)
ple = ple_model_proj(x) * (d_model ** -0.5)        # ① 맥락 인지: 토큰 임베딩을 레이어별로 투영
ple = ple_proj_norm(ple.view(B,T, n_layers, ple_dim))
table = ple_table(idx) * (ple_dim ** 0.5)          # ② flash 표에서 토큰별 행을 꺼냄
ple = (ple + table) * (2 ** -0.5)                   # ③ 둘을 합쳐 각 레이어로 배분

// 각 레이어(Block) 안에서 게이팅 — 곱셈이라 서로를 억제할 수 있음
g = gelu(ple_gate(x))
x = x + ple_norm(ple_proj(g * ple_layer))          # 단순 편향이 아니라 '조건부' 주입

나머지 모델 본체는 요즘 LLM의 표준 부품으로 짜였다: 디코더-온리 트랜스포머, 정규화는 RMSNorm, 위치 인코딩은 RoPE(split-half), FFN은 SwiGLU, 입력·출력 임베딩은 묶음(tied). 배포 설정은 어휘 32768 · d_model 96 · 6개 레이어 · ple_dim 128이고, 계산 코어는 559K로 512KB SRAM에 들어가도록 크기를 맞췄다.

5디렉토리 구조 해부

파일 수는 적지만(핵심 소스 ~1,800줄) 역할 분담이 또렷하다. src/는 파이토치 학습·양자화·export, firmware/는 C 추론과 온칩 배포, experiments/는 밤새 돌리는 실험 큐, data/는 데이터 준비다. "학습 → 양자화 → export → 호스트 검증 → 칩 flash"라는 파이프라인이 폴더 순서에 그대로 담겨 있다.

6학습 포인트

① 메모리 계층을 '아키텍처'로 다루는 법

가장 값진 교훈. 파라미터를 접근 패턴(dense-every-token / sequential-scan / sparse-lookup)으로 나누고, 각각을 맞는 메모리 층에 배치하는 사고방식이다. budget.py는 이 회계를 코드로 보여주고, "출력 head를 core에서 빼는" 한 줄의 결정이 어떻게 큰 어휘를 가능케 하는지 드러낸다. 임베디드가 아니어도, "무엇을 어디에 두는가"가 모델 설계의 일부라는 관점을 얻는다.

② Per-Layer Embeddings(PLE)를 코드로 이해하기

논문·블로그로만 접하던 Gemma의 PLE를, model.py의 60줄 남짓으로 직접 읽을 수 있다. "레이어별 표 lookup + 게이팅"이 실제 텐서 연산으로 어떻게 조립되는지, embed_scale(sqrt(ple_dim))처럼 문서에 안 적힌 결정적 디테일이 어디서 곱해지는지까지 주석으로 짚어 준다.

③ 정직한 ablation 실험 설계

"PLE가 좋다"를 어떻게 공정하게 증명하는가. 이 레포는 모든 arm의 계산 코어 크기를 이진 탐색으로 똑같이 맞추고(안 그러면 그냥 FFN 큰 놈이 이김), 2개 시드로 노이즈 대비 효과 크기를 재고, ple_notable(표 없는 PLE 배관)·fatembed(같은 표 예산을 입력에 몰아줌)·bigcore(표 예산을 코어 확장에)라는 대조군으로 "이득의 출처가 정확히 표"임을 격리한다. 실험을 설계하는 사람이라면 반드시 볼 예제다.

④ 엣지 양자화 — 무엇이 4비트를 잘 견디나

quantize.py는 그룹별 대칭 int4 PTQ를 구현하고, 거대한 표까지 포함해 전부 양자화한 뒤 품질을 다시 잰다. 배우는 것: 왜 작은 dense 모델은 4비트에 취약하고(모든 가중치가 중요), 중복 많은 큰 표는 4비트에 강한가. "flash 예산을 건 그 부분이 하필 가장 압축에 강하더라"는 결과가, 왜 QAT 없이도 되는지를 설명한다.

⑤ 포터블 C 추론 — 한 코드로 호스트와 칩 둘 다

firmware/common/llm.h(385줄)는 동적 아키텍처 없이 모델 헤더에서 차원을 읽어 동작하는 단일 헤더 추론기다. 같은 코드를 호스트에서 컴파일해 PyTorch golden과 대조(1e-5 일치)한 뒤, 글자 하나 안 바꾸고 ESP32로 컴파일한다. "칩에 올리기 전에 정확성을 완전히 못박는" 방법론의 정석이다.

⑥ 온칩 성능 엔지니어링 — 병목을 옮겨 가며 최적화

RESULTS.md의 온칩 섹션은 0.57 → 9.5 tok/s까지의 최적화 여정을 단계별 수치로 기록한다. head를 PSRAM에 int8로 미리 펼치고, 활성값도 int8로 양자화해 토큰당 언패킹을 없애고, 두 코어(LX7)에 출력 행을 나눈다. 결국 head가 계산이 아니라 PSRAM 대역폭에 묶인다는 걸 프로파일로 증명하고, "여기서 더 빨라지려면 SIMD가 아니라 읽는 바이트 자체를 줄여야 한다"는 결론에 도달한다. 실전 프로파일링 사고의 표본이다.

7하드웨어 / 시스템 요구사항

칩 — ESP32-S3-DevKitC-1 N16R8 (실제 사용 보드)

flash 파티션 배치 (partitions.csv)

# Name,   Type, SubType,  Offset,    Size
factory,  app,  factory,  0x10000,   0x100000   # 619KB 애플리케이션 (1MB 파티션)
model,    data, 0x40,     0x110000,  0xEE0000    # 14.9MB 모델 (15.6MB 커스텀 파티션)
# 모델 payload는 새로 export 할 때만 다시 flash. 펌웨어만 고치면 재업로드 불필요.

학습 쪽 요구사항

온칩 성능 — 최적화 단계별 실측 (200토큰 평균)

현재 런타임 프로파일(토큰당, 듀얼코어 wall): head 57.6 · attn 25.6 · PLE 8.5 · FFN 6.9 · 입력 4.4 ms. head가 토큰당 int8 가중치 2.43MB를 읽어 60.7MB/s에서 ~40ms 대역폭 바닥에 묶인다. 여기서 더 빨라지려면 SIMD가 아니라 읽는 바이트를 줄이는 방향(int4 head + SIMD 언패킹)이나 더 작은 head(모델 변경)가 필요하다.

8직접 해볼 수 있는 실습 과제

9관련 기술 심화 학습 로드맵

10핵심 키워드 사전

11참고 링크

• GitHub 저장소: github.com/slvDev/esp32-ai (Python + C · 30 커밋 · 분석 시점 183 stars)
• TrendShift: trendshift.io/repositories/91619 (2026-07-25 Daily #6)
• 핵심 소스: src/model.py(모델·5 arm) · src/budget.py(3단 회계) · src/quantize.py(int4 PTQ) · firmware/common/llm.h(포터블 C 추론) · RESULTS.md(전체 방법·실측)
• 온칩 배포 가이드: firmware/esp32_llm/README.md (arduino-cli·esptool·파티션·부팅 진단)
• 배경 기술 — TinyStories: arXiv:2305.07759 (Ronen Eldan & Yuanzhi Li, Microsoft Research)
• 배경 기술 — Gemma / PLE: ai.google.dev/gemma (Per-Layer Embeddings 원 설계)
• 계보(비교 맥락): karpathy/llama2.c (순수 C 소형 LLM) · DaveBben의 esp32-llm(260K 파라미터, 이전 사례)