ESP32 LLM実装esp32-ai解説｜$8マイコンで28.9Mを動かすPer-Layer Embeddings

ESP32 LLMの実装として「$8のマイコンで28.9Mパラメータが動く」と話題になった slvDev/esp32-ai は、2026年7月25日のHacker News投稿で281ポイントを集め、英語圏のメディアが一斉に取り上げました。ただしこの見出しは、リポジトリの中身を読むとそのままの意味では受け取れないことが分かります。作者自身がRESULTS.mdに「能力の倍率として引用するな」と書いているからです。この記事では、公式リポジトリのコードとRESULTS.mdの実測記録だけを材料に、28.9Mという数字の内訳・Per-Layer Embeddingsが効く条件・実際に何が生成速度を決めているのかを順に分解します。

この記事はマイコン上でのLLM実行という極端なローカル実行事例として esp32-ai を扱います。LLMの仕組みやローカル実行・量子化の全体像は LLMとは？仕組み・主要モデル比較・ローカル実行・量子化を一気にまとめる2026年版 をご覧ください。

esp32-aiとは：ESP32 LLMを$8のESP32-S3でオンチップ実行する実験リポジトリ

esp32-aiは、マイコン1個の中だけで言語モデルを動かすことを目的にした実験リポジトリです。推論中はWi-Fiを使わず、サーバーへも何も送りません（READMEのスペック表でも Connectivity は none と書かれています）。GitHub APIとリポジトリの中身を確認すると、2026年7月28日時点で以下の状態でした。

READMEはボードの価格を「約$8」としています。英語メディアの一部は$10と表記していますが、本記事は一次情報であるREADMEの表記に従います。ボード価格はモデルや流通経路で変動する数字なので、厳密な単価というより「安価な汎用マイコンで成立する」という主張の目安として読むのが妥当です。

コミット履歴が示す「7日間」

31件のコミットは2026年7月20日から26日までの7日間に収まっています。並べ替えると、この期間に何が起きたかがそのまま読み取れます。

ここで注意したいのはMIT LICENSEの追加がHacker News投稿の約14時間後である点です。公開時点のコミット（9c4a214b）の中身を確認すると、LICENSE ファイルが無いだけでなく pyproject.toml に license の記載もなく、READMEにもライセンスへの言及がありませんでした。つまり公開からHN掲載までの数日間、このリポジトリには明示的なライセンス表示が存在しなかったことになります。その時期にクローンした場合は、再配布や派生物を検討する前に現在の LICENSE（MIT）を基準として確認しておくのが安全です。

何ができて、何ができないか

READMEは能力の限界を先に書いています。モデルはTinyStories——子ども向けの短い物語だけを集めた合成データセット（Eldan & Li, Microsoft Research）で学習されているため、書けるのは短い物語だけです。

・できる：短く単純な物語を、おおむね一貫性を保って生成する
・できない：質問に答える／指示に従う／コードを書く／事実を知っている

RESULTS.mdは、この天井が密なコア側で決まっており「メモリの工夫では動かない」と明記しています。つまりesp32-aiが示したのは「マイコンで賢いAIが動く」ことではなく、大きなモデルを小さなチップへ載せるためのメモリ設計です。読む側もそこを取り違えないほうが、この成果を正しく評価できます。

「28.9Mパラメータ」の正体：3層メモリ会計をbudget.pyから再計算する

この記事で最初に確かめたいのが、28.9Mという数字の内訳です。リポジトリには src/budget.py という、報告専用の3層メモリ会計モジュールが独立して置かれています。コメントには「このファイルは報告するだけ」と書かれ、学習側の予算計算（model.py の param_budget()）とは意図的に切り離されています。

budget.py の分類は「速いか遅いか」ではなく、毎トークンどう読むかで切られています。

・core：密で、毎トークン全体をランダムアクセスする。SRAMに置くしかない。本当に希少な予算
・stream：密だが、毎トークン先頭から末尾へ1回だけシーケンシャルに走査する。出力ヘッドがこれに当たる。消費するのはSRAM容量ではなく帯域
・table：疎。毎トークン1行だけ引く。メモリマップされたフラッシュに最適

budget.py のコメントは、この分類が生まれた理由をこう書いています——streamをcoreと同じものとして扱ってきたことが、大きな語彙を「使えない」ように見せていた。実際には単に遅いだけだった、と。

