【2026 最新】Random Attention 是什麼？動手做 KV Cache 隨機淘汰評測

同一個 Random Attention，為什麼論文在 H200／vLLM 報告更高吞吐，第三方在 Apple M4 卻量到比 dense cache 慢？兩組結果其實沒有互相推翻：前者測長輸出、多請求的 serving stack，後者測單筆、短輸出的 Python／PyTorch adapter。真正要驗證的不是一句「隨機比較快」，而是保留規則、模型品質與系統吞吐三件不同的事。

這篇會先用一條公式拆開 Random Attention，再帶你寫出可執行的 KV Cache 隨機淘汰核心，最後建立 dense 對 random 的受控評測：固定模型 revision、cache budget、題組與 seed，同時記 task accuracy、TTFT、decode throughput、峰值記憶體與變異。你也會知道何時該用最小 Transformers adapter，何時必須換到 vLLM serving harness。

證據邊界：AlphaLab 在 Python 3.12.13 執行了 randkv 的 10 個 dependency-free policy 單元測試，全部通過；目前環境沒有 torch、Transformers 或 vLLM，因此沒有執行模型品質或速度跑分。下文數字會明確標示來自論文或第三方原始紀錄，不把操作流程寫成本站跑分結果。

一句話重點：Random Attention ＝ Prompt 全保留 ＋ 每個 KV head 各自隨機保留舊生成 token ＋ 最近 r 個 token 暫緩淘汰。

先說結論：Random Attention 沒有通用的加速倍率

值得研究，但不能把 32–43% 貼到所有電腦上。原論文的這個區間，是同一套 H200／vLLM 長序列服務裡，Random 相對 TriAttention 的吞吐增幅，不是相對 dense、不是筆電單請求，也不是所有模型都保證如此。第三方 randkv 在 M4 的 0.9208 倍則只隔離目前 adapter overhead，沒有評模型品質。兩者回答不同問題。

• 想理解方法：先跑純 Python policy，確認 prompt、recent window、每頭獨立抽樣與順序不變。
• 想判斷答案是否壞掉：固定題組與解碼參數，用多個 seed 報平均、離散程度與逐題配對差異。
• 想判斷是否更快：把 TTFT、每 token 延遲、總吞吐、併發與峰值記憶體分開，並在同一 backend 比較。

若你還不熟悉 KV Cache，可先讀大型語言模型運作原理與下一個 token 預測器；這會讓後面的「邏輯位置」與「實體 cache 長度」比較直覺。

Random Attention 怎麼運作？先抓住 K、r 與 KV head

模型生成每個 token 時，各層的 key／value 會累積在 KV Cache，避免每一步都重算過去。Dense cache 全留，記憶體隨序列增長；Random Attention 則把可保留位置壓到固定預算。論文演算法會為每一層、每個 KV head 獨立產生隨機分數，prompt 位置設為無限大，最近 r 個位置暫不參加淘汰，其餘舊生成位置只留下能填滿持久預算 K 的樣本。

最容易寫錯的是把 compact 後的陣列索引當成原始 token 位置。RoPE 與 attention mask 需要的是絕對邏輯位置，而 K/V tensor 只剩實體保留位置；兩者必須分開追蹤。可把它想成書的原頁碼不變，只是影印本抽掉部分頁面。這也是第三方 randkv adapter 額外維護 absolute position 的原因。

什麼情境值得用？先看輸出長度與失敗代價

Random Attention 的合理候選是長 reasoning 輸出、KV 記憶體成為瓶頸、prompt 能完整放進預算的工作，例如大量數學推理 rollouts 或程式題生成。這正是原始預印本測試的核心範圍：Qwen3 與 Phi-4-reasoning、最長 32k 生成，以及 MATH、GPQA、AIME、HMMT、LiveCodeBench 等 reasoning 任務。若你的服務可因較小 KV Cache 增加 resident sequences，壓縮才可能在系統層轉成總吞吐。

相反地，long-input／short-output、一次只跑一筆、prompt 已接近 K、或必須精準找回很早以前唯一出現的帳號／passcode，都不是直接套用的好情境。論文的 57 輪壓縮 passcode 測試裡，Random retrieval 為零，已經提供明確反例。先用Transformers KV Cache 文件確認模型的 cache 類型；若是 sliding、chunked 或 linear attention，也不能假設首版 randkv adapter 相容。

截至 2026 年 9 月 7 日，這仍是 arXiv v1 預印本。社群追問未納入的 learned-retention 方法時，作者公開回覆其訓練式保留與本文 inference-time selector 範圍互補，資源允許才會補實證比較。因此本文把「selection signal 幾乎沒用」視為待擴大檢驗的假說，不當成已證明定律。

步驟一：用 30 行 Python 重做隨機淘汰核心

先不碰模型與 GPU。下面只輸入目前的絕對位置，回傳單一 KV head 應保留的位置；K 是包含 prompt 的持久預算，r 是另加的最近窗口。正式程式還要把 request、eviction round、layer 與 head 都放進 seed，避免不同請求共用可變 RNG。

from hashlib import blake2b
from random import Random

