Gemini 4 Carbon 值得多等一会儿吗？两份独立测试给出的取舍

封面采用 Google 官方发布主视觉，仅作报道引用，不代表官方合作、本站生成或实测。

Gemini 4 Carbon 值不值得多等，取决于那段等待换回了什么。 Plotly 的一轮数据分析测试里，它比 Argon 多答对一道题，但每题耗时中位数是 93 秒，对方是 23 秒；Vals 的财务工作指数里，它领先 1.05 个百分点，而测试方明确说两者差距在误差范围内。两份独立原测把同一个选型问题拉到了任务层面：先确定什么结果可交付、错误要付出多少复核成本，再看等待与账单。它们也测试了不同的工作，不能被拼成一张“Carbon 全面胜出”的成绩单。

如果你想知道 Carbon 什么时候公开、怎么调用、在 pirouter 上按什么价格计费，11 月 11 日的发布稿已经逐项说明。这里不再重讲开放入口。本文只追问一件更窄、也更接近实际工作的事：当两个模型都能完成大部分任务，剩下那一点差异是否足以改变默认选择？

43 道数据分析题里，多答对一题不等于稳赢

先看最容易被转成标题的数字。Plotly 的 Carbon 原始评测报告，它在自家的 DataAnalyticsBench 里答对 42/43 题，Argon 是 41/43 题。如果只把这一列搬进采购表，Carbon 看起来有一个明确的分数优势。可这套题只对一个合成的风电数据仓库发问，每个模型只跑了一轮。Plotly 在测试方法与总榜说明里提醒：其他模型的重复运行曾出现最多三题的分数波动；一两题的差别，应当视为相近，而不是精确排名。

这不是一套单纯的“查出表格里的数字”考试。Plotly 用自己的 Studio Embedded 分析代理访问约 2000 万行数据，43 题分成六组：20 道直接分析题、5 道存在合理歧义的问题、5 道数据无法支持的请求、5 道统计陷阱、3 道数据质量问题、5 道需要找出隐藏规律的问题。六组加起来是 43，不是六个额外加权的百分比。Plotly 给的题型例子很直观：只有风电数据的仓库，却问太阳能发电量，合格回答应指出资料不支持；问“哪座风场表现最好”，则要先说明“最好”按发电量、效率还是成本衡量。这两题考的不是复杂算术，而是代理会不会承认没有数据、会不会在一个含糊问题上擅自选指标。一个模型答对常规汇总题，并不代表它会在“这个问题无从回答”时停下来，也不代表它能识别数据污染而不误报。对分析团队来说，后两种错误通常比公式写得漂亮更费时间。

Plotly 的分项表让一题之差更具体：Carbon 在直接分析题得 20/20，Argon 19/20；歧义、无法回答、统计陷阱和隐藏规律四组在这轮里两者均满分。数据质量一组，两者都是 2/3。因此，Carbon 的总分优势来自直接分析题，并非“更擅长抓数据质量缺陷”。如果团队最担心的是错过缺失数据或虚构异常，这一组恰好没有给出升级的可靠理由。要下结论，还需要在自己的错误分布上重测。

这轮评估使用 Plotly 的专用代理，经 OpenRouter 对接 Google AI Studio，单次请求最大输出设为 32,768 token。原文没有披露精确 API model ID、思考档或实际执行日；总榜方法页中 11 月 9 日是 Released 列，不是测试日。这些是复用结果时应留在来源旁的条件，而不是本篇另一个“发布后新测”的新闻点。

一个误报，会把一份“认真”的报告带向哪里

分数之外，Plotly 公开了 Carbon 在数据质量审计里的一处失误：它把数据的预期特征当成缺陷，并把这个并不存在的问题排在报告前面。它的解释显得谨慎，其他发现也正确，但如果分析员直接照单派工，就会让团队追查一个不存在的故障。这是该次测试中的一个可描述案例，不是我们发现了 Carbon 有固定的误报率，也不能据此推断 Argon 不会犯同类错误——两者在数据质量组三题里都只对了两题。

这类结论交给分析员前，可以先要求四件可复查的东西：数据集、时间窗口、判断异常的对照基线、可复算的查询或文件位置。如果模型说某字段缺失，却没写清原本应在哪些记录出现，审阅者无法判断它发现了缺陷，还是把筛选后的正常状态误读了。缺基线时标待核，不自动派单；审阅者确认后再决定修数据、改查询，还是纠正模型。这里是针对 Plotly 案例提出的编辑建议，并非本站验证过的一套产品流程。

还要分别记下两种错误。把正常特征判为异常是误报，成本在无谓的排查、工单与解释；没有抓到真实缺陷是漏报，成本可能在随后使用错误结论作决策。可设想一条自动工单写着“最近一周订单缺失”，复核才发现查询刻意排除了退款单：误报会耗费排查时间，但这不是 Plotly 的原题，也不是本站事故。它提醒我们，评模型时不能只核答案有没有数字，还得核为什么这个数字值得人采取行动。Plotly 只给出 Carbon 的一个误报实例，两款模型在该组三题也都只答对两题；长期误报率或漏报率仍待同一套业务题的盲评。

