用了 CoreML，推論怎麼反而比 CPU 慢？

GPU、NPU、Neural Engine、AI Accelerator。

名字一個比一個厲害。
聽起來，只要把模型交給它，推論就會像裝了火箭。

於是，我們很容易產生一個期待：
「既然有專門的加速方案，應該比 CPU 快吧？」

我想知道，這個「應該」，在實際部署後能不能成立。

最近我完成了一個小工具：
inference-doctor。

它替 ONNX 模型做一次部署健康檢查：結果是否正確、推論花多少時間、Worker 使用多少記憶體，以及 Execution Provider 留下了哪些執行證據。

正確性與速度結果

我拿一個訓練好的手寫數字分類模型，在 Apple M5 Pro 上比較 ONNX Runtime 的 CPU 與 CoreML Execution Provider。

同一個 ONNX 模型，同一批 450 筆保留測試資料。
最大批次大小分別設為 1、16、64、128。

先看結果。

兩邊的分類結果都與獨立參考一致，準確率都是 96.89%（436／450）。輸出的 logits 與機率，也通過各自參考值的誤差檢查。

再看速度。

在這四種批次設定下，CPU 的暖機推論時間都比較短。
最大批次大小 128 時，每筆資料的攤提推論時間：

CPU：約 0.076 微秒。
CoreML：約 0.694 微秒。

等等。
用了 CoreML，怎麼 CPU 反而先到了終點？

這讓我想到一場賽車。

旁邊停著一台跑車，空氣力學套件、電子控制系統，各種性能科技一應俱全。

比賽開始，隔壁的房車卻先到了。

「不是說你的車比較厲害嗎？」
「可是今天比的是從停車場開到便利商店。」

選車之前，還是得先看路線。

路線會影響選車；但這次 CPU 為什麼較快，還需要進一步拆解模型大小、運算量與部署開銷。

眼前能確認的，是這套模型、機器與量測條件下的實測差距。

執行歸屬能支持什麼結論

還有一個重要區別。

CoreML EP 的歸屬紀錄，不等於已確認使用 GPU 或 Neural Engine。這次 profiling 在另一個獨立 session 執行，也不能據此斷言每次計時都採用相同的執行配置。

所以，這不是「CPU 打敗了 AI 加速晶片」的證明。
它是兩種 Execution Provider 在這個工作負載上的部署比較。

攤提時間與請求延遲

速度數字也需要讀對。

每個獨立程序暖機後，完整跑過 450 筆資料五輪；每輪包含最後 66 筆的小批次。

將同步推論呼叫的總時間除以 450×5，得到該次量測每筆資料的攤提時間。報告再取四次獨立程序量測結果的中位數，得到前面的 0.076 微秒。

它不是使用者送出一個請求後，0.076 微秒就能收到答案。

否則，你可以開一間餐廳，一次煮 100 碗牛肉麵，總共花十分鐘，然後宣布：

「本店每碗牛肉麵只需六秒！」

客人點了一碗，等了十分鐘。
「不是說六秒嗎？」
「對啊，平均六秒。」

你沒有算錯。
你只是把統計學拿來得罪客人。

工具也另外記錄計時階段每輪完整資料驗證的耗時，納入資料切片、輸出檢查、分類計分與資料覆蓋檢查。

這些工作不在前面的推論呼叫時間裡；這個較完整的指標，也不包含資料載入、session 建立與暖機。

Worker 記憶體的範圍

記憶體同樣要看範圍。

這次測量的是整個驗證 Worker Process 的 RSS，包含直譯器、函式庫、完整測試與參考資料，以及驗證和執行時的配置。

它沒有涵蓋控制程序、CoreML Helper Services 或裝置記憶體，不能直接用來比較兩種方案的整體部署記憶體成本。

量測目標與工程判斷

這也是我做 inference-doctor 想釐清的事。

模型跑出來的結果對不對？
效能數字代表什麼？
執行證據能支持哪些結論？
還有哪些成本沒有量到？

這次實驗沒有證明 CoreML 不值得使用，也沒有找出所有情境下最快的 ONNX Backend。

它讓我看見：在這台機器、這個小型 Digits MLP，以及這四種批次設定下，CPU EP 的暖機推論時間比較短。其他模型與部署情境，還需要其他證據。

對工程主管而言，這也關係到資源怎麼投入。

採用一項加速方案之前，我們需要先說清楚目標：要縮短請求延遲、提高批次吞吐量，還是改善整體部署成本？每個目標，都需要相應的量測。

工程師可以有假設、偏好與直覺。
但當實測結果跟直覺不一樣，我們應該修改的是判斷，不是修改 Benchmark。

否則，還沒量到加速，報告就已經寫好：
「AI Acceleration Successfully Enabled。」

啟用成功。
加速還沒確認。
但簡報做得很快。