Core AIについて

こんにちは BenといいますCore AIチームの エンジニアです。

本日はCore AIの概要と アプリにインテリジェントな機能を 追加する方法をご紹介します。 AIはかつてないスピードで 進化しています。 以前は実現不可能と思われていた 新しいモデルや機能が 次々と登場しています。 Core AIはその勢いを活かし さらに発展させるために構築されました。

Core AIはAppleプラットフォームにおける オンデバイスAI実行の 次世代の進化です。 最新のワークロードに向けて ゼロから構築されており 高度なAI機能を構築するために 必要な 高性能な推論を提供します。 Core AIはオンデバイスの Apple Intelligenceを動かす推論フレームワークです。 そして今 皆さんも利用できるようになりました。 アプリ独自のインテリジェンスに 同じ力をもたらします。 Core AIは単なるフレームワークでは ありません。 モデルデプロイのライフサイクル全体をカバーする 完全なテクノロジーセットです。 モデルの最適化とコンバージョンから デバッグおよびアプリへの 統合まで対応します。 優れたAI機能の構築に欠かせない 高速で反復的なサイクルを サポートするよう設計されています。 Core AIはApple Siliconを 最大限に活用できます。 CPU GPU Neural Engine全体で 超高速の推論を実現します。 このフレームワークにはモダンな Swift APIが付属しています。 アプリが求めるパフォーマンスを提供する 表現力豊かなAPIで メモリ安全性も犠牲にしません。

より広範なテクノロジーセットは 一般的なML エンジニアリングワークフローに 自然に溶け込みます。 使い慣れたPythonとPyTorchの基盤を 活用して モデルのオーサリング 最適化 そしてコンバージョンを行います。 Core AIはきめ細かな推論管理や モデルの特化から カスタムGPUカーネルまで 広範なカスタマイズも サポートします。 これらすべてが新しいデベロッパ ツールチェーンと緊密に統合されており 事前コンパイル 専用のCore AI Instruments そして強力なビジュアルデバッガが テンソル値を元のPythonソースコードまで 直接トレースできます。 Core AIはニーズと利用可能な コンピューティングに合わせてスケールします。 小規模な話者分離モデルで ライブ会議中の発言者を識別したい場合も スピーカー分離モデルで対応できます。 ユーザーがカメラを任意のものに向けて 質問を投げかけ 大規模なビジョン言語モデルで 即座に回答を得たい場合も または複雑なマルチステップタスクを 700億パラメータのLLMが動かす 強力なエージェントアシスタントに任せる場合も Core AIが対応します。 すべてAppleデバイス上で ローカルに動作し サーバー不要でトークンコストもかかりません。 このセッションではまずモデルを Core AI形式に変換する方法を解説します。 次に変換したモデルをアプリに 統合する方法を説明します。 その後 少し深掘りして モデルとアプリの パフォーマンス最適化を取り上げます。 最後にCore AIの追加機能と 関連ツールの中で役立つものを ご紹介します。 では始めましょう。 素晴らしいアプリ体験はすべて アイデアから始まります。 少し魔法のような感覚を 提供するものを作りたいとか インテリジェントに反応するものとか 人間の判断やハードコードされたルールを 必要とする意思決定を行うものとか。 そういった体験を可能にするのが 機械学習とAIです。 そのアイデアが決まったら 次のステップはそれを実現できる モデルを見つけるか作ることです。 アイデア自体が時間とともに 進化していくように 適切なモデルを見つけることも 反復的なプロセスです。 試して要件に照らして評価し 改善していきます。 Core AIはその反復をサポートし できる限り高速で スムーズに進めるよう設計されています。 具体的な例として 私が思いついたゲームのアイデアを実装します。 2人用のスネークゲームができるアプリで 一方のスネークはCore AIを通じて 実行されるAIモデルが操作します。 アプリは従来のスネークのルールに従い スネークは食べ物を食べることで 成長でき 壁や自分自身 そして もう一方のスネークに当たらないようにします。 最後まで生き残ったスネークの勝ちです。 各タイムステップでAIモデルは 現在のボード状態を表す 一連の特徴量を受け取り それらが蓄積されて モデルに入力されるゲーム全体の 履歴になります。 そしてモデルは最適な進行方向を 予測します。 スネークはシンプルなゲームですが この体験を作るために使うツールとAPIは 同じ基盤の上に成り立っており より大規模で複雑なユースケースまで スケールします。 このプロジェクトで PyTorchを使って 何が作れるか試してみました。 AIコーディングアシスタントの 少しの助けを借りて シンプルなスネークの行動予測モデルを かなり素早くスケッチできました。 訓練には単純なシミュレーションを使って トレーニングデータを生成しました。 ゲームを実行して状態と アクションを記録するだけです。 まずシンプルに始めてアプリで モデルを動かすことが目標でした。

