ほとんどの人は、いまだにローカル AI を贅沢品のように扱っています。
3,000 ドルの NVIDIA DGX Spark を買ったり、800 ドルの Mac Mini を積み上げたりして、自律的なインテリジェンスには大規模で集中型のハードウェアが必要だと思い込んでいるのです。
しかし、実際に物理 AI を大規模に導入しているエンジニアたちは、もっとずっと安価なものを作っています。それは、分散型のスウォーム（群れ）です。
- 1 つの 8 ドルのチップが部屋の音を聞く。
- 別の 8 ドルのチップがローカルで意図を処理する。
- 決定論的なスクリプトがバックグラウンドノイズを除去する。
- 3 つ目のチップが Bluetooth コマンドを実行する。
- ネットワーク全体の消費電力は、LED 1 個分の電力で十分です。
これこそが、物理的なスウォームアーキテクチャです。
読み進める前に:
このガイドをブックマークしておけば、パーツが届いたときに最後の組み立て手順に戻ってくることができます。そして、
@ardchain — 私は自律エージェント、ローカル AI パイプライン、そしてコードと安価なハードウェアの両方をスケーラブルな自動化ビジネスに変えるシステムについて解説しています。
(注: この記事の最後に、完全なステップバイステップのハードウェアとフラッシュのマニュアルを記載しています。ただし、パーツを注文する前に、アーキテクチャが実際にどのように機能するかを理解する必要があります)。
私は slvDev/esp32-ai の GitHub リポジトリ と実際のプロダクション IoT パターンを何週間もかけて分析し、ローカルインテリジェンスを 1 つの実用的なプレイブックに再構築しました。
巨大な集中型の頭脳を買う代わりに、インテリジェンスを環境に分散させるのです。
聞く → 解析する → ルーティングする → 実行する
各マイクロコントローラーは、限定された役割を持つノードになります。各チップは特定のモデルを搭載します。オフライン推論がどのアクションを実行するかを決定します。重要な変化は、あなたのスマートホームが、すべての音声コマンドを高価な API やノイズの多いワークステーションにルーティングする必要がなくなることです。
28.9 百万パラメータの LLM を、たった 8 ドルの ESP32-S3 チップ で完全にオフラインで実行でき、クラウドの帯域幅を消費しません。
基本的なパターンは新しいものではありません。ハードウェアエンジニアは、マイクロコントローラー、I2S バス、BLE メッシュを何十年も使用してきました。変わったのは、各ノードに何が搭載されるかです。ノードは自然言語を処理し、乱雑な音声コマンドを解析し、それを厳格な API にマッピングし、またはセンサーデータを統合して意思決定を行うことができます。
このガイドでは、ハードウェアのボトルネックからメモリマッピング、I2S 音声キャプチャ、BLE 実行、そしてシリコン上で直接生成される動的スウォームまで、システム全体を分解して説明します。
これを読み終える頃には、物理的なタスクを見て、次のように尋ねるのをやめられるでしょう。
「どの API を呼び出すべきか？」
1. 物理 AI はメモリのボトルネックから始まる
ハードウェアのマーケティングは、しばしばより多くの VRAM を購入する理由として提示されます。しかし、このフレーミングは実際のエンジニアリング上のブレークスルーを見落としています。
ただ明かりを点けるためだけに 70B モデルを実行するために RTX 5090 を購入することは可能ですが、その代償として熱、電気代、そして莫大なハードウェア費用を支払うことになります。有用なノードは、メモリがどこに保存されるか、どのコンポーネントが各決定を処理するか、そしてデータがどのようにシリコン内を移動するかを制御します。
8 ドルの ESP32-S3 マイクロコントローラーに言語モデルを実行させることを想像してみてください。従来の常識では、それは失敗するでしょう。このチップには、512KB の高速 SRAM と 16MB のフラッシュメモリ しかありません。モデルは収まりません。標準的なフレームワーク内では、これは不可能なタスクになります。埋め込みテーブルだけで、ワーキングメモリを圧迫してしまいます。
スウォームエンジニアリングは、そのボトルネックを解消し、すべてのパラメータに明確な場所を与えます。
ブレークスルーはアーキテクチャにあります。埋め込みテーブルの大部分（約 2500 万パラメータ）は、フラッシュメモリに直接メモリマッピングされます。アクティブなワーキングメモリは、高速な SRAM 内に留まります。
その結果、チップはトークンあたり約 450 バイト をプルするだけで済むワークフローが実現します。
ノードは 1 つの決定を行うべきである
有用な物理ノードは、限定された責任を持ちます。
- ウェイクワードを見つける。
- 意図を低、中、高の信頼度に分類する。
- Bluetooth マクロを実行する。
各ノードには、明確な入力、定義された出力、そして限られたハードウェアフットプリントが必要です。音声をキャプチャし、意図を推定し、応答を設計し、信号を送信する中央の Mac Mini には、複数の障害点が存在します。家全体が 1 台のマシンに依存しているため、デバッグは困難なままです。
物理的な境界を小さくすることで、どのセンサーが故障したかを正確に特定できます。
エッジは意図を伝えるべきである
エッジは、次の物理的なアクションに必要なデータを表します。音声ノードは、予測可能な JSON オブジェクトを返すことができます。
1{2 "sensor": "mic-living-room",3 "confidence": 0.98,4 "intent": "open_chrome_20_tabs",5 "execution_node": "ble-host-1"6}
スキーマは、チップ間の解釈のずれを減らします。自由形式のオーディオストリームは、下流のすべてのノードに、前のノードの意味を再構築することを強制します。
一部のノードは通常のコードである
ワークフローは、コマンドの重複排除、信号のデバウンス、および意図のハードコードされたアクションへのマッピングを行う必要があります。これらの操作には、決定論的な答えがあります。
以下は、実際の実行ループの様子です。I2S マイクが音声をキャプチャし、LLM がフラッシュメモリから意図を解析し、C++ コードが Bluetooth コマンドを発火します。
1// 1. マッピングされたフラッシュから 28M パラメータモデルを初期化2LLM model = LLM_Init(FLASH_MAPPED_EMBEDDINGS);34void loop() {5 // 2. I2S 経由で環境音声をキャプチャ6 String audio = I2S_Record_Voice();78 if (Detect_Wake_Word(audio)) {9 // 3. 推論 (約 9.5 トークン/秒)10 String intent = model.generate(audio);1112 // 4. 決定論的実行13 if (intent.indexOf("open_chrome") > -1) {14 BLE_Send_Macro(MAC_ADDRESS, CMD_OPEN_CHROME);15 }16 }17}
このシンプルな C++ 変換はワークフローを瞬時に処理し、実行のたびに同じ出力を生成します。同じタスクを別のモデルに送信すると、レイテンシが追加され、障害点が生まれます。モデルノードは、自然言語解析とファジーロジックの周辺に属します。コードは、BLE 実行、デバウンス、および明示的なルーティングルールを処理します。
2. スウォーム：分散ノードがどのように処理を移動させるか
ほとんどの本格的な物理 AI グラフは、最終的に同じ形状をとります。タスクは環境内で始まり、いくつかの独立したセンサーに分割され、物理的な証拠を圧縮し、その結果を最終的なハードウェア実行に渡します。
その形状がスウォームです。
- ファンアウト: 環境キャプチャ (I2S マイク)。
- バリア: オフライン LLM (意図解析)。
- ファンイン: 物理アクション (BLE マクロ)。
このパターンは、タスクが rigid な if-this-then-that ルールには複雑すぎる場合に、あらゆる場所で現れます。
キャプチャは独立した入力を生成するべきである
センサーは、メインの頭脳を起動することなく環境をリッスンし、有用な結果を生成できる場合、キャプチャフェーズに属します。
ESP32 は、ほぼゼロに近い電力で継続的にウェイクワードをリッスンできます。トリガーされると、オーケストレーションはシリコン上に留まります。チップは音声を記録し、モデルを実行し、検証済みの意図を返します。
実行する前に削減する
音声をキャプチャした後、ノードはいくつかの競合する解釈を保持する可能性があります。生のオーディオをそのまま実行レイヤーに送信すると、混乱が生じます。削減ステージがコマンドを準備します。
一部の削減は量子化 (16MB フラッシュに収まる 4 ビットモデル) によって行われます。実行ノードは、トレーサビリティを失うことなく、厳格なコマンドを受け取ります。
3. 分散化はアーキテクチャの一部である
ノードは推論を迅速に完了できても、間違ったアクションをトリガーする可能性があります。システムには、どのコマンドを実行に値するかを決定するためのルールが必要です。
ハードウェアの制限でルーティングする
ルーターは構造化された出力を読み取り、次の物理的なブランチを選択します。これにより、高価な処理は意味のあるインパクトを持つノードに集中します。
ハードウェアをノードに合わせる
すべての部屋に Apple M4 チップが必要なわけではありません。抽出、基本的な意図分類、および限定的な音声検索は、8 ドルの ESP32 で実行できます。大規模なビデオ処理、複雑な推論、およびグローバルな統合は、より強力な中央サーバーを正当化する可能性があります。
ハードウェアの階層化は、スウォームのもう 1 つの特性になります。
集中化をいつ止めるべきかを知る
グラフのオーバーヘッドには、オーケストレーション、Wi-Fi レイテンシ、ルーター設定、およびデバッグするためのより多くのネットワーク状態が含まれます。デスクが 1 つだけの場合、集中型の Mac Mini で通常は十分です。
スウォームエンジニアリングは、環境に複数の部屋、高額な API コスト、大規模なセンサーアレイ、または完全なオフラインプライバシーの必要性がある場合に有用になります。
4. 完全な組み立て手順
何をはんだ付けし、何をフラッシュするかを正確に知らなければ、理論は無意味です。今週末にローカル AI ノードを構築したい場合は、以下がフィルターなしのステップバイステップの技術ガイドです。
ステップ 1: ハードウェアと配線
必要なコンポーネントは正確に 2 つです。
- ESP32-S3 開発ボード (モデルのメモリマッピングを機能させるには、16MB フラッシュ と 8MB PSRAM を搭載したバリアントである必要があります)。
- INMP441 I2S マイクモジュール。
これは物理 AI です。つまり、配線する必要があります。INMP441 は I2S バスを使用します。接続を正確にこのようにはんだ付けしてください。
- VDD \rightarrow 3.3V
- GND \rightarrow GND
- L/R \rightarrow GND (マイクを左チャンネルにプルします)
- WS \rightarrow GPIO 4 (ワードセレクト / フレーム同期)
- SCK \rightarrow GPIO 5 (シリアルクロック)
- SD \rightarrow GPIO 6 (シリアルデータ)
ステップ 2: モデルとフラッシュプロセス
ChatGPT をロードしているわけではありません。ロードしているのは、意図分類と構造化 JSON 出力に最適化された 28.9 百万パラメータの蒸留モデル です。
ESP-IDF ツールチェーンと格闘する必要はありません。プリコンパイル済みのバイナリとモデルウェイトを、esptool.py を使用して直接フラッシュできます。
- ボードをブートローダーモードにします (BOOT を押したまま、RST を押し、BOOT を離します)。
- モデルを 16MB フラッシュパーティションに直接マッピングする、正確なフラッシュコマンドを実行します。
1esptool.py --chip esp32s3 --baud 921600 \2 --before default_reset --after hard_reset write_flash -z \3 --flash_mode dio --flash_freq 80m --flash_size 16MB \4 0x10000 build/firmware.bin \5 0x400000 models/intent_classifier_28M_q4.bin
ステップ 3: レシーバー (Home Assistant)
フラッシュされると、ESP32 は Wi-Fi やクラウド API を必要としません。意図を検出すると、標準の BTHome 互換 BLE ペイロード をブロードキャストします。
この信号をキャッチして実際に照明を点灯するには、以下の手順に従います。
- Home Assistant を Bluetooth 統合機能 (または ESP32 BLE プロキシ) と共に実行します。
- ノードは BTHome センサーとして自動検出されます。
- 意図 (例: open_chrome、lights_off) は、センサーの状態変化として表示されます。この状態を既存のオートメーションに直接マッピングします。
価値は、コンピューティングを見えなくすることにあります。
すべてのノードには限られた物理的責任があります。すべてのチップは構造化された意図を伝えます。すべての部屋には存在する理由があります。すべての音声コマンドはオフラインのままです。
その時点で、あなたの家は高価な API で動作しているのではありません。
それは、エンジニアリングされたスウォームを実行しているのです。
