Cost, Billing, and Ops2026年10月14日Flatkey Team

独自GPUでOpenAI互換の推論サーバーを構築する：vLLM推論サーバーのOpenAI互換APIガイド

独自GPU上に vLLM 推論サーバーの OpenAI 互換APIを構築し、SDK移行、エッジ制御、テスト、メトリクス、フォールバックルーティングで本番対応に強化します。

すでにGPU容量があるなら、OpenAI互換の推論サーバーを使うことで、アプリケーション側のクライアント形状はそのままに、バックエンドをホスト型モデルAPIから自社インフラへ差し替えられます。一般的な流れは概念的にはシンプルです。GPUノードでvLLMまたはLocalAIを動かし、/v1 APIを公開し、SDKのbase_urlをそのエンドポイントに向け、あとは認証、ルーティング、監視、キャパシティ向けにサービスを強化します。

このガイドは実務的な構築に焦点を当てます。つまり、vllm inference server openai compatible api をどう立ち上げるか、本番トラフィックの前に何をテストすべきか、そして多くのワークロードはFlatkeyのような管理型モデルAPIへルーティングしつつ、自前ホスティングをベンチマークとして維持する方が賢いのはいつか、を解説します。

簡単な答え

多くのLLMテキストワークロードでは、まずvLLMから始めてください。vLLMはOpenAI互換のHTTPサーバーを提供し、読み込んだモデルの種類に応じて、チャット補完、補完、埋め込み、モデル一覧表示などの一般的なOpenAI風エンドポイントをサポートし、デプロイ用の公式Dockerイメージも提供しています。

最小構成のセルフホストスタックは次のようになります。

レイヤー	本番での選択肢	重要な理由
GPUホスト	H100、H200、B200、A100、L40S、またはその他の対応アクセラレータ	モデルサイズ、同時実行数、コンテキスト長、レイテンシ上限を決定します。
コンテナランタイム	NVIDIAドライバーとNVIDIA Container Toolkit	`--gpus all` を通じてDockerコンテナからGPUを認識できるようにします。
推論エンジン	高スループットなテキスト提供にはvLLM、より広いローカルOpenAI互換ユースケースにはLocalAI	vLLMはGPU上でTransformer LLMを提供する際の既定の出発点です。
API面	`/v1/chat/completions`、`/v1/completions`、`/v1/models`、およびモデルが対応する追加エンドポイントのみ	クライアント移行を小さく保ち、誤った互換性の前提を防ぎます。
エッジ	Nginx、Envoy、Caddy、またはクラウドロードバランサー	TLS、認証、リクエスト制限、ルーティングを処理します。
運用	メトリクス、ログ、GPUテレメトリ、カナリア、フォールバックルーティング	サーバーが見えない障害源になるのを防ぎます。

直接的なハードウェア制御、データ所在地、独自モデル重み、または予測可能な大規模提供コストが必要なときは、vllm inference server openai compatible api を使ってください。主に信頼できる出力が必要で、GPU利用率、ドライバーのずれ、モデル読み込み、フェイルオーバーを自分で管理したくない場合は、ゲートウェイ/モデルAPIを基準にしてください。

構築前に判断する: セルフホスティングは見合うか

自分でOpenAI互換の推論サーバーを運用することが、自動的に安くなるわけではありません。GPUが常に稼働し、ホストするモデルにワークロードが合っているなら非常に有効です。一方で、利用率が不規則、プロンプトのばらつきが大きい、モデル品質が頻繁に変わる、あるいはインフラのデバッグに製品開発以上の時間を使うなら、コスト高になり得ます。

ハードウェアを借りる、または購入する前に、この判断表を使ってください。

質問	はいならセルフホスト	はいなら管理APIまたはゲートウェイを優先
安定したトラフィックがありますか？	GPUを常時ウォームかつ高利用率に保てます。	トラフィックがバースト的、季節的、または実験的です。
カスタム重みが必要ですか？	ファインチューニング済み、量子化済み、またはプライベートモデルを提供します。	公開フロンティアモデルまたはオープンウェイトのホスト済みモデルで十分です。
データ所在地が必須ですか？	リクエストはVPC内またはオンプレネットワーク内に留まる必要があります。	標準的なAPIセキュリティ制御で要件を満たせます。
GPUインフラを運用できますか？	ドライバー、CUDA、コンテナ、メモリ、キュー、ロールアウトリスクをすでに監視しています。	GPU運用を製品ロードマップにしたくありません。
出力品質は安定していますか？	1つのモデルファミリーでワークフローに十分です。	多くのモデル間で比較、ルーティング、フェイルオーバーが必要です。

