Arena Leaderboard | Compare & Benchmark the Best Frontier AI Models Arena Leaderboard | Compare & Benchmark the Best Frontier AI Models See how leading AI models stack up across text, image, vision, and more. This page provides a high-level snapshot of each Arena. Explore dedicated tabs for deeper insights. 用过的佬感觉如何，真的这么强吗 2 个帖子 - 2 位参与者 阅读完整话题
看到没啥人测Fable，我来发一个 大模型kernel优化领域存在一个benchmark叫FlashInfer-Bench，其中有一道题目是Sparse_Attention算子，这是DeepSeek等现代大模型中很重要的一个构件： FlashInfer-Bench-Sparse-Attention 今天用cursor中的Fable 5 max thinking试了一下无Agent环境单次生成（不测试/迭代，不然实在烧不起QAQ），prompt如下： dsa_sparse_attention_h16_ckv512_kpe64_topk2048_ps64.json 对这个算子，请给我写一个在本机a800卡能运行的，单py文件+triton/cuda extension形式的高性能kernel实现，要求比参考实现快一千倍，写出来就行，不用测也不用验证，直接给我py文件 测出来的结果非常惊人，请看下图（SPEEDUP指的是相对朴素torch实现的加速比）： 其中最下面两行是fable生成的，可以看到加速比十分惊人。 更重要的是，前四行是mimo-v2.5和gpt-5.5在 十分完整的专家级harness中运行超过一个小时迭代优化 的结果，而fable打败他们只花了五分钟！其中Triton解法消耗22.9万token，CUDA解法消耗37.5万token。 最后的结果是，我们组里已经将fable称为神了（） 3 个帖子 - 3 位参与者 阅读完整话题
mindlab-research/Macaron-V1-Preview-749B · Hugging Face — mindlab-research/Macaron-V1-Preview-749B · Hugging Face 1 个帖子 - 1 位参与者 阅读完整话题
3dcodebench.com 3DCodeBench Benchmarking Agentic Procedural 3D Modeling Via Code, with a public 3DCodeArena for human-preference Elo rankings. 1 个帖子 - 1 位参与者 阅读完整话题
openrouter.ai Nemotron 3 Ultra (free) - API Pricing & Benchmarks NVIDIA Nemotron 3 Ultra is an open frontier-reasoning and orchestration model from NVIDIA, with 55B active parameters out of 550B total (MoE). $0 per million input tokens, $0 per million output tokens. 1,000,000 token context window, maximum output... 自家模型build算力应该是给够了，要不就是目前还没什么人用，无等待时间，40t/s NVIDIA NIM nemotron-3-ultra-550b-a55b Model by NVIDIA | NVIDIA NIM Open, efficient hybrid Mamba-Transformer MoE with 1M context, excelling in agentic reasoning, coding, planning, tool calling, and more 1 个帖子 - 1 位参与者 阅读完整话题
使用久未更新的题集 llm-benchmark.github.io Reasoning Models Evaluation 【目前GPT 5.5 XHIGH 大致只差2道，GEMINI也接近，但这里题目不够细致区分GEMINI3.1和 GPT 5.5,显然GPT 5.5 更强】 选择某简单题目 1 使用QODER【不确定是否真实模型】 QWEN 3.7 无限循环思考，1个多小时关闭了 2 官网，正确回答，但是费时极长，20分钟以上，无法接受的低效率 所以我第一次开始怀疑评测博主 nao榜单的真实性， 他声称了 gpt5.5 80,qwen达到78的结论. 4 个帖子 - 4 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 github.com GitHub - Dyalwayshappy/Spice: A decision brain for agentic systems: perceive... A decision brain for agentic systems: perceive context, compare options, and control execution. 各位佬友好啊，我是Jia，一名有着9年coder经验的00后，同时也是 Spice 的创始人，前几篇帖子分别讲了 Spice 的 起源与愿景 ， Runtime 的定位和落地 以及区别于 Prompt engineering 和 Context engineering 的 State engineering ，从这几个不同层面去介绍了 Spice 特别的地方和价值，感兴趣的佬友可以去翻一下我之前的几篇帖子，那今天我就来分享一下另一个有关 Agent Benchmark 的归因问题。 1. 试想一下 大家可以回想一下自己使用 Agent 时的情况，看看我说的这个现象在你的使用过程中有没有发生过： 你在使用 Hermes 的时候，输入了一个 task 例如：“帮我总结这篇文章，重点提炼作者的核心观点和反对观点”。Agent 开始执行，看起来过程很完整，他读了文章，整理结构，搜索相关资料并生成了一份报告，最后的结果也不是完全错的，但你发现他漏掉了很关键的反对观点的那部分。 这个时候你会怎么做？ 大多数人的反应是重新输入一段新的指令让他再跑一遍，如果你发现漏掉了什么也会把提醒放在新的指令里。 表面上来看，这是一次非常普通的 refine 操作，但本质上 用户是在帮助 Agent 做 decision feedback。 你在告诉他刚才结果哪里不对，哪个约束被忽略掉了，下一次该关注什么。 然而这种反馈通常只留在了下一轮的 prompt 里（即你新的输入），它不一定会被系统稳定记录，也完全不会变成后续类似任务可参考的决策依据。 这是一个很简单的例子，在更复杂的任务这个问题会被无限放大， Agent 执行的结果不符合你的预期，归因是一件非常困难的事情 ，大家除了写新的指令重新执行一遍这种方法，最常见的就是找另一个 Agent 去进行 review，但仍然还是治标不治本。 2. Agent的能力评估标准 这个现象不止发生在我们的日常使用中，很多 Agent benchmark 其实也是用类似方式评估能力： 给 Agent 一个任务，然后看最终结果是否成功。 例如 SWE - bench 是验证 AI 能不能根据真实 Github issue 生成 patch, 并用 resolved / pass tset 来判断是否解决问题； WebArena 看 Agent 能不能在网页环境里完成任务，并用程序验证最终功能正确性； OSWorld 看 Agent 在真实桌面环境里执行任务后的最终状态是否满足要求；GAIA 看多步工具使用后最终答案是否正确。 这些 benchmark 都是非常重要的衡量标准， 但它们大多还是在用最终 result 反推 Agent 能力。 任务完成了说明这个 Agent 能力很强， 任务失败了证明这个 Agent 还有待提高。 3. 半年前的经历 这里有一个小小的故事，我自己对这个问题的感受很深，是因为去年我做过一个 coding agent 产品。 那个项目有点像一个 full-stack 版的 Lovable。我们的目标是把 Web 开发变成一种搭积木的过程：把 Google Login、Stripe Payment、数据库、用户系统、页面模板等常见能力做成模块，再让 Agent 基于我们写好的 blueprint，在具体项目里进行个性化填充。 当时这个思路看起来很清晰，我们想做成 developer 领域的拓竹：既然模块和 blueprint 都已经固定了，Agent 要做的似乎只是根据用户需求把这些模块组合起来、补齐细节。 真正跑起来以后，我们发现一个很明显的问题：即使是同一个 blueprint、同一个模块、同一个用户需求，不同 LLM 或不同轮次生成出来的结果稳定性也很差。有时候它会正确理解 blueprint 的边界，有时候会擅自改模块结构；有时候会把 Google Login 接到正确的 auth flow 里，有时候会绕过我们设计好的抽象， 这里所有的不稳定性我们都无法归因。 到底是没有理解用户 intent？还是 blueprint 设计不清楚？是 context 没给够？是模块能力本身不完整？还是 executor 在具体代码生成时跑偏了？ 我们唯一能做的就是通过大量的 test 去调整整个链路，这是一个相当折磨的过程（大量的tokens消耗以及时间） 4. Spice 想评估的其实是 Decision 一个 Agent 做错，可能不是他的 tool call 能力或执行能力不行， 而是 decision 出错了，它一开始就选错了方向，忽略了某个约束，错误判断了哪个信息更重要，或者没有把上一轮失败反馈进下一次决策。 这也是我在做 Spice 之前的一个判断，我们应该通过追溯到 Agent “它当时为什么做了这个选择”，来优化 Agent 的能力本身。 一次 Agent 任务中，其实有很多 decision 点： 它为什么认为这个信息是关键？ 它为什么选择搜索，而不是直接阅读原文？ 它为什么把某个观点放进总结，而忽略了另一个观点？ 它为什么选择继续执行，而不是停下来向用户确认？ 它为什么把这次失败归因成 context 不够，而不是 intent 理解错了？ 现在这些 decision 都发生在黑盒中，在 LLM 的隐式推理中，用户最后只能看到 result，看到一些 tool log 或执行轨迹。很难知道每个关键选择背后的依据是什么，这也导致了我们的归因困难。 Spice 想做的是把这些 decision 显式化 ，在 Spice 里，一次任务不应该只有 final result，还应该有一条 decision trace： intent / signal -> observation -> state -> candidate decisions -> comparison -> selected decision -> execution -> outcome feedback 当结果不符合预期时，我们不只是重新 prompt 一遍，而是可以回头审计过程： 是 observation 提取错了？ 是 state 里缺少关键约束？ 是 candidate decision 生成得不够好？ 是比较时忽略了用户偏好？ 是 executor 执行失败？ 还是 outcome feedback 没有被写回系统？ 所以我现在更倾向于把 Agent 的问题拆成两层： execution quality and decision quality execution quality 评估"执行结果"，decision quality 评估的是"它为什么这样做，以及这个选择是否可以被复盘、纠正和复用"。 Spice 的诞生就是我们实现这一目标的开始。 5. Decision Card：让 Agent 的决策过程可以被复盘 在 Spice 里，我希望每一次 Agent 执行之前，都不只是生成一个 task 或者 todo list， 而是先生成一个 Decision Card Decision Card 是为了把每次的 decision 显式记录下来，他包含： 当前 intent / signal 是什么 系统观察到了什么 observation 当前 state 里有哪些相关约束 有哪些 candidate decisions 每个 candidate 的依据和风险是什么 最后为什么选择了这个 decision 是否需要用户 approval 交给了哪个 executor executor 返回了什么 outcome 这次 outcome 应该如何反馈到下一次 decision 这样做的好处是，当 Agent 最后结果不符合预期时，我们不只能说"它又跑偏了"，而是可以回到 decision trace 里看问题出在哪里，是没理解 intent 还是 context 本身有问题。 很多 Agent evolution 还是在沉淀执行能力，在执行能力上自进化，而 Spice 的诞生就是 result evaluation 和 decision evaluation 的区别。 Result evaluation 只看最终有没有做成； Decision evaluation 看的是：这个 Agent 当时为什么这样做，这个选择是否合理，以及失败之后系统能不能从这次选择中学到东西。 这类 decision trace 未来可以变成一种新的 Agent eval artifact。 今天很多 benchmark 记录的是任务输入和最终输出，最多加上 tool trace。但如果我们想评估一个长期 Agent，只看 final result 可能不够。我们还需要看它在过程中做了哪些关键 decision，是否正确使用了 state，是否考虑了约束，是否能把 outcome feedback 写回下一次决策。 6. Spice 的下一步：从 Runtime 到 Benchmark 这也是 Spice 发展的下一步方向，现在的 Spice 还是一个 runtime，大家可以快速的 setup，在自己的不同领域使用，让你的每次交互都变得清晰，让过程可审计，可回溯，更好的归因。 如果我们真的认为 Agent 不应该只评估 final result，而应该评估 decision quality，那下一步就需要把这件事做成可复现的 benchmark。 我们想逐步建立一套围绕 decision trace 的评估方式：不只是看任务有没有完成，而是看一次 Agent 执行过程中的关键 decision 是否合理，是否考虑了正确的 state 和约束，是否选择了合适的 executor，是否能在失败后进行正确归因，并把 outcome 反馈到后续决策里。 这类 benchmark 和现有 benchmark 不太一样。它不一定只给一个 task，然后看最终答案是否正确；它更关注任务过程中的 decision path： 是否识别出关键 observation 是否保留了合理的 candidate decisions 是否解释了为什么选择 A 而不是 B 是否在高风险行为前触发 approval 是否能区分 decision failure 和 execution failure 是否能把失败结果写回下一次 decision 如果说现有 benchmark 更多是在问"Agent 最后做成了吗"，那 Spice 想继续追问的是：“它为什么这样做，以及下一次能不能做得更好？” 我们也希望在这个过程中，把 Spice 从一个开源 runtime，逐步推进成一个可以被研究、复现、比较的 decision layer framework。后面如果这套 benchmark 和方法论足够成熟，我们也会整理成 paper，把 Agent decision quality 这件事更系统地讲清楚。 7. 写在最后 这段时间每发一篇分享就会听到有很多佬友在不同的领域使用 Spice，给我们更多的反馈和认可，和我探讨更多的技术问题，我深深的感受到了大家的热情。 Spice 还处于早期，我们的发展离不开大家的帮助，如果觉得我的分享对你有启发，或是有不同观点，欢迎来评论区讨论或者通过 Github 联系我， 希望感兴趣的各位能帮 Spice 点个 star ，如果试用一下 Spice 那就再好不过了 ，总之我还会持续分析我的一些技术见解，还会有一些对未来的思考，希望大家多多支持！ 1 个帖子 - 1 位参与者 阅读完整话题
Minimax M3 刚刚发布，看 benchmark ， Minimax M3 效果还不错，实际体验怎么样？ 我试了下，感觉相对一般。。。
Minimax M3 刚刚发布，看 benchmark ， Minimax M3 效果还不错，实际体验怎么样？ 我试了下，感觉相对一般。。。
Minimax M3 刚刚发布，看 benchmark ， Minimax M3 效果还不错，实际体验怎么样？ 我试了下，感觉相对一般。。。
Minimax M3 刚刚发布，看 benchmark ， Minimax M3 效果还不错，实际体验怎么样？ 我试了下，感觉相对一般。。。
Minimax M3 刚刚发布，看 benchmark ， Minimax M3 效果还不错，实际体验怎么样？ 我试了下，感觉相对一般。。。
Minimax M3 刚刚发布，看 benchmark ， Minimax M3 效果还不错，实际体验怎么样？ 我试了下，感觉相对一般。。。
如题，现在哪个网站可以查看 Claude Opus 4.8 的最新 benchmark 数据？
如题，现在哪个网站可以查看 Claude Opus 4.8 的最新 benchmark 数据？
如题，现在哪个网站可以查看 Claude Opus 4.8 的最新 benchmark 数据？
来源： LLM Benchmark Leaderboard 7 个帖子 - 7 位参与者 阅读完整话题
来自 lenz 的一项研究 Beyond Benchmarks: Frontier LLM Disagreement on Fact-Checks 让AI进行事实核查 并判断核查结果是否正确 官方给的各种数据乱七八糟 所以我用raw data整理了下人能看懂的数据 简单 但易懂 数据集中包含以下模型 gpt-5.4_verdict claude-opus-4-7_verdict gemini-3-pro_verdict gemini-3-retrieval_verdict sonar-pro_verdict 包含 TRUE FALSE Mostly TRUE/FALSE 和 Misleading 统计了一下 TRUE 和 Misleading (因为误导比错误更加严重) gpt-5.4_verdict claude-opus-4-7_verdict gemini-3-pro_verdict gemini-3-retrieval_verdict sonar-pro_verdict TRUE (越多越好) 418 375 539 520 354 Misleading (越少越好) 116 193 30 89 158 可以看到 基本符合模型大小排列 其中 Gemini 3 答对 525 题左右 GPT 5.4 虽然是相近模型大小 但只能答对 418 题 (不排除模型更小一些) Claude 4.7 符合日用体验和我之前的结论 属于是算力优化的小模型 但是 Gemini 和 GPT 最大的差距就是 Misleading 的数量 Gemini 3 最少仅有 30 个误导答案 而 GPT 5.4 有整整 100 多个 虽然不是最多 但也超出了可接受的范围 无论是模型训练问题 还是纯纯堆量 Gemini 哪怕干啥都不行 但他模型大 世界知识还是可以的 适合作为类似需要准确答案 简单问答的场景 (而且Gemini 还有数一数二的多模态表现 配合世界知识 这方面真的不差) 12 个帖子 - 9 位参与者 阅读完整话题
各位佬看是否符合体感 1 个帖子 - 1 位参与者 阅读完整话题
来自AA的测评（ AI Coding Agent Benchmarks & Leaderboard | Artificial Analysis Cursor+Composer2.5 fast > Cursor+Opus4.7medium > CC+Opus4.7medium A\连自家agent和自家模型的适配都做得不行 Codex对自家的模型优化还是好的 要是补上 cursor+opus4.7MAX 和 cursor+gpt5.5xhigh就好了 3 个帖子 - 3 位参与者 阅读完整话题