2026-05-29 — Claude Opus 4.8、ITBench-AA 頂尖模型低於 50%、TRL Delta Weight Sync

Claude Opus 4.8：更誠實的代理模型，Legal Agent 基準首破 10%

Anthropic News · 2026-05-28

Anthropic 於 2026 年 5 月 28 日發布 Claude Opus 4.8，定價維持 $5 / 百萬 input token、$25 / 百萬 output token。本版主要改進方向並非原始推理能力，而是誠實性（honesty）與可靠性（reliability），同時在多個 agentic 基準上取得顯著進步。

核心改進：誠實與可靠性

Anthropic 將本版最重要的進步定位於模型行為層面。Opus 4.8 漏掉程式碼缺陷的機率比 4.7 低四倍，並更主動地標記分析輸入輸出中的問題，而非直接傳遞錯誤結果。模型對自身不確定的主張也表現出更低的信心輸出。

Agentic 基準結果

多個自動化任務基準顯示明確進步：

Terminal-Bench 2.1、OSWorld-Verified、CursorBench：整體 coding 與 agentic 能力提升
Online-Mind2Web（電腦操控）：84%，超越 Opus 4.7 與 GPT-5.5
Legal Agent Benchmark：首個在 all-pass 標準下突破 10% 的模型（以往最先進模型均低於此門檻）

工具呼叫效率

工具使用的步驟數量減少，在「相同智識輸出下使用更少的工具呼叫輪次」。這在 agentic 任務中意味著更短的執行鏈與更低的 token 消耗，Fast mode 定價較上一代便宜三倍。

對齊與安全評估

部署前評估顯示 Opus 4.8 在「支持使用者自主性」等親社會特質上達到新高，不對齊行為發生率較 4.7 顯著下降。Anthropic 並未公佈詳細評估方法論，但強調這是 responsible scaling policy 的標準審查流程。

原始來源：Anthropic — Introducing Claude Opus 4.8

ITBench-AA：頂尖模型在企業 IT 代理任務上普遍低於 50%

HuggingFace Blog (IBM Research & Artificial Analysis) · 2026-05-27

IBM Research 與 Artificial Analysis 聯合推出 ITBench-AA，首個針對企業 IT 代理任務的基準集，首階段聚焦 SRE（Site Reliability Engineering）場景。評測結果顯示，所有受測前沿模型得分均低於 50%，是目前飽和度最低的 agentic 基準之一。

基準設計

資料集包含 59 個 SRE 任務（40 個公開 + 19 個保留），每個任務提供一個 Kubernetes 事故快照，內含：

告警（alerts）、事件（events）、追蹤（traces）
指標（metrics）、日誌（logs）、應用拓撲

評分採用「全召回率下的精確率（Average Precision at Full Recall）」：若有任何根因實體被遺漏，得分直接歸零；若全部識別正確，得分為精確率（真陽性 / 識別總數）。每個任務執行上限為 100 輪工具呼叫，重複 3 次取平均。

模型得分

模型	得分	平均輪數	每任務成本
Claude Opus 4.7 (Max Effort)	47%	—	$5.38
GPT-5.5 (xhigh)	46%	31	—
Qwen3.7 Max	42%	—	—
GLM-5.1 (Reasoning)	40%	—	$1.23
Gemini 3.5 Flash (high)	40%	—	$1.70
Gemma 4 31B (Reasoning)	37%	58	$0.14
Gemini 3.1 Pro Preview	30%	83	$2.23

主要失敗模式

過度調查問題（Over-Investigation）：更長的工具呼叫軌跡不等於更高的準確率。GPT-5.5 以 31 輪取得 46%；Gemini 3.1 Pro 花費 83 輪卻只達 30%。

模型同時傾向於將故障注入機制本身（如 NetworkPolicy chaos）誤識為根因，或把共現症狀錯誤分類為獨立根因，均受精確率懲罰。未來擴展將涵蓋 FinOps 與 CISO 場景。

原始來源：HuggingFace Blog — ITBench-AA · arXiv 2502.05352 · GitHub itbench-hub/ITBench

TRL Delta Weight Sync：用稀疏差分將兆參數模型同步從 1 TB 降至 20 GB

HuggingFace Blog · 2026-05-27

HuggingFace TRL 團隊發布 Delta Weight Sync（PR #5417），針對非同步 RL 訓練中的 trainer–inference 權重同步問題，利用 bf16 權重的自然稀疏性，將每步同步的資料量從完整模型大小壓縮至 1–2%。

核心洞察：bf16 更新的高度稀疏性

在連續兩個 RL optimizer step 之間，約 99% 的 bf16 權重在位元層面完全相同。原因是 Adam 的典型更新幅度 Δw ≈ η ≈ 3×10⁻⁶ 低於 bf16 的精度閾值（|w|/256），更新被捨入吸收。PULSE 論文（arXiv 2602.03839）在 Qwen、Llama、Gemma 多個模型上驗證，400 步內稀疏率穩定在 99% 附近，變動率 <1%。

架構：三節點 + Hub Bucket

系統由三個獨立節點透過 Hub Bucket 解耦：

Trainer：以 BF16ChangeDetector（optimizer hook）在每步前後對比 bf16 快照，生成稀疏差分
Hub Bucket（Xet 儲存）：接收 sparse safetensors，透過 content-defined chunking 去重
vLLM Rollout Server：下載差分並套用 (indices, values) patch 到本地快照

Wire Format：稀疏 Safetensors

每隔 N 步（預設 10）上傳完整 anchor 快照；其餘步驟上傳 delta 檔：

deltas/step_000042.safetensors
├── model.layers.0.self_attn.q_proj.weight.indices  (int32)
├── model.layers.0.self_attn.q_proj.weight.values   (bf16)
└── ...
metadata: sparse=True, sparsity=0.9938

基準測試

以 Qwen3-0.6B 實測：

每步 payload：1.2 GB → 20–35 MB（34–60 倍壓縮）
inference 暫停時間：~1.1 秒/步
實際稀疏率：99.38%

外推至 Llama-3.1-405B（bf16 = 810 GB）：完整同步需 8 秒暫停；Delta 同步預估 2 秒、資料量降至 ~6 GB。Fireworks 實測 1 兆參數模型（1,024 GiB 快照）的實際 delta 僅 20.3 GiB（約 2%）。

原始來源：HuggingFace Blog — Delta Weight Sync in TRL · arXiv PULSE 2602.03839 · PR #5417

End of article