Apple Core AIフレームワーク
(developer.apple.com)- Core AIは、Apple silicon上でAIモデルをアプリ内で実行・最適化・配布するための新しいフレームワーク
- CPU、GPU、Neural Engineを活用し、Swift APIで
.aimodel推論をアプリに統合可能 - PyTorchモデルをCore AIモデルに変換し、圧縮・デバッグ・事前コンパイルまでツールチェーンとして提供
- 大規模モデルは実行前にspecializationが必要なため、ダウンロード、キャッシュ、初回実行フローの設計が重要
- SAM 3、Qwen、Transformerの例で、オンデバイスのビジョン・言語・状態キャッシュ最適化フローも紹介
Core AIの役割
- Core AIはAppleプラットフォーム全体でオンデバイスAI実行のための新しい技術群
- iOS 27.0+ Beta、iPadOS 27.0+ Beta、macOS 27.0+ Beta、tvOS 27.0+ Beta、visionOS 27.0+ Beta、watchOS 27.0+ Betaをサポート
- アプリ内で高性能なAI推論を実行し、ユーザーデータをデバイス外に送らない構成を提供
- Core AIは単なる実行APIではなく、モデル準備からアプリ統合までを含む
- モデル最適化、PyTorch変換、
.aimodel生成、デバッグ、Xcodeプロファイリング、事前コンパイルを提供 - ニューラルネットワーク以外のdecision treeやtabular feature engineeringモデルはCore MLの対象
- モデル最適化、PyTorch変換、
開発フロー: PyTorchからSwiftアプリまで
- Core AIは既存のPyTorchワークフローをApple silicon向け配布フローにつなぐ
torch.exportでPyTorchモデルをexported programに変換- Core AI PyTorch Extensionsの
TorchConverterで.aimodelを生成 - Core AI OptimizationでApple silicon向けの圧縮と最適化を適用
- Swiftアプリでは新しいCore AI Framework APIでモデルのロードと推論実行を行う
AIModelは.aimodelファイルを読み込み、推論関数を検査InferenceFunctionは実行可能な単一の計算グラフNDArrayは多次元の入出力データを格納する型run呼び出しでNDArray入力を渡し、推論結果を受け取る構造
- Xcodeでは
.aimodelファイルを直接確認可能- モデルサイズ、演算分布、メタデータ、関数シグネチャを確認
- 動的shape次元は
?で表示
パフォーマンス最適化: state、cache、memory layout
- Transformerモデルのように入力シーケンスが長くなる構造では、推論時間が徐々に増えることがある
- Snakeの例では、2つのSnakeをどちらもAIモデルで実行すると、時間が経つにつれてゲームが遅くなった
- Core AI Instrumentsで推論区間が徐々に長くなる現象を確認
- Core AIはstateを使ってkey/value cacheのような構造を実装できる
- stateはモデル入力であると同時に、推論中に読み取られ、その場で更新される
- 前段階のkey/valueを再計算せずキャッシュに保存
- 毎回ゲーム全体の履歴を入力しなくてもよい構造
- Swift側では
InferenceFunction.runのstates引数にmutable viewコレクションを渡す- 更新後のモデルは時間が経っても一定の速度を維持
- Instrumentsでも推論レイテンシの増加が大幅に緩和
- Core AIは推論ループのオーバーヘッドを減らすメモリ制御機能も提供
NDArrayの最適なメモリレイアウトを確認し、その構造で割り当て可能- 出力値をあらかじめ割り当てて、推論中の新規出力割り当てを防止可能
- 非同期値を使って複数の推論関数をパイプライン化可能
モデル配布: ダウンロード、specialization、事前コンパイル
- Core AIモデルはすべてのAppleデバイスで実行できるソース表現であり、実行前にデバイスごとのspecializationが必要
- モデル読み込み時に、すでにキャッシュ内にspecialization済みの結果があるか確認
- なければ、そのデバイスとOSバージョンに合った実行artifactを生成
- 大規模モデルではspecializationに時間がかかるため、ユーザー操作の途中に挟まないことが重要
- SAM 3の例では、初回実行時にmodel loadと大きなspecializationイベントのため、spinnerが長時間表示された
- 機能紹介画面で、ユーザーが試す段階になってからBackground Assetsでモデルをダウンロードするフローを提示
coreai-buildコマンドで、開発マシン上で一部のコンパイルを事前に実行可能- 特定デバイスアーキテクチャ向けのcompiled modelを生成
- ユーザーデバイス側でもspecializationは必要だが、残作業が減るため準備時間を短縮できる
AIModelCacheでモデルキャッシュをプログラムから制御可能- 不要な項目を削除
- 項目保持ポリシーを制御
- 同じapp groupの複数アプリ間でキャッシュ共有
モデル最適化とデバッグ
- Core AI Optimizationはモデル圧縮と量子化機能を提供
- INT4、INT8、FP4、FP8の重み圧縮をサポート
- calibrationデータまたはquantization aware trainingを使う量子化APIを提供
- SAM 3の例では、32ビットのbaseline assetは3GB超だったが、4ビット圧縮後は約430MBになった
- すべての層に積極的な圧縮を適用すると、隠れた花の1つが検出されなかった
- 出力だけでは、どの層が問題かを見つけるのは難しい
- Core AI Debuggerは変換後のモデルと元のPyTorchモデルの内部値を比較する
- モデル構造をグラフで可視化
- 中間テンソル値を確認
- Pythonソースコードの特定行まで追跡
- PSNR基準で差分の大きい演算を表示
- SAM 3の比較では、PSNRの低いsync pointの大半がdetector decoderで発生
- detector blockは全パラメータの4%にすぎず、圧縮による利得は小さい
- detectorを量子化対象から外すと、すべての花が再び検出され、baseline品質を回復
Core AI Modelsと高水準API
- Core AI Modelsリポジトリは、アプリ向けに変換・最適化できる人気モデルとexport recipeを提供
- SAM 3やQwen系モデルを見つけてCore AIモデルへ変換可能
- Swiftパッケージはモデルごとの前処理・後処理を抽象化
- SAM 3のようなsegmentationモデルは
CoreAIImageSegmenterとして利用可能- テキストプロンプトでオブジェクトを分割
- 生のtensor shapeを直接扱わずにSwift APIでmaskを抽出可能
- Qwenのような言語モデルは
CoreAILanguageModelとしてロード可能- asset loading、engine creation、tokenizer setupを抽象化
FoundationModelsのLanguageModelSessionと接続して利用可能- ストリーミング応答と
@Generableベースの構造化出力を利用可能
開発者が注目すべき点
- Core AIは「モデルをアプリで実行するAPI」より広い範囲のオンデバイスAI配布基盤
- PyTorchモデルをApple silicon向け
.aimodelへ変換するフロー - Swiftアプリでモデルを安全かつ効率的に実行するAPI
- Xcode、Instruments、Debuggerによる性能・精度診断
- PyTorchモデルをApple silicon向け
- アプリ設計では、モデル自体よりも準備プロセスがユーザー体験に大きく影響する
- モデルをアプリにバンドルするか、Background Assetsで受け取るかの判断が必要
- 初回実行時にダウンロードとspecializationをどう見せるかの設計が必要
- キャッシュ方針と事前コンパイル戦略が大規模モデルの使い勝手に直結
- Core AIはAppleプラットフォームでビジョンモデル、言語モデル、Transformerベースのモデルをオンデバイスで扱う開発フローを提示
- SAM 3の例でsegmentationモデルの圧縮・分離・デバッグフローを提示
- Qwenの例でカスタム言語モデルとFoundation Models APIの接続を提示
- Snake Transformerの例でstateベースのkey/value cache最適化を提示
参考リンク
- Apple Core AI Documentation: https://developer.apple.com/documentation/coreai/
- WWDC26: Core AIを見てみよう: https://www.youtube.com/watch?v=XJFfCVW1UZ0
- WWDC26: Core AIを使ってオンデバイスAIモデルをアプリに統合する: https://www.youtube.com/watch?v=gl5lD2gEhb0
- WWDC26: Core AIモデルの作成と最適化を深掘りする: https://www.youtube.com/watch?v=MdlyLT_y3i0
1件のコメント
Hacker Newsの意見
近いうちに出る オンデバイス Foundation Models のアップデートのほうがさらに楽しみ: https://developer.apple.com/documentation/updates/foundation...
まだ情報は多くない
ただし https://github.com/Arthur-Ficial/apfel を管理しているので、バイアスがあるかもしれない
fmツールが追加されたのを見たか気になる。Platforms State of the Unionで言及されていた実行するとこんな結果が出る: https://gist.github.com/robgough/7893602895e7580117475076198...
普段はソフトウェアが細かく分かれているほうを好むが、Appleの場合は標準搭載機能で気に入っているものが多い
ソフトウェアが「このプラットフォームにはこのモデルがある」と分かっていて、さまざまな小さな、そして今後さらに大きくなる生成AIタスクに活用できる点が特に惹かれる
ローカルエージェント型コーディングツールもさらに深掘りしており、
little-coder --model ollama/gemma4:12b-it-qatから始めたセットアップ時間を数分節約できる小さな無料の本も作った: https://leanpub.com/read/local-coding-agents
ハイパースケーラー主導のAI成長の誇張、とくにデータセンターの環境コストや社会的コストにはかなり腹が立っているので、ローカル・プライベートAI を促進する試みはすべて支持する
MCPサポートを提供している今、コンテナ化/seatbelt戦略 についてももっと聞きたい
Appleのコンテナシステムの中でDarwinがどう使われているのかについての話はまだ見ていない
Apfelは素晴らしいプロジェクトで、Tahoeにアップグレードしたくなった唯一の理由だった
WWDC 2026 Core AI の動画
Meet Core AI - https://developer.apple.com/videos/play/wwdc2026/324/
Dive into Core AI model authoring and optimization - https://developer.apple.com/videos/play/wwdc2026/325/
Integrate on-device AI models into your app using Core AI - https://developer.apple.com/videos/play/wwdc2026/326/
これはPyTorchモデルをCPU、GPU、Apple Neural Engine(ANE)全体で実行される形式に変換する新しい方法のように見える [0]
既存APIの Core ML を完全に置き換えるのか気になる [1]
[0]: https://apple.github.io/coreai-optimization/
[1]: https://developer.apple.com/documentation/coreml/
unslothは、こうした作業を「バッテリー同梱」方式でやってくれる良い例だ
それぞれの長所・短所と、どこまで機能的に同等なのかをAppleはもっとうまく説明すべきだ
ダウンロード数200万未満のアプリにはサーバー級モデルへのアクセスを無料で提供し、同じ プライバシー保証 も与えるとのこと
時間がたてばすべてのアプリに拡大されるとよい。ハードウェア/コスト制約はあるだろうが、より大きな開発会社ならコストを払えるはずだ
https://developer.apple.com/private-cloud-compute/
AIの未来は明らかに ローカル であり、最近では「無限トークン」と説明されている
M1 MacBook Proでもそれができ、RTX 3090でも可能だ
毎月何百ドルも払う必要はなく、ほかの人たちにとっても同じだ
40年が過ぎ、私たちは現代版のスマート端末に近い 中央集権型インフラ へと戻ってきた
AIの未来も結局はそのように流れていくだろう。おそらくローカルと中央集権の間を行き来する可能性が高い
ただ、人々がローカルで動くものを売って金を稼げるとしても、中央集権化のほうがより大きな権力とより大きな金を生み出すように見える
一般ユーザーは汎用モデルを求めるので、AIチャットアプリは今後も残るだろう
ほとんどのプログラムはローカルで動かせる特化AIから利益を得られ、プログラム数はユーザー数よりはるかに多い
Appleは活性値の側にも取り組んでいるようだ。知る限りでは w4a8, w4a16 だ
もしきちんと実現できれば、そしてそれは大きな前提ではあるが、Appleの市場到達力を考えると、1,000億未満のパラメータモデルが学習・提供される方法をかなり左右し得る
主な用途はオンデバイスになり、その多くはiOSよりmacOSになる可能性が高い
まだどこでも大きく取り上げられているのを見ていないが、Mac間の分散推論 は興味深い。Thunderbolt 5上のJACCL、OpenAI互換の
mlx_lm.server、Mac上でのエージェント型実行が含まれるAppleはMLX（直接の重み取り込み）をFoundation Models / Core AIとは分けている
AI企業が上場を急いでいる理由はこれだ
来年末ごろには、AIの大半を デバイス上で直接実行 するようになるだろう
彼らには堀がなく、拡張の限界に達しており、魔法のように見えるものの大半はより小さなモデルに蒸留できる。そして彼ら自身もそれを分かっている
Qwenが1,200億級モデルのリリースを止めたのは非常に示唆的だ
今後10年以内、ひょっとすると3年以内に、誰かがローカルで動かせるOpus 4.5級の2,560億モデルを出すだろう
今、こちらのエンジニアはOpusトークンに月800ドルほど使っており、その比率ならローカルLLMの投資回収期間は約10か月だ
残念ながら、より大きいモデルほど依然としてより良いモデルに見える
今の 最優先のAI要望 はそれだ。頼む、Apple
Linuxにもこういうものがあるのか気になる
たとえばアプリケーション開発者なら、カーネルが特定バージョン以上のとき GNU Core AI のようなものがあると想定できるだろうか？
Appleも今やCore ML、MLX、Core AIの間でその状態になっているようだ
フレームワークの断片化問題がすぐに消える兆しは見えていない
NVIDIAは誰もが学習と推論をCUDAで行うことを望んでおり、NPUが有用だという事実は認めたがらない
NPUを作る各社は、それぞれ独自のアーキテクチャと、LLM以前に設計されたハードウェアから受け継いだ制約に合わせた別個のフレームワークを持っている。多くはGPU向けの別のフレームワークも持っている
OSベンダーも、ハードウェア別フレームワークの代わりに使ってほしいフレームワークを1つか2つは持っている
これがANEでやりたいものを何でも実行できるという意味なのか気になる
最後に試したときは、Face IDのような Appleのファーストパーティ機能 でしか使えないように見えた
まったくANEを使えなかったのは MLX のほうだった