Skip to Content

07b - 百万 Token 上下文实战

本文是《AI Agent 实战手册》第 7 章第 2 节。 上一节:Gemini 模型家族能力概览 | 下一节:多模态能力实战

概述

从 Gemini 2.5 Pro 到 3.1 Pro,Google 始终保持着 100 万 token 的上下文窗口——这是当前主流模型中最大且最稳定的可用上下文。100 万 token 约等于 5 万行代码、75 万字中文、1,500 页 PDF 或 3 小时视频。更重要的是,随着模型代际演进,长上下文的可靠性也在持续提升:Gemini 3 Pro 在 128K 8-needle 检索测试中达到 77%,远超 Claude 的 47.1% 和 GPT 的 61.6%。本节将系统讲解如何在实际工作中高效利用百万级上下文,覆盖大代码库分析、长文档处理、多文件推理、视频/音频处理四大核心场景,并深入探讨上下文缓存、200K 价格阶梯优化和流式响应等实战技巧。


1. 百万 Token 上下文:能力边界与容量规划

1.1 容量直觉

内容类型大约容量典型场景
代码(80 字符/行)~50,000 行中型 TypeScript/Python/Rust 项目(300+ 文件)
中文文本~750,000 字完整法律合同集、企业知识库
英文文本~1,500,000 字8 本平均长度英文小说
PDF 文档~1,500 页技术手册、研究论文集
视频~3 小时完整会议录像、教程系列
音频~11 小时播客系列、客服录音
混合(代码+文档)视比例而定代码库 + README + 设计文档 + 测试

1.2 工具推荐

工具用途价格适用场景
Google AI Studio 在线 token 计数 + 长上下文测试免费快速验证 prompt 大小、可视化上传文件
Gemini API count_tokens编程式精确计数免费(API 调用)自动化管线中的 token 预算预检
Gemini CLI 终端长上下文交互免费(开源)命令行直接分析代码库
NotebookLM 长文档交互式问答免费研究论文、法律合同的交互式分析
Vertex AI 企业级长上下文部署按用量计费生产环境、合规需求

2. 长上下文可靠性演进(2.5 → 3 → 3.1)

百万 token 上下文窗口从 Gemini 1.5 Pro 时代就已存在,但”能装下”和”能用好”是两回事。三代模型在长上下文可靠性上的演进是选择模型的关键参考。

2.1 可靠性基准对比

维度Gemini 2.5 ProGemini 3 ProGemini 3.1 Pro
上下文窗口1M tokens1M tokens1M tokens
最大输出64K tokens64K tokens65K tokens
128K 8-needle 检索~65%(估计)77%≥77%(改进中)
长上下文推理质量中等,偶有上下文遗忘显著提升,多模态原生最佳,Deep Think 内置
已知问题上下文遗忘、指令漂移幻觉率偏高Preview 阶段延迟波动

2.2 128K 8-Needle 检索基准详解

128K 8-needle 检索测试是评估长上下文实际可用性的关键基准。它在 128K token 的文本中随机插入 8 个”针”(特定事实),然后要求模型同时检索所有 8 个事实。这比传统的单针测试(needle-in-a-haystack)难度高得多,因为它测试的是模型在长上下文中的多点并行注意力能力。

模型128K 8-Needle 检索准确率说明
Gemini 3 Pro77.0%长上下文多点检索最佳
GPT 系列61.6%中等水平
Claude 系列47.1%长上下文检索相对较弱

💡 实际意义:当你将一个 300+ 文件的代码库喂给模型,并要求它同时找出分散在不同文件中的多个相关实现时,Gemini 3 Pro/3.1 Pro 的检索准确率显著高于竞品。这对于跨文件推理、依赖分析、架构审查等场景至关重要。

2.3 各代模型长上下文选择建议

决策树:长上下文任务模型选择 ├── 需要最高推理质量 + 长上下文? → Gemini 3.1 Pro(Preview) ├── 需要稳定 GA + 长上下文? → Gemini 3 Pro ├── 需要速度 + 成本平衡? → Gemini 3 Flash(1M 上下文,$0.50/1M 输入) ├── 预算极度敏感? → Gemini 2.5 Flash(1M 上下文,$0.30/1M 输入) └── 上下文 < 200K + 极低成本? → Gemini 2.5 Flash-Lite($0.10/1M 输入)

