一個標稱一百萬的窗口，真正能用的只有四分之一：上下文長度是一套被設計出來的介面

規格表上寫一百萬，工程師的設定檔裡填三十五萬。這兩個數字之間的落差，是最近 V2EX 上一則討論串的核心：編程任務中，模型的上下文窗口開多大最合適。發文者把 2023 到 2026 年的論文、基準與工程部落格串成一條線，得出一組相當具體的結論。這則討論有意思的地方在於，它把一個看似純技術的參數問題，變成了一次介面設計的示範：窗口大小、輸出上限、壓縮觸發點，三者互相咬合，像一套排版系統裡的欄寬、行高與斷行規則。

標稱不等於有效：中間那段是被浪費的

先看最基礎的一組數據。Liu 等人在 2023 年的研究發現，模型對上下文開頭與結尾的資訊利用最好，落在中間位置的檢索準確率會下降三成以上，有時甚至不如乾脆不給這份文件。這就是後來被反覆引用的 lost in the middle 現象。窗口拉得越開，中間被浪費的區域就越大，把一百萬塞滿，有效資訊佔比反而更低。

到了 2025 年的 LongCodeBench，這個現象在編程任務上有了更直接的拐點。多數模型的準確率峯值落在 64K 到 128K 之間，之後單調下降。Claude 3.5 Sonnet 在 LongSWE Bench 上從 32K 的 29 分跌到 256K 的 3 分；Qwen2.5 從 512K 的 70.2 分跌到 1M 的 40 分。換句話說，一個標稱一百萬窗口的模型，真正幹活的好用區間，大約就在 32K 到 256K 之間。

工程圈把這類現象統稱為 context rot，上下文腐爛。NVIDIA 的 RULER 基準專門測聲稱長度與有效長度的差距，方法是跑一條長度掃描曲線，找準確率跌破閾值的拐點，那個拐點才是真正可用的窗口。NoLiMa 把字面匹配線索拿掉之後更狠，GPT-4o 從 1K 的 99.3 分跌到 32K 的 69.7 分。arXiv 上一篇編號 2512.02445 的論文則發現，標稱 1M 到 2M 的模型在 100K 處能力就嚴重退化，良性任務的掉幅超過五成。

這裡的設計課題很清楚：規格表上的那個數字是行銷介面，設定檔裡的那個數字才是工作介面。兩者之間需要一道翻譯，而這道翻譯目前只能由工程師自己做。

三個數字互相咬合：窗口、輸出、觸發點

發文者給出的配置建議，結構上像一份排版規範。工作窗口設在標稱值的四分之一到一半，標稱 1M 的模型取 250K 到 500K；但因為 LongCodeBench 顯示多數模型 256K 之後編程能力已經明顯退化，更保守的取值落在 256K 上下。發文者自己的調研最終選了 350K，一個偏寬鬆但留有餘量的選擇。

最大輸出是第二個數字。單輪編程輸出通常是一個補丁、一個檔案、一段重構程式碼加上工具呼叫參數。普通補丁佔 2K 到 8K，大型源檔或批量修改佔 8K 到 16K。超過 32K 的單輪輸出，實務上幾乎都是失控重複。所以建議 32K，極限 64K。輸出上限在這裡還兼任保險絲：模型一旦開始無意義複讀，會在上限處被截斷，而不是燒掉整段預算。

第三個數字是壓縮觸發點。主流編程工具的做法是從窗口裡扣除最大輸出作為緩衝，觸發點等於窗口減去最大輸出。以 350K 窗口配 70K 輸出為例，280K 開始壓縮，任何一輪的上下文加輸出都不會超窗，永遠不會被硬截斷。這是 Claude Code 系工具的標準做法，邏輯自洽。

但發文者保留了兩個意見。其一，280K 的觸發點偏深，多數模型的編程能力在 256K 後已經退化，280K 才觸發，等於允許上下文在退化區間裡跑上一段，如果工具支援，往 245K 到 260K 收會更穩。其二，壓縮本身會引入漂移，2026 年的研究指出遞歸摘要是漂移的機制，所以壓縴要少次而深，壓縮後把關鍵檔案與未完成事項原文回貼。

三個數字這樣咬合起來，就是一套完整的介面設計：窗口定容量，輸出定保險，觸發點定節奏。任何一個單獨調大，另外兩個都會跟著出問題。

快取失效，才是頻繁壓縮真正的帳單

討論串的最後一段算了一筆帳，這筆帳解開了一個直覺誤區。直覺上窗口越大越省事，壓縮越少越省錢。但主流 API 的 prompt caching 機制是：快取命中部分按約一成的價格計費，未命中部分全價。壓縮一旦發生，摘要後的新上下文對不上舊快取，下一輪請求必然快取失效，於是一次全價的 280K 輸入。一次壓縮的代價，大約是普通輪次的十倍以上。

頻繁壓縮費的從來不是摘要本身那幾千個 token，而是快取失效後那一整段全價輸入。這一點和我們先前在國產模型寫程式碼成本的討論裡觀察到的現象是同一個結構：AI 工具的成本從來不是一個標價，而是一套被快取、摘要與計費規則共同設計出來的介面，使用者以為在比較單價，實際上在比較的是自己讀不懂的計費版面。

從這個角度看，上下文窗口的「開多大」，本質上是一種成本結構的排版決策。窗口開太滿，能力退化；壓縮太頻繁，快取失效。工程師在這兩個懲罰之間找的平衡點，和設計師在欄寬與行數之間找的平衡點，是同一種工作。

把長度設計成介面

這則討論串真正值得留下的，是它示範了一種面對規格表的態度。標稱一百萬是廠商寫在封面上的字級，有效兩百五十六萬分之一才是內文真正可讀的欄寬，而工程師的設定檔，是這份文件的最終排版。基準測試在這裡扮演的角色，很像設計評審：RULER 測的是聲稱與實際的落差，LocoBench 補上了既有基準沒覆蓋的多會話開發與跨檔重構，Letta 的 Context Bench 用一千輪任務鏈暴露短會話測不出來的記憶失效。

模型命名與窗口標稱，其實是同一門品牌語言的兩面。我們先前看過DeepSeek 把旗艦退休設計成一次通知，那次的觀察重點是命名如何把資訊壓縮成可傳播的符號；這次的窗口數字則是把能力壓縮成一個行銷位數。兩者共同的地方在於，真正可用的那個數字，永遠藏在設定檔深處，留給願意跑長度掃描曲線的人自己找。

結論可以收得很具體：標稱一百萬的模型，工作窗口設三百五十萬分之一上下、最大輸出三十二 K、觸發點收到兩百五十萬分之一之前，是目前各項基準數據交集出來的一個穩妥解。而更重要的觀點是那個方法：不要相信封面字級，跑一條自己的掃描曲線，找到屬於你的任務的拐點。規格是廠商的介面，拐點才是你的。