編輯 | 伊風(fēng)

出品 | 51CTO技術(shù)棧（微信號(hào)：blog51cto）

深夜更新！Claude Sonnet 4 已經(jīng)支持百萬(wàn)級(jí)上下文窗口了！

這次升級(jí)，將上下文從原本的 20 萬(wàn) Token 一口氣提升 5 倍——百萬(wàn)上下文究竟有多大？相當(dāng)于一次性放進(jìn)整套《哈利·波特》全集。

換算到開發(fā)場(chǎng)景，就是可以一次處理 超過(guò) 75,000 行代碼的完整代碼庫(kù)，或幾十篇研究論文。

這次的更新毫不意外地被技術(shù)社區(qū)熱議。

圖片

目前，這一功能已在 Anthropic API 和 Amazon Bedrock 上已經(jīng)可用。更令人關(guān)注的是，部分 Claude Code Max 用戶已經(jīng)收到了郵件通知，預(yù)計(jì)新的上下文窗口上限正在灰度推廣中。

圖片

對(duì)比來(lái)看，OpenAI 最新發(fā)布的 GPT-5 API 支持 40 萬(wàn) Token 上下文，總體體驗(yàn)雖有爭(zhēng)議，但其編程能力升級(jí)與超低價(jià)格，被不少人視作打向 Anthropic 腹地的一記重拳。

有網(wǎng)友調(diào)侃，正是 GPT-5 的出現(xiàn)逼出了這次更新，否則 Claude 可能還不會(huì)這么快動(dòng)手。

圖片

隨著 Sonnet 4 升級(jí)完成，它正式躋身 百萬(wàn) Token 窗口俱樂(lè)部——這個(gè)陣營(yíng)中，除了它，還包括 Gemini 2.5 Pro / Flash、Qwen-Plus、Qwen-Flash 等在編程領(lǐng)域表現(xiàn)突出的選手。長(zhǎng)上下文之戰(zhàn)，已經(jīng)開打。

為什么 Claude 要用“加長(zhǎng)上下文”來(lái)迎戰(zhàn)？原因很直接——長(zhǎng)上下文對(duì)編碼體驗(yàn)的提升是立竿見(jiàn)影的。它讓開發(fā)者能在一次會(huì)話中處理更復(fù)雜、更龐大的任務(wù)，而百萬(wàn)級(jí)已是當(dāng)前的關(guān)鍵門檻。

此前，谷歌 DeepMind 長(zhǎng)上下文預(yù)訓(xùn)練聯(lián)合負(fù)責(zé)人Nikolay Savinov在播客中提醒：

在當(dāng)前百萬(wàn) token 上下文遠(yuǎn)還沒(méi)有達(dá)到完美之前，盲目追求更大規(guī)模的長(zhǎng)上下文意義不大。

接下來(lái)，我們就來(lái)拆解 Sonnet 4 的百萬(wàn)上下文細(xì)節(jié)，與 Gemini 的長(zhǎng)文本能力做對(duì)比，并分享如何在實(shí)際編碼中更高效地用好這一能力。

一、Claude Sonnet 4 百萬(wàn)上下文詳解：更長(zhǎng)了但也更貴了

根據(jù) Claude 技術(shù)報(bào)告，百萬(wàn)級(jí)上下文主要解鎖了三大核心場(chǎng)景：

1. 大規(guī)模代碼分析 一次性加載完整代碼庫(kù)，包括源碼文件、測(cè)試和文檔。Claude 能理解整體項(xiàng)目架構(gòu)，識(shí)別跨文件依賴，并在改進(jìn)建議中考慮到整個(gè)系統(tǒng)的設(shè)計(jì)。 
2. 文檔綜合分析 可處理法律合同、研究論文、技術(shù)規(guī)范等大規(guī)模文檔集，在保持全局上下文的同時(shí)，分析數(shù)百份文檔間的關(guān)聯(lián)與邏輯。 
3. 具備上下文記憶的智能體 構(gòu)建能在數(shù)百次工具調(diào)用和多步驟工作流中保持連貫性的智能體，可一次性加載完整 API 文檔、工具定義和交互歷史，不丟失上下文。

然而，這個(gè)“長(zhǎng)度飛躍”帶來(lái)了價(jià)格的同步攀升。對(duì)于超過(guò) 20 萬(wàn) Token 的請(qǐng)求，輸入費(fèi)用翻倍至 $6 / 百萬(wàn) Token，輸出費(fèi)用更是達(dá)到 $22.5 / 百萬(wàn) Token。

圖片

不少網(wǎng)友表示，本來(lái)看到百萬(wàn)上下文很激動(dòng)，但一看價(jià)格立刻冷靜下來(lái)：

“這一下操作得花我們 51 美元?！?/p>

“AI幻覺(jué)一次，我一個(gè)月工資沒(méi)了?！?/p>

圖片

