Well-Architected Framework:パフォーマンスの柱

理論的根拠

モデルのパラメーター数は、必要な GPU メモリ容量と計算能力を直接決定します。小さすぎるハードウェアは、メモリ不足エラーや CPU メモリへのオフロードなどの頻繁なメモリスワッピングを引き起こし、パフォーマンスが急激に低下します。大きすぎるハードウェアはリソースを浪費し、コストを増加させます。適切なハードウェアの選択は、パフォーマンス最適化の基盤です。

実装

パラメーター数とハードウェアのマッピングを確立します。7B パラメーターモデルは、単一の A10 GPU (16 GB メモリ) で推論を実行でき、軽量なアプリや開発/テスト環境に適しています。14B パラメーターモデルには、A30 (32 GB メモリ) または同等のものが必要で、中程度の複雑さの本番ワークロードに適しています。72B パラメーターモデルには、テンソル並列処理でデプロイされた少なくとも 2 つの A100-80GB GPU が必要で、最高の品質が求められるミッションクリティカルなシナリオに適しています。バッチサイズの選択にはトレードオフが伴います：バッチサイズを大きくすると GPU 使用率が向上します (30% から 80% 以上へ) が、リクエストごとのキューイングレイテンシが増加します (ほぼ即時の処理から数百ミリ秒の待機へ)。ご利用の SLA に基づいてバッチサイズの上限を設定することを推奨します。リアルタイムのチャットシナリオでは、バッチサイズを 8～16 以下に制限します。オフラインのバッチジョブでは、64～128 に緩和できます。

アンチパターン

すべてのシナリオで 1 つのハードウェア構成を使用すること。これにより、過剰なプロビジョニングでコストを浪費するか、不十分なプロビジョニングでパフォーマンスを損なうかのいずれかになります。レイテンシを犠牲にしてリアルタイムシナリオで最大スループットを追求し、バッチサイズの影響を無視すること。ピーク時のトラフィックを無視して、平均負荷でプロビジョニングすること。

Alibaba Cloud プロダクトマッピング

PAI-EAS は、さまざまな GPU インスタンスの仕様を提供し、auto scaling をサポートしています。Lingjun Intelligent Computing Cluster は、超大規模モデルのデプロイメントをサポートするための大規模 GPU クラスターを提供し、テンソル並列処理の効率を確保するための高速 RDMA ネットワークを備えています。

理論的根拠

ベースモデルは、多くの場合 FP32 または FP16 精度で保存および計算されるため、最適化の余地がかなりあります。量子化、コンパイル最適化、および推論アクセラレーション技術を使用することで、限定的な品質損失で数倍のパフォーマンス向上を達成し、推論コストとレイテンシを大幅に削減できます。

実装

量子化：FP16 から INT8 への量子化は、GPU メモリ使用量を半分に削減し、レイテンシを約 40% 削減します。典型的な品質損失は 3～5% で、ほとんどの本番シナリオに適合します。INT4 量子化は、メモリをさらに 4 分の 1 に削減し、レイテンシをさらに 30% 削減しますが、品質損失は 8～12% に達する可能性があります。テキスト分類や情報抽出など、より低い精度要件のワークロードに使用します。コンパイル最適化：TensorRT または ONNX Runtime を使用して、モデルの計算グラフを最適化します。演算子融合はメモリコピーを削減し、混合精度コンピューティングは Tensor Cores を最大限に活用します。KV-Cache 管理：PagedAttention を使用して、ページングで GPU メモリを管理します。この技術は、KV-Cache の断片化と浪費を回避します (従来の隣接した割り当てでは、GPU メモリの 30～50% が浪費されることがよくあります)。KV-Cache の量子化 (FP16 から FP8 へ) は、キャッシュのフットプリントをさらに削減し、より長いコンテキストウィンドウをサポートします。推測デコーディング：小さなドラフトモデル (1B パラメーターモデルなど) を使用して候補トークンシーケンスを迅速に生成し、その後、大きなターゲットモデルで並行して検証させます。検証に合格した場合は、トークンを受け入れます。そうでない場合は、拡散したポイントから再生成します。この技術は、元のモデルと同一の出力品質で 2～3 倍の高速化を実現できます。

