取引のためのONNXの学習 - ページ 4

[MetaQuotes]

2020 ONNX ロードマップ ディスカッション #2 20200909

2020 ONNX ロードマップ ディスカッション #2 20200909

「ONNX ロードマップ ディスカッション」ビデオでは、スピーカーは、形状の推論、演算子の定義、参照実装、ONNX 仕様など、ONNX のロードマップに関連するさまざまなトピックについて説明します。講演者は、一般的な形状推論インフラストラクチャを構築して、形状推論の最適化を改善し、プリミティブ オペレーターの数を減らし、すべてのオペレーターに参照実装を追加し、より適切に定義されたテスト ケースを構築して、ONNX の適切な実装とテストを確実にすることを提案しています。このグループは、新しいオペレーターを追加するために、オペレーター SIG 内および GitHub ディスカッション ボードで議論を継続する予定です。

• 00:00:00 このセクションでは、講演者が ONNX ロードマップについて説明し、いくつかの提案されたトピック、特に形状推定、オフ定義、および IR について説明します。これらはすべてロードマップ ドキュメントで以前に言及されており、さまざまな個人からのコメントが含まれています。スピーカーは、Changming または Buchan が自分たちの提案を説明できるかどうかを尋ねます。 Buchan は、形状干渉に関するフィードバックと、過去にどのように問題を抱えていたかについて説明します。彼は、IR に変更があるたびに形状を再コンパイルする汎用的な形状影響インフラストラクチャを構築して、形状推定の最適化が連携して同時に最適化を改善することを保証することを提案しています。スピーカーは、これが形状推論に直接適用されるというよりも、最適化に適用されると結論付けています。
  
  
• 00:05:00 形状の推論と最適化パスに関する ONNX の現在の機能を理解してください。既存のインフラストラクチャは、既知の入力値に基づく形状推定を既にサポートしており、出力形状の推定に使用できます。モデル チェッカーを更新することで簡単に成果が得られる可能性がありますが、その他の変更についてはさらに議論が必要になる場合があります。グループは、これらの変更が ONNX に属するのか、それとも別の場所に属するのかについて議論します。彼らはまた、連続したループで各オペレーターの形状推論メソッドを呼び出して、目的の結果を達成するというアイデアも検討しています。最終的に、既存のインフラストラクチャはすでに最適化パスと形状推論を可能にしていますが、変更と改善によりこれらの機能が強化される可能性があります。
  
  
• 00:10:00 このセクションでは、スピーカーはオペレーターの定義について議論し、他のオペレーターを低レベルのオペレーターで構成可能にすることができるため、プリミティブ オペレーターの数を減らすことを提案します。また、参照実装のトピックと、一連の演算子を評価するインフラストラクチャの必要性についても説明します。現在の参照実装は、テスト ケース ジェネレーターに Python 実装の形式で存在しますが、一連の演算子を簡単に評価できるように編成されていません。スピーカーは、検証に使用できる関数サブグラフを検証するために、ONNX ランタイムのようなランタイムを CI に追加することを提案しています。
  
  
• 00:15:00 このセクションでは、スピーカーは、ランタイムが作成者の期待から逸脱しないようにするために、すべてのオペレーターの参照実装の必要性について説明します。彼らは、リファレンス実装を単体テストとして使用してランタイムとのパリティを検証し、インタープリター モードとして使用して相互運用性と検証を確認することを提案しています。講演者は、関数が ONNX に存在するプリミティブ op で構成されているという前提の下で、関数の検証に ONNX ランタイムを使用することが可能であることに注意します。ただし、新しいプリミティブ op を含むサブグラフの新しい演算子に ONNX ランタイムを使用することはできません。これは、他のランタイムがその実装を持っていないためです。彼らは、参照実装を作成するには多くの作業が必要であることを認めていますが、それはすべての操作で必須です。また、ランタイムが作成者の期待から逸脱しないようにするために、ONNX 準拠の必要性も強調しています。
  
  
• 00:20:00 このセクションでは、スピーカーは ONNX 仕様での参照実装の使用と、仕様での明確で簡潔な言語の重要性について説明します。仕様の英語テキストのあいまいさを取り除くために参照実装を使用することを支持する人もいれば、参照実装が不要になるように仕様を十分に明確にする必要があると主張する人もいます。講演者はまた、考えられるすべてのコーナー ケースを確実にテストするための厳格なコンプライアンス テストの重要性についても説明します。最終的には、リファレンス実装は有用であるが、ONNX 仕様では必須ではないというのがコンセンサスのようです。
  
  
• 00:25:00 このセクションでは、ONNX でオペレーターを実装するための要件、特にリファレンス実装とテスト手順の必要性について説明します。演算子の参照実装はテスト データの生成に必須であると主張する人もいれば、テスト データを生成する Python 関数または固定データ セットのいずれかを提供するだけで十分であると主張する人もいます。ただし、ランタイムにオペレーターを実装する人にとって、特に多くの異なる属性を持つ複雑なオペレーターの場合、実装を適切にテストするには、参照実装を持つことが重要であることに注意してください。この議論では、ONNX のリファレンス ランタイムは必要ないが、各オペレーターのリファレンス実装が必要であることも明確にしています。
  
  
• 00:30:00 ビデオのこのセクションでは、スピーカーは、ONNX の適切な実装とテストを確実にするために、参照実装とより適切に定義されたテスト ケースを持つことの重要性について議論しました。彼らは、生成されたテスト データに依存するだけでは不十分な場合があり、簡単なコードを利用できるようにすることで、誰にとっても問題を解決できると指摘しました。会話では、完全な仕様の必要性と、未定義の動作ケースで何をすべきかをランタイムが決定する自由についても触れました。一部の講演者は、リファレンス実装を追加することで、オペレーターを提案する側に負担がかかることに懸念を表明しました。彼らは、エンジニアリングの労力を最小限に抑え、システムに ops を追加するための現在の要件を再検討することを提案しました。
  
  
• 00:35:00 ビデオのこのセクションでは、講演者が ONNX の完全で明確な仕様を持つことの重要性と、それを実施する方法について説明します。彼らは、Python での参照実装が、ランタイムにオペレーターを実装する人々がすべてのテスト ケースを検証できるようにするのに役立つことに同意しています。ただし、仕様の実装は簡単ではなく、対処すべき問題がまだあることも認めています。彼らは、仕様をどのように使用できるかを明確にする方法を議論し、オペレーターを提案してからランタイムに実装するのではなく、実践とフィードバックが新しいオペレーターの提案を導くべきであると提案しています。また、新しい op を追加するための要件の 1 つは、既知のフレームワークで実装する必要があることにも注意しています。
  
  
• 00:40:00 ONNX ロードマップ ディスカッションのこのセクションでは、グループは ONNX の仕様に新しい演算子を追加するプロセスについて説明します。提案は、新しい演算子を追加するためのポリシーを変更することです。これには、Python での参照実装が既に必要です。彼らの議論はリファレンス実装とコンプライアンス テストを中心に行われており、オペレーター SIG 内と GitHub ディスカッション ボードで会話を続ける予定です。グループは、翌週に予定されている次の会議で議論を続ける予定です。

[MetaQuotes]

2020 ONNX ロードマップ ディスカッション #3 20200916

2020 ONNX ロードマップ ディスカッション #3 20200916

このビデオの議論は、エラー処理の改善、モデルの作成を示す事前定義されたメタデータ スキーマ フィールドの追加、量子化物理最適化の必要性、Model Zoo から最新バージョン。チームは、影響とコストに基づいてこれらのトピックに優先順位を付け、1.8 リリース後に取り組む予定です。さらに、このグループは、Spark などのさまざまなプラットフォームをサポートするために、Java に特に関心を持って、ONNX ツールセット用のさまざまな言語バインディングを作成するというアイデアを検討しています。スピーカーは、ONNX ランタイムの Java ラッパーを作成する可能性についても説明します。

• 00:00:00 このセクションでは、スピーカーはコミュニティと 3 つのトピックについて話し合うことを提案しています: エラー処理、モデル ズーの拡張、量子化のためのより多くの操作または演算子の実装です。彼らは、次の 3 つのセッションを利用して、これらのトピックのコストと影響について話し合い、最も影響が大きくコストが低い項目に基づいて優先順位を決定する予定です。また、これらのトピックがリリース 1.8 に与える影響についての質問に答え、これらの変更のほとんどが 1.8 以降に行われることを説明しています。コミュニティ メンバーの 1 人は、エラー処理を改善して、ランタイムが不正な形式の protobuf に遭遇した場合に終了せず、代わりにエラー コードを返すか例外をスローして、ユーザー エクスペリエンスを向上させることを提案しています。
  
  
• 00:05:00 このセクションでは、クラッシュを防ぎ、機能を改善するために、ONNX の読み込みコードのエラー処理を改善することに焦点を当てています。チームはコードのファジングを実施し、信頼されていないモデルがプロセス全体を停止する可能性があることを発見し、対処することを最優先事項にしました. ONNX ランタイムには、ONNX チェッカーとは異なるチェック プロセスがあり、同じチェッカーを共有できるかどうかはまだ明らかではありません。さらに、監査中のエラー処理の改善に関するトピックが提起されており、チームはこの提案をフォローアップする予定です。
  
  
• 00:10:00 このセクションでは、スピーカーは、ONNX エコシステムとやり取りし、ONNX モデルを提供する Trivial と呼ばれるライブラリについて説明します。彼らは、モデルが作成されたときのタイムスタンプ、モデルに使用されたトレーニング アルゴリズム、モデルを生成するために使用されたソース ライブラリを示すために、ONNX に定義済みのメタデータ スキーマ フィールドを追加することを提案しています。彼らは、メタデータ フィールドに標準のキー名を定義し、それらも入力することを提案しています。講演者は、メタデータ フィールドのスキーマを持つことは、ライブラリや ONNX モデルを提供する他のユーザーにとって役立つと考えています。その後、Model Zoo のすべてのモデルをカバーし、高品質の良い例を提供するために、モデル テストを拡張する必要性に話題が移ります。
  
  
• 00:15:00 このセクションでは、量子化の物理的最適化の必要性と、ONNX のモデル ズーを拡張して量子化されたモデルを含めることについて議論します。モデル ズーに量子化されたモデルを含めてほしいというリクエストがいくつかあり、チームは貢献者を見つけたいと考えています。彼らは、Hugging Face の量子化された ONNX モデルがうまく機能しているブログについて言及していますが、それを投稿するには Hugging Face の許可が必要です。また、トランスフォーマー ライブラリの最上位モデルが量子化の例になる可能性があることも示唆されており、マイクロソフトとスペースの両方がそれに取り組んでいます。さらに、最適化についての議論があり、最適化は ONNX の仕様の範囲を超えているため、ランタイムに任せたほうがよいという意見で一致しました。
  
  
• 00:20:00 このセクションでは、参加者は、バージョン コンバーター ツールを使用して Model Zoo から最新バージョンに ONNX モデルを更新する可能性について話し合います。ただし、ONNX は以前のすべてのバージョンをサポートしているため、バージョン コンバーターは完全には最新ではなく、変換が必要かどうかについては不確実性があることに注意してください。このグループは、Spark などのさまざまなプラットフォームをサポートするために、ONNX ツールセットのさまざまな言語バインディングのアイデアも検討しています。特に Java に関心があります。 Java API またはバインディングを追加すると、モデル ファイルの読み込みと検証、および他のライブラリから ONNX 形式へのコンバーターの作成が容易になります。
  
  
• 00:25:00 このセクションでは、スピーカーは ONNX ランタイムの周りに Java ラッパーを作成する可能性について説明します。これにより、Spark などの JVM ベースの機械学習プロジェクトがより簡単になります。これは簡単な作業ではありませんが、Java CPP プリセットを使用してスタブを自動生成することは、良い出発点になる可能性があります。下位互換性は、Spark のような大規模なプロジェクトにとって非常に重要であり、Java 8 をターゲットにするにはかなりの作業が必要になります。ただし、コミュニティに貢献するのに十分な関心と意欲がある場合は、調査するのが良いでしょう.

[MetaQuotes]

2020 ONNX ロードマップ ディスカッション #4 20200923

2020 ONNX ロードマップ ディスカッション #4 20200923

ONNX ロードマップ ディスカッションの 4 番目の部分では、データ フレームのサポート、前処理、標準化、エンド ツー エンドの機械学習パイプライン、およびツールの推奨事項について説明します。データ フレームのサポートは、従来の機械学習モデルにとって価値があると評価されており、前処理の必要性をなくすことができます。画像処理などの高レベルのカテゴリの標準化に重点を置いて、パフォーマンスを向上させるために、ONNX モデル内で前処理をキャプチャする必要性が強調されています。エンド ツー エンドのパイプラインは優先度が低いと評価されていますが、パイプラインにコンポーネントを徐々に追加することをお勧めします。議論は、議題項目のさらなる議論と分析を支援するツールを使用することを推奨して終了します。