圖片

至于是否值得為如此高昂的上下文窗口買單，社區(qū)爭(zhēng)議依然很大——即使給了更大的窗口，也未必真的能發(fā)揮出真正的價(jià)值。

二、爭(zhēng)議：百萬(wàn)token已經(jīng)超出模型注意力極限

盡管百萬(wàn)級(jí)上下文聽起來(lái)令人興奮，但開發(fā)者在實(shí)際應(yīng)用中或許會(huì)感到“貨不對(duì)板”——隨著會(huì)話長(zhǎng)度和上下文規(guī)模的增長(zhǎng)，模型常常難以保持連貫性。

有工程師指出，在自己的實(shí)際工作體驗(yàn)中：

看到一個(gè)新模型比上一個(gè)好一點(diǎn)并不有趣，價(jià)格才是王炸。除非能有評(píng)估數(shù)據(jù)證明 Sonnet 在百萬(wàn)級(jí)上下文下依然能穩(wěn)定保持上下文質(zhì)量，否則“加長(zhǎng)”未必意味著“更好”。

圖片

在 Reddit 上，也有不少用戶表達(dá)了類似觀點(diǎn)：

有報(bào)告稱，當(dāng)上下文長(zhǎng)度超過(guò) 30K Token 時(shí)，部分 LLM 的表現(xiàn)就會(huì)急劇下降，甚至直接“崩潰”。

圖片

這種現(xiàn)象反映出一個(gè)核心矛盾：上下文窗口的物理長(zhǎng)度并不等于模型的有效注意力范圍。在真實(shí)的長(zhǎng)文本或大代碼庫(kù)場(chǎng)景中，超過(guò)一定規(guī)模后，模型很可能無(wú)法在全局范圍內(nèi)平均分配注意力，從而導(dǎo)致性能下降。

模型生成的代碼可能會(huì)變得雜亂、邏輯跳脫，或者開始遺漏關(guān)鍵信息。

因此，Claude Sonnet 4 的百萬(wàn) Token 升級(jí)，雖然在技術(shù)規(guī)格上進(jìn)入了“超長(zhǎng)賽道”，但真實(shí)能力仍需要實(shí)測(cè)驗(yàn)證。

三、Sonnet 4 實(shí)測(cè)：處理百萬(wàn)代碼庫(kù)，與Gemini 2.5 Pro孰強(qiáng)孰弱？

外媒 Every 的 CEO Dan Shipper 提前獲得了 Sonnet 4 百萬(wàn)上下文的測(cè)試權(quán)限，并用自家內(nèi)容管理系統(tǒng)（CMS）的代碼庫(kù)進(jìn)行了實(shí)測(cè)。

測(cè)試方法很直接——他們將完整的 CMS 代碼庫(kù)（約 25 萬(wàn) Token 的 Ruby on Rails 代碼）配上 70 萬(wàn) Token 的填充代碼，總計(jì)湊滿 100 萬(wàn) Token，然后拋出 5 個(gè)問(wèn)題：

1.  訂閱系統(tǒng)如何運(yùn)作？ 
2.  數(shù)據(jù)庫(kù)中有哪些關(guān)系？ 
3.  用戶取消訂閱時(shí)會(huì)運(yùn)行哪些后臺(tái)任務(wù)？ 
4.  CMS 使用什么支付處理器？ 
5.  找到 FooBar 類并解釋其作用（陷阱題——實(shí)際并不存在） 

平均得分（0-100）與耗時(shí)：

• Claude Sonnet 4：74.6 分 / 36 秒 
• Gemini 2.5 Pro：89.7 分 / 39 秒 
• Gemini 2.5 Flash：91.7 分 / 39 秒

從結(jié)果來(lái)看，Claude 在速度和穩(wěn)定性（少幻覺(jué)）方面有優(yōu)勢(shì)，但在代碼分析的細(xì)節(jié)完整度上不如 Gemini。尤其是遇到復(fù)雜邏輯時(shí)，Gemini 給出的答案覆蓋面更廣，得分也明顯更高。

價(jià)格對(duì)比（輸入 Token 每百萬(wàn)計(jì)）

•  Claude（> 200K Token）：$6
•  Gemini Pro：$2.50
•  Gemini Flash：$0.30

綜合性能與價(jià)格來(lái)看，Claude Sonnet 4 的絕對(duì)表現(xiàn)不差，但性價(jià)比相較 Gemini 仍稍顯遜色。

不過(guò)，這個(gè)實(shí)測(cè)也在一定程度上回?fù)袅松衔牡馁|(zhì)疑：Claude Sonnet 4 和 Gemini 2.5 系列（Pro、Flash）在技術(shù)上都能穩(wěn)定加載并處理百萬(wàn) Token 級(jí)別的輸入，并且在完整運(yùn)行過(guò)程中沒(méi)有因?yàn)樯舷挛倪^(guò)大而直接崩潰。

