モデルサービングとは？推論APIの構成とKServe・Triton・BentoMLの選定基準を解説【2026年版】

モデルサービング（model serving）は、学習を終えた機械学習モデルを、ほかのシステムから呼び出せる推論APIとして提供し続けるための仕組みです。ノートブック上で動いたモデルをアプリケーションのプロセスへ直接抱え込ませると、同時アクセスで待ち行列が伸び、モデルを差し替えるたびにサービス全体を停止することになります。サービング層を独立させれば、モデルの版と業務ロジックの版を別々に動かせるでしょう。この記事では、推論APIの内部構成、主要ランタイムの守備範囲、マネージドと自前Kubernetesの分岐、自前で組んでよい下限条件までを2026年8月時点の一次情報で整理します。

まとめ｜配置方式とランタイムの決め方

結論から示します。最初に決めるのは推論の配置方式です。応答をユーザーが待つならオンライン推論、待たないなら夜間のバッチ推論に寄せます。この一点でインフラ費用は桁で変わるため、ランタイムの比較より先に片付けてください。

ランタイムは、既にKubernetesを運用しているならKServe（0.19.0・2026-06-14公開、CNCFのincubatingプロジェクト）、GPU実機を持つならNVIDIA Triton Inference Server（2.71.0・2026-07-29公開）、少人数でPythonのまま素早く出すならBentoML（1.4.39・2026-05-07公開）が第一候補です。PyTorch公式のTorchServeはリポジトリがアーカイブ済みで、最新リリースは0.12.0（2024-09-30公開）のため、新規採用の候補から外す判断が妥当でしょう。

モデルサービングの定義と役割｜組み込み推論・バッチ推論との違い

用語としてのサービングは「提供」を指しますが、実装上は「推論を独立したサービスとして切り出すかどうか」の設計判断です。

サービングが担う4工程｜受信・前処理・推論・後処理を分離する理由

推論APIの内部は、リクエストの受信、特徴量への前処理、モデル本体の推論、結果の後処理という4工程に分かれます。この4つを1つの関数へ詰め込むと、前処理だけを直したいときにもモデルごと再配備することになり、切り戻しの単位も粗くなってしまいます。

工程を分ける効き目は、負荷特性の違いに現れます。前処理と後処理はCPU側の仕事で、推論本体だけがGPUを使う構成が一般的です。同じプロセスに同居させると、CPU待ちの間もGPUが遊びます。KServeのように前処理（Transformer）と推論（Predictor）を別コンテナへ分ければ、両者を独立してスケールできます。

学習側のパイプライン（データ収集・学習・再学習）は、サービングの守備範囲外です。機械学習全体の運用サイクルについてはMLOpsの仕組みと導入判断で整理しているため、本記事では学習が終わったあとの配備と運用だけを扱います。

オンライン・バッチ・ストリーミングの3方式と選び分けの判断基準

推論の配置方式は3つです。オンライン推論はリクエストごとに即時応答を返す形で、レコメンドや不正検知が該当します。バッチ推論は蓄積したデータをまとめて処理し、結果をテーブルへ書き出す形。ストリーミング推論はキューのイベントを順次処理します。

選び分けの基準は「結果を誰が、いつ見るか」の一点です。人が画面の前で待つならオンライン、翌朝のレポートに載ればよいならバッチという整理で、迷う場面は多くありません。判断を誤りやすいのは推薦系で、全ユーザー分のスコアを夜間に計算してキャッシュしておけば、オンライン推論そのものが不要になる場合もあります。

費用の差は無視できません。夜間の数十分だけGPUを借りる構成と24時間確保する構成では、同じモデルでも月額が10倍以上離れることも起こり得ます。

推論APIの内部構成｜モデルレジストリ・動的バッチング・スケール単位

サービング基盤の実装は、モデル成果物の受け渡し、スループットを作る仕組み、スケールの単位という3層に分けると設計しやすくなります。

モデルレジストリと成果物の受け渡しで先に固定する3項目の規約