• 00:00:00 このセクションでは、スピーカーが ONNX ロードマップとコミュニティによって提案された機能について説明します。これまでに、ML パイプラインとデータ処理、op 定義または IRS、およびコア ロボティクスを含む 3 つのセクションを取り上げました。ロードマップ ドキュメントには、優先度が高、中、低の推奨機能の表が含まれています。ただし、一部のトピックは一般的すぎて、その重要性を評価するのが困難です。講演者は、次の 30 分間で、これらの機能の一部が高く評価された理由について話し合い、どの機能が最も重要であるかについてコミュニティからフィードバックを収集する予定です。
  
  
• 00:05:00  はONNX ロードマップがどのように優先されているのか疑問に思っていました。ビデオのこのセクションでは、データ フレーム サポート機能の重要性と、プラットフォーム内の他の問題を解決する方法について説明しています。講演者は、この機能はデータ サイエンティストにとって価値があり、前処理機能の必要性を潜在的に否定できると説明しています。また、タスクに効果的に優先順位を付けるために、ロードマップの各項目のエンジニアリング コストの見積もりを取得する必要があることにも言及しています。ロードマップがこのように提示されるのはこれが初めてであるため、提案を歓迎します。
  
  
• 00:10:00 ONNX ロードマップ ディスカッションのこのセクションでは、機械学習モデルのデータ フレーム サポートの重要性について説明します。データ フレームのサポートは、DNN やその他のモデルではなく、主に従来の機械学習モデル用であると考えられています。データ フレームは、テンソルの異種コレクションまたは異なる型を持つことができる列を持つリレーショナル テーブルであるという点で、シーケンスとは異なります。各機能の重要性は、それが持つ影響に基づいて評価され、エンジニアリング コストが考慮されます。機能の重要性が高いまたは低い理由を強調するために、ボックスごとにコメントを提供することをお勧めします。
  
  
• 00:15:00 このセクションでは、ONNX モデル内での前処理の重要性について説明します。この会話は、特に前処理がパフォーマンスに大きな影響を与える可能性があるトレーニングのコンテキストでは、外部ライブラリに依存するのではなく、必要なすべてのステップを ONNX モデル内でキャプチャする必要性を強調しています。さらに、前処理は、特に Python ベースの環境でない場合、推論側で役立ちます。この議論では、データ型の異種性による前処理の標準化の課題についても触れています。前処理は広範で複雑なトピックですが、会話は、前処理を標準化するために ONNX 内に不足している演算子と型を考慮する必要があると結論付けています。
  
  
• 00:20:00 このセクションでは、講演者は前処理の幅広い範囲と、視覚関連の処理だけでなく音声データも含める方法について説明します。前処理を考慮することは重要ですが、講演者は、すべてのデータ型をサポートする必要はなく、代わりに、画像処理などの高レベルのカテゴリで標準化することが開発者にとってより有益である可能性があると述べています。ただし、スピーカーは、画像のサイズ変更などの一見単純な前処理タスクでさえ、ライブラリ間に微妙なエッジケースの違いがあり、標準化がエンジニアリング上の課題になる可能性があると警告しています。それにもかかわらず、前処理タスクを標準化することは役立つ可能性があり、講演者は、将来の検討のために一般的な前処理手順を収集することを提案しています。
  
  
• 00:25:00 このセクションでは、スピーカーは ONNX にエンドツーエンドの機械学習パイプラインを含めることの優先度について議論します。対処する必要がある他の項目を考えると優先度が低いと述べている人もいます。ただし、特に ONNX ランタイムが混在している場合に、ONNX を適用する方法のエンド ツー エンドの例と図を用意することの有用性を認識しています。トレーニング部分に焦点を当て、ONNX を微調整し、最終的に前処理をミックスに追加することで、コンポーネントをパイプラインに徐々に追加するというアイデアが提案されています。議論は、議題項目のさらなる議論と影響分析を促進するためのツールを使用することを推奨して終了します。
  
  
• 00:30:00 このセクションでは、スピーカーは参加してくれたすべての人に感謝し、ソーシャル メディアと ONNX Web サイトにディスカッションを投稿しようとすることを聴衆に伝えます。

[MetaQuotes]

2020 ONNX ロードマップ ディスカッション #5 20201001

2020 ONNX ロードマップ ディスカッション #5 20201001

ONNX ロードマップ ディスカッション中に、ONNX チームは、コミュニティ メンバーによって提案され、運営委員会を含むさまざまな人々によって採点されたさまざまな機能について話し合いました。一部の機能は全会一致で合意されましたが、他の機能はコミュニティを分割しました.チームは、ONNX IR を複数の IR および集中型 IR 最適化ライブラリに変更する可能性について議論しました。また、ONNX 内で最適化ライブラリを一元化するというアイデアと、ops が標準インターフェイスとコーディング スタイルを実装するための要件についても説明しました。チームはまた、ONNX モデル用の単純なランタイムを持つ可能性と、ONNX ランタイムが利用できない場合に備えてカスタム Python ops を使用する可能性についても議論しました。さらに、チームは、前処理操作とデータ フレームの使用との関係を調査し、アイデアを将来の作業のための実用的な提案に変えることを計画しました。

• 00:00:00 このセクションでは、ONNX チームが、プロジェクトにとって何が重要かについてさまざまな人々の考えを収集するために設定された影響分析スプレッドシートについて説明します。彼らは提案されたさまざまな機能をすべてリストアップし、運営委員会や他のコミュニティ メンバーを含むさまざまな人々からスコアを得ました。彼らは、非常に重要であるか、まったく重要ではないことに誰もが同意しているように見えるいくつかの機能と、コミュニティが分裂している機能があることに気付きました.彼らは分割されたものについて話し合い、同意したものについては次のステップが重要であると話しました。彼らはまた、優先度が高いと見なされる基準の設定と、それが機能を実装するために時間を割いてくれる人にどのように依存するかについても話しました.
  
  
• 00:05:00 ONNX ロードマップ ディスカッションのこのセクションでは、参加者は、ONNX IR を複数の IR および集中型 IR 最適化ライブラリに変更するというアイデアについて話し合います。最適化と IR は別の問題であるため、これら 2 つのアイデアをグループ化する必要があるかどうかについては、いくつかの議論があります。複数の IR を持つことの目標は、最適化ライブラリがコア ONNX を改善する一方で、より単純な操作を単純化および連結することです。 ONNX IR の意味についてはさらに議論があり、明確化が必要です。参加者は、これらの潜在的な変更が ONNX ロードマップの現在のスコアにどのように影響するかについても話し合います。
  
  
• 00:10:00 このセクションでは、チームは最適化ライブラリを ONNX に集中化する可能性について議論しますが、最終的には、最適化はランタイムの一部であるべきであり、他の問題に比べて優先度が低いことに同意します.また、ops を特定の方法で実装する必要があること、標準のインターフェイスとコーディング スタイルを使用する必要があることについても説明しています。彼らは、誰かが特定のスタイルを提案した場合、それが受け入れられると思われる場合、それを受け入れることができると示唆しています.
  
  
• 00:15:00 このセクションでは、スピーカーは ONNX モデルの単純なランタイムを持つというアイデアについて議論しますが、モデルを処理するために実行フローと内部 IR を必要とすることの複雑さについての懸念が生じます。ただし、ONNX モデルを実行して評価し、正確性をテストおよび確立できることには価値があります。特に、オペレーターの単体テストのギャップを明らかにする場合に役立ちます。単純なランタイムを実装するのにどれだけの労力とコストがかかるかについては議論の余地があるかもしれませんが、ONNX ランタイムには、この目的に使用できる Python ops をプラグインする機能があります。
  
  
• 00:20:00 このセクションでは、ONNX ロードマップ ディスカッションの参加者が、ONNX ランタイムが利用できない特定のケースでカスタム Python op を使用する可能性について話しました。彼らは、Python op の制限と、実現可能性を確保するための標準インターフェースの必要性について議論しました。さらに、グループは、特にスケーリングやバウンディング ボックスの処理などの画像ベースの前処理のために、モデルをより自己完結型でポータブルにするために、ONNX グラフ内の前処理機能の必要性について議論しました。このグループは、テキストの前処理、特にトークン化はより複雑で包括的な問題であるが、いくつかの一般的な前処理シナリオを抽象化できる可能性があると指摘しました。
  
  
• 00:25:00 このセクションでは、参加者は前処理操作とデータ フレームの使用との関係について話し合います。彼らは、前処理とデータ フレームがリンクされていることに同意しますが、それらを異なる種類の作業を必要とする別個のエンティティと見なしています。前処理は、データ フレームの列全体で行単位で機能する演算子と見なされますが、データ フレーム抽出自体は、前処理演算子を列の行全体にマップします。このグループは、この 2 つが密接に関連していると考えており、彼らのアイデアを将来の作業のための実行可能な提案に変えることを計画しています。

[MetaQuotes]

2021 ONNX ロードマップ ディスカッション #1 20210908

2021 ONNX ロードマップ ディスカッション #1 20210908

ONNX ロードマップ ディスカッションで、IBM Research は、Pandas Dataframe の典型的なデータ前処理パターンを ONNX 形式に変換する新しい機械学習パイプライン フレームワークの提案を紹介しました。 Data Frame Pipeline と呼ばれるこのフレームワークは、GitHub でオープンソース化されており、提供された API を使用して定義できます。この API は、トレーニング フェーズ中に Python で実行されます。また、スピーカーは、Java、C#、C++ などの Python 以外の言語で ONNX を可視化する必要性、および ONNX モデルのエクスポートと他の言語からの発行についても議論しました。さらに、ONNX Python および C++ コンバーターの現在の機能と、ONNX モデルを作成する際のスコーピング、ネーミング、およびパッチ機能の必要性についても説明しました。

• 00:00:00 このセクションでは、IBM Research の Takuya が、新しい ONNX オペレーターを使用した新しい機械学習パイプライン フレームワークの提案を紹介します。この提案の動機は、既存のパイプライン フレームワークがデータ前処理の典型的なパターンを表すことができないことにありました。彼らは、Python で Data Frame Pipeline と呼ばれる新しいパイプライン フレームワークのプロトタイプを作成しました。これは、Pandas Dataframe の典型的なデータ前処理パターンを ONNX 形式に変換します。彼らは、日付演算子と 2 つの単純な演算子 (文字列連結子と文字列スプリッター) を含む 3 つの新しい ONNX 演算子を保護しました。パイプライン フレームワークは GitHub でオープンソース化されており、トレーニング フェーズ中に Python で実行される提供された API を使用して定義できます。モデルは、データ フレーム パイプラインから出力されたデータを使用してトレーニングされ、それらのフレームワークは、既に変換された ONNX 機械学習モデルを使用できます。
  
  
• 00:05:00 このセクションでは、スピーカーは ONNX 形式と、Microsoft が提供する ONNX ランタイムでの使用方法について説明します。プロトタイプでは、11 個のデータ フレーム トランスフォーマーを Python で実装し、それらを ONNX 演算子にマッピングしました。ほとんどは単純なマッピングですが、関数トランスフォーマーなどの分析と変換が必要なものもあります。また、ONNX で集計演算子を実行するのではなく、帯電したボディ プロパティを使用して ONNX 演算子を生成するアプローチについても説明します。講演者は、ONNX で前処理を学習するときに大幅なスピードアップを示す予備的な実験結果を共有し、カテゴリカル エンコーディングのパフォーマンスが 300 倍向上します。彼らはまた、予測精度を比較し、彼らの提案に言及し、提示されたオペレーターに関する質問とコメントの場を開きます。
  
  
• 00:10:00 このセクションでは、Oracle Labs の Adam Pogba が、現在の機能はすべて Python でラップされており、C++ がバインドの有効なターゲットであるかどうかが明確でないため、ONNX を Python 以外の言語で表示できるようにすることを提案しています。 Pogba 氏は、ユーザーが有効な Python 環境を必要とせずに操作できるように、モデル チェッカーを他の言語で表示できるようにする必要があると説明しています。さらに、Pogba 氏は、ONNX ランタイムが解析の問題のためにモデルを使用するときにセグメンテーション違反を起こすことがあり、モデル チェッカーを使用してこの問題を検証し、簡単に修正できると述べています。
  
  
• 00:15:00 このセクションでは、スピーカーはモデル チェックのコア機能と、他の言語で公開されるとどのように役立つかについて説明します。彼らはそれを Java で実現したいと考えていますが、誰もが Java API を作成するわけではないことを理解しているため、ほとんどの言語が簡単にバインドできる C API の方が適しています。ただし、人々がバインドするための安定した適切なターゲットが必要であり、これらのツールのいずれかの C++ API がバインドの適切なターゲットと見なされるかどうかはすぐにはわかりません。講演者はこの取り組みに喜んで参加しますが、コミュニティからの関心がない限り、大規模な取り組みを促進しようとする価値はありません。
  
  
• 00:20:00 このセクションでは、講演者は ONNX モデルのエクスポートと、C# や Java などの Python 以外の言語からのモデルの発行について、特に ML.NET と Trivial Library に焦点を当てて説明します。講演者は、すべてのプロジェクトが ONNX モデルを生成するために使用できる共通 API の必要性を強く主張しています。特に、現在存在する 3 つの異なる実装にはバグが発生しやすい共有コードがないことを考慮してください。共通 API により、ノードとグラフを更新および検証する場所が 1 つだけ確保され、強みを共有する機会が提供され、他の機械学習ライブラリが ONNX モデルを発行しやすくなります。講演者は、これは大変な作業かもしれませんが、共有された努力が Python を超えて ONNX エコシステムを成長させる可能性があることを認めています。
  
  
• 00:25:00 このセクションでは、スピーカーが ONNX Python および C++ コンバーターとその現在の機能について説明します。彼らは、ONNX のドキュメントは十分に具体的ではないため、特定の機能を理解するのが難しいと指摘しています。ただし、ONNX エクスポートに必要な機能の多くはこれらのコンバーターに既に存在しますが、他のプロジェクトに適切な方法で公開する必要があると主張しています。さらに、ONNX モデルを作成する際のスコーピング、命名、およびパッチ機能の必要性についても説明しています。最後に、彼らは、さまざまな人々が簡単に使用できるように、コンバーターをアーキテクチャ インフラストラクチャ sig にリンクすることでメリットが得られる可能性があることを示唆しています。

[MetaQuotes]

2021 ONNX ロードマップ ディスカッション #2 20210917

