Sentisだけじゃない！Unity上で高速なオンデバイス推論を実現するアプローチのご紹介
310 Views
November 17, 25
スライド概要
Sentisだけじゃない！Unity上で高速なオンデバイス推論を実現するアプローチのご紹介 / 竹村 伸太郎 / CA.unity #10
DeNA が社会の技術向上に貢献するため、業務で得た知見を積極的に外部に発信する、DeNA 公式のアカウントです。DeNA エンジニアの登壇資料をお届けします。
（ダウンロード不可）
関連スライド
各ページのテキスト
CA.unity #10 Sentisだけじゃない！Unity上で高速なオン デバイス推論を実現するアプローチのご紹介 株式会社ディー・エヌ・エー IT本部AI・データ戦略統括部 データ基盤部 ゲームエンタメグループ 竹村 伸太郎 © DeNA Co., Ltd. 1
本発表で皆様に持ち帰ってほしいこと ● ● © DeNA Co., Ltd. Unityにおけるオンデバイス推論の選択肢は、Sentisだけとは限りません ○ DeNAではTFLiteやONNX Runtimeを現役のスマホアプリで活用してます ○ Unity公式サポートのSentisに拘らない理由は、ずばり技術選択肢の自由度です ○ 加えて実プロダクトで採用しているカスタムビルドCIをOSSとして公開中 ○ 「いざという時Sentis以外の選択肢もある」とだけ知って頂けたら十分です！ それでも Unity Sentis (or Barracuda) に拘る事情がある貴方へ ○ 例えば、PCやスマホ前提コードの家庭用ゲーム機移植は大変ですよね… （業界歴長いので、PlayStation/Xbox/Switchへの移植作業を経験してます） ○ 「最新のPyTorchでTorchDynamoを使おう」これだけ覚えて頂けたら十分です！ 2
自己紹介 ● 竹村 伸太郎 (たけむら しんたろう) ○ 大手ゲーム開発会社を経て、2020年DeNA中途入社 ○ 近著（共著）に日経BP「クラウドデータベース入門」 2025年04月21日発行 ● © DeNA Co., Ltd. DeNA入社後の発表 ● CEDEC 2021/2023/2025 ● Unity公式カンファレンス SYNC 2022 ● DeNA公式カンファレンス TechCon 2022/2023 ● CA.unity は初となります🙇 3
SYNC 2022資料より抜粋 発表時間が限られているため、過去の登壇資料から抜粋してお伝えします もし興味ございましたら、 Unity Learning Materials で全資料をご覧ください © DeNA Co., Ltd. 4
5 ポータブルな機械学習モデルを目指して ● PyTorchやLightGBMは、ONNXという汎用フォーマットで出力可能 ● ○ この時点でONNX Runtime上で動作させることは出来る ○ が、それ以外の例えば Unity Barracudaでは制限のため多くは動作しない 例えば、以下のような工夫が必要 ○ ONNX出力時、互換性に配慮したopsetを指定 (target_opset = 9など) ○ 未対応のoperatorは、他のoperatorを使って代用 ■ ● 開発初期では、LightGBMを用いて必要な特徴量を探る ○ © DeNA Co., Ltd. register_custom_op_symbolic の使用など LightGBMをBarracuda用に変換する実装例を、次スライドで掲載 5
6 LightGBM学習モデルをBarracuda用に変換する実装例 @symbolic_helper.parse_args("v", "i", "v", "v") def gather_alt(g, self, dim, index, sparse_grad=False): dtype = self.type().scalarType() values = g.op("Constant", value_t=torch.LongTensor([0, 1])) # Barracudaでは動的な入力を受け付けないため、計算済みの固定値を代入 depth = torch.asarray([42]) # size(g, self, g.op("Constant", value_t=torch.LongTensor([dim]))) # BarracudaのOneHot operatorはaxis_iが設定できないため、Transposeで代用 index = g.op("Cast", g.op("OneHot", index, depth, values, axis_i=-1), # axis_i=dim to_i=symbolic_helper.cast_pytorch_to_onnx[dtype]) index = g.op("Transpose", index, perm_i=[0, 2, 1]) mul = g.op("Mul", symbolic_helper._unsqueeze_helper(g, self, [dim + 1]), index) return symbolic_helper._reducesum_helper(g, mul, axes_i=[dim], keepdims_i=0) register_custom_op_symbolic('::gather', gather_alt, 9) model = lgb.LGBMRegressor(num_leaves=8) X = np.array(np.random.rand(10000, 28), dtype=np.float32) y = np.random.uniform(size=10000) model.fit(X, y) onnx_model = hummingbird.ml.convert(model, "onnx", X, extra_config=dict(onnx_target_opset=9)) © DeNA Co., Ltd. 6
6 さらなる応用へ ~Barracudaの活用~ ● 大前提としてGPU推論は、Barracudaに限らず機械学習モデルの制約が大きい ● ○ 発表時間の都合で詳細割愛するが、端末独自プロセッサも同様に制約大 ○ まずはTFLiteで大局を掴み、シンプルなモデルに移行出来るか検討 BarracudaはUnity上のGPUリソースとの親和性が最も高い推論ランタイム ○ 入出力テンソルがTexture or ComputeBuffer上にある時、真価を発揮する ○ WorkerFactory.Typeを指定して必ずCPU/GPU双方でProfilingしよう ComputeBuffer Execute(tensor as input) ReferenceComputeOps ComputeBuffer .buffer Tensor IWorker Tensor Pin(tensor as input) Texture2D © DeNA Co., Ltd. .PeekOutput() Texture2D .ToRenderTexture() 7
CEDEC 2023資料より抜粋 発表時間が限られているため、過去の登壇資料から抜粋してお伝えします もし興味ございましたら、CeDIL に登録（無料）の上、全資料をご覧ください © DeNA Co., Ltd. 8
低遅延AIの開発事例 #1 リアルタイム動画像認識 ● 顔の位置や向き・ブレンドシェイプを、動画像から深層学習で推定（下左図参照） ● 新感覚 Vtuber アプリ IRIAM 2023年4月18日アップデート版より採用 ● 実機上で動くエッジAIとして、高精度かつ低遅延で顔認識する技術[1]を自社開発 1フレームの 推論速度 FPS 換算 < 16ms 60+ iPhone 7 < 16ms 60+ M1 MacBook < 6ms 120+ 位置 X: -75 Y -20 回転 X: -13 Y:-6 Z:-2 Galaxy A32 5G 口の開き具合 : 0.544 左目の閉じ具合 : 0.393 ・・・ TechCon 2023資料[1]より © DeNA Co., Ltd. 2021年発売 ¥31,190 9
既存技術の課題 ● Apple ARKit - Face Tracking ○ ● 動作環境の制約が大きい ■ 当然だがAndroid非対応 ■ iPhone 7~8世代非対応 Google MediaPipe - Attention Mesh ○ 精度に課題あり（右図参照） ■ ● 薄目や眉毛の検出が不安定 上記課題を克服するエッジAIを開発 ○ 詳しくは 04 実装編 にて 左: Mediapipeの眉毛・薄目検出失敗例[1] © DeNA Co., Ltd. 10
本章で伝えたいこと ● ● 実機向け最適化と一口に言っても、技術的選択肢は下記条件に左右される ○ 動かしたいプラットフォーム・OS/ABIバージョン ○ 提示可能な最低動作環境/推奨動作環境 ○ 組み込み先アプリの性質（CPU/GPU負荷など） ○ 機械学習モデルで使われているオペレータの種類 ○ 組み込み担当者のスキルセット 同じ機械学習モデルでも組み込み方次第で、実行時間は数倍〜数10倍と変わる 本章では、そんな厄介だが重要な実機組み込み技術をコンパクトに伝えたい © DeNA Co., Ltd. 11
推論処理の実機向け最適化 最適化の取り組みをPDCAサイクルに準え、ステップ順に勘所を解説します PDCAサイクル ● Plan | 課題整理と実装計画 ○ ● Do | 実機への組み込み ○ ● Check | 実機上での負荷測定 ○ ● Act | 負荷分析と最適化 ○ © DeNA Co., Ltd. 12
Plan ~ 実機固有の課題を整理 モバイル端末の実装で特に注意を要するのは、実は消費電力と発熱 ● ○ 消費電力 大＝バッテリーが早く枯渇するため、実用性に懸念 ○ 消費電力 大＝発熱が著しいと、サーマルスロットリングで結果的に性能低下 高負荷な処理ほど、電力効率を意識した実装が求められる ● ○ 客観的評価としては、LLaMA 13BのGPU(MPS)/CPU(C++)実装が参考になる ■ 処理速度・メモリ消費は互角だが、電力効率は3倍以上GPUがCPUより上 Implementation Total run time 256 tokens Tokens/s Peak memory use Peak SoC temperature Peak SoC Power consumption Tokens per 1 Wh LLAMA_MPS (13B fp16) 75 s 3.41 30 GB 79 °C 10 W 1,228.80 llama.cpp (13B fp16) 70 s 3.66 25 GB 106 °C 35 W 376.16 jankais3r/LLaMA_MPSより LLaMA 13BのApple M1 MAX上の GPU(MPS)とCPU(C++)の推論速度・電力効率比較 © DeNA Co., Ltd. 13
Plan ~ 普及端末の現状を整理 ● iOSと異なりAndroidは、普及端末でGPU推論ができるとは限らない ○ ComputeShaderが扱えない端末は、一般的に推論ランタイムがGPU非対応 ※Unity Barracudaは例外だが、課題は多い。詳細はSYNC 2022講演[6]を参照 ○ ● OpenGL ESの場合 3.1未満は望み薄。Googleの最新統計によればその割合は 14% GPU推論を本命視する場合、すべてのAndroid普及端末は救えない Version Distribution Version Distribution GL 2.0 6.51% None 15.0% GL 3.0 7.35% Vulkan 1.0.3 8.0% GL 3.1 5.90% Vulkan 1.1 77.0% GL 3.2 80.24% Android Developersより 2023-01-06から7日間のアクティブ端末のグラフィックスAPI統計 © DeNA Co., Ltd. 14
Plan ~ 実機移植時の課題を整理 #1 実機で推論する数多くの手段があり、動作条件で優劣は変わるが、検証時間は有限 ● ○ 故に、先人が残した推論ベンチマーク結果が頼りになる ○ TheWebConf 2022 論文によれば、TFLiteの性能がCPU/GPU推論ともトップ ■ TFLite = Tensorflow Liteの略。論文での検証端末はAndroidに限られる ■ プラットフォーマーが作るランタイムが強いという、予想通りの結果 TFLite PyTorch Mobile ncnn MNN Mace SNPE CPU 84 20 52 48 3 3 GPU 80 - 12 49 5 64 A Comprehensive Benchmark of Deep Learning Libraries on Mobile Devices[7] より、 15種類のMLモデル x 10種類の端末のベンチマークで最高性能を示した深層学習ライブラリの統計 © DeNA Co., Ltd. 15
Plan ~ 本ステップの趣旨 ● 目的 ○ ● 前述の課題を整理し、実機で動かす推論ランタイムを絞り込む 手順 ○ 動かすモデルが、推論ランタイムの対応フォーマットに変換できるか検証 ■ © DeNA Co., Ltd. 対応フォーマットとは、TorchScript Model, ONNX, TFLite などを指す ○ 推論ランタイムが、正しく推論できることをから確認 ○ すべての確認を終えたら、実装計画を立てる 16
Plan ~ 本ステップの勘所 #1 ● 最適化サイクルを回す過程で、推論ランタイムを変えることはある ○ ● ● © DeNA Co., Ltd. 重要なのは、いかに変化に強いコードを書くか 弊社の開発事例で採用したアプローチ ○ 複数の推論ランタイムを透過的に制御する、汎用ライブラリを自社で開発 ○ 現時点では、C#用（Unity/Non Unity）のインターフェースを提供 ○ Unity向け最適化（NativeArrayによるGC削減など）も施し、実行性能を最大化 NVIDIA Triton Inference Serverの実装が参考になる ○ Tensorflow, PyTorch, ONNX Runtimeなどを透過的に扱え、設計思想が近い ○ Dynamic Batchingに代表されるスループット重視のC++実装で、学びが多い 17
Plan ~ 本ステップの勘所 #2 ● モデル学習を担う研究開発メンバーとは、下記の点を合意形成するのが望ましい ○ モノシリックなnn.Moduleではなく、機能単位でこまめに分割 ■ ○ ディレクトリ構成や、Pythonパッケージ管理方法の統一 ■ ● © DeNA Co., Ltd. モデル変換失敗時のトラブルシュートが容易になる チーム開発におけるコミュニケーションコストを削減 弊社の開発事例で採用したアプローチ ○ Ascender という研究開発用のレポジトリテンプレートを参考にした ○ パッケージ管理をPoetryに統一し、相性の悪いものはpipで補完 18
Plan ~ 顔認識AI開発では、どう実装計画を立てたか ● サービス側とのヒアリングを通じて、アプリの性質を分析 ○ 描画アセット次第だが、基本的にCPUバウンド ■ ○ ● © DeNA Co., Ltd. CPU負荷が高いユースケースがある一方で、GPU負荷は低い 🙆 配信側の動作端末は良い意味で絞られている ■ Android 8.0以上 arm64-v8a限定、multi-threaded rendering有効 🙆 ■ iOS11以上 iPhone6s以降 🙆 推論ランタイムを確定し、本格的な実機組み込みに着手 ○ GPU推論の性能や、拡張容易なC++実装が決め手で TFLite に決定 ○ NNAPIとCoreMLは、最低動作環境でメリットが活きないと判断し見送り 19
推論処理の実機向け最適化 最適化の取り組みをPDCAサイクルに準え、ステップ順に勘所を解説します PDCAサイクル ● Plan | 課題整理と実装計画 ○ 実装課題を整理し、実機上で動かす推論ランタイムを絞り込む ● Do | プロトタイプの開発 ○ ● Check | 実機上での負荷測定 ○ ● Act | 負荷分析と最適化 ○ © DeNA Co., Ltd. 20
Do ~ 本ステップの趣旨 ● 目的 ○ ● 実機上の負荷測定が可能なプロトタイプを開発する 手順 ○ 立てた実装計画を元に、下記ログを記録できるプロトタイプを開発 ■ ■ トレースログ ● 次スライドで解説する、各処理の実行時間を測定 ● 実アプリで想定される頻度で一定回数実行し、その統計を記録 プロファイリングログ ● © DeNA Co., Ltd. 負荷試験中、メモリ使用量などの指標を一定間隔で観測し記録 21
Do ~ 本ステップの勘所 #1 ● ● 実機組み込みの際、下記処理のトレースログを残すことが望ましい ○ 入力処理（前処理で得たテンソルをコピー or マッピング） ○ 推論処理 ○ 出力処理（後処理に使うテンソルをコピー or マッピング） プロセッサやAPIをまたぐテンソル入出力が主な負荷になるケースがある ○ 例：DirectX 12 ⇔ CUDA, OpenGL/ES ⇔ OpenCL ○ 通常推論ランタイム側が吸収するため、コーディング時に気づきにくい ○ この負荷を早期に検出するためにもトレースログの記録が必要 ■ © DeNA Co., Ltd. Shared MemoryやSSBOの活用といった、次のアクションに繋げる 22
Do ~ 顔認識AI開発では、測定結果からどう対処したか ● トレースログからGPU推論のパフォーマンスが十分でないことが判明 ○ CPUとGPUの間をまたぐリソースの同期にボトルネックの存在を確認 ○ ShaderとSSBOを活用することで、ボトルネックを解消した CPU ■ 前処理・後処理は極力Shaderで行いGPU内で完結させる ■ SSBOでComputeBufferを入出力テンソルとして扱うことでゼロコピー化 前処理 後処理 同期 GPU CPU 同期 推論 GPU 前処理 SSBO 開発初期の処理フロー © DeNA Co., Ltd. 推論 後処理 SSBO 最適化後の処理フロー 23
Do ~ 本ステップの勘所 #2 ● 弊社の開発事例で採用したアプローチ ○ ○ ○ © DeNA Co., Ltd. トレースログの一元化 ■ Cloud StorageのV4署名プロセスを通じて、実機からセキュアにログ転送 ■ 実装は、Firebase Unity SDKより軽量な自社ライブラリを活用 プロトタイプビルドの自動化 ■ 負荷測定はPlay Mode testとして実装され、専用ビルドスクリプトを用意 ■ Unity+Xcodeによるapk/ipaファイルのビルドをCLI(Makefile)化 ■ Unity Build Serverが動く、GitHub Actions Self Hosted Runnerの導入 ログの一元化とビルド自動化により、後の負荷分析を効率化 24
推論処理の実機向け最適化 最適化の取り組みをPDCAサイクルに準え、ステップ順に勘所を解説します PDCAサイクル ● Plan | 課題整理と実装計画 ○ 実装課題を整理し、実機上で動かす推論ランタイムを絞り込む ● Do | プロトタイプの開発 ○ ボトルネックを正確に追跡できるよう、ログの記録と一元化を徹底する ● Check | 実機上での負荷測定 ○ ● Act | 負荷分析と最適化 ○ © DeNA Co., Ltd. 25
Check ~ 本ステップの趣旨 ● 目的 ○ ● 手順 ○ ● Doステップで実装した負荷測定アプリを端末にデプロイする 留意点 ○ © DeNA Co., Ltd. 動作条件に該当する複数端末で、負荷を測定する 本ステップは、継続的インテグレーションの一環としてリリース後も継続 ■ モデルのアップデートに伴う動作確認 ■ OSのアップデートや新端末の発売に伴う動作確認 26
Check ~ 本ステップの勘所 #1 ● 実機の保有を前提にしたモバイルテストは、カバレッジの担保が困難 ○ Android ■ 機種が多く、かつ最新機種であっても性能差が大きい ● ○ iOS ■ ● © DeNA Co., Ltd. 古いiOSのバージョンに戻せない 実機を直接操作しての、モバイルテストはそもそも非効率的 ○ ● CEDEC 2019 講演資料[8] に詳細な記述あり 加えて、電源管理・資産管理などのコストがかかる モバイル端末での負荷測定をスケールする仕組みを考えよう 27
Check ~ 本ステップの勘所 #2 ● 弊社の開発事例で採用したアプローチ ○ Google CloudのFirebase Test Labsを活用 ○ AWS, GCP, Azure それぞれのサービスを検証し、Unityとの相性が最良と判断 ■ ● 詳しくは DeNA Engineers’ Blog[9]を参照 Firebase Test Labsの特長 ○ Android/iOSの新旧物理端末を網羅 ■ ○ 対応端末のメーカーは10社以上 gCloud CLI対応でCIと連携が容易 DeNA Engineers' Blog[9]より © DeNA Co., Ltd. 28
推論処理の実機向け最適化 最適化の取り組みをPDCAサイクルに準え、ステップ順に勘所を解説します PDCAサイクル ● Plan | 課題整理と実装計画 ○ 実装課題を整理し、実機上で動かす推論ランタイムを絞り込む ● Do | プロトタイプの開発 ○ ボトルネックを正確に追跡できるよう、ログの出力を徹底する ● Check | 実機上での負荷測定 ○ 継続的インテグレーションを意識して、負荷測定の効率化を図る ● Act | 負荷分析と最適化 ○ © DeNA Co., Ltd. 29
Act ~ 本ステップの趣旨 ● 目的 ○ 測定した負荷を分析し、必要であれば高負荷の原因を精査し対処する ■ ● © DeNA Co., Ltd. 本講演では、高負荷の対処が必要なケースを想定 手順 ○ 次スライドで解説する前準備で、補足データを確保 ○ 既知モデルの測定結果と比較し、高負荷の主因を洗い出す ○ 主因が推論の実行効率であれば、最適化を試みる 30
Act ~ 前準備 #1 ● 動かすモデルのMACs（積和演算の数）を算出する ○ ○ MACsは下記ツールなどで算出可能 ■ DeepSpeed ■ onnx-tool 動的なループを含むモデルなど、算出困難なケースもあるが本講演では割愛 Model MACs(M) GPT-J 1 layer 173,398 RealESRGAN 73,551 rvm_mobilenetv3 4,289 onnx-tool より、既知モデルのMACsを抜粋 © DeNA Co., Ltd. 31
Act ~ 前準備 #2 ● 比較用モデルのMACsと推論速度を把握する ○ ○ 比較用モデルは、以下の観点で選定すると良い ■ 推論ランタイムの性能を発揮しやすい、シンプルな構造である ■ 信頼に足る推論ランタイムでの測定結果が公開されている 算出困難なケースを除けば、ひとまずMobileNet V1のTFLite測定値で良い Model MobileNet_v1_1.0_224(float) MACs(G) Device CPU GPU 0.56 Pixel 3 23.9 ms 6.45 ms 14.8 ms 3.40 ms 486.0 ms 93.0 ms 309.0 ms 54.4 ms iPhone XS Inception_V4 13.16 Pixel 3 iPhone XS TensorFlow > Learn For Mobile & Edge > Models > Performance measurement より抜粋 © DeNA Co., Ltd. 32
Act ~ 本ステップの勘所 #1 ● 動かすモデルの期待値 y = x / x0 * y0 を求める ○ ● x = 動かすモデルのMACs(G) y = 動かすモデルの推論速度(ms) 期待値 x0 = 比較用モデルのMACs(G) y0 = 比較用モデルの推論速度(ms) 測定値 ← 同一の動作環境を想定 期待値と測定値を比較し、高負荷の要因を大別する ○ 乖離が小さい（期待値 ≒ 測定値）場合 ■ ○ 乖離が大きい（期待値 ≫ 測定値） 場合 ■ © DeNA Co., Ltd. 絶対的な計算量が多い 推論の実行効率が低い 33
Act ~ 本ステップの勘所 #2 ● ● © DeNA Co., Ltd. 絶対的な計算量が多い場合 ○ 推論処理の最適化で、改善できる余地は乏しい ○ 理論編で示したような、モデル構造の抜本的見直しを検討 推論の実行効率が低い場合、下記の要因が考えられる ○ 推論ランタイム側の最適化が十分でないオペレータを多用 ○ 大量の非効率なオペレータが、キャッシュヒットや並列処理を阻害 34
Act ~ 本ステップの勘所 #3 ● 推論ランタイム側の最適化が十分でないオペレータを多用しているケース ○ 典型的な例は、Conv1d/ConvTranspose1d ■ 利用頻度が低いオペレータは、概して最適化のサポートが貧弱 ■ ONNX Runtimeをモバイル端末で動かした場合 ■ ● ランタイム内部の最適化で、テンソル構造をNCHWcに置き換え ● この最適化は、Conv2dには適応されるが、Conv1dは対象外 Google XNNPACKやApple BNNSをアクセラレータに指定した場合 ● ● 弊社の開発事例で採用したアプローチ ○ © DeNA Co., Ltd. どの推論ランタイムも確認した範囲で、Conv1dは最適化の対象外 Conv*1d を Conv*2d に PyTorchのモデル定義時に置き換えて高速化 35
Act ~ 本ステップの勘所 #4 ● 大量の非効率なオペレータが、キャッシュヒットや並列処理を阻害するケース ○ ● 典型的な例は、ONNX(NCHW)→TFLite(NHWC)変換 弊社の開発事例で採用したアプローチ ○ 複数の変換手段を検証し、実行効率が最も高い手法を採用 画像入力モデル 推論速度 推論速度 最適化前 最適化後 MobileNetV2 20.0 ms 7.5 ms MobileNetV3Small 8.1 ms 2.3 ms DeNA TechCon 2023[1] より、元モデル構造、NHWC変換後（最適化前/後）のモデル構造、推論速度比較表 © DeNA Co., Ltd. 36
Act ~ 更なる最適化 #1 ● ● 推論ランタイムの内部では様々な最適化が行われている ○ 行列×行列乗算(GEMM)のSIMD命令を用いた高速化 ○ 頻出するオペレータ組み合わせに特化した計算量削減（Conv2D+BNなど） ○ Arena Allocationに代表される、データの連続的なメモリ配置 最適化による、実行効率の改善率 ○ XNNPACKのConv2Dは、C++のNaive実装（8重ループ）より50倍以上高速[10] 推論速度 C++ Naive Conv2D NHWC FP32 3.20 sec XNNPACK Conv2D NHWC FP32 0.06 sec XNNPACKを直接使ってみた[10] より抜粋 © DeNA Co., Ltd. 37
Act ~ 更なる最適化 #2 ● ● XNNPACKは、数々の推論ランタイムの採用実績からも、性能の高さが伺える ○ LibTorch, ONNX Runtime, TFLite など ○ 一方どのオペレータが最適化されるかは、ランタイム側の裁量に依存 より発展的な話題として、LSTMやGRUの最適化を考える ○ これらも内部でGEMMを使うため、XNNPACKよる高速化は期待できる ○ まだ結論は出ていないが、下記アプローチを検討中 ■ PyTorchのLSTM/GRUオペレータのONNX出力をオーバーラップ ● ■ © DeNA Co., Ltd. LSTM/GRUを、XNNPACKが対応するオペレータの集合に分解 推論ランタイムをXNNPACKで実装したカスタムオペレータで拡張 38
推論処理の実機向け最適化 最適化の取り組みをPDCAサイクルに準え、ステップ順に勘所を解説しました PDCAサイクル ● Plan | 課題整理と実装計画 ○ 実装課題を整理し、実機上で動かす推論ランタイムを絞り込む ● Do | プロトタイプの開発 ○ ボトルネックを正確に追跡できるよう、ログの出力を徹底する ● Check | 実機上での負荷測定 ○ 継続的インテグレーションを意識して、負荷測定の効率化を図る ● Act | 負荷分析と最適化 ○ 高負荷の主因を大別し、実行効率が問題ならモデル出力に手を加える © DeNA Co., Ltd. 39
CEDEC 2025資料より抜粋 発表時間が限られているため、過去の登壇資料から抜粋してお伝えします もし興味ございましたら、CeDIL に登録（無料）の上、全資料をご覧ください © DeNA Co., Ltd. 40
オンデバイス推論の全体的な流れ オンデバイス推論は様々なエコシステムで支えられ、多くの場合ONNXがハブとなる 深層学習フレームワーク PyTorch TensorFlow ・モデル学習 ・モデル評価 深層学習ツールチェーン TorchDynamo ・学習済みモデルの変換 ・モデルフォーマットの提供 ONNX model 推論ランタイム ONNX Runtime CoreML Unity Sentis Unreal Engine NNE ・変換済みモデルの読込み ・オンデバイス推論の実行 © DeNA Co., Ltd. ONNX Script AI Edge Torch TFLite model LiteRT (TFLite) 41
推論ランタイムの各プラットフォームにおけるサポート Platform Processor Win CPU LiteRT (TFLite) GPU CUDA Graphics API macOS CPU Direct ML ✓ GPU ✓ ✓ Unity Sentis UE5 NNE ✓ CPU Metal ✓ ExecuTorch ONNX Runtime iOS GPU Android ANE ✓ ✓ *1 ✓ ✓ ✓ *1 ✓ *1 ✓ ✓ ✓ ✓ ✓ *1 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ *1 ✓ ✓ ✓ GPU Open Vulkan GL ES Metal Android NNAPI Apple CoreML CPU DSP NPU *1 *1 ✓ *1 *1 *1 ✓ ✓ ✓ ✓ ✓ オンデバイス推論における技術的選択肢のプラットフォーム・プロセッサ対応表 (2025年4月調べ) *1 NNAPIやQNN、CoreMLを内部的に呼び出すことで対応を謳っているもの © DeNA Co., Ltd. 42
オンデバイス推論における技術選定 初手は汎用性の高い技術を選択し、モデル成熟後に目的特化型を検討することを推奨 汎用性・拡張性重視 ONNX Runtime ゲーム用プラットフォームに特化 Unity Sentis Unreal Engine NNE 広く普及した汎用フォーマットのONNXモデ ルを正しく推論できるマスモニ的存在 ✓ 商用ゲームエンジンの公式機能として、家 庭用ゲーム機のサポートされるのが強み ✓ LLMなど大規模なモデルに特化 スマートフォンや組込み機器に特化 ExecuTorch LiteRT (TFLite) AOT採用でモデルをパースするオーバヘッ ドが省かれるため、大規模推論向き ✓ © DeNA Co., Ltd. CoreML GoogleやAppleが提供しており、NPUやANE など実機固有のプロセッサを活用できる ✓ 43
目的特化型の技術的選択肢で発生しがちな問題 ● モデル更新に起因するトラブルの一例 ○ ○ 動かなくなった原因 1. ONNXモデルにGRU オペレーターを追加した 2. GRU未対応のUnity Sentis *2で動かそうとした 考えられる解決案 model = nn.GRU(10, 20) x = torch.randn(5, batch, 10) x_hidden = torch.zeros(1, batch, 20) outputs = model(x, x_hidden) torch.onnx.export(model, …) *2 公式マニュアルより2025年4月調べ 1. GRUを相当の計算を、自前でハードコード 2. GRUを使わないモデルを考案し、学習・評価をやり直す 3. コード・推論結果を変えずにSentisで動くONNXに変換 影響範囲を最小に留めつつ、簡単な方法で解決するにはどうしたらよいか？ © DeNA Co., Ltd. 44
移植性の高いモデル出力 ● 結論から言えば、ONNXモデル出力方法の修正（案3）で対処可能 ○ 鍵はPyTorch 2.7におけるTorchDynamoとONNX Scriptの2種OSS間連携 ○ エコシステムの進化とともに移植性の高いモデル出力が容易になりつつある TorchScriptベース のONNX出力結果 TorchDynamoベース のONNX出力結果 構造はシンプルだが、 推論ランタイム側に GRU対応が求められる Lowering Passが挟まる ことで、GRUは展開さ れ、移植性の高いモデ ルに変換されている 拡大図 次のステップとして、モデル更新の不確実性に強い仕組みを考えたい © DeNA Co., Ltd. 45
実験管理の一環としてのモデルチェック機構の導入 ● 本節で述べる実験管理とは、学習前後のちょっとしたバッチ処理と記録・可視化 ○ 学習が再現できる形で記録され、成果物と紐付けされるだけで十分価値あり ○ ちょっとした記録・可視化はほぼ無料で使えるクラウドサービスに頼ろう 弊チームが採用したVertex AI Experimentsや、他にはAzure MLなど ■ ● 本質は学習前後のバッチ処理。コード同様にモデルも自動テストすることが大事 実験アーカイブ 実験メタデータ 実験成果物 ・学習コード ・マスターデータ ・パラメータ ・メトリクス ・学習途中モデル ・デプロイ用モデル Cloud Storage 学習前バッチ処理 © DeNA Co., Ltd. Vertex AI Experiments 学習途中バッチ処理 Cloud Storage 学習後バッチ処理 46
モデルのテストで重要なこと 出来るだけ動的な中間処理を介さず、実機上の挙動に一致させることが重要 ● ○ 推論ランタイムの中には動作環境に合わせて動的な最適化を行うものがある ■ ○ 挙動一致、初期化時間短縮の観点から、静的な最適化が望ましい 加えてモデルをバイナリレベルで無加工なまま推論できることが望ましい ONNX Runtimeを使う場合は、ORT(Format)モデルの採用で上記条件を満たせる ● ○ ORTモデルはONNXモデルからCLIで簡単に静的最適化した上で変換できる。 ONNX Runtimeを通じて、C++/C#から利用可能。 シリアライズ方式 初期化 ONNXモデル Protocol Buffers 低速 ORTモデル Flat Buffers 高速 © DeNA Co., Ltd. ONNX モデル ORT モデル パース 処理 動的な 最適化 初期化 推論 OK 推論 OK 47
オンデバイス推論をサポートする弊社OSSのご紹介 ● ONNX Runtimeはカスタムビルドを行うことで軽量化・省メモリ化できる ○ ● ORTモデルとの併用で、ランタイムサイズ→3割減 メモリ消費量→5割減 そのカスタムビルドを行うためのCI(GitHub Actions)をOSSとして公開中 DeNA Engineering - OSS への取り組み より「DeNA OSS」でご検索ください © DeNA Co., Ltd. 48
© DeNA Co., Ltd. 49