3. 200K Token 价格阶梯与成本优化

3.1 价格阶梯机制

Gemini Pro 系列(2.5 Pro、3 Pro、3.1 Pro)在 200K token 处存在一个价格翻倍阶梯

模型输入 ≤200K输入 >200K输出 ≤200K输出 >200K
Gemini 3.1 Pro / 3 Pro$2.00/1M$4.00/1M$12.00/1M$18.00/1M
Gemini 2.5 Pro$1.25/1M$2.50/1M$10.00/1M$15.00/1M

⚠️ 关键洞察:当你的 prompt 从 199K token 增加到 201K token 时,整个输入的单价翻倍,不仅仅是超出部分。这意味着一个 201K 的请求比 199K 的请求贵约 60%。

3.2 成本优化策略

策略 1:上下文精简——控制在 200K 以内

import os from google import genai client = genai.Client(api_key=os.environ["GEMINI_API_KEY"]) def collect_project_files(project_dir, extensions=(".ts", ".tsx", ".py")): """收集项目文件并计算 token 数""" files = [] for root, dirs, filenames in os.walk(project_dir): # 跳过不必要的目录 dirs[:] = [d for d in dirs if d not in { "node_modules", ".git", "dist", "build", "__pycache__", ".next", "coverage" }] for f in filenames: if f.endswith(extensions): path = os.path.join(root, f) with open(path) as fh: files.append((path, fh.read())) return files def estimate_tokens(text): """粗略估算 token 数(中文约 1.5 token/字,英文约 1.3 token/词)""" return len(text) // 3 # 粗略估算 def build_context_under_budget(files, budget=190_000): """构建不超过 token 预算的上下文""" context_parts = [] total_tokens = 0 # 按文件重要性排序(入口文件优先) priority_patterns = ["index.", "main.", "app.", "config.", "types."] files.sort(key=lambda f: ( not any(p in f[0].lower() for p in priority_patterns), len(f[1]) # 小文件优先 )) for path, content in files: file_tokens = estimate_tokens(content) if total_tokens + file_tokens > budget: # 超预算,添加文件摘要而非全文 context_parts.append(f"// File: {path} (摘要: {len(content)} 字符, 已省略)") continue context_parts.append(f"// File: {path}\n{content}") total_tokens += file_tokens return "\n\n".join(context_parts), total_tokens # 使用示例 files = collect_project_files("./src") context, token_count = build_context_under_budget(files, budget=190_000) print(f"上下文大小: ~{token_count:,} tokens(在 200K 阶梯内)")

策略 2:上下文缓存——重复查询节省 90%

上下文缓存(Context Caching)是处理长上下文时最重要的成本优化手段。Gemini 提供两种缓存机制:

  • 隐式缓存(Implicit Caching):自动启用,相同前缀的请求自动命中缓存,无需额外代码
  • 显式缓存(Explicit Caching):手动创建缓存,保证成本节省,适合需要反复查询同一大文档/代码库的场景
from google import genai from google.genai import types client = genai.Client(api_key="your-api-key") # ========== 显式缓存:适合反复查询同一代码库 ========== # 1. 上传大文件(代码库打包或长文档) uploaded_file = client.files.upload(file="./project_codebase.txt") # 2. 创建缓存(TTL 设为 1 小时,可按需调整) cache = client.caches.create( model="gemini-3.1-pro-preview", config=types.CreateCachedContentConfig( display_name="my-project-codebase", system_instruction=( "你是一位资深软件架构师。以下是一个完整的项目代码库," "请基于这些代码回答用户的问题。" ), contents=[uploaded_file], ttl="3600s", # 1 小时 ) ) print(f"缓存已创建: {cache.name}") # 3. 使用缓存进行多次查询(每次查询只需支付缓存价格) questions = [ "这个项目的整体架构是什么?画出组件关系图。", "找出所有潜在的安全漏洞。", "哪些模块的测试覆盖率可能不足?", "给出重构建议,按优先级排序。", ] for q in questions: response = client.models.generate_content( model="gemini-3.1-pro-preview", contents=q, config=types.GenerateContentConfig(cached_content=cache.name) ) print(f"\n问题: {q}") print(f"回答: {response.text[:200]}...") # 查看缓存命中情况 print(f"缓存 token: {response.usage_metadata.cached_content_token_count}") print(f"总输入 token: {response.usage_metadata.prompt_token_count}")

