クラウド不要の自律エッジ AI──WASM 版 DOOM と Bonsai-1.7B を WebGPU / VRAM 内で直結する

Published: 2026-06-16 | Updated: 2026-06-16

AIKernel の Day 2 として、WASM 版 DOOM、WebGPU、Bonsai-1.7B、VRAM resident vision path、zero-copy、CPU fallback、AutoPlay runtime を接続した完全ローカル自律エッジ AI デモの低レイヤ実装を解説します。

カテゴリ: AI Infrastructure, WebGPU, WASM, Edge AI, Local AI, Developer Experience

昨日の記事では、AIKernel の Perception Layer に耳を与えました。

stereo PCM を解析し、auditorySnapshot を作り、視覚情報と融合するための spatialSnapshot を整え、HUD overlay によって AI がどちらを向いて世界を感じているのかを可視化しました。

今日のテーマは、身体です。

AI が音と視覚で空間を読めるようになったとしても、その認知が実際の実行環境へ接続されなければ、まだ「感じている」だけです。

今日公開するのは、その認知を実際のランタイムへ接続するための低レイヤ実装です。

WASM。 WebGPU。 Bonsai-1.7B。 VRAM resident vision path。 zero-copy。 AutoPlay。 CPU fallback。 DOOM runtime。

この記事では、思想や統治理論には踏み込みません。

今日はただ、ブラウザ上でローカルに動く WASM アプリケーションと、小型モデルと、GPU resident な視覚パスをどう接続したのか だけを扱います。

なお、準備していた DOOM AutoPlay デモは、予定どおり 2026 年 6 月 16 日公開に向けて最終段階まで到達しました。

1. 何を作ったのか

今回作ったものは、AIKernel 上で動く DOOM AutoPlay デモです。

構成要素は、次のように分かれます。

WASM DOOM Runtime
  ↓ frame / state
WebGPU Vision Path
  ↓ GPUTexture / GPUBuffer
Bonsai-1.7B Local Model
  ↓ action candidate
AIKernel Capability Runtime
  ↓ input dispatch
DOOM Runtime

大きく言えば、WASM で動く DOOM をローカル小型モデルが観察し、判断し、入力を返す という構成です。

ポイントは、クラウドに映像を送らないことです。

画面をクラウドへ投げる。クラウドで推論する。戻ってきた結果をローカルで実行する。

この方式は分かりやすい一方で、遅延、転送コスト、プライバシー、ネットワーク依存が発生します。

今回のデモでは、その経路を使いません。

ブラウザ上で DOOM を動かし、ローカルで視覚入力を取り、ローカルの Bonsai-1.7B に渡し、ローカルで行動を返す。

つまり、クラウド不要の自律エッジ AI ランタイム です。

2. 全体アーキテクチャ

今回の実装は、ひとつの巨大な処理としてではなく、複数のレイヤを接続する形で構成しています。

AIKernel.NET
  - contracts
  - capability definitions
  - provider boundary
  - CLI / status surface

WASM DOOM Runtime
  - doom_init
  - doom_tick
  - doom_render
  - doom_input

WebGPU Runtime
  - GPU adapter / device
  - GPUTexture
  - GPUBuffer
  - command queue
  - palette expansion

Bonsai Runtime
  - Bonsai-1.7B-Q1_0.gguf
  - local inference
  - action generation
  - structured output

Control Runtime
  - AutoPlay loop
  - action reuse
  - fallback switching
  - runtime consent

HUD / UI
  - runtime state
  - inference state
  - fallback state
  - performance metrics

この構造で重要なのは、DOOM が主役ではないことです。

DOOM は、視覚入力、状態遷移、入力制御、リアルタイム描画、失敗時の観察がすべて揃った、非常に扱いやすいシナリオです。

本体は、WASM アプリケーション、WebGPU、ローカルモデル、Capability 実行系をひとつのランタイム上で接続する仕組みです。

3. Runtime Consent Flow：ロード前に必ず止める

起動直後に、AIKernel のブートシーケンス風の画面を表示します。

その後、アセット利用への同意を求めます。

ユーザーが明示的に yes と入力した場合のみ、次の保護対象アセットをロードします。

