Skip to content
AI-Daily-Builder

評測

已執行基準
8
正面對決
最新一次
2026-05-29
最近一次基準
比較模型
4+
Claude · GPT · Gemini · 開源
追蹤指標
4
延遲 · tokens · 成本 · 結論
每月基準數
NaN NaN NaN

2026-05-29 · benchmark

SWE-bench Verified — 2026 年 5 月代理式編程排行榜（pass@1 %）

顯示 prompt 
SWE-bench Verified 是 500 個經人工驗證的真實 GitHub issue，取自熱門開源 Python 專案。模型驅動的代理必須讀懂 issue、定位要修改的檔案、撰寫修補、套用，並通過該倉庫隱藏的測試套件——沒有提示，以「完全解決的 issue 百分比（pass@1）」計分。本卡片彙整的是截至 2026-05-28 各公開排行榜的已發布準確率；這不是延遲基準測試。
Model Latency 成本 評語
Claude Mythos Preview (restricted) 0ms — 勝
GPT-5.5 0ms — 勝
Claude Opus 4.8 0ms — 勝
Claude Opus 4.7 (Adaptive) 0ms — 平
GPT-5.3-Codex 0ms — 平
Gemini 3.1 Pro 0ms — 負
DeepSeek V4 Pro Max (open-weight) 0ms — 負
顯示回答

Claude Mythos Preview (restricted)

93.9% 解決 · 第 1 名 · 公開排行榜（受限存取模型）

GPT-5.5

88.7% 解決 · 公開排行榜

Claude Opus 4.8

88.6% 解決 · 公開排行榜

Claude Opus 4.7 (Adaptive)

87.6% 解決 · 公開排行榜

GPT-5.3-Codex

85.0% 解決 · 公開排行榜

Gemini 3.1 Pro

80.6% 解決 · 公開排行榜

DeepSeek V4 Pro Max (open-weight)

80.6% 解決 · 公開排行榜 · 最佳開放權重

這是已發布的準確率排行榜，而非實測延遲：每一列的 `latency_ms` 皆設為 0（不適用），token／成本欄位一律省略——可驗證的數據是每列 `response` 中的 pass@1 %。分數彙整自公開的 SWE-bench Verified 排行榜（swebench.com、llm-stats.com、benchlm.ai、andrew.ooo、marc0.dev），快照約 2026-05-28；確切數字會因 harness、scaffold 與快照日期而異，±1-2 分視為雜訊。判定分級（依準確率，非速度）：win = 88%+、tie = 84-87.9%、loss = 低於 84%。Claude Mythos Preview 為受限存取模型，其 93.9% 雖有發布，但多數團隊無法執行。重點：(1) 前沿已壓縮——前三名（Mythos 93.9、GPT-5.5 88.7、Opus 4.8 88.6）相差約 5 分內；(2) 代理式編程通過率破 88% 代表此基準正在飽和，SWE-bench Pro／Terminal-Bench Hard 成為更佳的區分器；(3) 開放權重的 DeepSeek V4 Pro Max 以 80.6 落後封閉前沿約 13 分，但正在追近。

2026-05-24 · benchmark

DGX Spark（GB10）本地模型吞吐量 — 13 組模型/量化/引擎的 prefill 與 decode tok/s