93 秒对 23 秒：同一分数附近，等待改变了使用方式

Plotly 测的是每题从发送问题到拿到最终答案的端到端耗时中位数，包含模型执行的数据库查询。Carbon 是 93 秒，Argon 是 23 秒，约四倍；这是这套数据分析代理在这轮测试中的读数，不能解释成模型 API 通用首 token 延迟，也不能推定每个问题恰好都慢四倍。中位数不会告诉你最慢题拖了多久：Plotly 报告 Carbon 跑完整套题约 1 小时 48 分钟。在五道寻找隐藏规律的题里，Carbon 每题平均执行 41 次查询；这描述的是特定分组的 queries，不是所有题的模型调用次数。更充分的检索可能找到线索，却也让前台等待变长，必须回到具体交付物判断值不值。

前台交互需要一条等待契约。用户点击“分析本月收入”后，页面是持续显示过程，还是 90 秒无反馈才吐出一份报告？Plotly 在方法文中把约 20–30 秒视为前台分析的重要体验区间，这只是它的产品判断，不是行业 SLA。把 Carbon 的延时照搬为“我们的接口会等 93 秒”也不对；可先测自己同一批问题的端到端分布，再决定是否提供进度、允许取消、将长任务移到后台，以及失败后从哪一步恢复。夜间批量生成待审材料时，人不必守在屏幕前，较长等待可能可以接受，但早上必须能看到结果、来源和失败原因。

这里有一道比“哪个模型快”更实际的选择：任务能否分阶段交付？一个跨五张表核口径的分析，如果先交代选取的表、过滤条件和已发现的冲突，再补最终结论，审阅者可以提前发现查错方向；如果一次性输出，错误可能直到最后才暴露。分阶段交付也可能增加调用和账单，不能只凭构想认定划算。对于两个模型都能给出同样可复核结论的任务，额外等待没有带来交付收益；若较慢路径确实减少复查，则应把节省的人工时间与端到端等待一起计。这是测试设计，不是 Carbon 或 Argon 已验证的行为。

Google 的公开开放公告也把 Carbon 定位于特别困难的多步骤编程、调试与开放研究，同时认为多数软件工程和知识工作用 Argon 即可。那是厂商对用途的定位，不是等待和成功率的独立结论；Plotly 的结果给出一种更具体的提醒：在常规分析题已经接近满分时，把每一步都升级为长推理未必合算。

Carbon 等得更久，这轮账单为何反而更低

Plotly 的另一组数字有一点出乎直觉：Carbon 跑完整套 43 题花 11.55 美元，Argon 花 13.47 美元；前者每题中位等待更长，却在这一轮总账里更便宜。Carbon 在这轮读取约 2930 万输入 token，其中 88% 来自缓存。同一模型如果没有相同的复用输入，成本条件也随之改变。原文没有逐题公布 token、查询和缓存分布；不能把总费用除以 43，称作一份真实客户分析的市场均价，更不能把 Google 直连渠道的活动价当成 pirouter 已发布的 Carbon 计价。

假设团队希望比较“改用 Carbon 后，每周少改几份错误报告”，账单应该以一份被审阅者接受的交付为单位。记录同一任务的模型调用、缓存实际读取、失败重试、工具费用和审阅者修正时间；误报触发的数据排查也算进来。一次生成便宜，但多次回炉或让人花半小时核一个不存在的异常，就未必便宜。反过来，多等一会儿若真能减少这类返工，也会改变总成本。Plotly 的这一轮金额说明费用和等待不必同向，最终要靠自己的任务账本判定，而不是复制它的美元数。

财务榜首只领先 1.05 个百分点，Vals 自己说在误差内

第二份独立原测来自 Vals Finance Index 的原始榜单与方法。它把财务工作拆成三种实际交付：阅读公司披露材料、形成有依据的分析；在 Excel 里建立或编辑估值模型；回答需要引用法规依据的美国企业税务问题。一个团队如果主要核财务表格，会更在意建模分项；如果主要做税务研究，关心的则是错误引用与漏掉适用条款。Vals 用美国子行业 GDP 权重合成总指数，具体是前两项先取平均，再与税务项按 1.6 对 0.5 加权。这种权重适合描述该榜单设计，并不等于任一家企业的工作量分配。

截至榜单 2026 年 11 月 9 日的页面版本，Carbon 得 67.05%，Argon 66.00%；Carbon 名次第一。Vals 同页却说，前两名位于误差范围内。Carbon 模型评估页把其财务指数标为 67.05% ±1.43 个百分点；Argon 的对应误差数值没有在这张榜单中同列展示。这 1.05 个百分点可以把 Carbon 放进试点名单，不足以承诺团队改用后一定能多做对 1% 的财务工作。