2021 ONNX ロードマップ ディスカッション #2 20210917

ONNX ロードマップ ディスカッション #2 20210917 では、さまざまなスピーカーが、量子化と融合の使いやすさ、特定のハードウェア プラットフォーム向けのカーネルの最適化、ONNX へのモデル ローカル関数の追加など、ONNX の改善が必要ないくつかの重要な領域について議論しました。その他のトピックには、エンド ツー エンドのパイプライン サポートに関するフィードバック、さまざまなプラットフォームでクライアントが直面する課題、GRU および LSTM グラフの変換に関する問題が含まれていました。いくつかの提案された解決策には、バックエンドが事前に量子化されたグラフを実行するためのより多くの情報を提供すること、さまざまなフレームワークの相互運用性を改善すること、および元のグラフに関連する名前空間を含めて、一般的な解決策と最適化された解決策の両方を可能にすることが含まれていました。さらに、スピーカーは、より幅広い採用のためにパッケージのより良い展開の必要性と、マルチモーダル モデルをサポートするために開発されるより多くのコンバーターの可能性について議論しました。

• 00:00:00 このセクションでは、Green Waves Technologies の Martin が、ONNX に改善が必要な 2 つの領域、量子化と融合の使いやすさについて説明します。量子化について、Martin は、バックエンドが事前に量子化されたグラフを実行するためにより多くの情報を提供することを提案しています。ONNX が顧客が特殊なものを実装したいすべての異なる方法に従うことは不可能だからです。これを支援するために、マーティンは、可能なアドオンとして、外れ値統計、チャネルごとのチャネル情報、分布情報などの追加情報とともに、最小最大、標準偏差、および平均情報をテンソルに追加することを提案しています。フュージョンを使いやすくするために、Martin は、より優れたインポート/エクスポート機能を提供することで、さまざまなフレームワークの相互運用性を改善することを提案しています。これにより、ONNX がさまざまなグラフをインポート/エクスポートするときに使用する適切なコンバーターを簡単に識別できるようになります。
  
  
• 00:05:00 このセクションでは、スピーカーは、構成されたオペレーターの関数の現在の使用法と、オペレーターが分割されている場合に特定のハードウェア プラットフォーム用にカーネルを最適化することの難しさについて説明します。エクスポートされた関数を上位レベルのコンテナー (おそらく関数) の下にグループ化し、そのコンテナーを特定のバックエンドの最適化されたカーネルにマッピングするというアイデアが提案されています。スピーカーは、元のグラフに関連する名前空間を含めることも提案しており、一般的なソリューションと最適化されたソリューションの両方を可能にします。最新の ONNX リリースでは、モデルのローカル関数をインポートする機能の追加についても言及されています。
  
  
• 00:10:00 このセクションでは、スピーカーは ONNX へのモデル ローカル関数の追加について説明します。これにより、コンバーター オペレーターは、ONNX 標準で定義されていないオペレーターのプレースホルダーとしてモジュール proto に関数本体を含めることができます。ただし、スピーカーは、コンバーターが機械可読な方法でエクスポートするものにラベルを付けてコメントすることがベストプラクティスであるべきであるとも述べています。また、最適化が命名規則にどのように影響するかについても触れており、Slack チャンネルまたは別の会議でこのトピックに関する議論を続けることを提案しています。次のプレゼンテーションは、ONNX プロファイリングに関するものです。
  
  
• 00:15:00 このセクションでは、エンドツーエンドのパイプライン サポートに関するフィードバックについて説明します。ONNX は、重いエコシステム要件を必要としないさまざまなオペレーティング システムへの軽量展開に最適であると見なされています。講演者は、ONNX と ONNX ML の両方で ONNX オペレーターがモデルだけでなく、他の種類のデータ生成操作を含むデータ準備段階も実行できるようにする方向への希望を表明します。彼らは、単純化された、または一般的な展開アーティファクトまたはモデルが付加価値をもたらす可能性があると主張しています。また、標準的な変換に関する簡単な成果に焦点を当てることで、労力と一貫性を節約する機能も備えていると主張しています。
  
  
• 00:20:00 このセクションでは、講演者はさまざまなプラットフォームでクライアントが直面する課題のいくつかについて説明し、ONNX プラットフォームの開発と拡大を継続することの潜在的な価値に注目しています。彼らは、サイロ化の問題と、より良い採用のためにパッケージの展開を簡素化する必要性について触れています。会話には、同様の問題に直面していることを確認し、Linux サーバーの ONNX をマージするか、ユーザーがカスタム コードを ONNX に変換するのを助けるためのより良い方法を見つけるオプションを提案する参加者からのコメントも含まれています。講演者は、マルチモーダル サポートのトピックと、モデルのアンサンブルを単一の ONNX グラフとして表す必要性についても触れています。彼らは、より多くのコンバーターの潜在的な必要性について議論し、正しい方向への一般的な動きを示唆しています。
  
  
• 00:25:00 ONNX ロードマップ ディスカッションのこのセクションでは、チームはプロキシ モデルのプロキシの例について説明し、顧客が企業環境で使用している画像以外の種類のユース ケースの種類を紹介します。あるチーム メンバーは、いくつかのオープン データを使用し、比較的単純な 2 層 LSTM モデルである不正検出モデルのプロキシの例について言及しています。チームはこの問題をさらに調査しており、プロキシ モデルのより多くの例を提示しようとしています。また、GRU と LSTM が正しく変換されない問題についても議論し、すべてのケースのサポートを追加したいと述べています。
  
  
• 00:30:00 このセクションでは、スピーカーは、GRU (gated recurrent unit) グラフをバックエンドのコンバーターが読み取ることができる形式に変換する際の課題について説明します。彼らは、TensorFlow で既にブレークダウンが発生している特定のケースがあると述べていますが、それを GRU に戻すのは困難です。彼らは、「--custom ops」フラグを使用して、それで機能するカーネルを作成してから、それを関数にするかセマンティクスの観点から保存するという考えに移ることを提案しています。彼らは、最適なオプションは、ユーザーが分割を希望するかどうかを明示的に示すことであり、カスタム op を使用することが確実にそれを行う唯一の方法である可能性があることを指摘しています。
  
  
• 00:35:00 このセクションでは、スピーカーは、ONNX と高レベルの両方でフル機能のボディを持つ方が良いのか、それとも単に TF ベースを持つ方が良いのかについて議論します。彼らにとっては、チェーンに沿った結果の証明として ONNX を使用できるため、TF ベースで十分です。ただし、ONNX はさまざまな場所から取得できる必要があるため、ONNX を TensorFlow 中心にすることには注意が必要です。彼らはまた、セマンティックな意味を持つ名前付きサブグラフを持つことの魅力についても触れました。これは、さまざまなフロントエンドによって定義および生成される必要があるほぼ演算子と考えられます。最後に、彼らは、より知識のある人々との議論を続けるために、より深いプレゼンテーションを行うことに同意しました.

[MetaQuotes]

2021 ONNX ロードマップ ディスカッション #3 20210922

2021 ONNX ロードマップ ディスカッション #3 20210922

ONNX ロードマップ ディスカッションでは、スピーカーは、特定のユース ケース向けに最新の最適化されたスタックを使用して ONNX の採用を改善するために、ONNX のオフセット変換ツールの問題を修正する必要性について言及しました。スピーカーは、オフセット変換をテストするためのモデルのより良いカバレッジと、オペレーターまたはレイヤーのテストで現在欠落している中間ステップの解決を提案しました。また、メタデータとフェデレーテッド ラーニング インフラストラクチャの重要性についても説明しました。これには、転移学習アノテーション用の ONNX 仕様にメタデータを含める必要性や、プライバシー、効率、および計算リソースの使用を可能にするフェデレーテッド ラーニングの概念が含まれます。スピーカーは、コミュニティからのコラボレーションを奨励し、これらのアイデアをさらに議論して実装するためのフィードバックを求めました。次回は10月1日を予定しております。

• 00:00:00 このセクションでは、Intel の Manoj が、多くの顧客に問題を引き起こしている ONNX モデルのオフセット変換のギャップに対処します。基本的な問題はオフセット変換にあります。多くの顧客は、モデルを本番環境にデプロイした後、オフセットを更新し続けようとはしません。お客様は、量子化のために 7 から 10 から 13 に移動したり、古いオフセットを新しいオフセットに変換してパフォーマンスと優れた精度を活用できないなど、オフセット変換に関する複数の問題に直面しています。さらに、すべてのオペレーターまたはレイヤーに関連する単体テストまたはすべてのテストは、ISV が満足できるレベルに達していないため、ほとんどの顧客はまだ 10 または 9 オフセットのままです。
  
  
• 00:05:00 このセクションでは、ONNX のオフセット変換ツールの問題を解決する必要性について講演者が議論します。これは、特定のユース ケースに対して最新の最適化されたスタックを使用した ONNX の採用を妨げているためです。 AI を統合してアプリケーションに組み込んでいる開発者は、変換ツールを修正し、それらがシームレスであることを確認する必要性についてフィードバックを提供しています。彼らは、量子化されたパフォーマンス モデルへの移行を妨げている、中間ステップの欠落やアダプターの実装の欠落など、直面した問題の例を共有しています。スピーカーは、ONNX のより良い採用を確実にするために、より良いカバレッジとより多くのモデルをテストする必要性を強調しています。
  
  
• 00:10:00 ビデオのこのセクションでは、スピーカーは、ONNX をさらに改善するために、トップ クリエーター企業から少なくとも 1 つの失敗したモデルの承認が必要であることについて話し合います。議論は、モバイルと Windows などの異なるエコシステム間のギャップの 1 つであった fp16 変換の改善と、Microsoft コンバーター ツールを使用して最近どのように修正されたかに移ります。変換の責任は明確ではありませんが、議論はモデル動物園に関する次のプレゼンテーションに移ります。ここでは、トレーニングにフォニックス オペレーターを含めることで、カテゴリ全体のすべてのモデルをカバーするのに役立ちます。彼らは、Transformer または NLP トレーニング サンプルから始めて、より多くのモデルに移行して、ONNX に適用可能な分散トレーニング インフラストラクチャとテクニックを紹介することを提案しています。
  
  
• 00:15:00 このセクションでは、スピーカーは、量子化を意識したトレーニングや混合精度の使用の重要性など、トレーニングにおける ONNX モデルの関与について説明します。彼らは、元の fp32 モデルを要求して、精度をよりよく比較し、ONNX モデルを使用したトレーニングでの混合精度の使用を示します。彼らはトランスフォーマーのサンプルへの貢献を優先していますが、他の人気のあるカテゴリへの貢献についてはコミュニティに助けを求めています。また、メタデータの一部としてモデル内での混合精度の使用をより適切に反映するための将来の提案についても議論しています。最後に、Gabe Stevens が、Intel が検討し始めている展開構成を紹介します。
  
  
• 00:20:00 このセクションでは、スピーカーは、分散および連合学習の概念と、プライバシー、遅延、効率、および計算リソースの使用に関する利点について説明します。アイデアは、モデルを一連のデバイスにデプロイすることです。デバイスの一部には、表示されるデータを使用してモデルを強化するトレーニング グループがあります。 ONNX への提案された変更により、連合学習が容易になり、開発者が ONNX を使用する可能性が高くなります。 API への最小限の追加セットには、パーツを照会してローカル モデルのパラメーターを取得し、それらのパラメーターを更新し、モデルがどのように変更されたかをサーバーに通知して、モデルからの調査結果を含む新しいモデルに統合する方法が含まれています。デバイス。
  
  
• 00:25:00 ビデオのこのセクションでは、講演者は ONNX 仕様にメタデータを含めて転移学習アノテーションを可能にし、より大きなデータセットでトレーニングされたモデルを使用して小さなデータセットをトレーニングしやすくするというアイデアについて説明します。ただし、このようなシステムの実装には、実装者に任せる必要がある複数の設計上の決定が含まれます。講演者は、アプリケーション開発者に必要な柔軟性を制限することなく、そのようなシステムの基本的なインフラストラクチャを促進できる 3 つの項目を提案します。また、デバイスのフリート全体でのモデル バージョンの展開における一貫性の必要性と、ONNX モデルのみがフェデレーション ラーニング システムへの参加を許可されることを義務付けないことの重要性についても言及しています。講演者は、仕様の設計者がこの種の学習の構成に注意を払うことに関心があるかどうか、およびさらなる議論を受け入れるかどうかについてフィードバックを求めます。別の講演者は、トレーニングをサポートし、それを使用して連合学習を行うための概念実証が構築されているため、ONNX ランタイムでこれを行うことを提案しています。
  
  
• 00:30:00 このセクションでは、講演者は、プレゼンテーションにかけられた多大な努力に感謝の意を表し、コミュニティからの質問に感謝します。プレゼンテーションの目的は、さらなる議論と最終的な実装のために、関連する SIG にアイデアを提示することです。最後のセッションは 10 月 1 日に開催され、講演者はこれらのアイデアに引き続き関与することを楽しみにしています。

[MetaQuotes]

ONNX コミュニティ バーチャル ミートアップ – 2021 年 3 月

000 ONNX 20211021 ONNX SC ウェルカム プログレス ロードマップのリリース

ONNX ワークショップは紹介から始まり、主催者は ONNX エコシステムの成長におけるコミュニティ参加の重要性を強調しました。彼らはまた、ONNX 統計の最新情報、コミュニティ プレゼンテーション、ONNX 運営委員会のロードマップ ディスカッションを含む議題の概要を提供しました。ロードマップの提案は、ONNX フレームワークのサポート、堅牢性、使いやすさを向上させることを目的としており、前処理演算子、C API、連合学習、データ処理と推論のより良い統合が含まれています。 ONNX 仕様のバージョン 1.10 の最近のリリースについても議論され、参加者は質問をしたり、ONNX Slack チャネルに参加して会話を続けることが奨励されました。