DOOM WAD
Bonsai-1.7B model
doom.wasm
manifest
NOTICE / license metadata
checksum

承認がない限り、大容量アセットのダウンロードやロードは開始しません。

これは派手な機能ではありません。

しかし、ブラウザ上でローカル AI デモを動かすうえではかなり重要です。

モデル、WASM、WAD のような大きなアセットは、ユーザーが何を読み込むのかを理解したうえでロードされるべきです。

今回のデモでは、まず consent flow を通し、manifest と checksum を確認し、ロード状態を doom.status から確認できるようにしました。

4. WASM 版 DOOM：ホスト側から tick / render / input を制御する

DOOM 側は doom.wasm としてビルドし、AIKernel の Runtime からロードします。

ここで重要なのは、DOOM 側に閉じた無限ループを持たせないことです。

AIKernel 側から 1 フレームずつ制御できるように、概念的には次のような ABI に分解します。

int doom_init(void);
int doom_tick(void);
uint8_t* doom_render(void);
void doom_input(int keycode, int pressed);

doom_tick() で 1 フレーム進める。 doom_render() で現在の framebuffer を得る。 doom_input() で AI またはユーザーの入力を注入する。

この分解によって、ゲームループを AIKernel 側の orchestration に載せられます。

AI 推論が遅れているなら前回の action を再利用する。 WebGPU が不安定なら CPU summary に切り替える。 AutoPlay を UI / CLI から切り替える。デモ中に doom.status で現在の状態を見る。

これらを行うには、DOOM 側のループをホスト側から握れる必要があります。

WASM 化の本質は、単にブラウザで動かすことではありません。

AIKernel が実行周期を制御できる形へ、ランタイムを分解すること です。

5. WebGPU 描画パイプライン

DOOM の framebuffer は、古典的な 320 x 200 の 8bit paletted framebuffer として扱います。

必要に応じて、WebGPU 側で RGBA へ展開します。

8bit paletted framebuffer
  ↓ palette lookup
RGBA texture
  ↓ GPUTexture
vision input

WebGPU が使える環境では、描画結果を GPUTexture として保持します。

この GPUTexture は、画面に表示するだけでなく、AI 側の視覚入力としても使います。

一方で、WebGPU は環境依存が強いです。

ブラウザ。 OS。 GPU ドライバ。 secure context。 adapter / device の制約。 device lost。

これらの条件によって、同じコードでも挙動が変わることがあります。

そのため、今回の実装では WebGPU を使える前提にせず、使えない場合は CPU fallback へ切り替える構成にしています。

6. WebGpuComputeProvider：GPU を直接触らせない境界

AIKernel 側では、WebGPU を抽象化するために WebGpuComputeProvider を整備しました。

この Provider が担当するのは、主に次の領域です。

GPU adapter / device の選択
command queue の管理
GPUTexture / GPUBuffer の生成
resource lifetime の管理
device lost の検知
WebGPU が使えない場合の fallback
描画パスと推論パスの接続

WebGPU は強力ですが、ブラウザ API と GPU リソースのライフタイムが絡むため、扱いを間違えるとすぐ不安定になります。

特にハマりやすいのは、command encoder と texture view の寿命です。

描画側で作った texture を、推論側でいつ参照するのか。前フレームの texture view を持ち続けていないか。 device lost 後に古い buffer を触っていないか。 fallback へ切り替えた後も GPU path の状態が UI に残っていないか。

このあたりをアプリケーション層へ散らすと、デバッグがかなり苦しくなります。

そこで WebGPU の扱いは Provider に寄せ、上位レイヤは「GPU が使えるか」「視覚入力を渡せるか」「fallback 中か」という状態だけを見るようにしました。

7. Bonsai-1.7B のローカル実行

AutoPlay の判断には、軽量モデルである Bonsai-1.7B を使います。

今回のデモでは、Bonsai-1.7B-Q1_0.gguf をユーザー承認後にロードする構成にしています。

Bonsai 側の役割は、DOOM の状態を観察し、次の action を返すことです。

ここでの action は、たとえば次のような単純な入力へ落とします。

