ローカルモデル、クラウドGPU、そして「欠けている中間」

AIのプライバシーに関する議論は、しばしば「ローカルかクラウドか」という対立として語られます。ローカルはプライベートですが難しい。クラウドは便利ですがリスクがある。さあ、どちらの苦労を選ぶ？

しかし、その捉え方は単純すぎます。完全にローカルでの生成は、うまく動くなら素晴らしいものです。ユーザーがマシンを管理でき、ファイルは近くに留まり、外部の提供者が経路に入りません。とはいえ、ローカルモデルは重く、遅く、扱いが面倒で、高価で、チームにとってはプロダクト内の信頼できる機能を求めるだけなのに混乱を招きがちです。

一般的なクラウドAPIは、利便性の問題を解決します。マネージドされたモデル、稼働率、スケーリング、そして分かりやすい課金モデルを提供します。しかし、プロバイダーのルーティング、保持ポリシー、エンドポイント固有のデータ制御、そしてプライベートなソース画像やプロンプトがどのように移動するかに対する制御の弱さなどを持ち込む可能性があります。

「欠けている中間」とは、プライベートなクラウド実行です。クラウドGPUを使いつつ、コンテンツの経路を自社の境界の内側に保ちます。制御されたインフラ上でオープンウェイトのモデルを実行します。短寿命の計算（compute）を使います。プロンプトやソース画像を、第三者の画像プロバイダーに渡さないようにします。プロダクトを単なるギャラリーに変えずに、出力を返します。

この中間策は魔法ではありません。クラウドのリスクは依然としてあります。セキュリティ、アクセス制御、削除の規律、課金、可観測性、そして運用の力量が依然として必要です。違いは、デフォルトでモデル提供者に中核となる管理（custody）を渡すのではなく、チームがコンテンツ境界をコントロールする点にあります。

開発者にとっての問いは実務的です。ユースケースに必要な制御の度合いはどれくらいか？ おもちゃのようなジェネレーターなら、通常のプロバイダーのエンドポイントで足ります。顧客に向き合うプロダクト、機密性の高いブランド作業、クライアントのキャンペーン、あるいは規制のある文脈を扱う場合は、より良い答えが必要です。

ローカル・ファーストの思想は、顧客がそのスタックをインストールできないとなるまで魅力的かもしれません。クラウド・ファーストの利便性は、顧客が「自分のソース画像はどこへ行ったの？」と尋ねるまで誘惑的かもしれません。中間策が存在するのは、実際のプロダクトには使いやすさと制御の両方が必要だからです。

正しいアーキテクチャとは、トレードオフをためらいなく説明できるものです。

さらなる読み物: 創作上のコントロールにオープンウェイトモデルが重要な理由, プライベートクラウドでの画像生成、およびAWSのAmazon Bedrockデータ保護ドキュメント。