【2026 最新】TokenGate 是什麼？四組保留預算，看懂 Prefill 加速與追問證據（新手白話篇）

你把一大份文件交給 AI，第一題很快就答出來；接著問「另一段提到的例外呢？」它還找得到嗎？TokenGate 要解決的是長文件開始作答前的讀取成本，但評估它，不能只盯著第一個答案出現得多快。

這篇寫給第一次接觸模型加速的讀者：先用白話拆開 Prefill、生成與保留預算，再學會設計四組對照，檢查追問是否仍有證據。概念段不需要程式背景；操作段供已有 NVIDIA CUDA 環境的人跟做。本文依 2026 年 10 月 29 日查閱的論文與原始碼整理，並未在 AlphaLab 執行模型推論；四組預算是評估設計，沒有填入自製跑分。

先說結論：快讀＝少做後段計算；可靠＝追問仍找得到證據

TokenGate 的記憶口訣：先略讀、挑重點、再深讀。 把模型想成多位接力審稿的人：前幾位先看完整資料，接著交出較少的重點，讓後面的審稿人深入處理。省下的是後段工作量；重點挑得好不好，要由任務成績回答。

• 保留預算 K 是「讓多少文件 token 繼續往上層走」，不是答案字數。
• 先比較同一套模型與適配器的全保留版本，再調低預算，才能看清剪枝的代價。
• 單輪答對、跨輪重用與重新讀原文，是三個不同問題，應分開記錄。

一、TokenGate 是什麼？先拆開五個零件

① Token：「文字的小積木」

Token 是模型處理文字的單位，可能是一個字、字的一部分或符號。不要把「100 token」直接換成「100 個中文字」。真正記錄時，使用同一個 tokenizer（把文字切成 token 的工具），保存切分後長度，才有共同尺標。

② Prefill：「先把題目讀進去」

在常見的自回歸 Transformer（以注意力處理序列的模型架構）中，Prefill 是處理輸入的階段，Decode 則接續產生答案。KV Cache 是模型暫存先前運算結果的筆記，讓後續生成重用；它不是原文檔案本身。可對照 Hugging Face 的快取說明，也可先讀站內的 Attention 與 QKV 圖解。

③ Gate：「受過訓練的篩選員」

TokenGate 在模型較早的層加入評分模組，替可剪枝的文件 token 評分，挑出前 K 個交給後面的層。這是模型內部的計算選擇，不是先請另一個聊天機器人寫摘要。論文的方法章節 以注意力中的評分權重，讓訓練訊號能影響選擇器。白話說，篩選員和接手閱讀的人要一起適應。

④ State：「允許挑選的文件區」

目前官方 API 用 {state} 標記可剪枝的文字；放在這個區域外的問題與指令會保留。max_kept_prefill_tokens 控制這個文件區的預算，而非整份提示的總長度。你應先畫出文件邊界，再調 K；把必要指令誤塞進文件區，會改變你以為自己在測的事情。

⑤ Checkpoint：「配好的一整套」

Checkpoint 是存下來的模型狀態。官方範例的載入器會讀取 gate 與配對適配器，基礎模型資訊來自 checkpoint 中繼資料。適配器可想成額外學到的一小套調整。換另一個基礎模型，已經是另一組實驗，不能把原本的結果直接搬過去。推論介面原始碼 可核對這些邊界。

二、為什麼「剪掉」不等於整個模型徹底忘記？

這個問題最容易被一句「內容被刪了」帶偏。TokenGate 的上層不會替被剪掉的原始位置建立 KV 項目；但前面已完成部分處理，留下的向量也可能帶著混合過的資訊。更關鍵的是，論文附錄 B 說明：預設情況下，gate 所在層及其下方仍保留完整輸入的 KV Cache。

因此，不能只看到某個詞未被選中，就判定模型一定答不出來；也不能因第一題答對，就推定所有細節仍可可靠取回。 正確判斷要把「哪一層保留什麼」和「第二題實際答得如何」一起看。這和 KV Cache 淘汰評估 相鄰，但這篇聚焦的是 Prefill 階段的學習式選擇。

