当我开始构建 /tools/pdf-chat 时，产品定位自己就呼之欲出了：Gemini 2.5 Flash 拥有百万级的 token 上下文窗口。你可以直接丢入一份 1500 页的 PDF，然后一次性提问，与整个文档对话。无需分块，无需 RAG，无需嵌入管道，无需检索错误。简直是魔法。
当你算笔账后会发现，魔法其实有点贵。
这篇文章将从内行视角，揭示运行百万级 token 上下文的真实成本，它如何塑造了 GeminiOmni 的定价策略，以及传统的分块式 RAG 何时才是正确答案。如果你正在构建任何处理长文档的产品，这就是在确定分层方案前必须消化理解的权衡。
核心数字
Gemini 2.5 Flash，目前最便宜的主流百万级上下文模型，定价为 每百万输入 token 0.30 美元 和 每百万输出 token 2.50 美元。这是我所知已公布的最低百万级上下文定价，而且相同上下文长度下，它仍比 Gemini 2.5 Pro 便宜 8 倍。
一百万 token 是个很大的数量。具体来说：
- 一百万 token ≈ 75 万个英文单词 ≈ 1500 页散文 ≈ 3000 页密集的学术论文
- 对于典型的扫描版 PDF（模型需要 OCR 图片），预期每百万 token 只能覆盖 800–1000 页，因为图片本身会消耗 token 预算
现在来看那个没人愿意公开做的乘法：
- 发送一份 200 页的 PDF（约 13 万 token）一次花费 0.039 美元。大约 4 美分。很便宜。
- 发送一份 1500 页的 PDF（约 98 万 token）一次花费 0.294 美元。30 美分。
- 提出十个追问，每次都要重新发送整份 PDF 作为上下文，花费 2.94 美元。针对那份 1500 页的文档，要花 3 美元。
最后一个数字，彻底打破了我原本的定价模型。
为什么追问需要重新发送整份 PDF
这是那些热情洋溢地撰写百万级上下文博文的人从未提及的部分。Gemini 的上下文窗口是按 每次调用 计，而非 每次会话。不存在持久的服务器端状态来为下一次消息保存你的文档。
当你在聊天会话中提出第二个问题时，客户端必须重新发送整份 PDF，再加上新问题以及模型上一次的回答（以保持连贯性）。每一轮的成本与第一轮大致相同。没有缓存折扣。
Google 已经推出了“上下文缓存”功能来优化这一点——你可以将长输入缓存最多一小时，并在重复使用时支付更低的每次调用费率——但缓存本身也并非免费。对于 Flash，缓存存储成本约为每百万 token 每小时 1 美元。对于一份 1500 页的文档，仅保持缓存活跃就需要大约 1 美元/小时。
以下三个真实场景由此产生：
- 针对新文档的一次性提问。 每个问题 0.04–0.30 美元。确实便宜。值得。
- 针对新文档的十轮问答会话，无缓存。 0.40–3.00 美元。作为付费功能尚可接受，但对免费功能来说相当残酷。
- 针对一份 1500 页文档的一小时深度对话，30+ 个问题。 启用缓存：约 1 美元保持活跃 + 每轮 0.05 美元 = 总计约 2.50 美元。无缓存：9 美元。一旦会话时长超过某个阈值，缓存就至关重要。
何时分块式 RAG 真正更便宜
这是异端邪说部分：对于某些工作负载，老式的“分块 + 嵌入 + 检索”管道仍然比百万级上下文便宜得多。
具体来说，如果你有 稳定的文档语料库（而不是每次都上传新文档），并且 有许多用户提出许多问题，那么 RAG 胜出：
- 嵌入语料库：Gemini Embedding 2 收费 0.20 美元/百万 token——一次嵌入一份 1500 页文档花费 0.20 美元，永久存储向量。
- 每轮提问：检索前 5 个分块（约 5000 token），将它们发送给 Gemini 2.5 Flash。每个问题的成本：约 0.0015 美元。连一美分都不到。
- 对比百万级上下文：如果每次重新发送整份文档，每个问题成本 0.30 美元。
对于基于固定知识库的客服机器人，RAG 便宜 200 倍。对于研究助手阅读用户刚上传的新论文，RAG 的嵌入开销无法摊销，此时百万级上下文胜出。
决策规则：
| 工作负载 | 使用方案 |
|---|---|
| 用户上传一次性文档，问 1–10 个问题 | 百万级上下文（无需嵌入设置，检索全由模型处理） |
| 静态知识库，多用户，多轮提问 | RAG（将嵌入成本摊销到所有查询中） |
| 用户上传多个文档，希望跨文档推理 | 百万级上下文（RAG 检索可能遗漏跨文档引用） |
| 针对单一密集文档的合规/法律审查 | 百万级上下文（RAG 可能因分块边界错过关键条款） |
GeminiOmni 的 PDF 聊天明确属于“一次性上传，1–10 个问题”的场景——这就是我们无条件使用百万级上下文的原因。
这如何塑造了定价层级
一旦我算清了每页成本的分摊，PDF 工具的层级结构就几乎是机械地得出了：
免费层：200 页以下，无限次提问。 一份 200 页的 PDF 每个问题成本约 0.04 美元。即使一个重度免费用户每月问 100 个问题，我的成本也只需 4 美元。这是一个可持续的获客成本——我可以从免费到 Pro 的转化率中赚回来。
Pro 层：9 美元/月，不限文档长度，不限提问次数。 基准情况：一个用户每月上传三份 1500 页的文档，每份问 30 个问题 = 90 个问题 × 约 0.30 美元 = 27 美元。这会颠覆单位经济模型。两件事拯救了它：
- 大多数 Pro 用户并不会冲击上限。第 90 百分位的重度用户每月成本约 4 美元。平均值更接近 0.80 美元。
- 上下文缓存将长会话的每次提问成本降低了大约 4 倍。
我能够接受在最重度 Pro 用户身上维持薄利运营，因为他们是最活跃、最积极地宣传产品效果的人，并且会带动队友转化。试图从最顶层的 10% 用户身上榨取最大利润，只会破坏他们眼中的产品体验。
团队层：79 美元/月，3 个席位，带 API 访问权限。 这才是真正利润的来源。对于相同使用量，团队支付的价格是 Pro 用户的 4 倍，因为他们购买的是协作、API 访问和 SLA——而不是原始的推理能力。我对此很满意，因为这符合 Notion、Linear 以及其他所有 SaaS 团队层级的模式。
如果今天重新构建，我会做什么不同的事
在运行了两个月的数据后，我有足够勇气分享一些看法：
向用户展示每次提问的成本。 当用户上传一份 1500 页的文档时，UI 应该说“此文档上的每个问题大约花费 1 个积分”。向用户隐藏成本会造成道德风险——他们明明问 5 个问题就能解决，却问了 50 个，最后我承担了利润损失。透明的定价能自我调节这种行为。
默认对超过 500 页的文档启用缓存。 在长会话上实现 4 倍的成本降低，足以让“启用缓存”不应该是一个高级用户开关。它应该成为默认行为，并为少数在意隐私的用户提供“禁用缓存”的退出选项。
不要承诺任何“无限”。 我犯了个错误，在 Pro 版宣传中写了“PDF 聊天无限页数”。现在这成了硬性承诺，我必须为即使是最高频率的用户也让单位经济模型成立。未来的我会写成“每份文档最多 5000 页，月度用量公平使用上限”。下一个产品记住这个教训。
继续阅读
— Lena
