NVIDIA、エッジでの推論・エージェントAI最適化手法をJetsonで公開

エッジでの推論やエージェント型 AI の運用は、これまで必要以上に困難でした。最近まで、多段階の推論が可能なモデルは大きすぎて、エッジハードウェア上でローカル実行できませんでした。エージェントを開発する開発者は、推論をデータセンター経由でルーティングする必要があり、ネットワーク依存が生じ、コストが増加し、デバイス上に留める必要があるデータの露出というリスクも生じていました。

その制約が解消されつつあります。今夏にリリースされた複数のモデルファミリーが、エッジ AI にとっての転換点を示しました。この新しい世代のコンパクトなオープンモデルは、数ヶ月前まで大規模なデータセンターシステムを必要としていた推論やエージェント機能を達成可能にし、NVIDIA Jetson で今日すぐに実行できます。

これにより、車内アシスタント、リアルタイム異常検知、過酷または遠隔環境で動作するロボットへの応用が可能になります。現場の専門家はトラブルシューティングに費やす時間を減らし、接続が制限されている場合や利用できない場合でも、重要なシステムを稼働し続けることができます。

本稿では、Nemotron 3.5 Lightning と Qwen3.8-27B を例に、この新しい世代のオープンモデルを Jetson でデプロイするために知っておくべき内容を解説します。モデルアーキテクチャを比較する際のポイントや、ハードウェア性能を引き出すための推論最適化手法、ワークロードに応じた設定の有効性検証方法について学びます。

具体的には、以下の開発者向け質問に回答します:

• Jetson 用の推論モデルはどのように選定すべきか？

NVFP4 の量子化と推測デコーディングは、どのようにして推論パフォーマンスを向上させるのでしょうか？

vLLM を用いて Nemotron 3.5 Lightning と Qwen3.8-27B をどうサービス化するのか。

アプリケーションの設定を検証するにはどうすればよいでしょうか。

以下の図 1 は、この変化を示しています。これはモデルサイズとリリース日別に Artificial Analysis Intelligence Index（人工知能インテリジェンス指数）をプロットしたものです。2026 年に公開されたオープンソースモデルは、2025 年の最上位モデルと同等のスコアに達しつつも、必要なパラメータ数は格段に少なくなっています。

Jetson で推論モデルを選ぶには？

より優れたトレーニング手法や効率的なアーキテクチャがこの変化を牽引しています。例えば、蒸留（distillation）技術を用いることで、Nemotron 3 Ultra の一部の機能を小型の Nemotron 3.5 Lightning モデルへ転送することが可能です。また、異なるアーキテクチャを採用することで、機能性、メモリ使用量、生成速度の間でそれぞれ異なるトレードオフが生じます。

Qwen3.8-27B は密度の高いモデルであり、トークンごとに全 270 億パラメータを活性化します。一方、Nemotron 3.5 Lightning は混合专家（MoE）アーキテクチャを採用しており、総パラメータ数は 300 億に達しますが、1 トークンあたりの活性化数はわずか 30 億です。この違いにより、両モデルは異なるワークロードに適しています。

これらの違いは、長時間稼働するエージェントにおいて特に重要になります。例えば、エージェントは生センサーデータやデバイスログを監視し、承認された是正措置を実行し、結果を事前に定義されたテストと比較して検証します。そして必要な場合にのみ専門家にエスカレーションします。これら一連の処理はすべてローカルでエッジ上で完結するため、インターネット接続が不要となり、レイテンシも低く抑えられます。

応答頻度の高いワークロードには Nemotron 3.5 Lightning が適しており、トークン生成速度を高めることで全体の処理時間を短縮できます。一方、Qwen3.8-27B は、意思決定の回数が少なく、かつ難易度が高いタスクや、各応答に時間をかけて生成できるタスクに適しています。

いずれかを選択する前に、アプリケーションが必要とする意思決定、ツール、および応答パターンに基づいて両モデルをベンチマークしてください。

Jetson 上では、これらのエージェントループは、動作対象となるセンサーやシステムと隣接して実行できます。vLLM や llama.cpp といった人気のあるフレームワークを通じてローカルにモデルを展開できるため、推論ループがデータセンターへの依存を完全に解消できます。

Jetson Orin Nano では Gemma 4 E4B が堅牢な選択肢です。一方、Jetson AGX Orin や Jetson AGX Thor を使う場合は、Nemotron 3.5 Lightning と Qwen3.8-27B が有力な候補となります。これらのモデルファミリーは、主要な推論エンジンに対応した高品質な量子化チェックポイントと、最適化されたデプロイオプションを備えています。

Jetson で推論性能を高めるには？

推論パフォーマンスを向上させるために、2 つの補完的な手法が有効です。1 つは NVFP4 量子化で、モデル演算に必要な計算量とメモリ使用量を削減します。もう 1 つはスペキュレティブ・デコーディング（speculative decoding）で、検証ステップごとに複数のトークンを同時に生成し、受け入れられる数を増やします。