遺憾的是，測(cè)試結(jié)果里并沒(méi)有展示具體題目的完整應(yīng)答，而且這些題目與真實(shí)生產(chǎn)環(huán)境仍有一定距離。

四、開發(fā)者如何用好長(zhǎng)上下文能力？

在百萬(wàn)級(jí)上下文的探索上，Gemini 是較早投入并積累經(jīng)驗(yàn)的大模型。

在找資料的過(guò)程中，小編發(fā)現(xiàn)了大神 Logan 與 DeepMind 上下文預(yù)訓(xùn)練負(fù)責(zé)人 Nikolay Savinov 的一次深度對(duì)談，主題正是——“深入解析長(zhǎng)上下文”。

對(duì)話從最硬核的技術(shù)視角，解答了開發(fā)者在真實(shí)使用中最關(guān)心的問(wèn)題。

比如，在實(shí)際交互中，問(wèn)題到底應(yīng)該放在上下文的前面，還是后面？

圖片

播客地址：

https://www.youtube.com/watch?v=NHMJ9mqKeMQ

答案是：放在后面。 

Savinov 解釋說(shuō)，如果想利用緩存降低成本，就必須把問(wèn)題放在末尾；如果放在開頭，每次請(qǐng)求都會(huì)導(dǎo)致緩存失效，模型必須從頭處理，既慢又貴。

除了這個(gè)“位置問(wèn)題”，Savinov 還給出了四條核心建議：

1.充分利用上下文緩存（Context Caching）

• 首次加載長(zhǎng)上下文成本高，但在相同上下文基礎(chǔ)上進(jìn)行的后續(xù)提問(wèn)可直接命中緩存，處理速度更快、成本可降至原來(lái)的約四分之一。
• 如果知識(shí)需要更新，應(yīng)將新增內(nèi)容追加到末尾，底層會(huì)匹配最長(zhǎng)公共前綴，只處理新增部分。

2.結(jié)合 RAG（檢索增強(qiáng)生成）

• 當(dāng)上下文達(dá)到數(shù)十億 token 時(shí)，RAG 是唯一可行方案。
• 即使規(guī)模較小，在需要跨多個(gè)關(guān)鍵信息檢索的任務(wù)中，RAG 也能提升準(zhǔn)確率。

3.精選上下文內(nèi)容

• 不要將長(zhǎng)上下文當(dāng)作“數(shù)據(jù)垃圾桶”。無(wú)關(guān)或干擾信息會(huì)與目標(biāo)信息爭(zhēng)奪模型的注意力，尤其在多關(guān)鍵信息檢索任務(wù)中，反而降低性能。

4.消除“權(quán)重內(nèi)”與“上下文內(nèi)”記憶沖突

• 模型會(huì)同時(shí)依賴權(quán)重中的固有知識(shí)與上下文中的新信息，兩者可能產(chǎn)生矛盾。解決方法是在提示中明確信息來(lái)源，例如加上“基于以上提供的信息……”，讓模型優(yōu)先依賴上下文知識(shí)。

最后，Savinov 也談到了長(zhǎng)上下文的發(fā)展趨勢(shì)：

•  在百萬(wàn)級(jí) Token 模型的質(zhì)量尚未完善前，盲目追求更大規(guī)模的上下文意義有限。 
•  隨著成本下降，千萬(wàn)級(jí) Token 上下文將很快成為標(biāo)準(zhǔn)配置，對(duì)編碼等場(chǎng)景將是革命性突破。

五、寫在最后

如今，模型的注意力瓶頸已經(jīng)追不上上下文長(zhǎng)度的擴(kuò)張速度。

因此，即便上下文窗口不斷變大，“上下文工程”在短期內(nèi)依然是必不可少的技能。

展望未來(lái)，如果 Savinov 預(yù)測(cè)的千萬(wàn)級(jí) Token 真成了標(biāo)配，長(zhǎng)上下文或?qū)⒁l(fā)開發(fā)模式的質(zhì)變：

模型可以真正“端到端”地接管整個(gè)代碼庫(kù)，從持續(xù)開發(fā)到重構(gòu)、調(diào)試全包攬，甚至變成團(tuán)隊(duì)的“常駐虛擬工程師”。

不過(guò)，長(zhǎng)上下文只是 AI 編碼能力躍升的一個(gè)維度。

模型架構(gòu)、推理鏈設(shè)計(jì)、工具集成、上下文管理等，都會(huì)共同決定最終體驗(yàn)。

問(wèn)題來(lái)了——

你愿意重金嘗試， Claude 的超長(zhǎng)上下文嗎？

參考鏈接：

1.https://news.ycombinator.com/item?id=44878147

2.https://www.anthropic.com/news/1m-context

3.https://every.to/vibe-check/vibe-check-claude-sonnet-4-now-has-a-1-million-token-context-window