アンチパターン

評価なしに最も積極的な量子化スキームを適用し、許容できない品質低下を招くこと。KV-Cache 管理を怠り、長い対話シナリオで GPU メモリ枯渇によるサービス中断を引き起こすこと。コンパイル最適化後に回帰テストを実行せず、数値精度の問題による散発的なエラーを招くこと。

Alibaba Cloud プロダクトマッピング

PAI-Blade は、量子化、コンパイル最適化、および推論アクセラレーション技術を統合したワンクリックのモデルの高速化機能を提供します。PAI-EAS に組み込まれた vLLM エンジンは、PagedAttention と継続的バッチ処理をサポートしています。DashScope 推論サービスは、さまざまな最適化技術が事前構成されています。

理論的根拠

体感的な「速さ」は、合計処理時間と同じではありません。心理学の研究によると、システムが 200 ms 以内に応答を開始し、安定して出力を続けると、たとえ合計生成に 10 秒かかっても、ユーザーはインタラクションを「速くてスムーズ」だと感じます。ストリーミング応答は、長い待ち時間を段階的な情報配信に変え、ユーザーがレイテンシをどのように認識するかを根本的に変えます。

実装

Server-Sent Events (SSE) プロトコルを使用して、トークンを段階的に配信します。重要な技術的ポイントは、体感的な「即時応答」のしきい値である TTFT を 200 ms 以内に保つことです。API ゲートウェイとロードバランサーを、長寿命の接続とストリーミングトランスポートをサポートするように構成します (応答バッファリングを無効にする)。クライアント側でインクリメンタルレンダリングを実装し、到着する各トークンを即座に追加して表示し、タイプライターアニメーション効果を使用して滑らかさを強調します。ネットワークのグリッチ中に受信したコンテンツを保持し、自動的に再接続してブレークポイントから再開するなど、ストリーム中断時のフォールバック戦略を実装します。複数ステップのエージェントワークフローでは、非生成フェーズ (ツール呼び出しの待機など) 中に進捗状況の更新を提供し、ユーザーが空白の画面を見つめないようにします。

アンチパターン

生成が完了した後に応答全体を一度に返し、ユーザーが数秒から数十秒間、空白の画面を見つめることになること。ストリーミングトランスポートを使用しているにもかかわらず、クライアント側でプログレッシブレンダリングを実装せず、コンテンツが一度に表示されること。API ゲートウェイのバッファー設定を見落とし、ストリーミング応答がチャンク転送に集約されてしまうこと。

Alibaba Cloud プロダクトマッピング

DashScope ストリーミング API は、SSE プロトコルを介したトークンレベルのプッシュをネイティブにサポートしています。PAI-EAS ストリーミングエンドポイントは、カスタムモデルのストリーミング出力をサポートしています。Application Load Balancer (ALB) は、WebSocket と SSE の長寿命接続転送をサポートしています。

Rationale

GPU の計算特性により、バッチ処理は効率化の重要な手段となります。1 つのリクエストを処理する GPU 時間と、8 つの同時リクエストを処理する GPU 時間は 30% しか違わないかもしれませんが、スループットは数倍に増加します。適切なバッチ処理戦略により、リクエストごとのレイテンシを大幅に増加させることなく、システム全体の容量と GPU 使用率を大幅に向上させることができます。

実装

動的バッチ処理：短いウィンドウ (5～20 ms) で受信リクエストを蓄積し、それらをバッチとして GPU に送信します。このウィンドウサイズにはトレードオフが必要です：短すぎると、バッチが小さすぎて GPU を十分に活用できません。長すぎると、回避可能な待機レイテンシが追加されます。継続的バッチ処理：vLLM の中核的な革新であり、バッチ内のすべてのリクエストが終了するのを待ってからリソースを解放するという従来の制約を打ち破ります。バッチ内のリクエストが生成を終了すると、そのリソースは即座に解放され、新しいリクエストがバッチに受け入れられます。これにより、従来のバッチ処理での GPU 使用率 50～60% から 85% 以上に向上させることができます。優先度別バッチ処理：異なる優先度のリクエストに対して別々のキューを維持します。VIP ユーザーやリアルタイムのインタラクティブリクエストを小さなバッチに入れて低レイテンシを実現します。バックグラウンドの分析リクエストを大きなバッチに入れて、安定した高スループットを実現します。

