Supermaven 的 100 萬 Token Babble 架構如何跳過 RAG 分塊延遲實現全專案行內補全

在程式碼行內補全（Inline Completion）的應用場景中，延遲決定了工具的實用價值。當開發者在編輯器中輸入程式碼或稍作停頓時，補全建議必須在 250 至 300 毫秒內出現在螢幕上，才能維持流暢的「心流」狀態。一旦等待時間拉長至 700 到 1,000 毫秒以上，AI 不再是思維的助力，反而會成為打斷專注力的瓶頸。

為了讓補全工具掌握多檔案專案的全貌，早期的 AI 程式碼輔助工具普遍採用檢索增強生成（RAG）。然而，傳統 RAG 架構存在著嚴重的權衡難題：向量檢索、語意評分與提示詞重組無可避免地帶來數百毫秒的延遲；而片段式的程式碼切塊，則頻繁切斷了跨檔案的型別定義、介面規格與共用輔助函式。

由 Tabnine 原作者 Jacob Jackson 創立的 Supermaven，透過專有的 Babble 神經網路架構與原生 100 萬 Token（1-Million-Token）上下文視窗，徹底突破了這項技術壁壘。它無需在每次鍵盤輸入時動態切片與檢索程式碼，而是將整個程式碼庫完整載入活躍上下文，以約 250 毫秒的極低延遲完成全專案感知的行內推論。

傳統 RAG 在程式碼補全中的核心限制

要理解 Supermaven 為何選擇自研模型架構，必須先檢視通用 RAG 流水線在即時程式設計場景下的根本瓶頸。

傳統基於 RAG 的補全引擎在每次觸發時，必須依序執行以下多個步驟：

[鍵盤輸入觸發]
       │
       ▼
1. 擷取局部上下文（游標前後文字、作用中檔案局部程式碼）
       │
       ▼
2. 向量與關鍵字檢索（計算 Embedding，於向量資料庫執行近似最近鄰搜尋）
       │
       ▼
3. 分塊篩選與排序（從索引檔案中選取關聯度最高的 Top-K 程式碼片段）
       │
       ▼
4. 組合提示詞（將檢索到的片段填入 4k–8k 的有限上下文視窗）
       │
       ▼
5. 大語言模型前向推論（生成行內補全）

在對話式介面中，額外等待 500 毫秒進行文件檢索通常難以察覺；但在每秒連續鍵入的行內自動補全中，這種多層調用架構會帶來顯著的延遲懲罰。

1. 多階段檢索引發的累計延遲

RAG 流程中的每個環節都需要運算時間。將目前編輯區塊轉換為向量、在包含數萬個程式碼塊的索引中搜尋相似項目，再對候選片段重新排序，整個過程通常耗時 100 到 400 毫秒。直到這段流程結束後，模型才能開始生成首個 Token。這正是傳統 Copilot 類工具端到端延遲通常落在 700 至 900 毫秒或更長的主因。

2. 程式碼切塊破壞了抽象語法樹與相依關聯

自然語言文件依 300 字切成段落通常不會遺失核心意旨，但原始碼本質上是高度相依的抽象語法樹（AST）與拓撲圖結構：

• service.ts 中的函式實作可能完全依賴 types.ts 定義的複雜泛型介面；
• routes.py 的路由處理邏輯受制於 config.py 中的全域設定字典；
• 跨目錄引用的公用巨集或工具函式，往往深藏於層級結構繁複的模組中。

一旦將程式碼庫依固定字元數切割成零散區塊，這些跨檔案的語意鏈結就會斷裂。如果 Embedding 模型在相似度檢索中未能匹配到其他目錄下的某個型別宣告，該定義便無法被送入提示詞，導致模型捏造不存在的方法名稱、產生不合法的型別，或是產出無法通過編譯的程式碼。

深入 Babble：Transformer 的擴展邊界與架構革新

繞過 RAG 的直覺方法是擴大上下文視窗，使整個專案能直接放入提示詞中。然而在標準 Transformer 架構下，這種做法在運算成本與推論速度上極不切實際。

標準自注意力機制的效能瓶頸

標準 Transformer 的多頭自注意力運算在全量提示詞讀取階段具有二次方複雜度（$O(N^2)$），且鍵值快取（KV Cache）的記憶體佔用會隨 Token 數量線性攀升。面對 100 萬 Token 的單次推論：

• 即使是參數量僅 8B 的標準 Transformer，單一開發者工作階段的 KV Cache 就需要佔用數十 GB 顯示記憶體；
• 每次敲擊鍵盤都對 100 萬 Token 重新進行注意力計算，推論時間將從亞秒級暴增至數十秒，徹底喪失即時補全的實用性。

Babble 架構的核心技術革新

Babble 是針對程式碼序列建模從零設計的專有神經網路架構，透過三大關鍵突破解決了 Transformer 的擴展瓶頸：

1. 次二次方長序列整合： Babble 採用了不同於密集全連接自注意力的序列建模機制（具備狀態空間或循環神經網路優勢），能夠在 100 萬 Token 的極長範圍內維持語意貫通，其運算與推論延遲僅相當於處理 4,000 Token 的標準 Transformer。
2. 極致輕量的狀態儲存： Babble 大幅降低了維護超長上下文所需的硬體記憶體佔用，免除了龐大 KV Cache 對顯示記憶體的消耗，使伺服器能夠以合理成本負擔高併發的即時推論。
3. 基於編輯序列（Edit Sequences）訓練： 多數程式碼模型以靜態檔案快照作為訓練資料，而 Babble 則直接在開發者編輯歷史與 git diff 變更軌跡上進行訓練。這讓模型不僅知道程式碼的最終結構，更能理解工程師在重構、重命名與增量迭代時的思維演進過程。