def stable_seed(base, request, event, layer, head):
    key = f"{base}|{request}|{event}|{layer}|{head}".encode()
    return int.from_bytes(blake2b(key, digest_size=8).digest())

def keep_positions(pos, prompt_len, K=2048, r=64, seed=0):
    pos = list(pos)
    if prompt_len > K:
        raise ValueError("prompt 已超過持久預算 K")
    prompt = [p for p in pos if p < prompt_len]
    if len(prompt) != prompt_len:
        raise ValueError("cache 已遺失受保護的 prompt 位置")
    if len(pos) <= K + r:
        return pos

    recent = pos[-r:]
    blocked = set(prompt) | set(recent)
    older_generated = [p for p in pos if p not in blocked]
    old_slots = K - len(prompt)
    picked = Random(seed).sample(older_generated, old_slots)
    return sorted(prompt + picked + recent)

# 每個 layer／head 都用不同穩定 seed
seed = stable_seed(42, "req-17", 0, layer=3, head=5)
kept = keep_positions(range(5000), 128, K=2048, r=64, seed=seed)

先寫四個斷言：prompt 一個不少、最近 r 個都在、總長等於 K+r、同 seed 結果相同；再確認不同 head 的結果不同。若 prompt 已大於 K，應直接失敗，不要默默刪 prompt。想看已處理 absolute position 與 torch.gather 的參考實作，可檢查固定 commit 的 randkv；它是獨立原型，不是 Salesforce 官方套件。

步驟二：接上 Qwen3，但先把相容性測試與跑分分開

建立乾淨環境，不要直接改系統 Python。randkv 0.1.0 需要 Python 3.10 以上；其 Transformers extra 會限制 Transformers 5.16.x，首版 adapter 只支援 batch size 1、無 padding、全注意力 decoder，不支援 beam search、sliding／chunked／linear attention，也沒有 vLLM 或最佳化 GPU kernel。

python3.11 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install "randkv[transformers]==0.1.0"

git clone https://github.com/DaBestCode/randkv.git
cd randkv
git checkout dc4be8e653ac1fa0f01739b8d3b11fe2e6e6a4d4

python scripts/smoke_transformers.py \
  --model Qwen/Qwen3-0.6B \
  --budget 512 --buffer-size 64 \
  --max-new-tokens 640 \
  --output-json results/my-smoke.json

Smoke test 只回答「能不能生成、真的有 eviction、cache 長度是否受控」，不能回答答案品質或加速。也要注意命名：randkv 的 budget 是持久 K，recent buffer 另外計；官方 Hugging Face harness 的 token_budget 會再扣 residual。把兩邊都填 2048，不代表實際容量相同。若顯存是你的主要限制，可搭配本機 LLM VRAM 指南先記錄模型、dtype 與裝置。

步驟三：固定品質評測，至少重跑 5 個 seeds

Random eviction 會改變輸出，因此速度比較前必須先設品質護欄。從 20–50 題小型題組起步即可，但每個條件要用同一批題、同一 prompt 模板、相同 max tokens、temperature、top-p 與停止條件。Dense 可以是固定 baseline；Random 至少跑 seeds 0–4，保存逐題答案與評分，不只報一個平均數。

model: Qwen/Qwen3-0.6B
revision: <固定 commit hash>
task_set_sha256: <題組雜湊>
conditions:
  - dense
  - random: {K: 512, r: 64, seeds: [0, 1, 2, 3, 4]}
decode: {max_new_tokens: 640, do_sample: false}
record_each_run:
  [correct, ttft_ms, decode_tok_s, peak_memory_mb, output_sha256]

若 Random 平均分接近 dense，但某幾題反覆掉分，先檢查題目是否只在很早的位置放一次關鍵字串。論文的 passcode stress test 也顯示，稀有、不可由後文重建的資訊可能讓內容分數法勝出；所以合理結論是「某些 reasoning benchmark 的結構保護很重要」，不是「所有 selection signal 都沒用」。長對話另可參考長 Session Prefix Cache 測試的固定輸入與冷／熱啟動分法。

步驟四：速度評測要分 TTFT、decode 與 serving throughput

單請求的短輸出常被 Python 選位與 gather 成本主導；長輸出、多請求則可能因 KV 記憶體縮小，容納更多並發並提升總吞吐。請先 warm-up，再交錯執行 dense／random，兩邊用完全相同的 prompt 與輸出長度。GPU 或 MPS 計時前後要同步，至少報中位數與所有 raw runs，別只挑最快一次。

原論文在單張 H200、1k-token prompt、約 32k-token generation、最多 128 requests、K=2048 的 vLLM 0.19 harness 中，Random 相對 TriAttention 高 32–43%；模型涵蓋 Qwen3 4B／14B／32B 與 Phi-4-reasoning 14B。第三方 randkv 維護者則在 Apple M4、Qwen3-0.6B、16-token prompt、128-token output、K=32、r=8 的三次單請求測試中，量到 dense 中位 38.53 tok/s、RandKV 35.48 tok/s，也就是 0.9208 倍、約低 7.9%。紀錄中的最後一組 dense 與 RandKV 輸出不相同，而且沒有品質評分。

