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 Pro | Gemini 3 Pro | Gemini 3.1 Pro |
|---|---|---|---|
| 上下文窗口 | 1M tokens | 1M tokens | 1M tokens |
| 最大输出 | 64K tokens | 64K tokens | 65K 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 Pro | 77.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/1M | 90% |
| 输入 token(>200K) | $4.00/1M | $0.40/1M | 90% |
| 缓存存储 | — | $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 足够完成一个分析会话
避坑指南
❌ 常见错误
-
忽略 200K 价格阶梯,导致成本翻倍
- 问题:一个 250K token 的请求,输入成本是 $1.00(250K × $4/1M),而如果精简到 195K,成本仅 $0.39(195K × $2/1M)——差距 2.5 倍
- 正确做法:在发送请求前用
count_tokens检查,如果接近 200K,优先精简上下文(去掉测试文件、注释、空行等)
-
所有长上下文任务都用 Pro,忽视 Flash 的能力
- 问题:Gemini 3 Flash 同样支持 1M 上下文窗口,且输入价格仅 $0.50/1M(Pro 的 1/4)
- 正确做法:简单的文档摘要、信息提取用 Flash;复杂的跨文件推理、架构分析才用 Pro
-
不使用缓存进行多轮查询
- 问题:对同一份 500K token 的代码库进行 5 次查询,不用缓存需支付 5 × $2.00 = $10.00 输入费
- 正确做法:创建显式缓存,5 次查询的输入费降至 5 × $0.10 = $0.50,加上存储费 $2.25,总计 $2.75(节省 72%)
-
将整个 monorepo 无差别塞入上下文
- 问题:大型 monorepo 可能有数百万行代码,远超 1M token 限制;即使能装下,无关代码也会稀释模型的注意力
- 正确做法:只包含与当前任务相关的模块,使用文件过滤和优先级排序
-
忽视长上下文的延迟问题
- 问题:处理接近 1M token 的输入时,首 token 延迟(TTFT)可能达到 30-60 秒甚至更长
- 正确做法:使用流式响应(
generate_content_stream)改善用户体验;非实时场景使用批处理 API
-
在 Preview 模型上构建生产系统
- 问题:Gemini 3.1 Pro 目前为 Preview 状态,延迟和可用性可能波动
- 正确做法:生产环境使用 GA 状态的 Gemini 3 Pro;3.1 Pro 用于实验和评估
✅ 最佳实践
- 先
count_tokens,再发请求:养成在发送长上下文请求前检查 token 数的习惯,避免意外触发价格阶梯 - 善用隐式缓存:将不变的内容(系统指令、参考文档)放在 prompt 开头,相似请求短时间内发送,自动享受缓存优惠
- 分层模型策略:Flash 处理简单提取,Pro 处理复杂推理,批处理处理非实时任务
- 结构化输入:用清晰的文件路径标记、分隔符和层级结构组织长上下文,帮助模型更好地定位信息
- 渐进式分析:先用 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 API Context Caching — Google AI for Developers (持续更新,Google 官方文档)
- Gemini Developer API Pricing (持续更新,最后验证 2026-02-19)
- Gemini 3.1 Pro Is Here: Benchmarks, Pricing, and How It Stacks Up — FelloAI (2026-02-21)
- Gemini 3.1 Pro ups performance, lowers cost curve — The Deep View (2026-02-21)
- Architecture, Context Windows, and Output Dynamics — Exzil Calanza (2026-02-22)
- Google Gemini 3 Benchmarks Explained — Vellum (2025-12)
- Gemini 3.1 Pro on Gemini CLI, Gemini Enterprise, and Vertex AI — Google Cloud Blog (2026-02-19)
- Gemini API Batch vs Context Caching: Cost Optimization Guide — YingTu AI (2026-01)
📖 返回 总览与导航 | 上一节:Gemini 模型家族能力概览 | 下一节:多模态能力实战