你的程式變快了，但它有把事情做完嗎？

工程師有一種很特別的成就感。
叫做：「我的程式比你的快。」

快 10%，很高興。
快 50%，值得分享。
快了三倍？

那已經不是技術成果了。
那是人格上的勝利。

但當一個工程師告訴你：
「我的程式快了三倍。」

你應該先問什麼？
「怎麼做到的？」

我會先問另一個問題：
「它有把事情做完嗎？」

真正麻煩的 Bug，往往不是程式當掉。
程式當掉，大家都知道有問題。

麻煩的是：
「它跑得很快，結果看起來也很合理。」
甚至準確率還不錯。

你看著 Benchmark：
「哇，快這麼多！」

再看測試結果：
「嗯，好像也沒錯。」

於是很開心地宣布：
「Optimization completed。」

但如果驗證不夠完整，你可能只是很有效率地跳過了某些計算。

少做不必要的計算，本來就可能是好優化。
問題是：省下的工作，會不會改變我們要求的結果？

同一組模型與資料

最近我完成了一個小專案：
tiny-infer-lab

一個用 C 寫的小型推論引擎，加上一套效能驗證工具。

我不是想證明 C 一定比較快。

如果只想得到「C 比 Python 快」的結論，方法很簡單：
找一個 Python 最吃虧的測試。
再找一個 C 最有利的條件。

跑完之後，宣布：
「C wins。」

這不叫公平比較。
這叫先決定冠軍，再安排比賽。

所以這次，我讓六種實作方式使用同一組模型權重、同一批測試資料，在五種批次大小下比較：

手寫 C、系統 BLAS、emlearn、ONNX Runtime、NumPy、scikit-learn。

結果與量測條件

結果呢？

450 筆資料，六個後端，在所有測試批次下，分類結果全部一致。
準確率 97.33%（438/450）。

不只分類結果一致；全部機率輸出，也通過獨立 float64 參考計算的誤差檢查。

在這次量測中，batch size 1 時，emlearn 最快。
batch size 8、32、128、450 時，ONNX Runtime 最快。

batch size 450 時，暖機後每筆攤提時間：

ONNX Runtime：約 0.059 微秒。
C BLAS：約 0.142 微秒。

每個數字來自六次獨立程序測量：先取各次的中位數，再取這六個中位數的中位數。
這是批次吞吐表現，不是單筆請求延遲。

這次比較的是透過 Python 呼叫、產生機率輸出的介面，不是裸運算核心。量測包含 Python API、輸入檢查、機率輸出與結果收集；不包含模型載入、暖機與計時外的正確性檢查。

各後端的批次實作與內部檢查仍有差異，結果需要連同這些條件一起看。

所以，自己寫的 C 引擎，有沒有打敗所有成熟工具？

沒有。

這就是工程實驗最不浪漫的地方。
你花了很多時間，自己寫的引擎卻沒有拿下第一。

但這恰恰是實驗的價值。
它讓我們看清楚不同工具的取捨，而不是只留下自己希望看到的結論。

讓檢查機制接受挑戰

這個專案裡，我也刻意讓 C 實作漏算，再嘗試竄改測試報告。

目的很簡單：
看看驗證機制能不能抓到。

這幾種刻意放進去的錯誤，都被相應的檢查抓到了。

我不只想知道程式跑得對不對。
我還想知道：
「當它跑錯時，測試到底知不知道？」

一份全綠的報告很令人安心。
但如果我們沒有挑戰過檢查機制，就還不知道那些綠燈能排除哪些錯誤。

記憶體與實驗邊界

另外，這次也測量了記憶體使用情況。

batch size 450 時，暖機後程序 RSS 的中位數：

ONNX Runtime：約 60.4 MiB。
C BLAS：約 38.9 MiB。

這包含 Python、NumPy 與共同量測環境，不能直接當成模型本身的 RAM 用量。

當然，這只是一個小實驗：一個 64→32→10 的模型、450 筆保留測試資料，在一台 Apple M5 Pro 上比較。

BLAS 與 ONNX Runtime 的運算執行緒設為 1，速度比較採暖機後的結果。

它不能證明哪個框架在所有情況下都最快，也不能證明自製引擎一定比較好。

但它讓我重新思考一件事。

工程師很喜歡追求效能。
快一點，再快一點。

在採用一個漂亮的效能數字之前，我們也需要問：
「你怎麼證明，它跑得又快又對？」

畢竟，程式跑得慢，我們可以優化。
程式跑錯，我們可以修正。

最可怕的是——
程式跑錯了，Benchmark 還在替它鼓掌。

對工程主管而言，這也是資源決策的問題：我們用來選工具、定方向、判斷成果的衡量系統，本身是否經得起挑戰？