Flatkeyは最後の列の基準に適しています。1つのOpenAI互換エンドポイント、1つの利用枠、そして多くの公式モデルへのアクセスを提供します。vllm inference server openai compatible api を構築する場合でも、ベンチマークにはモデルAPIの基準を残し、GPU時間あたりのコストだけでなく、受理された出力あたりのレイテンシ、品質、コストを比較できるようにしてください。

参照アーキテクチャ

本番のOpenAI互換推論サーバーでは、モデルエンジンをそのまま公開インターネットに露出させるべきではありません。前段に薄い制御層を置いてください。

flowchart LR
  A[OpenAI SDK / app workers] --> B[API edge: TLS, auth, rate limits]
  B --> C[OpenAI-compatible /v1 route]
  C --> D[vLLM inference server]
  D --> E[GPU node or GPU pool]
  D --> F[Metrics and logs]
  B --> G[Fallback route: Flatkey or another model API]

重要な設計上の選択は、互換性と運用を分離することです。vLLMはOpenAI風APIを話せます。エッジ側は認証、クォータ、リクエストサイズ制限、TLS、監査ログ、フォールバック動作を担当すべきです。

ステップ1: GPUホストを準備する

クリーンなLinux GPUマシンから始めてください。ホストに以下があることを確認します。

実行予定のGPUとCUDAスタックに対応したNVIDIAドライバー。
Dockerまたは他の対応コンテナランタイム。
コンテナがGPUへアクセスできるように設定されたNVIDIA Container Toolkit。
モデル重みを置くのに十分なローカルまたはネットワークストレージ。
認証とTLSが整うまで推論ポートを公開しないネットワーク経路。

NVIDIA のコンテナツールキットのインストールフローでは、nvidia-ctk runtime configure --runtime=docker を使って Docker を設定し、その後 Docker を再起動します。その後は、Docker の GPU フラグを使って GPU アクセス付きでコンテナを実行できます。

モデルサーバーをインストールする前に、次の確認を実行してください:

nvidia-smi
docker run --rm --gpus all nvidia/cuda:12.6.0-base-ubuntu22.04 nvidia-smi

どちらかのコマンドが失敗する場合は、まずドライバー/ランタイム層を修正してください。ベースの GPU ランタイムが不安定では、vllm inference server openai compatible api は安定しません。

ステップ 2: vLLM Inference Server OpenAI Compatible API を起動する

vLLM の公式 Docker デプロイメントドキュメントでは、OpenAI 互換サーバーを実行するイメージとして vllm/vllm-openai が案内されています。最初の実行例は次のようになります:

docker run --rm --gpus all \
  --ipc=host \
  -p 8000:8000 \
  -e HUGGING_FACE_HUB_TOKEN="$HUGGING_FACE_HUB_TOKEN" \
  vllm/vllm-openai:latest \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --host 0.0.0.0 \
  --port 8000 \
  --served-model-name llama-3.1-8b-instruct

プライベートモデルの場合は、モデル ID を自分のリポジトリまたはローカルパスに置き換えてください。本番環境では、latest をデプロイするのではなく、イメージタグとモデルリビジョンを固定してください。

次に、モデル一覧をテストします:

curl http://localhost:8000/v1/models

そしてチャット補完をテストします:

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama-3.1-8b-instruct",
    "messages": [
      {"role": "system", "content": "You are a concise assistant."},
      {"role": "user", "content": "Reply with one sentence about self-hosted inference."}
    ],
    "temperature": 0.2
  }'

これが最初の動作マイルストーンです。つまり、アプリケーションが OpenAI スタイルのチャットで既に使用しているのと同じリクエスト形式で呼び出せる、ローカルの vllm inference server openai compatible api です。

ステップ 3: 既存の SDK をローカルエンドポイントに向ける

OpenAI 互換への移行作業の大半は、アプリケーションロジックではなく設定で行うべきです。Python SDK のパターンでは、カスタムの base_url と API キーを設定します:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="local-dev-key",
)

response = client.chat.completions.create(
    model="llama-3.1-8b-instruct",
    messages=[
        {"role": "user", "content": "Give me a deployment checklist."}
    ],
)

print(response.choices[0].message.content)

本番環境では、アプリのワーカーを生の vLLM プロセスに直接向けないでください。代わりに、社内のゲートウェイまたはロードバランサーに向けます:

OPENAI_BASE_URL=https://inference.example.com/v1
OPENAI_API_KEY=<your-internal-service-token>

