Gemini 4 Carbon 对比 Grok 4.7：价目表上写着 3 倍，账单上却只字未提

Gemini 4 Carbon 的标价是每百万输出 token 10 美元。Grok 4.7 的标价是 6 美元。在每个定价页面都用粗体标出的这两个数字上，Carbon 的“说话”成本高出三分之二，“阅读”成本则是两倍，而显而易见的结论是 Grok 4.7 才是性价比之选。然后你衡量完成一项任务需要多少成本，结果两个模型只差一美分：在 Artificial Analysis 的 Intelligence Index 上，Gemini 4 Carbon 为 7.76 美元，Grok 4.7 为 7.77 美元。账单相同，二者能力却相差二十五个指数点。这就是本次对比的全部论点，而这是任何一家的价目表都无法向你展示的。

时间点很重要，它会影响你如何理解其余内容。Gemini 4 Carbon 于 2026 年 11 月 10 日在付费 Gemini API 上开放调用，此时距 Google 向一个封闭群体宣布它还只有十二天。Grok 4.7 由 xAI 于 2026 年 9 月 21 日发布，此后一直可供路由调用。一个在公众手中才一周；另一个背后已有七周的生产使用经验。

两张看似差距悬殊、实则不然的费率卡

从原始结构开始，因为分层正是两者在实践中产生分歧的地方。

• 输出价格 — Carbon 每百万 $10，直至 2026年11月30日，之后为 $20。Grok 4.7 在输入 token 少于 200,000 时为每百万 $6，之后为 $12。

• 输入价格——Carbon 为 2 美元，12 月 1 日起为 4 美元。Grok 4.7 为 2 美元，超过 200k 阈值后升至 4 美元。结构相同，数字相同，只是附加的日期不同。

• 缓存输入 — Carbon 现为每百万 $0.10，12 月 1 日起为 $0.20，仅支持隐式缓存。Grok 4.7 为 $0.50，长提示词时升至 $1.00，新费率可享 75% 折扣。

• 上下文 — Carbon 1,048,576 个 token。Grok 4.7 为 500,000 个 token。Carbon 的窗口更大，是其两倍。

• 输出上限 — Carbon 同步输出 65,536 个 token，使用长解码时最高可达 1,048,576。Grok 4.7 最高可达 450,000。实际使用中，Grok 单次调用写出的回答比 Carbon 默认情况下更长。

• 输入模态 — Carbon 接受文本、图像、音频、视频和 PDF。Grok 4.7 接受文本、图像和文件。

• 模型权重——两者均为闭源。二者都无法自托管，因此都承担相同的供应商风险敞口。

• 推理强度——Carbon thinking 分为低、中、高；Grok 4.7 分为低、高和 xhigh。公布的数据分别取自 high 和 xhigh 档，这是在照搬任何头条分数之前首先要检查的一点。

那份列表中的两处不对称确实有实际意义。Carbon 的 1M 上下文是 Grok 的两倍，这对整仓库或多文档工作是重要因素。Grok 的 450K 输出上限是 Carbon 同步上限的七倍，如果交付物本身就很长，这一点就很重要——例如生成的报告、迁移后的文件、长补丁系列。一个模型能容纳一百万 token 的输入，却只能写回 65K，那么无论规格表上的上下文窗口看起来如何，它都不是长输出模型。

使两个价格一致的那个数字

Artificial Analysis 在同一个九项评估指数（版本 v5.0.1）上衡量这两个模型，并公布每项指数任务的成本，其中计入了每个模型实际完成工作所消耗的 token 数量。正是这一衡量方式，使得本次比较的结果与价目表所暗示的不同。

• 智能指数——Gemini 4 Carbon 60 在高努力设置下得 60 分，在 74 个中排名第四。Grok 4.7 35 在 xhigh 下得 35 分，在 74 个中排名第四十一。Carbon 的中等和低设置得分分别为 58 和 54；Grok 的高和低设置分别落在 35 和 31。

• 每个索引任务的成本——Carbon 为 7.76 美元，Grok 为 7.77 美元。仅相差一美分，且对更昂贵的模型有利。

• 该指数上的输出 token 数——Carbon 为 2.05 亿，Grok 为 1.48 亿，而中位数为 7280 万。

