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 月）。
 
 
    
     请喝咖啡