ブラウザでLLMは
動くか

前編では、 RAGの「検索」部分をブラウザだけで動かせることを確認しました。 残るは「生成」——LLM本体です。これもブラウザで動くなら、 サーバー不要のAIアシスタントが完成します。

以下は実際に動くデモです。あなたの端末で小型LLMをロードし、速度とメモリ限界を実測できます。 モデルはサイズ順に並んでおり、最小モデルから試すことを推奨します。

Pixel 10（Chrome）と iPad mini A17 Pro（Safari）で、 5つのモデルを小さい順にロードし、生成まで試しました。 すべて q4f32_1（4bit量子化・fp32演算）を選択—— 前編でPixel 10のfp16埋め込みがNaNを返した教訓から、f16を避けました。

最も衝撃的だったのは、まったく同じモデルなのに、端末で生成速度が8倍違ったことです。

興味深いのは、両端末とも shader-f16 に対応し、Device Memory も Pixelは8GBあった点です。スペック上はPixelが不利ではないのに、この差が出ました。 WebGPU経由のLLM推論は、現状Apple GPUに強く最適化されていると考えられます。 同じ「ブラウザで動く」でも、Androidミドル機では体感が伴わない—— これは前編のベクトル検索で見た「カーネルが端末で逆転する」現象と同じ根っこです。

モデルの品質はパラメータ数に比例しませんでした。 むしろ新しくて大きいはずの Qwen3 系が、小型量子化で壊れました。

検証の判定基準そのものが、途中で変わりました。当初は「ロードできたか」で見ていましたが、 それでは不十分だと分かったのです。

そこでデモの判定を「生成まで成功して初めて実用可能」に改めました。 ロードのプログレスバーは、実用性の保証にはなりません。

// ❌ ロード成功で判定してしまうと 2B が「可」になる（実際は生成で落ちる）
// ✅ 生成の try が最後まで通って初めて recordVerdict(true)
try {
  for await (const chunk of stream) { /* ...トークン受信... */ }
  recordVerdict(true);   // 生成完了 = 実用可能
} catch (e) {
  recordVerdict(false);  // 生成でクラッシュ = メモリ上限超過
}

速度と品質の裏で、初回ロード時間が実用性に重くのしかかります。

2つの実機で限界まで試した結論です。 ブラウザ完結LLMは、技術的には確かに動きます。 iPad mini なら1.5Bモデルが 21 tok/s・良好な品質で動作しました。これは事実として大きい。

しかし実用の壁は高いと分かりました。3つの現実が重なります。