TensorRT Edge-LLMで6.4倍高速化、Jetsonでの成果を検証

クラウドからロボットや自動運転車などのエッジ機器へ、自律型AIエージェントを直接展開する動きが活発になっています。単発の質問に答えるチャットボットと異なり、エージェントはツールの呼び出しや実行結果の検証を繰り返しながら長時間の対話を維持するため、限られたエッジ環境では処理速度が大きな壁となっていました。NVIDIAが公開した検証データによると、次世代の組込みプラットフォーム「Jetson AGX Thor」上で「TensorRT Edge-LLM」を適用した構成が、従来の参照実装と比べて約6.4倍の速度でベンチマークを完了しました。本稿では、公開された性能指標をもとにその仕組みと導入時の注意点を整理します。

エッジ環境でエージェントを動かすと何がボトルネックになる？

エッジデバイス上でAIエージェントを実用化しようとする際、従来の単純なテキスト生成モデルとは異なる技術的課題に直面します。対話が1往復で完結する通常のチャットボットと異なり、エージェントは「ユーザーの要求を受け取る」「適切な外部ツールを選択して実行する」「その結果を読み込んで次の推論を行う」という一連のループを自律的に繰り返します。

この動作プロセスにおいて最大の問題となるのが、会話履歴の累積によるコンテキスト長の肥大化です。エージェントが思考を続けるにつれて過去のやり取りやツールの出力ログがすべて文脈として蓄積されるため、ターンが進むごとにモデルへ入力されるトークン数は膨大になっていきます。今回の検証対象となったワークロードでも、入力トークン数は最大約23.5Kトークンにまで達しています。

一般的なエッジ機器では、限られた電力枠とメモリ容量の中で推論を行わなければなりません。特にバッチサイズが小さい環境での大規模言語モデル（LLM）のデコーディング処理は、DRAMのメモリ帯域幅によって処理速度が強く制限されることが知られています。長大な履歴を処理するたびに全体の再計算を行ったり、メモリ帯域を浪費したりする構造のままでは、エッジ側でのリアルタイムな動作は困難になります。

MLPerf Edge Agenticベンチマークで測定された実際の数値

今回用いられた「MLPerf Inference v6.1 Edge Agentic」は、エッジ機器における自律型エージェントのエンドツーエンド性能を測定するために設計されたベンチマークです。OpenAI互換のエンドポイントに対し、性能（Performance）と精度（Accuracy）の2つのフェーズに分けて評価が行われます。

性能フェーズでは、ソフトウェアエンジニアリングに関するエージェントの実際の操作履歴（20の会話、合計1,007の生成ターン）を再生し、長文脈の処理効率やIoU（Intersection of Union）に基づくインライン精度が測定されます。一方の精度フェーズでは、業界標準の評価セット「BFCL（Berkeley Function Calling Leaderboard）v4」から995件のプロンプトを使用し、正しい関数呼び出し、適切な引数生成、不要なツール呼び出しの回避ができているかを単一ターンかつ推論機能オフで判定します。

検証は、128GBの統合メモリを搭載した1台の「NVIDIA Jetson AGX Thor Developer Kit」を最高性能のMAXN電力モードに設定し、パラメータ数270億のモデル「Qwen3.6-27B」を用いて実施されました。公開された主要な指標は以下の通りです。

NVIDIAの公式技術解説「TensorRT Edge-LLM Completes the MLPerf Edge Agentic Benchmark 6.4x Faster on Jetson AGX Thor」によると、従来のllama.cppを用いた参照構成では完了までに2時間37分を要していた全1,007ターンの処理が、TensorRT Edge-LLMでは24分36秒で終了しました。これは約6.4倍の高速化に相当し、出力スループットも毎秒52.33トークンという実用的な水準に達しています。

6.4倍の差を生んだ3つの高速化アプローチ

同じハードウェアとモデルを用いながら、ここまでの性能差を生み出した背景には、ハードウェアのアーキテクチャに最適化された3つの技術的アプローチが存在します。

第1のアプローチは、「NVFP4」量子化によるメモリ帯域幅の負荷軽減です。Jetson AGX Thorに搭載されたNVIDIA Blackwell GPUは、4ビット浮動小数点フォーマットであるNVFP4をハードウェアレベルでサポートしています。今回の構成では、言語モデルヘッドを含む重み（Weights）と活性化（Activations）にNVFP4を適用し、KVキャッシュにはFP8を採用しています。モデルのフットプリントを大幅に縮小することで、エッジ推論の大きな制約であるDRAM帯域のボトルネックを緩和し、128GBの統合メモリにより多くの長大な文脈や推測デコード用データを保持できる余力を生み出しています。

第2のアプローチは、「ツリー探索型マルチトークン予測（Tree-based MTP）」の導入です。通常の自己回帰型モデルは1回の推論ステップで1つのトークンを生成しますが、マルチトークン予測（MTP）ではドラフトモデルが複数の未来トークンを事前予測し、ターゲットモデルがそれを一括検証します。TensorRT Edge-LLMでは、単一の予測候補を直線的に並べる従来の線形MTPにとどまらず、高確率な候補をツリー構造に展開して検証する手法を実装しています。

