Gemini 4 Argon 的 100 万输出 token:一次百万级响应会给 API 架构带来什么

Gemini 4 Argon 的 100 万输出 token 是输出上限,不是上下文窗口。本文说明一次拉满的响应要花多少钱,以及流式、超时与配额限制该如何处理。

用 Apifox,节省研发团队的每一分钟

Gemini 4 Argon 的 100 万输出 token:一次百万级响应会给 API 架构带来什么

免费使用 Apifox

相关推荐

最新文章

API

一体化协作平台

API 设计

API 文档

API 调试

自动化测试

API Mock

API Hub

立即体验 Apifox
目录

Gemini 4 Argon 最醒目的数字 1M token 是它的输出上限,而不是上下文窗口。Google 表示单个 Argon 响应最长可达 100 万 token,约为此前 64K 上限的 16 倍,而且完全没有公布 Argon 的输入窗口。目前也还没有可调用的东西:Argon 今天只对 Fairwind Program 的防御者开放,等 Google 开放访问后才会轮到付费 API 客户(参见发布日期与访问指南)。

这么长的响应会打破大多数 API 技术栈依赖的三个假设:一次调用在几秒内结束、响应体能放进内存、一个请求的成本很小且可预测。本指南覆盖一次顶格响应的成本、流式传输、超时、输出上限、存储,以及在访问开放之前如何在 Apifox 中测试这一切。想了解模型概览,请看什么是 Gemini 4 Argon;想看请求形态,请看 Gemini 4 Argon API 指南。

1M 输出 token 不等于 1M 上下文窗口

不少在 Argon 上排名靠前的页面把 1M 这个数字说成上下文窗口,还有一个标题称其为“大 16 倍的上下文窗口”。这正好说反了。Google 的发布帖说的是它把“模型的输出 token 上限提升到业界领先的 1M token”。那个 64K 与 Gemini 3.1 Pro Preview 上 65,536 token 的输出上限一致,后者是 Google 上一代顶级 Pro 模型。

输入是另一个数字,Google 没有给出。它的长上下文评测记录在评测方法论中,使用了 256K 到 1M token 之间的 prompt。那只是一个基准测试子集,不是规格说明。输出侧也有一个注意事项:Vals AI 列出其测试的 Argon 配置最大输出为 262K。Google 说该模型的上限是 1M;至少有第三方评测者在其所使用的接口上看到了更低的上限。

模型 每次响应的最大输出 输入或上下文窗口
Gemini 4 Argon 1M(Google 声称的上限) 未公布
Gemini 3.1 Pro Preview 65,536 1,048,576
Gemini 3.8 Flash 65,536 1,048,576
GPT-6 Astra 128,000 1,050,000(最大输入 922K)
Claude Opus 5.5 128K(在 Batch 上使用 beta header 时为 300K) 1M

所有竞品都把同步输出上限设在 128K,所以 Argon 声称的上限约为它们的 8 倍。Google 给出的理由是推理深度:有了余量,模型可以“在单条轨迹中生成数十万 token”,并一次通过解决难题。关于其他厂商如何处理长任务,请看 Claude Opus 5.5 的 18 小时任务和 GPT-6 Astra API 指南。

一次顶格响应的成本

先算上限。输出在 Argon 优惠期内按每 1M token $10 计费,之后为 $20,所以一次满长度响应的成本为:

  • 优惠期:1,000,000 x $10/1M = $10.00 的输出
  • 标准价:1,000,000 x $20/1M = $20.00 的输出

输入费用另算。一个 200,000 token 的 prompt 在优惠期费率下增加 200,000 x $2/1M = $0.40,标准费率下为 $0.80,所以单次顶格调用为 $10.40 或 $20.80。一个每晚触发 100 次这类调用的任务,在优惠期费率下花费 $1,040。

思考让这一点更难看清。在当前的 Gemini 模型上,思考 token 按输出计费;Google 没有说明 Argon 是否遵循这一规则,也没有说明思考是否计入 1M 上限。无论哪种情况,一段很短的可见回答仍可能带来高额输出账单。Gemini 4 Argon 价格指南给出了更多场景,包括缓存输入 95% 折扣。

为什么流式传输是必需的

非流式调用在整个响应完成前不返回任何内容。在数十万 token 的量级上,那就是一条长时间静默的连接,整条链路里的空闲超时可能在第一个字节到达前就把它关掉。

