Production Serving & Deployment

実稼働レベルの LLM Serving は、推論エンジンを開始するだけでなく、サービスのセキュリティ、信頼性、スケーラビリティ、可観測性を保証する必要があります。

1. 全体的なアーキテクチャ

LLM Production Serving
├── API Layer
│   ├── OpenAI-compatible API
│   ├── SSE / Streaming
│   ├── Authentication
│   └── Rate Limiting
│
├── Request Management
│   ├── Queue / Concurrency
│   ├── Timeout / Cancellation
│   ├── Load Balancing
│   └── Backpressure
│
├── Runtime & Resources
│   ├── GPU Scheduling
│   ├── Model Replicas
│   └── Autoscaling
│
└── Operations
    ├── Health Checks
    ├── Metrics / Monitoring
    ├── Logging / Tracing
    └── Deployment / Rollback

典型的なアーキテクチャ:

                 Internet
                    ↓
               API Gateway
         ┌──────────┼──────────┐
         │          │          │
       Auth       TLS       Rate Limit
         └──────────┼──────────┘
                    ↓
              Load Balancer
                    ↓
        ┌───────────┼───────────┐
        ↓           ↓           ↓
      vLLM-1      vLLM-2      vLLM-3
        ↓           ↓           ↓
       GPU         GPU         GPU

Metrics → Prometheus → Grafana
Logs    → Logging System
Health  → Load Balancer / Orchestrator
Scaling ← Queue / Latency / GPU Metrics

2. OpenAI-compatible API

最新の推論エンジンは通常、OpenAI API スタイルと互換性のある HTTP インターフェイスを提供します。

たとえば:

POST /v1/chat/completions
Authorization: Bearer <api-key>
Content-Type: application/json

リクエスト:

{
  "model": "qwen",
  "messages": [
    {
      "role": "user",
      "content": "Hello"
    }
  ],
  "stream": false
}

通常、応答には次の内容が含まれます。

{
  "choices": [
    {
      "message": {
        "role": "assistant",
        "content": "Hello!"
      }
    }
  ]
}

共通 Endpoint:

OpenAI-compatible は、すべてのエンジンにわたる Tool Calling、Structured Outputs、および Reasoning の一貫したサポートを意味するものではありません。

3. SSE / Streaming

LLM は通常、SSE スタイル HTTP Streaming を使用して、生成されたコンテンツをクライアントに段階的に送信します。

Client Request
      ↓
Server Prefill
      ↓
First Token
      ↓
Token 1
      ↓
Token 2
      ↓
Token 3
      ↓
Stream Complete

リクエスト:

{
  "model": "qwen",
  "messages": [
    {
      "role": "user",
      "content": "Hello"
    }
  ],
  "stream": true
}

通常、応答では次のものが使用されます。

Content-Type: text/event-stream

例:

data: {"choices":[{"delta":{"content":"Hello"}}]}

data: {"choices":[{"delta":{"content":" world"}}]}

data: [DONE]

ここで送信されるのは、インクリメンタル メッセージ Chunk です。 1 つの Chunk が 1 つの Token に正確に対応するという保証はありません。

Nginx Streaming

location /v1/ {
    proxy_pass http://vllm:8000;

    proxy_http_version 1.1;
    proxy_buffering off;
    proxy_read_timeout 300s;
}

主要な構成:

• proxy_buffering off: Nginx による生成されたコンテンツのバッファリングを回避します。
• proxy_read_timeout: 2 つの連続するアップストリーム読み取り間の待機時間を制限します。
• proxy_http_version 1.1: HTTP/1.1 プロキシ アップストリームを使用します。

ストリーミング要求は、ユーザーが生成をキャンセルしても GPU が引き続き動作することを避けるために、クライアントが積極的に切断する状況にも対処する必要があります。

4. AuthenticationとRate Limiting

推論リソースは通常高価であり、保護されていないモデル サービスをパブリック ネットワークに直接公開することはできません。

Authentication

一般的な方法:

• API Key。
• JWT。
• OAuth / OIDC。
• 内部サービス認証。

たとえば:

Authorization: Bearer <api-key>

Rate Limiting

制限できるもの:

たとえば:

User A:
60 RPM
100,000 TPM
5 Concurrent Requests

LLM Serving の場合、RPM を制限するだけでは不十分な場合があります。

2 つのリクエストのコストは大きく異なる可能性があるためです。

Request A: 100 Input + 50 Output Tokens

Request B: 100K Input + 8K Output Tokens

したがって、Token の予算と同時実行の量の両方を制限することが最善です。

セキュリティ境界線

vLLM の --api-key は、API パスの一部のみを保護し、すべてのサービス エンドポイントが認証されているわけではありません。実稼働環境は、このパラメーターのみに依存することはできず、リバース プロキシとネットワーク ポリシーを通じて他の管理エンドポイントを保護する必要があります。

