大模型上下文視窗是什麼？token、失憶與128K到底多大
你跟 AI 聊到第二十來輪，它開始不聽話了。第二輪你就交代過「程式碼範例一律控制在三十行以內」，到第二十輪，它遞給你一段九十行的。你把規則重說一遍，它道歉、照辦，過一小時又犯。
模型不是變粗心了，它身上發生了一件最接近「遺忘」的事：大模型上下文視窗被塞滿了，你第二輪說的那條規則被悄悄擠了出去。搞懂這個機制，你對這類工具的用法會升一檔。這篇文章把上下文視窗是什麼、128K 換算成紙有多大、長對話為什麼會退化、廠商宣傳的數字怎麼讀，一次講清。
上下文視窗是什麼
上下文視窗（context window），指模型單次推理能處理的文字上限，計量單位是 token。它就是模型生成下一條回答時眼前能看到的一切。IBM 把它比作工作記憶：桌上攤著的東西它都能參考，不在桌上的，對它來說就不存在。
我覺得桌面這個比方更貼切，因為桌面能解釋後面所有的麻煩。把模型的上下文想成一張面積固定的桌子：你的問題、之前的對話、附帶的文件，全得同時攤在這張桌上。桌面不夠了怎麼辦？放新的之前，得先撤走一些舊的。沒有抽屜，沒有櫃子，只有這一張桌面。所以說大模型上下文視窗不是模型對你的記憶，而是這一次請求的桌面空間。
還有一個各家定義頁都一筆帶過、但很關鍵的細節：視窗是輸入和輸出共用的。你的提示詞、模型正在生成的回答，從同一個池子裡扣。
4K、128K 到底是多大
大模型上下文視窗按 token 計數。token 是模型閱讀文字的最小單位，通常是一個詞片，偶爾是整個詞。換算沒有固定匯率，但粗略數字夠用：一個英文單字約 1.3 個 token，一個漢字約 0.6 個 token。IBM 的研究者還發現分詞對語言並不公平：同一句話翻譯成泰盧固語，字元更少，token 消耗卻是英文的七倍。也就是說同樣的視窗，裝某些語言時裝的東西更少。
把這些行話換算成頁數，宣傳數字就誠實了：
| 視窗 | ≈ 英文字數 | ≈ 能裝什麼 |
|---|---|---|
| 2K | 1,500 | 一封長信往來（McKinsey 指出這是 GPT-3 的上限） |
| 8K | 6,000 | 一篇短論文或幾個程式碼檔案 |
| 32K | 24,000 | 一份帶附錄的白皮書 |
| 128K | 96,000 | 一本 200 頁的書 |
| 1M–2M | 75萬–150萬 | 1,500–3,000 頁，Gemini 的地盤 |
按中文算：一個漢字約 0.6 token，那麼 4K 視窗約裝 6,800 字，32K 約五萬字，128K 約二十一萬字，差不多一本長篇小說。表格第一行解釋了一大段歷史：GPT-3 出廠只有 2,048 token、約 1,500 英文字，裝不下一份保險計畫或供應商合約。現在看 8K 以下像史前時代，但直到 2023 年，整整一代圍繞大模型上下文視窗做文章的方案，就是為這一行而生的。
視窗裝的不只是你輸入的東西
看到「128K 上下文」，你大概以為是 96,000 字你的文件。實際桌面上坐著這些人：
| 占用者 | 是什麼 |
|---|---|
| 你目前的輸入 | 提示詞、貼上的文件 |
| 對話歷史 | 之前每一輪，每次請求都重發一遍 |
| 系統提示詞 | 廠商預置的隱藏指令，塑造模型行為 |
| 檢索資料 | RAG 流程為回答你現場查的文件 |
| 格式符號 | 特殊字元、換行、標記 |
| 模型的輸出 | 正在生成的回答，同一個池子裡扣 |
IBM 的文章是少數把這層說透的：系統提示詞和 RAG 檢索內容同樣占視窗。這就是為什麼標稱視窗用起來永遠沒有聽上去寬敞：等你看得見的部分上桌時，看不見的部分早就坐下了。
為什麼 AI 聊久了會「失憶」
現在解開開頭那個第二十輪的謎。聊天 API 是無狀態的：伺服器不記得你們的對話，每一輪，用戶端都把完整歷史重發一遍：你的訊息、模型的回答，全部，再加上新訊息。講 DeepSeek API 的實務文章把這件事講得最直白，程式碼都在：第二輪的請求裡原樣裝著第一輪的問和答。
於是每聊一輪，桌面就滿一分。等總量終於超過大模型上下文視窗，廠商的工程策略就上場了：上下文截斷。系統只保留最近 N 個 token，最早的內容被靜默丟棄。你看不到任何報錯——你看到的是一個照樣對答如流、但已經忘了五十輪前承諾過什麼的模型。這不是模型記錯了，是那些內容根本不在桌上了。
騰訊雲開發者社群有個實驗把這個失敗模式演示得很乾淨：給一個 4,096 token 視窗的模型餵 5,000 token 的產品說明書，最前面約 900 token 被切掉——「核心功能」一節在開頭，沒了；「售後政策」在結尾，活著。問核心功能，答非所問或者瞎猜；問售後政策，完美作答。同一份文件，命運完全相反，只取決於位置。
實際的應對都不性感：任務換了就新開一個會話；關鍵約束在最新一條訊息裡重說一遍，別指望第二輪；真正重要的參考資料放在最近的訊息裡。我自己的習慣是每到大節點交付前，把需求原文重新貼上一次，就當給可能已經掉下桌子的規則買份便宜保險。
標稱和有效：數字不等於數字
廠商規格和實際體驗在這裡分岔。一個大模型能裝下 128K token，不代表它能用好中間的部分。代表性研究是《Lost in the Middle》（Liu 等，2023）：模型對長輸入開頭和結尾的資訊利用得好，答案埋在中部時效能明顯下降。維基百科給這個現象起了個收編的名字——有效上下文長度（effective context length）：效能真正開始退化的位置，研究發現往往比標稱的大模型上下文視窗短。
廠商知道這件事，也在改善，Google DeepMind 2024 年報告新模型的長程一致性已有進步。但我的經驗法則是：工具明明「看過」某個資訊卻答錯時，先別罵模型笨，查一下那條事實是不是埋在文件中部。這也是為什麼有據可依的回答好過憑記憶硬答——檢索把桌上的東西變少了，這也是它能緩解 AI 幻覺的原因之一。
為什麼不把視窗無限做大
既然越大越好，為什麼沒有大模型廠商上線一億 token 的視窗？數學不允許。Transformer 的自注意力機制要讓每個 token 和其他所有 token 兩兩計算關係，計算量隨長度平方成長：token 翻倍，計算量翻四倍。社群工程師估算，128K 序列的注意力矩陣在 FP16 下需要約 65GB VRAM——8K 只要 262MB。長上下文還更慢（生成每個詞都要回頭參考前面全部內容）、更貴（按 token 計費，塞多少付多少），IBM 引 Anthropic 的研究還指出：視窗越長，越獄攻擊面越大。
解決方案是有的：稀疏注意力、滑動視窗、旋轉位置編碼，這些技術也是大模型視窗三年內從 4K 漲到百萬級的原因。但約束是真的，所以大模型上下文長度至今仍是發表會上的頭版參數，而不是一個「解決了的問題」。
2026 年主流視窗一覽，怎麼選
各家公開文件標註的視窗（標稱值，注意上面說的有效長度會打折扣）：
| 模型 | 標稱視窗 |
|---|---|
| OpenAI GPT-4o / o 系 | 128K |
| Anthropic Claude | 標準 200K（企業版 500K） |
| Google Gemini | 1M–2M |
| Meta Llama 3.1+ | 128K |
| DeepSeek | 64K |
| Mistral Large | 128K |
選型口徑：日常聊天、單檔案問答，8–32K 綽綽有餘；整份合約、論文、程式碼倉庫子目錄，要 128K 以上；整本書、跨文件批量分析，是百萬級視窗的地盤。如果你主要衝著大視窗選模型，先停一下：對大規模私有知識庫，用檢索（RAG）配一個中等視窗，通常勝過把所有東西塞進上下文——更便宜、可溯源，還不怕文件中部盲區。說到底，大模型上下文視窗決定模型一次能看多少，檢索決定什麼值得看。
常見問題快答
大模型上下文視窗一句話是什麼？ 模型單次請求能考慮的最大文字量，就是它這一輪交換的工作桌面，輸入輸出算在一起。
模型的輸出也算視窗嗎？ 算。輸入輸出同一個池子：64K 視窗、8K 最大輸出的模型，留給你的輸入上限是 56K。
為什麼 AI 會忘了我之前說的話？ 每輪都重發完整歷史，超窗後最早的內容被靜默截斷。關鍵約束要在最新訊息裡重說。
大模型上下文視窗越大越好嗎？ 不是。除了更貴更慢，有效長度往往低於標稱值，實測中部資訊的效能會下降。大規模文件場景，RAG 配合理視窗通常更優。
哪個大模型視窗最大？ 截至 2026 年，Google Gemini 系標稱最高 1M–2M token（約 1,500–3,000 頁）；Kimi 等也在百萬級競爭。這些數字每季都在變，用前查最新文件。
下次發表會再吹 token 數，你知道大模型上下文視窗的數字實際買到的是什麼了：桌面面積，按滿寬宣傳，而桌面中部的東西仍然容易漏看。按你自己的文件量去選模型——等材料多到任何桌子都攤不下，就是檢索該上場的時候了。