分项更适合决定该测哪种任务。Vals 报告 Carbon 在 Tax Agent Bench 得 51.78%，位列该分项前列；财务研究与 Excel 建模两项的最高分属于别的模型。模型页的分项把 Carbon 的 Finance Agent v2.1 列为 67.16% ±2.02、Excel Modeling Benchmark v1.1 列为 76.47% ±2.21。一个关心表格模型的团队不应拿综合指数替代 Excel 分项，更不应把税务研究“超过半数通过”改写成“足以无审阅地出具税务意见”。Vals 的方法写明税务分项采用 all-pass Accuracy：按它的规则，答案要满足整项通过，而不是在多个局部要点中答对一部分便算通过。这比随手摘取一句看似正确的税法条文严，但也只针对其测试任务。把 51.78% 转成你所在地区某类税务咨询的成功率，没有依据。榜首可能只是值得列入候选，离自动放行还很远。

同一张 Vals 表还有 Cost / Test：Carbon 6.46 美元、Argon 6.53 美元，以及 Duration / Test：30 分 38 秒、22 分 41 秒。这里的费用几乎相同，但 Carbon 用时更长；如果财务分析员要在会议里即时回答问题，差距和隔夜研究底稿的意义不同。页面未细化 Test 的计量单位与各子项时间的汇总规则，只能在 Vals 这张表里看方向。Vals 模型页列默认 Google 提供方与 high 思考强度，并提醒部分评测可能用其他设置；11 月 9 日是榜单更新日，非实际测试日。

两份原测各能回答什么，哪一格不能互填

读者若要同时使用这两张成绩单，先把三个量纲并排摆好：

这张表的两列只允许各自在列内比较。要决定一个 BI 页面是否能让用户等到结果，Plotly 的单题耗时更贴近问题，但仍要在自己的代理里重测；要决定税务或 Excel 工作是否值得进试点，Vals 的任务分项比综合名次更贴近问题。如果把 Plotly 的 11.55 美元与 Vals 的 6.46 美元排成“哪个平台省钱”，或者把两边分数折算为统一准确率，缺掉的是同一任务、同一验收标准和同一计费单位。

还有一个不该抹平的区别：Plotly 把误报的样子写出来了，Vals 给出的财务综合分数没有告诉我们这个模型在你手头表格里会错报哪一列。前者能直接帮助设计核查字段；后者能帮助选出财务试点候选。两份材料并存，让选型问题更具体，而不是让“Carbon 平均领先”听上去更有把握。

下一轮真正要测的，是误报与等待怎样影响交付

已发的发布与接入篇列过一般试点要记录的型号、调用和回退。这一轮可以更窄：只挑两类最容易使选型翻转的任务——可能产生高代价误报的分析，以及必须有人在场等答案的查询。另外的日常整理任务若本来就能顺利验收，不必为了填满表格再跑一轮。

先处理误报。在历史资料中找已结案的真实数据缺陷，同时加入“看起来异常、其实符合业务规则”的正常记录，去掉能泄露答案或身份的字段。将两组材料交给同一套代理设置，唯一变动是 Carbon 与 Argon；请不知模型名称的审阅者逐条标注：发现是否成立、依据能否定位、是否需要人工继续查。每个模型各跑多次，保留失败和拒答，不能只把看上去精彩的答案留作展示。这是一份建议的验收设计，不是本站已收集的客户样本或测得的误报率。

在记录表里给“异常”增加两个独立结果栏：误报后的核查分钟数，以及漏报后续才发现的错误。例如一条正常数据被判异常，如果审阅者三分钟能驳回，与需要跨部门排查半天，虽然都是一次误报，业务代价截然不同。反过来，一项真正缺陷没有被指出，可能不会即时触发工单，但会进入下游分析。这些成本必须由团队在自己的任务里定义，不能拿 Plotly 的单个案例反推出发生频率。图上的 42/43 也不会告诉你审阅者最终签收了几份材料。

再处理等待。从用户真实会问的短查询里挑出必须当场返回的任务，用同样的数据和工具执行两条路径，记录每次从点击到最终答案的耗时分布：中位数以外，看最慢几题、超时、取消之后是否重复计费。试验时要约定计时起点和终点：用户送出问题到完整可用的答案，不是模型开始吐第一个字就停表。如果模型先给一段自然语言、随后又执行查询并修正数字，用户真正能采取行动的时刻在后面。记录放弃等待的请求是否仍生成结果、重复点击是否重复计费，也能防止“中位数还行”掩盖尾部问题。只有在实际产品里测到长等待，才把进度反馈、后台任务通知、结果页可恢复位置列入界面方案；它们是可能的工程应对，不是已由 Plotly 验证的架构。若用户愿意异步拿结果，允许后台处理；若医生、客服或分析员要在一通电话里回答，别用夜间任务的时限为实时体验辩护。

把两类验收结果对齐到同一张内部决策表：合格交付数、误报漏报及其核查成本、用户可接受的等待、全链路账单。Carbon 可能对少数复杂题有价值，也可能在近分任务里只增加等待；哪一种发生，需要同一业务样本的重复结果才知道。眼下两份原测足以说明值得测什么，还不足以替任何团队决定全部流量往哪儿走。