{{< resource-info >}}

1M 上下文窗口 LLM 2026：950K Token 代码库实测 #

Meta Description：把 950K token 代码库灌进 Gemini 2.5 Pro 和 Claude Sonnet 4.6。实测检索、延迟、成本。两家都号称 1M——只有一家真正稳定兑现。

2026 年到处都在喊 1M token 上下文窗口。Gemini 2.5 Pro 和 Claude Sonnet 4.6（1M 档）都打出这个招牌。“1M 上下文"在实践中到底意味着什么？ 本文用同一份 950K token 代码库、可量化的检索任务对两家进行实测。

⚡ 一句话总结 #

Gemini 2.5 Pro：完整 1M 窗口内质量一致。约 1.25 美元/1M 输入。原生召回首选。

Claude Sonnet 4.6（1M 档）：约 3.50 美元/1M 输入。超过约 700K token 后检索退化，但中等上下文的推理质量更高。

低于 200K token：直接塞上下文（比 RAG 简单）。

200K-1M：两家都行，按成本或推理需求选择。

超过 1M：必须 RAG，没有模型装得下。

测试设置 #

把一份 950K token 的开源 TypeScript 代码库（规模相当于中型 SaaS 应用）灌进两个模型。跑 30 个检索问题：

• 10 个针对前 100K token 内的代码
• 10 个针对 400K-600K token（中段）的代码
• 10 个针对 800K-950K token（深段）的代码

检索准确率 #

结论：两家在"首块"内容上都能用。Gemini 在深段检索完胜。Claude 在 700K 之后质量明显下滑。

延迟 #

• Gemini 2.5 Pro：950K 输入时首 token 12-18 秒
• Claude Sonnet 4.6（1M 档）：950K 输入时首 token 18-25 秒

满上下文两家都慢。延迟敏感的交互式工作流不要用 1M 上下文。

成本现实 #

按每天 50 次查询、平均每次 950K token 计算：

• Gemini：50 × 0.95M × $1.25/1M = 59 美元/天 = 1770 美元/月
• Claude（1M 档）：50 × 0.95M × $3.50/1M = 166 美元/天 = 4980 美元/月

对于大批量长上下文工作，Gemini 便宜 3 倍。两家都会烧穿预算——在 1M 上下文下，每次查询 0.001 美元变成 1 美元。

何时真正该用 1M 上下文 #

该用 1M 的场景：

• 一次性分析大型代码库/文档
• RAG 检索会漏掉关联的长上下文问答
• 跨多文件推理，引用关系重要

不该用 1M 的场景：

• 查询会重复（RAG 可摊销 embedding 成本）
• 延迟敏感（1M 慢）
• 语料频繁更新（RAG 处理更新很轻量）

决策树 #

Corpus size?
├── < 100K tokens → stuff context, any model
├── 100K-700K → either Gemini or Claude works
├── 700K-1M → Gemini (Claude degrades)
└── > 1M → must use RAG, even 1M models can't fit

推荐基础设施 #

当 1M 不够、需要做 RAG 托管时：

• DigitalOcean — 200 美元额度足够搭好向量数据库
• HTStack — 香港 VPS，低延迟检索

联盟链接——价格相同，支持 dibi8.com。

结论 #

“1M 上下文窗口"的营销是真的，但要看工作负载。Gemini 2.5 Pro 在完整窗口内质量稳定、成本低——原生检索首选。Claude Sonnet 4.6 的 1M 档更贵、超过 700K 退化，但中等上下文的推理质量更强。

2026 年大多数生产场景：交互式流程别用 1M（太慢 + 太贵）。用 RAG。把 1M 上下文留给一次性深度分析任务——成本由洞察广度来证明合理。

相关阅读：RAG vs 微调 2026 · AI 编程工具 2026 Q2 大乱斗 · MCP 服务器 2026 排行