オープンソースの生成 AI モデルのブームは、データ センターだけでなく、現実世界で稼働する機器へと広がってきています。開発者は、これらのモデルをエッジにデプロイし、フィジカル AI エージェントや自律型ロボットによる高負荷のタスクの自動化が実現することを熱望しています。
主な課題は、メモリ容量が限られているエッジ デバイスで数十億パラメーター規模のモデルを効率的に実行することです。メモリ供給の制約が続き、コストが上昇する中で、開発者はより少ないリソースでより多くの成果を達成することに注力しています。
NVIDIA Jetson プラットフォームは、人気のあるオープン モデルをサポートするとともに、エッジ環境で強力なランタイム パフォーマンスとメモリ最適化を実現します。エッジ開発者にとって、システムが機能するかどうかは、メモリの占有量によって決まります。クラウド環境とは異なり、エッジ デバイスは厳しいメモリ制限下で動作し、CPU と GPU が限られたリソースを共有します。
メモリ使用効率が悪いと、ボトルネックの発生、遅延の急増、またはシステム障害につながる可能性があります。一方、最新のエッジ アプリケーションは、検出、トラッキング、セグメンテーションなど、複数のパイプラインを実行することが多く、効率的なメモリ管理が、電力や冷却能力の制約下で安定したリアルタイムのパフォーマンスを維持するために不可欠です。
メモリ使用率の最適化には明確な利点があります。開発者は、オーバーヘッドを削減し、並列処理能力を高めることで、同じハードウェアでパフォーマンスを向上できると同時に、LLM、マルチカメラ システム、センサー フュージョンなど、より複雑なワークロードを実行できます。また、小容量のメモリ構成にも対応することでシステム コストを削減し、ボトルネックを最小限に抑え、GPU 利用率を最大化することで、効率 (ワットあたりのパフォーマンス) を向上させます。
このブログでは、リソースに制約のあるエッジ システムで、開発者がパフォーマンス、効率性、機能を最大化するのに役立つ最適化戦略について説明します。
エッジ AI ソフトウェア スタック
エッジ デバイスのランタイム ソフトウェア スタックについて詳しく見てみましょう。これは、メモリ最適化のすべてを網羅したガイドではありませんが、アイデアのきっかけとなり、開発者がスタックを改善する新しい方法を見つけるのに役立つリファレンス フレームワークです。メモリの削減量は、NVIDIA チームが達成した成果を示しています。経験豊富なユーザーはさらに高い効率を実現できるかもしれませんが、その他のユーザーは、これらのサンプルを参考として、NVIDIA Jetson および NVIDIA IGX プラットフォーム上でリソースをより効率的に活用できるようになります。
このブログでは、Jetson BSP と NVIDIA JetPack という基盤を始めとして、推論パイプライン、推論フレームワーク、量子化手法へと進む、5 つの主要レイヤーを紹介します。各レイヤーを順を追って見ていきましょう。
基盤レイヤー: ボード サポート パッケージとソフトウェア スタック
NVIDIA Jetson Board Support Package (BSP) と NVIDIA JetPack レイヤーは、ソフトウェア スタックの基盤を形成し、ハードウェアとのインターフェイスを担います。これには、Linux カーネル、デバイス ドライバー、ファームウェア、JetPack SDK と、演算、マルチメディア、高速化された I/O を実現するコンポーネントが含まれています。このレイヤーは、GPU、CPU、メモリ、周辺機器といったハードウェアの複雑さを抽象化し、上位レベルのサービスやアプリケーション向けに安定的で最適化された基盤を提供します。
このレイヤーでは、未使用のサービスを無効化し、予約済みのカーブアウト領域を解放することで、メモリの節約を実現できます。これらの最適化により、コア機能に影響を与えることなく、オーバーヘッドを削減し、アプリケーション ワークロード用に DRAM を解放できます。以下のセクションでは、これらの最適化を実現する主な手法を紹介します。BSP と JetPack レイヤーの最適化ガイドラインは、Jetson Orin NX と Jetson Orin Nano で有効です。
| 調整項目 | 解放可能なメモリ | 手順 |
| ディスプレイと UI 関連サービスを含む、グラフィカル デスクトップの無効化 | 最大 865 MB | sudo systemctl set-default multi-user.target |
| ネットワーク、接続、必須でないジャーナリング サービスの無効化 | 最大 32 MB | sudo systemctl disable <service-name> |
NVIDIA Jetson Orin NX におけるカーブアウト領域とカーネルおよびユーザー空間の最適化は、システム全体の効率を向上させる重要な要素です。以下のセクションでは、これらのレイヤーを最適化する実践的な手法を紹介します。
カーブアウトの最適化
NVIDIA Jetson Orin NX と NVIDIA Jetson Orin Nano のカーブアウト領域は、特定のハードウェア エンジン、ファームウェア、リアルタイム サブシステムのために、起動時に予約される物理メモリです。Linux または NVIDIA CUDA アプリケーションはこれらにアクセスできず、オンチップのマイクロコントローラやアクセラレーターで使用されます。これらは専用のメモリプールとして機能し、分離性とセキュリティを確保するとともに、他の処理の影響を受けにくい、予測可能な動作を実現します。パイプラインとアプリケーションのニーズに応じて一部のカーブアウトを無効にすることで、メモリ使用量をさらに最適化できます。
| カーブアウト | 無効にするタイミング | 無効化する方法 | 解放される DRAM 容量 |
| CARVEOUT_DCE_TSEC | ディスプレイが 必要ないとき | 注 1 を参照 およびリフラッシュ | 1 MB |
| CARVEOUT_DCE | 32 MB | ||
| CARVEOUT_DISP_EARLY_BOOT_FB | 34 MB | ||
| CARVEOUT_TSEC_DCE | 1 MB | ||
| CARVEOUT_CAMERA_TASKLIST | カメラが 必要ないとき | 注 2 を参照 およびリフラッシュ | 32 MB |
| CARVEOUT_RCE | 1 MB |
注 1: 以下の例は、ディスプレイが必要ない場合に、ユーザーがメモリを最適化する方法を紹介しています。Linux_for_Tegra/bootloader/generic/BCT/tegra234-mb1-bct-misc-p3767-0000.dts の /misc/carveout/ ノード内にコード スニペットを追加します。
// Display-related carveouts
aux_info@CARVEOUT_BPMP_DCE {
pref_base = <0x0 0x0>;
size = <0x0 0x0>; // 0MB
alignment = <0x0 0x0>; // 0MB
};
aux_info@CARVEOUT_DCE_TSEC {
pref_base = <0x0 0x0>;
size = <0x0 0x0>; // 0MB
alignment = <0x0 0x0>; // 0MB
};
aux_info@CARVEOUT_DCE {
pref_base = <0x0 0x0>;
size = <0x0 0x0>; // 0MB
alignment = <0x0 0x0>; // 0MB
};
aux_info@CARVEOUT_DISP_EARLY_BOOT_FB {
pref_base = <0x0 0x0>;
size = <0x0 0x0>; // 0MB
alignment = <0x0 0x0>; // 0MB
};
aux_info@CARVEOUT_TSEC_DCE {
pref_base = <0x0 0x0>;
size = <0x0 0x0>; // 0MB
alignment = <0x0 0x0>; // 0MB
};
Linux_for_Tegra/bootloader/tegra234-mb2-bct-common.dtsi の /mb2-misc/auxp_controls@3/ ノードのコンテンツを以下に更新します。
/* Control fields for DCE cluster. */
auxp_controls@3 {
enable_init = <0>;
enable_fw_load = <0>;
enable_unhalt = <0>;
reset_vector = <0x40000000>;
};
Linux_for_Tegra/bootloader/tegra234-mb2-bct-common.dtsi の /mb2-misc/auxp_ast_config@6 と /mb2-misc/auxp_ast_config@7 ノード全体を削除します。
dtc ツールを使用して、カーネル dtb を dts にデコンパイルし、/display@13800000 ノードのステータスを disabled にマークし、dts をカーネル dtb に再コンパイルします。
display@13800000 {
status = "disabled";
};
注 2: 以下の例は、カメラが必要ない場合に、ユーザーがメモリを最適化する方法を紹介しています。Linux_for_Tegra/bootloader/generic/BCT/tegra234-mb1-bct-misc-p3767-0000.dts の /misc/carveout/ ノード内にコード スニペットを追加します。
aux_info@CARVEOUT_CAMERA_TASKLIST {
pref_base = <0x0 0x0>;
size = <0x0 0x0>; // 0MB
alignment = <0x0 0x0>; // 0MB
};
aux_info@CARVEOUT_RCE {
pref_base = <0x0 0x0>;
size = <0x0 0x0>; // 0MB
alignment = <0x0 0x0>; // 0MB
};
Linux_for_Tegra/bootloader/tegra234-mb2-bct-common.dtsi の /mb2-misc/auxp_controls@2/ ノードのコンテンツを次のように更新します。
/* Control fields for RCE cluster. */
auxp_controls@2 {
enable_init = <0>;
enable_fw_load = <0>;
enable_unhalt = <0>;
};
カーネル側の最適化
Jetson Orin、Orin NX、および Orin Nano プラットフォームは、NVIDIA 固有の入出力メモリ管理ユニット (IOMMU) を使用して周辺機器のダイレクト メモリ アクセス (DMA) アドレス変換を処理し、物理アドレスに関係なくデバイスがシステム メモリにアクセスできるようにします。
Linux Software I/O Translation Lookaside Buffer (SWIOTLB) は、ハードウェア IOMMU がないシステム、または 32 ビット DMA に制限された周辺機器を使用するシステムを対象とした回避策です。Orin には、DMA アドレスを再マッピングする堅牢なハードウェア IOMMU が搭載されているため、SWIOTLB は一般的に不要です。
SWIOTLB チューニング
特定のユース ケースや SWIOTLB を必要とする非標準の周辺機器、またはカーネル ログに DMA の問題が示される場合、ブート引数を使用して予約サイズを調整できます。
swiotlb= パラメーターは、I/O TLB スラブ (各 2 KB) の数を定義します。
合計サイズ (バイト) = swiotlb_value × 2,048
例 (4 MB バッファ):
- 4 MB ÷ 2 KB = 2,048 スラブ
- Kernel command:
swiotlb=2048
ユーザー空間側の最適化
Jetson ではアプリケーションの合計メモリに以下が含まれます:
- プロセスとシステム サービスで使用される CPU メモリ
- CUDA、マルチメディア バッファ、アクセラレーターで使用されるハードウェア (NvMap) メモリ
どちらも同じ物理メモリ プールを共有しているため、一方を最適化すると他方にもメリットがあります。
CPU メモリ使用量の削減
まず、CPU メモリを最も多く消費するプロセスを特定することから始めます。GUI やオーディオ コンポーネントなどのバックグラウンド サービスは、大量のメモリを消費している可能性があり、本番環境では不要な場合があります。
- CPU メモリ使用量の測定
procrankを使用してメモリ使用量を分析します:
$ git clone https://github.com/csimmonds/procrank_linux.git
$ cd procrank_linux/
$ make
$ sudo ./procrank
出力は、PSS (Proportional Set Size) 順にソートされ、実際の物理メモリ使用量を反映します。
- 調査結果に基づいて最適化し、以下のプロセスを特定します
gnome-shellまたはXorg(GUI)pulseaudio- 未使用の python3 プロセス
これらは本番環境では不要なことが多いため、無効にしてメモリを解放することができます。ヘッドレス環境では、GUI サービスを無効にすることで、システム メモリの大部分を解放できます。
- ハードウェアのメモリ使用量の分析と測定
CPU メモリに加えて、GPU とマルチメディアの割り当ても、利用可能なメモリに影響を与える可能性があります。
$ sudo cat /sys/kernel/debug/nvmap/iovmm/clients
*これは、NvMap を使用したプロセス (CUDA、ビデオ パイプラインなど) 全体のメモリ使用量を示しています。
- ハードウェア メモリの最適化
GPU またはバッファの割り当てが大きいプロセスを特定します。CPU の最適化と同様に、GUI パイプライン (gnome-shell、Xorg) などのサービスも、不要なハードウェア メモリを消費している可能性があります。これらの割り当てを削減することで、AI ワークロード用にさらに多くのメモリを解放できます。
推論パイプライン
このレイヤーは、前処理、推論、後処理を通じてエンドツーエンドのデータ フローを管理し、実用的な出力を生成します。NVIDIA DeepStream のようなフレームワークは、ビデオやセンサー入力などのストリーミング データを処理するための高性能な GPU アクセラレーテッド パイプラインを提供します。デコード、バッチ処理、推論、トラッキング、分析を効率化されたワークフローで処理し、スケーラブルな処理を実現します。このレイヤーは、複雑な処理を抽象化し、データ移動と演算の利用率を最適化することで、効率的かつ本番環境に対応した AI アプリケーションを実現します。
設定や実装の選択を通じて推論パイプラインを最適化し、メモリの占有量を削減し、パフォーマンスを向上させる方法を学びます。DeepStream を例として説明していますが、これらの原則は多様なフレームワークやアプリケーションに広く適用されます。
| 調整項目 | 解放可能なメモリ |
| コンテナー vs. ベアメタル | 最大 70 MB |
| Python から C++ への切り替え | 最大 84 MB |
| パイプライン構成の微調整:**Tiler/OSD の無効化、FakeSink の使用 | 最大 258 MB |
| 合計 | 412 MB |
*DeepStream スタイルの推論パイプラインでは、Tiler/OSD を無効にし、FakeSink を使用することで、可視化には必要だが、ヘッドレス環境や本番環境での展開では不要なディスプレイ ステージを削除できます。**これにより、メモリの節約、GPU の負荷の軽減、およびスループットの向上が実現します。
推論フレームワーク
LLM 向けの推論サービング フレームワーク レイヤーは、本番環境における大規模言語モデルの効率的なデプロイとスケーリングに重点を置いています。この分野では、vLLM、SGLang、Llama.cpp などのフレームワークがリードしています。これらのフレームワークは、継続的なバッチ処理、KV キャッシュ管理、効率的なメモリ利用などの手法を通じて推論を最適化し、スループットを最大化し、遅延を低減します。
- vLLM は、ページング アテンション メカニズムを活用した高スループット サービングに優れています。
- SGLang は、柔軟でプログラマブルな推論ワークフローを可能にします。
- Llama.cpp と NVIDIA TensorRT Edge-LLM は、リソースに制約のある環境でメモリ効率を高めて実行するように最適化されています。
これらのフレームワークは、エッジでローカルに導入する際、LLM を確実に提供するために必要なインフラを提供します。
モデルの量子化
モデルの量子化は、低精度のデータ型で重みとアクティベーションを表現することで、メモリ 占有量を削減し、AI モデルの推論を高速化するために使用される重要な手法です。
量子化は、対象のユース ケースにおける明確な精度とパフォーマンスの要件に基づいて実施する必要があります。量子化スキームを選択する前に、以下を定義してください。
- 許容可能な最小限のモデル品質またはタスク精度
- 目標とするスループットと遅延
- デプロイの制約、特に利用可能な GPU メモリ
これらの要件を明確にした上で、低精度の量子化オプションを段階的に評価することを推奨します。最高精度のベースラインから開始し、モデルが要求される品質の閾値を満たさなくなるまで、サポートされている量子化フォーマットを順に下げていきます。選択した量子化ポイントは、ユース ケースの精度要件を満たす最低精度であるべきです。なぜなら、それにより通常、メモリの節約と効率性が最も高まるからです。
低ビットの量子化によって許容できない劣化が起こった場合、量子化認識蒸留 (QAD) などの回復手法を使用して、失われた精度を回復してください。これらの手法は、多くの場合、デプロイの要件を満たしながら、より積極的な量子化を可能にするために十分なモデル品質を回復させることができます。
量子化レベルが選択されたら、ターゲット環境に合わせてランタイム メモリを最適化します。vLLM 構成パラメータ、特に GPU メモリ使用量を徹底的に調べ、目標のパフォーマンスを維持するために最小限のメモリ占有量を特定します。これにより、スループットと遅延の目標に適した、効率的かつ適切な規模のデプロイが可能になります。
FP16 や FP8 のようなフォーマットは、精度とパフォーマンスのバランスを保ち、FP8 のスループット向上のために、利用がますます増えています。W4A16 などのより積極的なスキームは、許容可能な精度を維持しながら、メモリと帯域幅の要件を削減します。NVIDIA NVFP4 は、ハードウェアに適した 4 ビットの演算により、効率をさらに向上させます。これらのアプローチを組み合わせることで、大規模モデルやリソースに制約のあるシステムにおいて、より高速でコスト効率に優れた推論が可能になります。サポート内容は Jetson プラットフォームによって異なります。詳細については、NVIDIA Jetson 製品カタログをご覧ください。
| 調整項目 | 解放可能なメモリ | 注意 |
| Qwen3 8B におけるモデルの量子化 (FP16 から W4A16) | 最大 10 GB | Qwen3 8B |
| Qwen3 4B におけるモデルの量子化 (BF16 から INT4) | 最大 5.6 GB | Qwen3 4B |
組み込まれ、最適化された 5 レイヤー ソフトウェア スタックの構成要素によって異なりますが、高い精度と機能の同等性を維持しながら最大 10 ～ 12 GB のメモリ削減が可能です。
専用アクセラレーターによるエッジでの推論の分散
Jetson プラットフォームには、CPU や GPU から専門的なワークロードをオフロードすることで、効率を向上させる GPU 以外のアクセラレーターがいくつか含まれています。これらには、カメラ処理用の画像信号プロセッサ (ISP)、ビデオのエンコード/デコード用の NVENC/NVDEC、ビジョン タスク用の NVIDIA Programmable Vision Accelerator (PVA) が含まれます。
Jetson Orin NX から Jetson Thor まで利用可能な PVA は、継続的な GPU 使用が非効率的となる、常時稼働の低消費電力ビジョン ワークロード (セントリー モード、モーション検出、オブジェクト トラッキング、特徴抽出など) に適しています。これらのタスクをオフロードすることで、PVA は遅延を短縮し、GPU リソースをより複雑な推論や並列ワークロードに活用し、エッジ導入における全体的なパフォーマンスと電力効率を向上させます。
NVIDIA cuPVA SDK は、現在早期アクセスの段階です。その機能に興味がある方は、詳細についてお問い合わせください。
複数のレイヤーにわたる潜在的な削減効果:
| レイヤー | 潜在的な削減効果 |
| BSP と OS サービス | 最大 1,025 MB |
| パイプラインの最適化 | 最大 412 MB |
| 推論フレームワークとモデルの量子化 | 最大 5 〜 10 GB |
重要なポイントが 1 つあるとすれば、適切な量子化の精度を使用することです。
NVFP4、INT4、W4A16 などのフォーマットは、多くの LLM ワークロードで高い精度を維持しながら、メモリとストレージの要件を大幅に削減します。
実際のユース ケース: Reachy Mini Jetson Mini Assistant
これらのメモリ最適化の効果を示すために、Jetson Orin Nano 上で実行されるオンデバイス対話型 AI ロボットである Reachy Mini Jetson Assistant を考えてみましょう。これは 8 GB の統合メモリを搭載し、クラウドに依存しないものです。
このアシスタントは、視覚理解のために 4 ビット (Q4_K_M GGUF) に量子化され Llama.cpp を介して提供されるビジョン言語モデル (Cosmos-Reason2-2B)、音声認識用の faster-whisper (small.en)、テキスト読み上げ用の Kokoro TTS を含むマルチモーダル AI パイプラインを、Reachy Mini ロボット SDK およびライブ Web ダッシュボードと並行して同時に実行します。
スタック全体の最適化 (ディスプレイ マネージャーの無効化、ヘッドレスでの実行、重い Python フレームワークの代わりに Llama.cpp 経由での VLM サービング、4 ビット量子化された Cosmos Reason2 2B の使用、STT 向けの CTranslate2、TTS および VAD 向けの ONNX Runtime といった最適化されたランタイムの選択) により、パイプライン全体を単一の Orin Nano 8 GB システム上で実行します。
より広範に、4 ビットの量子化と Llama.cpp や TensorRT-Edge-LLM など、効率的な推論ランタイムを組み合わせることで、最大 10B パラメーターの LLM と最大 4B パラメーターの VLM を搭載した幅広いモデルを、このメモリ予算内で利用できるようになります。テスト済みモデルの全リストは、Jetson AI Lab Models ページと NVIDIA Developer Forum でご覧ください。
| 最適化レイヤー | メモリ 最適化前の Orin NX 16 GB | メモリ 最適化後の Orin Nano 8 GB | メモリ 占有量 (最適化前) | メモリ 占有量 (最適化後) | 節約されたメモリ合計 |
| BSP と OS サービス | Ubuntu デスクトップ (GNOME フル セッション) | ヘッドレス モード | 1.8 GB | 1.1 GB | 最大 0.7 GB |
| llama.cpp における VLM のモデル量子化 | VLM FP16 | VLM Q4_K_M 量子化 | 6.6 GB | 2.2 GB | 最大 4.4 GB |
| Reachy Mini Jetson Assistant アプリ | Orin Nano 8 GB では実行されない (VLM 単体で 87% の RAM を使用) | 4.5 / 7.6 GB (最大 60%) でフル パイプラインを実行 | 7.6 GB 超 (OOM)[注 3] | 4.5 GB | 5.1 GB 超 |
注 3:
Jetson Orin Nano 8 GB モジュールは、8 GB の物理 DRAM のうち、ファームウェアとカーネルの予約分を差し引くと約 7.6 GB が使用可能です。この記事の「利用可能メモリ」の数値はすべて、その使用可能なメモリ枠を指しています。テスト対象の VLM は、Cosmos Reason 2 (2B パラメーター) です。
デスクトップ環境とヘッドレス環境の比較は、純粋に BSP 構成の切り替えによるものです。完全な GNOME デスクトップ セッション (gnome-shell + Xorg + gnome-software + 関連するバックグラウンド サービス) とヘッドレス ブート ターゲット (multi-user.target) を比較したもので、スタックにその他の変更は加えられません。
この節約効果は、最適化された C++ 推論バックエンド (llama.cpp) を前提としています。より負荷の重い推論フレームワークに切り替えると、1 バイトのモデルの重みがロードされる前に、フレームワークの初期化により 2.7 GB 以上の追加のオーバーヘッドが発生する可能性があります。8 GB のプラットフォームでは、そのオーバーヘッドによって、多くの場合モデルが収まるかどうかが決まります。
今すぐ始める
- 次世代の Jetson Orin Edge AI プラットフォームの詳細を確認します。
- JetPack と DeepStream をインストールします。
- NVIDIA Jetson フォーラムで、体験談と、この投稿がどのように役立ったかを共有しましょう。
翻訳に関する免責事項
この記事は、「Maximizing Memory Efficiency to Run Bigger Models on NVIDIA Jetson」の抄訳で、お客様の利便性のために機械翻訳によって翻訳されたものです。NVIDIA では、翻訳の正確さを期すために注意を払っておりますが、翻訳の正確性については保証いたしません。翻訳された記事の内容の正確性に関して疑問が生じた場合は、原典である英語の記事を参照してください。
