更新于

Claude 1M 上下文实战：何时开启与最佳实践

Claude长上下文1M context进阶

Anthropic 在 2025 年把 Claude 的上下文窗口从 200k 扩到 1M（部分场景）。这是一个大新闻但用法上有几个细节常被忽略。本文讲清楚怎么开、什么场景值得开、与 Gemini 2.5 Pro 的对比。

一、200k vs 1M：两套机制

Claude 默认 200k 上下文。1M 是通过 beta 标签开启：

POST /v1/messages
anthropic-beta: context-1m-2025-08-07

或在 SDK：

client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=8000,
    messages=[...],
    extra_headers={"anthropic-beta": "context-1m-2025-08-07"},
)

二、定价差异

1M 上下文模式的输入 token 价格比 200k 模式贵约 2 倍。具体：

模式输入价（相对）输出价
200k 标准100100
1M beta200100

关键：

  • 1M 模式即使你只输入了 5k tokens，也按 1M 模式的高价
  • 一旦开 beta 头，整个请求按高价
  • prompt caching 仍可用，能部分抵消

结论：除非确实需要超长输入，不要默认开 1M。

三、什么场景值得开

场景输入预估1M 模式必要？
日常对话< 10k不必
代码 review 单 PR20–50k不必
长文档摘要50–150k边界
整个代码仓库分析200k–800k是
多文档综合查询200k–800k是
长视频转录分析100k–500k看长度

最适合 1M 的场景：

  • 一次性给整个中型代码仓库（< 800k tokens）让模型理解架构
  • 把多个法律 / 学术文献合并问综合性问题
  • 长会议记录、长访谈转录综合分析

四、与 Gemini 2.5 Pro 的对比

维度Claude 1MGemini 2.5 Pro
上下文1M2M
价格高（200k 价 × 2）中等
召回准确率（500k 输入）88%92%
推理质量强强
编程能力极强中等
中文极强中等

结论：

  • 纯长上下文召回：Gemini 优势（更便宜、上下文更大）
  • 长上下文 + 编程 / 中文：Claude 优势

五、长上下文的性能特征

输入大小 vs 首 token 延迟：

输入Claude 1M TTFB
10k4s
100k12s
500k35s
800k55s

实战：> 200k 输入的请求 TTFB 上升明显。如果你的产品对响应时间敏感，谨慎用 1M 模式。

六、长上下文 + 缓存

长上下文 + caching 是最佳组合：

  • 大文档作为 system prompt 写一次，开 cache_control
  • 同一文档反复提问，每次只付缓存命中价（1/10）
  • 单次输入大也接受，因为后续都便宜
client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=2000,
    extra_headers={"anthropic-beta": "context-1m-2025-08-07"},
    system=[{
        "type": "text",
        "text": huge_document,   # 800k tokens
        "cache_control": {"type": "ephemeral"},
    }],
    messages=[{"role": "user", "content": "..."}],
)

首次请求 ~$10，后续每次 ~$1。

七、走中转时的注意点

中转必须透传 anthropic-beta 头才能开 1M：

curl -i https://yotradeapi.com/v1/messages \
  -H "x-api-key: $KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: context-1m-2025-08-07" \
  -H "content-type: application/json" \
  -d '{...}'

如果中转不透传 beta 头，发了 500k tokens 会被截断或报错。接入前用一个 250k+ 输入的请求测一下。

八、典型用法：代码仓库分析

import pathlib, json
from openai import OpenAI

def collect_repo(root, max_chars=2_000_000):
    parts = []
    total = 0
    for p in pathlib.Path(root).rglob("*"):
        if p.is_file() and p.suffix in (".py", ".ts", ".md", ".json"):
            content = p.read_text(errors="ignore")
            if total + len(content) > max_chars:
                break
            parts.append(f"=== {p} ===\n{content}\n")
            total += len(content)
    return "\n".join(parts)

repo = collect_repo("./my-project")
print(f"chars: {len(repo)}")

client = OpenAI(api_key="sk-yo-...", base_url="https://yotradeapi.com/v1")

resp = client.chat.completions.create(
    model="claude-sonnet-4-6",
    max_tokens=4000,
    messages=[
        {"role": "system", "content": f"项目代码：\n{repo}"},
        {"role": "user", "content": "找出可能的性能瓶颈，按严重度排序。给出 3 个最值得优化的地方。"},
    ],
    extra_headers={"anthropic-beta": "context-1m-2025-08-07"},
)
print(resp.choices[0].message.content)

九、什么时候反而不要用长上下文

  • 任务和上下文相关性弱：模型会被无关信息干扰
  • 响应时间敏感：TTFB 太久
  • RAG 是更好选择：检索 + 重点放进上下文比”全塞进去”更准确
  • 预算紧：1M 模式贵

十、与 RAG 的取舍

场景1M 上下文RAG
文档库 < 1M tokens直接塞不必
文档库 > 1M tokens必须 RAGRAG
一次性深度分析上下文不适合
高频提问不划算RAG
关联召回质量要求高上下文看效果
中文表现Claude > Gemini看 embedding

简单决策：一次性深度任务用长上下文，反复提问用 RAG。

十一、相关阅读

需要透传 anthropic-beta 头、支持 1M 上下文的中转？YoTradeApi 完整透传 beta headers，按上面代码直接发请求即可。

相关阅读