• 每个索引任务的耗时——Carbon 25.6 分钟，Grok 25.9 分钟。再次持平。

• 输出速度——Carbon 每秒 80 个 token，Grok 每秒 67 个 token。尽管 Carbon 更昂贵，但它是更快的生成器。

• 首个回答 token 用时——Carbon 66.85 秒，Grok 53.64 秒。两者都远超出其价格档位 12 秒的中位数，而且 Grok 是两者中更快开始输出的。

调和之处在于冗长，而非折扣。Carbon 每项任务产生的输出 token 比 Grok 多 39%，其输出价格也高出 67%，但每项任务的总成本却相差不到一美分，因为 Grok 的 token 价格并不是账单的唯一输入——输入量、推理 token 以及每项任务的形态都有影响。无论具体如何拆解，实用的解读都应是任何重新推导后依然成立的那一个：对这两个模型做逐 token 比较，几乎无法说明某项工作负载的成本；而两家厂商的标价差异，比它们实测的每结果成本差异更大。

二十五分并非在任何地方都是二十五分

这种规模的复合差距通常经得起分解；问题在于它在哪些地方成立、在哪些地方不成立。在任何人按 60 对 35 做预算之前，先说明三点注意事项。

首先是努力程度。Carbon 的 60 是在高努力程度下取得的，Grok 的 35 是在 xhigh 下取得的。两者都是厂商偏好的设置，而不是相互匹配的设置，因此比较的是各模型按其制造商意图运行的情况，而不是在同等算力下进行比较。把任一方调低，差距就会缩小或扩大，具体取决于你调整的是哪一端：Carbon 在低努力程度下为 54，Grok 在低努力程度下为 31。

第二点是，v5.0.1 指数由九项评估混合而成，而榜单并未公布任一模型在各基准上的分数——两个页面上的每张子图都写着“没有公开可用的 API”。因此，诚实的说法是：Carbon 在综合评分上以 25 分优势胜出，而目前除 Artificial Analysis 之外，没有人能说清这九项评估中究竟是哪一项造成了这一差距。任何发布这对模型逐基准细分的人，要么是在引用厂商，要么是在编造。

第三点是，这个指数只是一种工具。它是个好工具，最近刚修订过，并且被一致地应用于两个模型，但它不是产品决策。一个在综合得分上少 25 分的模型，仍然可能赢下你手头的任务，而接下来两节讲的就是它确实能做到的情形。

Grok 4.7 完胜之处

其中三个，而且第一个不是基准。

成熟度。 Grok 4.7 已正式全面可用七周。Gemini 4 Carbon 在一场两周内两次变形的发布之后，才刚可调用一天——10 月 28 日发布受限公告，11 月 10 日推出付费 API，12 月 1 日价格翻倍。一个需要模型在下一季度仍是同一款产品的团队，此时此刻在这两者中，恰好只有一个选项拥有可靠往绩。

单次调用的长输出。 450,000 个 token，而同步模式下为 65,536 个。如果任务是“写出整个文件”而不是“回答问题”，那么上限会先于索引决定这一点。

如果输入较小，长提示词的成本确定性。 Grok 迈向 $4/$12 的这一步仅在输入超过 200,000 个 token 时才生效；在该线以下，其 $6 的输出费率是 Carbon 12 月后 $20 的三分之一。对于输入适中、输出繁重的工作负载——摘要、起草、转换——这笔账确实有利于 Grok，而每个索引任务近乎相同的成本只是关于那个特定九项评估组合的说法，并非普遍规律。

相比之下，Grok 的缓存输入价格为每百万 $0.50，是 Carbon 当前每百万 $0.10 的五倍。对于每次调用都会重新发送同一份 100,000 token 语料的 RAG 流水线来说，仅这一项就可能超过上面提到的所有因素。这正是团队在这两个模型中选错的最常见方式：他们只比较输出费率，却从不根据自身流量形态计算缓存经济性。

Carbon 在哪里物有所值

支持 Carbon 的理由，比其指数评分所反映的要更有限，但比其价格所暗示的要更充分。