5. Queue、Concurrency、Backpressure

通常、推論サービスの GPU コンピューティング リソースと KV Cache リソースは限られています。

Incoming Requests
        ↓
   Admission Control
        ↓
      Queue
        ↓
     Scheduler
        ↓
   Running Requests
        ↓
       GPU

Concurrency

Concurrency は、同時に処理されるリクエストの数を表します。

区別する必要があります:

• In-flight Requests の API 層。
• Sequences は推論エンジンで実行されます。
• Requests がキューに入れられています。

これらの量は必ずしも同じである必要はありません。

Queue

リクエストが現在の処理能力 GPU を超える場合、一部のリクエストは待機する必要があります。

Queue は短期間のトラフィックのバーストを吸収できますが、キュー時間が長いと TTFT の状態が悪化します。

Backpressure

Backpressure は、システムが過負荷になったときに新しいジョブの入力をアクティブに制限するメカニズムです。

たとえば:

Queue < Limit
     ↓
Accept Request

Queue >= Limit
     ↓
Reject / Throttle
     ↓
HTTP 429 / 503

一般的な対策:

• 同時実行の最大量を制限します。
• キューに入れられるリクエストの最大数を設定します。
• 行列での待ち時間を制限します。
• 容量を超える新しいリクエストを拒否します。
• 信頼できる再試行可能なエラーにはバックオフ戦略を使用します。

と Queue を無限に増加しても、GPU の計算能力を増加させることはできず、遅延は増加し続けるだけです。

6. TimeoutとCancellation

LLM リクエストには、複数の異なるタイムアウトがあることがよくあります。

さまざまな API Gateway および推論エンジンは、すべてのタイプをネイティブにサポートしているわけではないため、特定のシステムに従って実装する必要があります。

Cancellation

ユーザーがページを閉じるか、Stop Generation をクリックすると:

Browser Cancel
      ↓
API Gateway
      ↓
Inference Server
      ↓
Cancel Request
      ↓
Release KV Cache / Scheduler Resources

運用サービスでは、キャンセル信号が推論エンジンに確実に配信されるようにする必要があります。

Streaming リクエストの場合、ネットワークの切断とサーバー側のタスクのクリーンアップとの関係に特別な注意を払う必要があります。

Retry

すべての失敗をすぐに再試行する必要があるわけではありません。

たとえば、GPU はオーバーロードされており、多数のクライアントが同時に再試行すると Retry Storm が形成される可能性があります。

一般的な方法は次のとおりです。

• Exponential Backoff。
• Jitter。
• Retry Limit。
• 再試行の対象となるエラーに対してのみ再試行してください。

部分的に出力されたストリーミング生成の場合、再試行するとコンテンツの重複や追加料金が発生する可能性があるため、注意が必要です。

7. Load Balancing

マルチインスタンス推論の展開:

                 Load Balancer
                        ↓
           ┌────────────┼────────────┐
           ↓            ↓            ↓
        vLLM-1        vLLM-2        vLLM-3
           ↓            ↓            ↓
          GPU          GPU          GPU

一般的な戦略:

LLMに関しては、通常のRound Robinが必ずしも最適とは限りません。

リクエストの長さは大きく異なるため、同じ接続数を持つ 2 つの GPU インスタンスの実際の負荷は完全に異なる可能性があります。

Cache-aware Routing は、複数のリクエスト間で同様の Prompt Prefix を使用して、計算の繰り返しを減らすことができます。

ただし、負荷分散戦略では、キャッシュ ヒット率と負荷の公平性も考慮する必要があります。

8. GPU SchedulingとAutoscaling

GPU Scheduling

推論エンジン内では、Scheduler は GPU へのリクエストの実行をスケジュールする役割を果たします。

たとえば:

Queue
  ↓
Continuous Batching
  ↓
Prefill / Decode
  ↓
KV Cache Allocation
  ↓
GPU Execution

これは、GPU Pod などのプラットフォームでの Kubernetes スケジューリングとは異なります。

• 推論エンジン Scheduler: Token とリクエストをスケジュールします。
• コンテナ オーケストレーション Scheduler: コンテナを GPU ノードにスケジュールします。

Autoscaling

Autoscaling 負荷に基づいて推論インスタンスを増減します。

たとえば:

Incoming Traffic ↑
       ↓
Queue Length ↑
       ↓
Scale Out
       ↓
More Model Replicas

拡張と縮小の一般的に使用される基準:

• Queue Length。
• TTFT / TPOT。
• Requests/s。
• Tokens/s。
• GPU Memory / KV Cache Usage。
• GPU Utilization。

GPU の混雑度は必ずしもキューイングとユーザー エクスペリエンスを反映するわけではないため、GPU Utilization を唯一のメトリックとして使用することはお勧めできません。

