AI 代理與基礎設施
LLM 代理把 HPC 工作送上異質叢集，描述性硬體資料令成功率由 48% 升至 87%
LLNL 團隊讓代理探索 Flux、Slurm、Kubernetes 等資源，再把高階意圖轉成可驗證的工作規格。六個雲端叢集實驗顯示架構、網路與記憶體 metadata 主要能排除不能執行的機器，並非穩定的效能最佳化器。
Lawrence Livermore National Laboratory 研究者在 8 月 12 日公開一套代理式 HPC 派工實驗，將「理解工作需求」與確定性的排程、提交機制分開。其開源 [Resource Secretary](https://github.com/converged-computing/resource-secretary) 可探測 CPU、GPU、記憶體、網路、容器及十種 workload manager，並把可用操作暴露成類似 MCP 工具的函式；代理負責把自然語言意圖轉成工作規格、提交工作、讀取狀態與日誌，最後回傳可由 Flux API 驗證的 job receipt。
在第一組測試中，團隊於五節點 EKS／Flux 環境執行 LAMMPS，排列 workload manager、資源、應用設定、額外旗標與四種提示風格，共產生 432 次派工。423 次成功完成，成功率 97.9%；九次失敗包括把旗標與檔名錯誤串接、插入 `False`，以及重試時把 320-task 工作縮到單節點而逾時。這說明日誌觀察與參數驗證能抑制代理「口頭宣稱完成」，卻不能取代命令列語法及資源數量檢查。
第二組實驗把 219 個容器濃縮成 11 個應用，部署在 AWS、Google Cloud 共六個三節點叢集，硬體橫跨 amd64、arm64、EFA、不同記憶體與每小時 0.29 至 3.78 美元。Fluxq 先用資源圖比對，再選擇叢集並以確定性模板轉換命令。加入架構、網路與記憶體描述後，220 次工作的成功率由 48% 升至 87%，並消除架構不相容；十個可量測應用中五個加速，MiniFE 最多達 3.3 倍。
但[論文](https://arxiv.org/abs/2608.11524)強調，metadata 的主要作用是避開完全不能跑的節點，並未可靠地挑出最快機器。測試叢集規模小、沒有 GPU，代理模型也未做跨模型比較；五次 API 中斷的 fallback 工作更全部失敗。工程上值得追蹤的是以 schema 驗證每個命令、把 queue depth、成本與歷史效能納入評分，以及在第一次派工失敗後能否安全重新配對，而非只讓代理自行重試。