ai-engineer/videos/model-evals
#model-evaluation#inference-efficiency#pruna2026-06-01 · 19:35 video

不要再只問誰是第一名;
SOTA 也該包含 效率

Bertrand Charpentier 用 Design Arena 等級的圖像模型評測成本開場:26,000 場 battle、每次生成 62 秒,完整跑完要 20 天、5,000 美元,以及約 400 場馬拉松等級的能耗。若換成快速壓縮模型,同樣評測可降到 7 小時與 265 美元。

AI Engineer · Bertrand Charpentier, Pruna · 約 1,140 viewsyoutube.com/watch?v=hqHC6Z_lXyo
FULL EVAL
baseline20 days
Design Arena style
FAST MODEL
20 days7 hours
same evaluation target
EVAL COST
$5,000$265
compressed model path
EFFICIENCY GAP
same rank?20x
possible latency/cost spread
// CONTENT MAP
00:00用 20 天 vs 7 小時說明:評測本身也有成本與能耗->
03:00單一 leaderboard 不能代表所有 use case 的最佳模型->
06:00同一模型在不同排行榜可能從第 10 名變第 5 名->
09:00多數模型輸掉 40% head-to-head battles,第一名也常常不是對的選擇->
12:00用 Pareto front 同時看品質、延遲、成本與能耗->
16:00真正的 frontier 可能是小型 specialized models,而非最大模型->

先講結論:最佳模型不是一個點,而是一條 frontier

這支 talk 反對的是「把 SOTA 縮成單一冠軍」的習慣。品質排行榜有用,但如果完全不看 latency、cost、energy,團隊很容易選到看似第一名、實際上不適合 production 的模型。

Bertrand 的主張是把效率視為 state-of-the-art 的一部分:把模型品質對上延遲或成本,找出 Pareto front。frontier 上通常不是只有一個模型,而是三到四個品質分數接近、但效率差距很大的選項。

如果一個模型讓你付出 20 天算力,另一個模型 7 小時能完成同樣評測,效率就不是 footnote,而是產品決策的一級指標。— 本頁依 YouTube metadata、影片描述與可得字幕資訊整理

為什麼 leaderboard 會誤導

影片描述指出,同一模型在不同 leaderboard 上排名可能從第 10 名變第 5 名。這不是小誤差,而是提醒我們:排行榜反映的是特定資料集、評分方法、偏好分佈與任務定義,不等於所有 use case 的真實排序。

更關鍵的是,大多數模型會輸掉約 40% 的 head-to-head battles。也就是說,即使某模型在平均分數上最高,它仍可能在接近一半的實際比較中不是更好的選擇。對產品團隊而言,「第一名」只是候選,不是答案。

評測成本本身也該被評測

Design Arena 式的圖像模型排名需要大量 pairwise battles。26,000 場 battle、每次生成 62 秒,意味著完整跑一次要 20 天、5,000 美元,並消耗約 400 場馬拉松等級的能源。這種數字讓「評測」不再只是研究流程,而是實際成本中心。

如果壓縮後的快速模型可以把同樣評測降到 7 小時、265 美元,團隊就能更常重跑、更快迭代,也能把 eval 從偶爾的大型活動,變成持續的工程流程。

Pareto front 把「差不多好」變成可選擇

傳統排名只會問誰分數最高;Pareto front 問的是:在品質不明顯退步的前提下,哪個模型更快、更便宜、更省能源。這種視角會把許多「分數差一點點但效率好很多」的模型帶回決策桌上。

影片描述中特別提到,quality score 緊密聚集的三到四個模型,可能在效率上差到 20x。這代表 production 選型不能只看小數點後的品質差異;如果使用者體感、成本或吞吐量是限制,效率更好的模型可能才是實際上的最佳模型。

小型 specialized models 會被重新看見

當評測只看整體品質,最大型 foundation models 常常佔據注意力。但一旦把 latency 與 cost 畫進同一張圖,小型 specialized models 可能落在 frontier 上:品質接近、效率明顯更好,而且更適合被部署到特定場景。

這對 AI 工程團隊的啟發很直接:不要把模型選型當成採購排名表,而要當成系統設計。每個 use case 都應該有自己的品質門檻、延遲預算、成本上限與能耗考量。

實務啟發:把模型評測改成決策工具

01
排行榜只當初篩,不當最終答案
先用 public benchmark 找候選,再用自己的任務、資料與 failure cases 重新排名。
02
每次 eval 都記錄 quality、latency、cost、energy
如果只記分數,團隊會自然偏向更大模型;如果同時記效率,才看得見 deployment trade-off。
03
用 Pareto front 開會,而不是用 Top 1 開會
把 frontier 上的模型列出來,讓產品、平台與財務一起決定哪個點最符合當前限制。
// TL;DR