Edge deployment
SLAMはクラウドでは動かない — ロボット、ドローン、ヘッドセット、あるいはスマートフォンの上で、厳しいレイテンシと電力の予算のもとで動く。**エッジデプロイメント（Edge deployment）**とは、知覚パイプライン（今日ではニューラルネットワークを含むことが増えている）を、NVIDIA Jetson、スマートフォンのSoC、XRヘッドセットなどの組み込み計算資源上でリアルタイムに動かすための技術である。
学習済みフロントエンドのエクスポート
現代のSLAMシステムは、手作りのコンポーネントをネットワークで置き換える。キーポイントにはSuperPoint、マッチングにはLightGlue/SuperGlue、密な事前情報には単眼深度ネットワークを用いる。これらはPyTorchで学習されるが、PyTorchは組み込みターゲット向けのランタイムとしては不向きである。標準的な経路は次の通り。
-
ONNXへのエクスポート — フレームワーク中立なグラフ形式。このステップで問題が早期に表面化する。動的な形状（キーポイント数が可変！）、未サポートの演算、制御フローはすべて注意が必要である。
torch.onnx.export( model, dummy_image, "superpoint.onnx", input_names=["image"], output_names=["scores", "descriptors"], dynamic_axes={"image": {2: "height", 3: "width"}}, ) -
TensorRTでコンパイル — NVIDIAの推論最適化器はレイヤーを融合し、高速なカーネルを選択し、FP16またはINT8に量子化することで、Jetson/RTX GPUで大幅な高速化を実現する。
trtexec --onnx=superpoint.onnx --fp16 --saveEngine=superpoint.engineプラットフォームごとに代替手段が存在する。ポータブルなベースラインとしてのONNX Runtime、Apple製ハードウェア向けのCore ML、Androidスマートフォン向けのTFLite/NNAPIなどである。
-
C++パイプラインへの統合 — コンパイルされたエンジンはSLAMフロントエンドから呼び出され、元の検出器/マッチャーを置き換える。理想的には、Jetsonのような統合メモリデバイス（CPUとGPUが物理メモリを共有するため、うまく配線されたパイプラインはフレームを一切コピーしない）上でゼロコピーの画像入力を行う。
実践における量子化。 FP16はGPU級のエッジハードウェアではほぼ無償で得られる高速化である。INT8は代表的な画像に対するキャリブレーションパスが必要である。SLAMフロントエンドにおける「代表的」とは自分のデプロイシーンを意味し、重要なチェック項目は分類的な精度スコアではなく、下流の品質（マッチングの内点率、トラッキングの安定性）である。Jetson級のモジュールにはさらに、対応するネットワークをGPUからオフロードできるDLAアクセラレータコアが搭載されている。
Jetsonでのベンチマーク
デスクトップGPUでの数値はエッジについてはほとんど何も語らない。Jetson級のデバイスでは、エンドツーエンドでベンチマークを行う。
- フレームごとのレイテンシ。前処理（リサイズ、正規化）、ホスト/デバイス間のコピー、後処理を含む — ネットワーク呼び出しだけではない。
- 熱負荷下での持続スループット — 数分間のウォームアップ後に測定する。組み込みデバイスはスロットリングするため、冷えた状態でのベンチマークは現実を過大評価する。
- 電力モード — Jetsonの性能は選択された
nvpmodel電力プロファイルとクロック設定（jetson_clocks）に依存する。数値がどのモードで得られたかを報告し、tegrastatsでライブの利用率を監視すること。 - SLAMに残る余力 — フロントエンドのネットワークは、トラッキング、マッピング、ロボットスタックの他の部分とSoCを共有する。残されたCPUの余裕とメモリ帯域幅も結果の一部である。
正直な指標は、対象デバイス上で対象の電力モードにおける、熱くなった状態で測定したフルパイプラインのフレームレートである。
よくある落とし穴
- INT8量子化後の精度低下 — 代表的な画像でキャリブレーションし、エンドツーエンドでマッチング品質を再確認すること。
- 動的な出力サイズ — キーポイント検出器は可変数の点を出力する。エクスポート時にトップKの予算を固定するか、ランタイムで動的な形状を明示的に扱う必要がある。
- 前処理の不一致 — 学習時とデプロイ時で正規化定数、リサイズの補間方法、色順序が異なると、エラーなしに静かに品質が劣化する。
- 推論だけをベンチマークすること — スライドで「30 FPSに到達」と言いながらロボット上では達成できない典型的な原因である。
SLAMにおける意義
「論文では30 FPSで動く」と「自分のロボットで動く」の間のギャップこそが、まさにこのトピックである。学習済みフロントエンドは、トラッキングとマッピングのスレッドと並んでエッジの予算に収まってこそ、実システムでの地位を得る。デプロイの制約（FP16/INT8、固定された入力サイズ、限られたメモリ帯域幅）は、しばしばSuperPointと、より軽量な検出器（例えばXFeat）のどちらを選ぶかを左右する。デバイス上でプロファイルし最適化できるエンジニアこそが、SLAMを実際に出荷できる人材である。