エッジで「推論」を動かす時代の到来
これまで、マルチステップ推論が可能なモデルをエッジデバイス上で動かすことは現実的ではありませんでした。パラメータ数が大きすぎてデータセンターGPUが必須であり、ネットワーク依存・コスト増・そして「データを端末外に出せない」制約のある現場ではセキュリティリスクも伴っていました。
しかし2026年に入り、状況は大きく変わりました。コンパクトなオープンモデルがデータセンター級の推論能力をエッジで発揮できるようになり、NVIDIA Jetsonシリーズでもそのまま実行可能になっています。車載アシスタント、リアルタイム異常検知、通信が不安定な環境で稼働するロボットなど、実用的なユースケースが一気に現実味を帯びてきました。
本記事ではNemotron 3.5 LightningとQwen3.8-27Bを例に、Jetson上でのモデル選定・最適化・検証の流れを実践ベースで整理します。
なお本内容はNVIDIA Developer Blogの根拠資料を基に、実務向けに再構成したものです。
モデル選定: DenseかMoEか
結論から言うと、ワークロード特性によって選択が変わります。 まず両モデルのアーキテクチャの違いを押さえましょう。
| 項目 | Qwen3.8-27B | Nemotron 3.5 Lightning |
|---|---|---|
| アーキテクチャ | Dense | MoE (Mixture-of-Experts) |
| 総パラメータ数 | 27B | 30B |
| トークンあたり活性パラメータ | 27B (全量) | 3B |
| 適したワークロード | 少数の「難しい判断」 | 応答量の多い反復ワークフロー |
| トークン生成速度 | 相対的に低速 | 高速 |
- Nemotron 3.5 Lightning: MoEのためトークンあたり3Bのみ活性化。センサー監視→是正措置→検証→エスカレーションというエージェントループのように、応答生成が多い処理に向きます。
- Qwen3.8-27B: Denseのため毎トークンで27B全量を計算。代わりに「一度の判断」に深い推論が求められるタスクに強いです。
Jetson Orin NanoであればGemma 4 E4Bが出発点として現実的、AGX Orin / AGX Thorであれば上記2モデルが有力な選択肢となります。
vLLMでのサービング: 実践コマンド
まずvLLMコンテナを起動します。
docker run --pull=always --runtime nvidia --rm -it \
--network host \
--ipc=host \
-v ~/.cache/huggingface:/root/.cache/huggingface \
--entrypoint bash \
vllm/vllm-openai:v0.28.0
Nemotron 3.5 Lightning (NVFP4 + DSpark)
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 (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 \
--trust-remote-code \
--speculative-config '{"method":"dflash","model":"incoai/Qwen3.8-27B-DFlash2","num_speculative_tokens":7}'
ポイントは--speculative-configです。モデルごとに最適なdraft方式が異なり、NemotronはDSpark、QwenはDFlash2が最も高速だったという点を覚えておきましょう。
最適化の原理: NVFP4 + 投機的デコーディング
2つの手法は補完関係にあります。
- NVFP4量子化: 各推論パスでGPUが転送・計算するデータ量を削減します。BF16比で品質劣化を最小限に抑えつつ、速度とメモリ効率を向上させます。
- 投機的デコーディング(Speculative Decoding): 小型のdraftモデルが複数トークンを提案し、メインモデルがまとめて検証します。複数が受理されれば、1回のパスで複数トークンを生成できる計算になります。
Draft方式の比較
| 方式 | 特徴 | 互換性 |
|---|---|---|
| MTP | メインモデルで学習済みのprediction headを使用 | Qwen, Gemma, Nemotronなど幅広く対応 |
| DFlash | 別途のdiffusionベースdraftがブロック単位で提案 | 対応draftチェックポイントが最も多い |
| DSpark | DFlashの拡張。draft補正＋弱い提案を早期打ち切り | チェックポイントは少ないが高速な場合あり |
注意事項(実務観点)
- ベンチマーク数値を鵜呑みにしないこと。 モデルレベルのベンチマークは出発点に過ぎず、実際のアプリケーションプロンプトで再測定が必要です。NVIDIAの検証でもワークロード別のスループット差が大きく出ています(Nemotron 123〜138 tok/s、Qwen 27〜34 tok/s)。
- Acceptance rateを必ず確認すること。 draftトークンの受理率が低いと、検証コストが利得を打ち消します。
- 閉域網・リモート拠点での注意点: 工場や遠隔地の機器にJetsonを組み込む場合、モデルチェックポイントを事前にイメージへ同梱しないとHugging Faceへのアクセスが遮断され、初期デプロイで躓きがちです。オフラインバンドリングを事前に準備しておきましょう。
- カスタム学習は最後の手段: 多くのケースは既存の量子化チェックポイントで十分です。精度が問題になった場合にのみ、NVIDIA Model OptimizerのQAT/QADを検討してください。
まとめ: 検証なきデプロイはない
全体の流れは次の通りです。
- ワークロード特性を把握 → Dense(Qwen)かMoE(Nemotron)を選択
- vLLMコンテナでNVFP4チェックポイントをサービング
- 投機的デコーディング設定はモデルごとに最適化(DSpark vs DFlash2)
- 必ず実際のアプリケーションプロンプトで再検証
- 精度・速度のギャップが明確な場合のみカスタム学習
エッジで推論モデルを動かす時代が本格的に到来しました。データセンター往復なしにローカルでエージェントループを完結できることは、レイテンシとセキュリティの両面で大きな変化です。次のステップとしては、Jetson AI Labのモデルレシピを参照し、ご自身のワークロードに合う構成を探してみてください。