{
  "moveForward": true,
  "turnLeft": false,
  "turnRight": true,
  "strafeLeft": false,
  "strafeRight": false,
  "fire": false,
  "use": false,
  "confidence": 0.74
}

今回の記事では、この action の「最終判断の制度」には踏み込みません。

今日はあくまで、ローカル小型モデルを WASM / WebGPU ランタイムに接続し、AutoPlay loop へ戻すところまでを扱います。

ポイントは、Bonsai をクラウド API として呼ばないことです。

DOOM もローカル。視覚パスもローカル。モデルもローカル。 action 適用もローカル。

この閉じたループが、今回のデモの中核です。

8. Zero-Copy Vision Path：画面を CPU に戻さない

今回いちばん重要なのは、DOOM の描画結果を AI 側へ渡す視覚パスです。

普通に作ると、次のような経路になりがちです。

GPU draw
  ↓ readback
CPU pixels
  ↓ preprocessing
CPU tensor
  ↓ upload
GPU inference

つまり、GPU → CPU → GPU の往復が発生します。

フレームごとにこれを行うと、レイテンシもメモリ帯域もかなり無駄になります。

そこで今回は、WebGPU が使える環境では、DOOM の描画結果を GPUTexture として保持し、そのまま Bonsai 側の入力 view として渡す構成を第一候補にしました。

概念的には次のような流れです。

// DOOM が描画した GPUTexture を取得
const doomTexture = doomRenderPass.outputTexture;

// Bonsai 側の入力 view として参照
const bonsaiInputView = doomTexture.createView();

// Bonsai の推論パイプラインへ bind
bonsaiEncoder.bindTexture("input_image", bonsaiInputView);

// GPU 上で前処理・推論を実行
bonsaiEncoder.dispatch(...);

実際には、palette 展開、texture format、synchronization、command encoder の寿命、fallback、HUD 表示との同期を扱う必要があります。

それでも考え方はシンプルです。

画面を CPU に戻さず、VRAM 内で AI に渡す。

この一点だけで、構成全体の意味が変わります。

AI が「画面キャプチャを受け取る」のではなく、GPU 上の視覚状態を直接読む。

これが、今回のデモを単なる AutoPlay から、低レイヤのエッジ AI ランタイムへ押し上げている部分です。

9. VRAM / メモリ配分の目安

今回の構成では、WASM 版 DOOM と Bonsai-1.7B を同じローカル環境で動かします。

概算のメモリ配分は次のようになります。

コンポーネント	想定量	役割
WASM 版 DOOM	約 200 MB	ゲーム実行、WASM memory、描画バッファ
Bonsai-1.7B	約 250 MB	視覚監視、状態判断、行動生成
合計	約 450 MB	500 MB 未満で同居可能な構成

もちろん、実使用量は環境によって変わります。

ブラウザ。 GPU ドライバ。 WebGPU 実装。モデル形式。キャッシュ状態。テクスチャ形式。一時バッファの持ち方。

これらで数字は変動します。

ただ、重要なのは、現代の一般的な GPU 環境であれば、DOOM と小型モデルを同じローカル環境に載せる余地が十分にあるという点です。

クラウドへ逃がさなくても、視覚入力と小型推論を同じブラウザ実行環境に収められる。

これはかなり大きいです。

10. CPU fallback：視覚パスが使えない環境でも止めない

Zero-Copy Vision Path は理想ですが、すべての環境で使えるとは限りません。

WebGPU が無効な環境。 GPU メモリが不足する環境。ブラウザ実装の制約がある環境。 secure context の条件を満たさない環境。 device lost が発生した環境。

こうした場合に、デモ全体が即座に停止してしまうと、実験環境として扱いにくくなります。

そこで、CPU fallback では、画像そのものではなく、WASM 側または Provider 側で抽出した軽量な状態サマリを Bonsai に渡します。

例としては、次のような情報です。

health
ammo
armor
position
angle
enemy count
damage state
current weapon
key possession
exit proximity

この状態サマリは、画像全体に比べると非常に小さいデータです。

数十バイトから数百バイト程度に圧縮できるため、低メモリ環境でも扱いやすくなります。