改用流式。在 generateContent 上,把方法换成 :streamGenerateContent?alt=sse,Google 就会发送 server-sent events,每个事件一个部分的 candidates 块。事件到达时逐个读取并写出;不要先把响应体收集起来。这在今天可以跑在 Gemini 3.8 Flash 上,模型名放在变量里,因为 Google 尚未公布 Argon 的模型 ID(配置方法见我们的 Gemini 3.8 Flash API 指南):

import json, os, requests

MODEL = os.environ.get("GEMINI_MODEL", "gemini-3.8-flash")
URL = ("https://generativelanguage.googleapis.com/v1beta/models/"
       f"{MODEL}:streamGenerateContent?alt=sse")
body = {
    "contents": [{"parts": [{"text": "Write a test plan for every endpoint in a payments API."}]}],
    "generationConfig": {"maxOutputTokens": 60000},
}
usage = None
with requests.post(URL, json=body, stream=True, timeout=(10, 120),
                   headers={"x-goog-api-key": os.environ["GEMINI_API_KEY"]}) as r, \
        open("response.txt", "a", encoding="utf-8") as out:
    r.raise_for_status()
    for line in r.iter_lines(decode_unicode=True):
        if not line or not line.startswith("data:"):
            continue
        event = json.loads(line[5:])
        for cand in event.get("candidates", []):
            for part in cand.get("content", {}).get("parts", []):
                out.write(part.get("text", ""))
        out.flush()
        usage = event.get("usageMetadata", usage)
print(usage)

timeout=(10, 120) 设置了 10 秒的连接超时和 120 秒的读取超时。在 requests 中,读取超时是字节之间最长的间隔,而不是总时长,所以只要流持续发送,它可以一直运行。每个块到达时都会写入磁盘。在 3.8 Flash 上,每个事件都带有累积的 usageMetadata,所以最后一个事件给出最终的 token 计数,供你记录和计费。

每一跳的超时

你的客户端只是其中一跳。一条长流还会经过反向代理、API 网关、负载均衡器,可能还有 serverless 运行时,其中任何一个都可能提前结束响应:

环节 要检查什么 出错时的表现
HTTP 客户端 读超时或空闲超时,以及任何整请求超时 只在长回答时于流中途抛出异常
反向代理 读超时以及对 text/event-stream 的响应缓冲 事件成批到达,或者流被切断
API 网关 请求最长持续时间 每次运行都在相同的耗时处失败
负载均衡器 空闲超时 在首个事件之前的长时间停顿期间断连
Serverless 函数 最长执行时间 函数在模型仍在输出时就结束了

留意固定的截断点。如果长响应总是在相同的耗时处失败,说明某一跳存在流式传输无法绕过的硬性时长限制,这类工作就需要移出请求路径。

在后台运行长任务

对于最长的任务,把工作从活动连接上移开。Interactions API 通过 background=true 支持长时任务的后台执行。后台运行依赖已存储的 interaction:文档说 store=false 与后台执行不兼容,所以这些请求要保持存储开启。要获取已完成后台 interaction 的结果,请遵循 Google 的文档;不要猜测轮询接口。由于 Google 表示新模型会在 Interactions API 上发布,请按 Argon 的长任务在那里运行来规划。

有意识地限制输出

1M 上限是天花板,不是目标。在 generateContent 上,generationConfig.maxOutputTokens 限制每次响应;流式示例中设为 60,000。在 3.8 Flash 上,思考也计入该上限:我们的测试运行设为 2,000,返回了 1,340 个思考 token 和 656 个可见 token。对于 Interactions API,在依赖输出上限字段之前,请先在 Google 的文档中确认它。然后根据你每次调用可接受的成本来选择上限:

输出上限 最坏情况输出成本,标准价($20/1M) 优惠期($10/1M)
64,000 64,000 x $20/1M = $1.28 $0.64
128,000 $2.56 $1.28
500,000 $10.00 $5.00
1,000,000 $20.00 $10.00

达到上限的响应会提前停止,所以要把它视为不完整。检查最后一个事件的 finishReason:MAX_TOKENS 表示被上限截断。之后可以在后续轮次中继续,或者为这一个任务提高上限。

存储和解析超大输出而不做缓冲

一百万 token 意味着每次响应有几 MB 文本。有几条规则可以避免这拖垮工作进程:

  • 把块到达时逐个写入文件或分片对象上传,而不是在内存里拼成一个字符串。
  • 连接中断时保留部分文件。从头盲目重试会再次生成输出,也会再次产生费用。
  • 需要结构时请求 JSON Lines,这样每一行都能独立解析,而不必等一个巨大的文档闭合。
  • 记录 usageMetadata 和字节数,而不是完整的响应体。
  • 在 800K token 的回答打到你的数据库和队列之前,先检查它们的列限制和消息大小限制。