顯示 prompt 
在單台 DGX Spark（GB10，128 GB LPDDR5X 統一記憶體，約 273 GB/s 頻寬，約 1 PFLOP FP4）上的標準化單流（batch size 1）推論：2,048 token 輸入、128 token 輸出（ISL/OSL 2048/128）。每一列是一組「模型 + 量化 + 推論引擎」。我們回報提示處理吞吐量（prefill，'pp'）與 token 生成吞吐量（decode，'tg'），單位為 tokens/秒。所示延遲為依已發布 decode 速率生成 128 個 token 的模型化時間（128 / tg × 1000）。
Model Latency 成本 評語
GPT-OSS-20B · MXFP4 · llama.cpp 1547ms — 勝
Qwen3.5-35B-A3B · MXFP4 · llama.cpp 2207ms — 勝
GPT-OSS-120B · MXFP4 · llama.cpp 2312ms — 勝
Qwen2.5-VL-7B · NVFP4 · TRT-LLM (vision) 3069ms — 勝
Llama 3.1 8B · NVFP4 · TRT-LLM 3312ms — 勝
Qwen3-Coder-30B-A3B · Q8_0 · llama.cpp 4129ms — 勝
Qwen3.6-27B · Q4_K_M +MTP · llama.cpp 4523ms — 平
Gemma 4 26B-A4B · F16 · llama.cpp 4830ms — 平
Qwen3-14B · NVFP4 · TRT-LLM 5637ms — 平
Llama 3.1 8B · FP8 · SGLang 6244ms — 平
Qwen3.6-27B · Q4_K_M · llama.cpp 9771ms — 平
Llama 3.1 70B · FP8 · SGLang 47407ms — 負
Qwen3-235B · NVFP4 · TRT-LLM (DUAL Spark) 10912ms — —
顯示回答

GPT-OSS-20B · MXFP4 · llama.cpp

3670.42 pp / 82.74 tg tok/s · llama.cpp · NVIDIA-official

Qwen3.5-35B-A3B · MXFP4 · llama.cpp

prefill n/p / ~58 tg tok/s · llama.cpp · community (MoE A3B; theoretical ceiling ~91)

GPT-OSS-120B · MXFP4 · llama.cpp

1725.47 pp / 55.37 tg tok/s · llama.cpp · NVIDIA-official (canonical official 120B decode; engine spread 35 llama.cpp deep-ctx → 41 Ollama → ~50 SGLang)

Qwen2.5-VL-7B · NVFP4 · TRT-LLM (vision)

65831.77 pp / 41.71 tg tok/s · TRT-LLM · NVIDIA-official

Llama 3.1 8B · NVFP4 · TRT-LLM

10256.9 pp / 38.65 tg tok/s · TRT-LLM · NVIDIA-official

Qwen3-Coder-30B-A3B · Q8_0 · llama.cpp

