NVIDIA Jetson で推論型モデルを現場へ届ける構成を考えてみた

はじめに

こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。

設備ログを読み、保全手順書を参照し、作業者へ次の確認項目を提案する。こうした支援を現場の端末で動かしたいとき、モデルが起動するだけでは十分ではありません。ログにない事実を付け足さず、根拠のある提案を、作業を妨げない時間で返してほしいところです。

NVIDIA が 2026 年 9 月 4 日に公開した技術記事では、Jetson 上で Nemotron 3.5 Lightning と Qwen3.8-27B を動かす構成と、生成を高速化する方法が紹介されています。

https://developer.nvidia.com/blog/frontier-reasoning-reaches-the-edge-how-to-deploy-and-optimize-models-on-nvidia-jetson/

ここでいう推論型モデルは、複数段階の reasoning を行って回答を組み立てるモデルです。一方、モデルに入力を渡して出力を得る実行処理も、inference の意味で推論と呼びます。この記事では、前者を現場で使うために、後者のメモリや待ち時間をどう調整するかを考えます。

ローカル処理は、ネットワークへの依存や外部へのデータ送信を減らせます。ただ、応答が遅ければ現場では使いにくいですね。Thor、AGX Orin、Orin Nano の選定も、担当させる仕事と一緒に考えます。

この記事では、量子化と投機的デコーディングの仕組み、およびモデルと配備先を選ぶ考え方を紹介します。LLM や RAG の概要を知り、Jetson を使った PoC を検討している方向けの内容です。

公開資料は 2026 年 9 月 5 日時点で確認しています。掲載する性能は NVIDIA の報告値であり、自分が Jetson 実機で再測定したものではありません。設備保全や映像認識の場面も、導入済みシステムではなく、説明用の架空の設計例として使います。

NVIDIA が示した高速化の結果を読む

元の記事が取り上げるのは、モデルを量子化する NVFP4 と、回答生成の進め方を変える投機的デコーディングです。まずは、何を速くした結果なのかを確認しましょう。

NVIDIA の Figure 2 は、それぞれのモデルを 16 ビット形式の BF16 で動かす構成を基準に、デコードスループットの倍率を比較しています。デコードは、入力を処理した後に回答を生成する部分です。

数値は NVIDIA の掲載値を表に整理したものです。Nemotron では DSpark、Qwen では DFlash2 が、NVIDIA が比較した中で最も速い構成として使われています。

この表で注目したいのは、量子化だけで終わらず、生成手順の変更を重ねて速度を伸ばしている点です。ただし、両モデルの 1 倍は同じ速度ではありません。Qwen の倍率が大きいからといって、Nemotron より絶対速度が速い、あるいは回答品質が高いと読める表ではないわけです。

確認した本文と図のキャプションからは、この数値に対応する機種、電力モード、入力・出力長などの全条件を特定できませんでした。Jetson の全機種で同じ倍率が出るという結果でも、Thor と Orin の性能差を示す結果でもありません。

設備保全では、ログ取得、手順書の検索、入力処理、回答生成を合わせた時間で比べます。検索やツール待ちが長ければ、生成を速くしても全体の短縮幅は小さくなります。長い回答を繰り返す処理なら、改善が効きそうです。

Thor と AGX Orin と Orin Nano をどう選ぶか

Jetson といっても、搭載メモリや GPU アーキテクチャは一様ではありません。今回は Jetson T5000 を搭載した AGX Thor の 128 GB 構成、AGX Orin 64GB、Orin Nano Super Developer Kit の 8 GB 構成を代表例にします。旧 Jetson Nano ではなく、Orin 世代の Nano が対象です。

ハードウェア仕様は NVIDIA の Thor、Orin、Orin Nano Super の製品ページに基づきます。最後の列は仕様ではなく、設備保全の例で考える担当範囲です。

電力範囲は、ストレージや周辺機器を含む装置全体の実測消費電力ではありません。また、FP4 の演算性能と INT8 TOPS を横並びの性能指標にすると条件がそろわないため、この表には載せていません。