モデルアーキテクチャが基礎となるものの、サービングの選択も性能に大きく影響します。以下の図 2 では、各モデルについて BF16、NVFP4、そしてそれぞれのモデルで最も高速なスペキュレティブ・デコーディング構成を適用した場合の推論速度を比較しています。

図2に示すように、最適化を一つずつ追加しています。BF16がベースラインとなります。NVFP4は量子化（quantization）を追加した構成です。最終的な設定では、各モデルに対してテストした中で最も高速な推論加速手法であるスペキュレーティブ・ディコーディング（speculative decoding）を NVFP4 と組み合わせています。

デコーディング中、モデルはトークンを一つずつ生成します。通常、各トークンごとにモデルへの再処理が必要となります。このため、パフォーマンス向上には二つのアプローチがあります。一つは各パスでの計算量を減らすこと、もう一つは各パスでより多くのトークンを生成することです。

量子化は前者のアプローチを採用しています。低精度の値を使用することで、GPU が各パスで移動・処理するデータ量を削減できます。NVFP4 などのフォーマットを用いれば、品質を BF16 に近い水準に保ちながら、生成速度の向上とメモリ使用量の削減を実現できます。

スペキュレーティブ・ディコーディングは後者のアプローチです。小さなドラフトモデルが複数のトークンを提案し、メインモデルがそれらをまとめて検証します。最終的な決定権は依然としてメインモデルにあります。もしメインモデルが提案された複数のトークンを受け入れれば、一つの検証ステップで生成が進むトークン数が増加します。

以下のビデオ1では、スペキュレーティブ・ディコーディングありとなしの両方で応答を生成する様子を示し、その速度向上効果を視覚的に解説しています。

*Video 1. NVIDIA Jetson 上での Qwen3.5 9B NVFP4 推論における、スペキュレーティブ・ディコーディングの有無による比較*

これらのドラフト生成には、MTP、DFlash、DSpark などの手法が利用可能です。これら 3 つはすべて Jetson 上で動作しますが、提案の生成と評価方法に違いがあります。特定のモデルで最も性能を発揮する構成を事前に想定するのではなく、実際に利用可能な手法やドラフトチェックポイントを試して検証しました。

2 つの最適化手法は互いに補完し合います。NVFP4 は各パスのコストを削減し、スペキュレーティブ・ディコーディング（speculative decoding）は各パスから受け入れられるトークンの数を増やします。この 2 つを組み合わせることで、単独で使用するよりも大幅なパフォーマンス向上が期待できます。

最も高速なスペキュレーティブ・ディコーディング構成はモデルによって異なります。Nemotron 3.5 Lightning では DSpark が、Qwen3.8-27B では DFlash2 がそれぞれ最高の性能を発揮しました。すべてのモデルで同じ構成が最適とは限らないため、実際にデプロイするモデルに合わせて手法とドラフトチェックポイントの組み合わせをテストしてください。

事前準備

以下のコマンドを実行する前に、必ず以下の条件を満たしていることを確認してください。

• Jetson AGX Thor または Jetson AGX Orin のいずれか
• NVIDIA Container Runtime と Docker が設定された JetPack 7.2
• モデルとドラフトチェックポイント用の十分なストレージ容量
• NVIDIA Nemotron および Qwen3.8 チェックポイントの利用許諾条件への同意

Nemotron 3.5 Lightning の場合、Jetson AGX Thor または Jetson AGX Orin で、NVFP4 と DSpark を組み合わせた最も高速な構成（テスト済み）を実行できます。

まず、vllm/vllm-openai:v0.28.0 コンテナを起動します：

docker run --pull=always --runtime nvidia --rm -it \

--network host \

--ipc=host \ （原文の技術表記: --ipc=host \`）

コンテナ内で以下のコマンドを実行します。

vllm serve nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4 \
  --reasoning-parser nemotron_v3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --max-model-len 128000
``` （原文の技術表記: ` `、` `、` `）

--kv-cache-dtype fp8 \

--gpu-memory-utilization 0.7 \

--trust-remote-code \

--max-num-batched-tokens 16384 \

--enable-prefix-caching \

--speculative-config '{"method":"dspark","model":"nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4-DSpark","num_speculative_tokens":5}' \

--mamba-backend flashinfer

