In Silico

推論

Triton複数GPU推論の設定：インスタンス複製とmulti-deviceの違い

2026/10/16

🤖 AIを使用して執筆

  • Triton
  • GPU
  • 推論サーバー
  • Dynamo-Triton
  • TensorRT
  • KIND_MODEL
  • KIND_GPU
  • instance_group
  • multi-device
  • NCCL
  • Cosmos 3 Nano
  • アムダールの法則
  • Ulysses
  • ランク
  • 集合通信
  • モデルインスタンス
  • レイテンシ
  • コンテキスト並列
  • gRPC
  • MPI
  • TensorRT-LLM
  • xDiT
  • Diffusers
  • config.pbtxt
  • B200
目次
背景・問い・要点
背景

動画生成のように、系列（モデルが一度に扱うトークンの並び）の長い生成モデルを、推論サーバーで動かすエンジニアを考える。推論サーバーは、学習済みのモデルを読み込み、アプリケーションから届く要求に推論の結果を返すサーバーである。一回の要求を一台の GPU で計算すると、結果が返るまでの時間（レイテンシ）が長い。そこでエンジニアは、同じ一回の要求を複数の GPU に分けて計算し、レイテンシを縮めたい。ただし、アプリケーションからは、これまでどおり一つのモデルを一回呼ぶ形のままにしたい。

Triton（Triton Inference Server、現在の名称は Dynamo-Triton）は NVIDIA が作る推論サーバーで、リポジトリは 2018 年に作られた1。Triton で複数の GPU を使うときの通常の設定は、モデルインスタンスの複製である。モデルインスタンスは、Triton がモデルを読み込んで推論を実行する単位である。複製の設定では、GPU ごとにモデルインスタンスを一つ置き、複数の要求を同時に処理する2。各モデルインスタンスは一つの要求を一台の GPU で計算するので、同時に処理できる要求の数は増えるが、一つの要求のレイテンシは縮まない。

一つの要求を複数の GPU に分けて計算すると、GPU どうしが計算の途中で結果を交換する。この交換は、全部の GPU が同じ時点で加わって初めて進む。そのため通常は、アプリケーションのコードが GPU 間の通信路を準備し、全部の GPU の実行を同時に呼ぶ3。Dynamo-Triton の 26.07 版は、この準備と呼び出しを Triton の側で行う multi-device という設定を加えた4。この設定は TensorRT バックエンドで使える。TensorRT は NVIDIA の推論ライブラリで、バックエンドは Triton がモデルを実行するために呼ぶ部品である。

問い

Triton で複数の GPU を使うとき、インスタンスを複製する設定と multi-device の設定では、一つの要求の速さはどう違うのか。

要点

インスタンスの複製は同時に処理する要求の数を増やし、multi-device の設定は一つの要求を複数の GPU で分けて速くするが、その速さは GPU の台数に比例しない。 multi-device では一つのモデルインスタンスが全部の GPU を同時に呼ぶので、アプリケーションは一つのモデル名を呼ぶだけでよい4。NVIDIA の動画生成の測定では、GPU を 8 台にすると、サーバーを呼んでいる時間は 6.09 倍に縮んだが、サーバーの外で動く約 10 秒の処理は縮まず、一回の生成の時間は 4.58 倍の短縮にとどまった4。NVIDIA の TensorRT バックエンドのガイドの測定では、アテンションの層が一つだけのモデルを GPU 2 台で動かすと、速さは約 1 倍だった5。

モデル・例示

二つの GPU で、複製は二つの要求を同時に進め、multi-device は一つの要求を二つのランクで進める

二つの GPU（GPU0 と GPU1）を持つサーバーで、二つの要求 A と B を処理する。インスタンスを複製する設定では、要求ごとに GPU を一台使う。各 GPU には同じモデルの複製が一つずつ載る。

  1. アプリTriton サーバー1. 要求 A を送る
  2. アプリTriton サーバー2. 要求 B を A と同時に送る
  3. Triton サーバーGPU03. 要求 A を GPU0 の複製に回す
  4. Triton サーバーGPU14. 要求 B を GPU1 の複製に回す
  5. GPU05. 要求 A を GPU 一台で計算する
  6. GPU16. 要求 B を GPU 一台で計算する
  7. GPU0Triton サーバー7. 要求 A の出力を返す
  8. GPU1Triton サーバー8. 要求 B の出力を返す