実際に電卓を入れて確かめる

budget.py の tiers() 関数の式に、firmwareのREADMEが示す起動時診断のパラメータ（V=32768 D=96 L=6 H=4 F=66 P=128）を代入すると、次のようになります。

合計28,867,968＝28.87M。READMEの「28.9M」と一致します。表の12.0MBもRESULTS.mdの「25M-param PLE table (12MB flash)」と一致し、エクスポートされた実ファイル（14,912,332バイト＝14.9MB）とも整合します。

coreだけはRESULTS.mdの表記（ple = 558K）とわずかにずれますが、これは budget.py の式がRMSNormの重みを数えていないためです。model.py を見ると、各ブロックに attn_norm / ffn_norm / ple_norm の3つ（各96要素）、モデル側に ple_proj_norm（128要素）と out_norm（96要素）があります。6ブロック×288＋224＝1,952を足すと556,416＋1,952＝558,368となり、RESULTS.mdの558Kに一致します。

「フラッシュに大きな表を置く」という発想自体は、モデル圧縮の文脈でも繰り返し登場します。量子化でモデル本体を小さくするアプローチとの対比は BitNet｜Microsoftの1ビットLLM量子化フレームワーク — CPUだけで100Bモデルが動く仕組み が詳しく、こちらは「重み自体を細くする」方向の代表例です。

Per-Layer Embeddings（PLE）とは：Gemma由来の仕組みをマイコンのメモリ階層へ移す

Per-Layer Embeddings（PLE）はGoogleがGemma 3n・Gemma 4で採用した設計です。通常の埋め込みが「入力の一番下で1回だけトークンをベクトル化する」のに対し、PLEは各層に対して別々の埋め込みを持ち、層ごとに注入する形をとります。

重要なのは、この形がマイコンのメモリ階層と噛み合うことです。層ごとの埋め込み表は行数が語彙サイズ、列が層数×表の幅になるため巨大になりますが、1トークンで必要になるのはそのトークンに対応する行だけです。esp32-aiの構成では6層×128次元＝768要素、4bitなら384バイトを読むだけで済みます。

model.py のコメントによれば、この注入は単なる「トークンごとのバイアス加算」ではありません。各ブロックが ple_gate（コアの状態から作るゲート）と ple_proj（表の行を戻す射影）を持ち、ゲートと表の行を掛け合わせてから残差へ足す構造になっています。掛け算があることで「条件付け」として働く、というのが作者の設計意図です。

「速いメモリに収まらない部分を、遅いが大きいメモリへ逃がす」という発想自体は、サーバー側の推論でも同じ形で現れます。MoEモデルの専門家をCPU側メモリへオフロードして24GB VRAMに載せる手法は KTransformers解説｜24GB VRAMでDeepSeek-R1級MoEを動かすCPU/GPUヘテロ推論 が扱っており、規模はまったく違うものの「疎にアクセスされる巨大な部分だけを外へ出す」という骨格は共通です。

アブレーションが示すPLEの適用条件：語彙32768で+0.098nats、4096では4分の1

esp32-aiが単なるデモに留まらないのは、PLEが効く条件を対照実験で切り分けている点です。RESULTS.mdには5つのアーム（実験条件）による比較が、いずれも2シードで記録されています。

デプロイ構成（語彙32768・コアを約559Kに揃えた条件）の結果は次のとおりです。

fatembed は「同じ量のパラメータを入力の一番下にまとめて置く」条件です。層ごとに注入する ple がこれを0.046nats上回っているので、パラメータをどこへ置くかではなく、どこで注入するかが効いていることになります。RESULTS.mdはこの差を「シードノイズ±0.006の約16倍」と表現しています。

対照実験が示す3つの境界条件

小語彙（4096）での比較は、PLEが万能ではないことを示す対照実験として置かれています。

ここから読み取れることは3つあります。

・効いているのは表であって配管ではない：ple_notable は層ごとのアダプタと射影を全部持ちながら参照表だけ外した条件で、baselineより悪化します。表がなければ、機構に割いたコアのパラメータが丸損になるということです
・行の幅は飽和し、行数は飽和しない：表の幅（ple_dim）を増やすスイープでは+0.045（d64）→+0.094（d256）→+0.087（d512）と頭打ちになります。一方、語彙を32768にして行数で表を大きくした場合は+0.098がそのまま出ています
・PLEはタダの容量ではない：コアを2倍にする bigcore は語彙4096で+0.170と圧勝します。デスクトップならコアを買えばいい話で、コアが固定のシリコンでフラッシュだけが潤沢という制約があって初めてPLEが選ばれる、というのがRESULTS.mdの整理です

