Core AI

インストール

このフォーマットはmacOS専用です。coreai-torchの依存指定には sys_platform == 'darwin'マーカーが付いており、ツールチェーンは他のどこでも変換も 実行もできません。

# すべての集約extraから意図的に除外。coreai-torchがtorchを2.11.xに固定し、# 環境全体をそのバージョンに引きずり込むためpip install "libreyolo[coreai]"

このextraは、coreai-torchがtorchを2.11系に固定するため、libreyolo[all]を含む すべての集約extraの外に置かれています。その組み合わせに縛られても構わない環境に インストールしてください。

エクスポート

from libreyolo import LibreYOLO model = LibreYOLO("LibreYOLO9t.pt") # weights/LibreYOLO9t.aimodelを書き出すpath = model.export(format="coreai", imgsz=640)print(path)

libreyolo export --model LibreYOLO9t.pt --format coreai --imgsz 640

model.export(    format="coreai",    imgsz=640,        # int、または(height, width)。これが実行キャンバス    batch=1,    output_path=None, # Noneならweights/<stem>.aimodelに書き出す) # dynamic=TrueはNotImplementedErrorを送出# half=Trueとint8=Trueは検証時に拒否される

キャプチャはtorch.exportであり、単一の記録されたトレースではなく、ガードを伴う 本物のグラフキャプチャです。これはCore MLの経路より厳格です：ホスト側のスカラー 読み取りやデータ依存の制御フローは黙って焼き込まれるのではなく拒否されるため、 いくつかのファミリーはキャプチャ失敗が記録されたうえでここではブロックされて います。

3つの準備ステップは、エクスポートが成功しても失敗しても呼び出し元の実モデルを 復元するスコープの中で実行されます。Darknet系のファミリーでは、Core AI 0.4.1が Darknetの平方根の後にイプシロンを足す式を保持しないため、推論時のバッチ正規化が 直前の畳み込みに厳密に畳み込まれます。グリッド系とアンカー系のファミリーでは、 固定キャンバス向けにアンカーが凍結されます。RF-DETRでは、コンバーターに aten._upsample_bicubic2d_aaのローワリングがないため、モデル自身のベイク経路を 再実行して位置埋め込みが要求されたキャンバス向けに再ベイクされます。

ローワリングでは、Core AIコンバーターにDETR系ファミリーが使うデフォーマブル アテンションのサンプラーのローワリングがないため、aten.grid_sampler_2dに対する PyTorchの参照分解を分解テーブルに組み込みます。

アセットは最小OSとしてv27を宣言しますが、これはツールチェーンが提供する唯一の値 です。これが制限するのはデプロイであって変換ではありません：変換とPython側の実行 はwheelに含まれるランタイムを通じてより古いmacOSでも動作しますが、数値はOSの バージョン間で異なるため、記録されたパリティはmacOS 27で測定しています。

アーティファクトを実行する

libreyolo/backendsにCore AIのエントリはないため、LibreYOLO()は.aimodelを 読み込みません。利用側はCore AIランタイムを直接使い、前処理、デコード、NMS、座標の リスケールは利用側の担当です。サポートマトリクスで検証済みとなっている行は、 エクスポートされたグラフが参照と同じ数値を計算するという主張であって、predictが それを実行するという主張ではありません。

利用側が自力で再導出できない唯一のものが、出力の順序です：

from libreyolo import LibreYOLO model = LibreYOLO("LibreYOLO9t.pt")model.export(format="coreai", imgsz=640) # アセットのメタデータは、エクスポートされた出力名をグラフ順で# "coreai_output_names"に記録する。Core AIが返す辞書はそのリストを使って# 名前でマッピングし、eagerのタプルと位置で対応づけないこと

Core AIが返すのは名前付きの辞書で、そのキーの順序はeager forwardのタプル順とも、 推測できる何かとも一致しません。エクスポートされた名前がまさにこの理由でアセットの メタデータにcoreai_output_namesとして書き込まれます。名前でマッピングしてくだ さい。

制約

固定キャンバス、FP32、バッチはエクスポート時のまま。dynamic=Trueは NotImplementedErrorを送出し、half=Trueとint8=Trueは検証時に拒否されます。

変換側の対応範囲は広いです。検証済みの組み合わせには、YOLO9系ファミリー、YOLOX、 YOLO7、Darknet時代の4つの検出器、YOLO-NAS、PicoDet、RTMDet、RT-DETR、RT-DETRv2、 RT-DETRv4、D-FINE、DEIM、DEIMv2、EC、RF-DETRの物体検出、4つのCNN分類ファミリーと クラス固定のCLIPおよびSigLIP2、Depth Anything V2とZipDepth、NAFNetとReal-ESRGANの 復元、PIDNetとLingBotVisionのセマンティックセグメンテーション、そしてFOMOの点検出が 含まれます。それぞれに独自の記録済みコンテキストがあり、libreyolo formatsがそれを 出力します。

ブロックされているものと、組み合わせごとに記録された理由：

RF-DETRには、アーティファクトを比較する前に読んでおく価値のある注意点が1つ あります。そのパリティはONNXではなくCore AIエクスポーター自身が準備するグラフに 対して記録されており、640のキャンバスではRF-DETRのONNXアーティファクトはその準備 済みグラフと一致しません。Core AIの再ベイクはeagerモデルが行うアンチエイリアス付き リサイズを保持しますが、ONNXの経路ではアンチエイリアスが無効になります。したがって ONNXは、ネイティブでないキャンバスではそのファミリーの有効な参照になりません。

Appleの以前のフォーマットについてはCore MLを参照してくだ さい。ファミリーとタスクの完全な一覧はエクスポートマトリクスを 参照してください。1つの組み合わせについては：

libreyolo formats --family yolo9 --task detect