動く、と、使える、は違う
2本目で、WebLLM は「動いた」。集計JSONを日本語に翻訳できました。 でも「実用になるか」は、まったく別の問題です。
実用の条件は3つ。待てる初回DL・許せる生成速度・信頼できる品質。 これが揃って初めて「使える」。2つの実機で、これを数字にします。
何を、どう測るか
2つの実機は、GPUアーキもブラウザも違います。Pixel 10 Pro（Android Chrome）と iPad mini A17 Pro（Safari）。ここで同じモデル・同じプロンプトを揃えて測ります。
3つの指標
LOAD TIME（初回DL＋GPU展開／キャッシュ後は短縮）、 PREFILL（入力処理 tok/s）、 DECODE（生成 tok/s＝体感速度）。加えて品質を、2本目の4段階評価で見ます。
q4f32_1）に揃えています。これは前編で
Pixel 10 の fp16 埋め込みが NaN を返した教訓から。モバイルGPUでは、fp16 が罠になることがあります。
「条件を揃える」のは、TF.js 記事の normalize と同じ思想です。
同じモデルで、速度が8倍違う
最も衝撃的だったのがこれです。まったく同じモデルなのに、端末で生成速度が8倍違った。
| モデル | サイズ | iPad decode | Pixel decode | 倍率 | 品質 |
|---|---|---|---|---|---|
| Qwen 0.6B | 315MB | 39.8 | 4.9 | 8.1× | 思考が漏れる |
| Qwen 0.8B | 420MB | 22.6 | 3.0 | 7.5× | やや不正確 |
| Qwen2.5-1.5B | 787MB | 21.8 | 2.6 | 8.4× | ★品質良好・最安定 |
| Qwen 1.7B | 892MB | 20.8 | 17.5 | 1.2× | 多言語で崩壊 |
iPad mini: 21.8 tok/s（サクサク読める）／ Pixel 10: 2.6 tok/s（1文字ずつ待つ体感）
差は 8.4倍。Pixel の 2.6 tok/s は、実用に耐えるレベルではありません。
なぜ Pixel 10 はこんなに遅いのか
これは TF.js 記事やティックベンチで見た「GPUアーキの差」と同じ根です。 WebGPU の効き方は端末で大きく異なり、Pixel 10 は WebLLM のワークロードと相性が悪い。 同じコード・同じモデルでも、GPUが変われば体感がまるで別物になります。
唯一 1.7B だけ、Pixel が 17.5 tok/s と急に速くなり、差が 1.2倍に縮みます（小型では 2.6〜4.9 だったのに）。特定のモデル構成で Pixel 10 のカーネルが効く瞬間がある——モバイルGPUの不可解さが、ここに出ています。ただし 1.7B は品質が「多言語で崩壊」で、速くても使えません。
初回DLという、税金
速度と並ぶもう一つの壁が、初回ダウンロードです。iPad mini（Safari・LTE）で実測した cold ロードは、 モデルサイズにほぼ比例して膨らみました。
Qwen2.5-0.5B（262MB）: 247.5s／ Llama-3.2-1B（525MB）: 533.5s
サイズが2倍になると、DLも約2.16倍。1B で 533秒（約9分）は、UXとして重すぎ、初回離脱の懸念大です。
注意すべきは、この数字が回線とキャッシュで激変すること。同じ 0.5B でも、条件が良ければ 10.5秒で載りました。2回目以降はブラウザキャッシュ（IndexedDB）からほぼ即時。 つまりDLは「初回だけの税金」ですが、その初回が数分では、多くの人が離脱します。
速くても、間違えたら意味がない
iPad は速い（0.5Bで47 tok/s）。でも、その速さで何を生成したかが問題です。 小型モデルに「WebLLMとは?」と一般知識を聞くと、露骨に破綻しました。
0.5B / 1B の実際の出力（iPad・実測）
0.5B は「WebLLMは大規模文書解析システムBERTと配合したAI」「2023年4月に初版」と堂々と作話。 1B は「Web LLMは、パズル、ラッセ…、パーソル化された…」と同語反復で崩壊。 速度は申し分ないのに、内容は信用できません。
2本目の「集計JSON解釈」タスクでは 1.5B が実用でした。一方この一般知識タスクは、より露骨に破綻する。 品質はタスク依存でもあり、モデルサイズ依存でもある。そして品質は、端末（GPU）を変えても改善しません—— GPUは速度に効くが、賢さには効かない。
どの端末で、どのモデルが実用か
3軸（DL・速度・品質）を掛け合わせると、実用の地図が描けます。
| 端末＼モデル | 0.5B | 1B | 1.5B | 擬似生成 |
|---|---|---|---|---|
| iPad mini | △ | △ | ○ | ◎ |
| Pixel 10 | ✕ | △ | ✕ | ◎ |
◎実用 ／ ○条件付き実用 ／ △速いが品質難 ／ ✕遅い・非推奨
推奨構成
結論はシンプルです。既定は擬似生成——全端末で即座に、正確に要点を返す。 その上で、オプションで 1.5B を「iPad など速いGPUで、載れば表現が豊かに」。 これは2本目で組んだフォールバック設計そのもの。実測が、あの設計判断を裏付けました。
実機ベンチと、実用の地図
速度×品質の散布図で「擬似生成が基準線」を確かめ、任意でこの端末での decode 速度も測れます （実WebLLM対応環境のみ・初回はDL）。
散布図の右上——瞬時かつ正確な擬似生成が、越えるべき基準線です。0.5B は右下（速いが低品質）、 1.5B は上方（正確だが遅め）。あなたの端末で 1.5B を測ると、この地図のどこに乗るかが分かります。
非力から始まった委譲は、こう着地した
動く≠使える。初回DL・生成速度・品質の3軸で見ると、WebLLM ログ分析の実用ラインがはっきりしました。 GPUは速度に効くが品質はモデル依存。実用下限は 1.5B、基準線は擬似生成。 そして端末差は残酷なほど大きい（decode 8倍）。
この記事のまとめ
- 同じモデルでも decode が端末で8倍差（iPad 21.8 vs Pixel 2.6 tok/s）。Pixel 10 は WebLLM と相性が悪い。
- 初回DLはサイズに比例し1Bで533秒。回線依存・要フォアグラウンド。初回離脱の懸念。
- 小型は速くても作話・崩壊。GPUは速度に効くが賢さには効かない。
- 実用の地図：擬似生成が全端末◎の基準線、1.5Bはapple GPUで条件付き実用。
- 既定=擬似生成、オプション=1.5B。2本目の設計を実測が裏付けた。
- 集計API — MongoDBは答えだけを返す
サーバー：生ログを出さず集計JSONだけ - ブラウザが推論を引き受ける
クライアント：WebLLMで言語化＋擬似フォールバック - 2つの実機で実用になるか（この記事）
検証：8倍差・533秒DL・品質、実用の見極め
「非力なVPSに載せられないから、クライアントへ逃がす」——そう始めた委譲は、実機でこう着地しました。 逃がした先のGPUにも、大きな当たり外れがある。だからこそ、擬似生成という揺るがない土台を持ち、 LLMは載れば彩りを添える。制約から出発した設計が、実測でその正しさを示した連載でした。
