LLMの推論基盤構築――vLLM・TGI・TensorRT-LLMの比較

LLMの自社推論基盤は、vLLM・TGI・TensorRT-LLMが3強で、汎用性と導入コストのバランスでvLLMが現時点のファーストチョイスです。API利用コストが月額数十万円を超えたあたりで、自社推論への切り替え検討が現実的になります。量子化、Continuous Batching、PagedAttention、KVキャッシュ共有という4つの最適化を組み合わせれば、APIに匹敵するコストパフォーマンスに到達できます。ただし、推論基盤の運用は「建てて終わり」ではなく、継続的なチューニングが必要な生き物であることを忘れてはなりません。

LLM推論基盤が必要な理由

LLMをAPIで利用できる現代において、わざわざ自社推論基盤を構築する理由は明確です。第一にコスト最適化で、大量のトークンを捌く場合、OpenAIやAnthropicのAPI料金は自社推論のGPU費用を上回ります。第二にレイテンシ制御で、ネットワーク遅延を排除し、First Token Latencyを安定させられます。第三にプライバシーとコンプライアンスで、外部APIに送れないデータでもLLMの恩恵を受けられます。第四にカスタマイズ性で、独自ファインチューニングモデルの運用が自由に行えます。

【LLM推論基盤のアーキテクチャ】

[クライアント]
     |
     v
[API Gateway / Load Balancer]
     |
     v
