AI推論は異なるルールに従う（9 分間の読了）

パートナーコンテンツ NVIDIA CEO のジェンソン・ファン氏は [最近]、私たちは「AI ファクトリー」の時代に入っていると宣言しました。この時代において、グローバルなテックエコノミーの主要な出力はソフトウェアではなく、知能そのものです。彼は正しいです。しかし、世界が GPU クラスターやトリリオンパラメータモデルに夢中になっている一方で、AWS、Azure、Google Cloud の環境内では、さらに下層で巨大かつ静かなる危機が進行しています。 AI エージェントはあなたのデータインフラストラクチャを襲います。そして、基盤となるストレージおよびデータアクセスレイヤーを圧倒するでしょう。 私たちは [AI データ津波] の瀬戸際に立っています。単純なチャットボットから自律的な多段階 AI エージェントへの移行により、推論（inference）はもはやステートレスで計算のみに関わる問題ではありません。それは巨大で予測不可能かつ前例のないデータの問題です。人間の速度のアプリケーション向けに構築された基盤となるデータインフラストラクチャは、次に起こる事態に対して準備ができていません。 パブリッククラウド上で AI を愛らしい概念実証（PoC）からエンタープライズグレードのプロダクションへ移行する際の、残酷な真実をここに示します。 ## 推論は OLTP++：前例のない並行処理のために計画せよ 過去20年間、私たちは人間の行動に合わせてデータシステムやストレージ層を最適化してきました。人間は遅いものです。ボタンをクリックし、ページの読み込みを待ち、画面を読み、そして30秒後に再びクリックするかもしれません。大規模なスケールであっても、人間のトラフィックは予測可能な日次パターンに従います。キャッシュして平均化することも可能です。 一方、AI エージェントはコーヒーをすすんだり、読む時間を取ったりしません。 自律型エージェントが ReAct（推論と行動）ループを実行すると、クエリを発信し、コンテキストを取り込み、追加情報が必要だと認識すると、ミリ秒のうちに並列でさらに3つのクエリを発信します。これを、EC2 フリート全体で同時に動作する数千ものエージェントに掛け合わせるとどうなるでしょうか。 顧客たちは、AI 推論が OLTP++ のように振る舞うことを肌で実感しています。前例のない並行処理能力、大規模な読み取りスパイク、予測不能なアクセスパターンを示します。CloudWatch や歴史的な CPU 利用率に基づく管理に優しい平均値を基にキャパシティプランニングを行っている場合、それは盲目で飛行しているようなものです。I/O 需要に対する突然の極端なスパイクに対応できるアーキテクチャを構築する必要があります。なぜなら、エージェント時代のピーク負荷こそが唯一重要となる負荷だからです。 ## ベクターデータベース & RAG: プロンプトだけでなくデータパスを設計する 現在、AI エコシステムはプロンプトエンジニアリングやモデルのファインチューニングに夢中になっています。しかし、Retrieval-Augmented Generation (RAG) アプリケーションをローカルの Jupyter ノートブックから AWS の本番環境へ移行すると、すぐに厳しい現実に直面します：ボトルネックは Python ではありません。LLM でもありません。 ボトルネックは、データがどのように保存され、アクセスされ、基盤となるストレージ層を横断して移動するかにかかっています。これにはインデックススキャン、埋め込みベクトルの取得、および散乱・集約（scatter-gather）の遅延が含まれます。 Hierarchical Navigable Small World (HNSW) や、相関メタデータフィルタリングと組み合わせた Flat 量子化を備えた Inverted File (IVFFlat) などのベクトル類似度検索を実行すると、データアクセス層に対して非常に複雑でメモリ集約型の操作を強いることになります。AWS でホストされたスタックの場合、ホットなベクトルに対するミリ秒未満の読み取りと、データセットが数億行に成長しても予測可能なスループットを実現することが目標となります。 多くのエンジニアリングチームは、AWS Relational Database Service (RDS) の読み取りレプリカを主要なスケーリング戦略として扱っています。はっきり言っておきましょう：レプリカは最後の手段であり、戦略ではありません。さらに重要なのは、基盤となるストレージやデータアクセス層への対応を怠ったままデータベース階層のスケーリングを図っても、ボトルネックが除去されるのではなく、単に場所が変わるだけだということです。「読み取りノードを追加して、あとは神頼み」というアーキテクチャ計画しかない場合、あなたはちょうど次のトラフィックピークで壊滅的な事後分析（post-mortem）を待つ状態にあります。 リスクのないベクトル検索によって既存のアプリケーションを強化し、AI イノベーションを解放する必要があります [こちら](https://silk.us/blog/vector-search-ai-integration/)。そのためには、高次元数学の物理法則に耐えうるデータパスを設計することが必要です。 ## AWS EBS における現実確認 AWS は素晴らしいプラットフォームですが、Elastic Block Store (EBS) は現代のクラウドにおける主力ストレージです。しかし、EBS は物理法則とクラウド経済学の法則に縛られています。 EBS ボリュームはバーストバッケットと厳格なボリュームごとの IOPS およびスループット制限に依存しています。これらのメカニズムはマルチテナントのクラウド環境を保護するために存在しており、お客様のアプリケーション SLA には関わりません。 AI エージェントが暴走したり、推論トラフィックの急激な増加がデータレイヤーに襲来したりすると、EBS のバーストクレジットは数分で枯渇します。一度バッケットが空になると、ストレージパフォーマンスは崖から転げ落ちるような形で低下します。レイテンシは 1 ミリ秒から 50 ミリ秒へと急上昇し、アプリケーションはストレージの応答を待って停止します。アプリケーションサーバーはワーカースレッドを使い果たし、スタック全体がロックアップします。 IOPS を増やすために単にスライダーをスライドさせるだけでこの問題を解決することはできません。ある時点で、単一の EC2 インスタンスとそれに接続されたストレージが物理的に押し出せる量には明確な限界があります。 ## AWS のストレージ制限からの分離 AWS が恒久的な拠点であっても、[AI 推論](https://silk.us/blog/ai-inferencing-enterprise-architecture/) はエンタープライズアーキテクチャへの需要を再構築しています。推論ワークロードは極度のパフォーマンスを要求します。もしデータアーキテクチャがネイティブ EBS SKU の物理的な制限に密結合している場合、あなたは閉じ込められてしまいます。 この罠から抜け出すには、AWS インフラストラクチャの上に位置し、莫大なレバレッジをもたらすソフトウェア定義ストレージ抽象化が必要です。[アプリケーションおよびデータのパフォーマンスをネイティブな AWS ストレージの制限から切り離す](https://silk.us/blog/aws-performance-bottlenecks-at-scale/) ことで、EC2 の容量逼迫、IOPS（1 秒間の入出力操作数）価格の高騰、およびインスタンスタイプへのロックインからアプリケーションを保護できます。 ## 唯一重要なる KPI: 混合負荷下における p99/p999 平均レイテンシを見るのをやめましょう。平均値は、自分自身や経営層に対してインフラストラクチャの状況を良く見せようとして私たちが語る嘘です。 ユーザーも AI エージェントも外れ値（アウトライヤー）を感じ取ります。1% のクエリが 3 秒を要し、アジェンシー推論チェーン全体をブロックしてしまう場合、2 ミリ秒の平均レイテンシなど何の意味も持ちません。テールレイテンシ（p99 および p999）を厳格なリリース阻止条件として確立する必要があります。 問題が発生する場所、特にストレージおよびデータアクセス層においてテールレイテンシを追跡する必要があります。アイドル状態のシステムをベンチマークしても無意味です。現実世界の過酷な条件下での p99 を測定する必要があります: - 並行 OLTP（オンライン取引処理）＋推論＋メンテナンスジョブ: 大規模なバッチ更新や真空プロセスが起動した際、ベクトル検索にはどのような影響が生じるか？ - AZ（アベイラビリティゾーン）間の変動: フェイルオーバーイベント発生時や AWS が配置グループの割り当てを変更する際に、レイテンシはどのように劣化するか？ - オートスケーリングイベントおよびキャッシュウォームアップ: 新しい EC2 ノードが起動した際、キャッシュがウォームアップされるまでどの程度の時間がかかるか、その間ストレージ層はどれほど影響を受けるか？ もしあなたのプラットフォームがこれらの混合負荷条件下でテールを厳密に管理できないなら、ステージ上でのデモがいかに素晴らしく見えたとしても、推論用として本番環境で使えるものではありません。 ## 顧客の悪夢：成功による災害 現在業界全体で進行しているあるシナリオを見てみましょう。関与する企業を「FinRetail」と呼びましょう。これは組み込み型フィンテックを持つ巨大な e コマースプラットフォームです。 FinRetail は素晴らしい AI ショッピングアシスタントを構築しました。これは RAG（Retrieval-Augmented Generation）を使用して、ユーザーの購入履歴、リアルタイム在庫、およびライブ価格データを相互参照します。概念実証は完璧でした。取締役会は大喜びし、火曜日にリリースしました。 火曜日の午後には、「成功による災害」が発生していました。AI エージェントがあまりにも徹底しすぎていたのです。「1,000 ドル以下の大学生向けに最適なラップトップは何ですか？」という単純な質問に答えるために、エージェントは 40 ステップの推論ループを実行し、PostgreSQL データベースに対して数百回のベクトル類似度検索を発行しながら、同時にリアルタイム在庫レベルも確認していました。 その並行処理能力は前例のないものでした。わずか 15 分以内に FinRetail は EBS バーストクレジットを枯渇させ、読み取りレイテンシが 0.8 ms から 120 ms に急上昇しました。システムは飽和状態となり、I/O ウェイト状態の管理に必死になるばかりでした。サイト全体がダウンし、収益を生む中核となる OLTP（Online Transaction Processing）システムも巻き込まれました。 彼らは読み取りレプリカを追加しようと試みましたが、根本的なストレージの制約は解消されず、AI エージェントは古くなった在庫データに基づいて幻覚を起こし、数時間前に売り切れた製品を推奨するようになりました。これは完全に、現代的な推論ワークロードに対応できないストレージ層によって引き起こされた、総括的な事後分析シナリオでした。 ## Silk がこのリスクをどのように異なるアプローチで解決するか AI データの問題を、単に管理ディスクを追加して解決することはできません。根本的なアーキテクチャの転換が必要です。パフォーマンスと容量を分離する必要があります。 [これがまさに Silk の行うことです。](https://silk.us/platform-technology/) Silk は、EC2 コンピューティングリソースと基盤となるインフラストラクチャの間に位置するソフトウェア定義型クラウドストレージです。複数の基盤となるクラウドリソースのパフォーマンスを加速し、[それらを単一の、信じられないほど高速で極めて耐障害性の高いデータ層として提示します。](https://silk.us/resources/silk-cloud-data-platform-architecture/) 私たちが「高速」と言うとき、それは些細な改善について話しているのではありません。クラウド物理学の絶対的な限界を押し広げることを意味しています。最近、データベースの専門家である Tanel Poder 氏が Silk のテストを行い、それが実際にどの程度の処理能力を持つかを確認しました。その結果は驚異的で、[20 GiB/s の I/O スループット](https://silk.us/webinars/how-i-achieved-20-gbs-throughput-tanel-poder/) を達成しました。 Silk を利用すれば、単一の EBS ボリュームの IOPS 制限に縛られることはありません。[Silk の対称型アクティブ・アクティブアーキテクチャ](https://silk.us/wp-content/uploads/2022/08/Silk-Overview-2.pdf) と大規模な分散キャッシュ層が、AI インフェレンスにおける前例のない並行性を吸収します。ホットベクトルを直接メモリから提供し、重い OLTP ワークロードとメンテナンスジョブを同時に実行している場合でも、一貫したサブミリ秒の p99 レイテンシを実現します。 私たちは、世界で最も要求の厳しいデータ集約型アプリケーションにおいてこれを証明しています。[Silk 上の Postgres で高性能 AI ベクトル検索の限界に挑戦](https://silk.us/blog/high-performance-ai-vector-search-postgres/) している場合でも、[Google AlloyDB を活用してさらに大規模な [Postgres AI ワークロード](https://silk.us/blog/high-performance-ai-vector-search-postgres/) をスケーリングしている場合でも、結果は同じです：極限のスケールにおけるエンタープライズグレードの予測可能性。 Silk は、ストレージパフォーマンスを向上させるために EC2 コンピューティングを過剰にプロビジョニングする必要性を排除します。また、コアデータパスのために脆弱なリードレプリカに依存する必要もなくなります。これにより、AWS 上で AI ワークロードを実行する際にも、同じエンタープライズデータサービスとパフォーマンス保証をそのまま利用することが可能になります。 ## 祈るのをやめてエンジニアリングを始めよう AI インフラ推論の津波はすでに到来しています。これを生き残るシステムは、激しい同時実行性、膨大なスループット、妥協なきテールレイテンシのために設計された、現代的なソフトウェア定義型クラウドストレージアーキテクチャの上に構築されたものです。 自分の「成功による災害」を待って AWS ストレージがボトルネックだと気づくのをやめましょう。今こそ、その下を見て、AI 対応データプラットフォームがどのようなものかを確認する時です。 証拠をご覧になる準備はできましたか？Microsoft のチーフデータ＆AI オフィサーである Eduardo Kassner 氏と、Silk の製品担当バイスプレジデントである Tom O'Neill 氏が、なぜ AI インフラ推論がシステム動作を再構築しているのか、またなぜ解決策が単なるレプリカの追加や新しいストレージシステムの採用、あるいはアプリケーションの書き換えではないのかについてお聞きください。 **今すぐウェビナーをご覧ください：** **[AI インフラ推論はあなたのアーキテクチャを壊したのではなく、次に来るものを明らかにしました。](https://silk.us/webinars/ai-inferencing-didnt-break-your-architecture/)** *Silk 提供*

AI推論は異なるルールに従う（9 分間の読了）

背景や根拠まで確認しますか？

このニュースを、実務の判断につなげる

調べる

選ぶ

サイト