教程
1M Token 是什麼？AI 大模型超長上下文窗口有什麼用？GPT、Claude、Gemini 對比
「100 萬 Token」不是更會聊天的代名詞。它是一次請求裏模型能同時看見的預算。預算變大，整倉、整本手冊、整段音視頻才進得去；輸出上限、計費檔和有效召回並不會自動跟着變大。
2026 年各家旗艦模型的宣傳頁幾乎都寫着 1M Token。產品文案把它說成「讀完整本書」「一次塞進整個代碼倉庫」，選型會卻經常卡在另一組數字：這次調用要花多少錢、輸出會不會被截斷、中間那 40 萬 Token 模型還記不記得。本文用工程口徑解釋 1M Token：它是上下文窗口的容量上限，不是理解力證書。讀完你可以估算自己的材料大概佔多少 Token，對照 GPT、Claude、Gemini 的窗口、輸出與加價規則，並決定哪些 JSON 該進窗口、哪些該先在瀏覽器裏校驗。
1M Token 是什麼：先把計量單位說清楚
Token 是模型讀寫文本的最小計費與計長單位。它不是字，也不是詞。英文裏一個常見詞往往略多於一個 Token；中文、代碼、JSON 鍵名、Base64 和空白縮進的換算都不一樣。同一段 OpenAPI 文檔，換一家模型、換一版分詞器，Token 數會漂。所以「1M Token」首先是該模型這次請求允許佔用的格子數，不是「一百萬個漢字」或「一百萬個英文單詞」。
| 窗口量級 | 直覺對照（只作數量級，不是承諾） |
|---|---|
| 1 Token | 英文大約 0.7–1 個詞；中文常常 1–2 個字；代碼和 JSON 更碎 |
| 8K–32K | 一篇長文、一份接口說明、一小段對話 |
| 128K–200K | 一本書的很大一部分，或中等倉庫加幾輪 Agent 軌跡 |
| 1M（約 100 萬–105 萬） | 厚手冊 + 多文件倉庫 + 長曆史的量級；Claude 新分詞器下同樣 1M 能裝的純文本往往更少 |
上下文窗口（context window）是一次請求裏輸入 + 輸出 + 推理/思考 Token（若單獨計量）共享的預算。系統提示、工具 Schema、檢索片段、多輪歷史、模型正在生成的答覆，都從同一口井裏打水。窗口寫成 1M，並不表示你能塞進 100 萬 Token 的倉庫，再指望它再寫出 12 萬 Token 的報告——輸出也佔窗口，而且各家還有單獨的 max output。
把 1M 理解成硬盤容量更合適：格子在，不保證隨機讀中間任意一頁都一樣準。針在乾草堆裏能找着，不代表多跳推理、跨文件對照、長 JSON 裏漏字段的檢查也能撐到標稱上限。選型時先問「這次要同時看見什麼」，再問「看見之後要穩定產出什麼形狀」。
超長上下文窗口真正能幹什麼
窗口從 128K 跳到 1M，改變的是你還要不要先切塊。以前必須檢索或摘要才能塞進去的材料，現在可以整包交給模型。真正賺到的場景通常長這樣：
- 整倉或大半個倉庫：跨文件追調用鏈、對比兩份實現、在一次請求裏同時看見接口定義和測試夾具。
- 長文檔與合同：政策手冊、審計底稿、多附件 PDF。問題依賴前後文同時在場，而不是單頁關鍵詞命中。
- 多模態大包：Gemini 一類接口可以把文本、圖、音視頻、PDF 算進同一窗口。數小時音頻或長視頻轉寫不再必須先切片。
- Agent 長軌跡：工具定義、多次 tool result、中間失敗重試都留在窗口裏，模型才能根據完整觀察選下一跳。循環本身見
- 對照與抽取：把兩版 OpenAPI、兩份導出 JSON、一份 Schema 放在同一請求裏做 diff 級閱讀，再按 Structured Output 吐出結構化差異。
這些場景有一個共同點：答案依賴同時看見多份材料。如果任務其實是「在十萬頁裏找一句原話」，先檢索往往更便宜、也更穩。1M 窗口的價值是減少錯誤切片，不是取消信息架構。
還有一類被高估的用法：把整站日誌、整庫 dump、未脫敏的生產 JSON 直接貼進提示詞。窗口夠大，泄露面和賬單也一起變大。能進窗口的，應當是你已經決定可以離開本機的那一份。敏感字段先在本地抹掉，形狀不對的 JSON 先修，再談「一次喂進去」。
標稱窗口 ≠ 有效窗口：輸入、輸出、計費
產品頁上的 1M 是受理上限：超過就拒請求或截斷。它不是「在 100 萬 Token 處推理質量仍等於 8K」。RULER 一類評測裏，有效長度常常只有標稱的一半上下；用戶側更常見的體驗是過了 200K–500K，跨文件對照開始漏，中間指令被忘掉。工程上應把標稱窗口當天花板，把你自己的迴歸集當有效窗口。
第二組被忽略的數字是最大輸出。GPT-5.6 Sol / Terra 與 Claude 旗艦同步請求大約 128K；Gemini 3.1 Pro 文檔寫的是 65,536，且默認 maxOutputTokens 往往更小，不顯式調高就會靜默截斷。讀完整本手冊再「寫一份同等篇幅的新規範」，窗口夠，輸出不一定夠。下面這份預算把輸出和餘量寫成一等公民，而不是塞完再看：
{
"window": 1050000,
"budget": {
"system": 2400,
"tools": 1800,
"repoPack": 420000,
"docs": 180000,
"history": 80000,
"reservedOutput": 128000,
"headroom": 238800
},
"rule": "never fill to the sticker; reserve output plus 20 percent headroom"
}第三組數字是錢。OpenAI 對 GPT-5.6 Sol / Terra 寫明：輸入超過約 272K Token 時，整單按 2 倍輸入、1.5 倍輸出計價。Gemini 長上下文常見另一檔加價（文檔多以超過 128K 或 200K 爲界，下單前核對當前價表）。Claude Sonnet 5 文檔把 1M 寫成默認窗口、按標準價計，沒有單獨的「開長上下文」開關——但分詞器更碎，同一段字可能變成更多 Token，等效成本照樣升。Prompt cache 能救重複前綴，救不了每次都換的大包。
2026 對比：GPT、Claude、Gemini
下表按 2026 年 9 月各家公開模型卡歸納旗艦檔，不把「全家所有快照」寫進同一格。數字會變，下單以官方頁爲準；對比的是選型時真正分叉的軸：窗口、輸出、加價、模態。
| 維度 | GPT-5.6 Sol / Terra | Claude Sonnet 5 / Opus 5 | Gemini 3.1 Pro |
|---|---|---|---|
| 上下文窗口 | 1,050,000 | 1,000,000（Haiku 4.5 仍爲 200K） | 1,048,576 |
| 最大輸出 | 128,000 | 128,000（Batch 另有更高檔） | 65,536（默認值往往更低） |
| 長上下文計費 | 輸入 >272K：整單 2× 輸入 / 1.5× 輸出 | 文檔稱 1M 爲默認、無單獨加價檔；新分詞器更碎 | 常見超過 128K 或 200K 加價，以官方價表爲準 |
| 輸入模態 | 文本、圖像 | 文本、圖像（PDF 等走平臺能力） | 文本、圖像、音頻、視頻、PDF |
| 同系列注意 | Luna 窗口約 400K，別把 alias 當成同一容量 | 同一 1M，新分詞器能裝的純文本更少，需重新計數 | 多模態最寬；輸出天花板更矮，長文生成先算輸出 |
| 更適合 | 長報告、Responses 工具鏈、要 128K 輸出的任務 | 長文檔推理、Agent 循環、要穩定讀完材料再作答 | 整倉 + 音視頻/PDF 一次喂入，最終答覆較短或走 Schema |
官方出處請直接看模型卡，不要只記第三方彙總表：OpenAI 的 GPT-5.6 Sol 寫明 1,050,000 窗口、128K 輸出與 272K 加價線；Anthropic 的 Claude Sonnet 5 概覽 把 1M / 128K 寫成默認；Google 的 Gemini 3.1 Pro Preview 寫 1,048,576 輸入與 65,536 輸出。價表和快照名會改，集成代碼應讀 usage 字段，而不是寫死去年的常數。
怎麼選，取決於瓶頸在哪。要一次吐出接近十萬 Token 的遷移說明或長 JSON 數組，輸出上限比窗口更要緊，GPT 與 Claude 旗艦更寬。要在同一次請求裏聽完會議錄音再對照設計稿和倉庫，Gemini 的模態是真實差異，不是營銷形容詞。要在 1M 裏做多跳修改且中間指令不能丟，別隻看標稱——用你自己的「三處針、兩處矛盾」迴歸集量有效召回，而不是隻跑一次 needle-in-a-haystack。
三家都支持工具調用和 Structured Output，但外殼字段不同，最終 JSON 仍要本地校驗。Gemini 一側「只要 JSON」和「按 Schema 吐字段」的開關，見站內 Gemini API JSON 輸出教程，本文不重複 SDK。
什麼時候該塞滿，什麼時候該檢索
1M 窗口沒有取消 RAG，它只是把「切塊邊界」往後推。決策可以壓成四條：
- 答案必須同時看見 A 和 B（兩份規格、調用方和被調用方、Schema 和實例）→ 優先進同一窗口，不要各切各的摘要。
- 答案是「在很大語料裏定位一小段」→ 先檢索再把命中段 + 元數據送進窗口，別爲了省檢索管道付 272K 加價。
- 材料每次請求都變（新 diff、新導出）→ 長上下文很貴；能緩存的前綴（系統提示、工具清單、穩定手冊）與易變包分開。
- 材料不能離開瀏覽器（密鑰、生產用戶字段）→ 窗口再大也不該上傳。本地清洗、校驗、抽樣之後，再決定是否進雲端模型。
Agent 循環尤其容易把窗口吃滿：每一步 tool result 都留下。maxSteps 之前就該摘要舊觀察，而不是指望 1M 當無限日誌。工作原理見 AI Agent 是什麼。
即便決定「整包進窗口」，也要打包，不要把 node_modules 和壓縮產物算進 1M。一份顯式的 context pack 比「把倉庫拖進去」可審計：
{
"pack": "context",
"files": [
{ "path": "openapi.json", "tokens": 12000, "role": "contract" },
{ "path": "schema.ticket.json", "tokens": 400, "role": "outputShape" },
{ "path": "fixture.valid.json", "tokens": 800, "role": "example" }
],
"omit": ["node_modules", "*.lock", "generated/**", "minified bundles"]
}pack 裏的 outputShape 應來自你真正會 parse 的那份 Schema，而不是模型自由發揮的鍵名。形狀約束見 AI Structured Output。
長上下文裏的 JSON：先本地校驗再喂模型
超長窗口放大的是壞輸入的殺傷半徑。一份缺逗號的導出、一份 extra 字段瘋長的工具回執、兩份同名不同義的 Schema，塞進 40 萬 Token 之後，你很難用肉眼定位。模型會順着壞 JSON 繼續編，賬單照付。所以長上下文工作流應在上傳前固定三步：
- Parse：確認每一份要進窗口的文件是合法 JSON / JSON5，而不是「看起來像」的日誌或截斷導出。
- Schema：對照你打算讓模型遵守的那份契約；多文件時先確認它們是否還同源。
- Diff：新舊夾具、模型 arguments 與下游 body、兩版 OpenAPI 先在本地看出差異，再問模型「爲什麼」或「怎麼改」。
在瀏覽器裏即可做完，數據不用先上傳：JSON 格式化看 parse 與結構；JSON Schema 校驗釘字段和枚舉；JSON Diff對比兩份將要同時進窗口的材料。校驗失敗的文件不要進 pack。
模型吐出的長 JSON 仍可能語法壞或形狀漂，分層見 AI 生成 JSON 錯誤指南。Agent 工具 arguments 與最終答覆是兩份契約，不要共用一個窗口預算當「已經校驗過」。
常見問題 FAQ
1M Token 等於一百萬個漢字嗎？
不等於。Token 是分詞器切出來的片段。中文、英文、代碼、JSON、圖片和音頻的換算都不同；同一家廠商換一版分詞器，同樣 1M 能裝的字數也會變。要知道自己的材料佔多少，用該模型的計數接口量，不要用「頁數 × 經驗係數」代替。
窗口都是 1M，是不是選哪家都一樣？
不一樣。輸出上限、長上下文加價、模態、有效召回差得很遠。GPT-5.6 的 272K 加價線、Gemini 更矮的輸出天花板、Claude 新分詞器更碎，都會讓「同樣 1M」變成不同賬單和不同截斷點。用你的迴歸集測，不要只對標稱窗口。
有了 1M 窗口，還需要 RAG 嗎？
需要。1M 適合必須同時看見的那一包材料。語料遠大於窗口、或每次只有一小段相關時，檢索仍然更便宜、權限更好控、也更好更新。很多生產系統是「檢索圈出候選 + 長窗口精讀」，不是二選一。
爲什麼把整個 JSON 倉庫塞進去，模型還是漏字段？
窗口負責「看得見」，不負責「按契約說話」。漏字段、類型漂、markdown 包一層，是形狀問題，要用 Structured Output / Schema，並在本地再校驗。材料在中間被稀釋時，有效召回也會掉——先保證進窗口的是合法、同源、已 diff 過的 JSON。
總結與下一步
1M Token 是 2026 年旗艦模型的共同量級：一次請求大約能同時看見一百萬個 Token。它讓整倉、整本手冊、多模態大包變得可行，但不自動等於更強推理、更長輸出或更低單價。GPT、Claude、Gemini 的分叉在輸出上限、加價線和模態，不在「有沒有 1M」這一個複選框。
下一步：用官方計數器量你的手冊和倉庫；按本文預算表預留輸出與餘量；對照三家模型卡覈對加價閾值。要進窗口的 JSON，先在 JSONVue 做 parse、Schema 和 Diff。形狀怎麼釘死讀 Structured Output，失敗怎麼分層讀 JSON 錯誤指南。