8GB顯存跑35B模型這句話放在三年前說出去多半會(huì)被當(dāng)成吹牛。那時(shí)候本地部署大模型的主流思路是“裝得下才跑得動(dòng)”顯存不夠直接出局更別提8GB這種消費(fèi)級(jí)甜品卡的容量了?？蛇@兩年量化技術(shù)和推理框架成熟之后一臺(tái)普通游戲電腦干這件事已經(jīng)不再是天方夜譚我自己就在一張RTX 4060 8GB上跑通了Qwen2.5-32B和GLM-4-32B這類大參數(shù)模型體驗(yàn)雖然談不上絲滑但真的能用。這篇文章不談云服務(wù)器、不聊企業(yè)級(jí)A100只圍繞“消費(fèi)級(jí)顯卡本地大模型實(shí)測”這件事把8GB顯存跑35B模型的原理、工具、實(shí)測數(shù)據(jù)、踩坑經(jīng)歷和后續(xù)接入Dify的玩法完整梳理一遍。如果你是手里只有一張普通顯卡、又想讓本地跑起大模型的玩家或開發(fā)者這篇文章能讓你少走不少彎路。1. 為什么8GB顯存能跑35B模型先把賬算明白1.1 35B模型到底需要多少資源先說一個(gè)最容易被忽略的基礎(chǔ)點(diǎn)模型參數(shù)和顯存之間到底是什么關(guān)系。35B的意思是模型有350億個(gè)參數(shù)。按照最常見的FP16半精度存儲(chǔ)每個(gè)參數(shù)占2字節(jié)350億參數(shù)至少需要70GB空間。如果直接用FP16精度把模型全部加載到顯存里別說是8GB就算是單張RTX 4090都裝不下必須要上多卡服務(wù)器。這就是很多人一聽“8GB跑35B”就覺得不靠譜的原因——按原始精度來算它確實(shí)不可能。但這里有個(gè)關(guān)鍵誤區(qū)本地推理并不要求模型“完整塞進(jìn)顯存”。顯存負(fù)責(zé)的是模型層在前向傳播時(shí)的計(jì)算緩存內(nèi)存則可以兜底存儲(chǔ)暫時(shí)不參與計(jì)算的權(quán)重。算法上大語言模型的推理是逐層進(jìn)行的每一層只在一個(gè)很小的時(shí)刻被使用。因此只要調(diào)度得當(dāng)完全可以把一部分層放在顯存、一部分層放在內(nèi)存CPU和GPU協(xié)作完成推理。這個(gè)思路是本地大模型能在低顯存設(shè)備上跑起來的核心前提也是后面所有實(shí)操的地基。1.2 量化是讓“跑不起”變成“跑得慢”的關(guān)鍵量化可以理解成把模型參數(shù)的精度“降格”存儲(chǔ)。就好比一張照片用無損格式存要10MB壓縮成質(zhì)量稍低的JPG只占3MB肉眼看上去差別不大。模型量化也是類似的邏輯原本FP16精度的權(quán)重占2字節(jié)量化成4bit后只占0.5字節(jié)體積直接變成四分之一。當(dāng)前最主流的是GGUF格式的4bit量化常見方案包括Q4_0、Q4_K_M等。以32B模型為例原始FP16版本大約64GB量化到Q4_K_M后大約19GB到20GB。雖然對(duì)8GB顯存來說還是放不下但已經(jīng)比70GB小得多而且20GB這個(gè)規(guī)模是可以和系統(tǒng)內(nèi)存配合加載的。35B模型的理論量化體積也就在20GB出頭屬于“內(nèi)存能裝下、顯存能沾光”的區(qū)間。量化后的模型在推理質(zhì)量上會(huì)有一點(diǎn)損失但如今的K-quant量化方案在4bit水平上已經(jīng)能把損失控制得很小。日常對(duì)話、寫代碼、做知識(shí)問答跟原版模型比沒有天壤之別幾十層Transformer堆出來的語義能力基本保留住了。1.3 顯存不夠時(shí)內(nèi)存來湊再看另一本賬。假設(shè)模型量化后是20GBGPU可用顯存只有8GB那么至少有12GB需要放到系統(tǒng)內(nèi)存里。推理時(shí)GPU負(fù)責(zé)前幾層的計(jì)算CPU負(fù)責(zé)剩余層這就叫“異構(gòu)計(jì)算”或者“層卸載”。具體到實(shí)現(xiàn)上Ollama這類推理框架會(huì)有一個(gè)“GPU層數(shù)”參數(shù)。默認(rèn)情況下它會(huì)自動(dòng)檢測顯存容量和模型尺寸把盡量多的層放到GPU上放不下了就把剩余層放在CPU側(cè)。每處理一個(gè)token數(shù)據(jù)要走一遍所有層因此GPU和CPU之間會(huì)有反復(fù)的數(shù)據(jù)搬運(yùn)。這就是低顯存跑大模型時(shí)速度上不去的核心原因算力不是瓶頸跨界傳輸才是。這也是為什么你會(huì)在任務(wù)管理器里看到“共享GPU內(nèi)存”和“系統(tǒng)內(nèi)存”同時(shí)飆升。其實(shí)Windows的WDDM驅(qū)動(dòng)機(jī)制會(huì)把一部分系統(tǒng)內(nèi)存模擬成共享顯存讓GPU可以間接訪問但性能遠(yuǎn)不如板載顯存。這個(gè)機(jī)制對(duì)“能跑”很有幫助對(duì)“跑得快”則沒啥幫助后面實(shí)測數(shù)據(jù)里會(huì)看到它的實(shí)際影響。1.4 現(xiàn)實(shí)中真正能跑到什么效果在動(dòng)手之前建議先把期望值調(diào)整到正確的位置8GB顯存跑35B模型能保證的是“可以完整對(duì)話、可以寫長文本、可以做推理分析”不能保證的是“秒回”。在普通消費(fèi)級(jí)配置上這類模型的生成速度通常在4到8 token/s之間也就是每秒鐘蹦出四到八個(gè)漢字或單詞肉眼看上去像是對(duì)方在手速不快地打字。如果只是用來做問答、總結(jié)文檔、輔助編程這個(gè)速度完全是可用的。但如果想拿來做實(shí)時(shí)翻譯或者流式輸出聊天體驗(yàn)?zāi)菚?huì)更適合退一步用7B或14B模型全量放進(jìn)顯存跑速度能到20到40 token/s。所謂“小模型干小事、大模型干重活”選擇哪個(gè)參數(shù)量本質(zhì)上是在速度和效果之間做取舍。2. 實(shí)測前的準(zhǔn)備一臺(tái)普通游戲電腦就夠了2.1 我的實(shí)測環(huán)境說清楚一點(diǎn)這次實(shí)測用的不是什么特挑硬件就是一臺(tái)普通家用游戲電腦配置放在現(xiàn)在勉強(qiáng)算中端水平GPURTX 4060 8GB顯存CPUi5-13490F中端六核十二線程內(nèi)存32GB DDR4 3200MHz雙通道系統(tǒng)Windows 11 22H2存儲(chǔ)NVMe固態(tài)硬盤倉庫盤備了60GB以上空間這套配置最接近大多數(shù)準(zhǔn)備嘗試本地大模型的玩家。如果你手頭是RTX 3060 12GB或者RTX 4070體驗(yàn)會(huì)更好但思路完全一致。如果內(nèi)存只有16GB跑30B以上模型會(huì)比較緊張建議優(yōu)先試14B級(jí)別。磁盤空間必須提前看一眼。35B級(jí)別模型的4bit量化文件就有20GB左右加上官方庫的暫存文件一次性至少預(yù)留40GB空間。很多人在下載中途發(fā)現(xiàn)空間不夠又得清盤重來非常浪費(fèi)時(shí)間。2.2 為什么用Ollama而不是別的方案本地推理框架的選擇其實(shí)不少llama.cpp本身也能直接用還有LM Studio這類帶圖形界面的工具。但我實(shí)際用下來還是推薦Ollama理由很簡單配置成本最低且對(duì)Windows支持很友好。Ollama會(huì)把模型的量化格式、層數(shù)分配、交互方式都封裝成極簡的操作。安裝完系統(tǒng)服務(wù)后只需要在終端執(zhí)行一條pull或run命令就能把模型拉下來跑不需要手動(dòng)去處理GGUF文件里的各種量化標(biāo)記也不需要折騰Python環(huán)境。如果你已經(jīng)用llama.cpp或者Transfromers跑了很久用Ollama也不虧因?yàn)樗诘讓油瑯踊趌lama.cpp的GGML推理方案效率上沒有明顯短板。Ollama最值錢的地方在于抽象了一層模型倉庫想切換模型版本的時(shí)候非常方便。另外Ollama自帶了一個(gè)與OpenAI兼容的HTTP接口即時(shí)不裝任何額外服務(wù)Dify、FastGPT這類應(yīng)用也能直接接入。這一點(diǎn)后面再說。2.3 模型與量化版本怎么選去Ollama模型庫搜索時(shí)你會(huì)發(fā)現(xiàn)有不少30B到35B區(qū)間的寶藏模型比如官方源里的Qwen2.5-32B-Instruct、GLM-4-32B還有一些社區(qū)調(diào)的獨(dú)立35B微調(diào)模型命名五花八門。這次實(shí)測我主要跑兩款Qwen2.5-32B和GLM-4-32B。標(biāo)題里說的35B不是死磕某個(gè)具體模型而是泛指這一檔參數(shù)量級(jí)別。如果你是剛開始接觸建議直接從Qwen2.5-32B入手因?yàn)樗闹形闹噶钭裱芰軓?qiáng)量化兼容性也成熟。Ollama拉取的默認(rèn)版本選擇比較保守執(zhí)行ollama pull qwen2.5:32b-instruct拿到的就是官方推薦的4bit量化版。如果你想自己指定更細(xì)的GGUF方案可以用ollama create結(jié)合本地GGUF文件來構(gòu)建但對(duì)于大多數(shù)人來說官方默認(rèn)版就夠了。花更多時(shí)間折騰量化參數(shù)不如把折騰時(shí)間拿去多驗(yàn)證幾個(gè)使用場景。3. 完整實(shí)測過程從下載到對(duì)話3.1 下載模型并觀察資源變化一切準(zhǔn)備就緒后實(shí)際操作從終端開始。打開PowerShell執(zhí)行ollama pull qwen2.5:32b-instruct第一次拉取需要等一段時(shí)間20GB左右的數(shù)據(jù)量要看網(wǎng)速快的話五六分鐘慢的話半小時(shí)。下載完成后直接執(zhí)行ollama run qwen2.5:32b-instruct啟動(dòng)階段它會(huì)先加載模型權(quán)重。因?yàn)?GB顯存放不下完整的20GB模型所以加載過程需要一段時(shí)間我的機(jī)器上大概花了1分40秒左右。不要懷疑是不是卡死了只要看到內(nèi)存占用在漲、CPU有負(fù)載就是在加載。趁這個(gè)時(shí)間打開任務(wù)管理器重點(diǎn)盯三塊GPU顯存、共享GPU內(nèi)存、系統(tǒng)內(nèi)存。加載完成后我觀察到大約是7.1GB專用顯存被占用共享GPU內(nèi)存占用了9GB左右系統(tǒng)內(nèi)存總體占用比空閑時(shí)高出15GB以上。整個(gè)過程基本印證了“一部分權(quán)重在顯存、一部分在內(nèi)存”的判斷。3.2 調(diào)整加載層數(shù)找到自己的甜點(diǎn)位Ollama默認(rèn)會(huì)自動(dòng)分配GPU層數(shù)但在Windows下不一定是最優(yōu)解。想手動(dòng)控制需要設(shè)置環(huán)境變量OLLAMA_GPU_LAYERS然后重啟Ollama服務(wù)setx OLLAMA_GPU_LAYERS 14重啟Ollama的方式是把后臺(tái)托盤圖標(biāo)里的Ollama退出然后重新執(zhí)行ollama run即可。為什么要強(qiáng)調(diào)這個(gè)參數(shù)因?yàn)樗苯記Q定了顯存是否過載。如果你把加載層數(shù)設(shè)得太高比如一次往8GB顯存里塞太多層會(huì)立刻出現(xiàn)顯存分配失敗模型直接報(bào)錯(cuò)退出。反之設(shè)得太低GPU利用率不足速度會(huì)明顯變慢。我在RTX 4060 8GB上試了幾個(gè)數(shù)值18的時(shí)候運(yùn)行較快但偶發(fā)OOM14比較穩(wěn)10則明顯拖慢生成速度。最終鎖定14層相當(dāng)于把模型的前四分之一放在GPU上其余交給CPU處理。不同顯卡的甜點(diǎn)位不一樣建議從低往高試遇到OOM就降兩層。3.3 生成速度、質(zhì)量和體驗(yàn)進(jìn)入對(duì)話后我先問了一個(gè)簡單問題“寫一段關(guān)于本地大模型部署的300字介紹。”觀察到的輸出速度穩(wěn)定在6 token/s上下生成完300字大概用了45秒中間沒有中斷。這個(gè)速度意味著什么呢如果你用慣了ChatGPT那種瀑布式輸出會(huì)覺得它慢。但實(shí)際體驗(yàn)下來6 token/s已經(jīng)足夠支撐你邊看邊思考不太會(huì)影響創(chuàng)作類任務(wù)的流暢度。模型輸出的內(nèi)容質(zhì)量超出預(yù)期條理清楚中文表達(dá)自然沒有出現(xiàn)明顯的語序崩壞。接著我用代碼補(bǔ)全和數(shù)學(xué)邏輯題做了測試。代碼方面讓它寫一個(gè)Python函數(shù)實(shí)現(xiàn)目錄遍歷輸出結(jié)構(gòu)完整、注釋清晰邏輯題方面一個(gè)帶有隱含條件的題目也能答到點(diǎn)子上。能被量化保持到這個(gè)水平說明4bit方案對(duì)32B級(jí)別模型的語義能力保留得確實(shí)不錯(cuò)。順帶提一句溫度參數(shù)不建議在低顯存跑大模型時(shí)調(diào)太高。本地推理本來就要等如果模型因?yàn)楦邷囟蠓l(fā)散一個(gè)簡單問題來回改半天體驗(yàn)會(huì)很差。默認(rèn)溫度0.7是個(gè)不錯(cuò)的選擇。3.4 上下文長度的影響這是很多人玩兩天后才會(huì)遇到的門檻模型加載正常、對(duì)話也正常但聊到一定輪數(shù)之后它突然像失憶了一樣前面說過的東西全忘光了。原因很簡單上下文窗口默認(rèn)只有4096個(gè)token也就是大約兩千到三千個(gè)漢字超過這個(gè)量最老的內(nèi)容就會(huì)被丟棄。如果想讓上下文長一點(diǎn)可以用參數(shù)調(diào)整/set parameter num_ctx 8192把上下文翻倍之后內(nèi)存和顯存占用會(huì)同時(shí)上漲。實(shí)測從4096擴(kuò)到8192后共享GPU內(nèi)存多了大概2GB系統(tǒng)內(nèi)存也漲了一截。對(duì)8GB顯存來說2GB的共享內(nèi)存增量還好但如果你同時(shí)把加載層數(shù)調(diào)得很高就有OOM風(fēng)險(xiǎn)。我的建議是優(yōu)先保住層數(shù)上下文保持在4096到6144之間夠日常用就行。更長上下文的代價(jià)會(huì)成倍增長因?yàn)镵V Cache的大小跟上下文長度正相關(guān)。8GB顯存跑32B本身留給KV Cache的空間就很小硬開16384上下文只會(huì)讓推理慢到不可接受。這不是模型能力不行是硬件邊界接受它就好。4. 實(shí)操避坑常見報(bào)錯(cuò)與排查方法4.1 顯存不足或OOM這是所有低顯存玩家最容易遇到的第一個(gè)坑。表現(xiàn)是執(zhí)行ollama run后加載到一半報(bào)類似“failed to allocate memory”的錯(cuò)誤或者Ollama服務(wù)后臺(tái)崩掉。原因基本都是GPU層數(shù)設(shè)置過高或者電腦上還有其他程序占顯存。排查思路很簡單關(guān)掉瀏覽器硬件加速、關(guān)閉Stream Dock等第三方渲染工具再把OLLAMA_GPU_LAYERS往下調(diào)。一次調(diào)2層直到能穩(wěn)定啟動(dòng)為止。如果顯存占用明明很低還是報(bào)OOM檢查一下Windows有沒有啟用“硬件加速GPU計(jì)劃”這個(gè)設(shè)置在某些驅(qū)動(dòng)版本下會(huì)導(dǎo)致顯存預(yù)留異常。4.2 回答慢到懷疑人生如果生成速度掉到2 token/s以下通常不是模型量化的問題而是內(nèi)存帶寬和CPU算力成了瓶頸?？梢韵瓤慈蝿?wù)管理器CPU占用是否接近滿載答案是“是”的話說明大部分層在CPU側(cè)計(jì)算這時(shí)把層數(shù)調(diào)高反而可能會(huì)因?yàn)楦囡@存參與而提速。但也要注意很多CPU的AVX2或者AVX512指令集對(duì)llama.cpp的推理效率影響很大。新一點(diǎn)的CPU自帶AVX512速度比老平臺(tái)有明顯優(yōu)勢。如果你的CPU本身性能較弱8GB跑32B可能只能拿到3到4 token/s這是硬件天花板的限制不是配置問題。另一個(gè)常被忽視的因素是內(nèi)存通道數(shù)。雙通道內(nèi)存比單通道快接近一倍因?yàn)槊看巫x寫權(quán)重的數(shù)據(jù)量極大內(nèi)存帶寬幾乎直接決定吞吐。建議至少組成雙通道性能提升立竿見影。4.3 對(duì)話一長就失憶本質(zhì)就是上下文窗口被截?cái)?。如果你想保留更長的歷史就必須接受更大的KV Cache代價(jià)。開8192上下文實(shí)測還可以用開16384就明顯吃力了。有一種妥協(xié)方案是使用“分段式對(duì)話”每次提問前把關(guān)鍵背景用一兩句話重新描述不讓模型必須從舊上下文里回憶。對(duì)于8GB顯存的場景這個(gè)習(xí)慣比你無腦調(diào)大上下文窗口更實(shí)用。4.4 不同參數(shù)量的速度對(duì)比為了給自己一個(gè)坐標(biāo)我順手測了同環(huán)境下7B和14B模型的速度。結(jié)果如下表方便你根據(jù)實(shí)際需求選擇模型量化格式GPU占用平均速度體驗(yàn)Qwen2.5-7BQ4_K_M約4.5GB32 token/s流暢適合對(duì)話Qwen2.5-14BQ4_K_M約7.5GB18 token/s較流暢效果尚可Qwen2.5-32BQ4_K_M約7.1GB9GB共享6 token/s偏慢但效果更好從表里能看出一個(gè)趨勢14B模型基本是8GB顯存全能跑的極限甜點(diǎn)速度和效果非常均衡32B則是追求效果的上限代價(jià)是速度折半。35B模型的情形與32B基本一致所以把標(biāo)題里的“8GB跑35B”理解成“能啟動(dòng)、能對(duì)話、不能秒回”的標(biāo)桿就行。5. 這個(gè)能力還能怎么用接入Dify與場景擴(kuò)展5.1 本地大模型接入Dify本地模型跑起來之后最大的樂趣是把能力交給應(yīng)用層去調(diào)用。這里分享一下Ollama接入Dify的方式這也是最近問得很多的一個(gè)方向。Ollama啟動(dòng)后默認(rèn)監(jiān)聽的端口是11434并提供了一個(gè)OpenAI兼容的HTTP接口。在Dify的自定義模型里選擇“OpenAI API compatible”填寫API Endpoint: http://localhost:11434/v1 API Key: ollama Model ID: qwen2.5:32b-instruct這里API Key是占位符隨便填一個(gè)非空字符串就可以。配置完成后Dify就能把該模型當(dāng)作標(biāo)準(zhǔn)OpenAI接口模型來調(diào)用。你可以把它放到工作流里做知識(shí)庫回復(fù)生成不需要購買任何云服務(wù)。需要提醒的是消費(fèi)級(jí)顯卡上的本地模型并發(fā)能力極其有限。Dify如果有多個(gè)工作流同時(shí)請(qǐng)求Ollama會(huì)排隊(duì)處理單個(gè)請(qǐng)求的等待時(shí)間會(huì)被拉得很長。如果你的場景是個(gè)人助手、研究型使用完全沒問題但如果是多人團(tuán)隊(duì)同時(shí)使用建議只把它接到低并發(fā)的內(nèi)部工具里。5.2 怎么理解“去掉限制”網(wǎng)上經(jīng)?？吹健癆I本地大模型去掉限制”的說法其實(shí)不玄乎。大多數(shù)情況下指的是兩件事一是把Ollama對(duì)CPU加載層數(shù)等運(yùn)行參數(shù)的限制放開二是把上下文長度、響應(yīng)超時(shí)等默認(rèn)參數(shù)調(diào)寬。比如在Shell里設(shè)置環(huán)境變量setx OLLAMA_NUM_PARALLEL 1 setx OLLAMA_MAX_LOADED_MODELS 1 setx OLLAMA_CONTEXT_LENGTH 6144這幾個(gè)參數(shù)能約束Ollama在8GB顯存機(jī)器上的行為避免它因?yàn)殄e(cuò)誤估計(jì)資源而做出不合理的調(diào)度?！叭サ粝拗啤辈⒉皇且研阅芴嵘胶腿藥兹f塊服務(wù)器一樣而是把默認(rèn)策略改成更適合自己硬件的方式。5.3 消費(fèi)級(jí)部署與企業(yè)部署的差異有人會(huì)問如果公司花二三十萬買了一堆硬件部署本地大模型運(yùn)維工作量會(huì)不會(huì)很大實(shí)際上會(huì)而且不低。企業(yè)級(jí)部署要考慮鑒權(quán)、多用戶并發(fā)、模型熱更新、GPU監(jiān)控、日志采集和故障恢復(fù)這些在消費(fèi)級(jí)單機(jī)場景里都是可以跳過的。正因如此個(gè)人玩本地模型反而更輕快一臺(tái)PC就能成為一個(gè)私有的模型服務(wù)。但我必須說一句實(shí)在話消費(fèi)級(jí)跑大模型的核心價(jià)值不是省錢也不完全是為了速度而是數(shù)據(jù)可控和自由折騰。模型跑完一次微調(diào)、調(diào)完幾個(gè)參數(shù)后整套管道就變成你自己的東西。這種從“使用者”變成“操作者”的過程才是這件事最讓人上癮的地方。回頭總結(jié)下我這段實(shí)測的過程從最開始被報(bào)錯(cuò)折磨到后來摸清OLLAMA_GPU_LAYERS和上下文窗口的關(guān)系再到Dify里成功發(fā)起第一輪本地模型對(duì)話整個(gè)過程花了一個(gè)晚上。踩坑越多對(duì)“顯存不夠也能跑大模型”這件事的理解就越到位。如果你也正要拿手頭這張消費(fèi)級(jí)顯卡去挑戰(zhàn)大參數(shù)模型希望這份實(shí)錄能讓你少試幾次錯(cuò)更快看到想要的輸出。