7개의 ESP32-S3 보드를 SPI로 연결하고, 그 위에서 0.5B 파라미터 LLM을 레이어 단위로 나눠 실행하는 오픈소스 프로젝트가 공개됐다. 마스터 노드가 토크나이저와 임베딩을 담당하고, 6개 컴퓨트 노드가 트랜스포머 블록을 4레이어씩 나눠 처리한 뒤 결과를 다시 마스터로 돌려보내는 구조다. 양자화 방식은 1.58비트 터너리(BitNet)로, 각 가중치를 -1, 0, 1 세 값으로만 표현한다.
HackerNews에서 이 프로젝트가 주목받은 이유는 분명하다. "MCU에서 LLM이 돌아간다"는 명제 자체가 몇 년 전까지는 성립하지 않았기 때문이다. 하지만 CTO나 개발 리드 입장에서 이 프로젝트가 던지는 진짜 질문은 따로 있다. 우리 제품의 요구사항에서 이 구조가 클라우드 API나 단일 엣지 컴퓨팅 장치보다 나은 선택인가.
기술 구조를 먼저 있는 그대로 읽어야 한다
판단 기준으로 쓰려면 각 설계 선택이 어떤 트레이드오프를 수반하는지 먼저 확인해야 한다.
임베딩 테이블은 INT4로 플래시에 약 14MB를 차지하고, KV 캐시는 PSRAM에 올라간다. 1.58비트 양자화는 모델 크기를 극단적으로 줄이지만, 이 수준의 양자화를 적용한 모델이 원본 FP32 모델 대비 어떤 정확도를 보이는지는 태스크마다 다르고, 이 프로젝트 자체에서 정확도 벤치마크를 제공하지는 않는다.
노드 간 통신은 SPI 데이지체인으로 이뤄진다. 고속 SPI라도 레이어 경계마다 히든 스테이트 벡터를 FP32로 직렬 전송하는 구조는 전체 추론 속도에서 통신 지연이 상당 비중을 차지할 수 있다. 토큰당 생성 속도가 실제로 어느 수준인지, 전력 소비가 얼마나 되는지 프로젝트 문서는 수치를 공개하지 않는다.
요약하면, 이 프로젝트는 가능성의 증명이지 제품 배포를 위한 검증된 플랫폼이 아니다.
클라우드 API와 비교할 때 실제로 달라지는 것
클라우드 LLM API는 추론 품질과 모델 크기 면에서 MCU 클러스터와 비교가 되지 않는다. 네트워크 연결이 안정적이고, API 응답 지연이 서비스 요구사항 안에 들어오고, 데이터를 외부로 내보내는 것이 법적·운영적으로 허용된다면, 클라우드 API가 거의 모든 면에서 더 단순하고 강력하다.
로컬 추론이 의미를 갖는 경우는 구체적이다. 네트워크 연결 자체가 없거나 불안정한 환경, 개인 식별 정보나 산업 기밀이 포함된 데이터를 외부로 내보낼 수 없는 규제 조건, 응답 지연이 수백 밀리초 단위로 제어되어야 하는 실시간 제어 루프. 여기에 더해 클라우드 통신 비용이 누적 규모에서 하드웨어 비용을 초과하는 배포 시나리오도 있다.
그런데 이 조건 중 하나라도 해당된다면, 다음 질문은 "ESP32-S3 클러스터냐 클라우드냐"가 아니라 "ESP32-S3 클러스터냐 단일 엣지 디바이스냐"가 된다.
Raspberry Pi나 NPU 내장 SoC와 비교할 때 선택 기준
네트워크 없는 로컬 추론이 필요하다는 결론이 나왔다고 가정하자. Raspberry Pi 5나 NPU를 내장한 SoC는 ESP32-S3 클러스터 대비 훨씬 큰 모델을 더 빠르게, 더 단순한 아키텍처로 실행할 수 있다.
ESP32-S3 클러스터가 단일 엣지 보드보다 경쟁력을 갖는 조건은 훨씬 좁다.
첫째, 단가와 수량 제약이 동시에 작용할 때다. 대량 배포에서 장치당 비용을 극단적으로 낮춰야 하고, 각 장치가 처리해야 할 AI 태스크가 0.5B 이하 모델로 해결 가능한 수준일 때만 이 조합이 경제적으로 성립한다.
둘째, 공간·전력 제약이 단일 고성능 SoC를 배제할 때다. 다만 7개 노드를 연결한 클러스터가 단일 Raspberry Pi보다 폼팩터나 전력 면에서 실제로 유리한지는 직접 재보는 수밖에 없다. 프로젝트 문서에는 이에 관한 측정값이 없다.
셋째, 하드웨어 공급망과 팀 역량이 ESP32 생태계에 이미 있을 때다. ESP-IDF 기반 펌웨어 개발, BitNet 양자화 파이프라인, SPI 다중 채널 타이밍을 모두 다룰 수 있는 팀이라면 진입 장벽이 낮아진다.
시작하기 전에 팀 안에서 먼저 물어볼 항목들
이 구조를 프로토타입으로라도 진행하기 전에 아직 답이 없는 지점들이 있다.
태스크 정의가 먼저다. 0.5B 1.58비트 양자화 모델이 우리 제품에서 필요한 언어 이해 수준을 충족하는지는 실제 태스크로 측정해야 한다. 분류, 키워드 추출, 간단한 명령 해석 같은 좁은 태스크는 가능성이 있다. 복잡한 문맥 추론이나 긴 대화 유지가 필요한 태스크라면 모델 크기 자체가 병목이다.
지연 요구사항을 수치로 먼저 정해두어야 한다. 토큰당 생성 속도가 얼마나 되어야 사용자 경험이나 제어 루프에서 허용 가능한지 정의하지 않은 상태에서는 "빠른지 느린지" 판단할 수 없다. 이 프로젝트의 실제 추론 속도는 공개되어 있지 않으므로, 직접 재현하거나 유사 구현의 보고값을 참고해야 한다.
노드 장애 시나리오는 팀이 직접 설계해야 한다. 7개 노드 중 하나가 오작동하거나 SPI 링크에 오류가 생겼을 때 시스템이 어떻게 동작하는지, 이 프로젝트는 장애 대응 설계를 다루지 않는다.
QAT 파이프라인을 팀이 소화할 수 있는지도 짚어봐야 한다. 프로젝트는 Qwen 기반 모델을 1.58비트로 양자화 인식 훈련(QAT) 파인튜닝하는 Python 도구를 포함한다. 원하는 도메인에서 이 파이프라인을 돌리고 결과를 검증하는 능력이 팀에 없다면, 기본 제공 모델의 일반적인 언어 능력에 의존해야 하고, 그 수준이 제품 요구사항을 충족하지 못할 수 있다.
이 프로젝트가 실제로 바꾼 것과 아직 바뀌지 않은 것
바뀐 것은 하나다. MCU 클러스터에서 작은 LLM을 분산 실행하는 오픈소스 구현이 존재한다. 특정 극단적 제약 환경에서 출발점을 찾는 팀에게는 참조할 수 있는 아키텍처가 생겼다는 의미가 있다.
바뀌지 않은 것은 엣지 AI 아키텍처 선택의 기본 구조다. 모델 품질, 추론 속도, 전력, 비용, 운영 복잡도는 여전히 요구사항에서 시작해서 가장 단순한 구조로 먼저 풀어야 한다.
클라우드 API로 충분한 환경이라면 그쪽이 맞다. 로컬 추론이 필요하고 비용과 폼팩터가 Raspberry Pi 계열을 허용한다면 그쪽이 더 단순하다. ESP32-S3 클러스터가 진지하게 검토되는 시점은 위 두 경로가 닫혔을 때, 그리고 처리해야 할 태스크가 0.5B 모델 수준으로 해결 가능하다는 근거가 있을 때다.
그 조건이 맞는 팀이라면, 이 프로젝트는 직접 재현하고 자기 태스크로 검증할 가치가 있는 시작점이다.