缓存价格对比(以 Gemini 3.1 Pro 为例):

计费项标准价格缓存价格节省比例
输入 token(≤200K)$2.00/1M$0.20/1M90%
输入 token(>200K)$4.00/1M$0.40/1M90%
缓存存储$4.50/1M tokens/小时

💡 何时使用缓存:如果你对同一份长文档/代码库要进行 3 次以上查询,显式缓存几乎总是更划算。例如,缓存 500K token 的代码库 1 小时,存储费约 $2.25,但每次查询的输入费从 $2.00 降到 $0.10(500K × $0.20/1M),4 次查询即可回本。

策略 3:批处理 API——非实时场景再省 50%

# 批处理 API 适合非实时的批量分析任务 # 所有模型的批处理价格为标准价格的 50% # Gemini 3.1 Pro 批处理价格: # 输入 ≤200K: $1.00/1M(标准 $2.00 的 50%) # 输入 >200K: $2.00/1M(标准 $4.00 的 50%) # 输出: $6.00/1M(标准 $12.00 的 50%) # 批处理 + 缓存可以叠加使用,实现最大成本优化

4. 操作步骤:四大核心场景

场景 1:大代码库分析(300+ 文件)

步骤 1:收集并组织代码文件

import os from pathlib import Path from google import genai client = genai.Client(api_key=os.environ["GEMINI_API_KEY"]) def collect_codebase(project_dir, max_tokens=900_000): """智能收集代码库,按重要性排序""" files = [] # 定义文件优先级 high_priority = { "package.json", "tsconfig.json", "Cargo.toml", "pyproject.toml", "README.md", "ARCHITECTURE.md" } skip_dirs = { "node_modules", ".git", "dist", "build", "target", "__pycache__", ".next", "coverage", ".turbo", "vendor" } code_extensions = { ".ts", ".tsx", ".js", ".jsx", ".py", ".rs", ".go", ".java", ".kt", ".swift", ".vue", ".svelte" } for root, dirs, filenames in os.walk(project_dir): dirs[:] = [d for d in dirs if d not in skip_dirs] for fname in filenames: path = os.path.join(root, fname) ext = Path(fname).suffix if fname in high_priority or ext in code_extensions: try: with open(path, encoding="utf-8") as f: content = f.read() files.append({ "path": os.path.relpath(path, project_dir), "content": content, "priority": 0 if fname in high_priority else 1, "size": len(content) }) except (UnicodeDecodeError, PermissionError): continue # 按优先级排序,然后按大小排序 files.sort(key=lambda f: (f["priority"], f["size"])) # 组装上下文,控制总量 context_parts = [] total_chars = 0 char_budget = max_tokens * 3 # 粗略:3 字符 ≈ 1 token for f in files: if total_chars + f["size"] > char_budget: context_parts.append( f"// File: {f['path']} [已省略, {f['size']} 字符]" ) continue context_parts.append(f"// File: {f['path']}\n{f['content']}") total_chars += f["size"] return "\n\n".join(context_parts) # 收集代码库 codebase = collect_codebase("./my-project")

步骤 2:精确计算 token 数并选择价格策略

# 精确计算 token 数 token_response = client.models.count_tokens( model="gemini-3.1-pro-preview", contents=codebase ) token_count = token_response.total_tokens print(f"代码库 token 数: {token_count:,}") # 根据 token 数选择策略 if token_count <= 200_000: print(f"✅ 在 200K 阶梯内,输入价格: ${token_count / 1_000_000 * 2:.2f}") strategy = "direct" elif token_count <= 1_000_000: print(f"⚠️ 超过 200K 阶梯,输入价格: ${token_count / 1_000_000 * 4:.2f}") print("建议:使用上下文缓存降低重复查询成本") strategy = "cache" else: print(f"❌ 超过 1M 上下文窗口,需要分块处理") strategy = "chunk"