そのゲートウェイでは、vLLM へのルーティング、未対応のリクエストフィールドのブロック、モデル別名の正規化、自社ホストのプールが飽和した場合の Flatkey や別のモデル API へのフェイルオーバーが可能です。

ステップ 4: 「OpenAI 互換」が意味しないことを理解する

OpenAI 互換とは、すべてのエンドポイント、モデルの挙動、ツール呼び出し、ストリーミングイベント、またはプロバイダー固有のオプションが OpenAI と完全に同じように動作することを意味するわけではありません。選択したエンドポイントについて、サーバーが見慣れた形式を受け入れるという意味です。

移行完了と判断する前に、次をテストしてください:

互換性領域	確認すべき内容
チャットメッセージ	ロールの扱い、system メッセージ、長いコンテキスト、使用する場合はマルチモーダルのペイロード。
ストリーミング	イベント形式、切断時の挙動、クライアントのタイムアウト、部分出力の処理。
ツール/関数呼び出し	読み込んだモデルとサーバーが、あなたのツール呼び出しパターンをサポートしているかどうか。
Embedding	読み込んだモデルが実際に embedding モデルであるかどうか。
エラーコード	エッジとエンジンでの 400、401、404、408、429、500、503 の挙動。
リクエストパラメータ	temperature、max tokens、top-p、stop シーケンス、追加のプロバイダー固有パラメータ。
トークン計上	プロンプト/出力トークン数とコストの帰属。

最も安全な方法は、互換性テストスイートを維持することです。実際のアプリケーションプロンプトの固定セットを OpenAI、Flatkey、そしてあなたの vllm inference server openai compatible api に送信してください。レイテンシ、スキーマの妥当性、拒否時の挙動、出力品質、受理された出力率を比較します。

ステップ 5: モデルとトラフィックに合わせて GPU メモリを見積もる

サービングの主な失敗モードは、「サーバーの起動が遅い」ことではありません。「サーバーは起動するが、実際のコンテキスト長と同時実行数で落ちる」ことです。

メモリ計画では次を考慮してください:

モデルの重み。
コンテキストと同時シーケンス用の KV キャッシュ。
ランタイムのオーバーヘッド。
断片化とヘッドルーム。
モデルが 1 枚の GPU に収まらない場合のテンソル並列化。
低精度を使う場合の量子化トレードオフ。

より詳しいワークシートが必要なら、Flatkey の LLM GPU メモリ要件ガイドを参照してください。クラスターレベルの計画には、これに GPU クラスターアーキテクチャと GPU クラスター TCO のような分析を組み合わせるとよいでしょう。

おおまかな受け入れ基準:

usable_capacity = model_fit + target_context + target_concurrency + 20-30% headroom

この余裕を確保できない場合は、コンテキスト長を短くする、同時実行数を減らす、より小さいモデルを使う、GPU 間で分割する、またはオーバーフローしたトラフィックをセルフホストのプールから別ルートに振り分けてください。

ステップ 6: 本番前に API エッジを追加する

生の vLLM サーバーは、本番向けの完全な制御プレーンではありません。その前段にエッジを置き、エッジに次の責任を持たせてください:

TLS 終端。
サービス間認証。
リクエスト本文の制限。
チーム別またはアプリ別のレート制限。
モデルエイリアスのマッピング。
構造化されたリクエストログ。
タイムアウトと再試行のバジェット。
カナリアルーティング。
フォールバックルーティング。

Nginx の例:

server {
  listen 443 ssl;
  server_name inference.example.com;

  client_max_body_size 4m;

  location /v1/ {
    proxy_pass http://vllm_backend:8000/v1/;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Request-Id $request_id;
    proxy_read_timeout 120s;
  }
}

これはあくまで出発点です。本番チームは、認証、mTLS またはプライベートネットワーク、リクエストログのポリシー、そしてプロンプトサイズと出力長に関する明示的な制限を追加すべきです。

ステップ 7: トークン毎秒だけでなく、受理された出力を測定する

GPU サービングのダッシュボードは、しばしばスループットを重視しがちです。トークン毎秒は重要ですが、製品チームが通常重視するのは受理された出力です。つまり、十分に速く、十分に妥当で、ユーザーや下流ワークフローにそのまま出せる品質の応答です。

次を追跡してください:

