1M Token 是什麼？AI 大模型超長上下文視窗有什麼用？GPT、Claude、Gemini 上下文能力對比

先給結論：2026 年 9 月，GPT-5.5、Claude Opus 4.8 / Sonnet 4.6、Gemini 3.7 Flash 都把廣告窗寫到約 100 萬 token。1M Token 不是「能讀 100 萬漢字」，也不是「塞滿就等於會用」。標稱視窗三家差不多；有效檢索、最大輸出、價格臺階差很多。對處理 JSON 的人，正確用法是先裁、先校驗、再決定塞多少——不是把整份 dump 扔進去。

這篇按 2026 年 9 月 5 日寫。數字以各家公開檔案為準：OpenAI 的 gpt-5.5 API 約 1,050,000 token 總窗、128K 輸出；Anthropic 的 Opus 4.8 / Sonnet 4.6 預設 1M、128K 輸出、無長上下文加價；Google 的 gemini-3.7-flash 為 1,048,576 輸入 / 65,536 輸出。產品面（ChatGPT、Codex、claude.ai）往往更窄，別拿營銷頁當 API 限額。

1M Token 是什麼

Token 是模型計數和計費的最小文字塊，不是字、也不是詞。英文大約 1 token ≈ 0.75 個詞、約 4 個字元；中文常見 1–2 個漢字換 1 個 token，視分詞器和標點而定。JSON 更「貴」：括號、引號、重複的 key、縮排空格都佔額度。

1M Token = 約 100 萬個 token 的上下文視窗。粗換算：大約 75 萬英文詞，或約 50–80 萬漢字，或一本厚書到幾本中等書，或一箇中型程式碼倉庫加檔案。它不是「100 萬字小說」，也不是「100 萬行程式碼」——同樣 1M，散文、表格和壓縮過的 JSON 能裝下的資訊量差一截。

上下文視窗是一次請求裡能同時待著的總量：系統提示 + 歷史對話 + 工具定義 + 工具返回值 + 本次輸出。GPT-5 系還要把 reasoning token 算進去；你寫了 90 萬 token 的輸入，再開高推理，會先撞 context_length_exceeded，不是模型「讀不完」，是預算已經花光。

2023 年主流還是 4K–32K；2024 年 Gemini 1.5 把 1M 做成廣告詞；2025 年 200K 成為中檔標配。到 2026 年 9 月，旗艦 API 的廣告數字已經對齊到 1M，競爭從「誰更長」換成「誰在 200K 之後還能找得回針、誰的快取更便宜」。

超長上下文視窗有什麼用

超長窗解決的是一次推理裡要同時看見很多材料，不是替代資料庫，也不是免費無限記憶。下面這些場景，128K 往往要切塊或上 RAG；1M 可以把「先檢索再問」收成「先裝再問」——前提是你裝進去的東西經過篩選。

• 整倉 / 多檔案編碼：相關模組、測試、介面定義放在同一輪，少一次「模型沒看見那個檔案」。Agent 編碼的瓶頸仍常在工具迴圈和測試反饋，不在視窗廣告——上一篇《Gemini 3.8 Flash 與 AI Coding》寫過。
• 長檔案審閱：合同、財報、規範、多份 PDF 對照。適合「找出第 47 節和附錄 B 的衝突」，不適合「把一年郵件原樣貼進去再問摘要」。
• 多模態長輸入：Gemini 把影片、音訊、圖片和文字算進同一扇窗。一小時影片的 token 消耗會非常快，1M 是配額，不是邀請你無壓縮上傳。
• Agent 多步：工具返回的 JSON、錯誤棧、上一輪補丁可以暫時留在對話裡。視窗再大，堆疊原文也不該原樣回灌——見《Agent JSON 資料流》。
• 大 JSON 對照：OpenAPI / JSON Schema、樣例載荷、生產錯誤日誌放在一輪裡做欄位對齊。這是本站讀者最該用 1M 的地方，也是最容易把帳單打穿的地方。
• 少做一層 RAG：材料穩定、體積可控、每次都要引用原文時，整包進上下文比向量庫更簡單。材料每天變、重複查詢多，檢索仍然更便宜、更穩。

反過來說：聊天閒聊、單條分類、短 JSON 抽取，用 1M 窗是浪費。延遲、預填和按 token 計費都會罰你。短任務用短模型或短預算。

GPT、Claude、Gemini 對比

下表是 2026 年 9 月 5 日能寫進檔案的公開規格。價格按官方每百萬 token 標價；產品面限額另算。Gemini 3.8 Flash 截至本文仍未 GA，生產請繼續用 3.7。

怎麼讀這張表：三家旗艦都能「塞進約 1M」。差別在輸出頭寸、推理是否佔窗、超過 200K 貴不貴、快取打不打折。

• 要一次吐很長的結構化結果（大 JSON、長補丁、多檔案 diff）：GPT-5.5 和 Claude 4.6/4.8 的 128K 輸出比 Gemini 的約 64K 寬一倍。Gemini 更適合「讀很多、寫一張表」。
• 同一份系統提示 + 工具 Schema 反覆打：Claude 的 prompt cache、Gemini 的 Context Caching、OpenAI 的 cached input 都比每次付全價輸入划算。Agent 的 tools JSON 就該快取，見《Tool Calling 與 JSON Schema》。
• 預算緊、材料多、輸出短：Gemini 3.7 Flash 的 Intro 價仍是三家裡最便宜的 1M 檔；有效檢索過 200K 要自己用多針測，不要只信視窗數字。
• 產品面 ≠ API：ChatGPT / Codex 上的 GPT-5.5 可能是 400K；部分雲市場的 Claude 仍是 200K。寫 SLA 前開啟對應產品的模型卡，不要複製這篇的 API 列。