次のステップはこのPyTorchモデルを Core AIに変換することです。 新しいCore AI Torch Pythonパッケージを使って 簡単に変換を行います。

まずSnakeTransformerモジュールの 学習済みチェックポイントを読み込み サンプル入力を準備します。 次にtorch.exportを使って torchプログラムをエクスポートし dynamic_shapes引数を使って 特徴量のシーケンス長が動的であることを 指定します。 これにより静的なサンプル長5で トレースされるのを防ぎます。 また変換されたプログラムに Core AIの分解テーブルを使って 分解を実行します。 次にCore AIのTorchConverterを実行し 入力と出力の名前を指定して 最後に変換されたCore AIモデルを ディスクに保存します。 Python環境を離れる前にもう一つ やっておくこととして 変換されたCore AIモデルが 元のPyTorchモデルの数値と 一致するかテストします。 Core AIフレームワークのPythonバインディングを 使えば簡単に実行できます。 まずPyTorchとCore AIのモデルを 読み込みます。 次にスネークゲームのサンプル入力を 準備します。 同じ入力をPyTorchモジュールと Core AIの推論関数の両方で実行します。 最後にユースケースにとって 十分に小さい差分を PyTorchとCore AIの出力間で確認します。

変換したAIモデルが用意できたので 次はXcodeに移ってモデルを アプリに統合します。 まずXcodeでAIモデルファイルを開くと モデルに関する情報が表示されます。 モデルサイズや演算の分布 その他の便利なメタデータが含まれます。 またタブでは モデル内の各ユニーク関数の 正確な関数シグネチャが確認できます。 この場合 モデルには関数が1つだけあり ゲームボードの特徴量を入力として受け取り ロジットを出力として生成します。 そのロジットはモデルが 最適と判断する移動方向を示します。 NDArrayの値にある クエスチョンマークは その次元が動的な形状を持つことを 示しており 動的なシーケンス長で変換した モデルと一致しています。 AIモデルファイルをXcodeプロジェクトに 追加して構造を確認したので 次のステップは Core AIフレームワークを使って モデルを実行することです。 Core AIフレームワークはCore AIモデルを 読み込んで実行するための 新しいSwift APIサーフェスです。 段階的に開示されるAPIセットを 提供しており シンプルに始められるとともに パフォーマンスクリティカルな アプリケーションをサポートするための より深い柔軟性の層も備えています。 また非エスケープ型などの モダンなSwift言語機能を活用し パフォーマンスを犠牲にせずに メモリ安全なAPIを提供します。 フレームワーク内の主要な型について 説明します。 AIModelは.aimodelファイルへの URLから初期化され 主に1つ以上の推論関数を 検査・読み込むために使用されます。 InferenceFunctionは実行可能なオブジェクトで 読み込まれた単一のコンピュートグラフを 表します。 一般的なケースでは AIModelには 単一のメインInferenceFunctionのみがありますが 複数の関数を持つ単一のモデルに 変換することもできます。 AIModelとInferenceFunctionは 通常 アプリのAI機能を準備する際に 構築するオブジェクトです。 たとえばアプリの初期化時に 行うことができます。 NDArrayは多次元の入出力データを 保持する型で InferenceFunctionのrunメソッドを使って そのデータで推論を実行します。 最後に推論の出力を 読み取って処理できます。 スネークゲームの実装では まずModelPlayerという型を作ります。 アプリ初期化時に 使用するAIモデルファイルへのURLで 初期化されます。 次にAIModelを初期化し そこからメインの推論関数を読み込みます。 次はモデルプレイヤーが 意思決定するロジックです。 アプリで定義したSnakePlayerプロトコルに 準拠します。 プロトコルの主な要件は chooseAction関数で ゲームの履歴が渡され スネークが次に取るべき アクションを返します。 最初にすることは入力特徴量を 格納するためのNDArrayを作ることです。 この推論関数に対して NDArrayの期待される構造は float32データを持つ2次元配列で 形状の第1次元が 現在のシーケンス長 第2次元が固定された 隠れ次元サイズです。 次にwriteFeatures補助関数を使って そのNDArrayに特徴量を書き込みます。 この関数はゲームとNDArrayの ミュータブルビューを受け取ります。 NDArray.MutableView型は 非エスケープ型で NDArrayのバッキングストレージへの 安全で効率的なアクセスを提供します。 入力を準備したら それで推論を実行し 期待される出力ロジットの ndarrayを取り出します。 最後のステップは 出力ロジットをサンプリングして スネークが次に移動する方向を選びます。 ndarray viewを補助関数に渡すことで 値を読み取り 最も大きいロジットに対応する 方向を選択します。 writeFeatures関数は 入力特徴量を格納するものです。 これらの特徴量に含まれるものを 簡単に説明します。