視覚が使える環境では視覚中心。使えない環境では状態サマリ中心。

この二段構えによって、デモとしての安定性が大きく上がりました。

11. AutoPlay Runtime：推論を待たずにフレームを進める

AutoPlay は、DOOM の tick に合わせて Bonsai の推論を非同期に呼び出す形で実装しています。

基本的な流れは次のとおりです。

1. doom_tick() で 1 フレーム進める
2. 画面または状態サマリを取得する
3. Bonsai 推論を非同期に開始する
4. 推論結果を次フレーム以降に適用する
5. 推論が間に合わない場合は前回 action を再利用する
6. renderFrame() で表示する

重要なのは、推論完了を待って描画ループを止めないことです。

AI の応答が少し遅れても、DOOM 側は動き続けます。

擬似コードでは、次のようになります。

let lastAction = null;
let pendingPrediction = null;

function tick() {
  doom_tick();

  const state = captureDoomState();

  if (!pendingPrediction) {
    pendingPrediction = bonsai.predictAsync(state)
      .then(action => {
        lastAction = action;
      })
      .finally(() => {
        pendingPrediction = null;
      });
  }

  if (lastAction) {
    applyAction(lastAction);
  }

  renderFrame();
}

この方式により、AI 推論とゲーム描画を疎結合にできます。

推論が速い環境では、ほぼ毎フレーム判断する。推論が遅い環境では、前回の action を短時間だけ再利用する。

これにより、AutoPlay の見た目の滑らかさを保ちながら、ローカル推論の遅延を吸収できます。

12. 協調スケジューラ：UI スレッドを詰まらせない

ブラウザ上で DOOM、WebGPU、Bonsai 推論、HUD を同時に回す場合、UI スレッドを詰まらせないことが重要です。

今回は、描画ループを 30 FPS 上限に制限し、requestAnimationFrame と setTimeout を組み合わせた協調スケジューラを使いました。

let lastTs = 0;
const FPS_MS = 1000 / 30;

function loop(ts) {
  if (ts - lastTs >= FPS_MS) {
    doom_tick();

    if (!pendingPrediction) {
      pendingPrediction = bonsai.predictAsync(currentState)
        .then(action => applyAction(action))
        .finally(() => pendingPrediction = null);
    }

    renderFrame();
    lastTs = ts;
  }

  setTimeout(() => requestAnimationFrame(loop), 0);
}

requestAnimationFrame(loop);

30 FPS に制限しているのは、単に軽くするためだけではありません。

WebGPU の command queue、Bonsai 推論、HUD 更新、Worker 通信に余裕を残すためです。

最初は、できるだけ高 FPS を狙いたくなります。

しかし、AutoPlay デモでは、瞬間的な最大 FPS よりも長時間安定して動くことの方が重要でした。

人間が見るデモとしても、AI が判断する実験環境としても、安定性の方が価値があります。

13. 推論の再利用と遅延管理

AutoPlay で重要なのは、推論が常にフレームレートに追いつくとは限らないという前提です。

そのため、ランタイムでは次の情報を管理します。

推論開始時刻
推論完了時刻
推論レイテンシ
推論成功回数
推論失敗回数
前回 action の再利用回数
推論結果の confidence
fallback 発生回数

推論が間に合わない場合は、直前の action を再利用します。

ただし、再利用し続けると同じ行動に固着する可能性があります。

そこで、再利用回数には上限を持たせます。

たとえば、数フレームだけは前回 action を使い、それ以上推論が戻らなければ neutral input に戻す。

prediction ready      → apply new action
prediction pending    → reuse last action within limit
reuse limit exceeded  → neutral action
invalid action        → neutral action

この設計により、推論遅延を吸収しつつ、長時間同じ入力が入り続ける状態を避けます。

ここもかなり地味ですが、実際にデモを安定させるうえでは効きました。

14. CLI と status surface

AIKernel.Doom では、CLI から DOOM と AutoPlay を操作できます。

代表的なコマンドは次のとおりです。

aik exec run doom
aik capabilities invoke doom.start
aik capabilities invoke doom.stop
aik capabilities invoke doom.status