另一個細節是問題放在哪裡。標準因果注意力讓某個位置看到自己與前面的文字；文件 token 的早期表示，不能先看到後面才出現的新問題。不要把「挑重點」想成它已預知每一個未來追問。你在評估紀錄裡，應保存完整提示順序，而不只保存問題文字。

三、TokenGate 四組保留預算：先建立公平對照

假設你要選一個閱讀預算，先別問「100 是不是最好」。請問「在我需要保留的證據下，哪個預算能達標？」以下四組沿用官方範例的設定；它們是工作表欄位，不是本篇跑出的成績。

第一步：「固定一套」，避免把微調收益當成剪枝收益

怕比較失真？先固定 checkpoint、原文、問題順序、生成長度、硬體與注意力後端。用 None 做全保留對照，再跑 2000、500、100。觀察答案是否改變，而不是每組換一套模型後只比較速度。若另測未適配的基礎模型，請獨立列為另一條基線。

這裡的公平有兩層：同一 checkpoint 的比較隔離保留預算；與一般微調模型的比較，才進一步檢查整套方法的收益。官方 README 的單輪示範是作者提供的觀察，不是獨立複驗，也不構成你自己的多輪聊天驗收。

第二步：「先跑原例」，確認你測的是什麼

已有 Python 3.10 以上、uv 與相容 CUDA PyTorch 的讀者，可以先開新資料夾，執行 git clone https://github.com/token-gate-llms/TokenGate.git，再 cd TokenGate，以 git checkout 6e51aac5be1bd84bfd747f43f3f67ed595072bc2 固定本篇核對版本。

接著執行 uv venv、uv pip install -e .，再以 uv run python examples/niah_demo.py --gate-attn flex --k 2000 500 100 --n 2 開始小樣本檢查。這個範例會另跑全保留組；Flex 路線避開自訂核心的建置步驟，仍需對應運算環境。首次載入會下載 checkpoint 與所需模型，先確認磁碟與記憶體空間。

對照 官方示範程式，你應看到各預算的答案成績、Prefill 計時與針句保留指標。先確認程式能完整結束，再談調參。 本篇未在 CUDA 執行這些指令；若只想理解原理，停在工作表設計即可，不必為了讀文章租 GPU。

第三步：「換題仍有證據」，再加入兩輪追問

準備一份自己有權使用的合成文件，放入三條互不相同的資訊，例如「會議在松林廳」「備用場地是海風廳」「改期須在週三前通知」。第一題問主場地，第二題問備用場地，第三題問通知期限；把標準答案另外存放，避免混入模型輸入。這是自訂測試設計，並非官方成績的延伸結果。

先做每題重讀完整原文的版本：三次請求都帶原文與當輪問題，使用相同 K。這能檢查不同問題下的品質，但每次重新 Prefill，不能稱為跨輪快取重用。再由已具備相關引擎接線的人，另測延續既有 KV 狀態的版本；請把兩條路線分開命名、分開計時。

如果快取重用路線失敗，另記一次回到原文的恢復測試：它是否找回正確句子？花了多久？不要把重新讀完才答對的成績，登記成「只靠舊快取就答對」。同樣地，把前一輪答案複製進新提示，也不等於重用前一輪的 KV。

第四步：「保存原句」，把答對與碰巧答對分開

每一題先要求短答案，再要求指出支持它的原句；評分時分別記錄答案正確、證據相符、引句是否確實存在。對「週三」這類細節，要預先定義可接受同義寫法，不能看到結果後才放寬規則。若答案對而引句錯，工作表保留這個差別。

同時保存 kept_pos，它是選中位置的紀錄，可協助回查文件哪些部分通過 gate。不過，原始碼中的針句指標偏向檢查答案詞彙保留，不等於完整語意證據都被保存。把關鍵句換位置、改成否定句或加入相似干擾句，再看結果是否穩定，比只測一條顯眼的針句更有資訊。

第五步：「記整段成本」，別只挑最快那次

先暖機，再固定重複次數，交錯執行四組預算，記中位數與較慢的尾端；第一次載入與編譯時間另列。out.prefill_s 是官方介面提供的 Prefill 計時，不等於使用者從按送出到讀完答案的總等待。完整任務還要加上生成、排隊與必要重讀。