AIスネークの頭から 全壁までの正規化された距離 最も近い食べ物までの 正規化された相対X・Y距離

現在の方向をエンコードする 4つの要素 もう一方のスネークまでの 正規化された距離 そして最後に相手の向きです。 これが整ったので テスト実行を試みます。 両方のスネークをAIモデルで動かして 性能を確認します。

実行するとモデルが 正常に動作しています。 ただし ゲームが進むにつれて 遅くなっているのがわかります。

Core AIフレームワークと並んで Xcodeに新しいInstrumentが追加されており アプリで実行されるCore AIモデルを プロファイルできます。 この場合 Instrumentsでアプリを実行すると 推論の間隔が時間とともに 顕著に大きくなっているのがわかり 推論呼び出しのレイテンシが 増加していることを示しています。 これはTransformerモデルが シーケンス長に対して 二乗の時間計算量を持つためです。 このゲームでは シーケンス長がモデルの 手を打つたびに増加します。 次のステップはモデル使用の パフォーマンスを最適化することです。

入力シーケンスが増えるたびに Transformerモデルはシーケンス内の 各要素に対して 内部的なキーとバリューの 埋め込みを再計算します。 Transformerを使った際のデコードループの パフォーマンスを改善するために よく使われる戦略は シーケンスの 各要素に対して計算されたキーと バリューをキャッシュすることです。 推論のたびにゼロから すべてを再計算するのではなく 計算済みのものを使い回します。 これはCore AIの状態を使うことで 実現できます。