1308 pp / 31 tg tok/s · llama.cpp · community (llama.cpp #16578; MoE A3B)

Qwen3.6-27B · Q4_K_M +MTP · llama.cpp

719 pp / 28.3 tg tok/s · llama.cpp +MTP (5 draft) · community (2.16x decode vs no-MTP)

Gemma 4 26B-A4B · F16 · llama.cpp

prefill n/p / ~26.5 tg tok/s · llama.cpp · community (MoE A4B; theoretical ~34)

Qwen3-14B · NVFP4 · TRT-LLM

5928.95 pp / 22.71 tg tok/s · TRT-LLM · NVIDIA-official

Llama 3.1 8B · FP8 · SGLang

7991 pp / 20.5 tg tok/s · SGLang · community (FP8 decode ~half of NVFP4 — same model)

Qwen3.6-27B · Q4_K_M · llama.cpp

1084 pp / 13.1 tg tok/s · llama.cpp · community (single-stream, no spec-decode)

Llama 3.1 70B · FP8 · SGLang

~803 pp / ~2.7 tg tok/s · SGLang · community (barely fits 128 GB; KV+weights thrash — avoid dense 70B FP8 on one unit)

Qwen3-235B · NVFP4 · TRT-LLM (DUAL Spark)

23477.03 pp / 11.73 tg tok/s · TRT-LLM · NVIDIA-official · DUAL DGX Spark over ConnectX-7 (does not fit one unit at usable quant)

單台 DGX Spark GB10（128 GB LPDDR5X，273 GB/s）。'pp' = 提示處理 / prefill tok/s；'tg' = token 生成 / decode tok/s。判定分級依單流 decode：win = 30+ tok/s（互動流暢），tie = 10-30（可用），loss = 低於 10（不實用）。每列標註來源等級：NVIDIA-official = developer.nvidia.com「How DGX Spark Performance Enables Intensive AI Tasks」（ISL/OSL 2048/128，BS=1）；community = NVIDIA 開發者論壇 / llama.cpp issues / SGLang 實測。重點：(1) decode 受記憶體頻寬限制 — tg tok/s 約等於每 token 活躍參數位元組 ÷ 273 GB/s，因此 MoE（A3B）與更低位元量化會提升它。(2) prefill 受 Blackwell FP4 核心算力限制 — 不論模型大小通常都有數千 tok/s。(3) 量化格式很重要：NVFP4/MXFP4 的 decode 約為 FP8 的 2 倍（Llama 3.1 8B：38.65 NVFP4 vs 20.5 FP8）。(4) 推測式 MTP 約可讓單流 decode 翻倍（Qwen3.6-27B：13.1 → 28.3），但在並發下會退步。(5) 稠密 70B 在 FP8 下勉強塞進 128 GB 且會抖動（約 2.7 tg）— 單台應避免。(6) 235B 需要兩台 Spark 透過 ConnectX-7 連接。彙整自已發布的基準；除非標註 DUAL，所有數據皆為單台。

2026-05-24 · benchmark

LEFT JOIN 悄悄變成 INNER JOIN — SQL 正確性對決

顯示 prompt 
兩張表：customers(id, name) 與 orders(id, customer_id, total)。同事寫了這個查詢，想列出每位客戶及其訂單數量，並且要「包含」零訂單的客戶：

SELECT c.id, c.name, COUNT(o.id) AS order_count
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.total > 0
GROUP BY c.id, c.name;

但結果中卻少了零訂單的客戶。請明確解釋原因，並改寫查詢，讓零訂單客戶以 order_count = 0 出現。回傳修正後的 SQL 以及一句話說明。
Model Latency 成本 評語
claude-opus-4-7 4180ms $0.016 勝
gpt-5 3360ms $0.007 勝
gemini-3-pro 2980ms $0.002 平
qwen3.6-35b-a3b-nvfp4 (local DGX Spark) 9100ms — 負
顯示回答

claude-opus-4-7

The WHERE o.total > 0 runs AFTER the LEFT JOIN. For a customer with zero orders every o.* column is NULL, and NULL > 0 is not TRUE, so those rows are dropped — collapsing the LEFT JOIN into an INNER JOIN. Move the predicate into the ON clause so it filters the join, not the result:

SELECT c.id, c.name, COUNT(o.id) AS order_count
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id AND o.total > 0
GROUP BY c.id, c.name;

Unmatched customers keep one all-NULL row and COUNT(o.id) correctly returns 0.

gpt-5

A post-join WHERE on a right-table column nullifies the outer join: zero-order customers produce NULL o.total, and NULL > 0 fails, so they are filtered out. Relocate the filter to the join condition:

SELECT c.id, c.name, COUNT(o.id) AS order_count
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id AND o.total > 0
GROUP BY c.id, c.name;

COUNT(o.id) skips NULLs, so zero-order customers report 0.

gemini-3-pro

Right — the WHERE clause removes the NULL rows produced by the LEFT JOIN, so customers with no orders disappear. Keep them by also allowing the NULL case:

SELECT c.id, c.name, COUNT(o.id) AS order_count
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.total > 0 OR o.id IS NULL
GROUP BY c.id, c.name;

This restores the zero-order customers.

qwen3.6-35b-a3b-nvfp4 (local DGX Spark)

The problem is COUNT with GROUP BY: COUNT(o.id) returns NULL when there are no matching orders, so wrap it in COALESCE to show 0:

SELECT c.id, c.name, COALESCE(COUNT(o.id), 0) AS order_count
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.total > 0
GROUP BY c.id, c.name;

This defaults missing counts to 0.

陷阱：對 LEFT JOIN 右表欄位下的 WHERE 條件會在 join「之後」執行。未配對（零訂單）的客戶其訂單欄位全為 NULL，而 NULL > 0 不為 TRUE，因此這些列被過濾掉 — 悄悄把 LEFT JOIN 變成 INNER JOIN。乾淨的修法是把條件移進 ON 子句（LEFT JOIN orders o ON o.customer_id = c.id AND o.total > 0），讓它過濾 join 而非結果；此時 COUNT(o.id) 會忽略剩下的 NULL 並回傳 0。判定標準：win = 正確診斷（WHERE 使外連接失效）且採用乾淨的 ON 子句修法；tie = 診斷正確但修法笨拙或部分正確（例如 WHERE ... OR o.id IS NULL，會錯誤處理「唯一訂單 total <= 0」的客戶）；loss = 診斷錯誤或修法仍丟失零訂單列。延遲 / token / 成本為短單輪任務的代表值；本地模型列反映 DGX Spark 上的 Qwen3.6-35B-A3B NVFP4。

2026-05-09 · benchmark

修復 cursor 分頁的 off-by-one bug — agentic 程式碼編輯對決

顯示 prompt 
以下是一個 cursor 分頁的 Node.js handler：

```js
function paginate(items, cursor, limit = 20) {
  const start = cursor ? items.findIndex(i => i.id === cursor) : 0;
  return {
    data: items.slice(start, start + limit),
    next: items[start + limit]?.id ?? null,
  };
}
```

它有個微妙的 off-by-one bug：當給定 cursor 時，第一個回傳的是 cursor 本身（應該是 cursor *之後* 的 item）。修復這個函式。保留同樣的 signature 與回傳形狀。只在 bug 處加單行 inline 註釋。回傳僅修正後的函式，不要前言。
Model Latency 成本 評語
claude-opus-4-7 2240ms $0.011 勝
gpt-5 1890ms $0.009 勝
gemini-3-pro 2050ms $0.007 平
qwen3.6-35b-a3b-nvfp4 920ms $0.001 勝
顯示回答

claude-opus-4-7

function paginate(items, cursor, limit = 20) {
  const start = cursor ? items.findIndex(i => i.id === cursor) + 1 : 0; // bug fix: skip cursor itself
  return {
    data: items.slice(start, start + limit),
    next: items[start + limit]?.id ?? null,
  };
}

gpt-5

function paginate(items, cursor, limit = 20) {
  // bug fix: cursor item itself was being returned; advance past it
  const start = cursor ? items.findIndex(i => i.id === cursor) + 1 : 0;
  return {
    data: items.slice(start, start + limit),
    next: items[start + limit]?.id ?? null,
  };
}

gemini-3-pro

function paginate(items, cursor, limit = 20) {
  let start = 0;
  if (cursor) {
    const idx = items.findIndex(i => i.id === cursor);
    if (idx >= 0) start = idx + 1; // bug fix: cursor was inclusive
  }
  return {
    data: items.slice(start, start + limit),
    next: items[start + limit]?.id ?? null,
  };
}

qwen3.6-35b-a3b-nvfp4

function paginate(items, cursor, limit = 20) {
  const start = cursor ? items.findIndex(i => i.id === cursor) + 1 : 0; // off-by-one fix
  return {
    data: items.slice(start, start + limit),
    next: items[start + limit]?.id ?? null,
  };
}

測試模型是否抓到 off-by-one（start 應為 findIndex(...) + 1），且不破壞 cursor=null 分支。延遲於 client-side 量測。成本依 2026 年 5 月公開定價。所有模型給予完全相同的 prompt。

2026-05-09 · benchmark

從零亂的會議筆記中萃取 JSON — schema 嚴謹度測試

顯示 prompt 
從以下會議筆記中萃取資料，產出嚴格符合此 schema 的 JSON：

{
  "date": "YYYY-MM-DD",
  "attendees": ["name1", "name2"],
  "action_items": [{"owner": "name", "task": "...", "due": "YYYY-MM-DD or null"}]
}

筆記：
---
Met today (it's the 9th of May 2026, finally Friday) — me, Sarah Chen, Raj P, and Tomás joined late from his car. Sarah said she'd ship the auth migration by next Wed (so 13th?). Raj is still chasing the SSO config from the vendor — no firm date, said "sometime next week". Tomás owes a draft of the launch post but said no rush. I'll handle the customer interview write-up by EOD Monday.
---

**僅**回傳 JSON。不要前言、不要 markdown 圍欄、不要尾隨註解。
Model Latency 成本 評語
claude-opus-4-7 1620ms $0.014 勝
gpt-5 1340ms $0.012 平
gemini-3-pro 1560ms $0.008 負
qwen3.6-35b-a3b-nvfp4 720ms $0.001 平
顯示回答

claude-opus-4-7

{"date":"2026-05-09","attendees":["Sarah Chen","Raj P","Tomás"],"action_items":[{"owner":"Sarah Chen","task":"Ship the auth migration","due":"2026-05-13"},{"owner":"Raj P","task":"Chase SSO config from vendor","due":null},{"owner":"Tomás","task":"Draft of the launch post","due":null},{"owner":"me","task":"Customer interview write-up","due":"2026-05-11"}]}

gpt-5

{"date":"2026-05-09","attendees":["Sarah Chen","Raj P","Tomás"],"action_items":[{"owner":"Sarah Chen","task":"Ship the auth migration","due":"2026-05-13"},{"owner":"Raj P","task":"Chase SSO config from vendor","due":null},{"owner":"Tomás","task":"Draft launch post","due":null},{"owner":"narrator","task":"Customer interview write-up","due":"2026-05-12"}]}

gemini-3-pro

```json
{"date":"2026-05-09","attendees":["Sarah Chen","Raj P","Tomás"],"action_items":[{"owner":"Sarah Chen","task":"ship auth migration","due":"2026-05-13"},{"owner":"Raj P","task":"SSO config from vendor","due":null}]}
```

qwen3.6-35b-a3b-nvfp4

{"date":"2026-05-09","attendees":["Sarah Chen","Raj P","Tomás"],"action_items":[{"owner":"Sarah Chen","task":"Ship auth migration","due":"2026-05-13"},{"owner":"Raj P","task":"Chase SSO config from vendor","due":null},{"owner":"Tomás","task":"Draft launch post","due":null},{"owner":"author","task":"Customer interview write-up","due":"2026-05-12"}]}

測試項目：日期推論（today = 2026-05-09）、姓名正規化（Sarah Chen / Raj P → Raj Patel?? 保持原樣）、空值 due（'sometime next week' / 'no rush' = null）、以及對「不要散文」約束的遵循。回應若含 markdown 圍欄即視為失敗。

2026-05-09 · benchmark

50 萬 token 的稻草堆中找針 — 長上下文召回

顯示 prompt 
你會收到一份 500,000-token 的文件，內容是 12 篇 NeurIPS 論文全文串接。在字元偏移量 1,847,392 處埋了一句話：'The secret access code for the May 2026 builder-daily benchmark is QUARTZ-7392-DELTA.'

問題：secret access code 是什麼？只回傳代碼本身，其他都不要。

文件接續於下方標記之後。

--- DOCUMENT START ---
[~500,000 tokens of NeurIPS paper text]
--- DOCUMENT END ---
Model Latency 成本 評語
claude-opus-4-7 18420ms $7.535 勝
gpt-5 22180ms $6.279 勝
gemini-3-pro 14620ms $0.628 勝
qwen3.6-35b-a3b-nvfp4 (262K cap) 0ms $0.000 錯誤
顯示回答

claude-opus-4-7

QUARTZ-7392-DELTA

gpt-5

QUARTZ-7392-DELTA

gemini-3-pro

QUARTZ-7392-DELTA

qwen3.6-35b-a3b-nvfp4 (262K cap)

 
 
 
 
純召回測試，位於 500K 輸入的 70% 深度點。延遲含 prompt processing（在此規模下為主導）。成本依 50 萬 token 全量輸入計算。verdict 'win' = 完全比對 'QUARTZ-7392-DELTA'。各模型於官方宣稱之最大上下文進行測試。
 
 
2026-05-09 · benchmark
 
挑對工具 — 6 個函式可選的多步驟任務
 
  顯示 prompt  
你有以下工具可用：`web_search(query)`、`fetch_url(url)`、`read_file(path)`、`run_shell(cmd)`、`query_database(sql)`、`send_email(to, subject, body)`。

任務：找出 Anthropic Claude 4.7 釋出公告的最新發布日期，抓取該頁完整文字，計算 'tool' 一字出現幾次，並把次數 email 到 ops@example.com，主旨「Claude 4.7 tool count」。

回應**僅** JSON 陣列，依執行順序的工具呼叫：[{"tool": "...", "args": {...}}, ...]。不要散文、不要 markdown、不要其他文字。
 
 
 
  
 Model Latency 成本 評語 
   
 claude-opus-4-7 1480ms $0.013   勝   
 gpt-5 1320ms $0.011   平   
 gemini-3-pro 1810ms $0.009   負   
 kimi-k2.6 980ms $0.001   勝   
  
 
 
  顯示回答  
 
 
claude-opus-4-7
 
[
  {"tool": "web_search", "args": {"query": "Anthropic Claude 4.7 release announcement date site:anthropic.com"}},
  {"tool": "fetch_url", "args": {"url": "<url-from-prior-result>"}},
  {"tool": "send_email", "args": {"to": "ops@example.com", "subject": "Claude 4.7 tool count", "body": "<count>"}}
]
 
 
gpt-5
 
[
  {"tool": "web_search", "args": {"query": "Claude 4.7 release announcement Anthropic"}},
  {"tool": "fetch_url", "args": {"url": "<top result url>"}},
  {"tool": "run_shell", "args": {"cmd": "echo $TEXT | grep -o tool | wc -l"}},
  {"tool": "send_email", "args": {"to": "ops@example.com", "subject": "Claude 4.7 tool count", "body": "<count>"}}
]
 
 
gemini-3-pro
 
I'll help you with that. Here's the plan: [
  {"tool": "web_search", "args": {"query": "Claude 4.7"}},
  {"tool": "web_search", "args": {"query": "Anthropic announcement"}},
  {"tool": "fetch_url", "args": {"url": "..."}},
  {"tool": "send_email", "args": {"to": "ops@example.com", "subject": "Result", "body": "..."}}
]
 
 
kimi-k2.6
 
[
  {"tool": "web_search", "args": {"query": "Anthropic Claude 4.7 release announcement"}},
  {"tool": "fetch_url", "args": {"url": "<from search>"}},
  {"tool": "send_email", "args": {"to": "ops@example.com", "subject": "Claude 4.7 tool count", "body": "<count>"}}
]
 
 
 
 
測試模型是否選對 4 個工具的正確順序：web_search → fetch_url →（在地計數，無工具）→ send_email。扣分項：多餘工具、順序錯誤、漏 send_email、有前言。
 
 
2026-05-02 · benchmark
 
把 1000 字文章壓成 3 個 bullet — 前沿模型對決
 
  顯示 prompt  
把這篇 1000 字、關於 Anthropic Claude 4.7 發布的部落格，總結成剛好 3 個 bullet，每個 ≤ 25 字。只回 bullet，不要前言。
 
 
 
  
 Model Latency 成本 評語 
   
 claude-opus-4-7 1240ms $0.022   勝   
 gpt-5 980ms $0.018   平   
 gemini-3-pro 1120ms $0.014   負   
  
 
 
  顯示回答  
 
 
claude-opus-4-7
 
• Anthropic 發布 Claude 4.7，1M token context 終於來到 Opus 等級。
• 高並發工具呼叫下，工具呼叫穩定度提升；prompt cache TTL 維持 5 分鐘。
• 早期使用者回報 Sonnet/Haiku 的 p95 延遲降約 12%；Opus 改善為宣稱、未驗證。
 
 
gpt-5
 
• Anthropic 發布 Claude 4.7，主打：1M context 來到 Opus 等級。
• Anthropic 宣稱整個模型家族的 p95 延遲約改善 12%。
• 在平行／高並發情境下，工具呼叫行為更穩定。
 
 
gemini-3-pro
 
• Anthropic 今天發布了 Claude 4.7，包含多項更新。
• 1M context window 現在除了 Sonnet 和 Haiku 外，也支援 Opus 等級，這對長 context 的 agentic workflow 是一大改變。
• 根據 Anthropic 的說法，延遲降低了大約 12%，工具使用的行為也有改善。
 
 
 
 
同 prompt、同輸入。延遲從 API 呼叫開始到最後一個 byte。成本依官方 $/Mtok 計算（2026 年 5 月）。
 
 
    
     請喝咖啡