1. 項(xiàng)目概述為什么我們需要關(guān)注KV Cache如果你最近在部署或者優(yōu)化一個(gè)大語言模型LLM的推理服務(wù)大概率會(huì)聽到“KV Cache”這個(gè)詞。它不是什么高深莫測(cè)的新算法但卻是決定你的模型推理速度是“龜速”還是“飛馳”的關(guān)鍵技術(shù)之一。簡(jiǎn)單來說KV Cache是一種用空間顯存換時(shí)間計(jì)算速度的緩存策略專門針對(duì)LLM自回歸生成文本時(shí)那令人頭疼的重復(fù)計(jì)算問題。想象一下這個(gè)場(chǎng)景你讓ChatGPT寫一首詩它每次生成下一個(gè)字token時(shí)都需要基于之前所有已經(jīng)生成的字來計(jì)算。如果沒有KV Cache模型在生成第100個(gè)字時(shí)需要把前99個(gè)字的計(jì)算過程全部重新來一遍這無疑是巨大的浪費(fèi)。KV Cache所做的就是把前99個(gè)字計(jì)算過程中產(chǎn)生的一些中間結(jié)果Key和Value向量保存下來這樣在計(jì)算第100個(gè)字時(shí)直接復(fù)用這些緩存結(jié)果避免了絕大部分重復(fù)的矩陣運(yùn)算。效果立竿見影推理速度可能提升幾倍甚至幾十倍同時(shí)批處理batch能力也大大增強(qiáng)。理解KV Cache不僅僅是知道它“能加速”更要明白它“如何加速”、“代價(jià)是什么”以及“如何用好它”。這對(duì)于任何從事LLM應(yīng)用開發(fā)、模型部署或性能優(yōu)化的工程師來說都是一項(xiàng)必須掌握的核心知識(shí)。無論是想降低API服務(wù)的延遲和成本還是在資源有限的邊緣設(shè)備上運(yùn)行模型KV Cache都是你繞不開的坎。接下來我們就從最基礎(chǔ)的注意力機(jī)制開始一步步拆解KV Cache的原理、實(shí)現(xiàn)和那些實(shí)際工程中必須面對(duì)的“坑”。2. 核心原理從注意力機(jī)制到KV Cache的誕生要理解KV Cache我們必須回到它的源頭Transformer模型中的注意力機(jī)制。這是所有現(xiàn)代LLM的基石也是產(chǎn)生重復(fù)計(jì)算問題的根本所在。2.1 注意力機(jī)制中的重復(fù)計(jì)算問題Transformer的自注意力Self-Attention機(jī)制其核心計(jì)算可以簡(jiǎn)化為以下公式Attention(Q, K, V) softmax(QK^T / sqrt(d_k)) V這里QQuery、KKey、VValue都是由輸入序列通過線性變換得到的矩陣。在自回歸生成任務(wù)中比如聊天、續(xù)寫模型每次只生成一個(gè)token。假設(shè)我們已經(jīng)生成了t-1個(gè)token現(xiàn)在要生成第t個(gè)token。在沒有緩存的情況下生成第t個(gè)token的步驟是將當(dāng)前所有t個(gè)token前t-1個(gè)已生成 第t個(gè)待預(yù)測(cè)輸入模型。模型為這t個(gè)token計(jì)算它們各自的 Q, K, V。進(jìn)行注意力計(jì)算得到第t個(gè)token的表示。基于這個(gè)表示預(yù)測(cè)第t個(gè)token是什么。問題來了當(dāng)我們下一步要生成第t1個(gè)token時(shí)我們需要把t1個(gè)token包含新的第t個(gè)token再次全部輸入然后重新為所有t1個(gè)token計(jì)算一遍它們的 K 和 V。注意前t個(gè)token的 K 和 V 在步驟2中已經(jīng)計(jì)算過了但因?yàn)闆]有保存所以不得不重新算一次。這種重復(fù)計(jì)算隨著生成序列的增長(zhǎng)而線性增加造成了巨大的計(jì)算開銷。2.2 KV Cache的核心思想與工作流程KV Cache的核心思想直白而有效把每次前向傳播中計(jì)算得到的 K 和 V 向量緩存起來供后續(xù)生成步驟復(fù)用。我們來看一下引入KV Cache后生成第t個(gè)token的工作流程初始步t1用戶輸入提示詞prompt模型進(jìn)行完整的前向傳播計(jì)算所有提示詞token的 K 和 V并將它們存入緩存Cache。生成第一步t2模型基于提示詞生成第一個(gè)輸出token。同時(shí)為這個(gè)新生成的token計(jì)算其 K 和 V并將它們追加到之前的緩存中。此時(shí)緩存里包含了所有提示詞token和第一個(gè)輸出token的 K 和 V。生成后續(xù)步t2要生成下一個(gè)token時(shí)模型不再需要為所有歷史token重新計(jì)算 K 和 V。它只需要 a. 為當(dāng)前最新的那個(gè)token即上一步剛生成的計(jì)算其 Q。 b. 從緩存中讀取所有歷史token包括提示詞和之前所有輸出的 K 和 V。 c. 用最新的 Q 去和緩存中的所有 K 計(jì)算注意力分?jǐn)?shù)再與緩存的 V 加權(quán)求和得到當(dāng)前token的上下文表示。 d. 預(yù)測(cè)出新token后再為這個(gè)新token計(jì)算其 K 和 V并追加到緩存。這個(gè)過程就像一個(gè)不斷增長(zhǎng)的“記憶庫”。每次生成新token我們只做三件事計(jì)算新token的Q、從緩存讀K/V、計(jì)算新token的K/V并寫入緩存。絕大部分的計(jì)算歷史token的K/V計(jì)算都被省去了。注意這里有一個(gè)關(guān)鍵細(xì)節(jié)。在標(biāo)準(zhǔn)的自回歸生成中當(dāng)前token的Q只與當(dāng)前token的輸入有關(guān)通常是上一步的輸出嵌入經(jīng)過線性層。而當(dāng)前token的K和V也是由這個(gè)相同的輸入經(jīng)過不同的線性層得到的。所以“計(jì)算新token的K/V”這一步是無法避免的因?yàn)樗切滦畔ⅰV Cache省去的是為所有歷史舊token重新計(jì)算K/V的開銷。2.3 KV Cache帶來的性能收益分析KV Cache帶來的性能提升是數(shù)量級(jí)的。我們可以從計(jì)算復(fù)雜度的角度來量化無KV Cache生成一個(gè)長(zhǎng)度為L(zhǎng)的序列總計(jì)算復(fù)雜度約為O(L^3)因?yàn)槊看紊啥夹枰獮樗袣v史token計(jì)算注意力而注意力計(jì)算本身是O(n^2)的。這在實(shí)際中是無法接受的。有KV Cache生成一個(gè)長(zhǎng)度為L(zhǎng)的序列總計(jì)算復(fù)雜度約為O(L^2)。雖然注意力計(jì)算仍然是O(n^2)但每次生成時(shí)計(jì)算K和V的這部分巨大開銷線性層計(jì)算從O(L)降到了O(1)因?yàn)橹粸樽钚聇oken計(jì)算。這使得模型推理的核心瓶頸從計(jì)算轉(zhuǎn)移到了內(nèi)存訪問讀寫緩存。在實(shí)際的工程測(cè)試中對(duì)于像LLaMA-7B這樣的模型開啟KV Cache可以將生成階段的吞吐量Tokens per Second提升5到10倍效果極其顯著。尤其是在長(zhǎng)文本生成場(chǎng)景下這種優(yōu)勢(shì)會(huì)更加明顯。3. 實(shí)現(xiàn)細(xì)節(jié)與內(nèi)存開銷的權(quán)衡理解了原理我們來看看具體怎么實(shí)現(xiàn)它以及那個(gè)無法回避的代價(jià)顯存占用。3.1 KV Cache的數(shù)據(jù)結(jié)構(gòu)與存儲(chǔ)方式在代碼中KV Cache通常被實(shí)現(xiàn)為一組不斷增長(zhǎng)的張量Tensor。對(duì)于Transformer的每一層layer和每一個(gè)注意力頭head都需要維護(hù)兩個(gè)緩存key_cache和value_cache。假設(shè)模型配置如下batch_size: B批處理大小num_heads: H注意力頭數(shù)量head_dim: D每個(gè)注意力頭的維度當(dāng)前已生成的序列長(zhǎng)度包括提示詞seq_len那么在某一層KV Cache的總大小可以這樣估算key_cache形狀:[B, H, seq_len, D]value_cache形狀:[B, H, seq_len, D]因此每一層的KV Cache所占用的顯存以字節(jié)為單位大約是Cache_Memory_Per_Layer 2 * B * H * seq_len * D * sizeof(dtype)其中sizeof(dtype)取決于精度例如float16是2字節(jié)bfloat16也是2字節(jié)float32是4字節(jié)。對(duì)于一個(gè)典型的模型比如LLaMA-7B32層32個(gè)頭頭維度128使用float16當(dāng)batch_size1seq_len1024時(shí)我們可以粗略計(jì)算其KV Cache大小單層Cache大小 2 * 1 * 32 * 1024 * 128 * 2 bytes ≈ 16.78 MB 總Cache大小 ≈ 16.78 MB/layer * 32 layers ≈ 537 MB537MB這僅僅是為了緩存K和V。而LLaMA-7B模型本身的參數(shù)fp16大約占14GB。這意味著KV Cache的顯存開銷可能達(dá)到模型參數(shù)本身的4%甚至更高。當(dāng)批處理B增大或序列長(zhǎng)度seq_len變長(zhǎng)時(shí)這個(gè)開銷會(huì)線性增長(zhǎng)迅速成為顯存占用的主要部分。3.2 不同推理框架中的KV Cache實(shí)現(xiàn)主流推理框架都實(shí)現(xiàn)了KV Cache但具體方式各有優(yōu)化Hugging Face Transformers /text-generation-inference(TGI)在Transformers庫中KV Cache的管理通常封裝在模型的past_key_values這個(gè)狀態(tài)中。在調(diào)用model.generate()時(shí)可以通過use_cacheTrue參數(shù)開啟。TGI在此基礎(chǔ)上做了大量生產(chǎn)級(jí)優(yōu)化如PagedAttention來自vLLM將KV Cache組織成非連續(xù)的內(nèi)存頁極大減少了由于碎片化導(dǎo)致的內(nèi)存浪費(fèi)提升了高并發(fā)下的顯存利用率。vLLMvLLM的核心創(chuàng)新就是PagedAttention和與之配套的KV Cache管理。它將每個(gè)序列的KV Cache視為一系列固定大小的“塊”block類似于操作系統(tǒng)的內(nèi)存分頁。好處是消除了顯存碎片。傳統(tǒng)方式為每個(gè)請(qǐng)求預(yù)留最大可能長(zhǎng)度的連續(xù)顯存導(dǎo)致大量?jī)?nèi)部碎片。PagedAttention允許不同序列的KV Cache塊交錯(cuò)存儲(chǔ)顯存利用率可以從通常的不足50%提升到80%以上顯著提高了服務(wù)吞吐量。TensorRT-LLM / FasterTransformer這些由硬件廠商主導(dǎo)的框架會(huì)將KV Cache的讀寫與計(jì)算內(nèi)核kernel做深度綁定和優(yōu)化。它們可能使用更底層的CUDA核函數(shù)將KV Cache的更新追加新token的K/V與注意力計(jì)算融合在一個(gè)核函數(shù)里執(zhí)行減少數(shù)據(jù)在全局顯存和片上緩存之間的搬運(yùn)次數(shù)從而獲得極致的性能。3.3 內(nèi)存開銷的量化分析與優(yōu)化策略面對(duì)KV Cache帶來的顯存壓力工程師們有一系列應(yīng)對(duì)策略策略一量化Quantization這是最直接有效的方法。將KV Cache的精度從float16降低到int8甚至int4。int8量化顯存占用直接減半。現(xiàn)代硬件如NVIDIA的Hopper架構(gòu)對(duì)int8計(jì)算有很好的支持在保證精度損失很小的前提下能同時(shí)節(jié)省顯存和提升計(jì)算速度。fp8量化一種新興的8位浮點(diǎn)格式在精度和范圍之間取得了更好的平衡特別適合KV Cache這種對(duì)動(dòng)態(tài)范圍有一定要求的激活值。策略二選擇性緩存與逐出Eviction對(duì)于超長(zhǎng)上下文比如128K緩存所有token的K/V是不現(xiàn)實(shí)的。可以采用一些啟發(fā)式策略窗口注意力Sliding Window Attention只緩存最近N個(gè)token的K/V。這假設(shè)遠(yuǎn)距離的token對(duì)當(dāng)前生成影響很小。很多長(zhǎng)上下文模型如Mistral本身就采用了這種注意力機(jī)制天然適合。層次化緩存對(duì)歷史token的K/V進(jìn)行采樣或池化pooling只保留一個(gè)“摘要”性的緩存犧牲一些精度換取空間。策略三內(nèi)存高效的注意力算法一些新的注意力算法本身就能減少KV Cache的開銷例如Multi-Query Attention (MQA) 和 Grouped-Query Attention (GQA)讓多個(gè)注意力頭共享同一份K和V。這能顯著減少需要緩存的K/V數(shù)據(jù)量。例如LLaMA2就采用了GQA。假設(shè)原來H個(gè)頭需要緩存H份K和VGQA可能只緩存4份顯存占用降至1/8。FlashAttention雖然主要優(yōu)化計(jì)算速度但其對(duì)顯存訪問的優(yōu)化也間接影響了KV Cache的讀寫效率。FlashAttention-2等后續(xù)版本對(duì)推理場(chǎng)景做了更多優(yōu)化。實(shí)操心得在選擇優(yōu)化策略時(shí)首先要做性能剖析Profiling。用Nsight Systems或PyTorch Profiler工具跑一下你的推理流程看看時(shí)間是卡在計(jì)算上還是顯存帶寬上。如果瓶頸是計(jì)算那么開啟KV Cache本身就能解決如果瓶頸是顯存帶寬特別是長(zhǎng)序列、大批次時(shí)那么就需要考慮對(duì)KV Cache進(jìn)行量化或采用MQA/GQA模型。永遠(yuǎn)不要盲目?jī)?yōu)化。4. 高級(jí)話題與工程實(shí)踐挑戰(zhàn)掌握了基礎(chǔ)我們來看看在實(shí)際工程中圍繞KV Cache有哪些更復(fù)雜的問題和高級(jí)技巧。4.1 動(dòng)態(tài)批處理與請(qǐng)求間調(diào)度在生產(chǎn)環(huán)境中推理服務(wù)器需要同時(shí)處理多個(gè)并發(fā)請(qǐng)求。這些請(qǐng)求的輸入長(zhǎng)度和生成長(zhǎng)度各不相同。如何高效地管理這些請(qǐng)求的KV Cache是推理引擎的核心競(jìng)爭(zhēng)力。連續(xù)批處理Continuous Batching或迭代級(jí)調(diào)度傳統(tǒng)批處理是“靜態(tài)”的收集一批請(qǐng)求一起處理完所有輸出token再處理下一批。這會(huì)導(dǎo)致快的請(qǐng)求等慢的請(qǐng)求GPU利用率低。連續(xù)批處理是“動(dòng)態(tài)”的它以每次模型前向傳播生成一個(gè)token為單位進(jìn)行調(diào)度。當(dāng)一個(gè)請(qǐng)求生成完一個(gè)token后如果它還需要繼續(xù)生成它的KV Cache會(huì)被保留狀態(tài)進(jìn)入等待GPU立即去處理其他請(qǐng)求的下一個(gè)token。這要求KV Cache的管理必須是細(xì)粒度且靈活的能夠隨時(shí)插入新請(qǐng)求加入、刪除請(qǐng)求完成和更新請(qǐng)求繼續(xù)生成。vLLM的PagedAttention正是為此而生。KV Cache的共享在一些場(chǎng)景下多個(gè)請(qǐng)求可能擁有相同的提示詞前綴。例如多個(gè)用戶都問“請(qǐng)解釋一下量子計(jì)算”。理想情況下這段公共前綴的KV Cache應(yīng)該只計(jì)算和存儲(chǔ)一次然后在多個(gè)請(qǐng)求間共享。實(shí)現(xiàn)共享需要引擎能識(shí)別公共前綴并在邏輯上讓多個(gè)請(qǐng)求的KV Cache指針指向同一塊物理顯存。這能大幅節(jié)省顯存和計(jì)算資源。4.2 長(zhǎng)上下文與無限生成的內(nèi)存管理當(dāng)序列長(zhǎng)度達(dá)到數(shù)萬甚至數(shù)十萬時(shí)KV Cache的顯存占用會(huì)成為不可承受之重。除了前面提到的窗口和量化還有更激進(jìn)的方案KV Cache的重計(jì)算Recomputation這是一種用計(jì)算換顯存的極端策略。當(dāng)顯存不足時(shí)不保存所有歷史K/V而是在需要時(shí)比如計(jì)算注意力臨時(shí)重新計(jì)算某一段歷史token的K/V。這聽起來回到了原點(diǎn)但可以策略性地使用。例如只對(duì)非常久遠(yuǎn)的歷史進(jìn)行重計(jì)算而緩存最近的歷史。這需要精細(xì)的算法來控制重計(jì)算的頻率和范圍。存儲(chǔ)卸載Offloading將一部分不活躍的、舊的KV Cache從GPU顯存轉(zhuǎn)移到CPU內(nèi)存甚至NVMe SSD硬盤上。當(dāng)未來需要用到它們時(shí)比如模型突然引用了很久以前的內(nèi)容再將其加載回顯存。這引入了IO開銷但在處理超長(zhǎng)文本時(shí)是一種可行的“擴(kuò)展顯存”的手段。一些研究正在探索如何預(yù)測(cè)模型的訪問模式以智能地預(yù)加載可能需要的緩存塊。4.3 與推測(cè)解碼、量化的協(xié)同優(yōu)化KV Cache不是孤立存在的它需要與其他推理優(yōu)化技術(shù)協(xié)同工作。推測(cè)解碼Speculative Decoding推測(cè)解碼用一個(gè)更小的“草稿模型”快速生成多個(gè)候選token然后用大模型一次性驗(yàn)證這些token。這能大幅提升解碼速度。KV Cache在這里扮演關(guān)鍵角色無論是草稿模型的生成還是大模型的驗(yàn)證都需要高效地管理KV Cache。而且由于是多個(gè)token一起驗(yàn)證對(duì)大模型的KV Cache讀寫模式提出了不同要求需要引擎能夠高效處理這種“小批量”的注意力計(jì)算。權(quán)重量化與KV Cache量化的協(xié)同現(xiàn)在流行的做法是對(duì)模型權(quán)重進(jìn)行4-bit量化如GPTQ, AWQ同時(shí)對(duì)KV Cache進(jìn)行8-bit量化。這里有一個(gè)精度對(duì)齊的問題。權(quán)重和激活值KV Cache屬于激活值的量化誤差可能會(huì)疊加。通常需要一些“校準(zhǔn)”步驟在少量數(shù)據(jù)上運(yùn)行模型觀察KV Cache的數(shù)值分布從而確定最佳的量化參數(shù)scale/zero_point以最小化整體精度損失。5. 常見問題、調(diào)試技巧與性能分析在實(shí)際操作中你會(huì)遇到各種各樣與KV Cache相關(guān)的問題。下面是一些典型場(chǎng)景和排查思路。5.1 典型問題與排查清單問題現(xiàn)象可能原因排查思路與解決方案推理速度遠(yuǎn)低于預(yù)期1. KV Cache未開啟。2. 序列長(zhǎng)度很長(zhǎng)但注意力計(jì)算未優(yōu)化。3. 批處理大小過大顯存帶寬成為瓶頸。1. 確認(rèn)代碼中use_cacheTrue已設(shè)置。2. 使用FlashAttention等優(yōu)化后的注意力實(shí)現(xiàn)。3. 減小批處理大小或?qū)V Cache進(jìn)行量化。顯存溢出OOM1. 序列長(zhǎng)度過長(zhǎng)KV Cache占用過大。2. 批處理大小過大。3. 未及時(shí)釋放已結(jié)束請(qǐng)求的KV Cache。1. 監(jiān)控seq_len考慮啟用窗口注意力或量化。2. 減小批處理大小。3. 檢查推理引擎是否支持動(dòng)態(tài)釋放緩存如vLLM。使用torch.cuda.memory_summary()分析顯存分布。生成結(jié)果出現(xiàn)重復(fù)或 nonsense1. KV Cache在更新過程中出現(xiàn)錯(cuò)位例如token位置索引錯(cuò)誤。2. 使用了量化KV Cache但量化誤差過大。1. 這是最棘手的bug之一。需要仔細(xì)檢查緩存張量的形狀和索引邏輯確保新token的K/V被正確追加到對(duì)應(yīng)位置。可以關(guān)閉緩存對(duì)比輸出結(jié)果。2. 嘗試使用更高精度的量化如從int8切換到fp16或在校準(zhǔn)數(shù)據(jù)上微調(diào)量化參數(shù)。多輪對(duì)話中模型“忘記”了之前對(duì)話內(nèi)容1. 在對(duì)話輪次間KV Cache被錯(cuò)誤地重置或未正確傳遞。2. 上下文長(zhǎng)度超過模型限制舊緩存被截?cái)唷?. 確保在后續(xù)輪次中將上一輪生成的past_key_values作為輸入的一部分傳遞給模型。2. 實(shí)現(xiàn)一個(gè)緩存管理策略例如只保留最近N輪對(duì)話的緩存或?qū)v史緩存進(jìn)行摘要。5.2 性能剖析實(shí)戰(zhàn)定位KV Cache的瓶頸理論說了很多最終還是要靠工具說話。以下是一個(gè)使用PyTorch Profiler進(jìn)行性能分析的簡(jiǎn)單示例import torch from transformers import AutoModelForCausalLM, AutoTokenizer from torch.profiler import profile, record_function, ProfilerActivity model_name meta-llama/Llama-2-7b-chat-hf tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name, torch_dtypetorch.float16, device_mapcuda) model.eval() prompt 請(qǐng)寫一個(gè)關(guān)于人工智能的短故事。 inputs tokenizer(prompt, return_tensorspt).to(cuda) with profile( activities[ProfilerActivity.CPU, ProfilerActivity.CUDA], scheduletorch.profiler.schedule(wait1, warmup1, active3, repeat1), on_trace_readytorch.profiler.tensorboard_trace_handler(./log/kv_cache_profile), record_shapesTrue, profile_memoryTrue, with_stackTrue ) as prof: with torch.no_grad(): for _ in range(5): # 生成5個(gè)token來觀察 outputs model.generate(**inputs, max_new_tokens1, use_cacheTrue, do_sampleFalse) inputs[input_ids] outputs.sequences prof.step() # 分析關(guān)鍵指標(biāo) # 1. 在TensorBoard中查看 self_cuda_time_total找到耗時(shí)最長(zhǎng)的算子。 # 2. 重點(diǎn)關(guān)注 aten::_scaled_dot_product_attention注意力計(jì)算和 linearQKV投影操作。 # 3. 觀察CUDA內(nèi)存使用情況看內(nèi)存峰值是否與序列長(zhǎng)度增長(zhǎng)同步判斷是否是KV Cache導(dǎo)致OOM。通過分析profile結(jié)果你可以清晰地看到時(shí)間花在了哪里是計(jì)算QKV的線性層還是注意力計(jì)算本身開啟緩存后每次生成迭代的時(shí)間是否穩(wěn)定理想情況下應(yīng)該大致穩(wěn)定因?yàn)橛?jì)算量固定顯存增長(zhǎng)曲線是否符合2 * B * H * seq_len * D * sizeof(dtype)的預(yù)期5.3 實(shí)操心得與配置建議根據(jù)我在多個(gè)項(xiàng)目中的經(jīng)驗(yàn)這里有一些不常被提及但非常重要的細(xì)節(jié)緩存形狀的預(yù)先分配Pre-allocation如果你知道生成的最大長(zhǎng)度可以預(yù)先為KV Cache分配一個(gè)足夠大的固定形狀的張量而不是每次動(dòng)態(tài)追加。這能避免頻繁的顯存重分配和碎片化對(duì)性能有輕微提升。許多推理框架內(nèi)部就是這樣做的。注意旋轉(zhuǎn)位置編碼RoPE與緩存像LLaMA這類使用RoPE的模型其K和V緩存的是應(yīng)用了位置編碼之后的向量。這意味著當(dāng)你從緩存中讀取歷史K/V時(shí)它們已經(jīng)包含了正確的位置信息。你只需要為新token的K/V計(jì)算并應(yīng)用新的位置編碼即可。確保你的實(shí)現(xiàn)沒有錯(cuò)誤地重復(fù)應(yīng)用位置編碼。“use_cache”的陷阱在Hugging Face Transformers中use_cacheTrue是默認(rèn)設(shè)置。但在一些自定義模型或微調(diào)腳本中可能會(huì)被意外關(guān)閉。始終在第一次性能測(cè)試時(shí)確認(rèn)緩存已開啟。一個(gè)簡(jiǎn)單的判斷方法是生成第一個(gè)token后檢查輸出的past_key_values是否不為None并且其形狀是否符合預(yù)期。混合精度訓(xùn)練與推理的一致性如果你用bfloat16訓(xùn)練模型但在推理時(shí)使用float16的KV Cache可能會(huì)因精度差異導(dǎo)致生成質(zhì)量輕微下降。盡量保持訓(xùn)練和推理的精度一致。如果必須混合建議KV Cache使用不低于模型計(jì)算精度的格式。理解KV Cache從原理到實(shí)現(xiàn)從優(yōu)勢(shì)到代價(jià)是現(xiàn)代LLM工程化不可或缺的一環(huán)。它不是一個(gè)可以黑盒使用的魔法開關(guān)而是需要你根據(jù)具體的模型、硬件和工作負(fù)載進(jìn)行仔細(xì)調(diào)優(yōu)的核心組件。從手動(dòng)管理past_key_values到依賴vLLM這樣的高級(jí)推理引擎對(duì)KV Cache的掌控程度直接決定了你能否在成本、速度和效果之間找到最佳平衡點(diǎn)。