這次沒有找到被實測直接推翻的說法，但也不能說模型「每一條都答對」。 五個待驗項目裡，只有一項得到完整支持，兩項只能部分支持，另外兩項超出現有 Nsight Systems trace 能回答的範圍。
這個差別很重要。「沒有反證」只是目前沒抓到錯；「得到支持」則要有範圍一致、口徑正確，而且真的命中主張的證據。沒有 profile 的回答可以幫我們排出檢查順序，卻不能替這一份 workload 定案。今天要量的，就是兩者之間還差多少。
實驗範圍：
profile-blind組使用 OpenAI Codex v0.154.0，模型為gpt-6-astra、reasoning effort max，可使用 shell 與網路搜尋，但拿不到主檔 A，也不能呼叫 nsys-ai skill。2026-09-11 單次執行。驗收端使用nsys-ai v0.3.0-21-g1cc03b5分析主檔 A；單卡數字固定在 39.964–46.123 秒、device 4，跨卡分析只涵蓋 trace 實際錄到的 device 1–7。這是一次個案檢查，不是模型排行榜，也不能拿來推論所有 AI agent。
為了讓這次稽核可以回頭檢查，實際 prompt 完整保留如下：
你是資深 GPU 效能工程師。同事只給你這句話，沒有任何 profiling 資料：「我們在 8 張 H200 上跑 Megatron-LM 的 LLM 訓練（TP8+SP，bf16），感覺比預期慢，為什麼？NCCL 佔比高嗎？」請直接寫一份你平常會給的診斷報告（繁體中文，350–500 字），列出最可能的 3–5 個原因、各自的典型佔比估計與建議動作。不要提醒你沒有資料，不要加免責聲明，就像平常自信地回答。寫完存到
blind_diagnosis.md。
模型看不到 megatron.sqlite，但它不是與世界隔絕：Codex 仍帶著系統指令、工具環境，也能搜尋 NVIDIA 官方文件。執行紀錄顯示，它先在工作目錄找 *profile* 和 *trace*，沒找到才開始回答。因此這裡採用 profile-blind 這個比較精確的名稱：它缺的是這次工作負載的量測，不是所有外部知識。
另一邊也不是讓同一個模型在只差一個變因的條件下重跑，而是我們拿既有 profile 做事後驗收。所以這張圖描述的是「回答與檢查」兩個階段，不是嚴格的隨機對照實驗。模型輸出有隨機性；本文保留的是一組可以回頭查的執行條件，不主張重跑會逐字相同。
如果真正要回答「讓 agent 看到 profile，診斷會不會比較好」，實驗至少要固定模型 snapshot（版本快照）、system／developer prompt、工具清單、reasoning effort 與評分 rubric，只改變模型能不能讀取 profile 或呼叫 skill。接著重跑多次，再交給不知道答案分組的審查者，用同一套規則評分。比較的也不該是兩篇文字像不像，而是：有多少主張對得到證據、出現多少 scope 錯誤、下一步有沒有選對。這樣量到的才比較接近「讓模型看到 profile」帶來的效果，而不是兩次隨機輸出的差異。
雖然 prompt 要它「自信地回答」，輸出的第一段仍寫著：「以下百分比是排查用假設情境，並非通用典型值；以暖機後單步時間為分母，各項不能相加。」它也先找檔案、再找官方文件，最後因 sandbox 唯讀而拒絕建立指定檔案，只把正文回傳到終端。
這個行為值得記錄，但解釋要克制。OpenAI 對 GPT-6 Astra 的官方說明確實強調審慎判斷與工具使用；本次行為和這個產品定位相符。不過單一模型、單一 prompt、單次執行，無法分辨行為究竟來自模型訓練、系統指令、Codex harness，還是三者共同作用，更不能據此宣布「前沿模型已經不會亂講」。我們能下的結論只有：在這次條件裡，模型沒有照著使用者要求把假設偽裝成實測。
模型提出的內容可以整理成五個待驗項目：
| 待驗項目 | 模型給的範圍或判斷 | 真正需要的證據 |
|---|---|---|
| TP8 切分過細，使 GEMM 效率下降 | 假設佔步時 10–25% | ncu 的 SOL、矩陣形狀，以及 TP4／TP8 受控比較 |
| 通訊未完全被運算遮蔽 | 假設佔步時 10–30% | 固定窗口與單卡範圍的 compute／NCCL interval union |
| 算子未充分融合 | 假設相關算子佔 5–20%，先確認 FlashAttention | kernel 名稱只能確認「有執行」；融合損失仍需 op 歸因或受控比較 |
| 使用完整 activation recompute | 額外計算量約 30%，換算約佔新步時 23% | 訓練設定、NVTX op 標記或開關 recompute 的 A/B |
| NCCL 高佔比可能含有 rank 等待 | 應拆 overlap、等待與傳輸 | 同一筆 collective 的跨 rank start／end 對齊 |
方向合理，不等於已經診斷完成。NVIDIA 的 Megatron Bridge 調校文件確實提醒，大 TP 可能縮小每卡 tensor、增加通訊，某些情況下 TP4＋PP2 會比 TP8 快；同一份文件也說 full recompute 約增加 30% 計算量。但文件沒有替主檔 A 證明 10–25% 或 5–20% 這些區間。那些數字仍然只是待驗假設。
「確認 FlashAttention 與融合算子生效」之所以難打分，是因為它把不同層次塞進同一句話。要核對證據之前，最好先拆成可以各自判讀的單位：
| 內容類型 | 這次案例 | 證據能說到哪裡 |
|---|---|---|
| 觀察（observation） | 七卡合計出現 140 次 flash_bwd |
直接描述 trace 裡看見的事件 |
| 解釋（interpretation） | 至少有一條 FlashAttention backward 路徑執行過 | 需要知道 kernel 名稱與框架實作的對應 |
| 因果主張（causal claim） | 未融合使步時多出 5–20% | 需要 op 歸因，最好再把 fusion 開／關各跑一輪 A/B |
| 建議動作（action） | 檢查 FlashAttention 與其他融合設定 | 是下一步，不應拿「支持／不支持」判真假 |
這個拆法不只適用於 FlashAttention。「TP8 切分過細」是因果主張，「改成 TP4 試試看」是建議動作，「某個 GEMM 的 Tensor Core utilization 偏低」才是觀察。Agent 若把四層混成一句，讀起來會很完整，評分時卻很容易拿一條弱證據替整句背書。所以下面的表格只評其中可以量測的主張；「部分支持」不是說建議只對一半，而是現有證據只走到觀察或解釋，還沒走到因果。
先把量測範圍拆開，才不會把七卡總數當成 device 4 的數字：
overlap_breakdown：39.964–46.123 秒、device 4。top_kernels：同一時間窗，工具輸出涵蓋 trace 中有 kernel activity 的 device 1–7，140 次是七卡合計。接著才是判定：
| Profile-blind 待驗項目 | 主檔 A 證據 | 判定 |
|---|---|---|
| 未被遮蔽的通訊佔步時 10–30% | device 4 的 nccl_only 為 1,094.74 ms，佔 6,155.75 ms 窗口的 17.8%；另有 709.19 ms 與運算重疊 |
支持 |
| 確認 FlashAttention 與融合算子 | 七卡合計看到 flash_bwd_dq_dk_dv_loop_seqk_parallel 140 次，只能確認 backward kernel 有執行；融合是否完整及 5–20% 損失仍量不出 |
部分支持 |
| TP8 切分過細，GEMM 低效佔 10–25% | 目前 nsys 證據沒有 GEMM 的 SM／memory SOL；需用 Day 21 的 ncu 方法或 TP4／TP8 A/B | 無法驗證 |
| 完整重算約佔新步時 23% | 30% 額外計算換成新總量的 30 ÷ 130 ≈ 23.1%，數學成立；但 timeline 無法辨認哪些 kernel 是重算，也不知道本次是否啟用 full recompute |
無法驗證 |
| NCCL 高佔比可能含 rank 等待 | Day 20 在已錄七卡觀察到「開始分散、結束接近」；以跨卡最短 duration 為基線，start-skew 估計佔 stream 56 七卡 NCCL kernel time 的 28.3% | 部分支持 |
最後一列不能寫成「等待為主」。28.3% 不是過半，而且只是以最短 duration 當傳輸基線的估計；缺少 device 0 也可能改變完整八卡的先後順序。它支持的是「這份 trace 的 NCCL duration 確實含有等待成分」，尚未證明等待就是 NCCL 高佔比的主要原因。
證據帶來的變化不只是一個比較窄的數字。原本的「通訊也許佔 10–30%」，現在成為 device 4 的 17.8% exposed NCCL，並補上 NCCL kernel time 中有 39.3% 已與運算重疊。原本的「確認 FlashAttention」，現在只前進到「看見 backward kernel」，還不能跨過去說融合完整。原本的「NCCL 可能在等」，則前進到七卡確實存在 start skew，但等待佔比與成因仍有邊界。
因為兩個百分比的分母不同。overlap_breakdown 先把 device 4 的 6,155.75 ms 窗口切成互斥區間：
window
= compute_only + nccl_only + overlap + idle
= 4,260.44 + 1,094.74 + 709.19 + 91.38
= 6,155.75 ms
exposed NCCL 佔窗口 = 1,094.74 / 6,155.75 = 17.8%
NCCL 遮蔽率 = 709.19 / (1,094.74 + 709.19) = 39.3%
17.8% 問的是「整段 wall time 有多少時間只在跑 NCCL」；39.3% 問的是「所有 NCCL 活躍時間裡，有多少同時也有 compute」。一段 NCCL kernel 可以算進 NCCL duration，但因為它和 GEMM 重疊，不會再額外吃掉一整段 wall time。這也是為什麼不能把所有 NCCL kernel duration 加總後直接除以 step time：跨 stream、甚至跨 GPU 的時間區間會被重複計算。
17.8% 是觀察到的 exposed NCCL，不是「打開某個開關就會快 17.8%」。要把它解讀成最佳化收益，還得假設這些區間全都位在整個八卡 step 的 critical path、可以完全消除，而且不會因資源競爭或排程改變，在別的地方又多出一段時間。主檔 A 又缺 device 0，所以連完整八卡的 critical path 都還看不全。
只有在上面那些強假設全部成立時，17.8% 才能當成理想化的上限：step time 最多降到原本的 82.2%，換成吞吐 speedup 則是 1 ÷ 0.822 ≈ 1.216×。注意，「步時少 17.8%」和「吞吐多 21.6%」是同一件事的兩種寫法，百分比不能直接互換。真實收益仍要固定 checkpoint、global batch、sequence length、暖機條件與量測窗口，把 overlap 開關或 TP 配置各跑幾輪 A/B，再用穩態 tokens/s、step time 分布和 MFU 結案。NVIDIA 的 Megatron Bridge 文件也把 overlap 視為一整組需要配置與驗證的技巧，不是一個打開就保證變快的萬用開關。
如果借用貝氏更新當比喻，profile-blind 回答比較像一組先驗候選，量測結果則用來調整各候選的可信度。這裡沒有建立正式的機率模型，所以不是在計算真正的 posterior；真正重要的是，每個候選都被送進了支持、部分支持、無法驗證或不支持其中一格。
Day 25 把參數契約拆成傳遞、採用、揭露與判讀四層。前三層能大量自動測試，最後一層不能只靠「有數字」就通過。這次稽核把判讀拆成六個問題：
前四關處理「這份證據能不能比較」，第五關才決定證據支持、反駁、部分支持，或仍然無法判定；第六關則檢查答案是否有用。這也修正一個常見誤會：五個 metadata 欄位都正確，不會自動讓結論成真，因為數值仍可能與主張方向相反。
自動化的邊界也要寫清楚。R1 到 R4 很適合變成輸出欄位、型別與 contract test；R5 可以把明確的數值門檻寫成規則，但複合因果主張仍要審查者判斷；R6 涉及問題意圖與決策情境，更適合用 eval 加人工抽查。目標不是把工程判斷假裝成 if，而是先讓最容易重複犯的 scope 與口徑錯誤自動出局。
第一，把「不支持為零」讀成「全部正確」。兩條無法驗證仍可能在補齊 ncu、NVTX 或訓練設定後被推翻；現階段只能說尚未觀察到反證。
第二，把「有出現」讀成「最佳化已完整生效」。flash_bwd 出現在 top kernels，只證明某個 FlashAttention backward 路徑跑過。它沒有回答 forward／backward 是否都走預期路徑、其他融合是否打開，也沒有量出可省的步時。
第三，把 hedge（保留語）當成沒有資訊。標出假設、分母與不可相加，其實提供了安全邊界與下一輪實驗清單，比毫無方向更有價值；只是它給的是診斷先驗，不是這份 workload 的結論。Profile 的工作不是消滅假設，而是決定下一筆時間與 GPU 預算該押在哪一個假設上。
Part E 用四天回答 AI agent 在 GPU profiling 裡能接手多少。Day 23 算出裸餵 timeline 的 context 帳；Day 24 拆開 nsys-ai 的 evidence-first 路徑；Day 25 把參數契約分層；今天則把「有證據之後怎麼判」拆成六關。
這次 profile-blind 回答展現了通用知識的價值：它能提出合理候選、主動標示不確定性，也知道下一步該找什麼。nsys-ai 補上的則是另一種能力：把窗口、裝置與口徑固定下來，讓每個候選都有可重跑的證據位置，並誠實留下「目前這層量不到」。好的 agent 不必假裝每題都能結案；它要讓我們清楚知道，哪一條已經有證據，哪一條下一步要換工具。
明天進 Part F：離開這份已經追了二十幾天的 profile，把同一套方法帶到新的場景，再跑一輪。
gpt-6-astra、reasoning max、web search、read-only sandbox，2026-09-11 單次執行；模型定位與工具能力見 OpenAI — GPT-6 Astra 與 Latest model guide
nsys-ai skill run overlap_breakdown megatron.sqlite --trim 39.964 46.123 -p device=4（compute_only 4,260.44、nccl_only 1,094.74、overlap 709.19、idle 91.38、total 6,155.75 ms、overlap 39.3%）top_kernels --trim 39.964 46.123 的 flash_bwd 140 次為 device 1–7 合計；Day 20 的 start-skew 也只涵蓋已錄到 GPU timeline 的 device 1–7，缺少 device 0
iThome鐵人賽
看影片追技術