开放访问前在 Apifox 中测试

你可以在一个替身上把这一切先演练一遍,然后完成三项检查。

观察流。把 GEMINI_API_KEY 和 GEMINI_MODEL 作为环境变量,向 3.8 Flash 发送流式请求。Apifox 会解析 text/event-stream 响应,并在 Timeline 视图中随到随显示每个事件,这样你就能看到块大小、间隔和最终的 usageMetadata。

流式返回一个长得多的假响应。真实的 3.8 Flash 输出最多 65,536 token,所以运行一个本地 mock,用相同的事件形态流式返回多得多的内容:

# long_stream_mock.py: Gemini-shaped SSE for parser and timeout tests (fake data)
import json, time
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer

EVENTS, DELAY, CHUNK = 20000, 0.005, "lorem ipsum " * 40

class Handler(BaseHTTPRequestHandler):
    def do_POST(self):
        self.rfile.read(int(self.headers.get("Content-Length", 0)))
        self.send_response(200)
        self.send_header("Content-Type", "text/event-stream")
        self.end_headers()
        for i in range(EVENTS):
            event = {"candidates": [{"content": {"parts": [{"text": CHUNK}]}}]}
            if i == EVENTS - 1:  # fake counts sized like a near-max reply
                event["usageMetadata"] = {"promptTokenCount": 1200,
                    "candidatesTokenCount": 950000, "thoughtsTokenCount": 40000,
                    "totalTokenCount": 991200}
            self.wfile.write(f"data: {json.dumps(event)}\n\n".encode())
            self.wfile.flush()
            time.sleep(DELAY)

ThreadingHTTPServer(("127.0.0.1", 8787), Handler).serve_forever()

把一个“mock”环境的前置 URL 指向 http://127.0.0.1:8787,并通过它发送同样的流式请求。该流运行约两分钟(我们的测试中为 128 秒),传输 960 万个字符的文本,足以暴露会缓冲的解析器、会囤积事件的代理,或者设得过短的超时。

对 token 计数添加断言。在非流式的 generateContent 请求上,断言 candidatesTokenCount 加上 thoughtsTokenCount 在 usageMetadata 中不超过你的上限,并且按 Argon 价格计算出的成本低于你的成本天花板。Argon API 指南里有一个现成的成本脚本。

常见问题

1M 是 Gemini 4 Argon 的上下文窗口吗?不是。1M 是每次响应的输出上限,从 64K 提升而来。Google 尚未公布 Argon 的输入窗口。

一个 1M token 的 Argon 响应要多少钱?优惠期费率下输出为 $10,标准费率为 $20,另加输入费用。更多场景见 Gemini 4 Argon 价格指南。

我今天能生成 1M token 的响应吗?除非你的组织处在拥有 Argon 访问权限的 Fairwind 名单内,否则不行。Gemini 3.8 Flash 和 3.1 Pro Preview 的输出上限是 65,536 token,而 Vals AI 列出其测试的 Argon 配置最大输出为 262K。

长 Argon 响应必须用流式吗?Google 没有发布针对 Argon 的流式传输指南,但一次持续数分钟的非流式调用会暴露在你技术栈里的每一个空闲超时之下。请用流式,或者使用 Interactions API 的后台执行。

Argon 的输出上限与 GPT-6 Astra 和 Claude Opus 5.5 相比如何?两者都把同步输出上限设为 128K;Anthropic 在使用 beta header 时允许 Batch 上 300K。Argon 声称的 1M 约为其 8 倍。

下一步

现在就为你的 Gemini 客户端加上流式传输和输出上限,跑在 3.8 Flash 上,并用长 mock 流反复测试,直到技术栈里没有任何环节会把它截断。Argon 的 ID 发布后,改一下 GEMINI_MODEL,在 Apifox 中重跑同样的测试。


HiFox:将 Agent 变成真正的队友

另外,我们也在思考,AI 如何从个人提效走进团队协作。

HiFox 是一个让人和 AI Agent 在同一个工作现场协作的平台:你可以像给同事分派任务一样指派 Agent,在任务看板中跟踪进度、查看结果,让 Agent 成为团队里的队友。

👉 立即体验 HiFox:https://hifox.com

AI Coding 交流群

如果你也在用 AI 写代码,或者正在研究 Cursor、Claude Code 这些工具,
欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流,还有各种新工具和新玩法。

AI Coding 交流群