学習側が出力したモデルを、サービング側がどう受け取るかを決めます。固定すべきは、保存形式（state_dict、SavedModel、ONNXなど）、置き場所（オブジェクトストレージのパス規約）、版の付け方（連番かハッシュか）の3項目。これが決まっていれば、学習と配備を別チームが担当しても引き渡しが成立します。

保存形式で迷うなら、交換形式への変換を先に検討してください。フレームワーク非依存の形式へ寄せると、推論側のランタイムを後から差し替えられます。変換の仕組みと制約はONNXのモデル変換と推論の仕組みで扱っています。

動的バッチングと並行実行でGPUの待ち時間を埋める設計の勘所

GPUは、1件ずつ推論を投げると性能を出し切れません。同時に届いた複数のリクエストをサーバ側で束ね、1回の演算としてまとめて処理する仕組みが動的バッチングです。待ち合わせ時間の上限（数ミリ秒から数十ミリ秒）を設定し、その間に集まったリクエストを1バッチにします。

効果は入力サイズの均質さで決まります。画像分類のように入力形状が揃う処理では、束ねるほどスループットが伸びていきます。系列長がばらばらのテキスト処理では、短い入力が長い入力に引きずられ、束ねすぎるとp95が悪化しかねません。

もう1つの手段が並行実行です。1つのGPUに同じモデルのインスタンスを複数載せ、前処理待ちの間に別のリクエストを走らせます。増やしすぎるとメモリ不足で起動に失敗するため、実測しながら1つずつ増やしてください。

スケールの単位の決め方と、ゼロスケールが成立する条件の見極め

オートスケールの判断材料は、CPU使用率ではなく同時リクエスト数かキューの待ち件数を使います。GPU推論ではCPU使用率が低いままGPUが飽和するため、CPU基準ではスケールが遅れます。KServeがKnative経路で同時実行数を基準にする設計は、この事情によるものです。

リクエストがない時間帯にインスタンスを0まで落とすゼロスケールは、費用面では魅力があるものの、成立条件が限られます。分かれ目はモデルの読み込み時間で、数百メガバイトのモデルをオブジェクトストレージから取得してGPUへ載せるまでに数十秒かかる場合、最初のリクエストがその時間ぶん待たされる形になります。社内向けで日中しか使われない用途なら選択肢に入りますが、応答時間の約束がある外部公開のAPIでは最低1インスタンスを常時起動させてください。

主要サービングランタイムの比較｜2026年8月時点の版と守備範囲

ランタイムは機能の多さではなく、既存の運用基盤と担当者の人数で決まります。代表的な6つを守備範囲で並べます。

6製品の比較表｜自社設置の可否・得意領域・向く場面で横に並べる

いずれもオープンソースで自社設置が可能ですが、前提とする運用体制が異なります。版と公開日は2026-08-03にGitHub APIで実測した値です。

KServeはKubernetes上で InferenceService というカスタムリソースを書くだけで、推論サーバ・オートスケール・トラフィック分割までを宣言的に扱える基盤です。CNCFのincubatingプロジェクトで、GitHubのスター数は5,764。Tritonはスター数10,889でライセンスはBSD-3-Clause、TensorRT・ONNX・PyTorchなど複数の実行形式を1つのサーバへ同居させられます。このうちTensorRT系の実行形式を担うエンジン側の中身と、Tritonへ載せるかどうかの判断材料はTensorRT-LLMの仕組みと採用判断を解説した記事にまとめています。両者は競合ではなく、KServeがTritonを内部の推論サーバとして呼ぶ組み合わせが標準的な形です。

TorchServeはアーカイブ済み｜新規採用の候補から外す判断根拠

ここは明確に言い切ります。TorchServeを新規プロジェクトの候補に入れる理由は、2026年8月時点では見当たりません。GitHubリポジトリはアーカイブ状態（読み取り専用）で、最新リリースは0.12.0、公開日は2024-09-30です。リポジトリへの最終push日は2025-08-06で、以降の更新が止まっています。