メトリクス	重要な理由
最初のトークンまでの時間	ストリーミングアプリでのユーザー体感レイテンシ。
エンドツーエンドのレイテンシ	キュー時間と生成時間の合計。
キュー深度	GPU プールが飽和しつつある早期警告。
GPU メモリ使用率	コンテキスト/同時実行の前提が現実的かどうか。
モデルエイリアス別のエラー率	モデル固有の障害を検出する。
出力スキーマ合格率	エージェント、抽出、ツールワークフローで重要。
受理済み出力率	品質、レイテンシ、有効性を組み合わせた指標。
フォールバック率	セルフホストのプールが十分でないときに示す。

次に、受理された出力あたりのコストを計算します:

cost_per_accepted_output =
  (gpu_cost + storage + network + ops_time + fallback_api_cost)
  / accepted_outputs

ここで vllm inference server openai compatible api は、マネージド API と公平に比較されます。ローカル GPU が生のトークン単価では安くても、再試行、失敗、運用者の工数が多ければ、受理済み出力あたりのコストは予想より高くなる可能性があります。

ステップ 8: GPUサーバーを単一障害点として扱うのではなく、フォールバックを追加する

アプリケーションは、応答がセルフホストの vLLM、Flatkey、または別のモデルルートのどれから来たかを気にするべきではありません。モデルエイリアスを要求し、応答または制御された失敗を受け取るべきです。

次のようなルーティングルールを使います:

条件	ルート
通常トラフィック、GPU 健全	セルフホストの vLLM。
GPU キューが閾値を超過	Flatkey モデル API にオーバーフロー。
モデルの読み込みまたは再起動	ウォームになるまで全トラフィックを Flatkey にルーティング。
スキーマ失敗が急増	カナリアでマネージド API に戻す。
実験的なプロンプト評価	比較のため、ローカルとマネージドの両方のモデルで実行。

この設計により、チームは単一の推論サーバーに製品可用性を縛られることなく、セルフホスティングの経済性と制御性を維持できます。

OpenAI 互換のローカル推論における vLLM と LocalAI の比較

vLLM と LocalAI はどちらも OpenAI 互換の推論サーバーを探す際に候補として挙がりますが、適した用途は異なります。

オプション	最適な用途	注意点
vLLM	GPU 上での高スループットな LLM サービング、特に Transformer 系のテキストモデル。	互換性はモデルの種類とエンドポイントに依存します。本番向けの堅牢化は依然としてその周辺で必要です。
LocalAI	複数のローカルモデルバックエンドとモダリティにまたがる、ローカルな OpenAI 互換 API。	スループットと GPU の挙動は、バックエンド、モデル、ハードウェアに大きく依存します。
Flatkey	多数の公式モデルにわたる、マネージドな OpenAI 互換モデル API のベースライン。	サービングエンジンへの直接制御は失われますが、GPU 運用を自分で持つ必要はありません。

この記事の対象ワークロードでは、まず vllm inference server openai compatible api から始めてください。目標が 1 つの LLM ファミリーに対する最大の GPU サービングスループットではなく、より広いローカル実験や複数バックエンドにまたがる単一のローカル API である場合に、LocalAI を評価してください。

本番チェックリスト

実ユーザーにルーティングする前に、次を使用してください:

[ ] GPUドライバーとコンテナランタイムが、コンテナ内のnvidia-smiで検証済み。
[ ] vLLMのイメージタグとモデルリビジョンが固定済み。
[ ] モデルエイリアスが安定しており、文書化済み。
[ ] /v1/models と /v1/chat/completions が最終エッジURL経由でテスト済み。
[ ] ストリーミングがクライアント切断込みでテスト済み。
[ ] 長文コンテキストと同時実行テストを、想定する本番規模で実施済み。
[ ] エッジ側で認証を追加済み。生のvLLMポートは公開していない。
[ ] リクエスト本文サイズ、最大出力トークン、タイムアウトを強制済み。
[ ] ログから、明示的に承認されていない限り機密プロンプトデータを除外済み。
[ ] メトリクスでレイテンシ、キューイング、GPUメモリ、エラー率、および受理出力率を取得済み。
[ ] 飽和時および障害時のフォールバックルートを設定済み。
[ ] 同じプロンプトを使って、マネージドAPIのベースラインを測定済み。
[ ] ロールバック計画をテスト済み。

よくあるミス

最大のミスは、最初の成功したcurlを作業完了とみなしてしまうことです。それは始まりにすぎません。

その他によくある失敗:

latestイメージを、本番でバージョン固定せずに実行する。
生の推論ポートをインターネットに公開する。
すべてのOpenAIリクエストパラメータがサポートされていると想定する。
短いプロンプト1つだけでベンチマークし、その結果を「本番対応済み」と呼ぶ。
実際のコンテキスト長によるKVキャッシュの増大を無視する。
モデルのロード時間がデプロイや復旧に影響することを忘れる。
GPU時間コストだけを測り、運用者の時間、リトライ、品質失敗を含めない。
ローカルエンドポイントが「OpenAI互換」だからといってフォールバックを省略する。