※概念図（やりとり）：本文の手順を図式化したもの。

要求 A も B も一台の GPU で計算するので、各要求のレイテンシは GPU を一台使うときとほぼ同じと考えられる。複製で増えるのは同時に進む要求の数で、この例では二つになる。

multi-device の設定では、一つのモデルインスタンスが二つの GPU を使い、一つの要求を二つに分けて計算する。計算に加わる GPU の一つひとつをランクと呼ぶ。ランクどうしが途中結果を交換する通信を、集合通信と呼ぶ。集合通信は全ランクが同時に加わって初めて進むので、モデルインスタンスは全ランクの実行を同じ時点で呼ぶ。

  1. Triton のモデルインスタンス1. 読み込み時に、ランクごとの実行の準備と、ランクどうしの通信路を作る
  2. アプリTriton のモデルインスタンス2. モデル名を指定して一つの要求を gRPC で送る
  3. Triton のモデルインスタンスGPU ランク03. 入力を渡し、実行を呼ぶ
  4. Triton のモデルインスタンスGPU ランク14. 同じ入力を複製して渡し、同じ時点で実行を呼ぶ
  5. GPU ランク05. 集合通信で途中結果をランク1とやり取りしながら、入力の一部を計算する
  6. GPU ランク16. 同じ集合通信に加わり、入力の別の一部を計算する
  7. GPU ランク0Triton のモデルインスタンス7. ランク0の出力を返す
  8. Triton のモデルインスタンスアプリ8. その出力を返す
※概念図（やりとり）：本文の手順を図式化したもの。

アプリケーションが呼ぶのは一つのモデルで、二つのランクを同時に呼ぶのはモデルインスタンスである。一つの要求を二つのランクで分けるので、計算の時間は短くなりうる。ただし、入力を複製する時間と、集合通信でランクどうしが待ち合わせる時間が、計算の量によらず要求のたびに加わる。以下、この時間を要求ごとの固定時間と呼ぶ。

速さが台数に比例しない理由は、一つの足し算で示せる。一回の生成の時間は、アプリケーションがサーバーを呼んでから結果が返るまでの時間（RPC の時間）と、サーバーの外でアプリケーションが動かす処理の時間の和である。NVIDIA の動画生成の測定では、GPU 一台のとき、全体が 156.595 秒、RPC の時間が 146.192 秒で、外の時間は約 10.4 秒だった4。仮に八台で RPC の時間がちょうど 8 分の 1 になったとすると、全体は 10.4 + 146.192 ÷ 8 ≈ 10.4 + 18.3 = 28.7 秒で、速さは 156.595 ÷ 28.7 ≈ 5.46 倍になる。台数で縮むのは RPC の時間だけで、外の約 10 秒は縮まないので、全体は 8 倍に届かない。全体のうち並列にできない部分の時間が全体の速さの上限を決めるこの関係を、アムダールの法則と呼ぶ。

同じ足し算から、外の時間や要求ごとの固定時間が RPC の計算に比べて大きいモデルほど、全体の速さは 1 倍に近づくと言える。実測では、八台での全体の速さは 4.58 倍で、5.46 倍よりさらに小さかった。RPC の時間そのものも 8 倍に届かず、6.09 倍までしか縮まなかったためである。RPC の時間が縮みきらない原因は、要求ごとの固定時間である。

multi-device では、全部の GPU を同時に呼ぶ処理をモデルインスタンスが行う

multi-device の設定では、GPU 間の通信路の準備と、全ランクの実行の同時の呼び出しを、Triton の一つのモデルインスタンスが行う。アプリケーションは gRPC で一つのモデル名を呼ぶだけで、ランクの起動と通信路の管理はアプリケーションのコードに入らない4。

