※ 引述《Yokot0813 (yokot0813)》之铭言：
: https://i.mopix.cc/Fr1y2x.jpg
: 顺便问一下，这个推出的用量限制是什么
: 是将之前的使用频率给数据具体化吗
: 还是他在使用限制上面有进行更改
: 就是每段时间能使用的对话次数相比上个版本总体是增加还是减少
跟杰纳麦问一轮了，整理以下回复就不用烧各位的token
Gemini 3.1 Pro 与 Gemini 3.5 Flash 在计算使用者可用额度（Token 消耗量）时，遵
循相同的底层计量逻辑，但在计价费率以及特定功能的消耗结构上有所不同。
以下为计费与消耗方式的完整解析：
一、 Token 消耗量基本计算公式
不论使用哪一个模型，单次对话的总消耗量计算公式如下：
总消耗量 = 输入 Token 数 (Input) + 思考 Token 数 (Thinking) + 输出 Token 数
(Output)
基本换算率： 对于 Gemini 模型而言，1 个 Token 约等于 4 个中文字符或 1 个英文字
词（中文因编码关系，Token 消耗密度通常高于英文）。
2026 最新计费与级距差异（以每百万 Token 为单位）
Gemini 3.5 Flash：
标准费率：输入约 0.50$ 美元 / 1M tokens；输出约 3.00$ 美元 / 1M tokens。
注：Flash 模型通常不设长上下文惩罚级距，极具成本优势。
Gemini 3.1 Pro（设有“20 万 Token”的定价悬崖）：
标准模式（≦20万 tokens）：输入 2.00$ 美元 / 1M tokens；输出 12.00$ 美元
/ 1M tokens。
长上下文模式（>20万 tokens）：一旦对话历史或输入文件总量超过 20 万 Token，
整笔请求（包含输出）直接翻倍调整为：输入 4.00$ 美元 / 1M tokens；输出
18.00$ 美元 / 1M tokens。
二、 哪些行为与设定会“增加”消耗量？
1. 历史对话累积（Multi-turn Chat）
Gemini 属于无状态（Stateless）架构。在同一个聊天视窗中，每一次您送出新问题，系
统都必须将过去所有的对话纪录（您说的话 + 模型的回答）全部打包，当作“新输入”
重新传送给模型。因此，对话轮次越多，单次点击发送所消耗的输入 Token 将呈线性甚
至指数型暴增。
2. 开启“深度思考模式”（Deep Think / Reasoning）
这是 Gemini 3.1 Pro（或 Flash 的思考扩充模式）的核心消耗来源。
当面对复杂技术规格或量化计算时，模型在输出最终答案前，会在后台进行自主推理（产
生 thoughts_token_count）。
这些隐藏的思考 Token 完全视同“输出 Token”计费（Pro 费率为每百万 12$ 至
18$ 美元）。在复杂任务中，思考 Token 的消耗量有时会比最终答案多出数倍。
3. 多模态档案输入（Multimodal Inputs）
非文字档案会转换为高额的固定 Token 计算：
图片：分辨率在 $384 \times 384$ 像素以下，每张固定计为 258 tokens；超过此解析
度会被切格（Tiles）处理，消耗量倍增。
音讯：每秒固定消耗 32 tokens。
影片：每秒固定消耗 263 tokens（上传一部 1 分钟的工程或系统操作影片，将直接消耗
约 15,780 tokens 作为输入基础）。
4. System Instructions（系统指令）与 Tools（外挂工具）
如果您在 API 或进阶设定中加入了冗长的系统提示词（System Prompt），或是启动了搜
寻扩张（Google Search Grounding）等外挂工具，这些设定的描述文字在每一次对话中
都会被算进输入 Token 里。
三、 哪些行为与设定“不会增加”或能“减少”消耗量？
1. 呼叫 Token 计数器（Count Tokens API）
在正式发送文字给模型前，使用呼叫 count_tokens 函数来检查当前字数或档案会消耗多
少 Token。这项检查行为本身是完全免费的（上限为每分钟 3000 次请求）。
2. 善用“快取机制”（Context Caching）
这是高频率、大文本对话中最关键的省钱杠杆。当您需要连续针对同一份庞大资料（如资
产整合总表、NAS 说明书或整段代码库）进行提问时，Gemini 提供两种快取机制：
自动隐含快取（Implicit Caching）：Gemini 3.5 Flash 默认开启（门槛为输入达
1,024 tokens）；Gemini 3.1 Pro 默认在输入达 4,096 tokens 时触发。系统若在短时
间内侦测到相同的输入开头（Prefix），会自动命中快取。
显示快取（Explicit Caching）：手动指定快取，提供高达 75% 至 90% 的输入 Token
费用折扣。
注意：快取读取非常便宜，但会产生少许的快取写入费与每小时微量的储存空间费。
3. 调低限制参数 max_output_tokens
在模型设定中限制最大输出 Token。这不会减少您的输入消耗，但可以强制阻断模型吐出
过于冗长、口水话的回答，从而精准锁定并控制输出端的额度消耗。
四、 总结与操作建议
针对您的日常与专业工作情境，建议透过以下方式优化额度：
长对话适时断舍离：进行技术咨询或代码除错时，若该阶段目的已达成，建议开新视窗对
话，避免几十轮前的旧纪录持续拉高每次提问的输入成本（特别是避免将 3.1 Pro 逼入
过 20 万 Token 的高价级距）。
控制推理预算：在不需要极致逻辑的日常对话（如行程规划、故事查询）中，关闭或调低
思考权重，改用 Gemini 3.5 Flash 回应，即可免除庞大后台推理 Token 的开销。
已归属入笔记本内的对话、进入Notebooklm内的对话、在Notebooklm加入并勾选多种来源
资料三种操作情境对 Token 消耗量 的影响，必须分为 Gemini 平台原生功能（如 Gemini
进阶版中的笔记本对话栏）与 NotebookLM 独立平台 来进行解析。两者的底层架构不同
，计量机制也有很大的差异。
以下为您详细说明这三种情境对 Token 消耗的具体影响：
1. 已归属入笔记本（Gemini 接口）内的对话
如果您使用的是 Gemini 网页版接口中的笔记本（Gem）对话栏功能，将对话归属或储存
在特定的笔记本中：
会额外消耗 Token 吗？：会（但在特定条件下）。
影响机制： * 无状态打包重新输入： 当您在该笔记本视窗进行多轮对话时，Gemini 每
一次接收新问题，都必须将该视窗内过去所有的对话纪录（您说过的话与 AI 的回复），
以及该笔记本背后设定的系统提示词（System Instructions）全部重新打包，算作“新
输入的 Token”传送给模型。
快取减免机制： 所幸，不论是 Gemini 3.5 Flash 还是 3.1 Pro，在该视窗对话文本累
积到一定长度（Flash 默认 1,024 tokens；Pro 默认 4,096 tokens）时，会触发自动隐
含快取（Context Caching）。这时，已被快取的旧对话在后续提问时，输入 Token 的计
费会获得显著的折扣（通常省下 75% 以上），但整体计算的 Token 基数依然会随对话拉
长而持续增加。
2. 进入 NotebookLM 平台内的对话
如果您是将资料移至 Google 独立的 NotebookLM 平台（或在该接口的对话栏与 AI 互动
）：
会额外消耗 Token 吗？：在官方标准使用下“不影响您的个人帐户配额”。
影响机制： * 平台服务性质： NotebookLM 目前是 Google 推出的个人化研究助理平台
。虽然它的底层是调用 Gemini 旗舰模型，但其计费与额度消耗与您个人的 Gemini API
帐户或 Gemini Advanced 订阅配额是完全分开且独立的。
官方内置限制： 在 NotebookLM 中，系统改以“每个笔记本的来源数量（上限 50 个）
”、“每个来源字数（上限 50 万字）”来实施硬性限制，而非即时扣除您的个人
Token 额度。因此，在这个视窗内聊天，不会额外消耗您个人帐户的可用 Token 额度。
3. 在 NotebookLM 加入并勾选多种来源资料后的对话
这是在 NotebookLM 中最核心的操作。当您上传了多份文件（如 PDF、Google 试算表、
网页网址等），并在左侧面板全部勾选，然后在右侧对话框提问：
对底层算力/Token 基础的影响：会面临爆发性的 Token 运算（但由平台承担）。
技术运作机制：
大文本全量加载： NotebookLM 的核心设计理念是“资料溯源（Grounding）”。当您勾
选了多个来源，每一次在对话框输入新问题时，系统为了保证不产生幻想，底层会把所有
被勾选文件的全部文字内容，直接塞进 Gemini 模型的超长上下文窗口（Context Window
）中作为背景资料。
Token 暴增： 举例来说，如果您勾选了 5 份各 1 万字的技术说明书，每一次提问，模
型的输入端（Input）就自带至少 5 万字（约 7 万个 Token）的基础消耗。对话轮次越
多，消耗量会呈几何级数上升。
结论： 虽然此操作在技术上会消耗极其庞大的底层 Token，但由于目前 NotebookLM 平
台的运作机制，这笔庞大的 Token 消耗是由 Google 平台端吸收，目前不会向使用者的
个人 Gemini 帐户扣除或计费。
Gemini 3.1 / 3.5 系列模型与思考模式 Token 耗用比例分析
针对同一个提问对话（Same Query），Gemini 3.1 Flash-Lite、3.5 Flash 与 3.1 Pro
在 Token 上的耗用并非完全固定，而是由输入与基础输出 Token、隐藏思考 Token（
Thinking Tokens）以及代理工作流交互轮数（Agentic Turns）三大变量共同决定。
以下为依据 2026 年 5 月最新释出之官方技术文件与第三方权威评测机构（Artificial
Analysis）实测数据所整理的 Token 耗用比例与对照分析：
一、 基础对话 Token 消耗（输入与可见输出）
输入 Token（Input Tokens）：对于完全相同的提问内容，三款模型所转换的输入
Token 数完全一致。在 Gemini 编码架构中，1 个 Token 大约等同于 4 个字符或 0.6
至 0.8 个英文单字。
可见输出 Token（Visible Output Tokens）：在未触发深度推论的常规直答情境下，三
款模型生成的最终可见文字长度与 Token 消耗量差异并不明显，通常落在数百个 Token
内。
二、 思考程度（Thinking / Effort Level）引发的隐藏 Token 消耗比例
当模型开启“思考模式（Thinking Mode）”时，系统在生成最终可见答案前，会在底层
生成大量的“隐藏思考 Token（Thinking Tokens）”，这部分会等同于输出 Token 进行
计费。依据不同的思考预算等级（Thinking Level / Effort Level），单次对话
的 Token 激增比例如下：
低程度思考（LOW / minimal / low）：模型仅进行表面逻辑梳理。单次请求产生的思考
Token 通常控制在 200 至 500 个。相较于最高等级，能节省 80% 以上的输出 Token
消耗。
中程度思考（MEDIUM / medium，此为 3.5 Flash 的默认值）：平衡型推论。单次请求会
产生约 1,000 至 3,000 个 思考 Token，相较于最高等级可节省约 50% 的 Token 成本
。
高程度思考（HIGH / high，即 Deep Think 模式）：激发完整推论链（Deep Think Mini
）。单次请求会狂热消耗 5,000 至 20,000+ 个 隐藏思考 Token。在此模式下，隐藏的
思考 Token 往往占据整趟对话输出总额的 95% 以上。
三、 综合基准任务（如 Intelligence Index）的总 Token 累积消耗比例
在实际处理复杂的多步骤任务（如程式开发、代理自动化工作流）时，模型会因为“自主
拆解步骤与反复呼叫工具（Agentic Turns）”的次数不同，导致输入 Token 因脉络叠加
而产生滚雪球式暴增。
在相同基准测试下，整体的总 Token 消耗与费用折算比例（以轻量模型 3.1 Flash-Lite 为基底 1x）表现如下：
Gemini 3.1 Flash-Lite * 总耗用比例：1x（基准费用约 $93.60）
特点：最经济实惠，无多余的深度思考与工具呼叫循环，仅消耗最基础的输入与输出
Token。
Gemini 3 Flash (Reasoning)
总耗用比例：约 3x（基准费用约 $278.26）
特点：引入基础推论机制，Token 消耗量随思考深度温和增长。
Gemini 3.1 Pro
总耗用比例：约 9.5x（基准费用约 $892.28
特点：属于正统深度推理模型，其逻辑缜密，平均完成一个复杂任务仅需 23 轮（Turns
） 交互即可收敛，虽然单价较高，但 Token 总增长在复杂任务中相对受控。
Gemini 3.5 Flash (High Effort)
总耗用比例：约 16.5x（基准费用约 $1,551.60）
特点：为 2026 年 5 月发布的最新速度与智慧前沿模型。虽然其单个 Token 的定价
低于 3.1 Pro，但在实际执行复杂代理任务时，它倾向于进行极其激进的自主拆解，平均
单个任务需要高达 49 轮（Turns） 的工具呼叫与交互。这种高度代理化（Agentic
）的特性导致其输入 Token 被极高频率地重复读取与叠加，最终其总 Token 消耗量与运
作总成本反超了 Gemini 3.1 Pro 约 75%。
总结对照推估
常规单纯问答：进行简单的翻译、分类或单纯问答，将思考等级设为 LOW，三者 Token
总耗用比例约为 3.1 Flash-Lite (1x) : 3.5 Flash (1.2x) : 3.1 Pro (1.5x) [2, 3]
。
复杂代理/程式任务：执行复杂的 Agent 代理或程式除错任务且给予 HIGH 思考额度时，
由于 3.5 Flash 会自发产生双倍于 3.1 Pro 的交互轮数，其总 Token 耗用推估比例会
反转为 3.1 Flash-Lite (1x) : 3.1 Pro (9.5x) : 3.5 Flash (16.5x) [4, 5]。

推个

用gpt就好了

：0

可以丢掉这个AI了，光看前面几段就一堆错误，首先gemini老早就换token算法了，不是4:1，再来3.5的费率差超多，他查到3 flash版本去了，新版贵三倍，照他的建议你会破产。

gemini:嘘 楼上不要说

忽然觉得Deepseek香多了

有没有开新对话 它都会一直提旧内容啊

总之我期待真正的雌小鬼AI可以被玩出来 我目前的AI像癫婆

GPT好用太多 又有codex两边还分开流量

现在随便就会吃光token我已经退订了，还有3.5Flash超反

共？

现在问ai东西不用查证就可以到处贴？

你都要问ai了为什么不再用一次ai精简内容

意思是叫这个AI算自己的token费率都会算错吗 笑死