峰值顯存也要寫清楚量測範圍。依 PyTorch CUDA 記憶體 API，可在每組前重設峰值統計，再讀取 tensor 配置的峰值；若包住整次生成，就命名為整次請求峰值，不冒稱 Prefill 專屬峰值。memory_allocated 與 memory_reserved 的口徑也要分開，OOM 則記為執行失敗，不能填零。

四、Prefix Cache 還有用嗎？先分開兩種省法

有它自己的用途。Prefix Cache（前綴快取）重用先前算過、且前綴相符的 KV；TokenGate 則減少後段要處理的文件 token。用生活比喻，前者是「同一頁不用重抄」，後者是「交給下一位的筆記變少」。vLLM 的官方說明 以重複長文件問答解釋前綴重用，但那是 vLLM 的功能說明，不是 TokenGate 相容性證明。

要評估兩者一起用，先保存後端、模型與適配器身分、提示 token、K、gate 設定與位置配置，再核對引擎真正使用的快取鍵。vLLM 的快取設計 把前序區塊與額外身分資訊納入雜湊；改了保留狀態後，不能只因原文一樣就自行宣告安全命中。

最實用的紀錄是：第一次冷讀多久、相同前綴暖讀多久、改問題後答對幾題，以及需要幾次回原文。若引擎沒有回報可核對的命中證據，這一欄寫「本次未驗證」，不要從變快就反推命中。進一步可讀 Agent Prefix Cache 驗證。

五、怎麼選預算？先訂品質線，再比整段等待

適合先評估的任務，是輸入長、答案可客觀核對，而且你能保留原文以便恢復的文件工作。要逐字引用、多處整合或頻繁換題的工作，先提高證據驗收強度。這是選測試的原則，不代表某一類工作必然成功或失敗。

先在工作表寫下你的品質線，例如「三個指定事實與各自原句都要正確」；通過的預算才進入成本比較。若較小 K 第一題很快、卻常常需要重讀，請比較三題加恢復的總時間。若全保留也答錯，先查模型、提示或題目，不要把問題全歸因於剪枝。

閱讀作者的加速報告，也採相同原則：看硬體、樣本、任務與比較基線，然後看品質點位。不同版本與不同測試不可直接互比；論文中的特定操作點，不能轉成每種文件與後端的固定加速倍率。

常見問題：八個先講答案的判讀

1. TokenGate 就是把原文先刪短嗎？

不是在入口直接刪文字。文件先經過早期層，再由 gate 選擇哪些位置繼續往上層走。原文檔案與模型內的計算狀態，應分開理解。

2. K＝100，整份提示就剩 100 token 嗎？

不一定。K 控制 state 文件區的保留預算，外部指令與問題另計；下層預設快取也有不同範圍。請保存分層配置。

3. 第二題一定會因剪枝漏答嗎？

不一定。早期層與保留向量仍可能帶有資訊；真正要驗收的是當輪答案與證據。不要由 token 是否留下，單獨推定最後成績。

4. 把完整原文再送一次，能算快取重用嗎？

不能光靠這個動作認定。它可能是重新計算，也可能由引擎重用部分前綴；要靠命中紀錄和實作路徑區分。

5. 官方範例答對，就可以用在我的長篇文件嗎？

還要另外測。針句檢索和跨段推理的需求不同；同一個 checkpoint 在新任務上的品質，需要新題目與標準答案。

6. 沒有 CUDA，也值得學嗎？

值得。你可以先做文件、問題、答案與評分工作表；實際模型推論留給已有合適硬體的環境。本篇不要求你另買運算資源。

7. 最小預算就是最便宜嗎？

不一定。多次追問、恢復原文與生成時間都會進入總成本；品質未達標的快速答案，也不算完成任務。

8. 我現在該先改模型還是先做測試？

先寫可判定的測試。固定三個問題、原句和通過條件，再評估方法。要把測試接成系統，可接著讀 Agent Harness 實作。

給新手的三個重點

• 先略讀、挑重點、再深讀，是計算路線；「所有細節都記得」是另一項待驗收能力。
• 四組預算使用同一套 checkpoint，並把每題重讀與延續快取分開。
• 保存原文、答案、引句、位置紀錄與總成本，才知道速度換來了什麼。