先拋一個(gè)有點(diǎn)反常識(shí)的結(jié)論單純靠量化不可能把 700GB 的大模型塞進(jìn) 8GB 顯存。這個(gè)說(shuō)法不是勸退而是先把賬算清楚。700GB 的模型參數(shù)按目前最常見(jiàn)的 INT4 量化來(lái)算壓縮率差不多是 4 倍也就是還要 175GB 左右距離 8GB 還有二十多倍差距。真正能解決問(wèn)題的路徑是兩條腿走路蒸餾負(fù)責(zé)把模型“變小”量化負(fù)責(zé)把變小后的模型“塞進(jìn)”顯存。這篇文章我會(huì)把兩條路分別拆開(kāi)講透結(jié)合我自己在 8GB 顯卡上跑大模型的實(shí)際經(jīng)驗(yàn)給你一套可以直接照著做的方案。先交代一下我自己的環(huán)境一張 8GB 顯存的消費(fèi)級(jí)顯卡平時(shí)主要玩本地大模型部署、微調(diào)和推理加速。這種卡在 2024 年之后越來(lái)越尷尬因?yàn)樾鲁龅哪Ｐ蛣?dòng)輒 70B、上百 B顯存卻一分錢(qián)沒(méi)漲。但尷尬歸尷尬真要用起來(lái)也不是沒(méi)有辦法關(guān)鍵看你愿不愿意把“大模型”的定義放寬一點(diǎn)。1. 先把話(huà)放這700G 不是“塞進(jìn)”顯存而是“縮”到能用1.1 顯存里到底存了什么參數(shù)、KV緩存、臨時(shí)張量很多人以為顯存只裝模型權(quán)重這是最普遍的誤解。實(shí)際跑推理時(shí)顯存里至少同時(shí)放著三類(lèi)東西。第一類(lèi)是模型權(quán)重也就是模型文件里的那些浮點(diǎn)數(shù)。700GB 的模型文件光權(quán)重就要占掉 700GB這是最基本的開(kāi)銷(xiāo)。第二類(lèi)是 KV 緩存每個(gè) token 在生成時(shí)都需要把之前所有 token 的 Key 和 Value 保存下來(lái)用來(lái)算注意力權(quán)重。KV 緩存的大小取決于模型層數(shù)、注意力頭數(shù)、上下文長(zhǎng)度這部分會(huì)隨著對(duì)話(huà)變長(zhǎng)持續(xù)增長(zhǎng)。第三類(lèi)是中間激活值前向傳播過(guò)程中每一層的輸出都要臨時(shí)保存在顯存里方便反向傳播或繼續(xù)算下一層雖然單次占用不大但峰值時(shí)刻很容易成為 OOM 的元兇。推理階段如果不需要反向傳播中間激活值會(huì)在每層算完后釋放所以顯存壓力主要是兩個(gè)權(quán)重和 KV 緩存。你盯著任務(wù)管理器看的那個(gè)顯存占用其實(shí)是這兩者加在一起的結(jié)果。1.2 成本賬從 700GB 到 8GB壓縮率到底有多夸張直接做算術(shù)。700GB 模型權(quán)重假設(shè)原始精度是 FP16也就是每個(gè)參數(shù)占 2 字節(jié)那這個(gè)模型大概有 3500 億參數(shù)。350B 是什么概念目前開(kāi)源社區(qū)能公開(kāi)下載的最大模型也基本在這個(gè)量級(jí)附近。如果做 INT8 量化每個(gè)參數(shù)占 1 字節(jié)總體積降到 350GB。再做 INT4 量化每個(gè)參數(shù)占 0.5 字節(jié)總體積降到 175GB。依然不夠 8GB。所以純量化的極限壓縮率大約是 8 到 16 倍但 700GB 到 8GB 需要的是接近 90 倍的壓縮。這個(gè)量級(jí)靠精度壓縮根本做不到只能靠蒸餾先把參數(shù)量從千億砍到幾十億甚至十幾億。換句話(huà)說(shuō)蒸餾負(fù)責(zé)把大象變成狗量化負(fù)責(zé)把狗裝進(jìn)籠子。兩個(gè)動(dòng)作缺一不可順序也不能顛倒。1.3 拆解后的正確路線(xiàn)蒸餾負(fù)責(zé)縮量化負(fù)責(zé)摳如果你的終極目標(biāo)是“在 8GB 顯存上跑一個(gè)強(qiáng)到離譜的模型”那我得潑冷水目前沒(méi)有任何一條公開(kāi)路徑能把 700GB 這種體量的模型無(wú)損壓到 8GB。但換個(gè)角度想你真正的訴求并不是“必須跑某個(gè) 700GB 模型”而是“希望在本地硬件上得到接近大模型的效果”那就有操作空間了。我推薦的路線(xiàn)是四步走。第一步選擇一個(gè)開(kāi)源的大模型作為“教師”可以是 70B 級(jí)別甚至是 API 形態(tài)的更大模型。第二步用蒸餾技術(shù)把教師模型的推理能力遷移到一個(gè) 7B 或者 3B 的小模型上。第三步對(duì)蒸餾后的小模型做 INT4/INT8 量化。第四步在 8GB 顯卡上用 llama.cpp 或 Ollama 部署量化后的模型。每一步都有成熟的工具難點(diǎn)不在選型而在理解每步到底在干什么。2. 量化最容易見(jiàn)效的顯存“減重”手段2.1 量化在做一件什么事精度換體積的底層邏輯量化這件事本質(zhì)上是把連續(xù)分布的浮點(diǎn)數(shù)映射到離散的整數(shù)區(qū)間。原始模型權(quán)重大多數(shù)是 FP16 或 BF16 格式數(shù)值范圍寬、精度高但每個(gè)數(shù)字都要占 2 字節(jié)。量化之后權(quán)重變成 INT81字節(jié)或 INT40.5字節(jié)顯存直接砍半甚至砍到四分之一。但問(wèn)題也出在這里。量化不是簡(jiǎn)單地把大數(shù)變小而是要保證“離散化”之后模型的輸出分布盡量接近原始分布。如果直接四舍五入那些數(shù)值很小的權(quán)重會(huì)被直接抹成 0模型推理結(jié)果會(huì)產(chǎn)生大量噪聲嚴(yán)重時(shí)整段輸出都是亂碼。所以業(yè)界提出了很多量化算法本質(zhì)都是在解決同一個(gè)問(wèn)題如何通過(guò)一個(gè)量化縮放系數(shù)和零點(diǎn)偏移讓有限位寬的整數(shù)能最大程度地表示原來(lái)的浮點(diǎn)數(shù)值范圍。你可以把它理解成把一張高清照片壓縮成 JPEG壓縮率越高肉眼可見(jiàn)的畫(huà)質(zhì)損失越明顯但好的壓縮算法會(huì)更聰明地保留人眼敏感的信息。2.2 主流量化類(lèi)型與工具PTQ、GPTQ、AWQ、GGUF/llama.cpp目前實(shí)際部署中最常用的量化方案可以分成兩大類(lèi)。第一類(lèi)是訓(xùn)練后量化PTQ拿已經(jīng)訓(xùn)練好的模型不需要重新訓(xùn)練直接用校準(zhǔn)數(shù)據(jù)算出量化參數(shù)。GPTQ 和 AWQ 都屬于這一類(lèi)它們各自有不同的權(quán)重處理策略。GPTQ 最早是針對(duì) GPU 推理設(shè)計(jì)的基于二階信息做逐層誤差補(bǔ)償量化后模型能用 Transformers 庫(kù)直接加載。AWQ 則是根據(jù)激活值的重要程度來(lái)保護(hù)敏感權(quán)重AWQ 在低 bit 下通常比 GPTQ 保留更多模型能力尤其是對(duì)話(huà)和代碼生成任務(wù)。第二類(lèi)是 GGUF 格式加 llama.cpp 生態(tài)。GGUF 是 llama.cpp 定義的一種模型封裝格式它把模型權(quán)重、分詞器、超參數(shù)打包在一起并內(nèi)置了多種量化等級(jí)。你在 Hugging Face 上看到的 Q4_K_M、Q5_K_S、Q8_0 這些后綴全部來(lái)自 GGUF 的量化命名體系。GGUF 系列的優(yōu)點(diǎn)是兼容 Ollama、llama.cpp、LM Studio 等各種本地推理工具且內(nèi)存管理做得非常細(xì)支持 CPU、GPU 混合推理。選型建議只有一個(gè)如果要在 8GB 顯卡上跑優(yōu)先找 GGUF 格式的模型從 Q4_K_M 或 Q5_K_M 開(kāi)始試。如果你是為了追求最低延遲、不想套 GGUF 這層殼再用 GPTQ/AWQ 的 4bit 版本。2.3 量化后的顯存怎么算一個(gè)公式快速估算關(guān)于顯存估算我給一個(gè)偏保守但很好用的公式權(quán)重顯存 模型參數(shù)量 × 每參數(shù)字節(jié)數(shù) 實(shí)際部署顯存 權(quán)重顯存 × 1.2 KV緩存每參數(shù)字節(jié)數(shù)按量化等級(jí)查FP16 是 2 字節(jié)INT8 是 1 字節(jié)INT4 是 0.5 字節(jié)。GGUF Q4_K_M 大體接近 0.55 到 0.6 字節(jié)因?yàn)樗牧炕瘔K里還混了一些更高精度的分量。舉例一個(gè) 7B 模型70億參數(shù)用 Q4_K_M 量化權(quán)重大約 70億 × 0.55 字節(jié) ≈ 3.85GB。加上 KV 緩存和其他臨時(shí)開(kāi)銷(xiāo)8GB 顯卡在 2048 token 上下文長(zhǎng)度下是能跑起來(lái)的實(shí)測(cè)顯存占用大約在 5GB 到 6.5GB 之間。再舉個(gè)例子13B 模型 Q4_K_M 量化后大約 7.2GB加載后 8GB 卡就非常緊張了幾乎沒(méi)給 KV 緩存留空間稍微加長(zhǎng)一點(diǎn)上下文就會(huì)直接 OOM。所以你也別迷信“7B 一定能跑”模型能不能上要看“量化后體積 目標(biāo)上下文長(zhǎng)度對(duì)應(yīng)的 KV 緩存”是否同時(shí)落進(jìn) 8GB。2.4 實(shí)際跑起來(lái)以后量化模型的質(zhì)量與速度經(jīng)驗(yàn)先說(shuō)我測(cè)試過(guò)的一組數(shù)據(jù)。同一個(gè) 7B 模型FP16 下顯存占用約 14GB生成速度大概 15 token/s這個(gè)速度依賴(lài)具體顯卡量化到 Q8_0 后顯存占用約 7.5GB速度提升到 22 token/s 左右再量化到 Q4_K_M 后顯存占用約 4GB速度能到 30 token/s 以上。速度提升來(lái)自?xún)煞矫嬉皇菣?quán)重體積變小顯存帶寬壓力下降二是更多層能完整放下 GPU不需要反復(fù)搬運(yùn)到 CPU。從質(zhì)量角度看Q8_0 和 FP16 的差異在絕大多數(shù)場(chǎng)景下幾乎感覺(jué)不出來(lái)Q5_K_M 損失也非常小日常對(duì)話(huà)、文本摘要這種任務(wù)完全夠用。但到 Q4_K_S 之后尤其是代碼生成和數(shù)學(xué)推理任務(wù)錯(cuò)誤率會(huì)有可感知的上升。如果你要跑的是知識(shí)問(wèn)答或者創(chuàng)意寫(xiě)作Q4 完全能忍但如果是寫(xiě)代碼或者做結(jié)構(gòu)化輸出我建議至少用 Q5_K_M。這個(gè)現(xiàn)象背后的原因不難理解代碼和數(shù)學(xué)對(duì)數(shù)值精度更敏感權(quán)重量化會(huì)破壞某些關(guān)鍵 token 的預(yù)測(cè)概率分布有時(shí)候一個(gè)小數(shù)點(diǎn)級(jí)別的誤差就把整段推理帶偏了。3. 蒸餾把大模型的“內(nèi)功”傳給小模型3.1 為什么直接量化和蒸餾不能互相替代量化是把參數(shù)精度降下來(lái)模型的參數(shù)量和網(wǎng)絡(luò)結(jié)構(gòu)完全不變蒸餾則是重新訓(xùn)練一個(gè)參數(shù)量更小的模型讓它的輸出模仿大模型。從效果上看量化不改變模型的知識(shí)容量只改變參數(shù)存儲(chǔ)和計(jì)算方式所以當(dāng)壓縮率過(guò)高時(shí)知識(shí)會(huì)因?yàn)楸磉_(dá)能力不夠而丟失。蒸餾則不然它是讓小模型把大模型“已經(jīng)學(xué)會(huì)的知識(shí)”重新學(xué)一遍雖然知識(shí)容量天生有限但在特定任務(wù)上可以做到很高的逼近程度。這就引出一個(gè)策略組合當(dāng)你手中的大模型大到量化也無(wú)法塞進(jìn)目標(biāo)顯存時(shí)不要死磕量化先把模型變小當(dāng)你完成蒸餾之后再用量化進(jìn)行最后一輪壓縮。很多開(kāi)源社區(qū)的小模型就是這么產(chǎn)出的一個(gè) 7B 模型蒸餾自 70B 模型再量化成 Q4部署在筆記本上。3.2 知識(shí)蒸餾的基本流程教師模型、學(xué)生模型、KL散度知識(shí)蒸餾這個(gè)概念最早由 Hinton 在 2015 年提出核心思想用一個(gè)比喻就能講明白教師模型像是一個(gè)經(jīng)驗(yàn)豐富的廚師學(xué)生模型像是一個(gè)剛?cè)胄械膶W(xué)徒。學(xué)徒光看菜譜原始訓(xùn)練數(shù)據(jù)學(xué)得慢但如果能有師傅在旁邊指導(dǎo)火候和調(diào)味進(jìn)步會(huì)快得多。具體到技術(shù)上蒸餾過(guò)程不是讓學(xué)生模型直接學(xué)大模型的正確答案hard label而是讓學(xué)生模型去擬合大模型輸出的概率分布soft label。教師對(duì)每個(gè) token 的輸出分布里不僅包含正確答案還包含錯(cuò)誤選項(xiàng)之間的相對(duì)概率關(guān)系這些“軟信息”才是學(xué)生真正要模仿的精華。蒸餾損失函數(shù)一般由兩部分組成學(xué)生模型與真實(shí)標(biāo)簽的交叉熵加上學(xué)生模型與教師模型輸出分布之間的 KL 散度。KL 散度衡量?jī)蓚€(gè)概率分布的差異數(shù)值越低說(shuō)明學(xué)生的預(yù)測(cè)越接近教師。你可以把 KL 散度理解成師生之間的距離度量蒸餾訓(xùn)練的過(guò)程就是不斷縮小這個(gè)距離。實(shí)戰(zhàn)中蒸餾一個(gè) 7B 模型的成本并不低哪怕是在單張 24GB 顯卡上也需要數(shù)天時(shí)間。所以如果你是個(gè)人玩家我更推薦直接使用社區(qū)已經(jīng)蒸餾好的小模型而不是自己從零蒸餾。3.3 實(shí)用蒸餾姿勢(shì)收集高質(zhì)數(shù)據(jù)、利用 API 蒸餾如果你確實(shí)需要定制蒸餾又受限于硬件最實(shí)用的姿勢(shì)是用 API 作為教師來(lái)進(jìn)行數(shù)據(jù)蒸餾也叫“模型自舉”。具體分三步第一步準(zhǔn)備一個(gè)高質(zhì)量種子數(shù)據(jù)集可以是你業(yè)務(wù)場(chǎng)景里的真實(shí)問(wèn)題也可以從公開(kāi)數(shù)據(jù)集中抽取。第二步把這些問(wèn)題發(fā)送給大模型 API讓教師模型輸出詳細(xì)回答。為了讓回答質(zhì)量更高我會(huì)在提示詞里要求模型給出推理步驟、結(jié)論和可能的邊界條件。第三步用這些“問(wèn)題-回答”對(duì)來(lái)微調(diào)一個(gè)開(kāi)源小模型這個(gè)過(guò)程叫 SFT監(jiān)督微調(diào)本質(zhì)上是讓學(xué)生模型記住教師模型的表達(dá)風(fēng)格和推理路徑。為了提升蒸餾效果你可以借鑒更強(qiáng)的思路讓教師模型同時(shí)輸出多個(gè)候選回答再?gòu)闹刑暨x最優(yōu)答案作為訓(xùn)練目標(biāo)這比單次輸出的噪聲更小。另外一個(gè)細(xì)節(jié)是不要把原始 prompt 直接丟給教師模型而是要經(jīng)過(guò)精心設(shè)計(jì)比如加一句“請(qǐng)?jiān)敿?xì)解釋你的推理步驟”這樣得到的回答包含更多中間邏輯學(xué)生模型能學(xué)到的東西更多。3.4 蒸餾之后的小模型為什么更容易量化蒸餾對(duì)小模型還有一個(gè)隱形好處它的輸出分布通常比從零訓(xùn)練的小模型更平滑、更集中。這個(gè)特性對(duì)量化極其友好因?yàn)榱炕`差主要發(fā)生在那些數(shù)值尺度差異過(guò)大的權(quán)重上而經(jīng)過(guò)蒸餾輸出的模型很多層都已經(jīng)學(xué)會(huì)了用更簡(jiǎn)潔的表示來(lái)解決同一類(lèi)問(wèn)題權(quán)重分布更均勻量化時(shí)信息損失就會(huì)更小。我在實(shí)際測(cè)試中發(fā)現(xiàn)同一個(gè) 7B 架構(gòu)如果訓(xùn)練數(shù)據(jù)來(lái)自從零訓(xùn)練INT4 量化后準(zhǔn)確率可能下降 3% 到 5%但如果是蒸餾自 70B 教師模型的 7BINT4 量化后準(zhǔn)確率下降通常能控制在 1% 到 2%。這說(shuō)明蒸餾和量化之間確實(shí)存在正向協(xié)同效應(yīng)蒸餾后的模型不僅僅是“更小”它在量化后也能保留更多有效知識(shí)。4. 實(shí)操路線(xiàn)8G 顯存機(jī)的完整選擇與部署4.1 先做一道減法題不同規(guī)模模型對(duì)應(yīng)的量化后體積設(shè)備是 8GB所以推理時(shí)大概率還要留出一些顯存給圖形界面和其他程序。根據(jù)我長(zhǎng)期壓測(cè)的經(jīng)驗(yàn)?zāi)Ｐ图虞d后的總占用最好控制在 6GB 以?xún)?nèi)留 2GB 給系統(tǒng)緩存和臨時(shí)峰值否則在對(duì)話(huà)過(guò)程中極易觸發(fā) OOM。給你一張可以直接對(duì)照的表按不同參數(shù)的模型和量化等級(jí)估算一下“加載后模型權(quán)重體積”模型參數(shù)量FP16體積Q8_0體積Q5_K_M體積Q4_K_M體積1.5B3.0GB1.5GB0.95GB0.85GB3B6.0GB3.0GB1.9GB1.7GB7B14GB7.0GB4.3GB3.9GB8B16GB8.0GB5.0GB4.5GB13B26GB13GB8.2GB7.2GB從這張表能直接得出結(jié)論想在 8GB 顯存上留足上下文空間首選 7B 量級(jí)模型配 Q4_K_M 或者 Q5_K_M或者 3B 模型配 Q8_0。13B 模型即使量化到 Q4_K_M加載后權(quán)重已經(jīng) 7.2GB幾乎把顯存占滿(mǎn)了KV 緩存稍微變長(zhǎng)就會(huì)溢到 CPU速度斷崖式下跌。4.2 部署工具鏈選擇與安裝Ollama / llama.cpp GGUF本地部署這塊我的常用組合是 GGUF 格式加 llama.cpp或者直接用 Ollama。Ollama 本質(zhì)上是對(duì) llama.cpp 的封裝安裝簡(jiǎn)單命令友好。下載模型后一條命令就能啟動(dòng)交互式對(duì)話(huà)。它的優(yōu)點(diǎn)是省心適合用來(lái)快速驗(yàn)證一個(gè)量化模型能不能跑缺點(diǎn)是它的底層參數(shù)暴露得不夠多如果你想精細(xì)控制 KV cache 和 GPU 層數(shù)還是要回到 llama.cpp。llama.cpp 的使用思路是先從 Hugging Face 下載 GGUF 文件然后用 llama-cli 加載。如果你改了量化等級(jí)也可以用 llama.cpp 自帶的 convert 腳本重新量化。不過(guò)個(gè)人建議直接在 HF 上找別人量化好的 GGUF社區(qū)量化版本的質(zhì)量通常經(jīng)過(guò)大范圍測(cè)試比自己量化更穩(wěn)。4.3 加載模型時(shí)的關(guān)鍵參數(shù)ctx長(zhǎng)度、KV cache與層數(shù)分配8GB 顯存環(huán)境下要盯住的參數(shù)有三個(gè)上下文長(zhǎng)度、GPU 層數(shù)和 Flash Attention。上下文長(zhǎng)度決定 KV 緩存的大小。KV cache 的粗略公式是2 × 層數(shù) × 注意力頭維度 × 上下文長(zhǎng)度 × 每字節(jié)數(shù)。以 7B Q4 模型為例假設(shè) 32 層、KV cache 用 FP16上下文 2048 tokenKV cache 大約占 0.5GB 到 1GB。如果拉到 8192這部分會(huì)漲到 2GB 以上稍不留神就把顯存吃光了。所以我的經(jīng)驗(yàn)是8GB 顯卡跑 7B 模型上下文長(zhǎng)度先設(shè) 2048能跑通以后再加長(zhǎng)。不要一上來(lái)就追求 32K 上下文大概率換來(lái)的是 OOM 或者無(wú)限等待。GPU 層數(shù)決定模型計(jì)算有多少放在顯卡上。llama.cpp 支持-ngl參數(shù)指定 GPU 加載的層數(shù)。對(duì) 8GB 卡可以先從 ngl32 試起把一部分層加載到顯存如果 OOM就降 ngl 到 24 或 16剩余層由 CPU 計(jì)算?；旌贤评淼乃俣炔豢斓偙韧耆懿黄饋?lái)強(qiáng)。提示Ollama 環(huán)境里可以直接在模型文件里設(shè)置參數(shù)比如num_ctx控制上下文長(zhǎng)度num_gpu控制 GPU 層數(shù)。用/set parameter命令可以臨時(shí)設(shè)置重啟后失效。4.4 我的實(shí)戰(zhàn)配置參考不同任務(wù)怎么選量化等級(jí)我自己跑過(guò)的組合里有三個(gè)配置比較滿(mǎn)意。日常聊天和內(nèi)容創(chuàng)作我用的是 7B 模型的 Q5_K_M 版本上下文 4096GPU 層數(shù)全開(kāi)首 token 延遲大約 0.8 秒流暢度可以接受。代碼生成和結(jié)構(gòu)化輸出我換成了 Q8_0 版本的 3B 模型顯存占用更少精度更高生成的代碼格式更穩(wěn)定不會(huì)經(jīng)常出現(xiàn)縮進(jìn)錯(cuò)亂或函數(shù)名拼寫(xiě)錯(cuò)的情況。如果只是偶爾跑一些簡(jiǎn)單任務(wù)比如文本摘要、郵件潤(rùn)色我會(huì)直接用 1.5B 蒸餾模型的 Q4_K_M加載速度快顯存占用不到 1GB可以跟其他程序共存。雖然能力有限但勝在輕巧。5. 常見(jiàn)問(wèn)題與避坑記錄5.1 為什么量化后輸出全是噪聲或胡言亂語(yǔ)量化模型輸出亂碼90% 的情況是權(quán)重沒(méi)有正確加載比如模型文件不完整或者 GGUF 格式與 llama.cpp 版本不匹配。另外如果你用的是自己轉(zhuǎn)換的 GGUF 文件轉(zhuǎn)換前一定確認(rèn)原始模型格式是 Hugging Face transformers 結(jié)構(gòu)并確保分片文件下載完整。從頭開(kāi)始檢查時(shí)先去跑一個(gè)官方示例模型比如 LLaMA 或 Qwen 的官方 GGUF確認(rèn)工具鏈沒(méi)問(wèn)題再排查自己下載的文件有沒(méi)有對(duì)齊分片。我在早期犯過(guò)這種錯(cuò)下載 70B 模型時(shí)少下了一個(gè)分片文件加載卻順利通過(guò)直到推理輸出中文變成亂碼才發(fā)現(xiàn)。5.2 8G顯存加載小模型還是OOM優(yōu)先檢查上下文長(zhǎng)度如果你加載 3B 模型 Q4 還 OOM那大概率不是權(quán)重放不下而是上下文長(zhǎng)度設(shè)置太大了。很多 Ollama 用戶(hù)的默認(rèn)上下文是 4096 甚至 8192KV cache 和中間激活值很容易把顯存塞滿(mǎn)。解決辦法很簡(jiǎn)單先把上下文調(diào)到 1024確認(rèn)能跑通再逐步往上加。同時(shí)可以開(kāi) Flash Attention它能減少 KV cache 的顯存占用4 到 8GB 顯存環(huán)境下收益特別明顯。5.3 量化程度越高越省顯存不一定還得看速度與質(zhì)量Q4 一定比 Q8 省顯存這是對(duì)的但并不代表 Q4 一定更好用。量化等級(jí)越低占用的顯存越少但推理速度不一定線(xiàn)性提升因?yàn)楝F(xiàn)代顯卡更依賴(lài)帶寬但也會(huì)受解碼開(kāi)銷(xiāo)影響低 bit 量化需要額外的反量化計(jì)算。實(shí)測(cè)中 Q4_K_M 和 Q5_K_M 的速度差異不大但 Q4 的質(zhì)量損失卻更明顯。所以在不追求極限顯存的情況下我會(huì)優(yōu)先選擇 Q5_K_M。它比 Q4_K_M 只重幾百 MB但回答質(zhì)量和穩(wěn)定性高了不止一個(gè)檔次這是性?xún)r(jià)比極高的一次取舍。5.4 蒸餾需要多少數(shù)據(jù)才夠這個(gè)問(wèn)題沒(méi)有標(biāo)準(zhǔn)答案取決于任務(wù)復(fù)雜度。我給一個(gè)參考區(qū)間如果你的任務(wù)是讓一個(gè)小模型模仿大模型的對(duì)話(huà)風(fēng)格5000 到 20000 條高質(zhì)量對(duì)話(huà)數(shù)據(jù)就夠了如果是做復(fù)雜推理或代碼生成可能需要 5 萬(wàn)條以上并且數(shù)據(jù)質(zhì)量比數(shù)量更重要。另外蒸餾過(guò)程不要盲目追求多個(gè) epoch。小模型參數(shù)量有限過(guò)度訓(xùn)練容易過(guò)擬合到訓(xùn)練數(shù)據(jù)反而會(huì)在未見(jiàn)過(guò)的任務(wù)上表現(xiàn)更差。我在跑蒸餾實(shí)驗(yàn)時(shí)一般先訓(xùn) 1 到 2 個(gè) epoch用驗(yàn)證集觀(guān)察 loss 曲線(xiàn)一旦驗(yàn)證 loss 不再下降就及時(shí)停止。6. 寫(xiě)在最后幾個(gè)實(shí)用心得這些年在低顯存設(shè)備上折騰大模型最深的感受是顯存不夠不等于玩不了大模型但它會(huì)倒逼你更清楚地理解大模型的存儲(chǔ)結(jié)構(gòu)和推理機(jī)制。量化讓你懂模型權(quán)重在說(shuō)什么蒸餾讓你懂模型能力是怎么傳遞的這兩樣搞明白之后再回頭看不帶量化的原版模型你對(duì)性能瓶頸的理解會(huì)完全不一樣。最后分享一個(gè)我自己踩過(guò)多次的坑下載 GGUF 模型時(shí)一定要仔細(xì)核對(duì)文件名中的量化等級(jí)不要混淆了 Q4_K_M 和 Q4_K_S。這兩個(gè)體積對(duì)比差距不大但 Q4_K_S 的質(zhì)量損失明顯更高。如果你不確定該選哪個(gè)記一個(gè)簡(jiǎn)單規(guī)律手頭顯存夠就上 Q8_0顯存緊張就選 Q5_K_M只有極度緊張才用 Q4_K_MQ4_K_S 能不用就不用。對(duì)了如果你跑 Ollama 時(shí)遇到模型推理速度很慢先看一眼是不是模型被完全放到了 CPU 上。Ollama 默認(rèn)會(huì)根據(jù)系統(tǒng)顯存自動(dòng)分配加載層數(shù)但在某些環(huán)境下它可能過(guò)度保守。手動(dòng)加一行num_gpu 999讓模型盡量全量加載到顯卡速度會(huì)有質(zhì)的飛躍。