步骤 3:使用流式响应处理长上下文查询

对于长上下文查询,流式响应可以显著改善用户体验——无需等待模型处理完整个百万 token 上下文后才看到输出。

# 流式响应:边生成边输出,适合长上下文的交互式分析 response_stream = client.models.generate_content_stream( model="gemini-3.1-pro-preview", contents=f"""作为资深架构师,请对以下代码库进行全面分析: {codebase} 请提供: 1. 架构概览(用 Mermaid 格式画组件关系图) 2. 模块间依赖关系分析 3. 代码质量评估(命名规范、结构清晰度、复杂度) 4. 潜在问题和技术债务(按严重程度排序) 5. 重构建议(按优先级和投入产出比排序) """, config={"thinking_config": {"thinking_level": "HIGH"}} ) # 逐块输出结果 full_response = "" for chunk in response_stream: if chunk.text: print(chunk.text, end="", flush=True) full_response += chunk.text print(f"\n\n--- 完成 ---") print(f"总输出长度: {len(full_response)} 字符")

场景 2:长文档处理(法律合同、研究论文)

import time from google import genai from google.genai import types client = genai.Client(api_key="your-api-key") # 1. 上传 PDF 文件(支持最大 100MB) pdf_file = client.files.upload(file="./contract_bundle.pdf") # 等待文件处理完成 while pdf_file.state.name == "PROCESSING": time.sleep(2) pdf_file = client.files.get(name=pdf_file.name) print(f"文件处理完成: {pdf_file.uri}") # 2. 创建缓存(法律合同通常需要多轮审查) cache = client.caches.create( model="gemini-3.1-pro-preview", config=types.CreateCachedContentConfig( display_name="contract-review", system_instruction=( "你是一位资深法律顾问,精通中国合同法和商业法。" "请基于上传的合同文件回答问题,引用具体条款编号。" "如果合同中存在风险条款,请明确标注风险等级(高/中/低)。" ), contents=[pdf_file], ttl="7200s", # 2 小时,足够完成审查 ) ) # 3. 多轮审查查询 review_queries = [ "列出所有关键条款的摘要,包括:合同期限、付款条件、违约责任、知识产权归属、保密义务。", "找出所有可能对我方不利的条款,按风险等级排序,并给出修改建议。", "对比行业标准,这份合同的付款条件和违约金比例是否合理?", "生成一份合同审查报告,包含风险评估和修改建议清单。", ] for i, query in enumerate(review_queries, 1): print(f"\n{'='*60}") print(f"审查轮次 {i}: {query[:50]}...") print(f"{'='*60}") response = client.models.generate_content( model="gemini-3.1-pro-preview", contents=query, config=types.GenerateContentConfig( cached_content=cache.name, thinking_config=types.ThinkingConfig(thinking_level="HIGH") ) ) print(response.text)

场景 3:多文件推理与交叉引用

from google import genai client = genai.Client(api_key="your-api-key") # 多文件推理:同时分析需求文档、设计文档和代码实现 # 利用 Gemini 的多点注意力能力进行交叉验证 requirements = open("./docs/requirements.md").read() design_doc = open("./docs/design.md").read() api_code = open("./src/api/routes.ts").read() db_schema = open("./prisma/schema.prisma").read() test_files = open("./tests/api.test.ts").read() cross_reference_prompt = f"""请对以下项目文档和代码进行交叉引用分析: ## 需求文档 {requirements} ## 设计文档 {design_doc} ## API 实现代码 {api_code} ## 数据库 Schema {db_schema} ## 测试文件 {test_files} 请完成以下分析: 1. **需求覆盖度**:哪些需求已在代码中实现?哪些缺失? 2. **设计一致性**:代码实现是否与设计文档一致?有哪些偏差? 3. **Schema 匹配**:API 代码中的数据操作是否与 DB Schema 匹配? 4. **测试覆盖**:测试是否覆盖了所有 API 端点和关键业务逻辑? 5. **交叉引用问题**:文档间是否存在矛盾或不一致? 请用表格形式呈现需求追踪矩阵。 """ response = client.models.generate_content( model="gemini-3.1-pro-preview", contents=cross_reference_prompt, config={"thinking_config": {"thinking_level": "HIGH"}} ) print(response.text)