• 00:00:00 ワークショップのこのセクションでは、主催者が概要を説明し、すべての参加者を歓迎します。彼らは、AI に利用できる膨大な数の製品について言及し、参加者にそれをチェックするよう促しています。ワークショップの全体的な目標は、ONNX、そのプロセス、ロードマップ、およびリリースに関する最新情報を入手し、ONNX がどのように使用されているかについてコミュニティの参加者から学ぶことです。彼らは、参加者がフィードバックを共有し、ONNX 運営委員会、SIG、およびワーキング グループにさらに関与することを奨励しています。彼らは議題の概要を提供します。これには、ONNX ワーキング グループのロジスティクス、Wenming Yi による State of the State プレゼンテーション、続いて Alex、およびコミュニティ プレゼンテーションが含まれます。最後に、彼らは ONNX の統計に関するエキサイティングな更新を提示します。これには、毎月のダウンロードがほぼ 400% 増加して毎月 160 万に達し、エコシステムの健全な成長が示されています。
  
  
• 00:05:00 このセクションでは、スピーカーが ONNX エコシステムの進歩と成長について議論し、コミュニティ内の企業からの貢献の重要性を強調します。講演者は、Java コミュニティに優れた経験をもたらし、多くの成長を遂げた Amazon のディープ Java ライブラリ プロジェクトについて言及します。 IBM、AMD、Sony などのいくつかの営利企業は、エコシステムのサポートを提供し、ONNX が業界標準になるのを支援しています。スピーカーは、コミュニティのガバナンスと運営委員会の新しいメンバーについても話し、ロードマップ ディスカッションへの参加、Slack チャネル、GitHub での Q&A、およびドキュメントとブログへの貢献を招待します。次の講演者は、正しい方向に進み、ONNX モデルを CPU とアクセラレータ用のバッテリにまで下げるために重要なロードマップをフォローアップします。
  
  
• 00:10:00 このセクションでは、スピーカーは、夏に行われた ONNX の運営委員会のロードマップに関する議論について説明します。異なるメンバーから受け取った提案は、それぞれ 3 つの提案からなる 4 つのグループに分けられ、各グループは承認と実施のためにそれぞれの Sig に提示されます。提案は、前処理演算子、C API、モデル チェック、他の言語でのモデルの発行のサポート、テンソルへのメタデータ情報の追加、データ処理と推論のより適切な統合、フェデレーテッド ラーニングの概念の定義、完全性を向上させるためのメタデータ処理プロパティの定義にまで及びます。データ、モデルなどの。目標は、すべてのユーザーに対して ONNX フレームワークのサポート、堅牢性、使いやすさを向上させることです。
  
  
• 00:15:00 このセクションでは、スピーカーは ONNX 仕様のバージョン 1.10 の最近のリリースについて説明し、貢献者の努力に感謝します。この最新の変更に関するさらなる議論と詳細は、next.ai Web サイトで行われる予定です。スピーカーは、会話を続けるためにチャットまたは ONNX の一般的な Slack チャンネルに質問を投稿するよう聴衆に勧めます。

[MetaQuotes]

ONNX コミュニティデイ！ 2022 年 6 月 24 日にライブ配信

このイベントは、6 月 24 日金曜日に真新しいマイクロソフト シリコン バレー キャンパスで直接開催されます。

このイベントでは、ONNX コミュニティの最新情報、パートナーとユーザーの事例、および多数のコミュニティ ネットワーキングが取り上げられます。

ONNX コミュニティデイ！

簡単な要約:

• 00:00:00 - 01:00:00 YouTube 動画「ONNX コミュニティ デイ！」機械学習モデルを扱う開発者向けの相互運用性と柔軟性に関する ONNX コミュニティの作業の更新と改善について説明します。 ONNX コミュニティはオープン ガバナンスの下で機能し、ツールの 3 つのカテゴリ (作成、実行、視覚化) がコミュニティの ONNX への関与と使用をサポートします。このビデオでは、ONNX 仕様の更新、新しいオペレーター、コンバーターの改善など、さまざまな側面に関する進捗レポートを提供します。また、講演者は、ハードウェア ベンダーにとって幅広い顧客層、ユーザーにとって複数のフレームワークとハードウェア アクセラレータへのアクセスなど、ONNX の利点についても強調します。 ONNX の将来には、実行可能な仕様を提供する ONNX 関数の概念が含まれます。
  
  
• 01:00:00 - 02:00:00 ONNX Community Day イベントでは、ONNX Model Zoo や、ONNX モデルで使用する事前トレーニング済みの機械学習モデルとデモを提供する ONNX チュートリアルなど、ONNX に関連する複数のトピックについて説明します。このビデオでは、データの前処理操作を標準化してモデルの展開を改善することを目的とした ONNX Preprocessing Working Group の作業に焦点を当てています。講演者はまた、ニューラル ネットワークの量子化の基礎と、TensorRT がトレーニング後の量子化や量子化を意識したトレーニングなど、さまざまな融合を通じて量子化されたネットワークをサポートする方法についても説明します。彼らはまた、低精度の量子化を表す際の ONNX の限界を掘り下げ、クリッピングを使用してその表現力を拡張し、量子化されたノードと逆量子化されたノード間の精度を誘導する戦略を提案しています。最後に、このビデオでは、量子化および微調整された TensorFlow 保存モデルの精度に関するケース スタディを詳しく説明しています。
  
  
• 02:00:00 - 03:00:00 ONNX コミュニティ デイでは、機械学習モデルにおけるメタデータの重要性と ONNX での Java 仮想マシン (JVM) サポートについて議論する多数のスピーカーが紹介されました。講演者は、データを保護するためにハードウェア ベースのテクノロジを使用することを強調し、DeepJ や Deep Java Library などのさまざまな機械学習ライブラリとの ONNX の互換性を強調しました。彼らは、効率を高めるためにバイト バッファを使用する方法を示し、信頼できる説明可能な AI のためにメタデータを標準化することの重要性について説明しました。プレゼンテーションでは、ONNX と ONNX ランタイムを使用して改善された中国の銀行のランタイムなどの成功事例も紹介されました。 ONNX コミュニティは、ハブ ワークフローからのメタデータの作成、クエリ、およびフィルタリングに取り組んでおり、ONNX での機械読み取り可能なメタデータをサポートしています。全体として、プレゼンテーションは ONNX プラットフォームの強みとその開発に対するコミュニティの取り組みを強調していました。
  
  
• 03:00:00 - 04:00:00 「ONNX コミュニティデイ！」ビデオでは、ONNX エコシステムに関連するさまざまな更新と機能について説明します。これには、量子化モデルと事前トレーニング済みモデルの間の精度低下を減らすための量子化のシミュレーション、NVIDIA のツールキットでトレーニングされた TensorFlow モデルの TensorRT を使用した ONNX グラフへの展開、最適化されたテンソル形状、実行プロバイダーなどの ONNX ランタイムの改善に関する議論が含まれます。モバイル プラットフォームのサポート。さらに、XNNpack ライブラリのサポートや、前後処理タスク用の ONNX ランタイム拡張機能の作成など、ONNX 自体の更新についても議論されました。このビデオでは、トレーニングから推論までの変換モデルの高速化に焦点を当てたライブラリ Optimum も紹介しています。
  
  
• 04:00:00 - 05:00:00 ONNX コミュニティ デイでは、ONNX ランタイムとそのユース ケースに関連するさまざまなトピックに関するディスカッションが行われました。講演者は、ONNX ランタイム パッケージ、PiTorch ONNX コンバーター、および PyTorch のカスタム Ops の機能について説明しました。また、プロセスの監視や商取引のデジタル化などのユース ケースや、モデルの展開や互換性テストに関連する課題についても説明しました。イベント全体を通して、ONNX ランタイムはパフォーマンスの向上と展開サイズの縮小に役立つことが強調されましたが、一貫した品質と速度を確保するには互換性と選択が不可欠です。
  
  
• 05:00:00 - 06:00:00 ONNX コミュニティ デイでは、ONNX フレームワークを使用して機械学習モデルを最適化および展開するために使用されるさまざまなツールや手法について話し合う複数のスピーカーが登場しました。 NVIDIA は、推論にブロック分割を使用して画質とモデルの互換性を向上させるアプローチと、モデルのデバッグと変更のための ONNX 固有のツールについて説明しました。 Qualcomm は、ONNX をインターチェンジ フォーマットとして使用して AI アクセラレータを設計に統合した方法を説明し、ONNX ランタイムと最適化と展開のためのさまざまなツールを含むソフトウェア スタックを紹介しました。さらに、何人かの講演者は、モジュールの最適化、チェックポイント、および形状の推論などの手法を使用して ONNX モデルを最適化することについて議論しました。このイベントでは、さまざまなデバイスのユース ケースに対する ONNX の汎用性とスケーラビリティが強調され、ONNX プロジェクトの成長を継続するための貢献が奨励されました。最後の部分では、SPIP 提案を使用して機械学習モデルを Spark にデプロイするプロセスを簡素化することに焦点を当てています。これは、開発者がタブ処理の変換とモデルの初期化の複雑さを隠すことを目的としています。 AI アプリケーションとサービスを構築するための API を提供するソフトウェア層「Kung」を含む、Ascend AI エコシステムとそのプロセッサが紹介されました。 Khan ソフトウェア スタックが議論され、それを ONNX ランタイムの新しい実行プロバイダーとして追加するためのロードマップが提示されました。イベントは、モバイルおよびエッジ用の ONNX、モデルの展開、トレーニングと運用、変換、オペレーターなどのトピックに関する円卓会議で終了し、ハッピーアワーとアンケートのフィードバックが続きました。

詳細なタイムラインの要約:

• 00:15:00 お好みのフレームワークでモードを作成し、モデルを他のフレームワークやツールで使用できる一般的な形式にエクスポートします。これにより、機械学習モデルを扱う開発者の相互運用性と柔軟性が向上します。さらに、ONNX は、複数の異なるフレームワークをサポートするのではなく、ONNX によって定義された共通の演算子セットのサポートに集中できるようになったため、機械学習モデル用に最適化されたランタイムを作成したいハードウェア ベンダーにとって有益です。
  
  
• 00:20:00 このセクションでは、スピーカーは ONNX を使用する利点について説明します。これにより、ユーザーは複数のフレームワークとハードウェア アクセラレータにアクセスできるようになり、ハードウェア ベンダーはより幅広い顧客にアクセスできるようになります。 ONNX の開発は、オープン ガバナンスの下でコミュニティによって行われます。つまり、それを制御する単一の企業はありません。講演者はまた、アーキテクチャとインフラ、オペレーター コンバーター、モデル ゾーン、チュートリアル、および新しい前処理ワーキング グループを含むワーキング グループにも注目します。講演者は、ONNX モデルの作成、実行、視覚化という 3 つのツール カテゴリの概要を説明し、PR、貢献者、スター、毎月のダウンロード数の増加など、過去 6 か月の統計を提供します。コミュニティの関与と ONNX の使用を強化します。
  
  
• 00:25:00 このセクションでは、スピーカーは、最後のコミュニティ更新以降に ONNX コミュニティで行われたリリースと更新について説明します。今年初めに ONNX 1.11 がリリースされ、新しいオペレーターが導入され、ユーザーがさまざまなモデル動物園から事前トレーニング済みのモデルをプルできるようにする ONNX モデル ハブを含むいくつかのオペレーターが更新されました。さらに、compose ユーティリティや関数ビルダーなどのユーティリティが導入され、バグ修正とインフラストラクチャの改善が行われました。 ONNX 1.12 が最近導入され、より多くの新しい演算子、形状と推論の機能強化、および python 3.10 のサポートが追加されました。講演者は、ONNX ロードマップ プロセスと、さらなる進行のために選択され、ワーキング グループに割り当てられた 12 のロードマップ リクエストについても説明します。これらの要求には、データ前処理用の新しい演算子の実装、ONNX 用の C API などが含まれます。
  
  
• 00:30:00 ビデオのこのセクションでは、スピーカーは、モデルとテンソルを介して流れる、より構造化された量子化された情報の必要性に対処するための進歩について説明します。 ONNX オペレーターを使用したエンドツーエンドのパイプラインの提案は、長期的な傍受として識別されるため、さらに洗練されています。これまでのところ、コンバーターでいくつかの進歩があり、より高機能な ops がサポートされています。講演者はまた、これはコミュニティ プロジェクトであるため、より多くのボランティアの必要性や、より多くの人々にこの取り組みに参加してほしいという企業への要求など、さまざまな分野にも触れています。スピーカーは、Web サイト、GitHub、Slack チャネル、ONNX カレンダーなどのさまざまなリソースをリストします。
  
  
• 00:35:00 このセクションでは、講演者が ONNX の最近の更新と改善について説明します。最近の 2 つのリリースでは、オペレーターに対するチップの影響が改善され、不正確なオプション入力の処理がより安定するなど、さまざまな更新が行われました。さらに、講演者は、Model Composer と Function Builder という 2 つの重要なリリースが追加されたことを強調しています。モデル コンバーターもより安定しており、チームは将来、混合リリースのサポートを改善する予定です。全体として、コントリビューターによって行われたすべての改善点をリストすることは不可能ですが、コントリビューターは ONNX の改善に向けて引き続き取り組んでいます。
  
  
• 00:40:00 Operator SIG の Rama は、ONNX 仕様に対する最近の変更と更新の概要を説明しました。 Operator SIG の焦点は、ONNX 仕様を構成する一連のオペレーターを進化させ、新しいオペレーターを追加し、その仕様を明確にすることです。過去 2 つのリリースでは、グリッド サンプルやレイヤーの正規化などの新しい演算子が導入されました。 scatter op などの既存の演算子は重複インデックスをサポートするように更新されましたが、一部の op は b float 16 やオプションの型などの型をサポートするように拡張されました。 Rama はまた、新しいオペレーターの一部をまもなく関数に昇格させる計画についても言及しました。
  
  
• 00:45:00 このセクションでは、講演者は ONNX の将来の計画と、コンパクトな仕様を持つことと、仕様でより多くの操作を必要とする新しい種類のモデルをサポートすることとのトレードオフについて説明します。この課題に対する解決策は、OP の実行可能な仕様を提供し、競合する要件間のバランスを可能にする ONNX 関数の概念です。スピーカーは、プリミティブ オペレーターを関数に昇格させ、ONNX-Crypt と呼ばれるサブセットを使用して Python でオーサリングできるようにすることで、一連のプリミティブ オペレーターを削減する計画について言及しています。 Jello アクティベーション関数やドロップアウト op などの関数の例を示して、制御フローを使用することで、それらのセマンティクスを自然かつコンパクトに指定することがいかに容易になるかを説明します。
  
  
• 00:50:00 このセクションでは、Kevin Chen がコンバーターの署名と前回の会議以降に行われた作業について最新情報を提供します。彼は、PyTorch、TensorFlow、sk-learn から ONNX へのコンバーターなど、フロントエンド コンバーターの更新について説明しています。 PyTorch コンバーターの場合、最新のリリースでは ONNX オフセット 16 までの ONNX エクスポートがサポートされており、特に ONNX ローカル関数としてニューラル ネットワーク モジュールをエクスポートする機能など、新しい機能が追加されています。 Chen は、ONNX 中心性や ONNX TensorFlow コンバーターなど、バックエンド コンバーターの更新についても説明します。最後に、Chen はコンバータ sig のロードマップを提示し、人々に参加を促します。
  
  
• 00:55:00 このセクションでは、スピーカーは、SK Learn to ONNX コンバーター、ONNX 検出キー コンバーター、および ONNX TensorFlow コンバーターの更新と改善について説明します。モデルを変換する際のユーザー エクスペリエンスを向上させるために、最新バージョンに更新することをお勧めします。コンバーター スティックのロードマップには、コミュニティ主導のツールの改善、ユーティリティ機能の標準化、オペレーターとオフセットのサポートの改善などの目標が含まれています。ユーザーは、Slack の ONNX コンバーター チャネルに参加するか、ONNX コンバーター SIG メーリング リストに登録して、コミュニティに参加し、フィードバックを提供することをお勧めします。