` （原文の技術表記: ）

--mamba-ssm-cache-dtype float16 \

--enable-mamba-cache-stochastic-rounding \

--mamba-cache-philox-rounds 5 \

--mamba-cache-mode align

Qwen3.8-27B の場合、上記のコマンドで起動した同じコンテナを使用し、Jetson AGX Thor または Jetson AGX Orin で最も高速な構成（NVFP4 と DFlash2 を組み合わせたもの）を実行できます。以下のコマンドで実行してください。

VLLM_GDN_DECODE_KERNEL=triton vllm serve Inferact/Qwen3.8-27B-NVFP4 \
  --served-model-name qwen38 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --max-model-len 50000 \
  --max-num-seqs 8 \
  --gpu-memory-utilization 0.85

各手法はドラフトトークンの生成・評価方法が異なり、提案のコストや精度に影響を与えます。

MTP（Multi-Token Prediction）は、メインモデルと併せて訓練された予測ヘッドを用いて複数の未来トークンを提案します。現在では Qwen、Gemma、Nemotron など主要なモデルファミリーで MTP を利用可能です。

DFlash は、拡散ベースの別ドラフトモデルを用いてトークンのブロックを並列に提案します。現在、最も幅広い互換性のあるドラフトチェックポイントに対応しています。DSpark は DFlash を基盤とし、ドラフトの補正や弱すぎる提案の早期停止を実現します。対応するチェックポイントが存在すれば DSpark の方が高速化できますが、対応可能なチェックポイント数は DFlash よりも限定的です。

代表的なワークロードで性能を検証する

モデルレベルのベンチマークは、強力な推測デコーディング構成を特定するのに役立ちます。ただし、アプリケーションごとに生成されるテキストの種類は異なり、ワークロードによってパフォーマンスが変動します。この影響を測定するため、各モデルに対して最速の構成を固定し、SpeedBench の 4 つのカテゴリ（ライティング、推論、要約、検索拡張生成）でテストを行いました。

--trust-remote-code

--speculative-config '{"method":"dflash","model":"incoai/Qwen3.8-27B-DFlash2","num_speculative_tokens":7}'

テストしたカテゴリ全体で同じ手法が最速でしたが、スループットにばらつきは見られました。DSpark を採用した Nemotron 3.5 Lightning は出力トークンあたり 123.01〜138.02 トークン/秒、DFlash2 を採用した Qwen3.8-27B は 27.69〜34.44 トークン/秒の範囲でした。

推論型デコードの設定は、実際のアプリケーションを想定したプロンプトで検証してください。代表的なデータセットを用意すれば、モデルとユースケースに最適な手法やチェックポイントを選定する際の参考になります。

カスタムチェックポイントを学習すべきタイミングは？

ほとんどの用途では、既存の量子化済みチェックポイントとドラフトモデルから始めるのがおすすめです。これだけで十分な精度と実用的な高速化が得られるケースがほとんどです。デプロイ前に自社のアプリケーション由来のプロンプトでテストを行いましょう。一般的なベンチマークだけでは、あなたのデータにおいて重要な振る舞いをチェックポイントが保持できているかどうかは判断できません。

量子化によって精度が低下する場合は、NVIDIA Model Optimizer を使用して、量子化認識トレーニング（Quantization-Aware Training）や蒸留（Distillation）を通じて量子化モデルを微調整します。量子化認識トレーニングでは、学習中に低精度の挙動をシミュレーションします。また、量子化認識蒸留でも、高精度な教師モデルを用いて、量子化モデルが元のモデルの動作特性を維持できるように支援します。

この追加チューニングは、わずかな精度の変化が重要となる特殊なワークロードにおいて特に有効です。どちらのアプローチで量子化モデルをトレーニングするかについては、NVIDIA Model Optimizer の QAT および QAD チュートリアルをご覧ください。

このアプローチは、推測的デコーディング（Speculative Decoding）にも同様に適用できます。公開されているドラフトチェックポイントがモデルと互換性を持っていても、期待通りの加速効果を得られない場合があります。速度向上の度合いは、メインモデルが提案されたトークンをどの程度受け入れるかにかかっています。受け入れ率が低い場合、ドラフトの生成と検証にかかるコストがメリットを相殺してしまう可能性があります。そのような場合は、vLLM Speculators のトレーニングガイドに従って、代表的なアプリケーションデータを用いて互換性のあるスペキュレーターをトレーニングしてください。Speculators は MTP、EAGLE-3、DFlash、DSpark などの手法をサポートしています。トレーニング後は、独自のプロンプト上でドラフトトークンの受け入れ率とデコードスループットを測定してください。

ほとんどのアプリケーションで、独自にモデルを訓練する必要はありません。まずは利用可能なチェックポイントから始め、精度とパフォーマンスを測定し、その結果に明確な課題が見られた場合にのみ、独自の訓練を行うようにしてください。

始め方

Jetson は、最適化されたランタイム、量子化済みチェックポイント、推測デコーディングに対応した最新のオープンモデルをサポートしています。この基盤を整えることで、モデルのテストからエッジアプリケーションの構築・展開へとスムーズに移行できます。

これらのモデルの詳細やベンチマーク方法、推奨レシピ、Jetson 各プラットフォーム間での性能比較については、Jetson AI Lab Models ページをご覧ください。

より実践的なガイドラインについては、以下のチュートリアルもご参照ください。Jetson 上での LLM と VLM の実行、生成 AI モデルのベンチマーク方法、そして主要なフレームワークにおける 推測デコーディングの入門 です。