つまりesp32-aiの結果は「PLEが常に強い」ではなく、語彙が大きく、かつ速いメモリを増やせない環境でだけ強いという限定付きの主張です。この限定を自分で書き残しているところが、この実験の信頼性を支えています。

実測プロファイルの逆説：遅いはずのフラッシュではなく出力ヘッドが律速

多くの人が直感的に「フラッシュは遅いのだから、そこを読むPLE表がボトルネックだろう」と考えます。実機の計測結果はその逆でした。

まず、実機（ESP32-S3 N16R8）でXtensaのサイクルカウンタを使って測った帯域の実測値がこちらです。

25Mパラメータの表を引くコストは、この合成ベンチマークにおける1トークンあたりメモリ時間の約0.7%でした。RESULTS.mdはこの0.7%を「推論全体のオーバーヘッド」ではなく「合成ベンチにおける表の帯域シェア」として引用するよう指定しています。同様に58 tok/sも「帯域の上限であって観測されたスループットではない」と釘を刺しています。

40msの床は自分で計算し直せる

現在のランタイムのプロファイルは、出力ヘッド57.6ms／Attention 25.6ms／PLE経路8.5ms／FFN 6.9ms／入力処理4.4msで、合計102.9ms＝9.72 tok/s（計算のみ）です。RESULTS.mdは出力ヘッドについて「計算律速ではなくPSRAM帯域律速」と書いていますが、これは手元で検算できます。

出力ヘッドはint8で常駐し、パディングされた到達不能な語彙行7,415行を飛ばして走査します。実際に読む行数は 32,768 − 7,415 = 25,353行。1行はd_model=96要素なので、25,353 × 96 = 2,433,888バイト＝約2.43MB。これをPSRAMの実測帯域60.7 MB/sで割ると 約40.1ms となり、RESULTS.mdの「57.6msのうち約40msは読み出しの床」という記述と一致します。残る約17msだけが演算時間ということです。

この分解が意味するのは、SIMD命令を使っても改善幅は限定的ということです。RESULTS.mdはこの点を「SIMDで削れるのは17ms側だけで、上限は約15%」と見積もり、次の大きなレバーは「読むバイト数を減らす（int4ヘッド＋SIMDでの展開）」か「出力ヘッド自体を小さく／分解する（モデル側の変更）」であって、ベクトル化を頑張ることではない、と結論づけています。

0.57 tok/sから9.5 tok/sまで

到達までの経過も5段階で記録されています。

最初に正しく動いた可搬版は1ステップ1,757.2ms（0.57 tok/s）でした。そこからヘッドのPSRAM常駐化とスカラー処理の整理で193.9ms、dot積・RoPE・Attentionの厳密な整理で172.9ms、ヘッドの2コア分割で139.4ms、int8ヘッド＋int8活性で102.9msという経過です。

int8化については、ホスト側の検証perplexityで劣化がほぼゼロであることを確認してから実機へ載せたとRESULTS.mdは記録しています（firmware/host_verify/ppl.c）。fp32の厳密版（139.4ms）は正解基準として残され、ホスト側のC実装は32,768個すべてのロジットについてPyTorchの出力と最大絶対誤差0.00001で一致しています。

「速いメモリが足りないなら、台数を増やして帯域ごと確保する」という別方向のアプローチもあります。複数デバイスへモデルを分割する Distributed Llama：家庭用デバイスを繋ぐだけでLLMローカル実行を高速化する分散フレームワーク はその代表で、esp32-aiとは「1台のメモリ階層を使い切る」か「台数で殴る」かという対照的な選択になっています。

4bit量子化とESP32 LLM先行実装との比較：PLEの優位は量子化後にむしろ広がる

フラッシュに置く以上、重みは4bitで格納されます。「学習時のfp32で見えた差が、量子化で消えてしまわないか」は当然の疑問で、esp32-aiはこれも2シードで検証しています。