状態はモデルへの入力で 読み取られると同時に 推論中にインプレースで更新されます。 キーとバリューのキャッシュを モデルの状態として導入することで 各推論でそれらを 再計算することを避け ゲームの全履歴を入力として 提供する必要もなくなります。 過去のステップに必要なデータは 状態に格納されているためです。 最初の入力の後は 後続の各ステップで 履歴にキャッシュを使用し 最新のボード状態の 新しい特徴量のみを受け取ります。 キー/バリューキャッシュを実装するために 元のオーサリングコードに戻って キーとバリューのキャッシュを追加する いくつかの変更を加えます。 まずtorchのregister_buffer APIを使って キーとバリューのキャッシュテンソルを Transformerモジュール内のバッファとして torchモジュールに追加します。 これにより後でこれらのテンソルが エクスポートされたtorchプログラム内の ミュータブルバッファになり Core AIが状態に変換します。 次にモジュールのforward関数で キャッシュを実際に使うロジックを 追加します。 これにはキャッシュから以前の 特徴量のキーとバリューを読み出すことが含まれます。 次に新しい特徴量に対して計算された キーとバリューをキャッシュに書き戻します。 最後にモデルを再変換するために 以前と同じコードを再実行しますが 今度はconvert呼び出しに state_names引数を追加して 新しい状態引数の名前を指定します。 新しい関数シグネチャでモデルを 再変換したので アプリのコードを更新して対応します。 まずModelPlayerを更新して キーとバリューのキャッシュNDArrayを保持するようにします。 これが各推論に渡される 状態引数になります。 Transformerに期待される形状で 初期化します。 この場合 キーとバリューのキャッシュが 常に固定サイズになるようにモデルを変換しました。 最大コンテキスト長に対応した 固定サイズです。 推論を実行するときは MutableViewsのコレクションを 構築して キーとバリューの両キャッシュの ビューを含めます。 そしてInferenceFunction.runメソッドの states引数としてそれらを渡します。 これでキャッシュは各推論で 読み取られインプレースで更新されます。 更新されたモデルで アプリを再実行します。 今度は一定の速度を 維持しているのがわかり 時間とともに遅くなることはなくなりました。 Instrumentsで更新されたアプリを トレースすると 推論レイテンシの増加速度が はるかに遅くなっていることが確認できます。

まとめに入る前に スネークゲームの開発では使わなかった いくつかの機能を紹介します。 独自のアプリを開発する際に 役立つかもしれません。 スネークゲームのモデルを変換する際は coreai-torchパッケージを使って PyTorchモジュールを直接変換しました。 このフローはシンプルで 多くのユースケースに有効ですが モデルのオーサリング方法を より細かく制御したい場合や モデル内の演算の実行方法まで 制御したい場合もあります。 Core AI Pythonパッケージの機能は まだ表面に触れたにすぎません。 Core AI APIを使ってモデルを 直接オーサリングする機能や Apple Silicon向けの モデル最適化 Metal 4を使ったカスタムカーネル実装の 定義もサポートしています。 これらの高度なモデルオーサリングフローの 詳細については 「Dive into Core AI model authoring and optimization」をご覧ください。 パフォーマンスのデバッグに加えて 変換されたモデルの数値を デバッグできることも重要です。 そのためにCore AI Debuggerを使えます。 変換されたモデルを視覚化し 中間テンソル値を簡単に確認でき 変換されたモデルの演算を それらを生成したPythonソースコードまで トレースできます。 また便利なCore AIデバッグゲージもあり Xcodeでアプリを実行中に Core AIのアクティビティをストリーミング表示します。 Instrumentsに移る前に パフォーマンスの問題を見つけるのに 最適な場所です。

スネークゲームの実装で さらっと流してしまったことの1つに モデルの特化プロセスがあります。