场景 4:视频/音频长上下文处理

import time from google import genai from google.genai import types client = genai.Client(api_key="your-api-key") # ========== 视频分析(最长 ~3 小时) ========== # 1. 上传视频文件 video_file = client.files.upload(file="./meeting_recording.mp4") while video_file.state.name == "PROCESSING": time.sleep(5) video_file = client.files.get(name=video_file.name) # 2. 分析完整会议录像 response = client.models.generate_content( model="gemini-3.1-pro-preview", contents=[ video_file, "请分析这段会议录像,提供:\n" "1. 会议摘要(关键决策和行动项)\n" "2. 每位参与者的发言要点\n" "3. 讨论中的分歧点和最终共识\n" "4. 待跟进事项清单(含负责人和截止日期)\n" "5. 按时间线标注关键讨论节点" ] ) print(response.text) # ========== 音频分析(最长 ~11 小时) ========== # 上传音频文件 audio_file = client.files.upload(file="./podcast_series.mp3") while audio_file.state.name == "PROCESSING": time.sleep(5) audio_file = client.files.get(name=audio_file.name) # 分析长音频 response = client.models.generate_content( model="gemini-3.1-pro-preview", contents=[ audio_file, "请对这段播客内容进行深度分析:\n" "1. 主题大纲和关键论点\n" "2. 嘉宾观点对比\n" "3. 提到的工具、书籍、资源列表\n" "4. 可引用的精彩语录(标注时间戳)" ] ) print(response.text)

5. 提示词模板

模板 1:大代码库架构分析

你是一位拥有 15 年经验的 [语言/框架] 架构师。 以下是一个完整的项目代码库([文件数] 个文件,约 [token 数] tokens): [完整代码库内容] 请完成以下分析任务: 1. **架构概览**:用 Mermaid 格式画出模块依赖关系图 2. **分层分析**:识别表示层、业务逻辑层、数据访问层的边界是否清晰 3. **代码质量**: - 命名规范一致性(1-10 分) - 模块内聚度(1-10 分) - 耦合度评估(1-10 分) 4. **技术债务**:列出 Top 5 技术债务,每项包含: - 问题描述 - 影响范围 - 修复难度(高/中/低) - 建议优先级 5. **重构路线图**:给出分阶段重构计划 请用中文回答,使用 Markdown 格式。

模板 2:长文档交叉审查

你是一位 [领域] 专家。以下是 [文档数量] 份相关文档: ## 文档 1:[文档名称] [文档内容] ## 文档 2:[文档名称] [文档内容] ... 请完成交叉审查: 1. **一致性检查**:文档间是否存在矛盾或不一致的描述? 2. **完整性检查**:是否有文档 A 提到但文档 B 缺失的内容? 3. **依赖分析**:文档间的引用关系是否正确? 4. **风险识别**:基于所有文档的综合分析,识别 [项目/合同/方案] 的主要风险 5. **改进建议**:给出具体的修改建议,引用具体文档和段落 输出格式:使用表格汇总发现,按严重程度排序。

模板 3:视频/音频内容深度分析

请对上传的 [视频/音频] 文件进行深度分析: 分析维度: 1. **内容摘要**:按时间线列出关键内容节点 2. **主题提取**:识别 [数量] 个核心主题 3. **[特定需求]**:[如:识别所有提到的技术工具和框架] 4. **情感分析**:[如:评估演讲者的语气变化和关键情绪转折点] 5. **行动项提取**:[如:列出所有提到的待办事项和决策] 输出要求: - 使用中文 - 关键引用标注时间戳(格式:[HH:MM:SS]) - 使用 Markdown 表格汇总结构化信息

实战案例 1:用 Gemini 3.1 Pro 审查 300+ 文件的 TypeScript 项目

背景

一个电商平台项目,包含 342 个 TypeScript 文件(前端 React + 后端 Node.js),总计约 45,000 行代码(~600K tokens)。团队需要在版本升级前进行全面的架构审查和安全评估。

操作流程

