結論から
Core AI は Core ML の後継です(WWDC 2026、iOS/macOS 27〜)。
役割はほぼ同じで、「PyTorch のモデルを変換して、iPhone や Mac の ANE/GPU/CPU で動かす」ためのものです。
本質的な違いはひとつだけです。
LLM の生成ループを、あなたのコード(アプリ側の CPU)が回すか、OS のランタイムが回すか。
そしてこの違いだけで、同じモデルが実測 3.5 倍速くなります。
使い分けの答えも先に置いておきます:
| あなたの状況 | 答え |
|---|---|
| iOS 26 以前をサポートする | Core ML 一択(Core AI は OS 27+) |
| 画像分類・検出・埋め込みなど、1回呼んで終わりのモデル | Core ML のまま。移行する理由はありません |
| iOS/macOS 27+ で LLM・生成系 | Core AI |
既存の .mlpackage 資産 |
動き続けます。急ぐ理由はない |
ここから先は、この結論——特に「ループを誰が回すか」がなぜ 3.5 倍になるのか——を理解するための記事です。
4つだけ用語解説
この記事で前提にする用語はこの4つだけです。知っていたら飛ばしてください。
KVキャッシュ。 LLM は1トークンずつ文章を生成します。そのとき、過去の全トークンについて計算した中間結果(attention の Key と Value)を毎回ゼロから計算し直すと、文章が長くなるほど絶望的に遅くなる。だから一度計算した分は取っておいて使い回します。この「作業メモ」が KV キャッシュで、推論と推論のあいだで持ち越される状態の正体です。
サンプリング。 LLM の1回の推論が出すのは、次のトークンそのものではなく「次に来るトークンの確率分布」です(「猫」80%・「犬」15%……のような表)。そこから実際に1個を選ぶ操作がサンプリング。従来これはモデルの外——アプリ側のコード——の仕事でした。ここもあとで効いてきます。
IR(中間表現)。 変換ツールがモデルを保存するときの、コンパイラ用の共通言語です。PyTorch のコードでも GPU の機械語でもない中間の表現で、.mlpackage や .aimodel の中身は実質これ。コンパイラは IR を読んで最適化します。つまり——IR に書かれていないことは、コンパイラには見えない。この一文があとで効いてきます。
dispatch(ディスパッチ)。 CPU が GPU に「この計算カーネルを1個実行して」と依頼する操作です。1回ごとに固定の手数料(マイクロ秒オーダー)がかかります。計算が大きければ誤差、計算が小さければ手数料のほうが本体より高くつく。
ありがちな説明を2つ捨てる
Core ML と Core AI の比較でよく見る説明は、調べるとどちらも差分として成立しません。
「Core ML は状態(KVキャッシュ)を持てない」— 嘘。 iOS 18 の MLState で推論間に状態を保持できます。Apple 自身が Core ML で LLM を動かす例を出しています。ループは、動く。
「Core AI なら自作モデルを Foundation Models に差せる」— これも差分ではない。 WWDC26 セッション 339 の LanguageModel は公開プロトコルで、MLX(MLXLanguageModel)も Hugging Face(AnyLanguageModel)も実装しています。Core AI にあるのは公式アダプタの「楽さ」であって、能力ではない。
では何が違うのか。
ループの中身を見るとわかります。
ループの中身を1周ぶん見る
LLM の生成は、1トークンごとに同じグラフを回すループです。あなたのコードがこのループを回すとき、1周の中身はこうなっています。
毎トークン:
① あなたのコード → フレームワークに predict を1回依頼
② ランタイムがグラフの数百 op を GPU に dispatch
③ 完了を待って結果を CPU に戻す(同期)
④ あなたのコードが確率分布から次のトークンを選び(サンプリング)、①に戻る
このうちモデルの本質的な仕事は②の一部だけです。ニューラルネットの推論は、突き詰めると「重み(モデルが学習した巨大な数の表)をメモリから読んで、入力と掛けて、足し合わせる」の繰り返しで、それが起きるのは②の中だけ。①③④はループを管理するための処理コスト——以下「管理コスト」と呼びます——で、モデルの賢さには1ミリも寄与しません。1回なら誤差ですが、LLM はこれを毎秒何十〜何百周回します。
管理コストがどれくらい効くか、実測があります。LLM のデコード速度の物理的な天井は、メモリからデータを読み出す速度です(毎トークン、モデルの重みを全部読むので、「重みの総量 ÷ 読み出し速度」より速くはなれません)。ところが手元の Mac で低レベル API からこのループを自分で回すと——構造は Core ML の predict() ループと同じです——読み出し速度の理論上限の約11%しか使えず、1トークンあたり約1000回の dispatch が発生しました。天井のはるか手前、管理コストで頭打ちになっているわけです。
そして Core ML + MLState の構造的な限界がここです。状態は持てる。でもループは、あなたのコードです。 つまり Core ML では、1トークン作るたびに必ず GPU からあなたのコード(CPU 側)へ制御が戻ってくる。①③④の管理コストは毎周必ず払う。この「毎トークン、CPU に戻る」構造そのものは、MLState では変わりません。
「ループを内包する」とはどういうことか
Core AI のランタイムには、LLM デコード専用のパイプラインエンジンが入っています。「ループをランタイムが内包する」を、GPU の目線で具体的に見ます。
まず、あなたのコードがループを回すとき、GPU から見た世界はこうです: 数百個の小さな仕事が届く → 全部こなす → 止まって次の依頼を待つ。CPU が結果を読み、サンプリングし、次の入力を作って再依頼してくるまで、GPU はただ待っています。1トークンごとに信号待ち。さっきの「読み出し速度の11%」の正体はこれで、GPU は実力の1割しか出していません。
パイプラインエンジンは、この信号を3つの方法で消します。
1. 1周の形を最初から知っている。 デコードの1周は、毎回まったく同じ形のグラフです(入力トークン1個・状態・出力)。エンジンはこれを前提に、数百の op を少数のカーネルに融合し、次の周のコマンド準備を前の周が GPU で走っている間に済ませておきます。
2. 周と周を GPU 側で繋ぐ。 「トークン N の出力がトークン N+1 の入力になる」という受け渡しを、CPU に戻さず GPU 上の仕事の連鎖として繋ぎます。サンプリングも含めてエンジンの内側で処理されるので、GPU のキューには常に次の仕事が積まれている。赤信号が消えます。
3. CPU は観客になる。 あなたのコードは最初に「生成して」と1回言うだけ。あとは完成したトークンが非同期のストリームで流れてくるのを受け取ります。毎トークンのループは、もうあなたのコードのどこにも存在しません。
比喩で言えば、自前ループは「1個作るたびにラインを止めて、事務所に運んで検品し、次の1個の指示書を書いてからラインを再開する」工場です。エンジンは「最初に指示書を渡したら、ラインは回りっぱなしで、完成品がベルトコンベアで流れてくる」工場。ライン(GPU)の性能は同じでも、出来高が違う。
効果は同じ重みで測れます。手元計測(qwen3.5、同一の変換済みモデル)で、自前ループ 58.5 tok/s → エンジン 204 tok/s、3.5倍。カスタムカーネルは1行も書いていません。変わったのは重みでも量子化でもなく、ループの所有者だけです。
これが Core ML と Core AI の本当の差分です。そして面白いのはここからで、Core AI の他の新機能は、全部「ランタイムがループを所有するための部品」として因果で繋がります。
所有するために必要だった3つの部品
① 状態が IR の語彙であること。 さっきの一文を思い出してください——IR に書かれていないことは、コンパイラには見えない。MLState はまさにそれで、ランタイムから見ると中身の見えない外部バッファでした。外から渡される不透明な箱を、エンジンは先回りしてスケジュールできません。Core AI の .aimodel は「このテンソルはグラフが in-place で書き換える状態だ」と IR のレベルで宣言します。状態の読み書きがグラフの一部だから、エンジンはループ全体を見通してパイプラインを組める。状態の一級市民化は、それ自体が目的ではなくループ所有の前提条件です。
② グラフが事前に固まっていること。 エンジンの技(1)——次の周を先回りして準備する——は、グラフが走る前に完全にコンパイルされているから可能になります。Core AI は AOT コンパイル(xcrun coreai-build compile → .aimodelc)と、端末上の初回最適化を制御する API(AIModel.specialize() / AIModelCache)を公開しました。Core ML では不透明だった「端末上でいつコンパイルされるか」が、開発者の手に渡っています。AOT 済みバンドルはウォームロード 0.0 秒です。
③ 1周あたりのバイト床を下げる演算。 ループの管理コストが消えると、次の天井はいよいよ物理です: 毎周、重みを全部メモリから読む。OS 27 の Core AI は FP4/FP8 の TensorOps と FlashAttention を解禁し(WWDC26 セッション 330)、この床自体を下げにきています。Core ML の実行時演算が実質 fp16 床だったのと対照的です。
変換器(coreai-torch)が SDPA・RoPE・RMSNorm を composite ops として構造ごと下ろすのも同じ文脈です。エンジンがループを最適化するには、グラフの中に「これは attention だ」という意味が残っている必要があるからです。
まとめ
Core ML はループを「回せる」。Core AI はループを「所有する」。 毎秒何百周も回るループでは、1周の管理コストを誰が消せるかがすべてで、あなたのコードからは構造的に消せない——だからランタイムごと作り直した。それが Core AI です。