LLM Autoscaling に関する特別な質問

新しいモデル インスタンスを開始するには、次のことが必要になる場合があります。

1. GPUを割り当てます。
2. モデルの重みをプルまたはロードします。
3. 推論エンジンを初期化します。
4. KV Cacheを割り当てます。
5. ウォーミングアップを完了します。

そのため、LLM インスタンスのコールド スタートのコストは高くなる可能性があります。

スケーリングは瞬時には行われないため、トラフィック予測と適切な最小数のレプリカの組み合わせが必要です。

9. Health Check

区別する必要があります:

たとえば:

Model Loading
     ↓
Startup Not Ready
     ↓
Model Loaded
     ↓
Readiness Passed
     ↓
Receive Traffic

vLLM は、サービス ヘルス チェック用の /health などのエンドポイントを提供します。

注: ヘルスチェックが成功しても、インスタンスに新しいリクエストを受信するのに十分な KV Cache 容量が必要であるという意味ではありません。

したがって、運用環境でも Queue とリソース インジケーターを組み合わせて、実際のサービス機能を決定する必要があります。

10. Metrics、Logging、Monitoring

Metrics

実稼働環境では通常、次のものを使用します。

vLLM Metrics
      ↓
Prometheus
      ↓
Grafana
      ↓
Dashboards / Alerts

vLLM は Prometheus-compatible /metrics Endpoint を提供します。

重要な監視ポイント:

その中で、Running Requests、KV Cache使用率、Prefix Cache HitsなどはすべてvLLMの観測可能な指標です。

Logging

ログは、次のような特定のリクエストやシステム イベントを記録するために使用されます。

Request ID
Timestamp
Model Version
Status Code
Latency
Input / Output Token Count
Error Type

運用環境では、特に機密データが含まれる可能性がある場合、ユーザー Prompt とモデルの応答を完全にログに記録するようにデフォルト設定しないでください。

Tracing

Tracing は、さまざまなサービスを介した単一リクエストの実行パスに焦点を当てています。

Request ID
    ↓
API Gateway
    ↓
Application
    ↓
Retriever / Tools
    ↓
Inference Server
    ↓
Response

RAG および Agent アプリケーションの場合、Tracing は、遅延が取得、ツールの呼び出し、キューイング、またはモデル生成によるものであるかどうかを判断するのに役立ちます。

11. Deployment、Rolling Update、Rollback

リリースプロセス

Model / Container Version
          ↓
Deployment
          ↓
Model Loading
          ↓
Readiness Check
          ↓
Accept Traffic
          ↓
Monitoring

実稼働環境は明確に修正される必要があります。

• Model Revision / Weight Version。
• Tokenizer / Chat Template。
• Quantization Format。
• Inference Engine Version。
• Serving Configuration。

通常、モデル名を記録するだけでは、再現可能な展開を保証するのに十分ではありません。

Rolling Update

複数のインスタンスの場合は、次のものを段階的に更新できます。

vLLM-1: Old → New
vLLM-2: Old
vLLM-3: Old

新しいインスタンスの準備ができると、他の古いインスタンスが徐々に置き換えられます。

Graceful Shutdown / Draining

古いインスタンスを停止する場合:

Stop Accepting New Requests
            ↓
Allow In-flight Requests to Finish
            ↓
Release Resources
            ↓
Terminate Instance

長い Streaming リクエストの場合は、適切な最大 Drain 時間も設定する必要があります。

Rollback

新しいモデルの品質が低下したり、動作に異常が発生した場合:

New Model Version
       ↓
Monitoring Detects Problem
       ↓
Rollback
       ↓
Previous Stable Version

ロールバックには Docker Image が関係するだけでなく、モデルの重み、Tokenizer、サービス構成バージョンが一貫していることを確認する必要もあります。

12. 導入計画の選択

Kubernetes は LLM Serving の必須条件ではありません。単一の GPU または少数のインスタンスの場合は、通常、Docker Compose とリバース プロキシで初期展開のニーズを満たすのに十分です。

概要

実稼働レベルの LLM Serving では、主に次の 5 つの問題を解決する必要があります。

コアアーキテクチャ:

Client
   ↓
API Gateway
   ↓
Authentication / Rate Limit
   ↓
Load Balancer
   ↓
Inference Server
   ├── Queue / Scheduler
   ├── KV Cache Manager
   └── GPU Execution
   ↓
Streaming Response

Observability:
Metrics + Logs + Traces

Operations:
Health Check + Scaling + Deployment

実稼働レベル LLM Serving の目標は、モデルを実行できるようにするだけではなく、指定された GPU リソースの下で安全で予測可能でスケーラブルな推論サービスを提供し続けることです。

---

参考資料

• vLLM Serving
• vLLM Production Metrics
• vLLM Security
• Prometheus
• Grafana
• Kubernetes Autoscaling