測試環境與正確性驗證方法

作者使用預訓練的 GPT-2 small（1.24 億參數）模型，在 NVIDIA A40 GPU 上以 fp32 精度（關閉 TF32）、批次大小為 1、貪婪解碼模式下進行測試。時間測量透過 torch.cuda.synchronize() 包裹，並在預熱後取五次運行的中位數作為基準。

正確性方面，自製實作的輸出 logits 與 Hugging Face 參考實現相比，最大絕對差異約為 6.1e-5。在連續生成 200 個詞的測試中，使用 KV Cache 與不使用 KV Cache 的貪婪解碼結果完全一致。

作者指出一個關鍵的失敗案例：若錯誤地反轉了 KV Cache 的串接順序，單詞注意力的單元測試仍能通過，但在同時解碼多個新詞時會導致結果錯誤。這顯示僅靠單步測試不足以驗證多步生成邏輯的正確性。

延遲表現與理論計算的落差

在上下文長度為 1,000 的情況下，理論上的浮點運算量（FLOPs）因使用 KV Cache 而減少約 1,000 倍。然而實際測量的單詞生成時間僅從 29.69 ms 降至 4.95 ms，加速比約為 6 倍，遠低於理論預期。

當生成總長度為 1,016 個詞時，不使用 KV Cache 需耗時 14.66 秒，使用後則降至 5.03 秒，整體加速比約為 2.9 倍。作者觀察到在此實作中，使用 KV Cache 後的延遲曲線趨於平緩。

對於延遲無法達到理論加速比的原因，作者推測可能來自 CPU 或 Kernel 啟動的開銷，但目前尚未透過 Profiler 進行確切分析，因此這僅為假設而非結論。

記憶體使用量與分配器開銷

根據 KV Cache 的理論公式，每個詞應佔用 72 KiB 的記憶體。作者最初直接測量請求分配的位元組數時，發現存在一個恆定的 8,519,688 位元組偏移量。

經過分析，該偏移量由兩部分組成：一個延遲分配的 8,519,680 位元組 cuBLAS 工作區，以及一個佔用 8 位元組的下一個詞張量。透過在基準測試前進行預熱並扣除這些非 Cache 相關的活躍張量後，測量值與理論公式在所有 16 個檢查點上完全吻合（差異為 0 B）。

儘管核心數據對齊，但記憶體分配器本身的區塊大小開銷仍然可見，這表明實際部署時需考慮框架層級的記憶體管理開銷。

專案性質與後續探討方向

作者明確指出這是一個教育性質的學習專案，旨在從頭理解 KV Cache 機制，並非提出新演算法或宣稱通用的加速效果。程式碼與詳細技術文章已公開於 GitHub 與個人部落格。

作者在社群中徵求關於正確性測試案例與 Profiling 控制的建議，特別是如何進一步調查尚未解決的延遲下限問題。作者也披露在撰寫過程中使用了 AI 輔助進行編輯與工具鏈處理。