AutoPlay は、UI と CLI の両方から切り替えられるようにしています。

doom.autoplay on
doom.autoplay off

doom.status では、DOOM 側の状態だけでなく、推論レイヤーや WebGPU の状態も確認できます。

表示対象の例です。

DOOM runtime state
WASM load state
WebGPU enabled / disabled
CPU fallback state
AutoPlay enabled / disabled
inference count
action reuse count
average inference latency
last action
device lost count
protected asset load state
model load state

この status surface があると、デモ中に「いま何が起きているのか」がかなり分かりやすくなります。

AutoPlay が動かないとき、それがモデル未ロードなのか、WebGPU fallback 中なのか、consent がまだなのか、推論が遅れているのか、action が無効なのか。

これらを UI の見た目だけで追うのはつらい。

doom.status は、そのための低レイヤ観測面です。

15. 監視と実験結果

ローカルで GPU 使用率を見るだけなら、Windows + NVIDIA 環境では次のような監視が便利です。

while ($true) {
  Clear-Host
  & nvidia-smi --query-gpu=utilization.gpu,memory.used --format=csv,noheader
  Start-Sleep -Seconds 5
}

ブラウザ上の WebGPU 利用状況は、環境によって見え方がかなり異なります。

そのため、OS 側の GPU 監視と、アプリ内の doom.status を併用すると分かりやすくなります。

現時点の実験では、おおむね次のような挙動を確認しています。

指標	結果
平均 FPS	22–30 FPS
FPS 上限	30 FPS
推論レイテンシ	約 30–80 ms
想定 VRAM / GPU memory 使用量	約 450 MB
protected download / cache size	約 253–270 MB
実行方式	ローカル WebGPU + fallback
クラウド依存	なし

実測値は環境によって変わります。

特に WebGPU は、ブラウザのバージョン、GPU ドライバ、OS、secure context の条件に強く依存します。

そのため、この数字は絶対値ではなく、現在の実装における目安として見てください。

重要なのは、完全ローカルで、ブラウザ上に、WASM 版 DOOM と Bonsai-1.7B と WebGPU 視覚パスを同居させられた という点です。

16. 開発中にハマったこと

ここからは、実装中に実際にハマった点を少しだけ残しておきます。

16.1 GPUTexture の寿命が思ったよりシビア

描画側で生成した texture view を、推論側で次のタイミングに参照しようとして失敗する場面がありました。

WebGPU は、リソースの寿命と command encoder の境界をきちんと意識しないと、見た目は動いているのに推論側だけ古い view を見ている、という状態が起きます。

最終的には、フレーム単位で参照を整理し、現在の frame token と texture view を紐づける形にしました。

16.2 palette 展開の位置

最初は CPU 側で palette → RGBA 変換を行う案もありました。

しかし、それをやると zero-copy の意味が薄れます。

現在は、GPU 内での展開を主経路に寄せ、CPU 側は fallback 用と割り切る方針にしています。

16.3 推論待ちで描画を止めるとデモが死ぬ

最初にやりがちなのは、推論結果を待ってから次のフレームを進める構成です。

これは分かりやすいのですが、推論が少し詰まるだけで画面が止まります。

AutoPlay では、推論と描画を分離する方が自然でした。

AI が少し遅れても、世界は止まらない。

この前提で設計した方が、デモとしてもランタイムとしても安定します。

16.4 status がないと何も分からない

一番地味で、一番効いたのが status surface でした。

WASM はロード済みか。モデルはロード済みか。 WebGPU は有効か。 fallback 中か。 AutoPlay は ON か。推論は何回成功したか。最後の action は何か。

これが見えないと、問題の切り分けに時間がかかります。

HUD と CLI の両方から状態を見られるようにしたことで、調整ループがかなり速くなりました。

17. なぜ DOOM なのか

DOOM は古典的なゲームですが、AI ランタイムの実験対象としては非常に優秀です。

理由はいくつかあります。

軽量でブラウザ上でも動かしやすい
描画、入力、状態遷移が分かりやすい
1 フレームごとの制御がしやすい
視覚入力と行動出力の関係が直感的
AutoPlay の成否が画面上ですぐ分かる
WASM / WebGPU / local model の統合デモとして伝わりやすい