アンチパターン

固定のバッチサイズを使用し、負荷の変動を無視すること。これにより、低負荷時には不要な待機が発生し、高負荷時にはレイテンシが急増します。優先度なしにすべてのリクエストを一緒にキューイングし、リアルタイムトラフィックが多数のオフラインワークロードによってブロックされること。同じバッチ内の長時間実行リクエストによって短いリクエストが妨げられる従来のバッチ処理フレームワークを使用すること (「head-of-line ブロッキング」)。

Alibaba Cloud プロダクトマッピング

PAI-EAS には動的バッチ処理機能が含まれており、継続的バッチ処理 (vLLM ベース) をサポートしています。PAI-EAS は、優先度スケジューリングのためのマルチキュー構成をサポートしています。Lingjun Intelligent Computing Cluster は、大規模な同時実行をサポートするための高密度 GPU デプロイメントを提供します。

理論的根拠

埋め込み計算は、RAG (Retrieval-Augmented Generation) システムの予備ステップです。そのパフォーマンスは、ナレッジベース構築の速度とリアルタイムのクエリレイテンシに直接影響します。数百万のドキュメントを持つナレッジベースの場合、非効率的な埋め込みパイプラインでは、初期インデックス構築に数日かかることがあります。増分更新は、許容可能な業務日時内に完了しない可能性があります。

実装

バッチ処理：ドキュメントを分割した後、100 から 500 のバッチで埋め込みモデルに送信します。これにより、GPU の並列計算能力を最大限に活用します。1 つずつ処理する場合と比較して、バッチ処理はスループットを 5～10 倍向上させることができます。GPU アクセラレーションによるインデックス構築：初期のナレッジベース構築には GPU アクセラレーションを使用します。これにより、数百万のドキュメントに対する HNSW インデックス構築時間が、CPU での数時間から GPU での数十分に短縮されます。増分処理戦略：ドキュメントフィンガープリント (コンテンツハッシュ) を使用して変更を検出します。新規および変更済みのドキュメントに対してのみ再埋め込みとインデックス更新を行い、完全な再構築の高コストを回避します。頻繁に更新されるシナリオでは、「非同期ダブルバッファリング」戦略を使用します。バックグラウンドで新しいインデックスが構築された後、アトミックに新しいインデックスに切り替えます。これにより、更新がオンラインのクエリパフォーマンスに影響を与えるのを防ぎます。

アンチパターン

ドキュメントを 1 つずつ処理し、GPU 使用率が 10% 未満になること。ドキュメントの変更ごとに完全な再構築をトリガーし、大量の計算リソースを浪費すること。インデックス更新とオンラインクエリでリソースを共有し、更新中にクエリパフォーマンスが大幅に低下すること。

Alibaba Cloud プロダクトマッピング

PAI-EAS は、埋め込み用の高性能モデル推論サービスを提供し、バッチリクエストをサポートしています。Model Studio のバッチ埋め込み API は、大規模ドキュメントの効率的なベクトル化をサポートしています。AnalyticDB for Vector は、GPU アクセラレーションによるインデックス構築機能を提供します。

理論的根拠

RAG システムの取得段階は、従来の検索エンジンの結果の最初のページのようなものです。この段階で関連情報が取得されなければ、後続の生成段階がどれほど強力であっても、それを補うことはできません。取得パラメーターの適切な構成は、正しい情報がモデルに届くかどうかを直接決定します。

実装

テキスト分割戦略は、取得品質の基本です。分割が小さすぎる (128 トークン未満など) と、コンテキストが失われます。これにより、取得されたフラグメントが独立した意味を欠き、モデルが理解しにくくなります。分割が大きすぎる (1024 トークン超など) と、関連性が薄まります。これにより、少量のキー情報と大量の無関係なコンテンツが混ざり、取得の適合率が低下します。最適な範囲は通常 256～512 トークンで、意味的な境界の整合性を確保するために 10%～20% の重複を持たせます。取得数量の構成：初期取得の top-K を 10～20 に設定して、情報が失われないように広範な再現率を確保します。Cross-Encoder で再ランキングした後、上位 3～5 項目をモデルに送信します。再ランキングステップは約 80～120 ms のレイテンシを追加しますが、適合率を 20%～35% 向上させることができ、非常にコスト効率が高いです。異なるドキュメントタイプに異なる分割メソッドを使用：よくある質問などの構造化ドキュメントは、エントリごとに分割します。物語風のドキュメントは、段落ごとに分割します。コードドキュメントは、関数またはクラスごとに分割します。