ツリー構造により、ツールの名称やJSON構文といった規則的な構造を捉えつつ、引数のバリエーションを複数の分岐として保持できます。今回の設定ではドラフト深さ8ステップ、各深さの上位2候補からなる16ノードのツリーを構成し、1回のフォワードパスで並列検証を行っています。この手法により、3ステップの線形MTPと比較しても、デコーディング性能がさらに約40%向上したと報告されています。

第3のアプローチは、ターン間での「KVキャッシュと再帰状態の再利用」です。エージェントの対話では、新しい要求が送られてきても、その大半は直前までの会話履歴と過去のツール実行結果で占められています。キャッシュを再利用しないシステムでは、ターンごとに蓄積された履歴全体を最初から計算し直す（プリフィルする）必要があり、コンテキストが伸びるほど処理時間が跳ね上がります。

TensorRT Edge-LLMは、再利用可能なプロンプトの接頭辞を検出し、保持されていたKVページを即座に復元します。Qwen3.6はハイブリッドアーキテクチャを採用しているため、通常のKVキャッシュだけでなく、再帰状態（Recurrent State）や部分的なKVページ状態も合わせて復元することで、新規に追加された末尾部分のみをプリフィルします。この最適化により、ワークロード全体（合計約1,360万トークン）のうち約96%のプロンプトトークンがキャッシュから処理され、実際にプリフィル計算が行われたのは約50万トークンにとどまりました。

llama.cpp参照実装との比較で見える条件の違い

ベンチマーク結果を評価する際には、比較対象となった環境の前提条件を客観的に把握しておく必要があります。

今回の比較相手であるllama.cppのリファレンス実装も、ハードウェアとしては同一のJetson AGX Thor上で稼働しています。ただし、モデルの量子化形式には広く普及している「Q4_K_M」が用いられており、推測デコーディングや大規模なキャッシュ再利用の仕組みは今回のTensorRT Edge-LLMほど高度に統合されていませんでした。

TensorRT Edge-LLMが達成した6.4倍という高速化は、単に計算チップの基本性能によるものではなく、Blackwellアーキテクチャの専用命令を活かしたNVFP4、ツリー探索による投機的デコード、そしてエージェント特有の長大な会話履歴をスキップするキャッシュ制御という、複数のソフトウェア最適化が噛み合った結果といえます。

一方で、今回の検証は「MAXN」と呼ばれる最大電力モードで実施されており、消費電力や発熱に対する制約が比較的緩やかな環境下での測定値であることには留意が必要です。車載や小型ロボットなど、消費電力や排熱に厳しい上限が課される実際の組込み製品へそのまま当てはまるわけではありません。

検証環境を再現するための公開リポジトリと手順

今回のMLPerf提出構成は、公開されているリポジトリやモデルチェックポイントを用いて開発環境上で再現できるよう構成されています。公式資料に記載されている主なセットアップ手順は次の5段階です。

なお、今回の公式ベンチマーク設定では、温度パラメータ（temperature）は0、乱数シードは42、推論機能（reasoning）は無効、同時実行数（concurrency）は1という厳密に固定された条件で実行されています。BFCL精度フェーズのみを個別に測定するためのオプション（–accuracy-only）も用意されています。

エッジAIへの導入を今進めるか見送るかの判断材料

今回示された成果は、これまでクラウドへの通信が不可欠とされていた長文脈の自律型エージェントを、エッジ側で完結して動かせる可能性を明確に示しています。しかし、すべての開発プロジェクトが直ちにこの構成へ移行すべきかというと、いくつかの前提条件が存在します。

まず、早期に検証を進める価値が高いのは、次世代の組込みハードウェア（NVIDIA BlackwellアーキテクチャやJetson AGX Thorなど）の採用を前提とし、オフライン環境下での自律的なロボット制御や高度な車載支援システムを開発している現場です。ツール呼び出しの回数が多く、対話ターンが数十回に及ぶユースケースでは、KVキャッシュ再利用とツリー型MTPの恩恵が最大限に発揮されます。

一方で、現在主流である前世代のJetson Orinシリーズや、他社のエッジアクセラレータでの運用を継続するシステムの場合、直ちに見送るか慎重な姿勢をとるのが合理的です。NVFP4の演算支援や大容量の統合メモリが存在しない環境では、同様の高速化倍率を得ることは難しいためです。

また、今回の精度評価は「推論機能オフ（reasoning disabled）」のシングルターンで行われている点も押さえておく必要があります。近年のモデルに見られる深い思考プロセスを常時有効化して動作させる場合、エッジ側でのレイテンシや消費リソースは今回の数値と大きく異なってくる可能性があります。

次のステップとしては、公開された「release/0.9.1-mlpinf」ブランチとMLCommonsのハーネスを参照し、自社で想定しているツールの引数仕様や関数の複雑さが、この実行環境でどの程度の精度と応答性を維持できるか、公式の構成ファイルをもとに部分的な適合テストを実施することが推奨されます。