[Inference Server Pool]
  ├── vLLM Worker 1 (GPU #0)
  ├── vLLM Worker 2 (GPU #1)
  └── vLLM Worker N (GPU #N)
     |
     +---> [Model Repository (S3 / PVC)]
     +---> [Tokenizer Cache]
     +---> [KV Cache Store (Redis 等)]
     |
     v
[Monitoring / Logging]
  ├── Prometheus + Grafana
  └── OpenTelemetry

自社推論基盤の検討は「なんとなく」ではなく、月間トークン消費量とSLA要件をベースに開始すべきです。MLOpsとAI/ML基盤のコスト管理の観点からも、意思決定を整理しましょう。

主要推論エンジンの比較

LLM推論エンジンにはそれぞれの思想と得意領域があります。vLLMはUCバークレー発のOSSで、PagedAttentionとContinuous Batchingを実装し、高スループットを低コストで実現します。TGI(Text Generation Inference)はHuggingFace謹製で、transformersエコシステムとの親和性が強みです。TensorRT-LLMはNVIDIA製で、最速クラスのレイテンシとスループットを誇りますが、モデル変換の手間とハードウェア依存がトレードオフです。Ollamaは開発者の手元環境での手軽さが魅力で、llama.cppはCPUやAppleシリコンでの軽量動作に強みがあります。

エンジン	対応モデル	PagedAttention	量子化	スループット	導入難易度	ライセンス
vLLM	LLaMA系・Mistral・Qwen他多数	〇	AWQ・GPTQ・FP8	高	低	Apache 2.0
TGI	HuggingFace主要モデル	〇	GPTQ・AWQ・EETQ	高	低	HFOIL
TensorRT-LLM	NVIDIA最適化モデル	〇	FP8・INT4	最高	高	Apache 2.0
Ollama	GGUFフォーマット	限定的	Q4・Q5・Q8	中	極低	MIT
llama.cpp	GGUFフォーマット	―	Q2〜Q8	中	中	MIT

vLLMの起動は拍子抜けするほど簡単です。OpenAI互換のREST APIを立ち上げるので、既存のOpenAIクライアントコードをほぼ無改修で切り替えられます。

# vLLM Python API でのモデルサーブ
from vllm import LLM, SamplingParams

llm = LLM(
    model="meta-llama/Llama-3.1-70B-Instruct",
    tensor_parallel_size=4,   # 4 GPU 分散
    dtype="bfloat16",
    quantization="awq",       # AWQ 量子化
    gpu_memory_utilization=0.9,
    max_model_len=8192,
)

params = SamplingParams(temperature=0.7, max_tokens=512)
prompts = ["Explain RAG in one paragraph."]
outputs = llm.generate(prompts, params)

for output in outputs:
    print(output.outputs[0].text)

また、`python -m vllm.entrypoints.openai.api_server –model … `のCLIコマンド一発で、OpenAI互換APIを起動できます。オープンソースLLM比較もご参照ください。

推論最適化テクニック

LLM推論のスループットを決定づけるのは、主にメモリバンド幅とKVキャッシュ管理です。PagedAttentionはvLLMの中核技術で、KVキャッシュをページ単位で管理することで、従来の固定長確保に比べてGPUメモリ利用率を大幅に改善しました。Continuous Batchingは、リクエストごとに生成長が異なる問題を解決するバッチング手法で、GPU稼働率を常時高く保てます。

量子化は、精度をほぼ維持しながらモデルサイズとメモリ帯域を削減する定番手法です。GPTQは事後学習量子化の代表で、4bit化による精度劣化は1〜3%に抑えられます。AWQ(Activation-aware Weight Quantization)はアクティベーション分布を考慮した手法で、重要な重みを高精度に保ちます。GGUFはllama.cpp由来のフォーマットで、CPUやAppleシリコンでの動作に最適化されています。

手法	精度低下	メモリ削減	速度向上	対応エンジン
FP16 / BF16	ほぼなし	50%	2倍	全て
INT8	1%以内	75%	2〜3倍	vLLM・TensorRT-LLM
GPTQ (4bit)	1〜3%	87%	2〜4倍	vLLM・TGI
AWQ (4bit)	0.5〜2%	87%	2〜3倍	vLLM・TGI
FP8	0.5%以内	75%	3〜4倍	vLLM・TensorRT-LLM
GGUF Q4	1〜4%	85%	CPUで実用化	llama.cpp・Ollama

KVキャッシュの共有も重要な最適化ポイントです。プロンプトの前半が同じ場合(たとえば共通のシステムプロンプト)、KVキャッシュを使い回すことで計算量を削減できます。vLLMの「prefix caching」はこの仕組みを提供します。LLM推論コスト削減の記事では、より実践的な削減テクニックを扱っています。

本番環境へのデプロイ

本番環境では、Kubernetes上でvLLMをデプロイするのが定石です。GPU Operatorでノードを準備し、Deploymentでvllm-serverを立ち上げ、Serviceで内部公開、IngressでHTTPSを終端する構成です。HPA(Horizontal Pod Autoscaler)で負荷に応じたスケーリングを行い、PDB(Pod Disruption Budget)で可用性を担保します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-llama3-70b
spec:
  replicas: 2
  selector:
    matchLabels:
      app: vllm-llama3
  template:
    metadata:
      labels:
        app: vllm-llama3
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        args:
          - "--model"
          - "meta-llama/Llama-3.1-70B-Instruct"
          - "--tensor-parallel-size"
          - "4"
          - "--quantization"
          - "awq"
        resources:
          limits:
            nvidia.com/gpu: 4
        ports:
          - containerPort: 8000

オートスケーリングは、GPU利用率ではなく「待機中リクエスト数」をメトリクスに使うのが正解です。GPUは常時高利用率で動くため、GPU使用率ベースではスケールアウト判断が機能しません。Prometheusでvllmのメトリクスを収集し、KEDAやCustom Metrics Adapterでリクエスト数ベースのスケーリングを実装します。GPU基盤選定の観点も併せて検討してください。

コストとパフォーマンスのトレードオフ

API利用と自社推論のコスト比較は、月間トークン消費量を軸に行います。GPT-4o相当の品質を70B級のオープンソースLLMで置き換える前提なら、H100×4台のGPUインスタンスで、1時間あたり約400 USD程度がピーク時のコストです。24/7で稼働させると月あたり数百万円規模になりますが、アイドル時間があれば半分以下に抑えられます。

損益分岐点の目安として、GPT-4oで月間1,000万トークンを消費するワークロードなら、自社推論の方がコスト的に有利になり始めます。ただし、これは純粋な計算コストの話で、運用人件費、障害対応、モデル更新の手間などのTCOを含めると、損益分岐点は2,000〜3,000万トークン程度にシフトします。SLMで要件を満たせるなら、さらに安価な構成が可能です。

まとめ

LLM推論基盤の選択肢は成熟してきており、vLLMを中心とした構成でほとんどのユースケースをカバーできます。量子化とバッチング技術を組み合わせれば、自社推論でもAPIに匹敵するコスト効率が実現可能です。本番化の判断は、月間トークン消費量、レイテンシ要件、データプライバシー要件の3点から総合的に行うことをおすすめします。「とりあえず建てる」のではなく、定量的な根拠を持って意思決定してください。

よくある質問

Q. vLLMとは?

A. PagedAttentionとContinuous Batchingを実装した高速なLLM推論エンジンです。Apache 2.0ライセンスのOSSで、OpenAI互換APIを提供するため、既存クライアントから容易に移行できます。

Q. LLMの自社推論基盤はいつ検討すべきですか?

A. API利用のコストが月額数十万円を超える、レイテンシ要件が厳しい、データを外部に送れない、といった条件が揃ってきたら検討価値があります。PoC段階ではAPI利用で始め、本番規模が見えてから移行するのが現実的です。

Q. 量子化するとどのくらい精度が下がりますか?

A. 4bit量子化(GPTQ/AWQ)でベンチマークスコア1〜3%低下が一般的です。日常的なタスクでは体感差がほぼない場合も多く、コスト削減効果の大きさを考えると有力な選択肢です。