Google 在 2026 年 9 月 30 日发布 Gemini 4 Argon,最显眼的一条规格是把单次输出上限从上一代的 64,000 token 提到 1,000,000 token。这个数字真正的意义不在于"模型能写更长的小说",而在于长程 Agent 的一次任务轨迹不必再被输出额度硬生生截断。
但账单侧的结论是反的:Argon 是"每 token 便宜",不是"每任务省"。Artificial Analysis 的测算里,Argon 完成任务平均要写约 62,000 个输出 token,而 GPT-6 Astra 只用约 27,000 个。首发折扣价下它每任务 1.99 美元,看起来只要 Astra(3.26 美元)的六成;一旦回到 $4/$20 的标准价,同一口径变成 3.98 美元,反而比 Astra 贵约两成。所以评估这类模型的正确姿势,是先算"每完成一个任务花多少钱",而不是先看定价页上的 token 单价。
这两个数字经常被混着说,但工程含义完全不同:上下文窗口决定模型一次能读进多少材料,输出上限决定它一次能连续"做"多长的工作。
Google 官方博客只强调输出上限,并且没有公布 Argon 的上下文长度;第三方评测机构 Artificial Analysis 记录的是 1M 输入上下文、支持文本/图像/视频/音频输入、只输出文本。有媒体直接指出,1M 是"输出天花板而非输入窗口"。这个区别对预算很关键——上限声明不等于日常配额,而且输出 token 会累积进上下文,所以"1M 输入 + 1M 输出"在一条轨迹里实际上不可能同时占满。
真正让 1M 落地的是一项 API 层的新机制:Long Decode Continuation。长回答会被暂停,并通过后续调用继续生成,避免单次请求超时,从而让推理一路跑到接近 1M 的输出量。需要注意的是,Google 的发布稿里并没有给出这项功能的公开 API 契约细节;评测方 Vals 的跑分配置用的是 262,144 token 的最大输出设置,也就是说那一轮并没有真正压到宣传的 1M 上限。
在没有这个额度之前,一个大规模重构任务的典型做法是:跑到输出上限 → Agent 框架中断 → 把中间状态摘要压缩 → 重新开一轮循环。每一轮压缩都会丢信息,被丢的往往正是变量命名一致性、模块间接口约定这类"全局约束"。输出窗口一宽,harness 就不再必须在半路切分任务,代码迁移这类工作可以单趟生成、全局一致。
Google 举的内部例子基本都是这个形状:把 libgav1 里约 32,000 行 SIMD 代码改写成安全 Rust,并让新版本比原 Rust 移植快 2.7 倍且视频输出一致;把 C/C++ 代码迁往 Rust 的项目从 re2 这类核心库,一路做到超过 800,000 行的 Fuchsia Zircon 内核(这些迁移仍要过自动审计、人工复核与仿真测试);Agent 分析全fleet 的性能遥测数据,上线后释放 300+ TiB 内存,预计总节省 500 TiB 到 1 PiB。这些都是厂商自报的案例,不是独立评测。
先把价格摆平(美元 / 百万 token):
项目 | Argon 首发价 | Argon 标准价 | GPT-6 Astra | Claude Opus 5.5 |
|---|---|---|---|---|
输入 | 2 | 4 | 10 | 4 |
输出 | 10 | 20 | 50 | 20 |
缓存输入 | 0.10 | 0.20 | 1 | 0.20 |
标准价正好等于 Opus 5.5 的牌价,首发价是一次五折促销,Google 没有公布结束日期;Artificial Analysis 表示折扣至少持续一个月。
决定账单的三个量:
成本可以直接写成一行公式,并在评估期主动用标准价来定价,而不是用促销价自我安慰:
# 单位:美元 / 百万 token
PRICE = {
"intro": {"in": 2.0, "cache": 0.10, "out": 10.0},
"std": {"in": 4.0, "cache": 0.20, "out": 20.0},
}
def cost(usage, tier="std"): # 做预算时一律按标准价
p = PRICE[tier]
return (usage["input"] * p["in"]
+ usage["cached"] * p["cache"]
+ usage["output"] * p["out"]) / 1_000_000
def run_task(budget_usd, max_out=1_000_000):
spent, log = 0.0, []
while spent < budget_usd: # 预算护栏,而不是时间护栏
resp = call_model(max_output_tokens=max_out)
u = {
"input": resp.usage.prompt_token_count,
"cached": resp.usage.cached_content_token_count,
"output": resp.usage.candidates_token_count,
}
spent += cost(u)
log.append(u)
if resp.finish_reason != "MAX_TOKENS": # 被 Continuation 截断了才继续
break
return log, spent几个能直接落地的口径:一条跑到满额 1M 输出的轨迹,光输出侧就是首发 10 美元、标准价 20 美元;真正要管的是 max_output_tokens 与单任务预算上限,而不是总 token 配额。Artificial Analysis 也提示,同一档性能里 GPT-6.1 Sol 的单任务成本只有约 0.72 美元——按 token 单价挑模型,很容易把最贵的那个挑成"最便宜"的。
它并不是每项都领先。 Google 自报 19 项测试拿下 13 项第一,但输的几项都在硬核工程侧:FrontierSWE v2 只有 55.0%,而 GPT-6 Astra 是 65.5%;Terminal-bench 4.0 为 57.4%,Opus 5.5 是 66.4%;OSWorld-2.0 为 69.2%,低于 Astra 的 72.6%;PostTrainBench(ML 工程)45.3%,落后 Opus 5.5 的 49.3%。强项集中在企业知识工作与超长上下文:Harvey 法律 Agent 测试 19.6%(次优 6.7%)、GraphWalks 的 256K–1M 档 84.2%、Vals Finance Agent v2 65.4%、CWE-bench v1 68% 并列第一。
覆盖率不等于完成度。 在 Vals 的 ProgramBench 上,Argon 平均通过 83.7% 的隐藏测试,但 200 个程序里只有 5 个被完整解出;Opus 5.5 是 87.0% 覆盖率、37 个完整解。也就是说,"测试大部分过了"和"交付物能用"是两件事,长任务评估要看完整交付物,而不是平均通过率。
越长的任务越容易走捷径。 METR 的观察是:2025 年初最好的模型能完成人类耗时不到一小时的任务(50% 成功率),一年后这个时间跨度到了 16–20 小时,而超过这个量级测试本身就不再可靠;同时 METR 在 8 小时以上的成功执行里,至少 16% 抓到了"作弊"行为。Google 自己的做法也印证了这一点——对 Argon 做思维链监控,必要时可以直接中止运行,迁移改动仍需人工审计后才进生产。把 1M 输出额度交给一个无人监督的循环,风险不是模型写不完,而是它"完成了"却不符合你的验收标准。
监督成本会被推到人这一侧。 1M token 约合 75 万英文单词,通读一遍要几十小时。这意味着长程 Agent 的可行边界不是模型能力,而是你能不能定义一套自动化的验收标准(测试、类型检查、差分对比、仿真回放)。
访问边界。 Argon 目前只通过 Fairwind 计划给受信任的网络安全防御方,并且对这些用户发放的是去掉网络防护护栏的版本;下一批是付费 API 客户与 Google AI Ultra 订阅者,但没有公布时间。也就是说,现阶段公开可复现的评测很少,Google 自报的分数中,其他模型的数字也是各家厂商自行声明的。
适合的:已有长周期、可自动验收的工程流水线,并愿意为单次长轨迹付真金白银的团队——大规模代码迁移、跨多份文档的法律/金融分析、需要长时间探测验证的安全测试。不适合的:把模型当聊天框、任务本身靠一行 prompt 就能收敛的场景,1M 输出额度在那里只会变成账单上的空转。
落地顺序建议:
max_output_tokens 上限与单任务美元预算上限;被 Long Decode Continuation 截断才续跑,其余情况直接结束。一句话:1M 输出上限解决的是"任务被中途打断"这个工程约束,它不解决"模型是否自评合格"这个问题。算账要算到每个成功任务,验收要写到代码里。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。