そして何より、見た目が分かりやすい。

AI が何を見て、どう動いたのか。それが画面上で即座に分かります。

この「分かりやすさ」は、エッジ AI や自律制御のデモでは非常に重要です。

ただし、DOOM は目的ではありません。

DOOM は scenario です。

本体は、WASM アプリケーション、WebGPU 視覚パス、ローカル小型モデル、AutoPlay loop を接続する実行基盤です。

18. 応用可能性

今回の構成は、ゲーム専用ではありません。

DOOM は、視覚入力、状態推定、行動生成、実行、監視、fallback をひとつの小さな環境に詰め込んだデジタルツインとして扱えます。

同じ構成は、次のような領域にも応用できます。

ロボットのローカル推論
車載カメラのエッジ処理
製造ラインの異常検知
ブラウザ上でのシミュレーション制御
WebGPU を使った低コスト推論
オフライン環境での自律エージェント
プライバシー重視のローカル AI アプリケーション
XR / AR HUD 上のリアルタイム認知補助

クラウドに映像を送らず、ローカルで見て、ローカルで判断し、ローカルで動く。

この構成は、今後かなり重要になるはずです。

19. 公開時点で到達している低レイヤ改善

当初、この領域は「次に進める低レイヤ改善」として整理していました。

しかし、公開時点では、その大半がすでにランタイムへ取り込まれています。

そのため、ここでは今後の予定ではなく、Day 2 の時点で実行基盤を支えている低レイヤ改善 として整理します。

重要なのは、これらが単なる最適化項目ではないことです。

OffscreenCanvas、Worker、GPU 内 palette 展開、action reuse policy、Snapshot / telemetry。

これらはすべて、WASM 版 DOOM と Bonsai-1.7B をブラウザ上で安定して同居させるための、ランタイムの骨格です。

OffscreenCanvas + Worker 化

描画、推論、監視の責務を UI スレッドから分離するため、OffscreenCanvas と Worker を中心にした構成へ寄せています。

ブラウザ上で DOOM、WebGPU、Bonsai 推論、HUD を同時に回す場合、UI スレッドにすべてを背負わせるとすぐに限界が来ます。

入力は遅れる。 HUD は詰まる。推論完了の反映が遅れる。描画と状態更新の順序が揺れる。

これでは、AutoPlay の挙動が不安定になります。

Worker 側へ処理を寄せることで、UI は操作面と表示面に集中できます。

DOOM の tick、WebGPU の描画・変換、Bonsai 推論、状態 snapshot の更新を、UI スレッドからできるだけ切り離す。

この分離によって、ブラウザ UI の応答性を保ったまま、DOOM と Bonsai のランタイムを安定して回しやすくなりました。

GPU 内 palette → RGBA 展開

DOOM の framebuffer は、8bit paletted framebuffer です。

そのままでは、現代的な WebGPU の描画・推論パスへ渡しづらい。

そこで、palette → RGBA 展開は、可能な限り GPU 内で行う方針にしています。

8bit paletted framebuffer
  ↓ WGSL palette lookup
RGBA texture
  ↓ GPUTexture
vision input / HUD rendering

CPU 側で RGBA へ変換してから GPU に戻すこともできます。

しかし、それでは zero-copy vision path の意味が薄れます。

公開時点では、主経路を GPU 内展開へ寄せ、CPU 側の変換は fallback と診断用途に限定する方針へ移行しています。

これにより、視覚パスはより強く VRAM 内へ閉じるようになりました。

action reuse policy の調整

推論遅延時の action reuse も、公開時点ではかなり重要な制御要素になっています。

Bonsai の推論は、常に描画フレームに追いつくとは限りません。

そのため、推論が戻るまで前回 action を短時間だけ再利用する仕組みが必要です。

ただし、再利用しすぎると挙動が固くなります。

前進し続ける。旋回し続ける。 Use 後のラッチが残る。同じ探索パターンへ戻る。

このような固着を避けるため、action reuse policy では、再利用回数、confidence、neutral action への戻し方を調整しています。

