WebGPU とオンデバイス AI: ブラウザーは本格的なランタイムになりつつあります

長年にわたり、ブラウザーはアプリケーションの良い顔であり、クラウドは困難なことが起こる場所でした。ユーザーはファイルを書き込み、クリックし、アップロードします。フロントエンドはすべてをサーバーに送信します。サーバーはモデルを呼び出します。答えが返ってきます。

このスキームは依然として非常に便利ですが、無料ではありません。すべての通話には、遅延、コスト、ネットワーク依存性、プライバシーに関する問題が伴います。ユーザーが文章を書いていて提案が必要な場合、0.5 秒が重要です。何千もの小さな入力を分類している場合、1 セントが実際のお金になります。テキストが機密性の高い場合、デバイスから送信することは中立的な選択ではありません。

WebGPU とオンデバイス AI が誇大広告になっているのはこのためです。明日にはすべてのモデルをブラウザで実行するからではありません。インテリジェントな機能の一部はユーザーに近づくことができるためです。

すべてがローカルになる必要はない

この議論の子供っぽいバージョンは、「クラウド対デバイス」です。便利なバージョンはハイブリッドです。

いくつかのタスクは、デバイス上で見栄えがします: 短い要約、言語検出、軽い書き換え、単純な分類、画像フィルター、小さな視覚モデル、即時フィードバックを伴う創造的なエクスペリエンス。

複雑な推論、フロンティア モデル、サーバー側のデータ、一元的な監査、均一な品質、各ステップを慎重に制御する必要があるワークフローなど、その他のタスクは依然としてクラウドの方が優れています。

健全なアーキテクチャは実行時に次のことを決定します。

ブラウザがクラウドに勝つ必要はありません。クラウド上で行う必要のない作業をクラウド上で行わないようにする必要があります。

WebGPU が重要な理由

WebGPU は、ブラウザから GPU を使用するための最新の API です。それは単に 3D グラフィックスを美しくするためだけではありません。また、GPU が得意とする並列ワークロード、シェーダー、パイプラインなど、コンピューティングに適したプリミティブを公開するため、これも重要です。

AI、科学的ビジュアライゼーション、3D エディター、ビデオ フィルター、クリエイティブ ツールでは、この違いが感じられます。 WebGL は Web に多くの貢献をしてきましたが、WebGPU は現在により適したモデルとして誕生しました。

ただし、最初に作成するのはシェーダーではありません。これは地味な特徴検出です。

export async function requestWebGpuDevice() {
  if (!('gpu' in navigator)) {
    return null;
  }

  const adapter = await navigator.gpu.requestAdapter({
    powerPreference: 'high-performance',
  });

  if (!adapter) {
    return null;
  }

  return adapter.requestDevice();
}

この機能は、WebGPU がすべてのデバイスに与えられる権利ではないという重要なことを示しています。確認できる能力です。一部のブラウザーはこれを完全にサポートしておらず、一部の GPU には制限があり、一部のエンタープライズ環境では機能が無効になっており、一部のユーザーは控えめなハードウェアを使用しています。

組み込み AI: ブラウザーがモデルを持ち込むとき

Chrome は、ローカル プロンプト、要約、書き込み、書き換え、翻訳、言語検出、校正などのタスク用の組み込み API をプッシュしています。このアイデアは非常に興味深いものです。ブラウザーがモデル、可用性、更新を管理します。アプリはプラットフォームに近い API を使用します。

うまく機能すると、大きく変わります。

• 単純なタスクのためのサーバー呼び出しが少なくなります。
• デバイス上に残る可能性のあるデータ。
• レイテンシが低い。
• オフラインまたは半オフラインのエクスペリエンス。
• 執筆と翻訳のためのより自然な UX。

ただし、これは漸進的な強化として扱う必要があります。一部の API は安定していますが、他の API はオリジンのトライアル版またはプレビュー版であり、その他の API は依然としてバージョン、言語、デバイスに依存します。

type LocalCapability = 'available' | 'downloadable' | 'unsupported';

export async function getLocalSummarizerCapability(): Promise<LocalCapability> {
  const SummarizerApi = (globalThis as any).Summarizer;

  if (!SummarizerApi?.availability) {
    return 'unsupported';
  }

  const availability = await SummarizerApi.availability();

  if (availability === 'available') return 'available';
  if (availability === 'downloadable') return 'downloadable';

  return 'unsupported';
}

特定のコードは変更されますが、パターンは変わりません。可用性を確認し、ダウンロードについて説明し、フォールバックを提供し、品質を測定します。

フォールバックは悲しいプラン B ではありません

クラウドのフォールバックは敗北ではありません。製品の一部です。

interface AiRequest {
  task: 'summarize' | 'rewrite' | 'classify';
  input: string;
}

