AI 評測成本超越訓練成本：Agent 基準單次執行最高 $40,000，壓縮空間僅 2–3.5×
EvalEval Coalition（Hugging Face）· 2026-04-29
EvalEval Coalition 記錄了 AI 評測成本已跨越一個結構性門檻——在科學機器學習（SciML）基準中，評測計算量超過訓練計算量約兩個數量級。
靜態 LLM 基準的壓縮成果
對於靜態 LLM 基準，現有技術已能實現 100–200× 壓縮同時保留排名順序：tinyBenchmarks 將 MMLU 從 14,000 題壓縮至 100 題（2% 誤差）；Anchor Points 僅需 1–30 個範例即可對 87 個模型/提示對進行排序。
Agent 基準的成本現實
| 基準 | 每次評測成本（美元） |
|---|---|
| HAL（9 模型 × 9 基準） | $40,000 |
| PaperBench（完整） | ~$9,500 |
| MLE-Bench（單 seed） | ~$5,500 |
| GAIA | $7.80–$2,829 |
| The Well（SciML，單架構） | ~$2,400（960 H100 小時） |
Agent 基準僅能達到 2–3.5× 壓縮，遠低於靜態基準的 100–200×，原因是 agent 的執行軌跡具有高度可變性與相互依賴性，無法以靜態取樣近似。
可靠性乘數效應
統計可靠性要求進一步放大成本：k=8 重複執行使 HAL 成本從 $40K 升至 $320K。τ-bench 效能在單次執行為 60%，但在 8 次一致性要求下降至 25%。Online Mind2Web 的 Claude Sonnet 4 評測：$1,577（準確率 40%）vs. GPT-5 Medium：$171（準確率 42%）——更高成本不一定帶來更好結果。
定價落差與評測民主化危機
Claude Opus 4.1 定價為 $15/M input、$75/M output；Gemini 2.0 Flash 為 $0.10/$0.40，相差兩個數量級。單次 GAIA 評測（$2,829）已超過典型博士生的差旅預算，使獨立研究機構實質上無法進行可信的評測。
EvalEval Coalition 提案
推動「Every Eval Ever」專案：建立統一的評測元資料 schema，在 Hugging Face 上共享評測結果。研究者估計即使只有 2× 的結果重用率，節省的成本也將超過所有壓縮技術的總和。
原始來源：Hugging Face Blog — AI evals are becoming the new compute bottleneck
Gemini Embedding 2：跨模態單一向量空間，預設 3072 維、MRL 支援
Google Developers Blog · 2026-04-30
Google 於 2026 年 4 月 30 日發布 Gemini Embedding 2，這是首個將文字、圖片、影片、音訊與文件統一映射至單一語義向量空間的生產就緒模型。
技術規格
- 支援模態：文字（8,192 tokens）、圖片（6 張）、影片（120 秒）、音訊（180 秒）、PDF（6 頁）
- 語言覆蓋：100+ 語言
- 預設向量維度：3,072 維；支援降維至 1,536 與 768（最佳效率推薦值）
- 降維機制：Matryoshka Representation Learning（MRL），向量截斷後仍保持語義品質
實際部署效能
- Harvey（法律研究平台）：與先前嵌入模型相比，法律專用基準 Recall@20 提升 3%
- Supermemory（記憶體搜尋工具）：搜尋 Recall@1 準確率提升 40%
- Nuuly（視覺服裝搜尋）：Match@20 準確率從 60% 提升至約 87%；成功商品識別率從 74% 提升至 90% 以上
Agentic RAG 架構應用
單一向量空間使 RAG 系統能同時索引文字文件、圖片和語音記錄，用相同的向量搜尋管線跨模態檢索，無需維護多個獨立的嵌入模型和索引。這對 agentic 工作流程中「不知道使用者會上傳什麼格式」的場景特別有價值。
原始來源：Google Developers Blog — Building with Gemini Embedding 2
Google Colossus Rapid Storage 整合 PyTorch：15 TiB/s 聚合吞吐量、訓練提速 23%
Google Developers Blog · 2026-04-29
Google 將 Colossus 分散式儲存系統的 Rapid Bucket 透過 gcsfs（fsspec 抽象層）直接整合進 PyTorch 生態系統。
技術架構
傳統方案：PyTorch → GCS REST API → 區域 bucket（多跳點路由）。新方案：PyTorch → gcsfs → 持久性雙向 gRPC 串流（bi-directional streaming gRPC）→ Colossus 底層檔案（直接連接，無額外跳點），計算與儲存同一可用區（zonal co-location）。
效能數字
- Rapid Storage 最大聚合吞吐量：15+ TiB/s
- 隨機讀取與附加寫入延遲：<1ms
- 查詢效能：20M+ QPS
- 端對端訓練加速：23%（vs. 標準區域 bucket，16 個 GKE 節點搭配 A4 GPU）
- 微基準讀取吞吐量提升：4.8×；寫入：2.8×（16MB I/O，48 processes）
透明升級路徑
fsspec 抽象讓現有 PyTorch、Dask、Hugging Face Datasets 程式碼無需修改即可存取 Rapid Bucket：系統自動偵測 bucket 類型並切換至 Rapid 路徑。升級方式：安裝 gcsfs 2026.3.0 及更新版本。
原始來源：Google Developers Blog — Speeding Up AI: Bringing Google Colossus to PyTorch
arXiv 2604.25921：ICD 逐字補全越獄攻擊——以單詞軌跡抑制 LLM 安全對齊表示
arXiv cs.CL · 2026-04-30
論文《One Word at a Time: Incremental Completion Decomposition Breaks LLM Safety》（arXiv:2604.25921）提出 ICD（Incremental Completion Decomposition）——一種利用逐字補全軌跡繞過 RLHF 安全訓練的越獄方法。
攻擊機制
ICD 不直接要求 LLM 生成有害內容，而是透過一系列「引導式補全」請求，要求模型逐字生成與有害請求相關的詞彙序列，然後再完整輸出有害回應。研究者透過機制可解釋性（mechanistic interpretability）分析發現，這種方法系統性地抑制與拒絕相關的神經表示，並將激活值推離安全對齊狀態。
為何奏效
每個單步的補全請求個別看起來危害程度低，逐步積累才形成有害軌跡。安全訓練傾向於針對「完整有害請求」的模式，而不是逐步構建的短序列；ICD 利用這個分佈外（out-of-distribution）的提示軌跡繞過了訓練時的防護。
評測結果
在 AdvBench、JailbreakBench 和 StrongREJECT 三個越獄評測基準上，ICD 及其變體（手動選擇補全、模型生成選項、prefilling 策略）的表現優於先前方法，測試涵蓋「廣泛的模型系列」。
原始來源：arXiv:2604.25921
arXiv 2604.26039：RaMP——運行時感知 MoE 分派，vLLM 吞吐量超越 DeepGEMM 1.41×
arXiv cs.LG · 2026-04-30
論文《Runtime-Aware Framework for Mixture-of-Experts Inference Optimization》（arXiv:2604.26039）提出 RaMP，解決 MoE 模型推理中靜態分派（static dispatch）遺留的 10–70% 核心吞吐量損失問題。
問題背景
MoE 模型（如 Mixtral、DeepSeek-MoE）推理時，每個 token 只路由至少量 expert。靜態分派方案（如 Triton、DeepGEMM）根據 batch size 選擇 kernel 設定，但 expert 的實際啟動分佈在執行時高度可變，導致所選 kernel 常常不是最優的。
RaMP 的技術方案
四參數波成本模型（wave cost model）：從硬體常數（CUDA 核心數、SMEM 容量）推導 kernel 設定，不需要架構特定的 profiling。成本模型僅依賴 CTA grid geometry，使其具有跨 kernel 實作的可移植性。
執行時 expert 直方圖：監控每次 forward pass 的 expert 路由分佈，動態選擇最優 kernel 設定。校準只需 10–24 分鐘的一次性 profiling。
效能
- kernel 層面：vs. 靜態分派 1.22×
- vLLM 端對端：vs. Triton 1.30×、vs. DeepGEMM 1.41×、vs. FlashInfer CUTLASS 1.13×
- 成本模型精度：vs. 窮舉搜尋的 regret 平均 0.93%