あなたはAI製品を出荷し、10人の顧客が登録した。
11番目の顧客がプロンプトを送信し、ランタイムをクラッシュさせた。
AIランタイムを共有するとこうなる。
共有ランタイムは基本的にお荷物
ほとんどのチームは、1つのAIランタイムを全テナントで共有することから始める。
ただし、テナントが実際の仕事を始めた途端、「出荷して次に進む」が「午前3時にデバッグする」に変わる。
私は常にこのような状況を見てきた：
**プロンプト・インジェクションはテナントの垣根を越える。**テナントAがプロンプトを作成し、ランタイムの動作を台無しにすると、テナントBはその壊れた状態を継承する。
**あるテナントが重いワークロードを実行すると、他のテナントが飢餓状態になる。
**envバー、APIキー、モデル設定 - 共有ランタイムでは、1つの誤った設定のエンドポイントによって、テナントBの秘密がテナントAに漏れる可能性がある。
**テナントごとにカスタマイズすることはできません。**異なる顧客は、異なるモデルバージョン、異なるシステムプロンプト、異なるレート制限を必要とします。共有ランタイムは、同じコンフィグで皆を強制します。
孤立は "いいとこ取り "ではない。
各テナントが独自のランタイムを取得すれば、これらの問題はすべて解決する。
**テナント間の汚染はありません。**テナントAsプロンプト・インジェクションはテナントAsコンテナ内に留まります。
**各テナントがCPU、メモリ、ストレージを専有する。
**テナントAは文字通りテナントBのコンフィグにアクセスできない。分離はアプリケーション・レベルではなくインフラ・レベルで行われる。
**顧客ごとに異なるモデル・バージョン、システム・プロンプト、料金制限、機能フラグを設定することができます。
"分離は後回し "の本当の代償
コンテナが増えればインフ ラが複雑になる。
しかし、孤立させないことの代償ははるかに大きい。
一時的ではなく、恒久的に。クロステナントのクラッシュが1件起きれば、SLAは意味をなさなくなる。
今、マルチテナントAIで勝っている企業は、分離を初日の要件として扱っている。
ShipClawの処理方法
ShipClaw は、顧客ごとに 1 つの独立した OpenClaw ランタイムを自動的に提供します。
各顧客が得るもの：
- 専用のDockerコンテナと専用コンピュート
- TOKEN_0@@の永続ボリュームは、再起動後も存続する。
- *APIキー、モデル設定、シークレット用の分離された環境変数。
- 自動SSLによる
slug.agents.shipclaw.ioでのユニークなURL**。 - 独立したスケーリングにより、あるテナントの使用量が他のテナントの使用量に影響することはない。
Dockerfileを書いたり、kubernetesのマニフェストを管理したりはしない。ノードをキャンバスにドラッグして接続し、デプロイする。
ビジュアル・ビルダーはトポロジーを扱い、プラットフォームはアイソレーションを扱う。
ボトムライン
共有AIランタイムは、長期的な負債を生む近道である。テナントごとの分離は、実際に安全にスケールする唯一のアーキテクチャである。
複数の顧客のためにAI製品を作るのであれば、分離は機能ではなく、要件だ。
東建