Kinference: vLLMとKubernetesのためのオープンソース推論コントロールプレーン

Buoyantは、Kubernetes上でvLLM推論プラットフォームを実行するためのオープンソースのコントロールプレーンであるKinference（発音は「ケイ・インファレンス」）をリリースしました。KinferenceはvLLMワーカーの前に位置し、通常のKubernetesにはないプラットフォームレベルの機能を追加します。KVキャッシュ対応のロードバランシング、ルーティングとコスト制御のためのYAMLポリシーエンジン、テナントごとの推論メトリクスなどです。Buoyantの公開ベンチマークでは、KVキャッシュ対応ルーティングにより、標準的なKubernetesのロードバランシングと比較して、あるワークロードタイプで中央値のタイム・トゥ・ファースト・トークンが95%、中央値のエンドツーエンド遅延が45%削減されました。

KinferenceはApache v2の下で完全にオープンソースであり、GitHubのKinference-AI/kinferenceで入手できます。これは、vLLMが基盤となる推論を実行し、自分で構築するプラットフォームのコントロールプレーン層として設計されています。

Kinferenceとは何か、そしてどこに適合するか

Kinferenceはコントロールプレーンであり、推論エンジンではありません。実際のモデルサービングにはvLLMを使用し、オープンウェイトモデルを実際に運用するために必要な周辺プラットフォーム機能（トークンレート制限、テナント使用量とコスト追跡、インテリジェントなロードバランシング、推論ポリシー）を提供します。

導入にあたっては、推論クライアントをKinferenceのHTTPエンドポイントに向ける以外の変更は必要ありません。KinferenceはOpenAI互換またはAnthropic互換の推論トラフィックを受け入れるため、既存のクライアントライブラリやアプリケーションは変更なしでリダイレクトできます。

このプロジェクトは、顧客が自社環境でオープンウェイトモデルを実行するのに苦労しているのを観察した後、Buoyantで作成されました。Buoyantは中核的な問題を、「異種で進化するモデル群を、異種で進化するGPUプール上で、異種で進化するクライアント群にサービスを提供すること」と位置づけています。

Kinferenceは、トラフィックゲートウェイと推論ハンドラーの2つの独立してリリースされるコンポーネントとして提供されます。各コンポーネントは、コンポーネント自体の前にインストールする必要がある別々のHelmチャートとしてCRDを提供します。

KVキャッシュ対応ロードバランシング

Kinferenceのロードバランサーは、一般的な接続レベルのシグナルではなく、推論固有のシグナルに基づいてルーティングします。GPUキューのサイズ、過去のパフォーマンス、各GPUのKVキャッシュの内容を考慮します。

KVキャッシュ認識が重要な差別化要因です。特定のGPUに既にキャッシュされているものをモデル化することで、Kinferenceはその特定のリクエストに対して最も追加作業が少ないvLLMワーカーにリクエストを送信できます。これは、共有プレフィックスやマルチターン会話を伴うワークロードで最も重要であり、プロンプトの大部分がワーカーのキャッシュに既に存在する可能性があります。

ベンチマーク結果

Buoyantは、標準的なKubernetesのロードバランシング（チャートでは「service」と表示、対して「kinference」）に対する2つのベンチマーク比較を公開しました。

未負荷遅延ベンチマーク — KVキャッシュ対応ロードバランシングの効果を分離するように設計されています：

  • 中央値のタイム・トゥ・ファースト・トークン（TTFT）が**95%**削減
  • 中央値のエンドツーエンド遅延が**45%**削減

これらの数値は、そのベンチマークの1つのワークロードタイプに適用されます。

容量ベンチマーク — 各エンドポイントが遅延SLO内で処理できる1分あたりのリクエスト数を測定しました：

  • 共有プレフィックスワークロードで7.4倍のグッドプット
  • マルチターンワークロードで約3.5倍のグッドプット
  • Kinferenceは、共有プレフィックスでは同時実行数32（測定最大）、マルチターンでは同時実行数8で選択したSLOを達成
  • kube-proxyアプローチは、どの同時実行レベルでもSLOを達成できませんでした

ベンチマークのセットアップ、プロセス、調査結果の詳細は、Buoyantの別のベンチマークレポートに公開されています。

推論ポリシー：ポリシー駆動のルーティング層

Kinferenceの中心的な抽象化は推論ポリシーです。Buoyantは、一回限りの機能セットを提供するのではなく、多くのルーティング、コスト、優先順位の要件を単一のメカニズムで表現することを目的としたポリシー層を構築しました。

ポリシーにより、プラットフォーム所有者は使用量、パフォーマンス、優先順位の間のトレードオフをバランスさせることができます。Buoyantは、設計の動機となった2つの繰り返し発生する顧客の質問を挙げています：

  • ユーザーは、「任意のQwen 3.8モデル」や「コーディングに適したもの」など、より広いクラスのモデルを、「Qwen 3.8 27Bパラメータ FP8量子化」のような特定のチェックポイントではなく、どのようにリクエストできるか？
  • ユーザーが高価なモデルをリクエストした場合でも、プロンプト履歴全体をコールドGPUに送信して大きな遅延ヒットを発生させることなく、「簡単な」リクエストをより安価なモデルにリダイレクトするにはどうすればよいか？

ポリシーはKubernetesカスタムリソース（kind: InferencePolicy、apiVersion: kinference.buoyant.io/v1alpha1）として宣言され、テナント、リクエストされたモデル、基盤となるGPUプールの状態、プロンプトのセマンティック分類、その他の要因に基づいてリクエストをルーティングまたは拒否できます。宣言型YAMLであるため、ポリシーは人間またはエージェントによるレビューを受け、gitにコミットされ、lintおよび検証され、独立して適用またはロールバックできます。