アンチパターン

すべてのドキュメントタイプに単一の固定分割サイズを使用すること。top-K を低く設定しすぎてキー情報を見逃したり、高く設定しすぎて無関係なコンテンツが生成を妨害したりすること。レイテンシを節約するために再ランキングステップをスキップするが、その結果生じる品質の損失は節約された時間をはるかに上回ること。

Alibaba Cloud プロダクトマッピング

Model Studio のナレッジベースは、構成可能な分割戦略と取得パラメーターを提供します。AnalyticDB for Vector は、カスタムインデックスパラメーターのチューニングと取得構成をサポートしています。Model Studio には、Cross-Encoder の再ランキング機能が組み込まれています。

理論的根拠

単一の取得メソッドには、固有の死角があります。密ベクトル検索は、セマンティックな類似性マッチング (「car」と「automobile」が同義語であることを理解する) に優れていますが、正確なキーワード一致を見逃す可能性があります。たとえば、ユーザーが「ModelY」のような特定のモデルを検索すると、ベクトル検索は意味的に類似しているが異なるモデルを返す可能性があります。BM25 などのスパース検索メソッドは、正確なキーワード一致に優れていますが、同義語の書き換えや意味的推論を処理できません。ハイブリッド検索は、両方の利点を組み合わせて、取得率を大幅に向上させます。

実装

密ベクトル検索と BM25 スパース検索を同時に実行します。スコア融合戦略を使用して結果をマージします。融合メソッド：reciprocal rank fusion (RRF) が最も堅牢な選択肢です。これは、順位の逆数に基づいて加重和を計算し、元のスコアの絶対値に依存しません。これにより、さまざまな取得メソッドの異なるスコア分布に対して自然な正規化効果が得られます。加重スコア融合では、シナリオに基づいて重みを調整できます。規制番号の取得など、正確なクエリシナリオでは、BM25 の重みを 0.6～0.7 に増やします。「コストを削減する方法」など、セマンティックなクエリシナリオでは、ベクトルの重みを 0.6～0.7 に増やします。測定データ：純粋なベクトル検索と比較して、ハイブリッド検索は Recall@10 を 10%～15% 向上させます。純粋な BM25 と比較して、セマンティックリコールを 20%～30% 向上させます。追加のレイテンシは、2 つの取得パスが並行して実行され、融合計算のオーバーヘッドが非常に低いため、わずか 15～25 ms です。

アンチパターン

単一の取得メソッドのみを使用し、特定のクエリタイプに対して体系的な死角を作ること。実際のクエリ分布に合わせて最適化されていない固定の融合重みを使用すること。2 つの取得パスを並行ではなくシリアルに実行し、不必要にレイテンシを増加させること。

Alibaba Cloud プロダクトマッピング

AnalyticDB for Vector は、ハイブリッド検索 (ベクトル + 全文) をネイティブにサポートし、RRF と加重融合戦略を組み込んでいます。Elasticsearch は、ベクトルプラグインと組み合わせることで、ハイブリッド検索機能を実現できます。Model Studio のナレッジベースは、ハイブリッド検索モードの構成をサポートしています。

理論的根拠

AI システムのエンドツーエンドレイテンシは、複数のシリアルおよびパラレルステージで構成されています。最適化は、真のボトルネックを特定することから始めなければなりません。よくある間違いは、すべての努力をモデル推論の最適化に集中させることです。しかし、実際のボトルネックは、ベクトル取得における最適化されていないインデックス、プロンプトテンプレート内の過剰なトークン数、またはネットワーク伝送における不要なホップである可能性があります。フルリンクのパフォーマンスプロファイリングは、適切な領域を最適化することを保証するために不可欠です。