標稱視窗 vs 有效視窗

2026 年的共識已經很難再裝看不見：廣告 1M 和用好 1M 是兩件事。多針檢索（MRCR v2 一類：在超長文字里找若干條分散事實）上，準確率通常在 128K 之後開始掉，200K–512K 分化，接近 1M 時只有少數模型還像「讀過全文」。

公開評測和第三方彙編（設定並不完全統一，當趨勢看，不當驗收標準）大致是：

• GPT-5.5：相對前代，在 512K–1M 的多針推理上跳了一檔，是目前「真往滿窗塞」時最常被點名的 API 之一。單針找一句原文，三家在 128K 內都還行。
• Claude Opus 4.6：1M 多針曾到約 76%，曲線比較平。4.7 / 4.8 更偏校準——找不到就拒答或標明不確定，而不是編造位置。長檔案合規審閱往往更要後一種。
• Gemini 3.x：128K 內檢索和長檔案理解仍然強，過 200K 多針掉得更陡。適合「先讀一厚疊、再輸出短 JSON」，不適合「在 90 萬 token 的日誌裡保證找出第 8 根針」。

工程上可以按三檔用，而不是按價目表用：

「中間丟失」（lost in the middle）沒有因為視窗漲到 1M 就消失。重要約束放在系統提示開頭和使用者訊息末尾，中間塞附錄。模型更常記住你最後說的那句「只輸出符合 Schema 的 JSON」，而不是第 40 萬 token 處的一個列舉值。

和 JSON 的關係：塞進去不等於校驗過

1M 窗讓「整份 OpenAPI + 三天錯誤日誌 + 一份草稿 Schema」第一次能放進單次請求。它不會讓非法 JSON 變合法，也不會讓松 Schema 自動變嚴。視窗解決的是可見範圍；契約解決的是形狀。我們在《從 Prompt 到 Structured Output》《OpenAI vs Gemini Structured Output》裡寫過同一條紀律：生成階段用 Schema 擋非法 token，落地後再校驗一遍。

把 80 萬 token 的生產 dump 整包塞進去，常見失敗不是「視窗不夠」，而是：重複 key 浪費預算、中間欄位被忽略、模型在超長陣列裡數錯長度、輸出截在 64K/128K 上限、帳單按輸入全額跳。正確順序是裁 → 校驗 → 再喂。

{
  "name": "longContextPack",
  "description": "送進 1M 視窗之前的資料包：只放已校驗、已裁剪的 JSON",
  "parameters": {
    "type": "object",
    "additionalProperties": false,
    "properties": {
      "task": { "type": "string", "enum": ["align_fields", "diff_versions", "extract_errors"] },
      "schemaId": { "type": "string", "description": "穩定 Schema ID，不要貼整份巨型 schema 原文" },
      "focusPaths": {
        "type": "array",
        "minItems": 1,
        "maxItems": 32,
        "items": { "type": "string", "description": "JSONPath，例如 $.paths./v2/orders.post" }
      },
      "payload": { "type": "object", "description": "已經過語法校驗與體積裁剪的物件，不要塞原始日誌字串" },
      "tokenBudget": { "type": "integer", "minimum": 1000, "maximum": 1000000 }
    },
    "required": ["task", "schemaId", "focusPaths", "payload", "tokenBudget"]
  }
}

把這份包丟進 JSON 工具箱做本機語法校驗，用 JSONPath 抽出 focusPaths，再用 JSON Diff 對比兩個版本的 payload。模型看到的應該是裁過的物件，不是 20MB 的 .json 檔案原文。換 GPT / Claude / Gemini 只換模型字串，包的欄位名不該變。

現在該怎麼用

1. 先數 token，再決定塞：系統提示、工具 Schema、歷史、附件分開估。GPT-5.5 要把推理預留算進去；Gemini 要把影片 / PDF 頁數算進去。超預算就切，不要賭「應該還放得下」。
2. 重複字首走快取：System + tools 幾乎每次都一樣，就該 prompt cache / Context Caching。1M 窗的第一筆貴在輸入；快取命中後，長窗才變得可日常用。
3. 輸出用 Structured Output，不要寫「請輸出 JSON」：OpenAI 用 response_format.json_schema，Gemini 用 responseMimeType + responseJsonSchema，Claude 用工具或預填約束。視窗再長，松提示詞照樣會多一個欄位、少一個 required。
4. 超過你測過的有效帶，就檢索，不要硬塞：自己的多針沒過 256K，就別把 700K 日誌當全文理解。JSONPath 抽出錯誤碼和時間戳，比讓模型在海里游泳便宜。
5. 按輸出上限拆回答：Gemini 約 64K、GPT/Claude 約 128K。要一份 200K 的 JSON 報告，分片 + 每片 Schema，不要指望一輪寫完。
6. 本機夾具過了再打 API：同一份 payload 在瀏覽器裡跑 JSON 校驗 和 Diff。資料不上傳，和上線前對 REST 契約是同一思路。

常見問題 FAQ

總結

1M Token 是 2026 年旗艦 API 的對齊廣告：GPT-5.5、Claude 4.6/4.8、Gemini 3.7 都能把約 100 萬 token 寫進限額表。它的用處是一次推理裡同時看見整倉、長檔案或裁過的大 JSON，不是免費記憶，也不是「塞滿就理解」。有效窗往往在 128K–500K；滿 1M 當容量，不當理解力。輸出上限、推理是否佔窗、200K 之後貴不貴，才是選型欄位。

對開發者，作業不是追下一檔「2M」傳聞，而是把送進視窗的材料寫成能過 Schema 的包：JSONPath 裁路徑，Diff 對版本，校驗過再打 API。相關的 Structured Output 和 Tool Calling，本站已經寫過；這篇只補上下文視窗這一側的讀法。