import os from google import genai from google.genai import types client = genai.Client(api_key=os.environ["GEMINI_API_KEY"]) # 1. 收集代码库 files = collect_codebase("./ecommerce-platform") # 使用前面定义的函数 # 2. 精确计算 token token_info = client.models.count_tokens( model="gemini-3.1-pro-preview", contents=files ) print(f"总 token: {token_info.total_tokens:,}") # 输出: 总 token: 612,345 # 3. 超过 200K,创建缓存以支持多轮审查 cache = client.caches.create( model="gemini-3.1-pro-preview", config=types.CreateCachedContentConfig( display_name="ecommerce-audit", system_instruction="你是一位资深全栈架构师,精通 React 和 Node.js。", contents=[files], ttl="3600s", ) ) # 4. 第一轮:架构审查 arch_review = client.models.generate_content( model="gemini-3.1-pro-preview", contents="请分析整体架构,画出模块依赖图,识别循环依赖和过度耦合。", config=types.GenerateContentConfig( cached_content=cache.name, thinking_config=types.ThinkingConfig(thinking_level="HIGH") ) ) # 5. 第二轮:安全审查 security_review = client.models.generate_content( model="gemini-3.1-pro-preview", contents="请进行安全审查:SQL 注入、XSS、CSRF、认证绕过、敏感数据泄露。", config=types.GenerateContentConfig(cached_content=cache.name) ) # 6. 第三轮:性能审查 perf_review = client.models.generate_content( model="gemini-3.1-pro-preview", contents="请分析性能瓶颈:N+1 查询、不必要的重渲染、缺失的索引、内存泄漏风险。", config=types.GenerateContentConfig(cached_content=cache.name) )

成本分析

项目计算费用
缓存创建(612K tokens)612K × $0.20/1M$0.12
缓存存储(1 小时)612K × $4.50/1M$2.75
3 次查询输入(缓存价格)3 × 612K × $0.20/1M$0.37
3 次查询输出(估计每次 8K tokens)3 × 8K × $12.00/1M$0.29
总计$3.53
对比:不使用缓存3 × 612K × $4.00/1M + 输出$7.63

使用缓存节省了约 54% 的成本。如果查询次数更多(如 10 次),节省比例更高。


实战案例 2:用长上下文分析 200 页研究论文集

背景

一位研究人员需要综合分析 15 篇关于大语言模型安全性的研究论文(共约 200 页,~300K tokens),提取关键发现、方法论对比和研究空白。

操作流程

import os import time from google import genai from google.genai import types client = genai.Client(api_key=os.environ["GEMINI_API_KEY"]) # 1. 上传所有 PDF 文件 pdf_dir = "./papers/" uploaded_files = [] for fname in sorted(os.listdir(pdf_dir)): if fname.endswith(".pdf"): f = client.files.upload(file=os.path.join(pdf_dir, fname)) uploaded_files.append(f) print(f"已上传: {fname}") # 等待所有文件处理完成 for f in uploaded_files: while f.state.name == "PROCESSING": time.sleep(2) f = client.files.get(name=f.name) # 2. 创建缓存 cache = client.caches.create( model="gemini-3.1-pro-preview", config=types.CreateCachedContentConfig( display_name="llm-security-papers", system_instruction=( "你是一位 AI 安全领域的研究员。" "以下是 15 篇关于大语言模型安全性的研究论文。" "请基于这些论文回答问题,引用具体论文标题和页码。" ), contents=uploaded_files, ttl="7200s", ) ) # 3. 综合分析 response = client.models.generate_content( model="gemini-3.1-pro-preview", contents="""请对这 15 篇论文进行系统性综述: 1. **研究主题分类**:将论文按研究方向分组(如:对抗攻击、防御机制、评估框架等) 2. **方法论对比**:用表格对比各论文的研究方法、数据集、评估指标 3. **关键发现汇总**:每篇论文的核心贡献(1-2 句话) 4. **共识与分歧**:研究者们在哪些问题上达成共识?哪些问题存在分歧? 5. **研究空白**:基于现有研究,识别尚未充分探索的方向 6. **未来方向建议**:给出 3-5 个值得深入研究的方向 请用学术论文的综述风格撰写,引用格式为 [论文标题, 年份]。 """, config=types.GenerateContentConfig( cached_content=cache.name, thinking_config=types.ThinkingConfig(thinking_level="HIGH") ) ) print(response.text)