実装

リクエスト処理の各重要段階でタイムスタンプを埋め込みます：クライアントリクエスト開始 → AI ゲートウェイ受信 → 認証 → インテント認識 → ナレッジ取得 (埋め込み計算、インデックスクエリ、再ランキングを含む) → プロンプトアセンブリ → モデル推論 (キューイングと計算を含む) → 後処理 (フォーマットとセキュリティチェック) → 応答返却。サンプリングされたデータを使用してレイテンシ分布チャートを作成し、P50、P95、および P99 パーセンタイルでのボトルネック分布を特定します。一般的な発見には、コールドベクトルインデックスによる高い初回クエリレイテンシ (コールドスタート問題)、不必要に長いコンテキスト推論を引き起こす肥大化したプロンプトテンプレート、および合計レイテンシをすべてのステージの合計にする非並列化のシリアルツール呼び出しなどがあります。レイテンシバジェットメカニズムを確立します。各ステージにレイテンシバジェットを設定します。バジェットを超えた場合、自動的にアラートと劣化戦略をトリガーします。

アンチパターン

ステージごとに分解せずに合計レイテンシのみを監視すること。データではなく直感に基づいて最適化方向を決定すること。レイテンシの 60% を占める真のボトルネックを無視して、レイテンシの 5% しか占めないステージを最適化すること。継続的なプロファイリングを欠き、一度の最適化後にパフォーマンスを追跡しないこと。

Alibaba Cloud プロダクトマッピング

OpenTelemetry と互換性のある Application Real-Time Monitoring Service (ARMS) の分散トレーシングは、フルリンクのトレース可視化を提供します。Log Service (SLS) のパイプライン可視化は、各ステージのレイテンシ分布と傾向を示します。Performance Testing Service (PTS) は、負荷テストとボトルネックの特定をサポートします。

理論的根拠

AI 推論の高い計算コストは、従来のアプリケーションよりもキャッシュをはるかに価値あるものにします。単一の大規模モデル推論のコストは、単一の Redis クエリのコストの 1,000 倍以上になることがあります。適切に設計されたキャッシュアーキテクチャは、ユーザー体験に影響を与えることなく、実際の推論リクエストの数を 30%～60% 削減できます。これは、コスト削減とレイテンシ短縮に直接つながります。

実装

3 層のキャッシュシステムを構築します。各レイヤーは、異なる再利用シナリオに対応します。

レイヤー 1: プロンプトキャッシュと KV-Cache の再利用。複数のリクエストが同じシステムプロンプトのプレフィックスを共有する場合、そのプレフィックスに対応する KV-Cache をリクエスト間で再利用して、冗長な計算を回避できます。実際には、長いシステムプロンプト (2,000～4,000 トークン) の場合、KV-Cache の再利用は最初のトークンまでの時間 (TTFT) を 40%～60% 削減できます。主な実装ポイント：システムプロンプトの一貫性を確保します。たとえば、タイムスタンプなどの変化するコンテンツを各リクエストに動的に挿入しないようにします。適切なキャッシュ立ち退きポリシーを設定します。

レイヤー 2: セマンティックキャッシュ。セマンティックな類似性に基づいてユーザーのクエリを照合します。新しいクエリと過去のクエリのセマンティックな類似性がしきい値 (通常 0.92～0.95) を超えた場合、過去の回答を直接返します。これにより、推論コストが完全に排除されます。典型的なシナリオは、多くのユーザーが異なる言葉遣いで同じ質問をするカスタマーサービスシステムです。セマンティックキャッシュのヒット率は通常 15%～35% です。各ヒットは 2～10 秒の推論時間を節約します。キャッシュの無効化要件に注意してください：ナレッジベースが更新された場合、関連するセマンティックキャッシュエントリを同期的にクリアする必要があります。

レイヤー 3: 応答キャッシュ。同一のクエリ (文字レベルの一致) に対して、キャッシュされた結果を直接返します。これにより、応答時間が数秒からミリ秒に短縮されます。これは、システム統合シナリオでの繰り返し API 呼び出しに適しています。

