Tensor Arena 省了 30%，推論卻沒有變快？

工程師有一種很特別的習慣。

看到一塊記憶體，會忍不住問：
「它真的有必要一直占著嗎？」

就像一間辦公室有十張桌子，只坐了六個人。
你覺得很寬敞。

工程師開始研究：
「不同時段的人，能不能共用桌子？」
「如果可以，我們是不是只需要七張？」

這個問題不是在追求更快。
而是在問：空間有限時，原本放不進去的工作，能不能放得進去？

從 Tensor 生命週期重用空間

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

這次沿用 tiny-infer-lab 已評估的模型與 450 筆保留測試資料，比較兩種 Tensor 記憶體配置。

研究的不是怎麼讓 AI 推論更快，而是：
「已經不再需要的 Tensor 空間，能不能交給其他 Tensor 使用？」

有一個前提。
你必須確定，原本的資料真的已經不需要了。

否則就像公司看到一張空桌子，以為員工離職了，立刻安排新人坐進去。

結果原本的員工只是去上廁所。
回來發現，位置沒了，電腦也被別人用了。

更麻煩的是，兩個人還在同一台電腦上工作。
報告照樣交得出去，只是內容開始有點奇怪。

所以這次，我用 C11 實作了一個小型推論引擎，依照 Tensor 的使用生命週期安排記憶體重用。

這叫 Tensor Lifetime Planning。

講得很專業。
其實就是：
「你用完了沒？用完借我一下。」

但你不能只看見空間，就認定它可以用了。
還得確認，後面的運算不會再讀到原本的資料。

否則 Memory Optimization，就可能變成 Memory Corruption。
原本想省記憶體，最後連正確答案都一起省掉了。

容量結果與量測條件

那這次結果如何？

以手寫數字分類模型測試，batch size 設為 16 時，Tensor Arena 所需空間為：

未重用：8,832 bytes。
重用後：6,144 bytes。

減少約 30.4%。

原本超過這次設定的 7 KiB Arena 預算，重用後可以在這個容量內完成推論。

同一批 450 筆資料，兩種配置都維持 97.33% 準確率（438/450），逐筆分類結果與 scikit-learn 參考一致。

很好。
那速度呢？

未重用：每筆約 0.685 微秒。
重用後：每筆約 0.686 微秒。

表面上差了 0.001 微秒。
但兩組結果的觀測範圍重疊，不能據此判定真的變慢，也不能宣稱可靠的速度提升。

這些數字是六次獨立程序測量的中位數彙總：先取各程序的中位數，再取這六個中位數的中位數。

這是批次測試中，每筆有效資料的攤提時間，不是單筆請求延遲。
計時包含最後一批的填補運算、工作計數與輸出指紋計算；計時結束後，再核對工作計數與輸出指紋是否一致。

所以這次優化成功了嗎？

如果目標是讓推論更快，這些結果沒有證明成功。
如果目標是讓 Tensor 配置符合設定的容量限制，它做到了。

同一份結果，回答的是不同問題。

驗證實際重用與檢查機制

更重要的是，這次我不只確認最終分類結果。
還檢查中間 Tensor 的數值與實際位址，並加入獨立數值參考、編譯後的故障注入測試，以及記憶體配置圖。

我想確認的，不只是：
「結果有沒有一樣？」

還包括：
「程式實際執行時，有沒有按照規劃重用記憶體？」

配置圖畫得漂亮，不代表執行器真的照著做。
測試報告全綠，也不代表每條量測路徑都已經被檢查。

所以我也刻意讓程式在計時路徑漏算，確認驗證機制能不能發現。

這件事很重要。
因為我們不只需要相信程式，也需要知道測試能抓到哪些錯誤。

實驗限制與工程判斷

當然，這次實驗有明確限制。

6,144 bytes 是 Tensor Arena 所需空間，不是整個程式的 RAM。
7 KiB 是這次設定的實驗預算，不是從實際 MCU 量到的可用容量。

權重、配置資訊、輸入與其他執行開銷，需要另外計入。
這次是在 Apple M5 Pro 上做的主機實驗，不能直接證明 MCU 一定跑得動。

但它提醒我：
在評估一項優化之前，我們得先說清楚，究竟要解決什麼限制。

是延遲？
吞吐量？
記憶體容量？
還是部署成本？

這些指標可以互相影響，卻不能互相代替。

對工程主管而言，這也影響投資判斷：團隊交付了更小的配置，我們就應該依照容量目標驗收，再分開評估速度與部署效果。

否則就像有人告訴你：
「我終於把所有行李塞進登機箱了！」

你卻問：
「那飛機會不會飛得比較快？」

不會。
但至少這次，行李符合尺寸限制了。