Thor は検証専用ではありません。必要な品質を出すモデルや、複数処理を収容するためにメモリが必要なら、Thor 搭載の量産機を選ぶ案もあります。反対に、用途が狭く配備先の制約も分かっているなら、Nano から直接検証を始めてもよいでしょう。どの案件も Thor の調達から始める必要はありません。

AGX Orin へ移すために蒸留が必要、と決めつけるのも早そうです。Nemotron 3.5 Lightning のモデルページ は、対応プラットフォームに AGX Orin 64GB を明記しています。同じモデルを使える候補があるなら、先にその構成で業務品質と待ち時間を確かめたいところです。

一方、Nano の 8 GB は CPU と GPU が共有するメモリであり、モデルの重みだけに使える容量ではありません。ログ取得や検索などを同じ端末で動かすなら、その分も見込む必要があります。小型化して動作が不安定になるなら、AGX Orin を使う、拠点側へ処理を渡す、といった案を比較します。中間の容量が必要なら Orin NX も候補になります。

開発キットと本番用の機器は区別します。NVIDIA の FAQ は、開発キットを開発・評価用、量産モジュールを本番配備用としています。量産ではモジュールと製品用キャリアボードに加え、筐体や冷却も選びます。

安全機能やセキュリティ、長期サポートの要件によっては、NVIDIA IGX 搭載システムも候補です。IGX が一律に必要なわけではなく、採用だけで装置全体の安全性が保証されるものでもありません。

モデルの規模と必要メモリを分けて考える

Nemotron 3.5 Lightning は、総パラメーター数が 30B、1 トークンの処理で有効になるパラメーター数が 3B の MoE モデルです。MoE は Mixture of Experts の略で、処理ごとに一部の Expert を選んで使います。

対して Qwen3.8-27B は、27B の Dense モデルです。MoE のような Expert の切り替えはなく、1 トークンの処理で 27B のパラメーターを使います。NVIDIA の記事では、応答を繰り返すエージェントに Nemotron、少ない回数で難しい判断をする用途に Qwen という見方を示しています。ただし、これは選定の出発点です。設備の取り違えを防げるか、手順書の根拠を正しく引用できるかまでは、モデルの構造だけでは決まりません。

特に気を付けたいのが、有効 3B を、そのまま必要メモリが 3B 相当という意味に読まないことです。使う Expert が一部でも、それ以外の重みが不要になるわけではありません。

説明用に、30B 個の重みをすべて 4 ビットで保存すると仮定してみます。30,000,000,000 × 4 ÷ 8 で 15,000,000,000 bytes、十進表記で約 15 GB です。これは単純計算であって、実際のチェックポイント容量や実行時メモリの測定値ではありません。

実際には、量子化のスケール情報、過去の計算を再利用する KV キャッシュなどの実行状態、補助モデル、推論エンジンの作業領域も使います。入力を長くしたり同時処理を増やしたりすれば、重みの容量だけでは説明できない差が出ます。モデルファイルが小さくなったことと、アプリケーションを含めて端末に収まることは別に確認します。

Nano では、既存の小型モデルへ置き換える案も早い段階で試したいところです。TensorRT Edge-LLM の公式チュートリアル には、Qwen3-4B-Instruct-2507 の重みを INT4 AWQ で 4 ビットに量子化し、Orin Nano 8 GB で使う例があります。これは Qwen3.8-27B の蒸留版ではなく、別のモデルを選ぶ例です。

量子化と投機的デコーディングで生成を速くする

入力を読む処理と回答を生成する処理

LLM の推論処理には、入力を読む Prefill と回答を生成する Decode があります。ここでは主に Decode を扱います。入力直後の待ち時間と生成速度は、同じ調整で改善するとは限りません。

NVFP4 は数値表現を小さくする

量子化は、重みなどの数値を低いビット数で表現する手法です。NVIDIA の NVFP4 の説明 では、4 ビットの値にブロック単位と全体のスケールを組み合わせます。数値の表現を粗くするだけでなく、値の大きさに合わせた尺度を併用する形式です。

毎回扱うデータを軽くする、と考えると狙いがつかみやすいと思います。GPU が重みを読み出して計算するときのデータ量を減らせれば、メモリ容量だけでなく、生成にかかる時間にも効きます。