本番のvllm inference server openai compatible apiは有用なインフラです。魔法のような互換性ではありませんし、運用上の規律の代わりにもなりません。

独自GPUと併用してFlatkeyを使うべき場合

このアーキテクチャでは、Flatkeyはマネージドなモデル/APIのベースラインとフォールバックパスとして最も有用です。アプリケーションはOpenAI互換のクライアント形状のままにして、一部のトラフィックをローカルGPUプールへ、残りをFlatkeyへルーティングします。

そうすることで、次のことが可能になります:

セルフホストの出力品質をホスト型モデルと比較する方法。
ローカルGPUが飽和したときのオーバーフロー容量。
ドライバー、モデル、またはデプロイの障害時のフォールバックルート。
プロバイダーキーを増やさずに他のモデルファミリーへアクセスする方法。
セルフホストモデルの性能が不足した場合に、マネージドAPIへ戻るよりクリーンな経路。

判断は「自前GPUかAPIか」ではありません。多くのチームにとって、持続可能な構成は両方です。制御やコスト面で有利な箇所ではGPUパスを自前で持ち、レジリエンスとモデル選択のためにマネージド経路を維持します。

FAQ

OpenAI互換の推論サーバーとは何ですか?

OpenAI互換の推論サーバーは、通常/v1配下で、OpenAI風のリクエストおよびレスポンス形状を持つHTTPエンドポイントを公開します。これにより、アプリケーションはbase_urlをカスタム設定するなど、慣れたSDK構成を使いながら別のバックエンドへトラフィックを送れます。

vLLMはOpenAI互換の推論サーバーですか?

はい。vLLMはOpenAI互換サーバーを提供し、モデルタイプと機能に応じて、チャット補完、補完、埋め込み、モデル一覧などの一般的なOpenAI風エンドポイントのサポートを文書化しています。

vLLMのOpenAI互換サーバーをローカルで実行できますか?

はい。GPUワークステーションまたはサーバー上でvLLMをローカル実行し、/v1エンドポイントをアプリケーションに公開できます。本番では、その前段に認証付きのエッジまたは内部ゲートウェイを配置してください。

どのようなハードウェアが必要ですか?

モデルサイズ、精度、コンテキスト長、同時実行の目標によります。まずモデル重み、KVキャッシュ、余裕分を見積もり、そのうえで実際のプロンプトでテストしてください。小さな指示モデルは1枚のGPUに収まる場合がありますが、70Bモデルや高同時実行ワークロードでは、より大容量のGPUやテンソル並列が必要になることがあります。

vLLMとLocalAIのどちらを使うべきですか?

GPU上で高スループットのLLM推論を行うなら、まずvLLMを使ってください。複数のローカルバックエンドやモダリティをまたいで、より広範なローカルOpenAI互換サーバーが欲しい場合はLocalAIを評価してください。

OpenAI互換は、そのまま差し替え可能という意味ですか?

いいえ。エンドポイントの形は一致しても、モデルの挙動、サポートされるパラメータ、ツール、ストリーミング、埋め込み、エラー、トークンの計上は異なる場合があります。本番トラフィックを切り替える前に互換性テストを実施してください。

結論

vllm inference server openai compatible apiを構築することは、自分のGPUをOpenAI風エンドポイントへ変える最も実用的で速い方法です。中核となる構築はシンプルです。GPUランタイムを準備し、vLLMを起動し、SDKの/v1先を向け、その後、本番運用レベルにするためのエッジ、監視、互換性テスト、フォールバックルートを追加します。

優れたチームは「動いた」で止まりません。セルフホスト推論をマネージドなモデルAPIのベースラインと比較し、受理された出力を測定し、フォールバックルートを常に準備しています。そうすることで、すべてのプロダクト要求が脆弱な推論サーバー1台に依存することなく、自前GPUのコントロールを得られます。

公式リファレンス

vLLM OpenAI互換サーバーのドキュメント: https://docs.vllm.ai/en/latest/serving/online_serving/
vLLM Docker デプロイメントのドキュメント: https://docs.vllm.ai/en/latest/deployment/docker/
NVIDIA Container Toolkit インストールガイド: https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html
OpenAI Python SDK README: https://github.com/openai/openai-python
LocalAI プロジェクトのドキュメント: https://localai.io/