• 01:00:00  Microsoft の Jackie が ONNX Model Zoo と ONNX チュートリアルを紹介します。 ONNX Model Zoo は、トレーニング済みの最先端の機械学習モデルのコレクションであり、主に ONNX コミュニティによって提供されています。現在、動物園には 168 のモデルがあり、その中には 40 の ONNX モデルと、画像分類と物体検出用の 35 の視覚ベースの ONNX モデルが含まれています。 ONNX チュートリアルでは、さまざまなシナリオやプラットフォームで ONNX を実際に使用する方法を説明するドキュメントとノートブックを提供しています。 Model Zoo は前回のワークショップ以降、Intel の新しい量子化モデル、定期的な CI テストによるテスト カバレッジの向上、壊れたテスト データセットの修正、Hugging Face チームと協力してモデルのデモ用の Web インターフェイスを作成するなど、いくつかの改善が見られました。
  
  
• 01:05:00 講演者は、ONNX を使用するためのチュートリアルとデモの可用性について説明します。これには、Python コードを数行書くだけで画像と ONNX モデルを簡単に処理できる Web サイトが含まれます。また、ONNX Model Zoo の将来のロードマップについても説明しています。ORT でより多くのモデルを実行できるようにし、量子化されたモデルやサンプル モデルのトレーニングなど、より多くの貢献を組み込む計画があります。さらに、ONNX モデルで使用するデータの前処理を容易にすることに重点を置いている ONNX Preprocessing Working Group の作業を強調しています。
  
  
• 01:10:00 ビデオのこのセクションでは、講演者がデータ前処理パイプラインの標準化の欠如について説明し、Pillow や OpenCV などの一般的なライブラリの画像前処理における違いを強調しています。これらの不一致は、モデルを異なるプラットフォームに展開するときに精度の問題につながる可能性があります。スピーカーは、あいまいさを回避し、モデルの展開を改善するために、データの前処理操作を標準化するという ONNX グループの目標を紹介します。このグループは、合成ユーティリティやバッチ処理用のシーケンス マップ オペレーターの開発など、データの前処理をモデルに含めるためのインフラストラクチャの開発に取り組んでいます。 ONNX グループは、バックエンドによる識別のために、モデルの前処理部分にタグを付ける方法も調査しています。さらに、このグループは、オプションのアンチエイリアシング フィルターや縦横比の保持ポリシーなど、サイズ変更オペレーターの拡張機能を提案しています。
  
  
• 01:15:00 講演者は、より高いレベルの抽象化を提供し、既存のパッドおよびスライス オペレーターに依存する、提案されたセンター クロップまたはパス操作の実装について説明します。 Slack チャンネルや毎月のミーティングに参加してアイデアを共有するよう視聴者に勧めています。次のプレゼンテーションは Joaquin Anton によるもので、ONNX 前処理ワーキング グループの目標を要約し、彼らが行ってきた最近の作業を共有しています。イタリア出身の Marvin は、自然言語処理の分野における開発者およびデータ サイエンティストとしての自身の仕事についても紹介しています。
  
  
• 01:20:00 スピーカーは、プロジェクトに取り掛かる前に ONNX のドキュメントを確認することの重要性について説明します。すべてのモデルを簡単に ONNX に変換または最適化できるわけではなく、プロジェクトに必要な操作機能が、使用しているフレームワークに確実に実装されていることが重要であると説明しています。さらに、スピーカーは、最良のパフォーマンス オプションが常にモデルを最適化するという仮定に反対するようアドバイスします。全体として、プロジェクトのアーキテクチャを慎重に検討し、ONNX のドキュメントと ONNX オプティマイザーなどのツールをチェックして、エラーを回避し、クラウドまたはデバイスへのデプロイを成功させることが重要です。
  
  
• 01:25:00 このセクションでは、Nvidia の Jiraj Perry が、ニューラル ネットワークの量子化の基本と、TensorRT がさまざまな融合を通じて量子化されたネットワークをサポートする方法について説明します。彼は、量子化とは、線形または非線形のスケーリング手法を使用して連続値を離散値セットに変換するプロセスであり、より高速な推論とより少ないメモリ フットプリントを提供できると説明しています。ただし、精度にはトレードオフがある場合があります。 Jiraj は、さまざまな量子化スキームと、量子化パラメーターまたは q パラメーターの重要性についても言及しています。次に、トレーニング後の量子化 (PTQ) と量子化を意識したトレーニング (QAT) と、それらが q パラメータを決定する方法を紹介します。
  
  
• 01:30:00 このセクションのビデオでは、トレーニング後の量子化 (PTQ) と量子化認識トレーニング (QAT) について説明します。 PTQ では、キャリブレーション データ セットで事前トレーニング済みのモデルを実行し、レイヤー単位の統計を収集して、量子化パラメーターを計算するための各レイヤーのダイナミック レンジを決定します。 QAT は、必要なレイヤーに qdq ノードを導入し、少数のエポックに対してグラフを微調整して、モデルまたは量子化パラメーターを学習します。 PTQ は一般的に高速で、最終的な精度を制御することはできませんが、QAT は低速ですが、精度をより細かく制御できます。このビデオでは、Google の TF Mod ツールキットと、TF Mod の上に構築された NVIDIA の TF2 量子化ツールキットのアプローチの違いも強調しています。
  
  
• 01:35:00 このセクションでは、スピーカーは、qdq ノードが配置される場所に関して、Nvidia の量子化ツールキットと tf mod の違いについて説明します。 Nvidia のツールキットは qdq ノードをネットワーク内の層の入力と重みに配置しますが、tf mod はそれらを層の重みと出力に配置することを推奨しています。講演者はまた、TensorRT が、qdq ノード専用のフュージョンとともに、ポイント ワイズ フュージョン畳み込みやプーリング フュージョンなどのレイヤー フュージョンを通じてモデルを最適化する方法についても説明します。さらに、TensorRT のグラフ オプティマイザは qdq 伝播を実行して q ノードと dq ノードを移動し、グラフの最大部分がインテークで実行されるようにします。提示された融合の例には、平均プール量子化と要素ごとの加算融合が含まれます。最後に、話者は残差ブロックの量子化融合を調べます。
  
  
• 01:40:00 このセクションでは、操作をリロードするときに Tensor RT から最高のパフォーマンスを得るために、ID ブランチに qdq ノードを追加することの重要性についてスピーカーが説明します。結果として得られる融合は、重みの dq ノードと入力が ad を超えて伝播され、追加レイヤーの後に q ノードと融合されるように見えます。講演者は、元のグラフで qdq ノードがモデルの最高のパフォーマンスを得るために必要であることを強調し、それらを適切に使用しないとモデルのパフォーマンスが低下する可能性があることを警告します。スピーカーは、TensorFlow ツールキットに qdq ノードを挿入する方法についてのディスカッションを招待して締めくくります。
  
  
• 01:45:00 このセクションでは、講演者はスライドをナビゲートする際の技術的な問題を認識し、聴衆にすぐに修正されることを保証します。次に、量子化および微調整された TensorFlow 保存モデルを取得した後、精度に関するケース スタディの議論に移ります。聴衆は、短い休憩を取る前に質問をするように招待されています。
  
  
• 01:50:00 このセクションでは、スピーカーは量子化の概念と、それを使用してニューラル ネットワークの量子化における低精度を表現する方法について説明します。量子化は、浮動小数点値を整数値にマップする量子化関数と、整数値を浮動小数点表現に戻す量子化関数の 2 つの関数の組み合わせです。これら 2 つの機能の組み合わせは、疑似量子化と呼ばれます。このプロセスにより、表現を整数のみの表現にマッピングできます。特に精度を落とした一様量子化の使用により、rf サッカー プラットフォームで 3 マイクロ秒未満のレイテンシで 1 秒あたり 17 億のサンプルが可能になりました。
  
  
• 01:55:00 このセクションでは、スピーカーは、特に 8 ビット未満の低精度の量子化を表現する際の ONNX の制限について説明し、クリッピングを活用して量子化ノードと逆量子化ノード間の精度を誘導することにより、ONNX の表現力を拡張する戦略を提案します。 .この戦略は、整数の境界を越えてサポートされる追加のクリッピング関数を追加し、既存のライブラリやツールとのレトロ互換性には影響しません。ただし、この戦略は、量子化された線形が演算子として使用できる範囲でのみ拡張され、さまざまなタイプの丸めに関していくつかの制限があります。スピーカーは、指数方言 (tuonex) の量子化に関する取り組みについても言及しています。これは、入力ブロードキャスト、バイナリ量子化オプションなどを使用してより幅広いシナリオ セットに拡張しながら、1 つのノードでの偽の量子化を表します。この形式は、fpgas での展開作業の一環として利用され、q ONNX や nqcdq などのツールは既存の量子化ライブラリと統合され、fpga コミュニティで採用されています。
  
  

