當我開始構建 /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