prediction ready      → apply new action
prediction pending    → reuse last action within limit
reuse limit exceeded  → neutral action
low confidence        → neutral action / guarded action
invalid action        → neutral action

この制御により、推論遅延を吸収しながら、同じ入力が入り続ける状態を避けられるようになりました。

AutoPlay を自然に見せるためには、モデルの賢さだけでなく、このような低レイヤの入力政策がかなり効きます。

Snapshot / telemetry の軽量化

入力、状態、推論結果、action、latency、fallback 状態は、軽量な snapshot として観測できるようにしています。

これは、単なるログではありません。

AutoPlay がどこで詰まったのかを後から比較するための、低レイヤ観測面です。

たとえば、次のような情報を追えるようにします。

current pipeline
objective
mobility mode
last action
action reuse count
inference latency
WebGPU / CPU fallback state
movement stall
sensor recovery
milestone state
confidence
timestamp

この snapshot があることで、見た目では同じ失敗に見える現象を、実際には別の原因として切り分けられます。

認識が悪いのか。推論が遅いのか。 action reuse が固着しているのか。 Worker の反映が遅れているのか。 GPU path から CPU fallback に落ちているのか。

これらを追うためには、フレームごとの軽量 telemetry が必要です。

ただし、この snapshot / telemetry の話を深く扱うのは後日に回します。

今日はあくまで、WASM + WebGPU + Bonsai + AutoPlay の実行層が主役です。

残る課題は「実装」ではなく「運用チューニング」へ

ここまでの低レイヤ改善は、公開時点でおおむね実装段階に入っています。

次に必要なのは、機能を追加することではなく、長時間実行と環境差の中でチューニングすることです。

Worker 境界をまたぐ latency の計測
GPU 内 palette 展開の環境別検証
action reuse policy の品質調整
snapshot schema の圧縮と永続化
fallback 発生条件の比較
HUD / status / telemetry の表示同期

低レイヤ実装は、書いた瞬間に終わるものではありません。

実行し、観測し、詰まりを見つけ、少しずつ安定化していくものです。

この意味で、Day 2 の成果は「機能が入った」ことではありません。

ブラウザ上で、WASM ランタイム、小型モデル、GPU 視覚パス、AutoPlay 制御、telemetry を同じループで回せるところまで来た ことです。

20. Day 2：AIKernel に身体を与える

昨日は、AIKernel に耳を与えました。

今日は、AIKernel に身体を与える日です。

WASM で動く環境がある。 WebGPU で視覚入力を持てる。 Bonsai-1.7B がローカルで判断する。 AutoPlay loop が action を返す。 doom_tick() が世界を進める。 doom_input() が身体を動かす。

この接続が成立したことで、AIKernel は「認識する」だけでなく、「ローカル環境の中で動く」段階へ入りました。

もちろん、まだこれは小さなデモです。

しかし、小さいことには意味があります。

小さいからローカルで動く。小さいからブラウザに載る。小さいから観察できる。小さいから改善できる。

WASM 版 DOOM と Bonsai-1.7B は、そのための非常に良い組み合わせでした。

結語：本当にローカルで動いている

今回の取り組みでは、ブラウザだけで完結する、クラウド不要の自律エッジ AI 環境を構築しました。

WASM 版 DOOM。 WebGPU。 Bonsai-1.7B。 VRAM resident vision path。 zero-copy。 CPU fallback。 AutoPlay runtime。

これらを接続することで、画面をローカルで観察し、ローカルで推論し、ローカルで行動するループを作ることができました。

これは単なるゲームハックではありません。

小さな WASM アプリケーションと小型モデルを接続し、ブラウザ上で自律制御のループを回すための実験場です。

Day 2。 AIKernel に身体を与える日。

次回は、この身体が出した action を、なぜそのまま実行してはいけないのか、という話に進みます。

敵を発見した。撃つべきか。

その問いから、AIKernel の次の層が始まります。

AIKernel.NET は Bing Webmaster Tools / IndexNow に対応しています。
記事更新は検索エンジンへ即時通知され、最新情報が迅速にインデックスされます。