src/quantize.py はグループ単位の対称int4量子化（グループ64、GGUFのQ4形式に相当）を行い、25Mの参照表を含むすべての大きな重みを量子化してから検証損失を測り直します。

PLEとbaselineの差は、fp32で+0.101／+0.095だったものが4bit後には+0.125／+0.121になります。つまり優位は124〜128%が保たれる——正確には広がるという結果です。RESULTS.mdはこれを「すべてのアームが劣化するがPLEの劣化が小さい。グループごとのスケールを持つ巨大で冗長な参照表は、1つ1つの重みが重要な小さな密モデルより本質的に量子化に強い」と説明しています。フラッシュ予算を賭けた部分が、同時に最も4bit耐性の高い部分だったわけです。

実際にフラッシュへ書き込まれる形式（グループ128・可変長行・fp16スケール）でも同じ検証を行い、優位の保持率は126%／121%でした。実際に焼くバイト列でも2シードの結論は変わらないことまで確認されています。

先行するesp32-llmとの比較

ESP32上でLLMを動かした先行例として、2024年9月に公開された DaveBben/esp32-llm があります。両者の位置づけを整理すると次のようになります。

数値だけ見れば先行実装のほうが2倍速いことになりますが、条件が違います。260Kのモデルは全体で約1MBなので毎トークン全部読んでも安く、さらにESP-DSPのSIMD命令を使っています。一方esp32-aiは約110倍の保存パラメータを抱えながらスカラー演算のみで9.5 tok/sに到達しており、RESULTS.mdは両者を「同程度の実用速度帯」と表現しています。優劣というより、モデルを大きくしたときに速度がどこまで持ちこたえるかという別の問いに答えたのがesp32-aiです。

なおRESULTS.mdは来歴についても明示的で、依存しているのはTinyStoriesデータセットとGoogleが公開したGemmaのPLE設計だけであり、llama2.cやesp32-llmからコード・モデル・手法を引き継いではいない、と書いています。READMEでkarpathy氏のllama2.cに触れているのは「小さな言語モデルを学習してCで動かせると信じられるようになった理由」という影響の記述であって、実装上の依存ではありません。

ESP32 LLMを自分で動かす手順と、再現できる範囲

最後に実務的な話です。このリポジトリを試すハードルは、記事の見出しから受ける印象よりかなり高いというのが結論です。

ステップ1：データを準備して学習する

data/prepare.py はHugging FaceからTinyStoriesの学習ファイルを先頭300MBぶんだけ取得し、BPEトークナイザーを学習してuint16のトークン列を書き出します。コメントによれば300MB＝約7,500万トークンで、「1Mパラメータのコアを計算最適点よりかなり過学習させるのに十分な量」を意図した設計です。学習は src/train.py にアーム名を渡して実行します。デバイスはMPS（Apple Silicon）→CUDA→CPUの順に自動選択されます。

# 語彙32768でデータを準備（TinyStoriesの先頭300MBを取得しBPEを学習）
cd data && uv run python prepare.py --vocab 32768 && cd ..

# デプロイ構成のアームを学習（アームは baseline / ple / ple_notable / fatembed / bigcore）
cd src && uv run python train.py --arm ple --steps 4000 --batch-size 32 --seq-len 512

ステップ2：int4へエクスポートしてホスト側で照合する

実機に焼く前に、可搬C実装の出力がPyTorchと一致することをホストで確認します。RESULTS.mdによれば、この照合は32,768個すべてのロジットについて最大絶対誤差0.00001で通っています。

# group-128のラグドint4形式でエクスポート
cd src && uv run python export.py && cd ..

# 可搬C実装をゴールデン出力と照合
cc -O3 -o /tmp/esp32-llm-verify firmware/host_verify/verify.c -lm
/tmp/esp32-llm-verify firmware/model/model.bin firmware/model/golden.txt

ステップ3：ビルドして実機へ書き込む

ファームウェアはArduino ESP32 core 3.3.10でビルドします。カスタムパーティション構成が前提で、モデル本体は 0x110000 に別途書き込みます。

# ファームウェアをビルド（PSRAM=opi・16MBフラッシュ・カスタムパーティション）
arduino-cli compile \
  --fqbn 'esp32:esp32:esp32s3:UploadSpeed=921600,USBMode=hwcdc,CDCOnBoot=cdc,UploadMode=default,CPUFreq=240,FlashMode=qio,FlashSize=16M,PartitionScheme=custom,PSRAM=opi,DebugLevel=info' \
  --build-property compiler.optimization_flags=-O3 \
  --build-path /tmp/esp32-llm-build \
  firmware/esp32_llm

