Model Serving Reference Manual#
Model Serving は、検証されたAIモデルを、 EDB Postgres AI機能とシームレスに統合する運用対応の推論エンドポイントに変換します。システムは、ハイブリッドマネージャーによって管理されるKubernetes環境内のスケーラブルサービスとして、コンテナ化されたモデルを展開します。
前提条件 Model Servingでは、モデルイメージ管理に Hybrid Manager installation および Asset Library configuration が必要です。すべての推論サービスは、制御されたKubernetes環境内で動作します。
システムアーキテクチャ#
KServe Foundation#
Model Servingは、基になるオーケストレーションエンジンとしてKServeを利用し、モデルの展開、スケーリング、ライフサイクル管理のためのエンタープライズグレードの機能を提供します。 KServeは、推論操作の包括的な制御を維持しながら、コンテナ化されたモデル展開の複雑さを抽象化します。
コアコンポーネント
ServingRuntime さまざまなモデルタイプに最適化されたフレームワーク固有の実行環境
InferenceService 自動スケーリングと状態管理を備えた運用エンドポイント
リソース管理 導入されたモデル全体のGPU割り当てとコンピューティングの最適化
統合フレームワーク#
サービスインフラストラクチャは、モデルライブラリの管理対象モデルカタログとEDB PG AIの操作機能間のブリッジとして動作します。ガバナンスワークフローを通じて承認されたモデルは、さまざまなAIワークロードをサポートする推論サービスとして展開できるようになります。
サポートされているモデルタイプ
テキスト生成と補完のためのラージ言語モデルLLM
ベクトル検索および取得拡張生成のためのモデルの埋め込み
CLIP、OCR、画像埋め込み機能を含むビジョンモデル
検索結果最適化のためのモデルの再ランキング
動作特性#
導入パターン#
InferenceServicesは、組織の要件とモデルの特性に基づいて、複数の展開戦略をサポートします。このシステムは、適切なリソース割り当てとスケーリング動作を備えた高可用性の運用展開と開発環境の両方に対応します。
展開構成
専用の推論ワークロードの 単一モデル展開
互換性のあるモデルでのリソース効率のための マルチモデルサービング
段階的なトラフィックシフトを使用した安全な運用更新のための カナリア展開
モデルパフォーマンス比較のための A/Bテスト構成
スケーリングメカニズム#
自動スケーリングは、推論需要に基づいてコンピューティングリソースを調整し、サービスレベル目標を維持しながらコストを最適化します。システムは、ワークロード特性に基づいて、ホリゾンタル ポッド スケーリングと垂直リソース調整の両方をサポートしています。
スケーリング係数
要求の同時実行性とキューの深さ
モデル固有のレイテンシー要件
GPUメモリ使用パターン
特殊なワークロードのカスタムメトリック
リソース管理#
GPUリソースは、マルチプルのモデル全体で使用率を最適化する集中的な割り当て戦略を介して管理されます。システムは、さまざまなGPU構成をサポートし、リソースの競合を防ぐための分離メカニズムを提供します。
リソースに関する考慮事項
モデルのロードと推論のためのGPUメモリ要件
前処理および後処理操作のためのCPU割り当て
高スループットの推論ワークロードのネットワーク帯域幅
モデルアーティファクトと一時データのストレージ要件
アクセスと統合#
エンドポイント構成#
InferenceServicesは、一般的なAIフレームワークおよびアプリケーションとの互換性を提供する標準化されたAPIエンドポイントを公開します。システムは、安全なゲートウェイ構成を介して内部クラスター通信と外部アクセスの両方をサポートします。
内部アクセスパターン
サービス間通信のクラスターローカルDNS解決
セキュリティ分離のためのネットワークポリシーの適用
高度なトラフィック管理のためのサービスメッシュ統合
外部アクセス構成
認証と承認を備えたポータルベースのエンドポイント
安全な外部統合のためのAPIキー管理
レート制限とクォータ適用機能
APIの互換性#
標準エンドポイントパスは、OpenAI互換クライアントおよびカスタムアプリケーションとの互換性を提供し、既存のAIワークフローおよびツールチェーンとのシームレスな統合を可能にします。
エンドポイント仕様
Chat completions (LLMs): <base>/v1/chat/completions
Embeddings: <base>/v1/embeddings
Reranking: <base>/v1/ranking
EDB PG AI統合#
Model Servingは、運用制御を維持しながら展開の複雑さを抽象化する一貫したインターフェイスを介して、すべてのEDB PG AIコンポーネントの推論機能を提供します。
統合ポイント
AI Accelerator Pipelines は、データ変換ワークフローの埋め込みモデルと前処理モデルを活用
ナレッジベース は、ベクトル検索およびセマンティック検索操作に埋め込みモデルを利用します
Gen AI Builder アプリケーションは、会話型AIおよびテキスト生成機能のLLMにアクセスします
構成フレームワーク#
ServingRuntime Management#
ServingRuntime構成は、さまざまなモデルフレームワークの実行環境を定義し、最適化されたパフォーマンス特性を提供しながら、展開操作からフレームワーク固有の複雑さを抽象化します。
実行時最適化機能
モデルの読み込みと推論のためのフレームワーク固有の最適化
GPUカーネルの最適化によるスループットの向上
大規模なモデル展開のメモリ管理戦略
リソース使用率を向上させるバッチ処理機能
リソースの割り当て#
適切なリソース構成により、最適なパフォーマンスが保証され、リソース競合やメモリ不足状態が回避されます。組織は、リソース仕様を定義するときに、パフォーマンス要件とインフラストラクチャコストのバランスを保つ必要があります。
重要な構成領域
コンテナスケジューリングのCPUおよびメモリ要求/制限
GPUの割り当てと共有戦略
ネットワークとストレージのパフォーマンス要件
ヘルスプローブとタイムアウト構成
可観測性構成#
包括的なモニタリングにより、推論サービスのプロアクティブな管理が可能になると同時に、パフォーマンス特性とリソース使用パターンの可視性を提供します。
モニタリング機能
要求レイテンシーとスループットメトリック
CPU、メモリ、GPU全体のリソース使用率の追跡
詳細な障害分析を含むエラー率モニタリング
アプリケーション固有の要件のカスタムメトリック
運用上の考慮事項#
パフォーマンスの最適化#
モデルサービスのパフォーマンスは、モデルの特性、ハードウェア構成、トラフィックパターンを含む複数の要素に依存します。組織は、ベースラインのパフォーマンスメトリックを確立し、本番使用パターンに基づいて継続的に最適化する必要があります。
最適化戦略
最適なスループットとレイテンシーのトレードオフのためのバッチサイズの調整
大幅な精度の損失なしでメモリ効率を高める量子化技術
頻繁にアクセスされるモデルと予測のキャッシュ戦略
マルチモデル展開の要求ルーティングの最適化
セキュリティフレームワーク#
実稼働モデルの提供には、業務効率を維持しながらモデル資産と推論データの両方を保護する包括的なセキュリティ制御が必要です。
セキュリティ制御
Kubernetesネットワークポリシーを介したネットワークの分離
APIアクセスの認証・承認
モデルイメージのセキュリティスキャンと脆弱性管理
コンプライアンスとフォレンジック分析のための監査ログ
スケーラビリティの制限#
システムの制限を理解することにより、大規模な展開の適切なキャパシティプランニングとアーキテクチャの決定が可能になります。
スケーリングコンストレイン
GPUメモリはモデルサイズとバッチ処理機能を制限します
ネットワーク帯域幅は高スループットの推論ワークロードに影響を与える
ストレージI/Oパフォーマンスはモデルのロードとチェックポイント操作に影響を与える
Kubernetesクラスター制限は最大同時展開に影響を与える
トラブルシューティングフレームワーク#
よくある問題#
モデルサービス展開では、体系的なトラブルシューティングのアプローチを必要とするさまざまな運用上の問題が発生する場合があります。
一般的な問題
HTTP 404エラー は、多くの場合、不正なエンドポイントパスまたはサービスの構成の誤りを示します
リソース割り当ての失敗 は、通常、不十分なGPUまたはメモリの可用性が原因で発生します
モデルのロードタイムアウト には、ヘルスプローブ構成の調整が必要になる場合があります
パフォーマンスの低下 は、多くの場合、リソース競合または準最適なバッチサイズを示します
診断手順#
体系的な診断アプローチにより、効率的な問題の解決が可能になり、トラブルシューティング操作中のサービスの中断を最小限に抑えます。
診断手順
InferenceServiceのステータスとイベントログの確認
リソースの割り当てと使用率メトリックの確認
ネットワーク接続とエンドポイントのアクセシビリティを検証する
モデルのロードログとコンテナステータスを確認します
実装パターン#
開発環境#
開発およびテスト環境は、実稼働グレードの信頼性とパフォーマンス特性よりも迅速な反復を優先する簡素化された構成の恩恵を受けます。
開発構成
コスト効率のためのリソース割り当ての削減
外部アクセス要件のない簡素化されたネットワーキング
緩和されたヘルスチェックとタイムアウト構成
複数の開発モデルにわたる共有GPUリソース
本番展開#
実稼働環境には、運用要件をサポートしながら、信頼性、パフォーマンス、セキュリティを保証する包括的な構成が必要です。
制作要件
適切な冗長性を備えた高可用性構成
包括的なモニタリングとアラートの統合
組織ポリシーに合わせたセキュリティ制御
予想されるワークロード特性に基づいたキャパシティプランニング
ハイブリッドアーキテクチャ#
組織は、一貫した運用手順を維持しながら、パフォーマンス、セキュリティ、またはコンプライアンス要件に基づいて、複数のインフラストラクチャ層にモデルを展開する場合があります。
ハイブリッドの考慮事項
さまざまな展開環境間での一貫したモデルバージョン
環境間のネットワーク接続と遅延の最適化
クロス環境通信のセキュリティ境界管理
ハイブリッド展開全体での統合された監視と管理
はじめに#
初期展開#
Model Servingを始める組織は、単純な構成から始めて、運用経験と要件に基づいて徐々に複雑さを追加する必要があります。
セットアップシーケンス
ハイブリッドマネージャーとアセットライブラリーのインストールの確認
ターゲットモデルフレームワークの基本的なServingRuntimeの構成
保守的なリソース割り当てを使用して初期推論サービスを展開する
エンドポイントのテストとモニタリングを介して機能を検証する
構成リソース#
ベストプラクティス#
カスタマイズの前に、実績のあるServingRuntime構成から開始する
運用展開前に包括的なモニタリングを実装する
モデルの特性に基づいて、リソース割り当てガイドラインを確立する
構成の決定事項と操作手順を文書化する
リファレンスドキュメント#
コアアーキテクチャ
実装ガイド
統合ドキュメント
Model Servingは、ガバナンスAIモデルを、パフォーマンス、セキュリティ、操作特性の包括的な制御を維持しながら、組織の要件に合わせてスケールする本番対応の推論機能に変換します。