• 02:00:00 このセクションでは、Mithril の Daniel が、ハードウェアを活用してデータを保護するセキュアなエンクレーブ内に ONNX モデルを展開できるようにする「ブラインド AI」と呼ばれるソリューションを開発した方法について説明します。このソリューションは、ハードウェア ベースのテクノロジを使用して、エンクレーブのメモリ コンテンツの分離と暗号化を提供し、外部からのダンプの試みを防ぎます。データはエンクレーブ内で復号化され、悪意のある内部関係者はデータにアクセスできません。これは、プライバシーとセキュリティに関してデータ所有者にとって大きな利点です. Blind AI は、オンボードが容易なオープンソース ソリューションであり、AI プロバイダーがこのソリューションを簡単に維持および販売できます。
  
  
• 02:05:00 このセクションでは、第三者にデータへのアクセスを許可することなく、Python SDK を使用してモデルを安全にアップロードし、分析用のデータを送信して、進行保証付きの AI モデルを展開する機能について講演者が説明します。 ONNX の表現力も際立っており、荷物のスクリーニング、医療文書の分析、顔認識など、さまざまなユース ケースをカバーできます。スピーカーは、実際に使用されるさまざまなモデルと、エンクレーブの内外でのそれらの速度も示します。また、スピーカーが提供する保護により、妥当な遅延が追加されます。さらに、ONNX は最小限のコード ベースを必要とするため、セキュリティ上の理由から改善され、各オペレーターを強化して、安全なエンクレーブの使用を保証できます。プレゼンテーションは、GitHub に関する情報と、さまざまなシナリオをカバーする方法、および技術的なセキュリティの詳細を掘り下げる機会で締めくくられます。
  
  
• 02:10:00 このセクションでは、講演者は、ONNX で機械可読 AI メタデータを有効にするための提案について説明します。これには、モデルの来歴やその他の関連する特性を追跡して、特定のユース ケースで時間の経過とともにどのように移動し、進化するかを特定することが含まれます。この提案は当初、2020 年 10 月に ONNX 運営委員会に提示されました。現在、チームは提案をさらに拡張して、モデル ハブと動物園。講演者は、責任ある説明可能な AI を可能にする重要な要素としてのメタデータの重要性を強調し、失敗モードを絞り込み、AI システムの問題点を特定する上でメタデータが有用であることを強調します。
  
  
• 02:15:00 ONNX コミュニティ デイ プレゼンテーションのこのセクションでは、講演者は、モデルにおけるメタデータの重要性と、RDF を使用して、メタデータを表現するためのより機械可読で標準化されたアプローチを実現する可能性について議論します。彼らは、このアプローチがエンティティ間の関係を確立し、透明性を維持し、来歴を追跡するのにどのように役立つかを説明し、モデルの精度が予想よりも低くなった原因についての質問に答えます。また、講演者は、SPARQL を使用してメタデータをクエリすることの威力についても説明し、RDF 形式のメタデータを含むモデルが、単純なモデル カードが提供できる以上の情報をどのように提供できるかを説明します。
  
  
• 02:20:00 このセクションでは、データとデジタル資産をアクセス可能、相互運用可能、再利用可能にするための指針となる一連の Furnace コントロール語彙について講演者が説明します。 Furnace の原則は、セマンティック Web コミュニティによって特定され、公平性、信頼性、および持続可能性が含まれます。 RDF でエンコードされたメタデータは、Furnace オントロジーを使用してクエリを実行し、NLP タスクに適したモデルを発見し、モデルの作成者とサイズを特定し、モデルの二酸化炭素排出量を追跡して分類およびソートできます。 RDF とそのクエリ言語である Sparkle の拡張性により、試験当局が選択した語彙を超えた無限の拡張性が可能になります。これにより、責任ある AI と混合精度電流の追跡が可能になります。
   
  
• 02:25:00 このセクションでは、プレゼンターが ONNX Community Day のクエリ機能とフィルタリング機能について説明します。これらは、メタデータ作成者が、メタデータ タグを使用して、プライベートまたは個人情報を含むデータセットでトレーニングされたモデルを識別する方法を示しています。また、プレゼンターは、拡張されたフィルタリング機能により、ユーザーが混合精度でモデルをクエリできるようにする方法も示します。モデル プロファイルの視覚化と、メタデータを効率的に表示するための説明可能な AI 手法が強調されています。プレゼンターは、ONNX で機械可読メタデータをサポートするハブ ワークフローからのメタデータの作成、クエリ、およびフィルタリング全体をカバーする、モデルの作成と使用に関する具体的な設計を検討するよう行動を呼びかけます。彼らは現在、ストローマンの実装を準備しており、メタデータ作成のためのテクノロジーを調査しています。
  
  
• 02:30:00 このセクションでは、Oracle Labs の Adam Pocock が、ONNX で Java 仮想マシン (JVM) をサポートすることの重要性について説明します。ほとんどの ML アプリケーションは Java などの Python 以外の言語で記述されていますが、これらの言語に機械学習を導入することは非常に重要です。 ONNX ランタイム Java API は、Oracle Labs によって開発され、機械学習を Java やその他の言語に組み込み、パフォーマンスへの影響を最小限に抑え、展開を容易にするなどの機能を備えています。 Adam は、Java API と他の API の類似点を示すコード例も提供しています。
  
  
• 02:35:00 このセクションでは、スピーカーはデータをフィードし、バイト ストリームのバイト バッファー表現である ONNX tensor を使用してモデルを実行する方法について説明します。 Java で通常の配列を使用することは可能ですが、講演者は、コピー パスがゼロであるためバイト バッファーを使用することを推奨しています。これにより、データ処理の効率が向上します。講演者はまた、Java の多次元配列はフラットではなく、多くのポインター追跡を伴うため、機械学習には最適ではないことにも言及しています。講演者は、Java の新しいバージョンへのアップグレード、新機能の追加、および ONNX ランタイム ツリーに合わせた構築の計画についてさらに説明します。さらに、講演者は、Java から ONNX モデルを作成するオープンソース ライブラリを紹介します。これは、JVM のどこからでも利用できます。
  
  
• 02:40:00 このセクションでは、DeepJ などの新しい機械学習ライブラリとの ONNX ツールセットの互換性と、ONNX ランタイムと統合して最高のパフォーマンスを提供する方法について講演者が説明します。 DeepJ は、さまざまなディープ ラーニング ライブラリ上に抽象化レイヤーを作成し、必要なすべてのライブラリを抽象化し、Apache MixTape、Tensorflow、PyTorch、ONNX、Pedal などの機械学習エンジンが使用する複数のオペレーター バックエンドを提供します。また、このツールセットのメタデータを標準化して標準のメタデータ形式を出力する方法を模索している一方で、オペレーターの列挙を拡張し続けています。
  
  
• 02:45:00 このセクションでは、画像分類、オブジェクト検出、感情分析、行動認識などのタスクをカバーする一連の事前トレーニング済みモデルを含む Deep Java Library の利点について講演者が説明します。このライブラリはすぐにサービスを利用でき、可能な限り最高の速度とメモリ制御で実行するための厳格なテストを経ています。これは、エラーなしで半年以上 DHL を使用して成功したことで実証されています。さらに、このスピーカーは、ONNX と ONNX ランタイムを使用してパフォーマンスを大幅に向上させ、レイテンシを削減したいくつかのユース ケースを共有しています。ある成功事例では、OCR モデルの実行時間を 1 秒から 400 ミリ秒未満に 1 枚の画像で短縮することに成功した中国の銀行が取り上げられています。さらに、このスピーカーは、ハイブリッド エンジンのコンセプトを導入しています。これにより、2 つのエンジンを同時にロードすることができ、エンジン間のスムーズな移行が可能になります。
  
  
• 02:50:00 このセクションでは、スピーカーはダイレクト バッファを使用して Python から ONNX ランタイムにポインタを直接送信する方法について説明します。これにより、データのコピーが回避され、パフォーマンスが向上します。また、より費用対効果の高いメモリ コレクションを提供するために、DeepDraw ライブラリに実装されたツリー状のアーキテクチャである ND Manager も導入しています。講演者は、お客様がコードを 1 行も変更せずに PyTorch の使用から ONNX ランタイムに移行する方法について説明します。その後、Hype Factors の講演者が、同社のメディア インテリジェンス企業について、また、開発者のエクスペリエンス、再利用可能なコンポーネントのエコシステム、および高いスケーラビリティのために、JVM を基盤とするインフラストラクチャをどのように選択したかについて語っています。
  
  
• 02:55:00 このセクションでは、スピーカーはメディア分析 Web サイトの技術的側面について説明します。これには、Web サイトのほとんどの機能を強化するための JVM の使用や、入ってくるすべてのデータを主に強化するシステムへの移行が含まれます。 1 日あたり数十億回の GPU 推論を行う製品の機能は、機械学習とモデル管理に大きく依存しています。これは、すべてを稼働させ続けるために不可欠な要素となり、プロセスの重要性につながっています。データには、HTML や PDF を含むあらゆる種類の形式が含まれており、ランタイムを追跡して、名前付きエンティティの認識、顕著性、感情などを含むデータをオンザフライで強化します。その過程で、変換エラーや DTL でまれに発生するメモリ リークなど、解決に時間がかかった多くの課題がありました。

[MetaQuotes]

ONNX コミュニティデイ！ 2022 年 6 月 24 日にライブ配信

このイベントは、6 月 24 日金曜日に真新しいマイクロソフト シリコン バレー キャンパスで直接開催されます。

このイベントでは、ONNX コミュニティの最新情報、パートナーとユーザーの事例、および多数のコミュニティ ネットワーキングが取り上げられます。

ONNX コミュニティデイ！

簡単な要約:

• 00:00:00 - 01:00:00 YouTube 動画「ONNX コミュニティ デイ！」機械学習モデルを扱う開発者向けの相互運用性と柔軟性に関する ONNX コミュニティの作業の更新と改善について説明します。 ONNX コミュニティはオープン ガバナンスの下で機能し、ツールの 3 つのカテゴリ (作成、実行、視覚化) がコミュニティの ONNX への関与と使用をサポートします。このビデオでは、ONNX 仕様の更新、新しいオペレーター、コンバーターの改善など、さまざまな側面に関する進捗レポートを提供します。また、講演者は、ハードウェア ベンダーにとって幅広い顧客層、ユーザーにとって複数のフレームワークとハードウェア アクセラレータへのアクセスなど、ONNX の利点についても強調します。 ONNX の将来には、実行可能な仕様を提供する ONNX 関数の概念が含まれます。
  
  
• 01:00:00 - 02:00:00 ONNX Community Day イベントでは、ONNX Model Zoo や、ONNX モデルで使用する事前トレーニング済みの機械学習モデルとデモを提供する ONNX チュートリアルなど、ONNX に関連する複数のトピックについて説明します。このビデオでは、データの前処理操作を標準化してモデルの展開を改善することを目的とした ONNX Preprocessing Working Group の作業に焦点を当てています。講演者はまた、ニューラル ネットワークの量子化の基礎と、TensorRT がトレーニング後の量子化や量子化を意識したトレーニングなど、さまざまな融合を通じて量子化されたネットワークをサポートする方法についても説明します。彼らはまた、低精度の量子化を表す際の ONNX の限界を掘り下げ、クリッピングを使用してその表現力を拡張し、量子化されたノードと逆量子化されたノード間の精度を誘導する戦略を提案しています。最後に、このビデオでは、量子化および微調整された TensorFlow 保存モデルの精度に関するケース スタディを詳しく説明しています。
  
  
• 02:00:00 - 03:00:00 ONNX コミュニティ デイでは、機械学習モデルにおけるメタデータの重要性と ONNX での Java 仮想マシン (JVM) サポートについて議論する多数のスピーカーが紹介されました。講演者は、データを保護するためにハードウェア ベースのテクノロジを使用することを強調し、DeepJ や Deep Java Library などのさまざまな機械学習ライブラリとの ONNX の互換性を強調しました。彼らは、効率を高めるためにバイト バッファを使用する方法を示し、信頼できる説明可能な AI のためにメタデータを標準化することの重要性について説明しました。プレゼンテーションでは、ONNX と ONNX ランタイムを使用して改善された中国の銀行のランタイムなどの成功事例も紹介されました。 ONNX コミュニティは、ハブ ワークフローからのメタデータの作成、クエリ、およびフィルタリングに取り組んでおり、ONNX での機械読み取り可能なメタデータをサポートしています。全体として、プレゼンテーションは ONNX プラットフォームの強みとその開発に対するコミュニティの取り組みを強調していました。
  
  
• 03:00:00 - 04:00:00 「ONNX コミュニティデイ！」ビデオでは、ONNX エコシステムに関連するさまざまな更新と機能について説明します。これには、量子化モデルと事前トレーニング済みモデルの間の精度低下を減らすための量子化のシミュレーション、NVIDIA のツールキットでトレーニングされた TensorFlow モデルの TensorRT を使用した ONNX グラフへの展開、最適化されたテンソル形状、実行プロバイダーなどの ONNX ランタイムの改善に関する議論が含まれます。モバイル プラットフォームのサポート。さらに、XNNpack ライブラリのサポートや、前後処理タスク用の ONNX ランタイム拡張機能の作成など、ONNX 自体の更新についても議論されました。このビデオでは、トレーニングから推論までの変換モデルの高速化に焦点を当てたライブラリ Optimum も紹介しています。
  
  
• 04:00:00 - 05:00:00 ONNX コミュニティ デイでは、ONNX ランタイムとそのユース ケースに関連するさまざまなトピックに関するディスカッションが行われました。講演者は、ONNX ランタイム パッケージ、PiTorch ONNX コンバーター、および PyTorch のカスタム Ops の機能について説明しました。また、プロセスの監視や商取引のデジタル化などのユース ケースや、モデルの展開や互換性テストに関連する課題についても説明しました。イベント全体を通して、ONNX ランタイムはパフォーマンスの向上と展開サイズの縮小に役立つことが強調されましたが、一貫した品質と速度を確保するには互換性と選択が不可欠です。
  
  
• 05:00:00 - 06:00:00 ONNX コミュニティ デイでは、ONNX フレームワークを使用して機械学習モデルを最適化および展開するために使用されるさまざまなツールや手法について話し合う複数のスピーカーが登場しました。 NVIDIA は、推論にブロック分割を使用して画質とモデルの互換性を向上させるアプローチと、モデルのデバッグと変更のための ONNX 固有のツールについて説明しました。 Qualcomm は、ONNX をインターチェンジ フォーマットとして使用して AI アクセラレータを設計に統合した方法を説明し、ONNX ランタイムと最適化と展開のためのさまざまなツールを含むソフトウェア スタックを紹介しました。さらに、何人かの講演者は、モジュールの最適化、チェックポイント、および形状の推論などの手法を使用して ONNX モデルを最適化することについて議論しました。このイベントでは、さまざまなデバイスのユース ケースに対する ONNX の汎用性とスケーラビリティが強調され、ONNX プロジェクトの成長を継続するための貢献が奨励されました。最後の部分では、SPIP 提案を使用して機械学習モデルを Spark にデプロイするプロセスを簡素化することに焦点を当てています。これは、開発者がタブ処理の変換とモデルの初期化の複雑さを隠すことを目的としています。 AI アプリケーションとサービスを構築するための API を提供するソフトウェア層「Kung」を含む、Ascend AI エコシステムとそのプロセッサが紹介されました。 Khan ソフトウェア スタックが議論され、それを ONNX ランタイムの新しい実行プロバイダーとして追加するためのロードマップが提示されました。イベントは、モバイルおよびエッジ用の ONNX、モデルの展開、トレーニングと運用、変換、オペレーターなどのトピックに関する円卓会議で終了し、ハッピーアワーとアンケートのフィードバックが続きました。

詳細なタイムラインの要約:

• 03:00:00 このセクションでは、講演者が ONNX エコシステムでの経験と、それを使用する際に直面した課題について話し合います。彼らは、ドライバーを一致させ、システムがスムーズに稼働し続けるように監視を設定する必要性について話しています。また、GPU の効率性を高め、モデルを追加し、GPU 高速化テストを通じてシステムの全体的な堅牢性を向上させるという将来の計画についても言及しています。スピーカーは、このユース ケースに関する質問やディスカッションを求め、全員に感謝の意を表します。昼食後、ビデオは NVIDIA トークのリプレイで再開されます。
  
  
• 03:25:00 申し訳ありませんが、このトランスクリプトの抜粋は「ONNX コミュニティ デイ」とは関係ありません。ビデオ。要約するために、ビデオから別の抜粋を提供してもらえますか?
  
  
• 03:30:00 ビデオのこのセクションでは、スピーカーは、量子化モデルと事前トレーニング済みモデルの間の精度低下を減らすために、量子化をシミュレートし、最終的な q パラメータを保存する方法について説明します。量子化を意識したトレーニングを実行する 1 つの方法は、TensorFlow モデル最適化ツールキットまたは Nvidia によって構築されたツールキットを使用することです。これは、レイヤー名とクラス属性を使用したレイヤーの量子化、およびパターンベースの量子化などの機能を提供します。スピーカーは、Nvidia のツールキットが 1 つの拡張機能を使用して GPU 上の QAT モデルに最高のパフォーマンスを提供する対称量子化バリアントを使用していることに注目しています。
  
  
• 03:35:00 このセクションでは、NVIDIA の TF2 量子化ツールキットを使用してトレーニングされたモデルを、TensorRT を使用して ONNX グラフに展開するプロセスについて学びます。ワークフローには、事前トレーニング済みの TensorFlow 2.0 モデルを NVIDIA のツールキットで量子化し、少数のエポックで微調整し、TF2ONNX コンバーターを使用して ONNX グラフに変換することが含まれます。次に、TensorRT の API を使用して、ONNX グラフから TensorRT Engine を生成します。量子化を意識したトレーニングは、より低い精度でディープ ニューラル ネットワークを展開するための代替手段を提供することがわかります。qrt モデルは、モデル パラメーターが微調整されているため、ptq モデルと比較して、推論中に精度が低下する可能性が低い可能性があります。最後に、ResNet モデルを使用した実験では、INT8 の精度が FP32 ベースラインの精度と同等であり、レイテンシが FP32 の対応するモデルと比較して 10 倍以上高速であることが示されています。
  
  
• 03:40:00 このセクションでは、作成以来 ONNX ランタイムに取り組んでいるソフトウェア エンジニアである Ryan Hill が、ONNX ランタイムの機能と使用法について話します。 ONNX ランタイムは、ONNX モデルのランタイムであり、完全にクロスプラットフォームであり、多くのプログラミング言語の言語バインディングを備えています。 Microsoft は、Windows、Office、Azure などの主要な製品グループすべてでそれを使用していますが、ONNX ランタイムを使用した実稼働モデルは 160 を超えています。 Hill は、最近のリリースで注目すべき新機能を経験しています。これには、運用カーネルを数学ライブラリとして使用する機能や、外部イニシャライザを完全にメモリに供給する機能が含まれます。パフォーマンスの向上には、転置オプティマイザーの追加、ヒープ割り当ての最適化、およびレイアウト変換の必要性の削減が含まれます。
  
  
• 03:45:00 このセクションでは、最適化されたテンソル シェイプやインライン ベクトル クラスなど、ONNX ランタイムに加えられた改善について講演者が説明します。これにより、ヒープ割り当てが削減され、パフォーマンスが向上します。また、フォールバック オプションとしての完全な CPU 実装など、ONNX ランタイムがさまざまなハードウェアの可能性で最適に実行できるようにする実行プロバイダーの利点についても説明します。さらに、モバイル プラットフォームをサポートするために行われた更新と、実行時の NHWC 変換の使用や、完全な ONNX ランタイム ビルドを使用した Android および iOS パッケージの追加など、モバイル開発者の使いやすさの向上が強調されています。最後に、ONNX ランタイムと同じコア コードベースとより小さなバイナリに支えられた ONNX ランタイム Web を紹介し、ONNX ランタイム コモンと呼ばれる JavaScript ライブラリの導入について説明します。
  
  
• 03:50:00 このセクションでは、XNNpack ライブラリのサポートや 1.12 リリースでの今後の OpenGL サポートなど、ONNX の更新について講演者が説明します。また、データの前処理と後処理、およびモデルの前後処理作業に焦点を当てた共有可能なカスタム ops のライブラリを提供する ONNX ランタイム拡張機能の作成に関する課題にも対処します。これらの拡張機能には、テキストを大文字または小文字に変換したり、正の値と負の値を別々のテンソルに分離したりするなどの潜在的な機能が含まれます。現在のライブラリは、主に自然言語処理と視覚およびテキスト ドメインに焦点を当てていますが、新しいニーズが特定されるにつれて、これは進化すると予想されます。また、Hugging Face の Jeff を紹介し、Transformers モデルを高速化するための ONNX と Optimum ライブラリの統合について説明しています。
  
  
• 03:55:00 このセクションでは、スピーカーは変圧器モデルの威力と、Tesla、Gmail、Facebook、Bing などの大企業が毎日何十億もの予測を行うためにそれらをどのように使用しているかについて説明します。彼らは、Hugging Face の目標は、すぐにアクセスできる事前トレーニング済みのモデルとそれらを利用するためのツールを通じて、世界中のすべての企業がこれらのモデルにアクセスできるようにすることであると説明しています。また、ライブラリへの 1,300 人を超えるオープンソースのコントリビューターと、すべての機械学習タスクおよび言語用に微調整された 50,000 を超えるモデルへのアクセスにより、可能なことを共有および改善するコミュニティの構築に重点を置いていることについても話し合っています。次にスピーカーは、トレーニングから推論までのトランスフォーマー モデルの高速化に焦点を当てたライブラリ Optimum を紹介し、モデル パラメータの増加に伴うコンピューティング、メモリ、および帯域幅リソースの課題に対処します。
  
  
  

• 04:00:00 このセクションでは、講演者は Optimum ツールキット内の ONNX ランタイム パッケージと、Transformer モデルのトレーニングと推論を加速するその機能について説明します。彼らは、ORT トレーナーと呼ばれる新しいトレーナー クラスを導入します。これにより、ユーザーは深い速度のネイティブ統合を実現し、トレーニングのスループットで最大 40% の加速を実現できます。推論には、ORT Optimizer、RT Quantizer、RT Model for Task の 3 つの主要なクラスがあります。これらのクラスを使用すると、ユーザーはモデルからグラフを単純化し、重みを最適化し、ONNX ランタイムによって提供されるすべてのハードウェア アクセラレーションを活用できます。講演者はまた、これらの最適化された加速された推論パイプライン クラスを通じて、シーケンスからシーケンスへのモデルの最適化を可能にするためのコラボレーションの取り組みについても言及しています。
  
  
• 04:05:00 このセクションでは、2 人のプレゼンターが ONNX コミュニティについて議論し、ONNX モデルの最適化と変換プロセスに焦点を当てています。最初のプレゼンターは最適なライブラリを紹介します。これにより、ユーザーはモデルを最適化および量子化し、モデルの精度を維持しながらスループットを向上させ、レイテンシを短縮できます。 2 番目のプレゼンターは、PiTorch ONNX コンバーターのアーキテクチャとフローについて説明し、PiTorch モデルをトーチ中間表現に変換する手順、グラフの最適化を使用して ONNX IR に変換する手順を説明します。また、量子化されたモデルを QTQ 形式でエクスポートするサポートや、ONNX モデルの Python 制御フロー ループと ifs を ONNX ループおよび ONNX if ノードとしてキャプチャするサポートなど、いくつかの興味深い機能も強調しています。
  
  
• 04:10:00 このセクションでは、スピーカーは、カスタム Torch オートグラフ関数の記述や forward および Backward メソッドの定義など、PyTorch でカスタム Op をエクスポートするさまざまな方法について説明します。講演者は、API を使用してカスタム シンボリック関数を登録し、それを標準の ONNX ops またはカスタム ドメイン内の任意のカスタム ops としてエクスポートする方法をエクスポーターに伝える方法を説明します。次に、ユーザーが特定の Torch モジュール クラスまたはノード タイプをバックエンドの関数として指定して、指定されたカーネルがなくてもモデルを実行できるようにする ONNX ローカル関数機能を導入します。最後に、スピーカーは、チームがより多くのモデルのサポートと障害診断のエクスペリエンスの向上に引き続き注力していくと述べています。
  
  
• 04:15:00 このセクションでは、既存のカメラ システムを再利用して、稼働中の機械の近くの危険なエリアに立ち入る従業員を検出するユース ケースについて説明します。人を検出するためのオープンソースの ONNX モデルと、リアルタイム分析およびイベント処理のための SAS の Sasebo Stream Processing ツールを使用して、1 秒あたり数百万のイベントを処理し、より大規模なシステムにスケーリングできるソリューションが開発されました。このソリューションは、データ サイエンティストがモデルを開発するためのグラフィカル スタジオと Jupyter ノートブックを通じても利用できるようになり、ONNX ランタイムは Sasebo Stream Processing に統合されました。復元力を確保するために、Kafka をバッファー キューとして使用して、画像処理をいくつかのステップに分割するモジュラー ソリューションが提案されました。
  
  
• 04:20:00 このセクションでは、スピーカーは、デプロイ メカニズムとして Kubernetes を使用してエッジにデプロイされたコンピューター ビジョン処理モデルについて説明します。このモデルには、各カメラ用のポッド、ビデオ データ用の Kafka バス、コンピューター ビジョン モデルを使用して結果を作成する処理ポッドを使用した取り込みプロセスが含まれています。次に、結果は 3 番目のポッドに送信され、顧客からの追加のセンサー データを処理して、記録されている機器がアクティブかどうかを判断します。さらに、スピーカーは、このアーキテクチャが現在顧客の施設の 1 つで運用中であり、ONNX ランタイム統合により、公開されている事前トレーニング済みモデルと顧客資産の再利用のおかげで、価値実現までの最適な時間が確保されると説明しています。アーキテクチャの回復力はもう 1 つの重要な利点であり、Kubernetes と Kafka のおかげで保証されています。
  
  
• 04:25:00 このセクションでは、Bazaar Voice の Matthew が、商取引のデジタル化と、ブランドや小売業者がインターネット上の無限の棚スペースに移行した方法について説明します。 e コマース企業が所有するデータの規模を考えると、AI を使用して影響力のある洞察を生み出すことは、ゲームチェンジャーになる可能性があります。 Matthew は、Bazaar Voice を例として使用してこれを説明します。Bazaar Voice は、月に 10 億人を超える買い物客のデータを管理および処理し、ブランドと小売業者に合計 80 億件を超えるレビューを提供します。カタログ全体で製品レビューを共有することに重点を置くことで、製品マッチングの概念が重要な役割を果たします。 Matthew は、固有の製品 ID を比較することによって製品マッチングを実行する機械学習モデルがどのように構築されているかを説明していますが、残りは手動で行われます。真のビジネス価値を生み出すソリューションを実装するための理想的なアプローチは、パフォーマンスを維持する軽量で費用対効果の高いソリューションです。
  
  
• 04:30:00 このセクションでは、仮想サーバー、クラウド ML プラットフォーム、Azure Cloud Functions や AWS Lambdas などのサーバーレス機能など、機械学習モデルをデプロイするためのさまざまなオプションについて講演者が説明します。各オプションの長所と短所を評価した後、講演者とそのチームは、ONNX 形式にエクスポートされた scikit-learn モデルを開発し、Python で構築し、それをサーバーレス機能にデプロイし、ノード環境を使用して ONNX で推論を実行することにしました。ランタイム。講演者は、ONNX はモデルのデプロイ サイズを削減するのに役立つことにも言及していますが、サーバーレス関数のタイムアウトとデプロイ サイズの制限内で作業することの課題、および Python パッケージのコストとサイズの制限を強調しています。
  
  
• 04:35:00 このセクションでは、Adobe Nikhil Calro のシニア ソフトウェア エンジニアが、ビデオおよびオーディオ ワークフローの高性能機械学習に伴う固有の課題について説明します。これらの課題には、リソースの制限、データ強度、計算負荷の高い要件が含まれます。これらの問題に対処するために、アドビはテクノロジーとパイプラインの組み合わせを使用してワークフローを高速化します。これには、Windows で機械学習ワークフローを強化する ONNX ランタイムや、Windows プラットフォームで GPU アクセラレーションを実現する Direct ML 実行プロバイダーが含まれます。 Calro 氏はまた、アドビの機械学習ワークフローは、クリエイターがクリエイティブ プロセスにより多くの時間を費やし、冗長で反復的なタスクに費やす時間を短縮できるようにすることを目的としていると述べています。
  
  
• 04:40:00 このセクションでは、Adobe の Creative Cloud アプリが Windows エコシステム全体を単一のプラットフォームとしてターゲットにし、Nvidia、Intel、AMD などの Windows をサポートするすべての主要な IHV で機能と機能の同等性を提供する必要があることについて話します。彼らは DirectML 実行プロバイダーを選択して、Nvidia GPU でテンソル コアなどのベンダー固有のハードウェアを使用できるようにしました。これにより、他の非同期コンピューティング ワークフロー用にハードウェアが解放されます。また、ONNX ランタイムの上にフレームワークを構築し、GPU とのリソースの競合を減らし、ドライバーのオーバーヘッドを最小限に抑えるために、推論要求をバッチ処理されたワークフローにアセンブルすることで、パフォーマンスをさらに最適化しました。彼らはシーン編集検出ワークフローの例を挙げています。これは非常にリソース集約的なワークフローですが、デコードから推論までパイプライン全体をエンドツーエンドで約 10 秒またはリアルタイムの 6 倍で実行できます。
  
  
• 04:45:00 このセクションでは、スピーカーは、ORT と Direct ML 実行プロバイダーによって提供されるパフォーマンスの有効化により、最新のハイエンド GPU を使用して、GPU レンダリング中に機械学習ベースのワークフローを有効にする方法について説明します。彼らは、パイプラインを右側のパイプラインのように見えるように移行し、CPU への転送を最小限に抑え、GPU または GPU でアドレス可能なハードウェアにできるだけ多くのものを保持することを計画しています。これは、より多くの GPU コンピューティングが DX12 に移行し、OP で OpenCL と CUDA から DX12 への移行に関連するオーバーヘッドが取り除かれるため、さらに簡単になります。
  
  
• 04:50:00 このセクションでは、Topaz Labs のソフトウェア開発者である Alexander Zang が、デスクトップとラップトップにイメージ モデルを展開する際の課題について説明します。彼は、この展開の重要な部分は、既存のワークフローに適合すること、手動構成なしで期待されるパフォーマンスを得ること、および高品質の画像モデルを提供することであると説明しています。アレクサンダーは、サーバーの展開とは異なり、デスクトップの展開はシステムを制御できないと説明しています。特に、さまざまなレベルのメモリと応答性の制約があるさまざまなベンダーのさまざまな GPU ではそうです。これに対する彼の解決策は、ONNX が提供するハードウェア ベンダーごとに異なる推論ライブラリに依存することです。このアプローチにより、Topaz Labs は手動作業を節約しながら、さまざまな推論ライブラリで使用できるモデル アーキテクチャを作成できます。
  
  
• 04:55:00 このセクションでは、スピーカーは、モデル変換に関連する課題と、モデルをトレーニングする前に互換性の問題をテストする必要性について説明します。モデル仕様のあいまいさの問題と、パフォーマンスと一貫性についてさまざまなライブラリをテストする必要性が強調されています。スピーカーは、複数の変換を実行する理由についても説明し、より一般的なインターフェイスを使用すると、追加の読み込み手順と変換コストが発生し、アプリのパフォーマンスに影響を与える可能性があると述べています。最後に、適切な構成を選択し、ランタイム推論パイプラインを処理するプロセスについて説明し、デスクトップから一貫した品質と速度を確保しながら、互換性と選択の必要性を強調します。