关键决策点

  • 为什么不用 RAG:15 篇论文共 ~300K tokens,完全在 Gemini 的 1M 上下文窗口内。使用长上下文直接分析比 RAG 管线更简单,且能保持论文间的交叉引用关系,避免分块导致的上下文丢失
  • 为什么用 HIGH 思考级别:学术综述需要深度推理和跨论文对比,HIGH 级别能产生更有洞察力的分析
  • 缓存策略:研究分析通常需要多轮迭代(先综述,再深入某个方向),2 小时 TTL 足够完成一个分析会话

避坑指南

❌ 常见错误

  1. 忽略 200K 价格阶梯,导致成本翻倍

    • 问题:一个 250K token 的请求,输入成本是 $1.00(250K × $4/1M),而如果精简到 195K,成本仅 $0.39(195K × $2/1M)——差距 2.5 倍
    • 正确做法:在发送请求前用 count_tokens 检查,如果接近 200K,优先精简上下文(去掉测试文件、注释、空行等)
  2. 所有长上下文任务都用 Pro,忽视 Flash 的能力

    • 问题:Gemini 3 Flash 同样支持 1M 上下文窗口,且输入价格仅 $0.50/1M(Pro 的 1/4)
    • 正确做法:简单的文档摘要、信息提取用 Flash;复杂的跨文件推理、架构分析才用 Pro
  3. 不使用缓存进行多轮查询

    • 问题:对同一份 500K token 的代码库进行 5 次查询,不用缓存需支付 5 × $2.00 = $10.00 输入费
    • 正确做法:创建显式缓存,5 次查询的输入费降至 5 × $0.10 = $0.50,加上存储费 $2.25,总计 $2.75(节省 72%)
  4. 将整个 monorepo 无差别塞入上下文

    • 问题:大型 monorepo 可能有数百万行代码,远超 1M token 限制;即使能装下,无关代码也会稀释模型的注意力
    • 正确做法:只包含与当前任务相关的模块,使用文件过滤和优先级排序
  5. 忽视长上下文的延迟问题

    • 问题:处理接近 1M token 的输入时,首 token 延迟(TTFT)可能达到 30-60 秒甚至更长
    • 正确做法:使用流式响应(generate_content_stream)改善用户体验;非实时场景使用批处理 API
  6. 在 Preview 模型上构建生产系统

    • 问题:Gemini 3.1 Pro 目前为 Preview 状态,延迟和可用性可能波动
    • 正确做法:生产环境使用 GA 状态的 Gemini 3 Pro;3.1 Pro 用于实验和评估

✅ 最佳实践

  1. count_tokens,再发请求:养成在发送长上下文请求前检查 token 数的习惯,避免意外触发价格阶梯
  2. 善用隐式缓存:将不变的内容(系统指令、参考文档)放在 prompt 开头,相似请求短时间内发送,自动享受缓存优惠
  3. 分层模型策略:Flash 处理简单提取,Pro 处理复杂推理,批处理处理非实时任务
  4. 结构化输入:用清晰的文件路径标记、分隔符和层级结构组织长上下文,帮助模型更好地定位信息
  5. 渐进式分析:先用 Flash 做快速概览,识别关键区域后,再用 Pro + HIGH 思考级别深入分析特定模块

相关资源与延伸阅读

资源类型说明
Gemini API 上下文缓存文档 官方文档显式/隐式缓存的完整 API 参考和代码示例
Gemini API Token 计数文档 官方文档count_tokens API 使用指南
Gemini Developer API 定价 官方定价最新价格,包含 200K 阶梯和缓存价格
Google AI Studio 在线工具免费测试长上下文能力,可视化 token 计数
Gemini CLI 开源工具终端直接分析代码库,免费 1M 上下文
NotebookLM 在线工具上传文档进行交互式长上下文问答
Gemini API 批处理文档 官方文档批处理 API 使用指南,50% 成本折扣
Gemini 长上下文设计指南 官方指南Google 官方的长上下文最佳实践

参考来源


📖 返回 总览与导航 | 上一节:Gemini 模型家族能力概览 | 下一节:多模态能力实战

Last updated on