# Triton Inference Server [[NVIDIA]]が開発するモデル推論サーバー。XGBoost・TensorFlow・PyTorch・LLMなど多様なフレームワークのモデルを単一インターフェース越しに配信し、モデルロード・バッチング・GPUスケジューリングを管理する。 [[Netflix]]のMSS(Model Scoring Service)ではTritonがGPU推論の共有バックエンドとして使われ、上位にデプロイ・バージョニング・ヘルスチェック・オートスケーリングを担うJava制御プレーンが乗る構成になっている。([[@2026__Netflix TechBlog__In-House LLM Serving at Netflix]]) ## モデルパッケージングの2方式 - **Pythonバックエンド**: 作者が入出力テンソル仕様を明示的に定義する。仕様が成果物に固定されるため、フロントエンドのI/O仕様変更のたびにパッケージングコード側の協調変更が必要になる。 - **vLLMバックエンド**: 成果物はモデル重みとトークナイザを指すJSON設定のみで、I/Oテンソル仕様はデプロイ時に動的生成される。モデルとフロントエンドが独立に進化できるため、Netflixはこちらをアーキテクチャ上の既定として採用した。 Netflixの本番運用では、TritonのvLLMバックエンドが特定のvLLM API surfaceに対してコンパイルされているため、Triton/vLLMのバージョンが乖離するとバックエンドがロードに失敗する問題が発生した(例: Triton 25.09がvLLM 0.11.2で削除されたモジュールをインポートしようとする)。サービスイメージのビルド時にバージョンを固定し、パッケージング時のバージョン上書きを禁止することで対処している。(Source: [[@2026__Netflix TechBlog__In-House LLM Serving at Netflix]]) ## OpenAI互換フロントエンド TritonはOpenAI互換API用のフロントエンドを提供しており、埋め込みTritonサーバー・`TritonLLMEngine`・FastAPIの組み合わせで実装される。KServeのHTTP/gRPCフロントエンドとも併存できる。Netflixの導入では、スキーマ上受理される`response_format`がvLLMに届く前に黙って捨てられる欠落があり、git-subtreeでフロントエンドを取り込んでパッチを当てる対応が必要だった。(Source: [[@2026__Netflix TechBlog__In-House LLM Serving at Netflix]]) ## 観測性のギャップ vLLMはメトリクスを`PROMETHEUS_MULTIPROC_DIR`にファイルとして書き出し、Tritonは自身のPrometheusエンドポイントでサーバーレベルのメトリクスを報告する。両者は互いを認識せず、Tritonの組み込みブリッジは40以上あるvLLMメトリクスのうち9個しか橋渡ししないため、トークンスループットやKVキャッシュ利用率などの重要指標が欠落する。(Source: [[@2026__Netflix TechBlog__In-House LLM Serving at Netflix]]) ## 関連 - 開発元: [[NVIDIA]] - 推論エンジン: [[vLLM]] / [[TensorRT-LLM]] - 導入事例: [[Netflix]] - ソース: [[@2026__Netflix TechBlog__In-House LLM Serving at Netflix]]