AI 研究與效率每日追蹤｜2026-11-03
今日重點
今天值得看的不是新通用模型，而是兩個把算力用得更有效的環節：NVIDIA 開放訓練作業復原工具，並公布 Cosmos 世界模型的部署配置。前者減少故障後等待人工處理的時間，後者用量化與推測解碼降低記憶體需求、加快推論。名單外的新研究則嘗試把「先決定哪些 token」融入一次並行生成，但目前只在有限任務上由作者測試。 developer.nvidia.com
重要更新
1. NVIDIA｜NVIDIA Recovery｜11 月 2 日，開源
方法：從訓練日誌與排程訊號偵測故障、停滯或拖慢進度的作業，判斷原因後建議排除節點、重啟或停止；初次部署預設只監看，不會直接操作排程器。 developer.nvidia.com
數據：官方稱，7 月 9 日至 10 月 9 日在單一訓練叢集監看每日近 200 個作業，記錄約 8,550 次異常；平均偵測延遲 69 秒、採取復原動作延遲 94 秒。叢集 GPU 型號、作業模型與規模未公布。 developer.nvidia.com
實際意義：大型訓練的有效算力，除了取決於 GPU 速度，也取決於故障後能多快恢復作業。 developer.nvidia.com
限制與疑點：94 秒只算到自動化動作，不是恢復有效訓練的總時間；排程等待及讀取 checkpoint 仍須另算。目前支援 Slurm，官方文件也將此專案標為實驗性。 developer.nvidia.com
一手來源：NVIDIA 技術文章、官方文件。 developer.nvidia.com
2. NVIDIA｜Cosmos Framework／Cosmos NIM｜11 月 2 日，正式發布
方法：公布世界模型的訓練、調整與部署流程；推論端結合量化、推測解碼、快取與路由，並提供相機影片及 LiDAR 模擬配方。 developer.nvidia.com
數據：官方列出 Cosmos3-Nano 生成所需 GPU 記憶體：BF16 為 58 GiB、FP8 為 44 GiB，FP8 加卸載為 31 GiB；另稱在 H200 上推測解碼的平均加速約 2–3 倍。加速測試的完整輸入長度、batch、輸出設定與品質對照，該文未公布。 developer.nvidia.com
實際意義：開發者可依硬體容量選擇世界模型的精度與部署方式，而不必只看模型是否「跑得動」。 developer.nvidia.com
限制與疑點：記憶體表是部署需求，不是同條件吞吐比較；2–3 倍也屬官方量測，不能直接外推到其他模型或 GPU。 developer.nvidia.com
一手來源：NVIDIA 技術文章。 developer.nvidia.com
新架構雷達
Lee 等研究團隊｜Asynchronous Flow Map Language Models（aFMLM）｜10 月 30 日
這是什麼：讓不同 token 按不同進度去噪，再把這種生成順序蒸餾進模型，使輸出能在一次前向運算中並行產生。 arxiv.org
符合的門檻：①不同於逐 token 自回歸生成的架構；②有公開論文及實驗方法。 arxiv.org
作者測試：單步生成在 2,000 題 Sudoku-Hard 上，Top-K 排程完整解題率 14.4%；在 GSM8K 全部 1,319 題上，另一種 EB 排程的零樣本程式解題正確率 11.4%。兩個最高數字來自不同設定，不能當作同一模型配置的兩項成績。 arxiv.org
第三方驗證：尚未見獨立重測；單步不等於已證明端到端延遲或成本領先，且目前解題率仍低，離通用語言任務有距離。 arxiv.org
一手來源：論文與完整實驗。 arxiv.org
趨勢整理
- 訓練效率從晶片延伸到營運：前幾天的 GPU 遙測與今天的 Recovery 串起來看，重點是少浪費故障期間的 GPU 時間，而非宣稱單卡算得更快。 developer.nvidia.com
- 部署數字要分開看：Cosmos 的記憶體需求、推測解碼加速與先前邊緣推論測試，衡量的是不同環節，不能合成一個「整體加速倍數」。 developer.nvidia.com
- 並行生成仍在驗證期：近期擴散與流式語言模型持續嘗試減少生成步數；aFMLM 顯示「生成順序」可能在單步模型裡仍有用，但尚未證明能取代一般 Agent 使用的模型。 arxiv.org
值得追蹤
- Recovery 是否公布從故障到恢復有效訓練的完整時間、誤報率及對照組 goodput。 developer.nvidia.com
- Cosmos 的 2–3 倍加速能否附上完整負載與品質條件，並由第三方重測。 developer.nvidia.com
- aFMLM 是否公開可重現實作，以及在更一般的語言任務上量測端到端延遲與正確率。 arxiv.org