ホームへ戻る

GitHub Repo

NpunlockがIntel NPUのカスタムCカーネルを検証、同一グラフで精度の異なる独立ブランチを実行

既存のIntelドライバーで計算グラフをコンパイルし、SHAVEカーネルを置き換えることで、カスタムCプログラムをNPU上で実行する。新たなテストでは2種類の精度を持つ独立ブランチを検証したが、任意の混合精度パイプラインにはまだ対応していない。

Jacek Halicki · CC BY-SA 4.0 · Image source
zh-Hant

オープンソースプロジェクトのNpunlockは、9月23日に公開した進捗報告で、同一のIntel NPUネイティブ計算グラフ内で、互いに独立したFP32の単一入力カスタムブランチとFP16の2入力カスタムブランチを実行した。作者は実行可能なサンプルを提供し、両ブランチの結果がホスト側の参照結果と一致したことを記録している。この更新によりカスタムカーネルの組み合わせ方が広がったが、異なる精度の処理を直列につないだパイプラインも動作することが実証されたわけではない。[実験記録](https://github.com/hsfzxjy/npunlock/blob/master/wiki/REVERSE_ENGINEERING.md)

この手法では、まず既存のIntelドライバーに計算グラフをコンパイルさせる。コンパイラーが認識できる演算子をカスタムノードの代わりに置き、テンソルのレイアウト、スケジューリング、データ転送、同期の構造を取得する。一方、別の処理経路ではMoviToolsを使い、CソースコードをSHAVEマシンコードにコンパイルする。ツールは呼び出しインターフェースとテンソルの条件を照合した後、周辺の実行構造を保持したまま、指定した演算のコードを置き換える。OpenVINO形式の中間表現を使用するが、実行時にOpenVINOパッケージをインストールする必要はない。[アーキテクチャの説明](https://github.com/hsfzxjy/npunlock/blob/master/wiki/HOW_NPUNLOCK_WORKS.md)

混合精度のサンプルでは、コンパイラーによる並べ替えの影響も明らかになった。ネイティブグラフ内のブランチの順序がフロントエンドの走査順序と異なったため、自動対応付けでは処理が拒否された。作者はまずコンパイルして内容を確認し、入力数と要素幅に基づいて対象を指定することで、2つのカーネルの組み込みに成功した。別途行った、処理を接続して精度を変換する実験では、入力と出力のバイト範囲が異なるため、検証器に拒否された。こうした失敗例も、現時点で再現可能な範囲を明確にしている。[検証の詳細](https://github.com/hsfzxjy/npunlock/blob/master/wiki/REVERSE_ENGINEERING.md)

作者はHacker Newsで、想定用途として、あまり使われないニューラルネットワーク演算子の補完、精度が重要な演算の提供、呼び出し回数を減らすための複数の小さなカーネルの融合を挙げている。これらはエッジ推論に有用な方向性だが、融合によって性能が向上するかどうかは、まだ検証が必要な仮説だ。現時点の資料には、モデル全体のスループットや消費電力の比較は示されていない。[作者による議論](https://news.ycombinator.com/item?id=49800513)

導入上の制約は具体的だ。検証済みの環境はWindows x64とMeteor LakeのNPU3720のみで、対応範囲は静的シェイプと既知のテンソルレイアウトが中心となる。Linux、新世代のNPU、任意の計算グラフについては、今後の検証が必要だ。プロジェクトはApache-2.0を採用しているが、外部依存のMoviToolsはプロプライエタリであり、旧版のドライバーパッケージから別途抽出する必要がある。プロジェクトは、ツールチェーンのみを取り出し、そのドライバーをインストールしたり、そのバージョンへダウングレードしたりしないよう求めている。エンジニアが次に行うべきことは、ドライバーのバージョンを固定し、カーネルごとにホスト側の結果と照合したうえで、データ転送と全体のレイテンシーを測定することだ。計算グラフの読み込みに成功しただけで、数値的な正しさが証明されたと判断してはならない。[プロジェクトのドキュメント](https://github.com/hsfzxjy/npunlock)

出典

  1. hsfzxjy/npunlock
  2. Reverse-engineering breakthroughs
  3. How npunlock works