この設定が無いと、アプリケーションが TensorRT の手順どおりに三つの処理を書く。NCCL（NVIDIA の GPU 間の集合通信ライブラリ）の通信路を初期化し、その通信路を各ランクに設定し、全ランクの実行を同時に呼ぶ。TensorRT の文書は「いずれかのランクが実行の呼び出しを出さなければ、ほかのランクは無期限に待つ」と警告する3。multi-device では、モデルインスタンスがこの三つを行う。読み込み時には、通信路を各ランクに結び付ける呼び出しを全ランクで同時に行う。この呼び出しでは各ランクがほかのランクの応答を待つので、一つずつ順に呼ぶと処理が止まる。要求のたびには、ランク 0 の入力を全ランクに複製し、全ランクの実行を同時に呼び、ランク 0 の出力を返す5。

ほかの道具は、GPU ごとにプロセスを立ててこの処理を行う。Triton の TensorRT-LLM バックエンドは、GPU ごとに Triton のプロセスを立て、MPI（プロセス間通信の標準規格）でそれらを連携させる6。xDiT は、拡散トランスフォーマー（DiT）を複数の GPU で推論するエンジンで、系列並列の論文 USP の著者らが 2024 年に GitHub で公開した。xDiT は torchrun で GPU ごとにプロセスを起動する7。拡散モデルのライブラリ Diffusers も、トランスフォーマーの計算を系列の方向で複数の GPU に分ける設定（ContextParallelConfig）を持ち、torchrun で GPU ごとにプロセスを起動する8。multi-device の設定では、プロセスは一つのまま、一つのモデルインスタンスが複数の GPU を持つ。

設定は、Triton のモデルごとの設定ファイル config.pbtxt に三つの項目を書く。instance_group の kind は、インスタンスをどこで動かすかの指定である。KIND_GPU は GPU ごとにインスタンスを置く2。KIND_MODEL は、インスタンスをどの CPU や GPU で動かすかをモデルやバックエンド自身の指定に任せ、Triton はその指定を上書きしない9。instance_group で KIND_MODEL のインスタンスを一つ置き、enable_multi_device を “true” にし、使う GPU を multi_device_gpus に並べる4。NVIDIA が示す抜粋は次のとおりである。

name: "cosmos3_cp8"
backend: "tensorrt"
max_batch_size: 0
instance_group [
  { kind: KIND_MODEL count: 1 }
]
parameters [
  { key: "enable_multi_device" value: { string_value: "true" } },
  { key: "multi_device_gpus" value: { string_value: "0,1,2,3,4,5,6,7" } }
]

複製の設定では KIND_GPU を使い、既定ではシステムの GPU ごとにインスタンスが一つ作られる2。multi-device を加えても、この KIND_GPU の経路は変わらず、既定のままである5。multi-device を使うには、複数の GPU に分けたモデルを、配備の前に TensorRT のエンジン（TensorRT がモデルを GPU 向けにコンパイルしたもの）にしておく。この設定が単一 GPU 用のエンジンを複数 GPU 用に変換するわけではない4。

速さが台数に比例しないのは、要求ごとの固定時間とサーバーの外の時間が縮まないからである

要求ごとの固定時間とサーバーの外の処理の時間は、GPU を増やしても縮まない。そのため速さは台数に比例せず、層の少ないモデルではほとんど速くならない。

NVIDIA の測定条件は次のとおりである。動画生成モデル Cosmos 3 Nano で、1280×720、189 フレーム、35 ステップの動画を作り、5 回の平均を取った。サーバーに置いたのは、ノイズを予測するトランスフォーマーだけである。プロンプトの処理、スケジューラの更新、動画への復号は、アプリケーションの側で Diffusers が動かした。アプリケーションは一ステップでサーバーを二回呼ぶので、一回の生成で呼び出しは 70 回ある。トランスフォーマーの計算は Ulysses のコンテキスト並列で GPU に分けた。アテンションの計算では、各ランクが全系列を、重ならない一部のヘッドについて処理する4。Ulysses は、系列の次元でデータを GPU に分け、アテンションの計算で all-to-all の集合通信を使う方法で、Jacobs らが長い系列を扱うトランスフォーマーの学習向けに提案した10。