多模态输入。音频和视频输入是这整个对比中最清晰的分界线。Carbon 两者都能接收；Grok 4.7 则两者都未列出。对于需要观看屏幕录制，或对通话内容进行转写并推理的流水线来说，这里只有一个候选方案，再多指数分也无法弥补这一差距。

网络安全与漏洞相关工作。谷歌为此构建了 Carbon，将首个版本仅限网络防御者使用，并报告称 SEC-bench Pro 达 88.2%、ExploitGym 达 54.8%、CWE-bench 达 71.0%——这些均为厂商报告且未经复现，但该方向与该模型所声明的用途一致，也与谷歌选择先向防御者而非开发者发布它这一事实一致。xAI 未对 Grok 4.7 提出可比的网络安全主张。

全仓库上下文。1M 窗口对 500K。两倍的上限对于 monorepo 规模的任务来说是实打实的差异，而对于“将整个服务保持在上下文中并跨其进行推理”这一特定场景，Grok 无法做到。

还有一个需要诚实看待的制衡因素：Carbon 的优势是以延迟为代价换来的。首个 token 需要 66.85 秒，每个索引任务需要 25.6 分钟，因此如果不具备极大的耐心，它并不适合放在请求-响应接口之后。Grok 也是如此，首个 token 需要 53.64 秒。如果你的产品需要 10 秒以内的响应，那么这场比较中的两个模型都会落败，答案是在任何一方选择更小、更快的模型。

同时运行两者，哪个才是真正的答案

这场对比之所以难以下定论，是因为这两个模型是为同一条流水线的不同阶段而设计的。Carbon 适用于输入端——在那里，模态与上下文占主导，且数据量较小。Grok 适用于长输出端——那里的任务是基于有限的提示生成大量文本，而每百万输出 token 6 美元的价格胜过了 20 美元的价格。大多数需要其中之一的团队实际上两者都需要，而错误在于为了同时获得两者，却签下了两份合同、两套 SDK 和两个计费关系。

一个 OpenAI 兼容端点就是捷径，而且对于这对组合中可路由的那一半，它今天已经可用：grok/grok-4.7 位于 OrcaRouter 上，采用 xAI 自己的 $2/$6 价格——同样的标价，以 0% 加价直接传递，包括超过 200,000 个输入 token 后的 $4/$12 阶梯价——同时还有 google/gemini-4-argon，价格为 $2/$10，用于 Gemini 侧那些不需要 Carbon 模态集的工作。Gemini 4 Carbon 本身不在目录中；它通过 Google 的付费 API 访问，而流水线的这一环是直接集成。

路由 DSL 正是让这种拆分从愿景变为可落地的关键：同一个请求可以组合为先走低成本路径，并在验证失败时升级，同时借助 自动故障转移 应对某个提供商性能下降。这一点在这里比平常更重要，因为这对组合中的昂贵模型在十四天内已经两次更改其访问条款。一条无需重新部署就能把分支迁移到不同模型的流水线，才是这种架构中唯一能经受住其自身供应商路线图变化的版本。

根据你实际面临的约束来选择

• 如果交付物是由受限提示词生成的长输出——Grok 4.7，请先检查你的缓存容量。

• 如果输入包含音频、视频或扫描版 PDF——选择 Carbon，因为在这一组合中没有其他替代方案。

• 如果任务是安全分析或漏洞分类——Carbon，凭借谷歌报告的网络数据以及公司自身的准入选择，但需注意这些数字均未经过独立复现。

• 如果你需要把整个仓库放进上下文——Carbon 的 1M 窗口，接受随之而来的延迟。

• 如果你需要一个下个月条款不会改变的模型——Grok 4.7，而这比听起来更有说服力。

• 如果你无法决定——就两个都运行。每项任务的实测成本不到一美分，因此为期两周的对比测试成本大约相当于一个模型的成本，而且它给出的答案比任何综合评分都更好。

这些列表都无法告诉你哪个模型更聪明，因为在这个层面上，“更聪明”是错误的衡量标准。正确测量时，25个指数点是一个很大的差距，但它仍然让纸面上更便宜的模型在每次结果成本上持平，并在输出上限、成熟度和首个 token 时间上领先。这并不是基准测试中的矛盾。而是当两个模型为不同任务而构建、却用同一个词来营销时会发生的情况。