日本語の解説記事にはTorchServeを標準の選択肢として挙げるものが残っているため、記事の公開年だけで判断すると古い前提を引き継ぐことになります。既に本番系がある場合は、脆弱性修正が供給されない前提でリスクを評価し、移行先としてKServeかBentoMLを検討してください。

同種の判断が必要な製品はほかにもあります。Seldon Coreは2.10.2（2025-12-19公開）が最新で、最終pushは2026-03-23。更新間隔は他製品より長い状況です。採用前にリリース頻度を確認する手順を、選定の標準工程へ入れてください。

LLMは汎用サービングと分ける｜専用CRDと推論エンジンの層構造

大規模言語モデルの提供は、汎用のモデルサービングとは別の層として扱う流れになっています。KServe 0.19.0のリリース内容を見ると、従来の InferenceService とは別に LLMInferenceService 系の機能追加が並び、異種GPU間の負荷分散やllm-dコンポーネントの移行対応が入りました。READMEでも、生成AI向けにvLLMとllm-dを性能面で仕上げたバックエンドとして扱うと明記されています。

分岐が起きた理由は、LLM推論の性能を決める要素が汎用モデルと違うためです。KVキャッシュの管理、連続バッチング、テンソル並列は推論エンジン側が持ち、サービング基盤は配置とルーティングを担う分業になります。NVIDIAが2025年3月に公開したDynamo（1.3.0・2026-07-22公開）も同じ層の製品です。

LLMを提供する具体の手順と、vLLM・SGLang・TensorRT-LLMなど推論エンジンの比較は、LLM Servingの仕組みと主要フレームワーク比較で扱っています。本記事は分類・回帰・画像・埋め込みを含む汎用モデルの配備が主題のため、エンジン単位の比較はそちらへ委ねます。

マネージド推論と自前Kubernetesの分岐｜費用構造と要員数で決める

クラウド各社のマネージド推論を使うか、自前でKubernetesクラスタを持つかは、機能ではなく費用構造と要員数で決まります。

常時起動エンドポイントの費用構造と、待機時間の扱い方の判断基準

Amazon SageMaker、Vertex AI、Azure Machine Learningのいずれも、リアルタイム推論のエンドポイントは「インスタンスを起動している時間」に対して課金されます。リクエストが1件も来なくても、費用は発生し続けます。GPUインスタンスを24時間確保する構成では、この待機時間ぶんが総額の大半を占める例も珍しくありません。

対策は、ゼロスケール可能なサーバーレス推論を使う、非同期推論（キューへ入れて処理する方式）へ寄せる、バッチ変換へ切り替えるの3通り。単価は各社とも改定が入るため、比較のたびに公式の料金ページで確認してください。判断に効くのは単価より、月間リクエスト数と1件あたりの推論時間から求める実稼働率です。1割を下回るなら、常時起動のエンドポイントは釣り合いません。

マネージド推論を選ぶ3条件と、自前基盤へ踏み込む条件の線引き

マネージドを選ぶ条件は3つです。専任のインフラ担当がいない、モデルの本数が10本未満、クラウドのマネージド機械学習基盤を既に使っている。この状態でKubernetesクラスタを立てると、推論以外の運用作業（クラスタの版上げ、ノードの入れ替え、ネットワークの管理）が新たに発生します。

自前基盤へ踏み込む条件も明確です。オンプレミスのGPUを保有している、推論トラフィックが常時GPUを埋める規模に達している、モデルの本数が数十を超えている、推論データを特定のネットワーク外へ出せない。いずれかに当てはまるなら、KServeで型を作る投資が回収できます。

本番で落ちる箇所｜モデルの版の切替・監視指標・コールドスタート

配備が終わってからの運用で問題が出るのは、だいたい決まった3か所です。

カナリアとブルーグリーンでモデルの版を切り替える手順と判断基準

モデルの差し替えは、オフラインの精度指標が改善していても本番で悪化する場合があります。入力の分布が検証データと違うためで、切り替えは段階的に行ってください。KServeでは InferenceService にトラフィックの配分比率を書けるため、新しい版へ5パーセントだけ流す運用が設定で表現できます。

