Day 1 問了一個問題：nvidia-smi 顯示 98% 使用率，那 98% 到底是在載客，還是只是引擎在轉、跳表在跳？三十天過去，這個問題其實一次都沒有離開過。從 MFU、roofline、NCCL、多卡 straggler，到 CUTracer 的指令層、agent 的證據判讀，最後親手修兩個 Ray bug、改一段 Ray Data 原始碼。每一天做的事，拆到最底層都是同一件：把「看起來很忙」和「真的有在做事」分開。

最後一天不加新工具。我想把整季反覆用到的判斷力，收成三個帶得走的原則。它們不綁定 nsys-ai、不綁定哪張卡、也不綁定 GPU；換一份 profile、換一個框架、甚至換成一個 AI 給你的優化建議，同樣適用。

原則一：忙不等於有用

這是整個系列的名字，也是最容易被忽略的一件事。

nvidia-smi 的 utilization 只回答「這張卡在過去一小段時間裡，有沒有至少一個 kernel 在跑」。它不回答那個 kernel 有沒有把算力用在刀口上。Day 1 用 MFU 把這件事量化：util 98% 的訓練，MFU 可能只有 40%。中間那 58% 就是「跳著表、沒載客」的部分：記憶體搬移、同步等待、kernel 之間的空檔、warmup，或者純粹算得沒效率。

這個原則在後面每一個 Part 都換一種形式回來。Part C 用 roofline 分辨一個 kernel 是被算力綁住還是被頻寬綁住；Part D 看多卡時，某張卡的「忙」其實是在等最慢那張卡（straggler）；Day 27 那份 Ray Data profile，util 看起來不低，但 31.3% 的時間根本沒有 kernel 在跑，其中還有一半是在搬資料而不是在算。

看到一個高使用率的數字，先別高興。問它一句：這段時間，運算單元真的在做有用的事嗎？

原則二：先問口徑和範圍，再讀數字

這一季踩過最多、也最貴的坑，全部集中在這裡。一個數字本身沒有意義，它的口徑和範圍才決定它能不能拿來下結論。

口徑是「這個數字怎麼算出來的」。同樣叫 idle，Day 14 的 per-stream 相加和 device-level union 差了兩位數；Day 17 的 MFU，分子用哪段時間、分母算 wall 還是 union，結論完全不同；Day 28 的 copy_ms 是「copy 的 wall time」，只有在確認 copy 和 kernel 沒有重疊時，才能把它當成 idle 的一部分。同一個詞，換個算法就是另一個故事。

範圍是「這個數字量的是哪一段、哪張卡」。Day 7 圈出穩定窗，因為 full profile 混進了 warmup 和收尾；Day 20 的 straggler 分析必須指定 device，不然跨卡的數字會互相污染；Day 23 更極端，一份 profile 有 1,742 萬個 token，硬塞給 AI 只會截斷成抽樣偏誤。

這一課在 Part E 有一個乾淨的示範。同一個問題，AI agent 在裸跑時把 full profile 的 67.7% idle 當成主因，但那段大半是開機關機；而且它用的是 per-stream 相加的口徑。答案裡每個數字都是真的，結論卻是錯的，因為口徑和範圍不對。有引用，不等於是對的。

看到任何一個百分比，先問兩件事：這是怎麼算的、量的是哪一段。問不出來，這個數字就還不能用。

原則三：改完一定要再量一次

量測→假設→再量測。這個迴圈最重要的不是前半段，是「再量測」那三個字。

整季最好的反例在 Day 27。工具明確建議「加 pinned memory」，照著做，H2D 頻寬確實快了 6.5 倍；如果停在這裡，這就是一個成功的優化。但再量一次整體時間，發現反而變慢了。原因是 pinned 只解決了頻寬，沒有解決重疊，staging 的成本只是從「GPU 等 DMA」搬到「GPU 等 CPU memcpy」。一個局部指標的改善，不會自動變成整體的加速。

這就是 Day 25、Day 29 反覆強調的三層區分：局部指標改善、機制生效、整體變快，是三個不同層次的主張，不能互相冒充。copy_ms 從 830 降到 155 是局部改善；stream concurrency 顯示 H2D 被遮蔽是機制生效；但要說「Ray Data 變快了」，需要的是控制掉 profiling overhead 和機器變異之後、同一份 workload 的成對計時。Day 29 的 prototype 讓 H2D 少了 81.4%，但 copy 和 compute 的重疊量出來還是 0 ms，有進步，但還沒到位。誠實地停在這裡，比宣稱「解決了」更有價值。

任何一個優化，不管建議聽起來多合理、局部數字多漂亮，都要回到同一份量測，再量一次整體。

一句補充：觀測工具本身，也要先被驗證

Part F 那三天多學到一件原本沒預期的事。原本只是想 profile 一個 Ray Data workload，結果第一份 profile 遲遲拿不到：先是 worker 因為 nsight 的一個 bug 起不來，修好之後，又發現 report 在 teardown 時被殺掉。兩個都是 Ray 本身的 bug，縮成最小重現、回報上游，變成了兩張 PR。

這件事把前面的原則往前推了一層：**profile 不是檔案出現就自動成為證據；產生這份檔案的路徑，也要先被驗證。**同樣的道理，一個 AI 給你的答案不是有引用就自動可信，一個 benchmark 不是跑出數字就自動成立。往上追一層，問「這個測量本身，可靠嗎」，常常才是真正的第一步。

三個原則，其實是同一件事

收在一起看，這三個原則是一條完整的判讀鏈：

1. 忙不等於有用，決定「值不值得看」：高使用率不代表有問題被解決，也不代表沒問題。
2. 先問口徑和範圍，決定「數字能不能用」：同一個詞換個算法、換個窗口，就是不同的結論。
3. 改完再量一次，決定「改動算不算數」：局部改善要回到整體量測才作數。

而 Part E 講的 agent，不過是把這條鏈自動化：機器可以幫你挑 skill、跑查詢、整理證據（inner loop），但「哪個窗口才穩定、哪個口徑才對、這個結論到什麼程度算定案」，這些原則還是人的責任（outer loop）。工具會越來越強，但這三個原則不會過期，因為它們檢查的不是工具，是證據本身。

謝謝這三十天

從一張 A100 的價目表，到親手改 Ray Data 的原始碼，這三十天其實只做了一件事：把 GPU「看起來很忙」這件事，一層一層拆開，直到能對每個數字說清楚它到底代表什麼。

如果這個系列只能留下一句話，就是最開始那一句：**GPU 很忙，不代表他真的有在做事。**下次看到一個漂亮的使用率、一個誘人的優化建議、或一個 AI 信心滿滿的診斷，希望你會多問一句：這是在載客，還是在跳表？

本系列所有實驗的 profile、程式碼與可重現腳本都已公開，兩個 Ray bug 的修正也在上游 review 中。工具會繼續進步，但量測→假設→再量測的紀律，得自己帶走。

參考資料

• 系列起點：Day 1｜GPU 很忙？先問：他在載客，還是在空轉跳表？
• Part E 的 agent 與人類 outer loop：Day 23、Day 25
• Part F 的兩個 Ray bug 與 Ray Data 修改：Day 27、Day 29
• 公開的 profile 與重現素材：Hugging Face dataset