例：より安価なモデルへのセマンティックルーティング

次のポリシーは、プロンプトを複雑さによってセマンティックに分類し、より単純なプロンプトをより安価なモデルにルーティングします。ただし、キャッシュ使用量を考慮して、高価なモデルに送信する方が速い場合は除きます：

apiVersion: kinference.buoyant.io/v1alpha1
kind: InferencePolicy
metadata:
  name: smart-semantic-routing
  namespace: inference
spec:
  rules:
  - name: low-complexity-consider-qwen
    matches:
    - model: glm-5.3
      tag: complexity-low
    route:
      consider:
      - models: { names: [ qwen-3.6-27b, glm-5.3 ] }
      select: [ { minimize: PredictedTTFT } ]

例：クラウドプロバイダーへのバースト

このポリシーは、キュー深度またはキャッシュプレッシャーがGPUの飽和を示している場合に、過剰なリクエストをサードパーティプロバイダーエンドポイント（Buoyantは例としてOpenAI、Anthropic、Databricksを挙げています）にバーストします：

apiVersion: kinference.buoyant.io/v1alpha1
kind: InferencePolicy
metadata:
  name: burst-policy
  namespace: inference
spec:
  rules:
  - name: burst-to-cloud
    route:
      exclude:
      - name: drop-overloaded-workers
        drop:
          backend:       { type: Local }
          queuedPrompts: { greaterThan: 2 }
 
      select:
      - { type: Local,
          minimize: PredictedTTFT }
      - { type: Provider,
          order: [bedrock, databricks] }

例：PIIをクラスター内に保持

このポリシーは、プロンプトにPIIが含まれているかどうかを分類し、そのようなリクエストがクラスターから出ることを防ぎ、ローカルバックエンドが利用できない場合はフェイルクローズします：

apiVersion: kinference.buoyant.io/v1alpha1
kind: InferencePolicy
metadata:
  name: pii-stays-local
  namespace: inference
spec:
  rules:
  - name: serve
    route:
      exclude:
      - name: pii-never-leaves-cluster
        if:   { tag: pii-detected }
        drop: { backend: { type: Provider } }
      select:
      - { type: Provider,
          order: [ databricks ] }
      - { type: Local,
          minimize: PredictedTTFT }
      onEmpty: Reject   # fail closed

推論メトリクスとSLO

Kinferenceは、監視、アラート、SLO構築のための推論固有のメトリクスのスイートを公開します。報告されるメトリクスには以下が含まれます：

  • 入力および出力のトークンレート、および入力/出力トークンサイズのヒストグラム
  • TTFT、ITL（トークン間レイテンシ）、およびエンドツーエンドレイテンシのヒストグラム
  • コスト見積もりのための未キャッシュ対キャッシュ済みプロンプトトークン
  • モデル使用量とGPU飽和度

ほぼすべてのメトリクスはテナントごとにも利用可能であり、オペレーターはテナント使用量を追跡し、テナント固有のパフォーマンスSLOを構築し、プラットフォームが各コンシューマーの要件を満たしていることを確認できます。

Kinferenceのインストール

公開されているクイックスタートでは、Kinferenceをdefault名前空間にインストールします。他の名前空間では、Helmコマンドで名前空間を上書きする必要があります。以下の手順は、発表で指定されたバージョンとチャートの場所を反映しています。Buoyantは、手順が進化するにつれて、公式ドキュメントkinference.ai/docsを最新の情報源として扱うべきであると述べています。

1. Gateway API CRDのインストール

GWAPI_VERSION=1.5.1
kubectl apply --server-side --force-conflicts -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v$GWAPI_VERSION/standard-install.yaml

2. Kinferenceゲートウェイのインストール

helm upgrade -i gateway-crds \
  oci://ghcr.io/buoyantio/charts/gateway-crds \
  --devel
 
helm upgrade -i gateway \
  oci://ghcr.io/buoyantio/charts/gateway \
  --devel --wait

3. Kinferenceのインストール

helm upgrade -i kinference-crds \
  oci://cr.kinference.ai/kinference-ai/charts/kinference-crds \
  --devel
 
helm upgrade -i kinference \
  oci://cr.kinference.ai/kinference-ai/charts/kinference \
  --set extension.enabled=true \
  --devel --wait

4. インストールの確認

kubectl get podsを実行し、両方のプロセスが実行されていることを確認します：

NAME                           READY   STATUS    RESTARTS   AGE
gateway-cp-566cddc46d-jsqlq    1/1     Running   0          8s
kinference-7bb854cfc5-pp4t7    1/1     Running   0          8s

なぜ重要か

Kinferenceは、オープンウェイトモデルが単一のvLLMデプロイメントから共有のマルチテナントプラットフォームに移行すると現れるギャップに対処します。Kubernetesのデフォルトのロードバランシングは接続指向であり、推論状態を認識しません。これは容量ベンチマークで直接示されています：kube-proxyアプローチはテストされたどの同時実行レベルでも遅延SLOを満たせませんでしたが、Kinferenceは共有プレフィックスワークロードで測定された最大同時実行数でSLOを満たしました。

ルーティング決定をハードコードされた機能ではなく宣言型YAMLにすることで、Kinferenceは推論プラットフォームの動作を、標準的なGitおよびKubernetesワークフローを通じてレビュー可能かつ元に戻せるようにします。これには、PIIをクラスター内に保持し、フェイルクローズデフォルトを持つような安全関連ルールも含まれます。

Buoyantは、プロジェクトのGitHubリポジトリを介して、フィードバック、問題、他のデプロイメントからのベンチマークレポートを明示的に歓迎しています。

Sources