比率を上げる判断は、精度そのものではなく業務指標で行います。推薦ならクリック率、不正検知なら見逃し件数と誤検知件数の両方。オフライン指標が同等でも業務指標が落ちる場合、切り戻しを優先してください。

監視する5指標｜p95・キュー待ち・GPU使用率・入力分布の偏り

推論APIで追う指標は5つに絞れます。p95レイテンシ、キューでの待ち時間、GPU使用率とメモリ使用量、エラー率、入力データの分布。平均レイテンシだけを見ていると、一部のリクエストだけが極端に遅い状態を見落とします。

GPU使用率が高くないのにキュー待ちが伸びる場合、前処理のCPU側が詰まっている可能性が高く、インスタンスを増やすより前処理を別コンテナへ分離するほうが効くでしょう。

入力データの分布は、精度劣化の早期発見のために記録します。特徴量ごとの平均や欠損率を日次で残し、学習データとの乖離が広がった時点で再学習を検討する運用です。推論そのものの速度を詰める手法はLLM推論の仕組みと高速化の手法で扱っており、GPU側の詰め方は共通して参考になります。

コールドスタートの実態と、モデル読み込み時間を縮める3つの手段

コールドスタートの正体は、コンテナの起動そのものではなくモデルファイルの読み込みです。数ギガバイトのモデルをオブジェクトストレージから取得し、メモリへ展開してGPUへ転送するまでに、条件によっては1分近くかかります。オートスケールで新しいインスタンスが立ち上がる場面でも、同じ待ち時間が発生する点に注意してください。

縮める手段は3つ。モデルをコンテナイメージへ同梱する、ノード側にキャッシュする仕組みを使う、量子化などでモデル自体を小さくする。KServeにはローカルモデルのキャッシュ機構があります。スケールアウトの判断はキューが伸びてからでは間に合わないため、閾値は余裕のある側へ倒しておいてください。

サービング基盤を自前で組む条件と、作らないと決めてよい場面の判断

ここは判断を言い切ります。自前で組む価値が出るのは限られた条件下だけで、多くの現場ではマネージドか、単一コンテナのAPIで足ります。

自前構築が成り立つ下限条件｜増える運用対象5系統の見積もり方

KServeで基盤を組む場合、増える運用対象はKServe本体だけではありません。Kubernetesクラスタ、サービスメッシュまたはゲートウェイ、オートスケールの制御層、モデル置き場のオブジェクトストレージ、監視基盤という5系統が、版上げとバックアップの対象として加わります。

この負担を引き受ける価値があるのは、次のいずれかに該当する場合に限ります。配備するモデルが十数本以上あり、型を統一しないと個別対応が回らない。GPUを常時使い切る規模の推論トラフィックがある。推論データを外部のクラウドへ送れない制約がある。オンプレミスのGPU資産が既にあり、稼働率を上げたい。どれにも当てはまらないなら、自前構築は見送るのが妥当な判断です。

基盤を作らない判断でよい2類型｜社内バッチと検証段階のモデル

1つ目の類型は、社内向けのバッチ処理です。月次や日次でまとめて推論し、結果をデータベースへ書き出す用途なら、サービング基盤は要りません。学習と同じコンテナイメージでスクリプトを回し、ジョブスケジューラの上で実行ログを残せば足ります。

2つ目は、検証段階のモデルです。利用者が数人で、応答時間の約束がなく、モデルの本数が1〜2本という段階なら、FastAPIなどでモデルを読み込む単一コンテナのAPIをコンテナ実行基盤へ載せるだけで十分に動きます。基盤へ移る合図は、モデルの本数が5本を超えたとき、あるいは配備手順が担当者ごとに違い始めたときになります。

委託時に見積書で確認する5項目｜運用の引き渡しまで含まれるか

推論基盤の構築を外部へ委託する場合、見積書では次の5点を確認します。モデル成果物の受け渡し規約（形式・置き場所・版の付け方）が決まっているか、推論APIの入出力仕様が納品対象に含まれるか、版の切り替えとロールバックの手順書があるか、監視指標とダッシュボードの構築が範囲に入るか、負荷試験と想定リクエスト数の根拠が示されているか。

