重要なポイント
- 単一マシン： 1 GPU、10～50人の同時ユーザー、シンプルなセットアップ。
- マルチGPU： 2～8 GPU、50～200人のユーザー、Kubernetes調整。
- エンタープライズ： 5～50 GPU、500+人のユーザー、分散型、高可用性。
- ロードバランシング： ラウンドロビンはリクエストをGPUポッド全体に分散します。
- 監視： レイテンシ、キューの深さ、GPU使用率、エラー率を追跡します。
- 2026年4月時点で、Kubernetesはエンタープライズ向けLLMデプロイメントの標準です。
単一マシンから分散システムへどのようにスケーリングしますか？
単一マシンから本番環境への進行：
| デプロイメントステージ | GPU数 | 同時ユーザー数 | SLA稼働率 | インフラストラクチャセットアップ |
|---|---|---|---|---|
| — | — | — | — | — |
| — | — | — | — | — |
| — | — | — | — | — |
| — | — | — | — | — |
ロードバランシングはどのように実装しますか？
ロードバランサーは、リクエストを最も負荷の低い推論ポッドにルーティングします。
ラウンドロビン： ポッド全体に均等に分散します（最もシンプル）。
最小負荷： キューが最短のポッドに送信します（低レイテンシ）。
スティッキーセッション： 同じユーザーは常に同じポッドを使用します（コンテキスト用ですが、ポッドが失敗するとリスク）。
# ロードバランシング機能を備えたKubernetesサービス
apiVersion: v1
kind: Service
metadata:
name: llm-inference
spec:
selector:
app: vllm-inference
ports:
- port: 8000
targetPort: 8000
type: LoadBalancer
sessionAffinity: None # ポッド全体でラウンドロビン冗長性とフェイルオーバーはどのように実装しますか？
高可用性には冗長なコンポーネントが必要です：
ポッドレプリカ： 複数の推論ポッド。1つが失敗すると、他のポッドがリクエストを処理します。
ヘルスチェック： Kubernetesは自動的に不健全なポッドを削除します。
ストレージ冗長性： モデルファイルはノード全体に複製されます。
DNSフェイルオーバー： データセンター全体が失敗した場合、バックアップ施設にルーティングします。
何を監視すべきですか？
エンタープライズデプロイメントは以下を監視する必要があります：
- レイテンシ： リクエストごとの時間（p50、p95、p99パーセンタイル）。
- キューの深さ： 待機中のリクエスト数。>10 = 過負荷。
- GPU使用率： 70～90%である必要があります。<50% = オーバーサイズ。>95% = アンダーサイズ。
- エラー率： 失敗したリクエストの割合。<0.1%である必要があります。
- スループット： すべてのポッド全体でのトークン/秒。
- 稼働率： サービスが利用可能な時間の割合（目標99.9%）。
- クエリあたりのコスト： リクエストあたりの€（ハードウェア償却）。
スケール時にコストを最適化するにはどうしますか？
スケール時には以下に焦点を当てます：
- GPU使用率： 高いほどリクエストあたりのコストが低くなります。目標80～90%。
- モデル量子化： Q4対FP16は4倍少ないVRAM、同じ速度。必要なGPU数を削減します。
- バッチサイズ： より大きいバッチ = リクエストあたりのコストが低くなります（ただしレイテンシが高くなります）。
- オートスケーリング： 夜間にスケールダウン、昼間にスケールアップ（クラウドコストの30～50%を節約）。
- マルチテナンシー： GPU あたり2～3個のモデルを実行します（VRAMが許可する場合）。使用率が高くなります。
エンタープライズスケーリングの一般的なミス
- レイテンシ要件を無視します。 デプロイメント前にp99レイテンシSLAに同意してください。2秒のレイテンシは良好に見えるかもしれませんが、ユーザーが不平を言うまでです。
- ピーク用のオーバープロビジョニング。 ピークが1日あたり2時間で100ユーザーの場合、1日中100人の同時ユーザー用にハードウェアを購入しないでください。オートスケーリングを使用してください。
- 不適切な障害分離。 1つのポッドクラッシュがロードバランサーを停止した場合、アーキテクチャは間違っています。障害シナリオをテストしてください。
- 間違ったメトリクスを監視します。 GPU使用率を監視するがレイテンシを監視しないことは、逆です。レイテンシはユーザーに影響を与えます。
- オープンソースツールがエンタープライズにスケーリングすると仮定します。 Ollamaは1ユーザーに対してうまく機能します。500人の同時ユーザーの場合は、エンタープライズ監視と調整が必要です。
Local LLMのスケーリングに関する一般的な質問は何ですか？
エンタープライズデプロイメントに必要なGPU数はいくつですか？
同時実行性とレイテンシ要件によって異なります。7Bモデルの100人の同時ユーザー：約5～8 GPU。500人の同時ユーザー：20～30 GPU。式：（同時ユーザー×予想レイテンシ）/（GPUあたりのトークン/秒）。
ロードバランシングとオートスケーリングの違いは何ですか？
ロードバランシングは、既存のポッド全体にリクエストを分散します。オートスケーリングは、負荷に基づいてポッドを追加/削除します。両方が必要です：ロードバランシングが今すぐ作業を分散し、オートスケーリングが容量を調整します。
GPU障害にはどのように対処しますか？
Kubernetesは自動的にポッドを正常なGPUに再スケジュールします。GPUが失敗すると、Kubernetesはそれを利用不可としてマークし、トラフィックを他のポッドにルーティングします。冗長性を持つ：8つのGPUが必要な場合、10個をプロビジョニングしてください。
どのレイテンシSLAを目指すべきですか？
p99レイテンシ<2秒がチャットボットの標準です。p99 <リアルタイムオートコンプリート用の500ms。ユーザーエクスペリエンスに基づいてSLAを定義し、それを満たすためのハードウェア/バッチサイズを選択してください。
分散推論クラスターを監視するにはどうしますか？
ポッドごとおよびクラスタ全体で監視：GPU使用率、キューの深さ、レイテンシ（p50/p95/p99）、エラー率、スループット、稼働率。Prometheus+Grafanaまたは同等のものを使用してください。
オンプレミス スケーリングはクラウドより安いですか？
はい、スケール時。損益分岐点は約500kトークン/月です。オンプレミス：高い初期コスト（€400k～1.5M ハードウェア）、その後リクエストあたりのコストが低くなります。クラウド：初期コストなし、高いリクエストあたりのコスト（€0.15～60/1M トークン）。
ソース
- Kubernetes公式ドキュメント -- kubernetes.io/docs
- vLLMデプロイメントガイド -- docs.vllm.ai/en/serving/distributed_serving.html
- Prometheusモニタリング -- prometheus.io