KubernetesでLLM推論を提供する際の評価ポイント

入力と出力の長さ、同時リクエスト数、応答の目標、許容する失敗を決めます。メモリにはモデルの重みだけでなく、キャッシュ、実行時の状態、同時処理などの領域も必要です。選んだモデル、数値形式、機器、推論エンジンの版が対応するかを確認します。小規模な試行だけでは、本番の処理能力は分かりません。

バッチ処理は処理量を増やせる一方、待ち時間やメモリを増やす場合があります。並列化、量子化、GPUの共有も、業務によって効果が変わります。長い入力と複数利用者を含む実際の質問で、最初の出力までの時間、その後の出力速度、遅いケース、エラーを確認します。

HPAを使う場合も、適切な指標と連携が必要です。GPUへの配置、重みの読み込み、モデルの準備に時間がかかるため、レプリカの数だけでは利用できる容量は分かりません。停止時にゼロ台にする運用には、対応する提供基盤と、再起動時の待ち時間の許容が必要です。HPAだけで自動的に実現するものではありません。

過負荷、タイムアウト、取り消し、レプリカやノードの停止、復旧を試します。認証、利用制限、ログ、モデルの版を戻す手順も決めます。入力や出力が届くすべてのサービスをデータ管理の確認に含めます。自社でKubernetesを動かしていても、それだけで国内保存や外部への情報送信の停止が証明されるわけではありません。

それだけで自動的に実現するものではありません。対応する提供基盤やイベント駆動の拡張機能、設定を確認し、再起動時の待ち時間を検証します。

見積もれません。実行時の状態、KVキャッシュ、入出力の長さ、同時利用、その他の領域を含め、負荷試験で確認します。