因此正確讀法是：目前最小 Transformers adapter 有可見 compaction overhead；官方長序列 vLLM 實作則顯示，省掉 signal scoring 與同步工作能在特定 serving 負載提高吞吐。若要測正式服務，請依 vLLM benchmark CLI分別記 TTFT、ITL／TPOT 與 request throughput，並避免 prefix cache 重用污染重跑。推論引擎的 batching 與排程背景可先讀LLM 推論引擎教學。

步驟五：要驗證論文主張，改跑官方 H200／vLLM harness

官方研究 repository的準確率流程以 8 張 H200 建置，serving 表格另用單張 H200；環境固定 Python 3.10、PyTorch 2.4.0 cu121、FlashAttention 2.7.3，vLLM benchmark 還有自己的 pinned runtime 與 plugin。這不是把一個 cache class 貼進最新 Transformers 就會得到的數字。

1. 先依 repo 的 setup 與 runbook 建環境，記錄 GPU、driver、CUDA、模型 revision、vLLM commit 與 plugin commit。
2. 用 matched budget 比較 dense、Random 與至少一個同類壓縮 baseline；prompt protection 與 recency window 必須相同。
3. 品質與吞吐分開跑，保存 per-seed、per-task raw JSON；發生 OOM 也要記錄，不能只刪掉失敗條件。
4. 逐步放大 output length 與 concurrency，找出省記憶體何時開始抵過 eviction overhead，而不是只報單一甜蜜點。
5. 最後才判斷能否泛化到你的 workload；論文作者也把 long-input／short-output、prompt 超過 K、模型與任務範圍列為限制。

若你的服務大量共用固定前綴，還要單獨控制 prefix cache 命中；否則第二輪可能只是重用了 prefill。可參考Agent 工作負載 Prefix Cache Trace的 request fingerprint 與命中紀錄方法。

一張 receipt 決定能不能下結論

• 可比：模型與 revision、dtype、解碼參數、題組 hash、K／r 定義、backend 與 kernel 都寫清楚。
• 可重跑：保存命令、seed、warm-up、交錯順序、raw runs、錯誤與輸出雜湊。
• 可解釋：品質、TTFT、decode、總吞吐、峰值記憶體與併發各自報告，不揉成一個「快」。
• 可否證：預先寫下失敗門檻，例如正確率掉超過 1 個百分點、p95 ITL 變差或任何 unsupported model 被跳過。

Random Attention 常見問題 FAQ

1. Random Attention 就是把 token 隨便刪掉嗎？

不是。它有結構限制：prompt 全保留、最近窗口暫不淘汰、每層每個 KV head 獨立抽樣，而且保留後要恢復時間順序。

2. K=2048 代表 tensor 永遠只有 2048 個位置嗎？

不一定。K 是持久預算；加上 recency buffer 後，淘汰完成通常是 K+r，下一輪前還會再增長。不同實作對 budget 的命名也可能不同。

3. 為什麼 prompt 必須小於等於 K？

因為 prompt 被永久保護。若 prompt 本身已吃完整個持久預算，就沒有空間留舊生成 token；安全實作應直接報錯或重新設定預算。

4. 同一個 seed 為什麼還要加入 layer 與 head？

避免所有 head 留下同一批位置。穩定雜湊也比 Python 內建 hash() 更適合重跑，因為後者可能隨程序改變。

5. 0.9208 倍代表論文失敗嗎？

不能這樣推論。M4 測試是短輸出、單請求、dense 對 Python adapter；論文是 H200 長輸出、多請求、Random 對 TriAttention。它只證明通用 gather 不會自動帶來加速。

6. 論文的 32–43% 是相對 dense 嗎？

不是。這是 Table 4 中 Random 相對同 serving backend 的 TriAttention 增幅；比較分母寫錯，就會把特定 selector 成本誤讀成通用速度。

7. 隨機法一定不會傷害品質嗎？

沒有保證。論文主表在多個 reasoning 任務很有競爭力，但附錄仍有 baseline 顯著勝出的格子；一次出現、不可重建的資訊尤其要另外測。

8. 新手應從 randkv 還是官方 repo 開始？

先依問題選。學保留規則與單筆相容性，randkv 較小；驗證論文的品質與 vLLM 吞吐，必須用官方 harness 與相符硬體，不能拿前者代替。

給新手的 7 點完成清單

• 把 Random Attention 記成 prompt＋每頭獨立 random＋recency，而不是「隨便丟」。
• 分開邏輯 token 位置與 compact 後的實體 K/V 索引。
• 固定模型 revision、dtype、題組 hash、解碼設定、K 與 r。
• Random 跑多個 seeds，保存逐題答案，不只報平均。
• 把品質、TTFT、decode throughput、峰值記憶體與併發分開。
• 同 backend、同分母才談倍率；M4 adapter 與 H200 serving 不互相代替。
• 先寫失敗門檻，再決定方法是否值得進正式服務。

想把這個受控比較方法移植到其他工具，可參考MCP vs CLI 同任務 A/B Test；想繼續練習模型、推論與 Agent 工作流，前往 AlphaLab 的線上課程與AI 專區。