首頁 ai KV 快取大小計算機 產生日期: 2026年7月20日 下午09:34 KV 快取大小計算機 輸入 層數32Key/value 頭數32頭維度128上下文長度4,096批次大小1精度FP16 / BF16(2 bytes) AI & LLM KV 快取大小計算機 依層數、key/value 頭數、頭維度、上下文長度、批次大小與每元素 bytes,估算 transformer 推論期間保留的 key-value 快取記憶體。 輸入 模型 層數 transformer 層的數量。每一層都保留自己的 key 與 value 張量,因此快取隨層數線性成長。 Key/value 頭數 key/value 注意力頭的數量。在分組查詢注意力(GQA)下,此值小於查詢頭數,並以相同比例縮小快取。 頭維度 每個注意力頭的大小。模型隱藏層大小約等於頭維度乘以查詢頭數。 工作負載 上下文長度 上下文中保留的 token 總數,提示加上已生成的部分。快取隨此長度線性成長,每個過往 token 占一格。 批次大小 同時服務的序列數量。每個序列各自保留快取,因此記憶體隨批次線性成長。 精度 FP16 / BF16 2 bytes 儲存每個快取數值所用的 bytes。半精度用兩個 bytes;八位元快取量化用一個,並將佔用減半。 結果 輸入數值即可顯示計算結果。 KV 快取大小 KV 快取記憶體估計:每層兩個張量,乘以 32 個 key/value 頭,再乘以頭維度、上下文長度與批次——約 ... GB。 分享 列印報告 重設 嵌入 嵌入這個計算機 預覽 將這段程式碼貼到您的網頁中即可顯示計算機。 複製程式碼 分享這個計算 開啟此連結的人都會看到您填入的數值。 複製連結 分享至 XFacebookLINE 電子郵件 最後更新：2026-06-22 KV 快取大小 在 transformer 推論期間,模型會關注到目前為止看過的每一個 token。為了避免在每個生成步驟都重算整段上下文的 key 與 value 向量,它將其儲存並重複使用——這就是 key-value 快取。在長上下文服務中,這份快取往往是加速器記憶體的最大消耗者,有時甚至大於模型權重本身。本計算機依層數、key/value 頭數、頭維度、上下文長度、批次大小,以及每個儲存數值所用的 bytes,估算其大小。 快取為何存在 逐個 token 生成文字,意味著每個新 token 都必須關注到它之前的所有 token。若沒有快取,每一步都要重新處理整段提示與所有先前的輸出,使生成成本隨序列長度的平方成長。藉由保留過往 token 的 key 與 value,模型讓每一步的工作量只與新 token 成正比。這份速度的代價是記憶體:每一層、每一個 key/value 頭、每一個上下文中的 token,都各有一組向量——一個 key 與一個 value。 公式 快取保留 key 與 value 兩個張量,因此其大小(以 bytes 計)為 Kbytes=2⋅L⋅H⋅d⋅s⋅B⋅eK_\text{bytes} = 2 \cdot L \cdot H \cdot d \cdot s \cdot B \cdot eKbytes=2⋅L⋅H⋅d⋅s⋅B⋅e 其中 LL 是層數,HH 是 key/value 頭數,dd 是頭維度,ss 是以 token 計的上下文長度,BB 是批次大小,ee 是每個儲存元素的 bytes。除以 10910^9 即得 GB。大小隨每個因子線性成長,這是關鍵直覺:上下文、批次或層數加倍,快取也加倍。 分組查詢注意力 key/value 頭數 HH 正是分組查詢注意力(GQA)鎖定的目標。在一般的多頭注意力中,每個查詢頭都擁有一組 key/value。GQA 讓一組查詢頭共用單一 key/value 頭,而多查詢注意力則讓整層只共用一個。由於快取隨 HH 變動,把 key/value 頭數從 32 降到 8,能把快取削減到四分之一,同時查詢頭——以及模型大部分品質——維持不變。近期大多數的大型模型都搭載 GQA,正是出於這個原因。 範例計算 取一個有 32 層、32 個 key/value 頭、頭維度為 128 的模型,保留 4,096 個 token 的上下文,以 16-bit 精度服務單一序列: Kbytes=2×32×32×128×4096×1×2=2,147,483,648K_\text{bytes} = 2 \times 32 \times 32 \times 128 \times 4096 \times 1 \times 2 = 2{,}147{,}483{,}648Kbytes=2×32×32×128×4096×1×2=2,147,483,648 約為 2.15 GB。同時服務四個這樣的序列會使其變為四倍,約 8.59 GB。將快取切換為 8-bit 精度,則會讓任一數字減半。 解讀結果 由於每個因子都線性相乘,長上下文、高批次的服務會把它們疊加在一起,快取便可能讓權重相形見絀。這正是為什麼正式環境的推論引擎仰賴快取量化以降低每元素 bytes、GQA 以削減 key/value 頭數,以及分頁注意力以無碎片地打包快取。同一硬體預算的運算面,出現在 注意力記憶體計算機,而模型權重的部分則在 LLM 推論 VRAM 計算器。 常見問題（FAQ）什麼是 KV 快取?在自回歸生成期間,transformer 會關注到每一個先前的 token。為了不在每一步都重算整段上下文的 key 與 value 向量,它將其儲存並重複使用——這份儲存就是 KV 快取。它以記憶體換取速度:若沒有它,生成每個新 token 都要重新處理整段提示與所有先前的輸出。快取為每一層、每一個 key/value 頭保留 key 與 value 兩個張量,每個 token 在上下文中各占一筆。 分組查詢注意力如何縮小快取?標準多頭注意力為每個查詢頭各保留一組 key/value。分組查詢注意力(GQA)讓多個查詢頭共用一個 key/value 頭,而多查詢注意力則推到極致,只用單一共用的 key/value 頭。由於快取大小與 key/value 頭數成正比,把頭數從比方說 32 削減到 8,能讓快取縮小到四分之一,同時查詢頭——以及模型大部分品質——維持不變。 為什麼長上下文這麼耗記憶體?快取隨上下文長度線性成長:上下文 token 數加倍,快取也加倍。它同時隨批次大小線性成長,因此一次服務許多長上下文序列時,兩者相乘。在長上下文下,KV 快取可能超過模型權重本身所占的記憶體,這正是長上下文服務仰賴快取量化、GQA 與分頁注意力(paged attention)等技術的原因。 免責聲明 此估計僅計入指定精度下的 key 與 value 張量,並忽略服務端的開銷,例如記憶體碎片、分頁中繼資料與框架保留空間。在特定推論引擎上的實際用量會略高一些。 推薦的下一個 LLM 推論 VRAM 計算器 根據參數量、權重精度，以及 KV 快取、激活值與碎片化所佔的執行階段開銷，估算為大型語言模型提供推論服務所需的 GPU VRAM。 深入了解情境視窗容納計算機 檢查提示加上保留的輸出詞元是否能容納於模型的情境視窗（上下文視窗）內。情境視窗界定了單次呼叫中輸入與輸出的合計上限。 深入了解 200+ 計算機 · 10 種語言 · 完全免費 更多infrastructure 注意力記憶體計算機專家混合活躍參數計算機量化模型大小計算器模型下載時間計算器GPU 數量需求計算機KV 快取大小計算機 +2 more Show less LLM 推論 VRAM 計算器Transformer 參數量計算機 其他ai計算機 cost 文字轉語音成本計算機代理人成本計算機向量資料庫大小計算機向量資料庫成本計算機自架與 API 損益平衡計算機批次 API 節省計算機每元詞元數計算機系統提示攤提計算機函式呼叫詞元額外負擔計算機音訊轉錄成本計算機訓練時間與成本計算訓練碳足跡計算情境成本增長計算機情境視窗容納計算機推論能源成本計算機嵌入成本計算機提示快取節省計算機結構化輸出額外負擔計算機詞元成本計算機詞元轉字數計算機微調成本計算影像生成成本計算機GPU 利用率成本計算器GPU 雲端成本計算機LLM 每月成本計算機LLM 速率限制規劃計算機inference 多模態影像詞元計算器有效每秒標記數計算器批次推論吞吐量計算器每標記 FLOP 計算機推測解碼加速計算機推論吞吐量計算器推論延遲計算器模型 FLOP 使用率計算機training 有效批次大小計算訓練 FLOPs 計算梯度累積記憶體計算機資料平行擴展計算資料集詞元數計算算力最佳模型大小計算算力預算可訓練輪數計算管線平行氣泡計算學習率暖身計算Chinchilla 最佳詞元數計算LLM 訓練 VRAM 計算機LoRA 參數計算機retrieval RAG 分塊計算器evaluation 困惑度計算器A/B 測試顯著性計算器LLM 評估樣本數計算器pass@k 計算器所有工具 餘弦相似度計算器 這個計算機對您有幫助嗎？ 有幫助 需要改進 需要改進 我們可以如何改進這個計算機？ 送出回饋 由 OneCalc 提供 ↗
最後更新：2026-06-22 KV 快取大小 在 transformer 推論期間,模型會關注到目前為止看過的每一個 token。為了避免在每個生成步驟都重算整段上下文的 key 與 value 向量,它將其儲存並重複使用——這就是 key-value 快取。在長上下文服務中,這份快取往往是加速器記憶體的最大消耗者,有時甚至大於模型權重本身。本計算機依層數、key/value 頭數、頭維度、上下文長度、批次大小,以及每個儲存數值所用的 bytes,估算其大小。 快取為何存在 逐個 token 生成文字,意味著每個新 token 都必須關注到它之前的所有 token。若沒有快取,每一步都要重新處理整段提示與所有先前的輸出,使生成成本隨序列長度的平方成長。藉由保留過往 token 的 key 與 value,模型讓每一步的工作量只與新 token 成正比。這份速度的代價是記憶體:每一層、每一個 key/value 頭、每一個上下文中的 token,都各有一組向量——一個 key 與一個 value。 公式 快取保留 key 與 value 兩個張量,因此其大小(以 bytes 計)為 Kbytes=2⋅L⋅H⋅d⋅s⋅B⋅eK_\text{bytes} = 2 \cdot L \cdot H \cdot d \cdot s \cdot B \cdot eKbytes=2⋅L⋅H⋅d⋅s⋅B⋅e 其中 LL 是層數,HH 是 key/value 頭數,dd 是頭維度,ss 是以 token 計的上下文長度,BB 是批次大小,ee 是每個儲存元素的 bytes。除以 10910^9 即得 GB。大小隨每個因子線性成長,這是關鍵直覺:上下文、批次或層數加倍,快取也加倍。 分組查詢注意力 key/value 頭數 HH 正是分組查詢注意力(GQA)鎖定的目標。在一般的多頭注意力中,每個查詢頭都擁有一組 key/value。GQA 讓一組查詢頭共用單一 key/value 頭,而多查詢注意力則讓整層只共用一個。由於快取隨 HH 變動,把 key/value 頭數從 32 降到 8,能把快取削減到四分之一,同時查詢頭——以及模型大部分品質——維持不變。近期大多數的大型模型都搭載 GQA,正是出於這個原因。 範例計算 取一個有 32 層、32 個 key/value 頭、頭維度為 128 的模型,保留 4,096 個 token 的上下文,以 16-bit 精度服務單一序列: Kbytes=2×32×32×128×4096×1×2=2,147,483,648K_\text{bytes} = 2 \times 32 \times 32 \times 128 \times 4096 \times 1 \times 2 = 2{,}147{,}483{,}648Kbytes=2×32×32×128×4096×1×2=2,147,483,648 約為 2.15 GB。同時服務四個這樣的序列會使其變為四倍,約 8.59 GB。將快取切換為 8-bit 精度,則會讓任一數字減半。 解讀結果 由於每個因子都線性相乘,長上下文、高批次的服務會把它們疊加在一起,快取便可能讓權重相形見絀。這正是為什麼正式環境的推論引擎仰賴快取量化以降低每元素 bytes、GQA 以削減 key/value 頭數,以及分頁注意力以無碎片地打包快取。同一硬體預算的運算面,出現在 注意力記憶體計算機,而模型權重的部分則在 LLM 推論 VRAM 計算器。 常見問題（FAQ）什麼是 KV 快取?在自回歸生成期間,transformer 會關注到每一個先前的 token。為了不在每一步都重算整段上下文的 key 與 value 向量,它將其儲存並重複使用——這份儲存就是 KV 快取。它以記憶體換取速度:若沒有它,生成每個新 token 都要重新處理整段提示與所有先前的輸出。快取為每一層、每一個 key/value 頭保留 key 與 value 兩個張量,每個 token 在上下文中各占一筆。 分組查詢注意力如何縮小快取?標準多頭注意力為每個查詢頭各保留一組 key/value。分組查詢注意力(GQA)讓多個查詢頭共用一個 key/value 頭,而多查詢注意力則推到極致,只用單一共用的 key/value 頭。由於快取大小與 key/value 頭數成正比,把頭數從比方說 32 削減到 8,能讓快取縮小到四分之一,同時查詢頭——以及模型大部分品質——維持不變。 為什麼長上下文這麼耗記憶體?快取隨上下文長度線性成長:上下文 token 數加倍,快取也加倍。它同時隨批次大小線性成長,因此一次服務許多長上下文序列時,兩者相乘。在長上下文下,KV 快取可能超過模型權重本身所占的記憶體,這正是長上下文服務仰賴快取量化、GQA 與分頁注意力(paged attention)等技術的原因。 免責聲明 此估計僅計入指定精度下的 key 與 value 張量,並忽略服務端的開銷,例如記憶體碎片、分頁中繼資料與框架保留空間。在特定推論引擎上的實際用量會略高一些。
