Maximizing Memory Efficiency to Run Bigger Models on NVIDIA Jetson｜NVIDIA Jetson上で大規模モデルを動作させるためのメモリ効率最適化 | AIニュース最前線

NVIDIA Jetson上でより大きなモデルを実行するためのメモリ効率の最大化 オープンソースの生成AIモデルの急増は、データセンターを超えて物理世界で動作するマシンへと拡大している。開発者はこれらのモデルをエッジ（edge）にデプロイすることに意欲的で、物理AIエージェントや自律型ロボットが重労働タスクを自動化することを可能にしている。 主要な課題の一つは、メモリが限られたエッジデバイス上で数十億パラメータのモデルを効率的に実行することである。メモリ供給の制約が続く中、コスト上昇により、開発者はより少ないリソースでより多くのことを達成することに注力している。 NVIDIA Jetsonプラットフォームは、人気のあるオープンモデルをサポートしつつ、エッジでの強力なランタイムパフォーマンスとメモリ最適化を提供する。エッジ開発者にとって、メモリフットプリント（memory footprint）はシステムが動作するかどうかを決定する。クラウド環境とは異なり、エッジデバイスは厳格なメモリ制限の下で動作し、CPUとGPUが限られたリソースを共有する。 非効率なメモリ使用は、ボトルネックの発生、レイテンシ（latency）の急増、またはシステム障害を引き起こす可能性がある。一方、現代のエッジアプリケーションは検出、追跡、セグメンテーション（segmentation）など複数のパイプラインを同時に実行することが多く、電力と熱の制約下で安定したリアルタイムパフォーマンスを実現するには、効率的なメモリ管理が不可欠である。 メモリ使用量の最適化は明確な利点をもたらす。開発者はオーバーヘッドを削減しコンカレンシー（concurrency）を増やすことで、同じハードウェア上でパフォーマンスを向上させることができる。これにより、大規模言語モデル（LLMs）、マルチカメラシステム、センサーフュージョンなどのより複雑なワークロードの実行も可能になる。さらに、より小さなメモリ構成に収まることでシステムコストを削減し、ボトルネックを最小化してGPU利用率を最大化することで効率性（ワットあたりのパフォーマンス）も向上する。 本ブログでは、リソースが限られたエッジシステム上でパフォーマンス、効率性、そして機能を最大化するための最適化戦略を探る。 エッジAIソフトウェアスタック エッジデバイスのランタイムソフトウェアスタックについてさらに深く掘り下げてみよう。これは完全なメモリ最適化の網羅的なガイドではないが、アイデアを刺激し、開発者が自身のスタックを改善する新たな方法を見出すための参照フレームワークである。メモリ削減の成果は、NVIDIAチームが達成した内容を示している。経験豊富なユーザーはより高い効率性を達成できるかもしれないが、他のユーザーはこの例を起点として、NVIDIA JetsonおよびNVIDIA IGXプラットフォーム上でリソースをより効果的に活用するための出発点とできるだろう。 本ブログでは、Jetson BSP（Board Support Package）とNVIDIA JetPackからなる基盤層から始め、推論パイプライン、推論フレームワーク、量子化（quantization）技術へと進む5つの主要レイヤーを探る。各レイヤーを順を追って詳しく見ていこう。 図1. NVIDIAハードウェアプラットフォームにおける典型的なエッジAIソフトウェアスタック 基盤層：ボードサポートパッケージ（BSP）とソフトウェアスタック NVIDIA Jetson Board Support Package（BSP）とNVIDIA JetPackレイヤーは、ハードウェアとインターフェースするソフトウェアスタックの基盤を形成します。これにはLinuxカーネル、デバイスドライバー、ファームウェア、および計算・マルチメディア・高速I/Oを可能にするコンポーネントを含むJetPack SDKが含まれます。このレイヤーはGPU、CPU、メモリ、周辺機器といったハードウェアの複雑さを抽象化し、上位層のサービスやアプリケーションに対して安定かつ最適化された基盤を提供します。 このレイヤーでは、未使用のサービスを無効化し、予約されたcarveout（メモリ確保領域）を回収することでメモリ節約を実現できます。これらの最適化はオーバーヘッドを削減し、コア機能に影響を与えることなく、アプリケーションのワークロード用にDRAMを解放します。以下のセクションでは、これらの最適化を有効にする主要な技術について解説します。 BSPおよびJetPackレイヤーの最適化ガイドラインは、Jetson Orin NXおよびJetson Orin Nanoで動作します。 | Knobs（最適化スイッチ） | Memory that may be reclaimed（回収可能なメモリ量） | Instructions（コマンド） | |---|---|---| | Disabling the graphical desktop, including display and UI-related services.（グラフィカルデスクトップの無効化、ディスプレイおよびUI関連サービスを含む） | Up to 865 MB（最大865MB） | sudo systemctl set-default multi-user.target | | Disabling networking, connectivity, and non-essential journaling services.（ネットワーク、接続性、および必須でないジャーナリングサービスの無効化） | Up to 32 MB（最大32MB） | sudo systemctl disable | Table 1. Memory optimization knobs at the BSP and JetPack levels（表1. BSPおよびJetPackレベルでのメモリ最適化スイッチ） NVIDIA Jetson Orin NXにおけるcarveout（メモリ確保領域）は、カーネルおよびユーザー空間の最適化と合わせて、システム全体の効率向上における重要な領域です。以下のセクションでは、これらのレイヤーを最適化する実用的な技術について探ります。 carveout（メモリ確保領域）の最適化 NVIDIA Jetson Orin NXおよびNVIDIA Jetson Orin Nanoにおけるcarveout（メモリ確保領域）は、起動時に特定のハードウェアエンジン、ファームウェア、リアルタイムサブシステム用に確保された物理メモリです。これらはLinuxやNVIDIA CUDAアプリケーションからはアクセスできず、オンチップマイクロコントローラおよびアクセラレータによって使用されます。これらは専用メモリプールとして機能し、分離、セキュリティ、決定論的な動作を保証します。パイプラインやアプリケーションの要件に応じて、一部のcarveoutを無効化してメモリ使用量をさらに最適化できます。 | Carveout（領域名） | When to disable（無効化するタイミング） | How to disable（無効化方法） | Reclaimed dram size（回収可能なDRAMサイズ） | |---|---|---|---| | CARVEOUT_DCE_TSEC | When display isn’t needed（ディスプレイが必要ない場合） | Refer to note 1 and re-flash（注記1を参照し、リフラッシュ） | 1 MB | | CARVEOUT_DCE | （該当なし） | （該当なし） | 32 MB | | CARVEOUT_DISP_EARLY_BOOT_FB | （該当なし） | （該当なし） | 34 MB | | CARVEOUT_TSEC_DCE | （該当なし） | （該当なし） | 1 MB | | CARVEOUT_CAMERA_TASKLIST | When camera isn’t needed（カメラが必要ない場合） | Refer to note 2 and re-flash（注記2を参照し、リフラッシュ） | 32 MB | | CARVEOUT_RCE | （該当なし） | （該当なし） | 1 MB | Table 2. Memory optimization knobs for various carveouts（表2. 各種carveoutのメモリ最適化スイッチ） 注記1：以下の例は、ディスプレイが必要ない場合にユーザーがメモリ最適化をどのように行うかを示しています。コードスニペットを `Linux_for_Tegra/bootloader/generic/BCT/tegra234-mb1-bct-misc-p3767-0000.dts` の `/misc/carveout/` ノード内に追加してください。 ```// ディスプレイ関連のメモリ確保領域（キャラウト） aux_info@CARVEOUT_BPMP_DCE { pref_base = ; size = ; // 0MB alignment = ; // 0MB }; aux_info@CARVEOUT_DCE_TSEC { pref_base = ; size = ; // 0MB alignment = ; // 0MB }; aux_info@CARVEOUT_DCE { pref_base = ; size = ; // 0MB alignment = ; // 0MB }; aux_info@CARVEOUT_DISP_EARLY_BOOT_FB { pref_base = ; size = ; // 0MB alignment = ; // 0MB }; aux_info@CARVEOUT_TSEC_DCE { pref_base = ; size = ; // 0MB alignment = ; // 0MB };``` `Linux_for_Tegra/bootloader/tegra234-mb2-bct-common.dtsi` の `/mb2-misc/auxp_controls@3/` ノードの内容を以下のように更新してください： ```/* DCEクラスターの制御フィールド。 */ auxp_controls@3 { enable_init = ; enable_fw_load = ; enable_unhalt = ; reset_vector = ;};``` `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 = ; size = ; // 0MB alignment = ; // 0MB }; aux_info@CARVEOUT_RCE { pref_base = ; size = ; // 0MB alignment = ; // 0MB };``` `Linux_for_Tegra/bootloader/tegra234-mb2-bct-common.dtsi` の `/mb2-misc/auxp_controls@2/` ノードの内容を以下のように更新してください： ```/* RCEクラスターの制御フィールド。 */ auxp_controls@2 { enable_init = ; enable_fw_load = ; enable_unhalt = ; };``` カーネル側の最適化 Jetson Orin、Orin NX、およびOrin Nanoプラットフォームは、NVIDIA固有のInput/Output Memory Management Unit（IOMMU）を使用して、周辺機器のDirect Memory Access（DMA）アドレス変換を処理し、物理アドレスに関係なくデバイスがシステムメモリにアクセスできるようにしています。 Linux Software I/O Translation Lookaside Buffer（SWIOTLB）は、ハードウェアIOMMUを持たないシステムや、32ビットDMAに限定された周辺機器を搭載したシステムのワークアラウンドです。OrinにはDMAアドレスを再マッピングする堅牢なハードウェアIOMMUが搭載されているため、SWIOTLBは一般的に冗長です。 SWIOTLB tuning（チューニング） SWIOTLBを必要とする特定のユースケースや非標準の周辺機器がある場合、またはカーネルログにDMA関連の問題が示されている場合は、ブート引数を使用して予約サイズを調整できます。 swiotlb=パラメータは、I/O TLBスラブの数（各2 KB）を定義します： Total size (bytes) = swiotlb_value × 2,048 Example（例）(4 MB buffer)： 4 MB ÷ 2 KB = 2,048 slabs（スラブ） Kernel command（カーネルコマンド）: swiotlb=2048 User space side optimizations（ユーザー空間側の最適化） Jetsonにおける総アプリケーションメモリには、次のものが含まれます： プロセスとシステムサービスによって使用されるCPUメモリ。 CUDA、マルチメディアバッファ、アクセラレータによって使用されるHardware（NvMap）メモリ。 両者は同じ物理メモリプールを共有するため、一方を最適化すれば他方も利益を得ます。 Reduce CPU memory usage（CPUメモリ使用量の削減） まず、最も多くのCPUメモリを消費するプロセスを特定することから始めます。GUIやオーディオコンポーネントなどのバックグラウンドサービスは大量のメモリを使用する可能性があり、本番環境では不要な場合があります。 CPUメモリ使用量の測定 procrank を使用してメモリ使用量を分析します： 出力はPSS（Proportional Set Size：比例セットサイズ）でソートされており、実際の物理メモリ使用量を反映しています。 結果に基づいて最適化し、プロセスを特定する gnome-shell or Xorg (GUI)（gnome-shell または Xorg（GUI）） pulseaudio Unused python3 processes（未使用のpython3プロセス） これらは本番環境では不要な場合が多く、メモリを解放するために無効にできます。ヘッドレスデプロイメントでは、GUIサービスを無効にすることで大幅なシステムメモリを解放できます。 Figure 2. Memory saved by disabling GUI-related services in the user space（図2. ユーザー空間でのGUI関連サービスの無効化により節約されたメモリ） Analyze and measure hardware memory usage（ハードウェアメモリ使用量の分析と測定） CPUメモリに加え、GPUおよびマルチメディアの割り当てが利用可能なメモリに影響を与える場合があります。 $ sudo cat /sys/kernel/debug/nvmap/iovmm/clients *This shows memory usage across processes using NvMap (e.g., CUDA, video pipelines).（*これは、NvMapを使用するプロセス全体のメモリ使用量を示します（例：CUDA、ビデオパイプライン）。） Optimize hardware memory（ハードウェアメモリの最適化） 大きなGPUまたはバッファ割り当てを使用するプロセスを特定します。CPU最適化と同様に、GUIパイプライン（gnome-shell、Xorg）などのサービスは不要なハードウェアメモリを消費する場合があります。これらの割り当てを削減することで、AIワークロードにより多くのメモリを解放できます。 Figure 3. Identifying processes in the user space that consume large GPU or buffer allocation memory（図3. 大きなGPUまたはバッファ割り当てメモリを消費するユーザー空間内のプロセスの特定） Inferencing pipeline（推論パイプライン） このレイヤーは、前処理、推論（inference）、後処理を通じたエンドツーエンドのデータフローを管理し、実行可能な出力を生成します。NVIDIA DeepStream などのフレームワークは、動画やセンサー入力などのストリーミングデータに対して、高性能なGPUアクセラレーテッドパイプラインを提供します。これらはデコード、バッチ処理、推論、追跡、分析を統合されたワークフローで処理し、スケーラブルな処理を実現します。このレイヤーは複雑さを抽象化し、データ移動と計算リソースの活用を最適化することで、効率的で本番環境対応のAIアプリケーションを実現します。 設定と実装の選択を通じて、メモリフットプリントを削減しパフォーマンスを向上させるために推論パイプラインを最適化する方法をご覧ください。DeepStream を例に示していますが、これらの原則はフレームワークやアプリケーション全体に広く適用可能です。 調整ノブ（Knob）：回収可能なメモリ コンテナ vs ベアメタル：最大 70 MB Python から C++ への切り替え：最大 84 MB パイプライン設定の微調整：**Tiler/OSD の無効化、FakeSink の使用：最大 258 MB 合計：412 MB 表3. DeepStream 形式の推論パイプラインでメモリフットプリントを削減するのに役立つ調整ノブ（Knobs）** DeepStream 形式の推論パイプラインにおいて、Tiler/OSD を無効化し FakeSink を使用すると、可視化には必要だがヘッドレス環境や本番デプロイメントでは不要な表示ステージが削除されます。これによりメモリが節約され、GPU 負荷が軽減され、スループットが向上します。 推論（Inference）フレームワーク LLM 向けの推論サービングフレームワークレイヤーは、本番環境での大規模言語モデルの効率的なデプロイとスケーリングに焦点を当てており、vLLM、SGLang、Llama.cpp などのフレームワークがこの分野をリードしています。これらのフレームワークは、連続バッチ処理（continuous batching）、KV キャッシュ管理、効率的なメモリ活用などの手法を通じて推論を最適化し、スループットの最大化とレイテンシーの削減を実現します。 vLLM はページドアテンション機構（paged attention mechanism）により、高スループットサービングで優れたパフォーマンスを発揮します。 SGLang は柔軟でプログラム可能な推論ワークフローを実現します。 Llama.cpp と NVIDIA TensorRT Edge-LLM は、リソース制約の厳しい環境におけるメモリ効率の高い実行のために最適化されています。 これらのフレームワークは、エッジでのローカルデプロイ時に LLM を確実にサービングするために必要なインフラストラクチャを提供します。 モデル量子化（Model Quantization） モデル量子化は、重み（weights）と活性化値（activations）を低精度データ型で表現することで、AI モデルのメモリフットプリントを削減し推論を加速するために用いられる主要な技術です。 量子化は、対象となるユースケースの明確な精度とパフォーマンス要件によって駆動されるべきです。量子化スキームを選択する前に、以下を定義してください： 許容される最小のモデル品質またはタスク精度。 目標とするスループットとレイテンシー。 デプロイメントの制約条件、特に利用可能な GPU メモリ。 これらの要件が確定したら、推奨されるアプローチは、低精度の量子化オプションを段階的に評価することです。最高精度のベースラインから始め、モデルが要求される品質閾値を満たさなくなるまで、サポートされている量子化フォーマットを下方向に確認していきます。選択する量子化のポイントは、ユースケースの精度要件を満たす最低精度であるべきです。これにより、通常、最大のメモリ節約と効率性が得られるためです。 図4. Llama.cpp上でのQwen3 4BのINT4対BF16ベンチマーク（Jetson Orin NX 16 GB）、メモリとスループットの向上を強調 低ビット量子化が許容できない性能低下をもたらす場合、量子化認識蒸留（Quantization-Aware Distillation, QAD）などの回復技術を用いて、失われた精度を復元してください。これらの手法は、デプロイメント要件を満たしつつより積極的な量子化を可能にするのに十分なモデル品質を、しばしば復元できます。 量子化レベルを選択したら、ターゲットデプロイメントの実行時メモリを最適化してください。vLLMの構成パラメータ、特にGPUメモリ利用率についてスキャンを実行し、目標パフォーマンスを維持するための最小限のメモリフットプリントを見つけてください。これにより、スループットとレイテンシの目標に向けた効率的で適切なサイズのデプロイメントが保証されます。 FP16やFP8などのフォーマットは精度とパフォーマンスのバランスを取っており、FP8はより高いスループットのために次第に使用されています。W4A16のようなより積極的なスキームは、許容できる精度を維持しつつメモリと帯域幅の要件を削減します。NVIDIA NVFP4は、ハードウェアフレンドリーな4ビット演算により効率をさらに向上させます。これらアプローチを組み合わせることで、大規模モデルやリソース制約のあるシステムに対して、より高速でコスト効果の高い推論が可能になります。サポートはJetsonプラットフォームによって異なります—詳細についてはNVIDIA Jetson製品カタログを参照してください。 調整可能なメモリ回収量の注記：Qwen3 8Bのモデル量子化をFP16からW4A16へ変換で約10 GB、Qwen3 8B。モデル量子化をBF16からINT4へ変換で約5.6 GB、Qwen3 4B。表4. モデル量子化における回収メモリ 含まれて最適化される5層ソフトウェアスタックのコンポーネントに応じて、高精度と機能の同等性を維持したまま、最大10〜12 GBのメモリ節約が可能です。 専用アクセラレータを用いたエッジでの推論の分離 Jetsonプラットフォームには、CPUやGPUから専用ワークロードをオフロードすることで効率を向上させる複数の非GPUアクセラレータが含まれています。これらには、カメラ処理用のイメージ信号プロセッサ（Image Signal Processor, ISP）、ビデオエンコード/デコード用のNVENC/NVDEC、ビジョンタスク用のNVIDIA Programmable Vision Accelerator（PVA）が含まれます。 NVIDIA cuPVA SDK は現在、Early Access（早期アクセス）の段階にあります。その機能について詳しく知りたい方は、お問い合わせください。 複数のレイヤー全体での潜在的な節約効果： レイヤーと潜在的な節約量：BSP & OS services（BSPおよびOSサービス）で約1,025 MB、Pipeline optimization（パイプライン最適化）で約412 MB、Inferencing frameworks and model quantization（推論フレームワークおよびモデル量子化）で5〜10 GB。Table 5. Memory reclaimed at various levels in the software stack（表5. ソフトウェアスタックの各段階で回収されたメモリ） 重要なポイントとして挙げられるのは、適切な量子化精度（quantization precision）の選択です。 NVFP4、INT4、W4A16 といったフォーマットは、多くの LLM（大規模言語モデル）ワークロードにおいて高い精度を維持しつつ、メモリおよびストレージの必要量を大幅に削減します。 リアルユースケース：Reachy Mini Jetson Mini Assistant これらのメモリ最適化の影響を示すため、8 GB の unified memory（統一メモリ）を備え、クラウドへの依存がない Jetson Orin Nano 上で動作するオンデバイス型会話AIロボット「Reachy Mini Jetson Assistant」を検討してください。 このアシスタントは、以下のマルチモーダル AI パイプラインを並行して実行します。視覚理解のために Llama.cpp 経由で提供され、4-bit（Q4_K_M GGUF）に量子化された vision-language model（Cosmos-Reason2-2B）、音声認識用の faster-whisper (small.en)、テキスト読み上げ用の Kokoro TTS です。これらはすべて、Reachy Mini robot SDK およびライブ Web ダッシュボードと並行して動作します。 スタック全体の最適化（ディスプレイマネージャーの無効化、headless 実行、重い Python フレームワークではなく Llama.cpp を介して VLM（Vision-Language Model）を提供、4-bit 量子化された Cosmos Reason2 2B の使用、最適化されたランタイムの選択：STT（Speech-to-Text）には CTranslate2、TTS および VAD には ONNX Runtime）により、フルパイプラインを単一の Orin Nano 8 GB システム上で動作させることができます。 より広く言えば、4-bit 量子化を Llama.cpp や TensorRT-Edge-LLM といった効率的な推論ランタイム（inference runtimes）と組み合わせることで、このメモリ予算内で最大約10Bパラメータの LLM および最大約4Bパラメータの VLM を含む幅広いモデルの利用が可能になります。テスト済みモデルの全リストは、Jetson AI Lab Models ページおよび NVIDIA Developer Forum で確認できます。 はじめに 次世代の Orin NX Edge AI プラットフォームについて詳しく学ぶ。 JetPack と DeepStream をインストールする。 NVIDIA Jetson Forum で、あなたのストーリーおよびこの投稿がどのように役立ったかを共有してください。

NVIDIA Jetson上で大規模モデルを動作させるためのメモリ効率最適化

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト