メモリー使用量の最適化¶

警告

ここで示される推奨事項は、最初の推論のレイテンシーに大きな影響を与える可能性があることに注意してください。

最も RAM を消費する OpenVINO ステージはモデルのコンパイルです。いくつかの問題が発生する可能性があります。

モデルをコンパイルするメモリーが不足しています。メモリー要件を軽減するには、次のオプションを適用できます。
- 重みマッピング - 重みを扱うデフォルトとしてメモリーマッピング (mmap を使用) が導入されました。現在、この機能は IR および ONNX フロントエンドでサポートされています。マッピングは、ov::Core の ov::enable_mmap(BOOL) プロパティーを指定することで切り替えることができます。“メモリー・オンデマンド” の性質により、すべての重みを RAM に保存する必要はありません。必要なデータのみを保存すると、コンパイルに必要なメモリーの量が削減されます。さらに、mmap は広範なメモリー共有を提供するため、同じモデルを連続してコンパイルすると、ストレージからではなく、すでに RAM に保存されている情報がフェッチされます。
- コンパイル用のスレッド数を減らします。スレッド数を変更するには、ov::Core の ov::compilation_num_threads(NUMBER) プロパティーを指定するか、追加の引数として ov::Core::compile_model() に渡します。
モデルを再コンパイルするメモリーが不足しています。モデルのコンパイルは成功しても、リソース不足により次のいずれかの再コンパイルが失敗する場合は、以下が原因である可能性があります。
- メモリーリーク - 直接的にリークを観察するには、‘address-sanitizer’ や ‘valgrind’ などのツールを使用できます。ツールで捕捉できない間接的なリークの場合、ピーク RAM (VMHWM) を追跡できる可能性があります (追跡ツールとして tests/stress_tests/memleaks_tests を使用できます)。メモリー使用量が大幅に増加した場合は、GitHub の問題で報告してください。
- メモリー・アロケーターの動作 - 各アロケーターは独自の方針に従って動作し、パフォーマンスとメモリー使用量のバランスをとります。例えば、GNU アロケーターは、連続したモデルのコンパイルで、最初のコンパイルに必要なメモリーよりも多くのメモリーを OS に要求します (そのような動作は、コンパイル後に実際の RAM (VMRSS) を追跡することで決定される可能性があります。メモリーは安定点まで増加します)。メモリー負荷を最適化するには、次のオプションを使用します。
  - malloc_trim(0) を適用します。この関数は、スレッドキャッシュからも空きメモリーを解放しようとするため、VMRSS の使用量が大幅に減少し、安定する可能性があります。
  - glibc の Tunables を使用します。有望なオプションは glibc.malloc.trim_threshold と glibc.malloc.arena_max です。詳細については、GNU Tunables Manual を参照してください。
  - 別のアロケータを試します。メモリーを注意深く扱うアロケーターの 1 つは jemalloc です。