TTT-E2E 值得注意的地方，不在於它把 context window 再拉長一次，而在於它試圖改寫模型面對長文本時的工作方式。它不再要求模型把每一個已讀 token 都留在可隨時查閱的快取裡，而是讓模型在讀取內容的同時，透過 next-token prediction 持續調整一部分權重。
這個方向仍屬研究階段，也還沒有證明能取代現有長上下文模型或 RAG。但它提出了一個更根本的問題：面對長文件、程式碼庫與持續累積的 Agent 任務，我們真的只需要更大的窗口，還是需要一種會隨上下文改變的模型？
重點快讀
- TTT-E2E 把長上下文視為持續學習問題，而不是單靠注意力架構擴張的問題。
- 它以滑動視窗注意力為基底，在測試階段透過 next-token prediction 更新部分 MLP 層。
- Full attention 的優勢是能直接檢索過往內容，但成本會隨 context 增長；TTT-E2E 嘗試以壓縮換取較穩定的單位處理成本。
- 論文目前主要實驗到 128K context，不應把它寫成已經解決百萬 token 記憶的通用方案。
- TTT-E2E 不是 RAG 的替代品。它較接近提升長文本理解與局部適應能力；RAG 仍適合精準查找、引用與版本可追溯的任務。
背景與核心脈絡
長上下文模型經常被當成「記憶力更好」的代名詞，但這個說法只對了一半。
Transformer 在處理長文本時，通常透過 attention 與 KV Cache 保留先前 token 的資訊。這讓模型有機會回頭讀取很早以前出現的細節，但代價是：內容越長，每新增一個 token 時需要檢視的既有內容也越多。對 full attention 而言，prefill 的計算成本會隨序列長度快速升高，而後續生成每個 token 的成本也會受到已讀 context 影響。
這種架構適合需要精確回看原文的任務，例如從長合約找特定條款、從報告定位數字，或核對某段程式碼的實際寫法。但它也讓長上下文成為一個越用越昂貴的能力。
TTT-E2E 的出發點，是不要把所有內容都當成必須原封不動保存的資料，而是嘗試在讀取時將可泛化的模式壓縮進模型的可調整部分。
長上下文的真正矛盾：記得越完整，成本越高
Full attention 的核心優勢，是可以直接對整段上下文中的 token 建立關係。模型需要某個細節時，可以回頭找到它，而不是只依賴已經壓縮過的摘要。
問題也正出在這裡。
當 context 從幾千 token 拉到數十萬 token，模型不是只多讀幾頁內容，而是必須管理大幅增加的注意力運算與 KV Cache。這會直接影響延遲、記憶體需求與推理成本。
因此，長上下文技術一直卡在兩種選擇之間：
- 保留更多原始內容，得到較好的細節存取能力，但成本持續增加。
- 用固定大小的狀態、滑動窗口或線性序列架構降低成本，但可能失去早期內容的重要訊號。
TTT-E2E 想做的，是在兩者之間找第三條路：模型不必保留所有細節，卻能透過測試階段的更新，把已讀內容轉成對後續預測有用的內部狀態。
TTT-E2E 怎麼運作：把閱讀變成一次短期學習
TTT 是 Test-Time Training 的縮寫。一般模型在訓練完成後，推理時的權重保持固定；TTT-E2E 則讓模型在面對當前輸入時，繼續使用 next-token prediction 做小幅更新。
它不是把整個模型重新訓練一遍。論文的實作中，注意力層、嵌入層與正規化層會保持固定，主要更新的是部分 MLP 層。這些被調整的層，成為暫時儲存當前上下文資訊的地方。
可以把它理解成兩種不同的閱讀方式。
Full attention 比較像是把整本書攤在桌上，每次回答問題都能翻回任何一頁。TTT-E2E 則更像是在閱讀過程中做筆記、形成理解，再用這些內化後的線索繼續往下讀。
前者擅長精準回查；後者想解決的是，當內容長到無法一直攤在桌上時，模型是否還能保持足夠好的理解能力。
它解決的是 decode 成本，不是讓輸入突然沒有成本
TTT-E2E 很容易被誤讀成「context 再長也不會變慢」。這不準確。
它的理論優勢在於：使用 full attention 時，prefill 對長序列的成本可視為平方成長，而 decode 每生成一個 token 時仍要掃過既有 context；TTT-E2E 則把 prefill 降為線性處理，並將後續 decode 做到不必隨 context 長度增加而擴張。
換句話說，模型仍然要讀完整份文件，也仍然要花時間把內容壓縮進可調整權重。差別是，當文件讀完後，它不需要像 full attention 一樣，讓每一次後續輸出都重新背負整段歷史的成本。
這也是論文中「延遲近似常數」真正指向的內容：在其實驗設定下，每千 token 的 prefill 延遲沒有隨 context 長度大幅上升，而不是整份 128K 文件能在和 8K 文件相同的總時間內讀完。
128K 的結果值得注意，但不該被寫成已經定論
研究團隊在 3B 模型、128K context 的實驗中，報告 TTT-E2E 的長上下文 loss scaling 能接近 full attention，並在 H100 的測試裡得到較低的 prefill 延遲。
這很重要，因為許多線性或固定狀態架構雖然很快，卻會在 context 拉長後失去效果。TTT-E2E 的價值，在於它試圖證明：模型可以不直接保存所有 token，仍從更長的輸入中持續獲益。
但這仍是特定模型大小、資料集與實驗條件下的結果。論文並沒有證明它已經適用於所有 instruction model、所有 Agent 工作流或所有需要高精度檢索的企業知識庫。
比較合理的判斷是：TTT-E2E 提供了一個值得持續觀察的長文本架構方向，而不是已經可以直接取代主流 Transformer 推理堆疊的通用答案。
RAG 不會因此消失，只是角色更清楚
看到「模型能把內容壓縮進權重」時，最常見的問題是：那 RAG 還有必要嗎？
答案是有，而且原因很實際。
RAG 的價值不只在替模型塞進更多文本，而在於它可以指出來源、限定檢索範圍、更新版本、保留原始證據，並讓回答能回到可驗證的文件位置。當任務需要回答「合約第幾條寫了什麼」、「最新 SOP 的哪一版有效」、「這個數字來自哪份報表」時，精準檢索仍然不可替代。
TTT-E2E 比較適合被理解成一種上下文適應能力：它可能讓模型在閱讀大量程式碼、長篇文件或持續任務紀錄後，建立更有用的內部理解。
RAG 則比較像外部檔案系統與查證工具。
一個更成熟的架構，很可能不是二選一，而是讓模型先用檢索取得可信資料，再用更好的長上下文機制理解資料之間的關係。
現實阻力：訓練端仍然很重
TTT-E2E 並沒有把成本消失，只是把部分難題移到訓練方式。
為了讓模型在測試時適應內容，訓練階段不能只把它當成靜態模型來最佳化。研究團隊使用 meta-learning，讓模型從訓練開始就學習如何在測試階段進行更新。
這會帶來更複雜的梯度計算，也讓目前實作的訓練延遲成為明顯限制。論文也提到，現有訓練流程無法直接使用某些高效 attention kernel，原因是它們尚未支援這類梯度的梯度運算。
這代表 TTT-E2E 的問題不只是「模型夠不夠聰明」，還包括訓練框架、硬體利用率與部署管線能否跟上。
對內容工作者與 AI Agent 使用者的實際意義
對多數使用者來說，TTT-E2E 不是今天就要導入的工具，而是一個值得調整預期的訊號。
未來評估長上下文模型時，不能只看它標示多少 token。更重要的問題包括：
- 它在長文件中是否真的能維持關鍵資訊的使用能力？
- 隨 context 增長，延遲與成本如何變化？
- 它能否精準回到來源，還是只留下壓縮後的印象？
- 它在程式碼、法務、研究資料或多輪 Agent 任務中，表現是否一致？
- 它是否能把長文本理解、外部檢索與可驗證引用整合成同一條工作流？
真正可用的長上下文能力，不會只是一個窗口數字。它必須同時處理理解、速度、查證與成本。
讀者常問
TTT-E2E 和一般長 context 模型差在哪裡？
一般長 context 模型主要把更多 token 保留在 attention 與 KV Cache 可讀取的範圍內；TTT-E2E 則會在測試階段更新部分模型層，把讀過的內容壓縮進暫時調整過的權重。兩者都能處理長輸入，但記憶機制與成本曲線不同。
TTT-E2E 會把我的文件永久寫進模型裡嗎？
以論文設定來說，測試階段更新是為當前輸入序列建立的適應狀態，不等於把使用者文件永久寫回公開基礎模型。實際產品是否保存、重用或隔離這些更新，仍取決於後續系統設計與資料治理方式。
它已經能處理百萬 token 了嗎？
不能把目前研究直接解讀成這個結論。論文的核心長上下文實驗主要到 128K，並未證明它在百萬 token、商用 Agent 或大規模企業工作流中已具備同樣效果。
TTT-E2E 會取代 RAG 嗎？
不太可能是單純取代關係。TTT-E2E 偏向提升模型對長文本的內部適應與理解；RAG 則適合精準找資料、保留來源與支援持續更新。對需要查證的任務，兩者更可能互補。
為什麼訓練 TTT-E2E 比推理更難？
因為模型不只要學會預測下一個 token，還要學會如何在測試階段更新自己。這涉及 meta-learning 與梯度的梯度，訓練流程較複雜，現有高效 attention 實作也未必能直接支援。
收尾
TTT-E2E 最值得注意的地方，不是它宣告長上下文競賽結束，而是它把問題重新命名。
我們過去一直問：模型的 context window 還能多大？
它改問：模型讀過的內容，究竟要被保存、檢索，還是被學習？
這兩個問題看似相近，實際上會導向完全不同的 LLM 架構、推理成本與產品設計。長上下文的下一步，可能不是讓模型看見更多，而是讓它知道哪些內容值得被內化，哪些內容必須保留為可回查的證據。
本文參考〈End-to-End Test-Time Training for Long Context〉論文與作者公開實驗說明。
發表迴響