專案攝取流水線：Supermaven 達成 250ms 延遲的運作原理

Supermaven 之所以能在 100 萬 Token 的超長脈絡下維持亞秒級反應速度，關鍵在於將專案程式碼攝取與即時鍵盤推論徹底解耦：

[開啟專案工作區] ──► 10–20 秒單次背景預處理 ──► 於伺服端建立預計算上下文狀態快取
                                                                │
[開發者敲擊鍵盤] ───────────────────────────────────────────────┴──► 增量前向推論（≤ 250ms）

初始預計算階段

當工程師在 VS Code、JetBrains 或 Neovim 中開啟專案時，Supermaven 的本機客戶端會在背景非同步讀取整個工作區。在初始的 10 至 20 秒內，系統將全專案程式碼（上限可達 100 萬 Token）傳輸至專屬伺服架構，並建立預先計算好的上下文狀態快取（Prefix Caching）。

這個預計算過程完全在背景靜默運作，不會鎖定編輯器。處理完成後，模型便已透徹掌握了專案中的全部 API、資料結構定義與命名慣例。

按鍵級增量推論

當開發者開始在編輯器中鍵入字元時：

1. 完全跳過動態檢索： 不再需要產生 Embedding 向量，省去向量資料庫檢索與分塊過濾的所有網路與運算開銷。
2. 直接重複使用快取狀態： 推論引擎將作用中檔案的最新編輯差異與伺服端已快取的專案狀態進行對齊，僅針對少量新增的字元執行增量推論。
3. 即時輸出補全內容： 在評估按鍵輸入至建議呈現於螢幕上的畫面訊框測試中，Supermaven 始終維持在約 250 毫秒（15 個畫面訊框），大幅領先競爭方案：

實證評測：100 萬 Token 上下文是否具備真實效益？

在超長上下文模型中，常見的失效現象是「迷失在中間（Lost in the Middle）」：模型往往只對開頭與結尾的輸入具備高注意力，而遺忘中間的關鍵資訊；此外，過長的上下文也容易引入過多雜訊導致預測準確度降低。

Supermaven 透過多組量化測試，證明了 Babble 對 100 萬 Token 上下文的實際掌握度：

1. 針海測試（Needle in a Haystack）

在評測中，測試團隊將隨機產生的 8 字元鍵值對註解（例如 // needle: vhmpphtv => 'oualsoki'）隨機埋入長度介於 5 萬至 100 萬 Token 的專案程式碼中。

• 評測結果： 無論該標記深藏於全體內容的 10%、50% 還是 90% 位置，Babble 均實現了 100% 的精準召回。

2. 密集鍵值對檢索（Dense Retrieval）

相較於語意突兀的單點針海測試，密集檢索測試在長達 30 萬 Token 的連續程式碼中，插入了密集交錯的斷言邏輯：

assert obj['tvdiqaac'] == 'm'
assert obj['qacbblfk'] == 'c'
# 間隔數萬至數十萬個 Token...
assert obj['tvdiqaac'] == 'm'

當提示模型補全再次出現的鍵值時，Babble 在極遠的間隔跨度下依然維持了 75% 至 100% 的精確度，驗證了其長期維持結構化實體對應的能力。

3. 預測誤差與上下文長度曲線

為了檢驗龐大上下文是否真能改善實際工程專案的補全品質，Supermaven 在完整的 PyTorch 官方倉庫（平均取樣 200 種隨機檔案排列組合）上進行了預測損失測試。

• 評測發現： 隨著輸入上下文從數千 Token 擴充至 100 萬 Token，下一個 Token 的預測損失（Prediction Loss）呈現平滑且連續的下降趨勢。這證明 Babble 並未被專案中的非關鍵程式碼干擾，反而能將額外的背景知識轉化為更高的補全精準度。

架構對比：原生 100 萬上下文 vs 傳統 RAG 檢索

技術演進與產業影響

2024 年 11 月，Cursor 開發商 Anysphere 正式收購 Supermaven。Cursor 團隊深刻體會到，儘管頂級通用大模型在處理複雜的多檔案 Agent 任務上極為強大，但在高頻率、毫秒級的 Tab 行內補全上，必須仰賴專門調校的序列模型與極致最佳化的推論架構。

Supermaven 的核心技術與超低延遲長脈絡能力隨後被全面整合進 Cursor Tab，將 Cursor 既有的語法樹上下文分析與 Babble 的高速推論優勢融為一體。2025 年 11 月，Supermaven 宣布其獨立商業服務正式步入下線（Sunsetting）階段，為現有的 Neovim 與 JetBrains 使用者維持長期免費的補全服務，並引導 VS Code 使用者順暢遷移至 Cursor 生態系。

工程結論

Supermaven 的 Babble 架構為軟體工程與 AI 輔助開發確立了重要範例：對於延遲極度敏感的行內補全場景，原生超長上下文與輕量序列架構在體驗與準確度上顯著超越多層串接的 RAG 檢索方案。 它消除了程式碼切塊帶來的資訊斷層與向量搜尋的延遲負擔，讓面對大型專案的軟體工程師不再需要在跨檔案完整性與亞秒級推論速度之間妥協。

參考資料

• Introducing Supermaven, the first code completion tool with a 300,000-token context window
• Benchmarking Supermaven's Long-Context Capabilities
• Announcing Supermaven 1.0
• Supermaven joins Cursor
• Sunsetting Supermaven