# モデル本体を専用パーティションへ書き込み、シリアルで生成を確認
esptool.py --chip esp32s3 --port /dev/cu.usbmodem2101 --baud 921600 \
  write_flash 0x110000 firmware/model/model.bin
arduino-cli monitor -p /dev/cu.usbmodem2101 --config baudrate=115200

firmwareのREADMEには、計測に使ったモデルのSHA-256（21067f5d78113f6c64a8720b05ff7e5c774dab0276797a522f81a6797253d97c）と、起動時に出るはずの診断（model: V=32768 D=96 L=6 H=4 F=66 P=128 / head staged int8: 2.53 MB / PSRAM free after alloc: ~5100 KB）が書かれています。自分のエクスポート結果がこのハッシュと一致するかで、同じ成果物を作れたかを確認できます。

再現できる範囲には境界がある

一方で、RESULTS.mdの数値をすべて追試できるわけではありません。

・学習済み成果物が無い：GitHub Releaseは0件、firmware/model/model.bin も golden.txt も .gitignore されており、チェックポイントも含まれません。焼くところから始めることはできず、学習から始める必要があります
・アブレーションの生データが無い：RESULTS.mdが参照する runs/_archive_old_accounting/ や runs/*fix-d* は runs/ ごと .gitignore されています。5アーム×2シードの数値を検証するには、同じ学習を自分で回すことになります
・新規性の主張は本人の限定付き：READMEは「これほど小さなチップで試した人はいないと自分の知る限り（as far as I can tell）」という書き方をしており、断定はしていません
・ハードウェアが要る：PSRAM付きのESP32-S3 N16R8が前提で、READMEに載っている数値はこのボードでの計測です

何が持ち帰れるのか

esp32-aiは「マイコンで実用的なAIアシスタントが動く」という話ではありません。TinyStoriesの物語しか書けないモデルであることは作者が最初に書いています。それでも読む価値があるのは、メモリ階層をアクセスパターンで分類し、その分類に合わせてアーキテクチャを選ぶという考え方が、規模を問わず使える形で提示されているからです。

エッジAIの実装では「速いメモリに載る大きさまでモデルを削る」ことが定石でしたが、esp32-aiが示したのは削らずに、毎トークン読む量だけを削るという別の解き方です。マイコン LLM という極端な制約下で成立するなら、同じ考え方は「ストレージは潤沢だがRAMが足りない」他の環境にも応用できるかもしれません——ただしこれは編集部の見立てであって、RESULTS.mdはマイコン以外のターゲットについて何も検証していません。そして前述のとおり、これは学習時からその構造を持たせた場合にのみ成立する話であって、既存モデルへ後付けできる最適化ではない点にも注意が必要です。

そして数字の扱い方そのものが参考になります。パラメータ計上のバグを見つけて数値を修正した経緯を残し、帯域の0.7%は「合成ベンチでのシェア」と限定し、58 tok/sは「上限であって実測ではない」と断り、小語彙の結果は「対照実験であって製品構成ではない」と書く——この徹底ぶりが、7日間で書かれた個人プロジェクトの主張を検証可能なものにしています。

参照ソース

・slvDev/esp32-ai — 公式リポジトリ。README・ソースコード・ファームウェア（2026-07-28確認）
・slvDev/esp32-ai — RESULTS.md — アブレーション・帯域実測・オンチップ生成・4bit量子化の一次記録
・slvDev/esp32-ai — src/budget.py — 3層メモリ会計の実装。本記事のパラメータ再計算はこの式に基づく
・slvDev/esp32-ai — MIT LICENSE追加コミット 74744182 — 2026-07-26のライセンス追加
・Hacker News — Running a 28.9M parameter LLM on an $8 microcontroller — 281ポイント・70コメント（2026-07-26 03:59 JST投稿）
・DaveBben/esp32-llm — 先行する独立プロジェクト。260Kパラメータ・19.13 tok/sの記載はこのREADMEより
・Eldan & Li, TinyStories: How Small Can Language Models Be and Still Speak Coherent English? — 学習に使われたデータセットの原論文