Part D 收官時，四層顯微鏡塔已經蓋完。回頭看這 22 天，每一步判讀都是人工：跑 skill、對口徑、追相依、把兩個工具的輸出擺在一起吵架。一個自然的問題浮上來：這套流程能不能交給 agent 代跑？
在回答之前，先處理一個更常見的念頭：「不用那麼麻煩吧，把 profile 丟給 ChatGPT 問『為什麼慢』不就好了？」這句話其實有兩種做法：一種是把資料攤成文字，直接塞進 prompt 讓模型讀；另一種是讓 ChatGPT 或 agent 寫 Python、跑 SQL、呼叫分析工具。兩條路差很多。本文先算第一條路的帳，再回頭看第二條路為什麼才是正解。
資料範圍提醒：本文把主檔 A 的七張主要資料表完整匯出為 UTF-8 CSV，再分別用
cl100k_base與o200k_base計數。以下採cl100k_base的 17.42M tokens；o200k_base為 17.48M，量級幾乎相同。這裡算的是「如果把每一列序列化後直接放進模型輸入」的成本，不代表 ChatGPT 上傳檔案時一定會把全文塞進 context。
主檔 A 只錄了約 36 秒的 8×H200 訓練，sqlite 檔 27 MB。把七張主要資料表完整攤成 CSV 文字後，逐表量測：
| 資料表 | 列數 | 攤成文字 | 約略 tokens |
|---|---|---|---|
| CUDA runtime 呼叫 | 317,902 | 17.95 MB | 8.26M |
| NVTX events | 53,709 | 5.44 MB | 1.78M |
| GPU kernel | 45,220 | 6.59 MB | 3.84M |
| synchronization | 57,379 | 3.90 MB | 1.88M |
| 其他（memcpy／memset／CUDA event） | 60,774 | 3.27 MB | 1.66M |
| 合計 | 534,984 | 37.15 MB | ≈ 17.42M |
拿 2026 年 9 月的公開規格對照：ChatGPT 手動選擇 Thinking 時，可用的 input 是 128K tokens；OpenAI 當下旗艦 API 模型的 context window 則是 1.05M。**這份 36 秒錄影的 17.42M tokens，分別是 128K 的約 136 倍、1.05M 的約 16.6 倍。**只看 kernel 表也有 3.84M tokens，已經是 1.05M 的 3.7 倍。
而且上表的 kernel 列還只有數字 ID。只把 demangled 名稱 join 進去，kernel CSV 就從 6.59 MB 增加到 16.73 MB、約 7.13M tokens；若把 demangled、short、mangled 三種名稱全帶上，則是 24.60 MB、約 10.2M tokens。再提醒一次量級：A 檔是教學用的迷你檔，真實工作的 trace 動輒分鐘級、GB 級，Day 5 用過的推論主檔 B，sqlite 就有 158 MB。
如果真的走「原始文字塞進 prompt」這條路，塞不進之後，常見的下一步是截斷：取前一萬列、或隨機抽樣。若 trace 從程式起點開始錄，前段通常包含編譯、autotune 與快取冷啟；只截前面，會把 warmup 當成穩定狀態。隨機抽樣則可能把 Day 14 教的區間結構抽碎。截斷不是壓縮，而是一個必須說清楚策略的取樣動作。
不過，「能不能上傳」跟「是不是逐列塞進 context」也要分開。ChatGPT 的資料分析功能可以對 CSV 寫 Python、做聚合，甚至用共同欄位合併資料集；CSV 的單檔限制約 50 MB，也不受一般文字文件 2M tokens 的單檔上限約束。這七張表總計 37.15 MB，而且每張都低於單檔限制，因此有機會分別上傳；但只要模型開始執行 Python，它就已經離開「硬讀 1,742 萬 tokens」這條路，改走工具查詢。這不是本文的反例，反而正好證明：真正有用的是可執行的資料介面，不是更能吞文字的眼睛。
「等窗口變大」也不是解法的全部。RULER 對 Llama 3.1 8B 的量測是一個很具體的例子：模型標稱 128K，13 項任務平均後的有效長度是 32K。這裡的「有效」不是硬體上限，而是仍高於 Llama 2 7B 在 4K 時 85.6 分的最長測試點。退化也不平均：retrieval 從 4K 的 99.9 分降到 128K 的 92.6，只掉 7.3 點；屬於 multi-hop tracing 的 variable tracking，則從 99.9 降到 70.4，掉了 29.5 點。這是特定模型與基準的結果，不能外推成每個新模型都只剩四分之一；但它提醒我們，標稱長度不等於每一種任務都能同樣可靠地使用那段長度。而 trace 判讀恰好很吃跨表關聯、區間運算與假說收斂。
所以，真正先出局的是「把每列都當文字，丟給 LLM 直接讀」。如果系統能跑 Python、SQL 或專用 skill，它已經繞過第一道牆；接下來要看的，是工具有沒有保留 trace 的結構與驗證能力。
第二道牆是結構。trace 不是文章，是關聯資料：一顆 kernel 的意義來自它跟 runtime 呼叫的 correlation、跟 NVTX range 的歸屬、跟其他 stream 的重疊關係。這個系列做過的每一個結論，Day 14 的兩把尺、Day 19 的四格帳、Day 20 的跨卡配對，都是 join、聯集、交集運算的產物，不是任何一列文字自己說出來的。最具體的例子是 Day 20 的翻案：光看 kernel 表，「device 空窗＋晚出發」怎麼讀都像 CPU 晚發射；把 runtime 表用 correlationId 接回來，才發現 launch 早在 236 ms 前送出。
關鍵事實住在兩張表的連接上，任何單表的逐列閱讀都到不了。把 53 萬列序列化成文字，只是保留了欄與列，不會自動完成關聯與時間運算。模型若要算出「device 4 的 NCCL 有 39.3% 與計算重疊」，仍然得寫出或呼叫正確的 join 與區間演算法。因此可相信的不是模型「讀懂了」，而是它執行了一段口徑清楚、可以重跑的查詢。
值得一提的是，trace 工具圈早就用腳投了票：Perfetto 把 trace 解析進欄式資料庫、用 SQL 查詢；Meta 的 HTA 用 pandas 的 merge(on="correlation") 把 CPU launch 接上 GPU kernel，跟 Day 20 我們手工做的 correlationId 配對一模一樣。「查詢而非閱讀」不是 AI 時代的新發明，是 trace 分析一直以來的常態。
第三道牆是驗證。語言模型會補完看起來合理的敘述；而這個系列光是 Part C 到 D，就抓過多少「看起來合理但錯了」的判讀：kernel 名帶 _LL 不代表走 LL 協定、NCCL 時間最長的卡不是 straggler、指令數量的組成不等於時間。人類判讀犯的錯，模型一樣會犯，而且說得更流暢。沒有留下命令、參數、版本與可重跑的檢查，讀出來的故事就很難判定對錯。
這裡有個值得回味的事實：你自己也塞不下這份 trace。54 萬列，一秒讀一列要六天。Day 10 到 11 我們怎麼處理的？三分鐘分診表：先看 GPU 條的顏色與密度、拖選一個穩定範圍、看 top kernels 的形狀，一套先壓縮再判讀的 protocol。人腦的 context window 更小，但配上對的流程照樣能診斷。
換句話說，問題不只在「context 不夠大」，還在「原始 trace 不該用逐列閱讀的方式處理」。這個系列的答案其實已經演了 22 天：
查詢範圍：device 4，39.964–46.123 秒
實際納入：2,114 顆 kernel
overlap_breakdown JSON：424 bytes
重跑用的是同一組範圍與裝置參數：
nsys-ai skill run overlap_breakdown megatron.sqlite --format json --trim 39.964 46.123 -p device=4
nsys-ai skill run nccl_breakdown megatron.sqlite --format json --trim 39.964 46.123 -p device=4
nsys-ai skill run gpu_idle_gaps megatron.sqlite --format json --trim 39.964 46.123 -p device=4
三個輸出分別是 424 bytes、1,049 bytes 與 7,234 bytes。這裡不能拿完整 kernel CSV 除以 424，宣稱它是 17,000:1 的壓縮：skill 先依 device 與時間範圍篩選，只回答一個被定義好的問題。比較準確的說法是針對問題的結果縮減。資料庫負責掃描、過濾與運算，模型最後只需要接收帶語意、可驗證的小結果。
Day 12 介紹 skills 時說的是「省你寫 SQL」；到了 agent 的視角，它們是 nsys-ai 這套 workflow 裡主要的證據介面。ChatGPT 的 Python、直接下 SQL、Perfetto trace processor 或 MCP 工具也能扮演類似角色，重點不在工具叫不叫 skill，而在模型拿到的是可執行、可重跑的取證能力。
skills 也不會覆蓋所有問題。Part D 的區間聯集交集、跨卡逐筆配對、相位切分與 CUDA runtime correlation，有些仍需要手寫分析。這正是 agent 的工作型態該有的樣子：不是讀資料，是挑工具、下參數、讀結構化輸出、決定下一步查什麼。跟你這 22 天做的事，形狀一模一樣。
把分工畫清楚。agent 能自動化的是內圈：選工具、帶參數、讀輸出、根據結果決定下一步，也就是「量測、假設、再量測」的執行部分。外圈仍然是人的：什麼口徑算數、哪個範圍才穩定、假說收斂到什麼程度才算定案，以及最重要的：這次要回答什麼問題。這個系列 22 天教的判準（sum 還是 union、單卡不代表全體、exit code 0 不是成功）就是外圈的內容；agent 站在證據上跑內圈，跑得比人快，但判準錯了它只會更快地跑錯方向。
這個形狀不是紙上談兵。NVIDIA 在 Nsight Systems 提供 preview 階段的 AI skill pack，設計就是讓你自帶 agent 去執行分析 scripts 與 recipes、拿結果再解讀，官方文件還特別要求重要發現要回查資料；Nsight Compute 的 developer preview 也內建 Copilot，把使用者選取的 profile result 附進對話。更大規模的版本在 Meta：2026 年公開的效能 agent 平台，用 MCP 工具查 profiling 與實驗資料、配上領域 skills，產出的 PR 交給工程師 review。incident 分析領域也有相同形狀：Microsoft 的 RCACopilot 先跑診斷 handler 收集多來源證據，再讓模型摘要、分類，最後交由工程師確認。
這些系統實作不同，不能武斷地說它們完全不把任何原始資料放進 context；Nsight Compute 就明確會附上選取的 profile result。比較穩健的共同點是：先用工具選取、查詢或整理資料，再把與問題相關的結果交給模型，而不是要求模型徒手讀完整 raw trace。
第一，「等 context 再大一點就解決了」。1.05M 的窗口對 A 檔仍差 16.6 倍；RULER 也提醒我們，長上下文能力會隨模型與任務不同。就算哪天真的裝得下，逐列文字仍然不會自己完成聚合、join 與區間運算，第二、三道牆原地不動。
第二，把 sqlite dump 或 timeline 截圖丟給模型，就把回答當成定案。截圖很適合讓模型看形狀、提出下一個假說；但要回答精確時間、跨表關聯與可改善上限，還是要回到程式或查詢。模型不只需要資料，也需要可執行的取證工具與檢查方法。
第三，期待 agent 取代判讀。它自動化的是執行迴圈，不是判準；口徑、範圍與假說紀律還是要人給。給錯 rubric 的 agent，只是把誤診自動化。
今天把「丟給 AI」這句話拆成了兩條路。把主檔 A 的 36 秒錄影逐列攤成文字，實測約 17.42M tokens；這條路不只撞上容量，後面還有結構與驗證兩道牆。讓模型改用 Python、SQL 或 skills，則是另一回事：先查詢、再縮減、最後判讀。agent 的正確形狀由此確定：在證據工具上跑內圈，人類守外圈的判準。
Part E 接下來三天照這個形狀走：Day 24 看 nsys-ai 的 agent 在工程上怎麼被限制成「只能呼叫 Day 12 那些 skills、不能編故事」（evidence-first 的實作）；Day 25 實戰 agent ask，把前面問過的問題交給它重跑一遍，對照人肉版本；Day 26 做交叉驗證：故意讓它有機會幻覺，看證據鏈怎麼把它拉回來。明天先從 evidence-first 開始。
openai_public.py
megatron.sqlite 為 28,364,800 bytes；kernel timeline 跨 36.123 秒，主要七表共 534,984 列。各表以 sqlite3 -header -csv 完整匯出，token 分別用 cl100k_base、o200k_base 對完整 UTF-8 內容計數。skill 輸出沿用 nsys-ai v0.3.0-21-g1cc03b5，範圍 39.964–46.123 秒、device=4；三個 JSON 大小依序為 424、1,049、7,234 bytes。
iThome鐵人賽
看影片追技術