各キャッシュレイヤーは、異なる無効化戦略を使用します。KV-Cache は、Least Recently Used (LRU) ポリシーを使用し、ビデオメモリ容量によって制限されます。セマンティックキャッシュは、ナレッジベースのバージョンとタイムウィンドウに基づいて無効化されます。応答キャッシュは、Time to Live (TTL) とアクティブリフレッシュに基づいて無効化されます。

アンチパターン

すべての応答を無差別にキャッシュし、ユーザーが古い情報を受け取ることになること。キャッシュ無効化戦略を欠き、ナレッジベースが更新された後に古い回答が返されることになること。セマンティックな類似性のしきい値を低く設定しすぎ、無関係なクエリに対して誤った一致を引き起こすこと。

Alibaba Cloud プロダクトマッピング

エンタープライズ対応の Redis である Tair は、高性能なセマンティックキャッシュと応答キャッシュを提供し、ベクトル類似検索をサポートしています。PAI-EAS には、KV-Cache の最適化と Prefix Cache 機能が組み込まれています。コンテンツデリバリーネットワーク (CDN) は、静的リソースのエッジキャッシングを高速化します。

理論的根拠

GPU などの AI 推論リソースは、従来のコンピューティングリソースよりもはるかにゆっくりとスケーリングします。新しい GPU インスタンスは、モデルのロード時間を含め、コールドスタートから準備が整うまでに数分かかることがあります。しかし、トラフィックスパイクは数秒で発生する可能性があります。選択的な負荷管理なしにシステムが過負荷になると、すべてのリクエストが長いキューのためにタイムアウトします。これにより、壊滅的な「完全な障害」シナリオにつながります。優先度付きキューとロードシェディングは、過負荷時に「重要なものを救い、重要でないものを捨てる」ためのコアメカニズムです。

実装

明確なリクエスト優先度を定義します。P0 は、ユーザー体験に直接影響し、数秒の応答時間を要求するサービスレベル合意 (SLA) が必要なリアルタイムのユーザー対話用です。P1 は、リアルタイムの推奨やストリーム要約など、数秒の遅延を許容できるリアルタイムのバックグラウンド分析用です。P2 は、完全な評価やデータバックフィルなど、数分の遅延を許容できるオフラインのバッチ処理用です。各優先度に対して別々の処理キューを維持し、異なるサービスレベル目標 (SLO) を構成します。たとえば、P0 キューの深さ制限を 20、タイムアウトを 30 秒に設定します。P1 キューの深さ制限を 100、タイムアウトを 60 秒に設定します。P2 キューの深さ制限を無制限、ハードタイムアウトなしに設定します。極端な負荷シナリオに対してロードシェディング戦略を実装します。GPU 使用率が継続的に 90% を超え、P0 キューの深さが増加している場合、まず新しい P2 リクエストの受け入れを停止し、429 Retry-After ステータスを返します。それでも不十分な場合は、P0 の SLA が侵害されないように P1 リクエストを一時停止します。SLO ベースのスケジューリングを実装します。リソースが豊富な場合は、キューを公平にスケジュールします。リソースが不足している場合は、優先度に基づいて厳密なプリエンプションを使用します。サポートメカニズムとして、シェディングされた P2 リクエストは自動的に遅延リトライキューに入ります。これらのリクエストは、負荷が正常に戻った後に自動的に処理され、最終的な完了を保証します。

アンチパターン

すべてのリクエストを優先順位付けせずに単一のキューに入れ、VIP ユーザーとバックグラウンドタスクが同じリソースを奪い合うようにすること。リトライメカニズムなしにタイムアウトしたリクエストを単にドロップし、バッチ処理タスクが永久に失敗するようにすること。負荷の事前警告システムを欠き、システムがクラッシュしたときに初めて過負荷が発見されること。

Alibaba Cloud プロダクトマッピング

AI ゲートウェイと Application Load Balancer (ALB) は、リクエストヘッダーに基づく優先度ベースのルーティングとレート制限をサポートしています。RocketMQ は、優先度メッセージキューと遅延配信機能を提供します。PAI-EAS は、マルチキュー構成とリクエスト優先度スケジューリングをサポートしています。Cloud Monitor は、GPU 使用率のアラートと auto scaling のトリガーを提供します。