interface AiResult {
  output: string;
  runtime: 'local' | 'cloud';
}

export async function runAiTask(request: AiRequest): Promise<AiResult> {
  const local = await tryLocalAi(request);

  if (local) {
    return { output: local, runtime: 'local' };
  }

  const cloud = await fetch('/api/ai', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(request),
  }).then((res) => res.json());

  return { output: cloud.output, runtime: 'cloud' };
}

このアーキテクチャにより、段階的に改善することができます。ローカル サポートがある場合は、遅延とプライバシーが向上します。持っていない人も引き続きこの機能を使用します。ローカルリクエストのパーセンテージ、時間、エラー、メモリ、知覚品質、コストを測定できます。

指標がなければ、オンデバイス AI は美的な選択肢になります。メトリクスを使用すると、それが製品のレバーになります。

モデルのUXが重要

ブラウザがモデルをダウンロードする必要がある場合、ユーザーはそれを認識します。漠然としたスピナーの後ろに隠さないでください。 「この機能をより高速に、さらにはオフラインでも使用できるようにモデルを準備しています。」と明確にしたほうがよいでしょう。

良い経験:

• 準備状況を示します。
• ページ全体をブロックしません。
• クラウド フォールバックを続行できます。
• バッテリーとメモリの予期せぬ事態を回避します。
• 可能な限りモデルを覚えておいてください。
• 利点を具体的な一文で説明してください。

最悪なのは、何も言わずに何かをダウンロードするため、「スマート」機能が壊れているように見えることです。

プライバシー: 自動的に保護されるものではなく、より優れたもの

デバイス上でデータを処理すると、大きな利点が得られます。電子メールの下書き、社内文書、または個人的なメモは、ブラウザを離れることなく提案を受け取ることができます。

ただし、ローカルだからといって自動的に安全であるとは限りません。ただし、次のことを考慮する必要があります。

• XSS;
• 偶然のログ。
• ストレージに保存されたデータ。
• 信頼できないコンテンツからの即時挿入。
• モデルに付与された権限。
• 自動アクションで使用される出力。

ローカル モデルが Web ページを読み取ってフォームに記入できる場合、そのページは Web ページを操作しようとする可能性があります。ツールを呼び出せる場合は確認が必要です。構造化された出力が生成される場合は、検証する必要があります。デバイス上で実行されるという事実により、プライバシー リスクがある程度軽減されますが、セキュリティ モデルが排除されるわけではありません。

本当に面白くなるのはどこですか

テキストは始まりにすぎません。 WebGPU により、最近までネイティブ アプリのように思われていた Web エクスペリエンスが信頼できるものになります。

• 複雑な 3D エディター。
• ブラウザ内でのガウス スプラッティング。
• リアルタイムビデオフィルター。
• 軽量 CAD。
• 科学的な視覚化。
• インスタントプレビューを備えたクリエイティブツール。
• UI付近の視覚推論。
• より野心的なブラウザゲーム。

ここで、フロントエンド、グラフィックス、機械学習が混ざり始めます。これはやや扱いにくい領域ですが、豊かな領域でもあります。ブラウザは、フォームやダッシュボードを配置する場所だけでなく、本格的なアプリケーション プラットフォームに戻ります。

制作前のチェックリスト

オンデバイス機能をユーザーに公開する前に、私は次のことを確認します。

1. 対象のブラウザとデバイス。
2. クラウドのフォールバックまたはエレガントな劣化。
3. ダウンロード時間とモデル キャッシュ。
4. 平均的なハードウェアのメモリとバッテリー。
5. クラウド版と比較した品質。
6. プライバシーポリシーとユーザーメッセージ。
7. 敵対的な入力によるテスト。
8. ローカル ランタイムとクラウド ランタイムのメトリクスを分けます。
9. テンプレートを更新するか無効にすることを計画してください。

問題が具体的であるため、これは具体的なリストです。遅い、壊れやすい、または不透明な AI 機能は、ブラウザーで実行されるからといって改善されるわけではありません。

適切な妥協

私は、未来が「すべてがデバイス上にある」とは考えていません。また、クラウドが推論に適した唯一の場所であり続けるとは思えません。最も可能性の高い将来は、その混合です。遅延、プライバシー、またはコストが改善される場合はローカル、そしてローカルな場合はローカルです。品質、更新されたデータ、一元管理が必要な場合は、クラウドを使用します。

WebGPU、WebNN、および組み込み AI API によってブラウザーが全能になるわけではありません。彼らは彼をより大人にします。そして、Web 製品を構築している人にとって、これは大きなニュースです。

役立つ情報源

• WebGPU API - MDN
• WebGPU 仕様 - W3C
• 組み込み AI - 開発者向け Chrome
• 組み込み AI API - 開発者向け Chrome
• WebNN API