你把整份 800 頁的合約載入模型。它回答了——而那一題的帳單，超過你上個月全部的 API 花費。模型確實「處理」了上下文視窗。你的預算可沒有。
長上下文是 LLM 技術棧中最被炒作的能力，而這股熱潮催生了一場辯論——「RAG 已死？」——這場辯論的形狀幾乎完全錯誤。1M token 的視窗是真的：Gemini 推出 2M 等級的視窗、Claude 推出 1M、Moonshot 的 Kimi K3 在 2026 年 7 月以 1M 上市、DeepSeek 的 V4 Pro 配備 1M 上下文與 384K 輸出。不過，物理定律沒有改變：token 要錢、attention 會隨距離衰退，而且「我塞得進去嗎」從來不等於「我應該塞嗎」。
這份指南涵蓋辯論跳過的部分：成本算式（完整上下文 vs 快取 vs RAG）、讓 1M token 視窗真正可用的工作流程模式（map-reduce、compaction、滑動視窗、分層上下文），以及用數字而不是感覺結束「長上下文 vs RAG」之爭的決策框架。
2026 年長上下文 API 提供了什麼
重點：1M 視窗現在已是前沿模型的標準配備——而差異化的關鍵是成本、快取行為與 attention 品質，不是視窗大小。
2026 年的產品陣容：Gemini 的 2M 等級視窗、Claude 的 1M GA、Kimi K3 的 1M（這台在上下文與價格兩方面都重新設定了期待的開放旗艦）、1M 上下文的 DeepSeek V4 Pro，以及 400K 以上的 GPT 等級家族。目前各供應商的限制，以模型目錄透過統一 endpoint 追蹤為準。
視窗大小不會告訴你的三件事：
- 全視窗下的每 token 成本。 用前沿費率處理 1M token 的輸入，每一題都是真金白銀——確切數字依供應商與層級而定，這正是成本算式那一節的重點。
- 快取定價。 大多數供應商把快取命中的輸入 token 折扣到大約基礎費率的十分之一——這是業界一致記錄的快取慣例——這徹底改變了重複性長上下文工作負載的經濟學。
- 深度處的 attention 品質。 「視窗是 1M」代表模型接受1M；不代表它會均勻使用1M。深度處的檢索式衰退是真實的，而這正是下方工作流程模式存在的工程理由。
為什麼「1M Token」不等於「1M 有用的 Token」
重點：視窗大小是上限，不是品質承諾——成本曲線是線性的，attention 曲線則不是。
行銷背後的三個現實：
- 成本線性成長，而且很痛。 視窗裡的每一個 token 都要計費，無論它有沒有貢獻。用美元級費率問一題 1M token 的問題，就是一題美元級的問題——可以重複，直到不行為止。
- Attention 隨距離衰退。 跨模型家族的證據一致顯示，模型對長上下文的開頭與結尾運用得比中間好——「lost in the middle」是有充分記錄的模式。硬塞進去不等於理解。
- 快取改變了形狀。 在快取定價約 0.1× 的情況下，第二題全視窗問題就便宜了——這獎勵穩定、重複的長上下文（同一份文件被查詢很多次），懲罰一次性載入完整上下文。
設計上的後果：長上下文最適合當成可重複使用的資產——一份你反覆查詢的穩定語料——最不適合當成每題一次的下注。
成本算式：完整上下文 vs 快取 vs RAG
重點：對同一份語料的反覆查詢，快取加 RAG 通常勝出；一次性整份文件的問題，完整上下文最誠實；其他情況，把數字算出來。
用一個具體的例子來比較——500K token 的語料、十個問題：
| 做法 | 成本驅動因素 | 典型的相對成本 |
|---|---|---|
| 每題都載入完整上下文 | 500K tokens × 10 | 完整輸入價格的 10 倍 |
| 快取 + 完整上下文 | 快取輸入約 0.1× | 約完整輸入價格的 1 倍 |
| RAG（top-k 檢索） | 5K tokens × 10 + 索引 | 一次完整輸入的零頭 |
結構性的結論：**對重複性查詢，RAG 在成本上以數量級勝出；當同一份語料經常被查詢時，快取讓完整上下文變得有競爭力；完整上下文只在一次性深度閱讀的問題上徹底勝出。**品質走的是另一條曲線——檢索可能漏掉、完整上下文可能淹沒——這正是決策框架存在的原因。
數字依供應商與語料而異；本系列的快取指南涵蓋快取機制，下方的實作範例就是一個可以用你自己的費率填入的模板。
如何打造 1M Token 的工作流程
重點：四種模式——map-reduce、compaction、滑動視窗、分層上下文——而設計規則是「永遠不為你用不到的 token 付費」。
- Map-reduce。 分割語料、處理區塊、合併結果。這是「回答整份文件」的主力：每個區塊都很小、平行處理很自然、最後的綜合階段只讀摘要。成本隨區塊數成長，而不是隨整個視窗成長。
- Context compaction。 在下一輪之前壓縮中間部分——摘要、抽取關鍵事實、丟掉冗餘。Compaction 是 agent 在沒有平方級成本的情況下維持多輪上下文的方式；它是「agent 記得」與「agent 扛著整份逐字稿」之間的差別。
- 滑動視窗。 保留最近的 N 個 token，把掉出去的部分做摘要。對對話與串流而言，視窗跟著動作走——這是讓互動成本維持在界線內的模式。
- 分層上下文。 一條快速路徑與一條完整路徑：例行輪次用摘要，問題需要時再按需檢索完整段落——自訂路由讓快／全的決策變成機械化操作。分層是讓「1M 上下文」成為能力而不是帳單的正式環境模式。
共同的主軸：每一種模式都是一種「只為重要的 token 付費」的方式。chat completions endpoint處理機制；這些模式決定經濟學。
如何選擇：長上下文 vs RAG vs 混合式
重點：問題不是「RAG 死了嗎」——而是「我的查詢模式是什麼」——而且這個決策框架只有三個問題，不是一種信仰。
- 語料是靜態的、而且會被反覆查詢嗎？ 快取加 RAG——索引一次、每次查詢檢索、快取穩定的 prefix。
- 問題是對一份大文件的深度一次性閱讀嗎？ 完整上下文——這是誠實的使用情境：檢索會漏、而成本被問題的罕見性限制住。
- 是一場長期進行的 agent 對話嗎？ 分層上下文——摘要加上檢索加上有界線的視窗，永遠不是完整歷史。
與本系列RAG 指南的關係是互補，不是競爭：那本指南負責檢索內部——分塊、混合搜尋、reranking——這本指南負責上下文視窗的經濟學與工作流程模式。兩者都適用於大多數正式環境系統，混合式是常態，不是妥協。
常見錯誤
重點：四個陷阱——三個成本形狀、一個品質形狀——每一個都是「1M 視窗」炒作的真實體現。
- 預設就用完整上下文。 視窗存在，所以什麼都塞進去——沒有快取設計、沒有檢索的線性成本陷阱。這份指南裡的預算表之所以存在，正是因為這個錯誤是預設行為。
- Agent 迴圈裡沒有 compaction。 每一輪都附加完整歷史；到了第二十輪，agent 正在為它說過的一切付費。對長期運行的 agent 來說，compaction 不是可選項。
- 漂移的快取 Key。 快取倍率只在 prefix 維持 byte 穩定時才適用——動態 header、時間戳記或重新排序的區段都會把命中率歸零，讓約 0.1× 變成 1×。快取指南有機制說明；紀律是你自己的。
- 用視窗中間來做基準測試。 「它處理了 1M token」是在上下文的開頭與結尾測試的——lost-in-the-middle 模式依然存在，而沒有抽樣中間部分的 eval set，會告訴你錯誤的故事。
常見問題
1M token 的上下文能取代 RAG 嗎？
對一份大文件的深度一次性閱讀，可以——這是誠實的使用情境。對語料的反覆查詢，不行：成本算式（完整輸入的 10 倍 vs 檢索級的大小）讓 RAG 成為答案，快取則扮演橋樑。由三個問題的框架來決定，不是行銷。
一題 1M token 的查詢實際要多少錢？
每一題都以前沿費率計完整輸入——確切數字依供應商與層級而定。在快取命中約 0.1× 的情況下，對同一份語料的反覆查詢會讓成本崩跌。這份指南裡的表格是形狀；你的供應商頁面才是數字。
什麼是 context compaction？
在輪次之間壓縮對話或語料——摘要、抽取關鍵事實、丟掉冗餘——讓 agent 攜帶意義而不是完整歷史。這是讓長期運行的 agent 保持可負擔的模式，而且超過幾輪之後就沒有討價還價的空間。
快取定價真的是約 0.1× 嗎？
業界慣例是快取命中倍率約為基礎輸入價格的十分之一，各家供應商的文件都一致記錄。它只在 byte 穩定的 prefix 上適用——這就是為什麼快取 Key 紀律是每個長上下文部署中隱藏的成本槓桿。
哪些供應商提供 1M token 的視窗？
目前這一代中有 Gemini（2M 等級）、Claude（1M）、Kimi K3（1M，開放旗艦）與 DeepSeek V4 Pro（1M 上下文）——目前可用性請以上面連結的模型目錄為準，透過一個 endpoint 查詢。
我什麼時候該用完整上下文而不是檢索？
當問題是一次性的深度閱讀、而檢索會漏掉時——合約審查、單一文件分析、全語料推理——而且查詢夠罕見，讓成本只是一次事件，而不是一種模式。所有會重複的事情，用快取或檢索。
總結
長上下文 LLM API 改變的是成本算式，不是物理定律：1M 視窗已是前沿模型的標準，差異化的關鍵現在是快取行為、深度處的 attention 品質，以及讓帳單保持理性的工作流程模式。整份語料的問題用 map-reduce、agent 用 compaction、串流用滑動視窗、正式環境用分層上下文——還有一個用數字取代「RAG 已死」辯論的三問題框架。視窗是一種能力；這些模式讓它變成預算。
這個決策框架本質上是一個試算表問題。立即取得你的 TokSpan API Key——$5 免費額度讓你測試這筆帳（快速上手）——然後在你自己的語料上，為三種做法各算一次價。