NVIDIA Nsight 開発ツールを用いたニューラル再構築パイプラインの最適化

[NVIDIA Omniverse NuRec](https://docs.nvidia.com/nurec/) は、カメラや LiDAR などのマルチセンサーデータから現実世界の環境の高忠実度な 3D レプリカを構築するためのニューラル再構成パイプラインです。これは、[自動運転車 (AV)](https://www.nvidia.com/en-us/solutions/autonomous-vehicles/) やロボティクスプラットフォームによってキャプチャされた動的シーンを、[NVIDIA Omniverse](https://www.nvidia.com/en-us/omniverse/) および関連するシミュレーションワークフロー内でレンダリング、再生、分析可能なシミュレーション対応のデジタル環境として再構成するために使用されます。 これらの再構築は、[物理 AI](https://www.nvidia.com/en-us/glossary/generative-physical-ai/) および自律システムの開発において重要な役割を果たします。エンジニアは現実世界の運転やロボティクスのシナリオをキャプチャし、環境を再構成した上で、そのシーンを検査または再生することができます。これにより、モデルの挙動をより深く理解したり、知覚結果を検証したり、合成視点データを生成したり、下流の機械学習ワークフロー用のトレーニングデータを作成したりすることが可能になります。 NuRec は、ガウシアンスプラッティングなどのニューラルレンダリング技術と、GPU 加速されたレンダリングおよびシミュレーションパイプラインを組み合わせることで、非常に現実的なシーン再構築を実現します。しかし、このレベルの忠実度には大きな計算コストが伴います。再構成およびレンダリングのワークロードには、大量のセンサーデータ、複雑な PyTorch ベースのトレーニングループ、GPU リソースを強く駆動する高度に専門化された CUDA カーネルが含まれています。 本記事では、[NVIDIA Nsight Developer Tools](https://developer.nvidia.com/tools-overview) を活用して NuRec ニューラル再構築パイプラインを最適化する例を紹介していきます。 ## パフォーマンス最適化の課題解決 NuRec ワークフローにおいてパフォーマンスは極めて重要です。なぜなら、再構築に要する時間がエンジニアの生産性に直接影響を与えるからです。一般的なワークフローでは、興味深いまたは問題のある AV（自動運転車）の実行記録を特定します。例えば、知覚や計画スタックが予期せぬ挙動を示したシナリオなどです。そして、エンジニアが可能な限り迅速にシーンを検査できるよう再構築を開始します。再構築に数時間待たされることは、反復作業とデバッグの速度を著しく低下させます。 この最適化取り組みの初期段階では、シーンや設定によっては、比較的短いキャプチャであっても再構築に 1 時間以上から数時間を要することがありました。チームの長期的な目標はさらに野心的で、30 秒間のキャプチャを約 30 秒で再構築できるリアルタイム再構築パフォーマンスの実現です。 パフォーマンスは再構築そのもの以外でも重要です。シーンが再構築された後、レンダリング専用のワークフローでは、強化学習（RL）、合成データ生成（SDG）、大規模シミュレーションのために膨大な数のフレームを生成することがあります。このスケールにおいて、わずかなパフォーマンスの向上も、GPU 使用時間とインフラコストの大幅な削減に直結します。 これらの課題に対処するため、NVIDIA のプロファイリングおよび最適化ツール、主に [NVIDIA Nsight Systems](https://developer.nvidia.com/nsight-systems) と [NVIDIA Nsight Compute](https://developer.nvidia.com/nsight-compute) を使用して NuRec ワークロードを分析し、ソフトウェアスタック全体にわたるボトルネックを特定するとともに、アプリケーションレベルのワークフローと基盤となる CUDA カーネルの両方を反復的に最適化しました。 ## Nsight Systems を用いたプロファイリングと最適化 [Nsight Systems](https://developer.nvidia.com/nsight-systems) は、CPU、GPU、ストレージ、ネットワークなどを含むワークロードのパフォーマンス挙動やリソース利用率を可視化し理解するためのプラットフォームプロファイリングツールです。多くのパフォーマンス最適化ワークフローにおける最初のステップは、Nsight Systems プロファイルを実行してベースラインを確立し、初期のボトルネックまたは改善すべき主要領域を特定することです。 トレーニングループの最適化を目的として、Nsight Systems の組み込み関数サポートと PyTorch に含まれる [NVIDIA Tools Extension SDK (NVTX)](https://github.com/NVIDIA/NVTX) を使用し、図 1 に示す順伝播（フォワードパス）の単一イテレーションにズームインしました。当初の仮説では、レンダリングカーネルがランタイムの大部分を占め、最適化の最良の出発点になると考えていました。しかし、上部に表示された CUDA ハードウェア（HW）タイムラインは、GPU の大半の時間が未利用または全く使用されていないことを示していました。上部行に青色が表示されていない点にご注意ください。また、アプリケーションは予想よりもはるかに多くの小さなカーネルを使用していることもわかりました。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/06/nsight-systems-profile-timeline-one-forward-pass-iteration.webp)*図 1. 順伝播（フォワードパス）の単一イテレーションに対する Nsight Systems プロファイルタイムライン* この初期の発見の後、時間の消費箇所と GPU が未利用となっているフェーズを特定するために、順伝播（フォワードパス）の各フェーズをさらに深く掘り下げる必要がありました。さまざまなフェーズや関数を区別するために、コードに追加の NVTX アノテーションを追加しました。新しいプロファイル（図 2）では、レンダリングが開始される前に `collect_gaussian_parameters` が時間の大部分を占めており、順伝播（フォワードパス）ごとに複数回呼び出されていることが示されました。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/06/nsight-systems-timeline-collect-gaussian-parameters.webp)*図 2. 実行時間の大部分を占める collect_gaussian_parameters の特定* さらに深く掘り下げたところ、最も時間を要しているのは interpolate 関数（4.148 ms）であり、GPU を重くする多数の小さなカーネルやメモリ操作を呼び出していることがわかりました。これは図 3 の下部にある CUDA API 行で確認できます。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/06/nsight-systems-timeline-interpolate-function.webp)*図 3. 最適化の機会として、interpolate 関数の多数の小さなカーネルを特定* 私たちは interpolate 関数下のコードを検討し、小さなカーネルを融合させて GPU により大きな作業チャンクを提出することに注力しました。その結果、これらすべての作業を単一のカーネルに凝縮することができ、interpolate 関数の実行時間を 4.184 ms から 83.81 μs（マイクロ秒）に短縮できました（図 4）。これはほぼ 50 倍の高速化です。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/06/interpolate-function-single-fused-kernel.webp)*図 4. CUDA API 行に単一の融合カーネルを備えた interpolate 関数* 次に、GPU が稼働している間に CPU が多数の小さなカーネルをキューに追加するのを遅らせていた長い cudaStreamSynchronize API（タイムライン上で緑色のバーとして表示）を特定しました。これにより、同期 API の戻り値後に小さなカーネルがスケジュールされて起動された後、上部の CUDA ハードウェア行に示されるような、GPU 利用率が不均一な状態が生じました（図 5）。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/06/nsight-systems-timline-long-cuda-stream-synch-api.webp)*Figure 5. Long cudaStreamSynchronize (bottom green row) followed by patchy GPU execution (top blue row)* 同期ポイントを1つ削除すると、その先の他のポイントがボトルネックとなりました。このプロセスを繰り返し、CPU が GPU で作業中であっても効率的に仕事をキューに追加できるまで十分な数の同期ポイントを削除しました。これにより、小さなカーネルは CPU の起動時間による制約から解放されたため、コンパクトに実行できるようになりました。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/06/nsight-systems-timeline-after-syncronization-points-removed.webp)*Figure 6. Compact GPU utilization (top blue row) after synchronization points removed* パラメータ収集に要する時間を短縮し、ボトルネックを引き起こしていた同期ポイントを削除したことで、一部のカーネル最適化に取り組むことが可能になりました。Nsight Systems を使用すれば、どのカーネルが最もホット（高負荷）であるかを特定できます。この場合、renderBackward カーネルは明らかに最有力候補でした。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/06/nsight-systems-top-kernels-by-execution_time.webp)*図 7. Nsight Systems における実行時間上位のカーネル* ## Nsight Compute を用いたカーネル最適化 [Nsight Compute](https://developer.nvidia.com/nsight-compute) は、個々のカーネルのプロファイリングと最適化に最適なツールです。このツールは、さまざまな種類のハードウェアカウンター、ソフトウェアパッチング、および計測機能を用いて、非常に微細な粒度で大量のパフォーマンスデータを収集するためにカーネルを自動的に再実行できます。また、ユーザーが問題の特定と理解を支援するための組み込みルールシステムとガイド付き分析機能を備えています。 renderBackward カーネルは、カメラデータと LiDAR データの両方の処理で使用されています。Nsight Compute でこのカーネルの複数のインスタンスをプロファイリングした結果、その稼働率（occupancy）は約 15% しかないことが明らかになり、また、どの入力データを処理しているかによって、このカーネルの動作やリソース要件が著しく異なることも判明しました。 最も実行時間の長い 3 つの renderBackward カーネルは LiDAR データに由来し、残りの 3 つはカメラデータに由来しています。これらの違いにもかかわらず、両方のケースでスレッドあたり 167 のレジスタが割り当てられていました（図 8）。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/06/nsight-compute-summary-kernel-performance-resource_usage.webp)*図 8. Nsight Compute でプロファイリングされた renderBackward カーネルの 6 インスタンス* トップの LiDAR カーネルを [Nsight Compute ベースライン](https://docs.nvidia.com/nsight-compute/NsightCompute/index.html#id8) として設定し、カメラカーネルと比較したところ、両者ともアクセスの大半が共有メモリ内で行われていたものの、LiDAR とカメラの両方のカーネルインスタンスがブロックあたり同じ量の共有メモリを静的に割り当てていたにもかかわらず、カメラカーネルは約 75% 少ないリクエストを行っていたことが自動的に明らかになりました。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/06/nsight-compute-memory-stats.webp)*図 9. LiDAR とカメラデータカーネルにおける共有メモリアクセスの違い* renderBackward カーネルがカメラデータに使用された場合と LiDAR データに使用された場合のこれらの動作の違い、およびレジスタと共有メモリの割り当てが両者で静的かつ同一であるという事実を踏まえ、次のステップとして、処理対象がカメラデータか LiDAR データかに応じてカーネルを分割することを試みました。 各バージョンのカーネルについて、チームは [launch_bounds](https://docs.nvidia.com/cuda/cuda-programming-guide/05-appendices/cpp-language-extensions.html#launch-bounds) 修飾子とブロックあたりに割り当てる共有メモリの量を用いて実験し、レジスタ割り当てを調整しました。[cudaFuncSetCacheConfig](https://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__EXECUTION.html#group__CUDART__EXECUTION) ランタイム API を使用して、両カーネルの優先設定を「より大きな共有メモリとより小さな L1 キャッシュ」とするように変更しました。 このテストと最適化の後、LiDAR とカメラのカーネルはそれぞれレジスタ割り当ての必要量を 167 から 64、128 に削減し、両方とも当初割り当てられた共有メモリの約半分でも効率的に実行可能となりました。これにより、occupancy（利用効率）が約 15% から 30-50% の範囲に向上し、全体の実行時間が大幅に短縮されました。最も長い LiDAR カーネルの実行時間は 31 ms から 18 ms に減少しています。

NVIDIA Nsight 開発ツールを用いたニューラル再構築パイプラインの最適化

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

調べる

選ぶ

サイト