ただし、4 ビット化によってパラメーター数が減るわけではありません。すべてのメモリ領域が同じ比率で縮むわけでもなく、精度の低下が業務上許容できるかは別の確認事項です。必要なメモリ、使われる演算、速度、回答品質を、選んだモデルと実装で確かめます。

投機的デコーディングは下書きをまとめて検証する

通常の自己回帰生成は、次のトークンを決めるために本体モデルを実行し、その結果を使って次へ進みます。少数のリクエストを扱う環境では、トークンごとに重みを読み出すメモリ帯域がボトルネックになりやすい、と Jetson AI Lab のチュートリアル は説明しています。

投機的デコーディングでは、軽量な予測器が複数の候補を下書きし、本体モデルがまとめて検証します。候補を先頭から採用し、却下された位置以降の下書きは捨てます。採用できた分だけ生成を先へ進められるので、本体の重みを読み出す一回の処理から、より多くの出力を得られます。下書きをそのまま回答にせず、本体を通して採否を決める点がポイントです。

量子化は数値表現、投機的デコーディングは生成手順を変える。模式図であり、処理時間・採用率・高速化倍率を表すものではありません。Jetson AI Lab と NVIDIA の NVFP4 資料を参照して作図しています。

方式にも違いがあります。MTP はモデルに対応した予測ヘッドなどを使い、DFlash はブロックを並列に下書きします。DSpark は並列の下書きに補正や信頼度の仕組みを加えます。どれも対応するモデルや実行経路の確認が必要で、別サイズ向けのドラフトをそのまま差し替えるものではありません。

候補数を増やせば速くなる、とも限りません。採用されない候補にも生成と検証のコストがかかります。設備名や固有のエラーコードを含む入力では、一般的な文章と採用率が変わる可能性もあるため、業務を代表する入力で比べます。

正しく実装された標準的な投機的デコーディングは、本体モデルの出力分布を保つ仕組みです。ただし、それは量子化前の品質へ戻すという意味ではなく、異なる実装間でビット単位の一致を保証する説明でもありません。量子化の品質評価を省略する理由にはしないほうがよいですね。

モデルを読み込めても速く動くとは限らない

NVFP4 形式のモデルを読み込めても、GPU の FP4 演算機能で処理できるとは限りません。実際の計算方法は、機種と推論エンジンによって変わります。

たとえば、TensorRT Edge-LLM の Jetson 向け NVFP4 対応は Thor が対象です。一方、NVIDIA は vLLM で AGX Orin に NVFP4 モデルを読み込ませる構成も紹介しています。

ただし、その Orin 構成が内部でどう計算するかは今回確認していません。モデルの保存形式だけで速さを判断せず、配備先の機種と推論エンジンの組み合わせで速度を確かめます。

公式のデプロイ構成を読み解く

NVIDIA の起動例は、JetPack 7.2、Docker と NVIDIA Container Runtime、vllm/vllm-openai:v0.28.0 を前提としています。ここではコマンド全文の転載ではなく、何を組み合わせているかを読み解きます。

Nemotron の例は、nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4 を本体に、同じ名前へ -DSpark を付けた専用ドラフトを指定しています。方式は dspark、候補数は 5 です。投機的デコーディングの別チュートリアルには候補数 4 の例もあるので、資料の設定を混ぜず、まず一つの構成を基準にします。

設定で確認したいまとまりは次のとおりです。オプションの意味は vLLM の serve CLI も参照できますが、更新される stable 文書の既定値を、過去のバージョンへ当てはめないようにします。

Qwen 側は Inferact/Qwen3.8-27B-NVFP4 と incoai/Qwen3.8-27B-DFlash2 の組み合わせで、方式指定は dflash、候補数は 7 です。チェックポイント名の DFlash2 と CLI の指定名を混同しないようにします。

ランタイムを替える場合は、必要な API も確認します。たとえば Nemotron のモデルページは、TensorRT Edge-LLM 0.10.0 の実験的サンプルで OpenAI tools 要求をサポートしないと明記しています。モデルがツールを選べることと、サーバーがツール要求を扱えることは別です。