AIモデルをアプリに同梱する場合 それはモデルのソース表現であり 任意のAppleデバイスで実行できます。 ただしアプリ内でモデルを実際に 読み込んで実行するには アプリが動作するデバイス向けに 特化する必要があります。 モデルが読み込まれると すでに特化されて キャッシュされているかどうかが 確認されます。 特化プロセスは 非常に大きなモデルの場合 かなりの時間がかかる場合があります。 2回目以降はキャッシュから高速に 読み込まれますが 初回は計画を立てる必要があるかもしれません。 ユーザーがインタラクティブなフロー内で モデルの特化が発生しないように することをお勧めします。 Core AIがその点をサポートします。 まずCore AIはアプリの デフォルトモデルキャッシュへの プログラムによるアクセスを提供します。 そこから直接モデルを 読み込むように要求できます。 nilが返された場合は存在せず 特化が必要です。 これを使って機能にゲートを設けたり ユーザーに アプリがモデルを準備中であるため 少し待つ必要があることを伝えられます。 次にアプリ内でモデルの読み込みとは 独立してモデルの特化を 明示的にリクエストできます。 アセットのダウンロード後や ユーザーが機能をオプトインした際に行うことで モデルをあらかじめ準備しておけます。 さらに多くの制御オプションがあります。 SpecializationOptionsはモデルを 推論向けにどのように最適化するかを 設定するのに役立ちます。 AIModelCacheでは不要になった エントリを削除したり エントリの保持期間のポリシーを 制御できます。 同じアプリグループ内の複数のアプリで キャッシュを共有することもできます。 詳細はdeveloper.apple.comの 「Managing model specialization and caching」の記事をご覧ください。

特化がいつ行われるかに関わらず 時間はかかります。 少し詳しく見てみましょう。 特化の際に モデルは主に2段階の 変換を経ます。 まずコアとなるコンパイルステップ群を経て コンピューティングを分割し 計画し最適化します。 次に使用するコンピュートユニット向けの 実行可能なアーティファクトが生成されます。 これらのアーティファクトは 生成されたデバイスとOSバージョンに紐付けられます。 この2つのステップのうち コンパイルがレイテンシのほとんどを占めます。 Core AIツールチェーンを使えば その時間を短縮できます。 開発マシン上で事前にコンパイルを 一部行うことができ コンパイル済みのモデルが生成されます。 そのコンパイル済みモデルは 特定のユーザーのデバイス向けに 特化する必要がありますが 残りの作業量がはるかに少なくなり 大幅に高速に完了します。 このオプションの詳細については developer.apple.comの「Compiling Core AI models ahead of time」の 記事をご覧ください。 特化がいつ どこで どのように行われるかを制御することは ユーザー体験を最適化する 方法の1つです。 最適化したいもう1つの領域は モデルを使った密な推論ループでの オーバーヘッドの除去です。 Core AIフレームワークにはこれを サポートするいくつかのAPIがあります。 NDArray引数の最適な メモリレイアウトを 動的に確認し その構造で割り当てることで 推論時のレイアウト変換を 回避できます。

フレームワークが書き込むための 出力値を事前に割り当てることもでき 推論中に新しい出力値を 割り当てることを避けられます。

また非同期値を使って 複数の推論関数の実行を 効率的にパイプライン化できます。 ほとんどのユースケースでは 高レベルの推論APIで 必要なところに到達できます。 ただし密な推論ループを最適化したり モデルを複雑なコンピュート パイプラインに統合する場合は これらの低レベルAPIが 必要なときに利用できます。 始めたばかりであっても 深く掘り下げる場合でも Core AI Modelsリポジトリは 必要なものを見つけるのに最適な場所です。 人気のモデルのコレクションがあり それぞれわずか1つのコマンドで アプリ向けに変換・最適化できます。 Core AIモデルのオーサリングに 精通したAIスキル 最適化とコンバージョンもあります。

また特定のモデルファミリ向けの ライブラリを含むSwiftパッケージもあり 多くの低レベル推論最適化が すでに組み込まれた 高レベルAPIを提供します。 Core AI言語モデルを作成するAPIも提供しており Foundation Modelsフレームワークに 直接プラグインでき 独自のカスタムモデルと トークンサンプリング戦略を持ち込めます。

まとめると Core AIはすべての Apple Silicon上で利用でき すべてのAppleプラットフォームで 最先端のAI体験を構築するのに役立ちます。 すでに使い慣れている 既存のPythonツールと 緊密に統合されており アプリ内でモデルを効率的に実行するための モダンなSwiftフレームワーク そして最先端のデバッグツールも備え モデルがAppleデバイス上でどのように 動作しているかを把握するのに役立ちます。 皆さんがどのような体験を 作り上げるか楽しみにしています。