この条件で、8 台では RPC の時間が 6.09 倍、全体の時間が 4.58 倍に縮んだ。RPC の外の時間は、台数を増やしても 10.2 秒から 10.5 秒のままだった。全体に占める RPC の時間の割合は、1 台の 93.4% から 8 台の 70.2% に下がった。NVIDIA の表の全体の倍率を台数で割ると、2 台で 0.89、4 台で 0.74、8 台で 0.57 となり、台数を増やすほど一台あたりの効果は下がる4。外の時間は、Diffusers の側で別に縮めない限り、台数では縮まない。

RPC の時間が台数ほど縮まない原因は、要求ごとの固定時間である。NVIDIA のガイドの測定では、NVIDIA の GPU である B200 を二台使い、単層のアテンションを batch 1 で動かすと、速さは約 0.92 倍から 1.21 倍で、差は測定のばらつき（±10%）に埋もれた。ガイドは原因を、入力の複製、集合通信の起動、カーネルの起動という要求ごとの固定時間とする。系列長 32,768 のアテンションを 6 層重ねた場合は、平均で約 1.1 倍だった。ガイドは、層が数十あり batch が大きいトランスフォーマーでは 2 倍に近づくと予想するが、この 2 倍は予想であって測定ではない5。同じ GPU 二台で、NVIDIA の 36 層のトランスフォーマーでは RPC の時間が 1.89 倍に縮んだ4。二つの測定はハードウェア、系列長、エンジンの作り方が違うので、差のうち層の深さによる分は切り分けられない。それでも、層が深いほど要求ごとの固定時間の割合が下がるというガイドの見通しとは矛盾しない。

現行の実装には、要求ごとの固定時間を増やす制約がある。たとえば、入力の複製は既定でホストのメモリを経由する5。NVIDIA の動画生成では呼び出しが一回の生成で 70 回あるので、要求ごとの固定時間も 70 回掛かる4。

台数を増やせる上限もある。Ulysses ではランクごとにヘッドを分けるので、分割数はアテンションのヘッド数を超えられない。USP の論文は、Llama3-8B（キーと値のヘッドが 8 個）では上限が 8 で、キーと値のヘッドが一つのモデル（MQA）では Ulysses を使えないと書く11。Cosmos 3 Nano のモデルカードの設定では、アテンションのヘッドが 32 個、キーと値のヘッドが 8 個である12。USP の数え方をこのモデルに当てると、NVIDIA が測った 8 台は上限にちょうど当たる。USP の論文は、Ulysses を Ring-Attention という別の分け方と組み合わせれば、この上限を外せるとする11。

代償は、一つの要求が複数の GPU を占有し、重みを複製し、出力が一致しないことである

multi-device の代償は、一つの要求が複数の GPU を占有すること、既定では重みを各 GPU に複製すること、出力が単一 GPU の出力と画素単位では一致しないことである。NVIDIA は、この設定を、一つの要求に割り当てる GPU を増やして待ち時間を縮める引き換えだと書く4。二つの GPU を持つサーバーでいえば、複製の設定では二つの要求が同時に進むが、multi-device の設定では二台が一つの要求に使われる。割り当てる GPU は設定ファイルで決まり、要求ごとには変えられない。

既定の設定では全ランクが同じエンジンを読み込むので、モデルの重みは各 GPU に一組ずつ複製される。重みを GPU ごとに分けて持たせるには、ランクごとのエンジンを用意し、multi_device_per_rank_engines を “true” にする5。

出力は、単一 GPU の結果と画素単位では一致しない。同じ乱数のシードで比べた八台の出力は、平均絶対誤差（MAE）16.316、ピーク信号対雑音比（PSNR）19.400 dB で（MAE は小さいほど、PSNR は大きいほど単一 GPU の出力に近い）、NVIDIA が置いた閾値（MAE 25 以下、PSNR 18 dB 以上）を満たす。NVIDIA は、画素単位の一致を主張していない4。