ここまでの構成は公式掲載例であり、自分の動作確認済み手順ではありません。検証する場合は型番、JetPack、コンテナのタグと digest、モデルとドラフトの revision、主要設定、電力モードを残します。開発用の起動例をそのまま本番ネットワークへ公開せず、認証、到達範囲、配布元、ツールの権限も別途決めます。

現場への配備は小型化だけではない

ここからは、紹介した技術を踏まえて導入の進め方を考えます。設備ログと保全手順書を使う支援エージェントを例にしますが、設備操作の自動実行は含めません。

先に比較できる業務フローを作る

まず、モデルを替えて比較できる業務フローを作ります。入力は設備 ID、ログ、計測値、手順書の該当箇所にそろえ、回答には事実、根拠、次の確認項目、人への確認事項を求めます。集計やしきい値判定はコードに任せます。

必要な品質の確認と並行して、配備先候補でも早期に動かします。評価用の正解はモデルの出力をそのまま使わず、手順書と業務担当者の確認で用意します。

既存モデルと担当範囲の変更を先に比較する

同じモデルの設定調整、既存の小型モデルへの変更、処理分担、必要時の追加学習や蒸留を比較します。順番にすべて実施する工程ではありません。たとえば温度上昇の検出は固定ルールへ寄せ、モデルには該当手順の説明を任せる案もあります。

同じ評価問題でモデルの調整・置き換え・蒸留・処理分担を比較し、配備先で評価する設計案です。蒸留は必須工程ではなく、学習・変換環境は配備先と別に考えます。

蒸留は不足が見えた場合の選択肢

小型モデルで品質が足りない場合に、用途を絞った蒸留を検討します。NVIDIA の知識蒸留の解説 は、教師の生成データで学ぶ方法と、出力分布へ近づける方法を区別しています。

対象は汎用能力すべてではなく、決めた形式で根拠のある確認項目を返す仕事です。教師の誤りも学習されうるため生成データをレビューし、評価問題は設備事象単位で学習用と分けます。

推論が動く環境で学習もできるとは限りません。学習・変換環境と配備先を分け、教師・生徒モデルとデータの商用利用・蒸留の条件を確認します。

NVIDIA が紹介する Quantization-Aware Distillation（QAD） は、量子化で失われた精度の回復を教師で助けます。小さい生徒へ置き換える話とは目的が異なります。

投機的デコーディングのドラフトは、単独で業務を完了する生徒モデルとは役割が異なります。

設備側と拠点側で仕事を分ける

Nano には用途を限定した分類や短い説明を任せ、複数設備の調査は拠点側の AGX Orin や Thor へ渡す案もあります。担当範囲や台数は配備先での評価に基づいて決めます。

通信不能時は端末の担当範囲を超えて判断せず、人へ確認します。上位へ渡す条件はモデルの自己申告だけに頼らず、根拠不足・入力欠損・ツール失敗・規定外の設備状態をアプリケーション側でも検出します。

映像でも探索するモデルと常時動かすモデルを分ける

2026 年 4 月 1 日時点の SAM 3.1 の検証記事を踏まえ、今回は学習・配備の分担を考えます。

VSS は、映像の検索・要約などを組み合わせた Blueprint であり、単一の学習モデルではありません。VSS や画像と言語を扱う VLM で対象場面を探し、SAM 系で物体の領域を示すマスクなどの注釈候補を作る。人がクラスや見落としを確認し、そのデータで用途に合う YOLO 系モデルを学習して、Jetson 上で評価する案です。

これは SAM の重みを YOLO へ変換する話ではありません。疑似ラベルを使う教師あり学習と、特徴量や出力分布を合わせる蒸留は区別します。学習後の TensorRT 形式への書き出しも別工程です。

搬送物のカウントなら検出・追跡・通過判定を組み合わせ、輪郭が必要ならセグメンテーション対応モデルを選びます。既存の軽量モデルで足りるかを先に比べ、作業順序の解釈や理由の説明まで検出器に移せるとは考えません。

同じ動画の隣接フレームが学習側と評価側に混ざらないよう、動画・撮影日単位で分離し、異なるカメラ条件でも確かめます。軽量モデルの検出時だけ VLM を呼ぶと、見逃しは後段にも届きません。通常映像の抜き取り確認も必要です。