この5点が抜けた見積は、モデルが動くところまでの構築費だけを見ていることが多く、公開後の運用で追加費用が発生します。データ分析基盤構築・MLOps構築支援では、学習側の基盤から推論の配備・運用設計までを含めた相談を受け付けています。委託先を選ぶ段階で、この5項目に答えられるかどうかを判断材料にしてください。

よくある質問

モデルサービングの設計でよく挙がる質問に、実装の判断基準という観点から答えます。

モデルサービングとMLOpsは何が違いますか？

MLOpsはデータ収集から学習・配備・監視・再学習までの運用サイクル全体を指し、モデルサービングはそのうち「学習済みモデルを推論として提供する」工程です。包含関係にあり、対立するものではありません。実務上の区別は担当範囲に現れます。サービングの担当者はGPUの割り当て、レイテンシ、スケール、版の切り替えを見ますが、学習データの品質や特徴量の設計には踏み込みません。組織で役割を分けるなら、境界線を推論APIのインターフェースに置いてください。

KServeとTritonはどちらを先に選ぶべきですか？

両者は同じ層の製品ではないため、比較して片方を選ぶ関係ではありません。Tritonは推論サーバ本体で、モデルを読み込んで応答するプロセスです。KServeはその推論サーバをKubernetes上へ配置し、スケールやトラフィック分割を制御する基盤にあたります。KServeがTritonを内部の実行体として呼ぶ構成が代表的な形です。Kubernetesを使わないならTritonを単体のコンテナとして動かす選択もありますし、モデルの本数が増えてからKServeを載せる順序でも問題ありません。

推論はCPUだけで足りますか？GPUは必須ですか？

モデルの規模と要求レイテンシで決まります。勾配ブースティングや小さなニューラルネットワークによる分類・回帰は、CPUで数ミリ秒から数十ミリ秒の応答が出るため、GPUを持ち出す理由がありません。GPUが必要になるのは、画像や音声の深層学習モデル、埋め込み生成の大量処理、そして大規模言語モデルです。まずCPUインスタンスで実測し、p95レイテンシが要求を満たすならそのままCPUで運用してください。GPU前提で設計を始めると、費用が1桁上がった構成から抜け出せなくなります。

モデルの旧版はいつまで残すべきですか？

成果物そのものは監査と再現性のため長期に保管し、起動中のインスタンスは新版の安定を確認できるまで残す、という二段構えが扱いやすい形です。インスタンスの保持期間は、業務指標が日次で判断できるなら1週間程度が目安になります。成果物のほうは、その版で出した推論結果に問い合わせが来たときに再現できる必要があるため、業務上の保存義務に合わせて期間を決めてください。学習データと学習コードの版も同じ場所へ紐づけておくと、再現の工数が現実的な範囲に収まります。

サーバーレスの推論サービスは本番で使えますか？

使える条件は絞られます。モデルが小さく読み込みが速いこと、リクエストの間隔が空いても最初の1件が遅れて構わないこと、常時起動のインスタンスより実稼働率が明らかに低いこと。この3つが揃うなら費用面で有利です。逆に、応答時間の約束がある外部公開のAPIや、数ギガバイト規模のモデルでは、コールドスタートの待ち時間が要求を超えるでしょう。迷う場合は、想定される最大の空白時間を挟んで実測してください。

関連記事

• MLOpsツール比較｜実験管理・パイプライン・監視の主要スタックと選定基準：学習側の基盤のツール選定
• LLMOpsとは？MLOpsとの違いとトレース・評価・コスト管理の実装を解説【2026年版】：推論を運用し続ける型
• Vertex AIとは？Google CloudのAI開発プラットフォームの機能・料金とSageMaker/Azure MLとの違いを実装者目線で解説：マネージド基盤の比較
• エッジAIとは？クラウドAIとの違い・仕組み・実装の判断基準を解説：端末側で推論する構成との使い分け