NVIDIA の測定は、同時に処理する要求の数を変えたときのスループット、生成一本あたりのコスト、総保有コスト（TCO）を測っていない。NVIDIA は、GPU 資源と待ち時間の引き換えを、各チームが自分のサービス水準と費用で判断するよう書く4。複製と multi-device を組み合わせたときの測定も、ここで引いた資料には無い。

出典12件

  1. triton-inference-server/server（2026-10-15 取得）. https://github.com/triton-inference-server/server — 2018 年に作成、スター 11,087（2026-10-15 UTC）。旧称 Triton Inference Server。 ↩

  2. Triton Inference Server「Model Configuration」Instance Groups（2026-10-15 取得）. https://github.com/triton-inference-server/server/blob/main/docs/user_guide/model_configuration.md — KIND_GPU でインスタンスを複製し、複数の要求を同時に処理する。 ↩ ↩2 ↩3

  3. NVIDIA「Multi-Device Inference」TensorRT documentation（2026-10-15 取得）. https://docs.nvidia.com/deeplearning/tensorrt/latest/inference-library/multi-device-inference.html — アプリが全ランクを同時に呼ぶ手順と、呼ばないランクがあると待ち続ける警告。 ↩ ↩2

  4. Chu ほか「Simplifying Model Serving Across Multiple GPUs with NVIDIA TensorRT Multi-Device Integration in NVIDIA Dynamo-Triton」NVIDIA Technical Blog, 2026. https://developer.nvidia.com/blog/simplifying-model-serving-across-multiple-gpus-with-nvidia-tensorrt-multi-device-integration-in-nvidia-dynamo-triton/ — 設定と測定。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14

  5. NVIDIA「TensorRT Multi-Device (multi-GPU) support」Triton TensorRT backend ガイド（2026-10-15 取得）. https://docs.nvidia.com/deeplearning/triton-inference-server/archives/triton-inference-server-2710/user-guide/docs/tensorrt_backend/docs/multi_device.html — 単層では約 1 倍にとどまる測定と、読み込み時・推論時の動作。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  6. triton-inference-server「tensorrtllm_backend」README（2026-10-15 取得）. https://github.com/triton-inference-server/tensorrtllm_backend — MPI で束ねる Leader モードと Orchestrator モード。スター 945（2026-10-15 UTC）。 ↩

  7. xDiT README（2026-10-15 取得）. https://github.com/xdit-project/xDiT — 複数 GPU 配備が必要という作り手の記述。torchrun で GPU ごとにプロセスを起動。スター 2,738（2026-10-15 UTC）。 ↩

  8. Hugging Face「Distributed inference」Diffusers documentation（2026-10-16 取得）. https://huggingface.co/docs/diffusers/main/en/training/distributed_inference — ContextParallelConfig の ulysses_degree と ring_degree、torchrun での起動。 ↩

  9. Triton Inference Server「model_config.proto」Kind::KIND_MODEL（2026-10-16 取得）. https://github.com/triton-inference-server/common/blob/main/protobuf/model_config.proto — KIND_MODEL のインスタンスは、モデルやバックエンド自身が指定した CPU／GPU で動き、Triton はその指定を上書きしないこと。 ↩

  10. Jacobs ほか「DeepSpeed Ulysses: System Optimizations for Enabling Training of Extreme Long Sequence Transformer Models」arXiv:2309.14509, 2023. https://arxiv.org/abs/2309.14509 — 系列分割の仕組み。 ↩

  11. Jiarui Fang, Shangchun Zhao「USP: A Unified Sequence Parallelism Approach for Long Context Generative AI」arXiv:2405.07719, 2024. https://arxiv.org/abs/2405.07719 — Ulysses の分割数はヘッド数以下という上限。 ↩ ↩2

  12. NVIDIA「Cosmos3-Nano」Hugging Face, transformer/config.json（2026-10-16 取得）. https://huggingface.co/nvidia/Cosmos3-Nano/blob/main/transformer/config.json — 36 層、アテンションのヘッド 32、キーと値のヘッド 8。 ↩

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。