この構成は未検証です。LLM の高速化倍率を映像へ当てはめず、探索・注釈作成・常時認識のどこに計算資源を置くかを、品質と応答時間で決めます。

品質と待ち時間と運用条件で配備を判断する

同じ最適化でも、入力の種類によって結果は変わります。NVIDIA の Figure 3 は、各モデル・各カテゴリの NVFP4 構成を 1 倍とした比較です。先ほどの BF16 基準とは異なります。

掲載された Writing、Reasoning、Summarization、RAG の 4 分類では、両モデルとも RAG の改善が大きく、Summarization が小さくなっています。これは RAG 全体の検索時間を測った結果ではなく、そのカテゴリの入力に対するデコードの比較です。設備保全の RAG でも同じ倍率になるとは考えず、実際の業務に近い入力を用意する動機として読みます。

配備の判断には、速度だけでなく次の項目を確認したいところです。

速度指標の定義は Jetson AI Lab の評価ガイド が参考になります。TTFT は最初のトークンまでの時間、ITL は生成トークン間の待ち時間です。一方、vLLM のサービングベンチマークが出す Output token throughput は、計測時間全体に対する出力トークン数であり、純粋な Decode だけの速度とは限りません。

推論型モデルでは、思考部分の出力が始まっても、作業者が使える回答はまだ届いていない場合があります。TTFT だけでなく、確認項目が見えるまでと、必要な参照が終わるまでを記録したいですね。平均だけでは見えない長い待ち時間や、失敗・タイムアウトした要求も残します。

比較時は、業務入力、検索結果、ツールの応答条件、出力長の上限、同時実行数、キャッシュ条件をそろえます。同じモデルの最適化前後ではサンプリング設定も固定し、候補が採用されやすい設定へ変えて速度だけを伸ばさないようにします。

品質や例外処理が合格しない構成は、速くても配備候補から外します。そのうえで、合格した候補の待ち時間、端末構成、運用負担を比較する順番です。合格率や秒数は、設備の停止影響や作業者が待てる時間に応じて、業務側と合意しておきます。

まとめ

Jetson 上の推論型モデルを考えるとき、モデルが起動すること、回答の生成が速いこと、現場で役立つことは、それぞれ別の確認事項です。NVIDIA の記事は、量子化と投機的デコーディングを重ねることで、生成速度を伸ばす構成を示しています。一方、その倍率だけでは配備先や業務品質までは決められません。

自分としては、比較できる業務フローを先に作り、既存の小型モデルや担当範囲の見直しを試し、不足が見えた場合に蒸留を検討する順が進めやすいかなと思っています。評価結果によっては Thor を使い続ける案も、AGX Orin や Nano に処理を分ける案も残せるからです。

今回は公開情報をもとに構成を整理した段階であり、Jetson 実機での品質や継続運転は確認していません。最小の端末へすべてを詰め込むのではなく、必要な品質と待ち時間で処理を配置する。その判断材料となる業務入力と評価基準を用意するところが、導入の出発点になりそうです。

参考リンク

• Frontier Reasoning Reaches the Edge: How to Deploy and Optimize Models on NVIDIA Jetson
• NVIDIA Jetson Thor
• NVIDIA Jetson Orin
• NVIDIA Jetson Orin Nano Super Developer Kit
• Jetson FAQ — NVIDIA
• NVIDIA IGX
• Nemotron 3.5 Lightning — Jetson AI Lab
• Qwen3.8 27B — Jetson AI Lab
• Speculative Decoding on Jetson — Jetson AI Lab
• TensorRT Edge-LLM on Jetson — Jetson AI Lab
• GenAI Benchmarking — Jetson AI Lab
• QAT and QAD — NVIDIA Model Optimizer
• Data-Efficient Knowledge Distillation for Supervised Fine-Tuning with NVIDIA NeMo Aligner
• NVFP4 — NVIDIA Transformer Engine
• serve CLI — vLLM
• Video Search and Summarization — NVIDIA
• Segment Anything Model 3 — Ultralytics
• Instance Segmentation — Ultralytics
• Model Export — Ultralytics