• 05:00:00 このセクションでは、NVIDIA の講演者が、ONNX モデルの互換性を処理し、イメージをブロックに分割して推論によって実行し、スループットを最大化し、複数のデバイスやライブラリで実行する可能性があるデスクトップ システム全体のイメージ品質を向上させるアプローチについて話します。並行して。講演者はまた、新しいモデル アーキテクチャを追加し、すべてのライブラリで適切に動作させることの難しさについても説明します。これには多くの作業と時間がかかる可能性があります。次に、ONNX モデルを作成および変更できる Python ライブラリである ONNX Craft Surgeon と、ディープ ラーニング モデルをデバッグするためのツールキットである Polygraphy の 2 つのツールについて説明します。スピーカーは、これらのツールがどのように機能するか、および tf グラフを作成するのと同じくらい簡単なモデルを作成するためにどのように使用できるかを説明します。
  
  
• 05:05:00 このセクションでは、講演者が ONNX ツールを紹介します。これには、Python API と、ONNX モデルを操作するための多くの機能を提供するさまざまなコマンドライン ツールが含まれています。講演者は、ONNX モデルのテキスト表現を表示するモデルの検査や、モデル内の定数を単純化して折り畳む外科医がサニタイズしたサブツールなど、ONNX 固有のツールに焦点を当てています。外科医抽出を使用すると、ユーザーはモデルからサブグラフを抽出してデバッグできます。モデル bisector デバッグ削減は git bisect のように機能しますが、ONNX モデルの場合は、システム内のエラーを診断するために最小の失敗モデルを見つけることができます。
  
  
• 05:10:00 このセクションでは、プレゼンターは Calligraphy debug reduce ツールを使用して、実行時の問題がある可能性のあるモデルをデバッグする方法について説明します。モデルのサイズを縮小し、各中間モデルをテストすることで、開発者はコード内の問題のある領域を特定し、デバッグ プロセスを容易にすることができます。また、プレゼンターは、イヤホンからラップトップ、車載システムまで、さまざまなデバイスで使用できる交換フォーマットとして ONNX を使用することで、Qualcomm がどのようにコミュニティと協力しているかについても説明します。 ONNX を使用してモデルをターゲットにすることで、開発者は Qualcomm がサポートするすべてのデバイスと互換性のあるモデルを作成できます。
  
  
• 05:15:00 このセクションでは、スピーカーは、さまざまなモデル、実装、およびタイミング要件を必要とするデバイスのさまざまなアーキテクチャに対処する際の課題について話します。彼は、携帯電話の深度センサーとカメラ用に構築されたものと同じアルゴリズムと技術が、自動車の安全なスマート ドアベルや車内外の監視カメラに使用されている例を挙げています。次に、スケーラビリティの重要性を強調し、CPU、GPU、および AI アクセラレータでの処理マシン アルゴリズムの違いを、AI アクセラレータで実行すると 1 秒あたり最大 1000 の推論を提供できる Inception V3 モデルを実行する例を使用して比較します。他の有用なタスクのために CPU を解放します。
  
  
• 05:20:00 このセクションでは、Qualcomm の担当者が、人工知能 (AI) アクセラレータをハードウェアに統合してパフォーマンスとスケーラビリティを向上させた方法について説明します。専用の AI アクセラレータを使用することで、CPU や GPU を使用することでしばしば発生する余分なエネルギー消費や速度低下を招くことなく、AI ワークロードを処理できます。さらに、同社の ONNX 交換フォーマットにより、さまざまなデバイスや業種にわたって機械学習モデルをコンパイルおよび実行できるため、会社の時間を節約し、移植性を高めることができます。また、さまざまなオペレーティング システムをサポートし、ハードウェアの詳細を隠して顧客がハードウェアを使いやすくする、統一されたソフトウェア スタックとライブラリも作成しました。
  
  
• 05:25:00 このセクションでは、クアルコムが ONNX を中心に開発したソフトウェア スタックをスピーカーが紹介します。彼らは、ONNX ランタイムを含む完全なソリューションと、デバイスのユースケースに応じてモデルを CPU または GPU にルーティングする委任システムを構築しました。講演者は、コンパイラ、プロファイラー、アナライザー、ネットワーク アーキテクチャ検索ツールの有効化など、彼らが開発した多くのツールについて説明します。このスピーカーは、ONNX のスケーラビリティと汎用性、およびカメラ アルゴリズム、スマート スピーカー、XR デバイスなどのさまざまなデバイスのユース ケースでの使用方法を強調しています。
  
  
• 05:30:00 このセクションでは、スピーカーは ANITA コンパイラの開発プロセスについて説明します。ANITA コンパイラは、さまざまなアーキテクチャ間での最適化を容易にし、さまざまな環境にモデルを展開するために、Mair で参照方言を提供するために使用されます。講演者は、カスタム アクセラレーターをサポートするために導入したフレームワークについても強調します。これにより、アップロードするオペレーターを選択し、アクセラレーターを簡単にオン/オフできるようになります。スピーカーは、ONNX モデルが徐々に中間表現に下げられる ONNX Mlir で最適化がどのように展開されるかの概要も提供します。
  
  
• 05:35:00 このセクションでは、スピーカーは ONNX コンパイラと、CPU とアクセラレータの最適化に複数の方言がどのように使用されているかについて話します。高レベルの最適化にはグラフ レベルの最適化が含まれ、低レベルでは CPU とアクセラレータの操作に最適化が適用されます。講演者は、コンパイラのアクセラレータ フレームワークがどのように機能するかの例を示します。アクセラレータを使用すると、CPU で実行するよりも 11 倍高速になります。また、ディープ ラーニング オペレーターの最適化にどのように重点を置いているかについても言及しており、オンライン機械学習オペレーターや CPU などの他のアクセラレーターをサポートする予定です。最後に、彼らは貢献者に感謝の意を表し、ONNX プロジェクトを成長させ続けるためのさらなる貢献を求めます。次の講演者である Preferred Networks は、ONNX の中間表現を使用するニューラル ネットワーク コンパイラである PFVM を紹介します。
  
  
• 05:40:00 このセクションでは、Compile チームのメンバーが、モジュールの最適化における ONNX の使用例、特に安定した十分に文書化された中間表現に関して説明します。チームは ONNX を使用して、デバイスの変更やメモリを最適化するためのデバイス情報の追加など、顧客のオペレーターと ONNX を拡張することで、さまざまな最適化パスでモデルを最適化します。また、モジュールの最適化における形状推定の重要性についても説明し、3 つの最適化ケースを紹介します。最初のケースでは、複数の要素単位の演算子を単一の融合群演算子に融合することで、CUDA で実行される計算グラフのカーネル範囲のオーバーヘッドを削減します。
  
  
• 05:45:00 モデルがニューラル アーキテクチャ検索のようなプログラムによって生成された場合、パスには多くの不要な演算子が含まれます。ここで、形状の推定やグラフの単純化などの最適化が役に立ちます。隣接する要素ごとの演算子を融合できるかどうかを判断するには、形状の推定が重要ですが、グラフを単純化すると、後方パスから不要な演算子を削除できます。これらの最適化はどちらも、必要な計算の数を大幅に削減し、モデルの全体的な効率を向上させることができます。
  
  
• 05:50:00 このセクションでは、スピーカーは、モジュール実行時のメモリ使用量を削減するチェックポイントの手法について説明します。計算グラフを変更することで、メモリ使用量をさらに削減できますが、レイテンシが増加します。スピーカーは、メモリ使用量を見積もるためにテンソルのサイズを知ることの重要性を強調し、未知の次元を扱う場合の自動チェックポイントの限界を述べています。さらに、スピーカーは、未知の次元が最適化の機会に与える影響について説明し、ONNX 形状推論に加えられた改善点について概説します。具体的には、ONNX 1.10 でのシンボリック推論の導入により、データ伝播による形状推論が大幅に改善されました。
  
  
• 05:55:00 このセクションでは、講演者は ONNX での形状推定について説明し、形状情報は静的なケースでは上からグローバルに伝播できるが、動的なケースではより多くのサポートが必要であることを説明します。スピーカーは、形状変更の形状を推定する必要がある ONNX グラフの例を示していますが、現時点では不明です。彼らは、動的なケースに対してより多くの形状推定関数を実装することを提案し、異なるサイズの 2 つのテンソルの連結などのケースのサポートが必要かどうかを尋ねています。講演者はまた、md4 スーパーコンピューターの最適化についても簡単に説明します。md4 スーパーコンピューターは、静的形状を持ち、動的分岐を持たないモデルのみを受け入れ、スケジューリングと最適化に静的情報を使用します。次に、Huawei の代表者が、推論のために ONNX の能力を Spark にもたらすことについて、事前に録音された講演を共有します。
  
  

• 06:00:00 このセクションでは、一般に SPIP として知られている SPARK 改善提案に焦点を当てています。これは、機械学習モデルを Spark に展開するプロセスを簡素化し、サードパーティの DL フレームワークと統合することを目的としています。この提案は、Spark に DL モデルをデプロイする必要があるデータ エンジニアまたは開発者を対象としています。最終的な目標は、タブ処理の変換とモデルの初期化の複雑さをモーダル UDF 内に隠し、ユーザーがビッグ データで ONNX 推論を簡単に完了できるようにすることです。 Ascend と呼ばれる Huawei 独自の AI プロセッサが導入され、Ascend プラットフォームで SPARK と ONNX パイプラインを完了するには、最初に ONNX ランタイムで Ascend サポートを導入する必要があると説明されています。
  
  
• 06:05:00 このセクションでは、講演者が Ascend AI エコシステムとそれがサポートするさまざまなプロセッサについて説明します。 Ascend 310 は AI 推論のみをサポートしますが、Ascend 710 と 910 はトレーニングと推論の両方をサポートします。さらに、エコシステムは、開発者が AI アプリケーションとサービスを簡単に構築するための API を提供する「Kung」と呼ばれるソフトウェア層を提供します。次にスピーカーは、Ascend エコシステムの現在のソフトウェア スタックである Khan と、最新バージョンの Khan 5.0 に焦点を当てます。 Khan のさまざまなレイヤーと、Khan がオペレーター ライブラリー、最適化エンジン、および開発者向けのフレームワーク アダプターを提供する方法について説明しています。次にスピーカーは、Khan を ONNX ランタイムの新しい実行プロバイダーとして追加し、ユーザーが Ascend ハードウェアで ONNX モデルを直接実行できるようにするためのロードマップについて説明します。
  
  
• 06:10:00 ビデオのこのセクションでは、ONNX コミュニティ デイの締めくくりとして、直接出席者のための円卓会議が行われます。円卓会議は 6 つの異なるトピックで構成され、出席者が書き込める大きなメモ帳が用意されていました。トピックは、出席者からの提出物に基づいて選択され、モバイルおよびエッジ用の ONNX、モデルの展開と機械学習の量子化、トレーニングと運用、変換、およびオペレーターが含まれます。 ONNX ランタイム チームも会話に参加することができました。円卓会議の後、参加者は食べ物や飲み物でハッピーアワーを楽しみ、フィードバックを提供するためにアンケートに記入するよう促されました。