AI 研究與效率每日追蹤｜2026-10-23
今日重點
今天值得看的是兩種不同的加速路線：OpenAI 把代理流程中的小型決策做成專用 API；NVIDIA 則展示八節點本地推論如何受益於節點間通訊最佳化。名單外的 Lafa 論文嘗試以連續流分塊生成，減少逐 token 解碼的限制。三者的速度數字都來自特定工作負載，不能互相比快慢。 openai.com
重要更新
1. OpenAI｜Decisions API｜10 月 22 日，正式發布
方法：讓開發者先定義選項，再由 GPT‑6 Luna 對文字、圖片或結構化輸入回傳機率、選項或評分，用於代理的路由與下一步判斷。
數據：官方稱相較同模型的 Responses API「最快 10 倍」，單次請求最多可問 400 個問題；但 10 倍宣稱的統一輸入長度、並發量與測試分布未公布。客戶 Box 另稱在 30 個保險證明案例中，路由選擇約快 5 倍且準確率相同，不能當成通用結果。
實際意義：若代理需要頻繁作出有界選擇，可避免每一步都走完整的生成式回應流程。
限制與疑點：不適用於開放式生成；仍須用自己的資料檢查延遲、校準度與錯誤決策成本。
一手來源：官方公告、API 文件。 openai.com
2. NVIDIA｜八節點 DGX Spark 推論｜10 月 22 日，技術實測
方法：以 RoCE 連接多節點；在交換器拓樸中，RoCEnante 用直接交換加本地歸約，降低小訊息 tensor-parallel 解碼的通訊延遲。
數據：官方以 Qwen3.8-27B、NVFP4、單併發、8,192 輸入／256 輸出 token、關閉推測解碼測試：單節點解碼 11.86 token/s；八節點交換器拓樸達 52.58 token/s（4.43 倍）。相同八節點的實體環形拓樸為 40.11 token/s。 developer.nvidia.com
實際意義：讓大型模型在本地多機部署更可行，也說明節點間通訊會直接左右單請求速度。
限制與疑點：這是增加七台機器後、在指定模型與低併發條件下的擴展結果，不是單機憑空快 4.43 倍；官方也指出高併發或更大叢集未必適合此通訊方法。
一手來源：NVIDIA 技術文章與測試表。 developer.nvidia.com
新架構雷達
Lafa 研究團隊｜Large Flow Language Models｜10 月 20 日
這是什麼：把預訓練自回歸模型改造成連續流語言模型，區塊內並行產生草稿，再用同一模型自回歸驗證。
符合的門檻：①不同於逐 token 生成的架構；②有論文、程式碼及模型權重。尚未把作者自己的比較算作「獨立驗證」。
作者宣稱：7B 模型在單張 H100、BF16、batch 1、區塊大小 16，於 IFEval、GSM8K、HumanEval 平均約 100.2 token/s；對照自回歸模型約 39.5 token/s，即 2.54 倍。兩者平均準確率分別為 74.5% 與 73.9%。
第三方驗證：目前未找到獨立重測；高併發與更長上下文的效益仍待確認。
一手來源：論文與完整測試條件、模型卡。 arxiv.org
趨勢整理
- 代理拆工：OpenAI 的有界決策 API，與 NVIDIA 展示的大小模型路由，都把「每一步都呼叫大型生成模型」當成可最佳化的成本。
- 瓶頸不只在模型：前幾天的 KV 傳輸研究處理首 token 延遲；今天的多節點實測聚焦解碼時的通訊。 developer.nvidia.com
- 並行生成持續試探：繼近期的擴散與並行語言模型研究後，Lafa 提供另一條連續流路線；目前仍是作者測試，不能推論為通用替代方案。 arxiv.org
值得追蹤
- 用相同輸入、並發量與準確率要求，重測 Decisions API 對一般 Responses API 的延遲。 openai.com
- 看八節點測試在高併發、不同模型及實際整機成本下是否仍划算。 developer.nvidia.com
- 等 Lafa 的獨立重測，尤其是長上下文、batch 大於 1 時的品質與吞吐。 arxiv.org