戰(zhàn)調(diào)優(yōu)指南)
8GB顯存跑35B參數(shù)的本地大模型這事聽起來就像用1TB的機(jī)械硬盤裝Windows能裝但誰信啊。我本來也不信直到自己動手在RTX 4060 8GB上把GLM-5.3-35B量化版跑起來還被群里人反復(fù)追問是不是偷偷用了云服務(wù)器。說實(shí)話我確實(shí)做好了全程看CPU慢慢擠牙膏的心理準(zhǔn)備但實(shí)測結(jié)果推翻了不少先入為主的判斷——消費(fèi)級顯卡本地大模型不是遙不可及8GB顯存跑35B級模型這件事雖然不像24GB旗艦卡那樣從容也確實(shí)有一條可復(fù)制的完整路徑。這篇文章就把這幾天的實(shí)測過程完整攤開怎么算顯存、怎么選量化、怎么調(diào)Ollama和llama.cpp、實(shí)際生成速度多少、踩了哪些坑以及Dify怎么把本地模型接進(jìn)工作流。如果你手頭也是一張8GB顯存的卡比如RTX 3050、3060、4060又不想為了跑個(gè)大模型就去租云GPU這篇實(shí)錄應(yīng)該能幫你省下至少一晚上的折騰時(shí)間。1. 為什么8GB跑35B聽起來像偽命題先把顯存賬單算清楚1.1 參數(shù)與顯存的樸素?fù)Q算35B模型默認(rèn)確實(shí)要70GB以上先說最基本的賬。模型的存儲和顯存占用通常按參數(shù)量乘以每個(gè)參數(shù)的字節(jié)數(shù)來估算。GLM-5.3-35B滿血版如果用FP16半精度浮點(diǎn)保存每個(gè)參數(shù)占2字節(jié)35B就是70GB。哪怕?lián)Q成BF16也還是這個(gè)數(shù)量級。70GB的模型單卡8GB自然是裝不下的這也是絕大多數(shù)人第一時(shí)間否決這個(gè)想法的根本原因。一張正經(jīng)的服務(wù)器顯卡比如A100 80GB才能做到無損加載。而消費(fèi)級顯卡里最頂?shù)腞TX 4090也就24GB8GB確實(shí)看起來差了太遠(yuǎn)。但這里很容易忽略一個(gè)前提模型放在內(nèi)存和顯存里不一定必須是FP16。從llama.cpp和Ollama流行起來之后量化這個(gè)詞被反復(fù)提及這條路就是從這打開的。1.2 量化用精度換體積失小得大的關(guān)鍵操作量化簡單說就是把模型權(quán)重從高精度數(shù)字壓縮到低精度數(shù)字。FP16的每個(gè)權(quán)重用16bit表示而量化后可以用4bit、5bit表示。聽起來像有損壓縮但實(shí)際效果比大多數(shù)人想的要好因?yàn)楝F(xiàn)在的GGUF量化不是簡單截?cái)喽菍?quán)重分組做縮放和補(bǔ)償把關(guān)鍵信息保留下來。市面上常見的量化等級量化等級每參數(shù)平均bit數(shù)35B模型落盤體積約體感質(zhì)量FP1616 bit70GB基準(zhǔn)Q8_08.5 bit37GB接近無損Q5_K_M5.5 bit24GB質(zhì)量很好Q4_K_M4.8 bit21GB甜點(diǎn)位Q3_K_M3.9 bit17GB明顯變傻Q2_K2.5 bit11GB基本沒法用我實(shí)測之后的感覺是Q4_K_M和FP16在普通問答、代碼生成上的差距很小有時(shí)甚至感覺不出來但降到Q3之后模型會開始答非所問邏輯鏈條斷裂。所以對8GB顯卡跑35B這件事Q4_K_M幾乎是唯一合理的選擇——體積21GB左右質(zhì)量損失控制在可接受范圍內(nèi)。1.3 KV Cache和臨時(shí)緩沖真正吃顯存的隱藏項(xiàng)量化把權(quán)重壓到21GB之后問題只解決了一半。推理過程中還有一個(gè)吃顯存的大戶叫KV Cache它用來緩存已生成內(nèi)容的注意力鍵值。上下文越長、模型層數(shù)越多KV Cache越大。GLM-5.3-35B這種體量的模型在8192上下文長度下KV Cache大約要占1.5到3GB具體取決于架構(gòu)細(xì)節(jié)。再加上CUDA context本身還要占幾百M(fèi)B到1GB顯存8GB顯存實(shí)際能用來裝權(quán)重的地方可能只剩6GB多一點(diǎn)。這意味著GPU最多只能承載35B模型的大約1/3層其余層數(shù)必須由CPU內(nèi)存承擔(dān)。這就是8GB能跑35B的另一個(gè)機(jī)制部分卸載或者說offload。拿我實(shí)測的配置來算筆賬Q4_K_M版本約21GB如果GPU加載其中30%的層大約6.3GB權(quán)重加上KV Cache和CUDA開銷剛好把8GB塞得很滿。CPU內(nèi)存?zhèn)纫袚?dān)剩下約15GB權(quán)重和約2GB KV Cache總共17GB左右。所以32GB內(nèi)存是起步門檻16GB大概率會卡到爆。這就是為什么8GB跑35B實(shí)際上不是偽命題而是顯存不夠內(nèi)存來湊的分布式解題思路。預(yù)算的分配重點(diǎn)也從買大顯存顯卡轉(zhuǎn)移到了買大容量高頻內(nèi)存。2. 實(shí)測配置與工具鏈這套組合最省心也最省錢2.1 硬件清單別小看內(nèi)存帶寬這次實(shí)測的硬件不是頂配反而是很典型的裝機(jī)配置部件型號備注GPURTX 4060 8GB還有一塊RTX 3050 8GB做對照CPUIntel i5-12490F6核12線程內(nèi)存32GB DDR4 3200雙通道雙通道必須開啟硬盤NVMe SSD 1TB模型落盤需要約22GB空間系統(tǒng)Windows 11 WSL2Ollama原生Windows版本為什么我反復(fù)強(qiáng)調(diào)內(nèi)存帶寬因?yàn)?GB顯存跑35B模型時(shí)大部分層其實(shí)跑在CPU內(nèi)存上。每生成一個(gè)token推理引擎都要把模型權(quán)重從頭到尾讀一遍。DDR4雙通道的帶寬大約25GB/s而GPU顯存帶寬有272GB/s。如果權(quán)限都在CPU側(cè)速度上限就被內(nèi)存帶寬卡死所以DDR5內(nèi)存或者四通道方案會有明顯優(yōu)勢。這也是后面調(diào)優(yōu)的核心邏輯。2.2 為什么主力用Ollama但llama.cpp也要裝Ollama現(xiàn)在的成熟度已經(jīng)很高了。它把模型下載、量化格式識別、GPU自動調(diào)度、API服務(wù)這些都封裝好了Windows下裝完就能用。我把它當(dāng)主力原因很樸素省事而且底層就是llama.cpp性能不會差太多。llama.cpp在我這里的定位是備用手術(shù)刀。當(dāng)我想手動指定GPU加載多少層、想查看更詳細(xì)的日志或者想測試不同量化文件時(shí)就會切到llama.cpp。兩個(gè)工具共存不沖突因?yàn)镺llama默認(rèn)端口是11434llama.cpp的server模式默認(rèn)端口是8080可以同時(shí)跑。安裝Ollama本身沒什么好說的官網(wǎng)下載Windows版一路下一步。裝完之后建議立刻做兩件事ollama --version ollama list然后把模型目錄挪到非系統(tǒng)盤避免C盤被撐爆。右鍵此電腦→屬性→環(huán)境變量新建OLLAMA_MODELSD:\ollama\models改完必須重啟Ollama服務(wù)才生效。Windows下可以打開任務(wù)管理器找到Ollama相關(guān)的進(jìn)程結(jié)束掉再重新啟動或者直接重啟電腦。2.3 拉取模型顯存不夠下載量來湊Ollama社區(qū)模型庫直接拉取是最快的方式ollama pull glm-5.3-35b:q4_k_m這個(gè)模型文件大約21GB具體耗時(shí)看網(wǎng)絡(luò)。拉取完成后用下面的命令確認(rèn)ollama list ollama show glm-5.3-35b:q4_k_m --modelfile如果官方庫沒有你想要的量化版本也可以從Hugging Face下載GGUF文件然后寫一個(gè)Modelfile導(dǎo)入。我的做法是放在本地目錄然后創(chuàng)建一個(gè)ModelfileFROM ./glm-5.3-35b-Q4_K_M.gguf TEMPLATE {{- if .System }} |system|{{ .System }}/s {{- end }} |user|{{ .Prompt }}/s |assistant| PARAMETER temperature 0.7 PARAMETER num_ctx 8192然后用ollama create導(dǎo)入ollama create myglm -f Modelfile這種方式的優(yōu)點(diǎn)是可控性強(qiáng)缺點(diǎn)是模板要自己摸。建議優(yōu)先用官方庫的現(xiàn)成標(biāo)簽把精力留在調(diào)參上。2.4 首次加載內(nèi)存搬運(yùn)工體驗(yàn)一切就緒之后運(yùn)行ollama run glm-5.3-35b:q4_k_m第一次啟動會有很明顯的等一會過程別急著敲鍵盤那是在把21GB的模型從SSD讀入內(nèi)存。512的SSD大概要讀一兩分鐘。加載完成之后可以另開一個(gè)終端看資源占用ollama ps nvidia-smi你會看到很奇妙的畫面顯存7GB多內(nèi)存18GB多GPU利用率很低但風(fēng)扇在轉(zhuǎn)。第一輪對話的首token延遲會比較長我這邊是4到8秒不等。不要誤會成卡死35B模型在這個(gè)配置下就是這樣的節(jié)奏。3. 完整實(shí)測過程從默認(rèn)限制到正常聊天的每一個(gè)設(shè)置3.1 去掉限制的正解把上下文和回復(fù)長度調(diào)到合理范圍很多人搜本地大模型去掉限制其實(shí)是遇到了同一個(gè)現(xiàn)象模型聊著聊著就截?cái)嗔嘶蛘咧挥涀∏懊鎺拙湓?。這個(gè)限制根本不是網(wǎng)絡(luò)層面的問題而是本地推理框架為了省顯存、內(nèi)存默認(rèn)把上下文長度設(shè)得很保守。Ollama默認(rèn)甚至可能只有2048或4096的上下文35B這種大模型回復(fù)長一點(diǎn)自然會被切斷?？茖W(xué)去掉限制的做法是把兩個(gè)參數(shù)調(diào)明白。第一個(gè)是num_ctx代表模型能看到的上下文長度第二個(gè)是num_predict代表單次最多生成的新token數(shù)。在Ollama里有兩種設(shè)置方式。環(huán)境變量方式一勞永逸OLLAMA_CONTEXT_LENGTH8192 OLLAMA_FLASH_ATTENTION1 OLLAMA_NUM_PARALLEL1Windows下把這些變量加進(jìn)系統(tǒng)環(huán)境變量然后重啟Ollama。num_ctx用8192而不是更大是我權(quán)衡過的結(jié)果8GB顯卡配32GB內(nèi)存8192已經(jīng)是比較舒服的上限再往上拉KV Cache會膨脹內(nèi)存會先扛不住速度也會跌得更難看。交互式會話里也可以隨時(shí)調(diào)整/set parameter num_ctx 8192 /set parameter num_predict 1024調(diào)完之后35B模型的長回復(fù)能力才算真正釋放出來。實(shí)測同一個(gè)總結(jié)任務(wù)默認(rèn)參數(shù)下輸出到一半就斷改完之后能完整輸出1000多字的分析這就是去掉限制的實(shí)際價(jià)值。3.2 不同GPU層數(shù)下的速度對比為了弄清楚8GB顯卡的極限我手動跑了幾組對比。Ollama會自動調(diào)度顯存但想精確控制時(shí)我改用llama.cpp的server模式通過-nolayers參數(shù)控制。這里記錄的是短問題約50字下的穩(wěn)定生成速度首token延遲單獨(dú)算配置GPU顯存占用CPU內(nèi)存占用生成速度GPU全部CPU推理0層上顯卡1GB28GB1.3 tokens/s10層上顯卡4.2GB23GB2.8 tokens/s18層上顯卡6.5GB20GB4.1 tokens/s20層上顯卡7.4GB19GB5.2 tokens/s嘗試22層上顯卡8.2GB18GB直接OOM結(jié)論很明確GPU層數(shù)越多越快但8GB顯存的上限就在20層左右。我后來長期使用的配置是20層顯存占用穩(wěn)定在7.2到7.6GB既不會OOM速度也最理想。如果再激進(jìn)一點(diǎn)把上下文長度降到4096可以擠到21層但收益已經(jīng)不明顯了。首token延遲的體驗(yàn)是這樣的20層配置下第一段回復(fù)大約需要5到7秒才出現(xiàn)之后每個(gè)token大約0.19秒。人眼閱讀速度大約是每秒4到6個(gè)字所以這個(gè)生成速度剛好夠正常閱讀談不上流暢但絕對可用。比起那種每個(gè)字等半天的體驗(yàn)已經(jīng)是天壤之別。3.3 實(shí)際使用體驗(yàn)?zāi)芰奶?、能寫代碼但別當(dāng)生產(chǎn)服務(wù)器我在實(shí)測里專門試了三類任務(wù)。第一類是中文日常問答比如讓它總結(jié)一篇幾百字的文章。速度在5到6 tokens/s體驗(yàn)接近一個(gè)慢一點(diǎn)但聰明的助手。第二類是Python代碼生成和debug35B模型在代碼上的表現(xiàn)明顯好于我在小模型上的經(jīng)驗(yàn)?zāi)芾斫庑枨蟛⑶医o出結(jié)構(gòu)完整的代碼但生成長文件時(shí)我不建議把num_ctx設(shè)太高否則后半段速度下降會很體感。第三類是翻譯8K上下文以內(nèi)中英互譯質(zhì)量相當(dāng)不錯(cuò)。但這里必須潑一盆冷水8GB跑35B只是能用不是好用。當(dāng)你有多個(gè)請求同時(shí)進(jìn)來或者想把上下文拉滿讀一篇長論文這個(gè)配置就會立刻露餡。并發(fā)方面OLLAMA_NUM_PARALLEL一定要設(shè)為1別想著同時(shí)跑兩個(gè)會話。模型本身的體積決定了單并發(fā)已經(jīng)占滿了內(nèi)存帶寬。4. 性能瓶頸分析與調(diào)優(yōu)把每一MB顯存都用到刀刃上4.1 為什么層數(shù)分配就是性能分配搞懂8GB跑35B的性能邏輯先要理解推理時(shí)的數(shù)據(jù)搬運(yùn)。每一次生成新token模型都要重新讀取一次當(dāng)前層級的權(quán)重。GPU顯存帶寬高所以放GPU的層讀取快CPU內(nèi)存帶寬低放內(nèi)存的層讀取慢。整體速度約等于短板決定而短板幾乎總是CPU內(nèi)存?zhèn)取Ｓ梦覍?shí)測的數(shù)據(jù)做個(gè)估算35B Q4_K_M大約21GB權(quán)重如果GPU只承擔(dān)20層大約7GB權(quán)重剩下的14GB權(quán)重在CPU側(cè)。DDR4雙通道帶寬約25GB/s純CPU側(cè)讀取14GB權(quán)重理論上限大約1.8個(gè)token/s。但因?yàn)镚PU側(cè)同步計(jì)算承擔(dān)了一部分實(shí)際跑出來5.2 tokens/s左右。這個(gè)數(shù)字為什么比純CPU理論值高因?yàn)閷又g是流水線式的不是嚴(yán)格串行搬運(yùn)GPU層和CPU層在重疊執(zhí)行效果接近兩個(gè)短板的加權(quán)組合加速。所以如果你也想抄這個(gè)方案可以對照自己配置預(yù)估速度內(nèi)存帶寬越高DDR5或四通道速度提升會非常明顯。加內(nèi)存容量能解決是否能跑的問題加內(nèi)存頻率才是解決跑得快不快的問題。4.2 顯存層面的終極調(diào)優(yōu)Flash Attention和context取舍Ollama的新版本支持Flash Attention我強(qiáng)烈建議開啟。它的作用是用更高效的注意力計(jì)算算法減少KV Cache的顯存占用。我開啟之后同一上下文長度下顯存占用下降了大約0.8到1GB等于白撿了2到3層GPU層的空間。環(huán)境變量設(shè)置OLLAMA_FLASH_ATTENTION1另外上下文長度是顯存占用里最靈活的參數(shù)。實(shí)測同一模型上下文長度KV Cache估算可上顯卡層數(shù)生成速度20480.6GB22層5.6 tokens/s40961.1GB21層5.4 tokens/s81922.2GB20層5.2 tokens/s163844.5GB16層4.0 tokens/s不要把上下文調(diào)到遠(yuǎn)高于自己的實(shí)際需求。很多人圖省事直接拉到32K結(jié)果模型雖然能加載但速度掉到?jīng)]法看內(nèi)存也瀕臨上限。我最終的平衡點(diǎn)是8192這個(gè)長度對絕大多數(shù)工作和代碼任務(wù)都夠用速度和資源占用也穩(wěn)。4.3 質(zhì)量參數(shù)Quantization與采樣參數(shù)的配合量化等級和采樣參數(shù)是兩回事但都影響最終輸出質(zhì)量。35B模型在Q4_K_M下的智力表現(xiàn)在線但采樣參數(shù)設(shè)置不當(dāng)會浪費(fèi)這個(gè)底子。我常用的參數(shù)組合temperature 0.7 top_p 0.9代碼生成類任務(wù)我會把temperature降到0.3以下減少隨機(jī)性創(chuàng)意寫作才拉到0.8以上。另外不要開repeat_penalty太高大模型本身對重復(fù)的控制已經(jīng)不錯(cuò)懲罰過高會導(dǎo)致輸出變得機(jī)械這也是很多人把模型調(diào)到變笨的常見原因。如果覺得質(zhì)量仍然不夠可以往上升一級用Q5_K_M約24GB。代價(jià)是需要再騰出3GB內(nèi)存上下文長度相應(yīng)縮到4096左右。我對比過同一段代碼生成Q5_K_M在復(fù)雜邏輯上確實(shí)略好但差距沒有量化等級之間那么大。日常使用我會保持Q4_K_M只有在做嚴(yán)肅寫作或復(fù)雜推理時(shí)才換Q5。5. 避坑實(shí)錄OOM、Windows路徑、Dify接入這些天踩過的坑5.1 顯存OOM看起來像崩潰其實(shí)是配置問題跑35B模型最常遇到的錯(cuò)誤是CUDA out of memory。我一開始傻乎乎地加GPU層數(shù)加到22層直接崩了。Ollama的崩潰表現(xiàn)不是彈紅字而是模型加載失敗或者會話直接卡死終端里沒有任何輸出。排查鏈路其實(shí)不復(fù)雜第一步先跑nvidia-smi看顯存是否被其他程序占用。Windows下瀏覽器開一堆標(biāo)簽頁尤其開了硬件加速可能占掉幾百M(fèi)B到1GB顯存。第二步看ollama ps確認(rèn)當(dāng)前加載的模型占用了多少。第三步把上下文長度從8192降到4096或者減少GPU層數(shù)重新加載。有一個(gè)經(jīng)驗(yàn)當(dāng)你發(fā)現(xiàn)Ollama加載35B模型時(shí)的GPU layers數(shù)字在自動調(diào)度并且接近滿載最好手動留出至少500MB顯存余量否則Windows桌面、瀏覽器這些日常程序一搶顯存立刻OOM。5.2 Windows路徑和WSL2的隱藏陷阱如果用的是WSL2最容易踩的坑是把模型放在/mnt/c盤。WSL2訪問Windows文件系統(tǒng)是跨文件系統(tǒng)讀寫性能比WSL2原生文件系統(tǒng)差很多加載模型時(shí)會明顯感覺慢甚至出現(xiàn)奇怪的IO錯(cuò)誤。正確做法是把模型放在WSL2的家目錄或者掛載的獨(dú)立ext4分區(qū)里。Windows原生版Ollama則要注意文件夾路徑不能有中文和空格否則部分版本會解析異常。另外Windows Defender防火墻經(jīng)常會把Ollama監(jiān)聽端口當(dāng)成危險(xiǎn)程序?qū)е戮钟蚓W(wǎng)內(nèi)其他機(jī)器訪問不到。如果Dify容器訪問宿主機(jī)Ollama失敗先查防火墻入站規(guī)則把11434端口放行。5.3 把35B接進(jìn)Dify本地模型終于成為工作流節(jié)點(diǎn)Dify接入本地Ollama模型是目前很多團(tuán)隊(duì)搭私有知識庫和Agent的高頻操作。我用的Dify版本是Docker Compose方式部署的整個(gè)流程大約十五分鐘。第一步確認(rèn)Ollama服務(wù)正常curl http://localhost:11434/api/tags看到返回模型列表就說明服務(wù)在線。第二步進(jìn)入Dify后臺選擇設(shè)置→模型供應(yīng)商→Ollama添加模型。這里有兩個(gè)關(guān)鍵點(diǎn)Base URL必須填http://host.docker.internal:11434。因?yàn)镈ify跑在Docker容器里localhost指向的是容器本身不是宿主機(jī)。模型名稱必須帶tag比如glm-5.3-35b:q4_k_m不是glm-5.3-35b否則校驗(yàn)會失敗。填完后點(diǎn)擊測試按鈕看到連接成功提示就可以了。之后在任何Agent工作流里都能選到這個(gè)模型同時(shí)Dify會通過Ollama的API調(diào)用本地推理。我實(shí)測在Dify里跑知識庫檢索加模型回答的完整流程35B模型速度依然能接受但并發(fā)請求多時(shí)Dify請求會排隊(duì)這是Ollama側(cè)單并發(fā)的上限導(dǎo)致的。如果你遇到Dify一直提示連接失敗先查三件事Ollama是否監(jiān)聽0.0.0.0、防火墻是否放行、模型名是否帶tag。按這個(gè)順序查90%的報(bào)錯(cuò)都能解決。5.4 借題聊聊花二三十萬買硬件做本地大模型值不值熱搜詞里有一條問如果本地花了二三十萬買硬件部署本地大模型會有運(yùn)維工作量嗎。這問題我太有發(fā)言權(quán)了。答案是會而且工作量一點(diǎn)也不小。服務(wù)器硬件涉及驅(qū)動兼容、CUDA版本管理、多卡通信、散熱、掉卡故障、權(quán)限控制、模型版本迭代每一樣都需要專人維護(hù)。相比之下單機(jī)單卡的消費(fèi)級方案運(yùn)維成本幾乎為零。但反過來消費(fèi)級方案的性能上限很明顯顯存小、內(nèi)存帶寬低、并發(fā)極低也沒有冗余。我的真實(shí)建議是個(gè)人折騰用消費(fèi)級單卡方案足夠小團(tuán)隊(duì)內(nèi)部使用可以先用一臺16GB顯卡的機(jī)器跑通流程真有高并發(fā)或大規(guī)模微調(diào)需求再考慮服務(wù)器級硬件那時(shí)候運(yùn)維預(yù)算也要一并算進(jìn)去。6. 個(gè)人結(jié)論8GB跑35B的真實(shí)邊界與最終配置參考6.1 什么樣的人適合這個(gè)方案這套方案適合三類人第一類是個(gè)人開發(fā)者想本地跑私有數(shù)據(jù)不想把代碼或文檔傳給云服務(wù)第二類是預(yù)算有限的學(xué)生或獨(dú)立研究者手里只有一張8GB游戲卡想體驗(yàn)30B以上大模型的真實(shí)水平第三類是小團(tuán)隊(duì)做技術(shù)驗(yàn)證先跑通Dify等工具鏈再決定要不要升級硬件。不適合的場景也很清楚高并發(fā)API服務(wù)、超長文檔的全文分析、需要實(shí)時(shí)流式交互的應(yīng)用。8GB顯卡跑35B模型的本質(zhì)是用時(shí)間換空間它能讓你在低預(yù)算下摸到35B模型的天花板但它不會變成一臺生產(chǎn)級推理服務(wù)器。6.2 可以直接抄作業(yè)的最終配置經(jīng)過反復(fù)調(diào)整下面是我穩(wěn)定使用一周的配置直接照抄就行環(huán)境變量 OLLAMA_CONTEXT_LENGTH8192 OLLAMA_FLASH_ATTENTION1 OLLAMA_NUM_PARALLEL1 OLLAMA_KEEP_ALIVE30m 模型 glm-5.3-35b:q4_k_m 啟動參數(shù)交互內(nèi)設(shè)置 /set parameter temperature 0.7 /set parameter top_p 0.9 /set parameter num_predict 1024硬件建議32GB DDR4起步能用DDR5更好GPU驅(qū)動更新到最新模型放SSD避免加載階段等太久。6.3 寫在最后的一點(diǎn)個(gè)人體感折騰了這么多天我最深的感受不是消費(fèi)級顯卡真能跑35B而是本地大模型的價(jià)值不全在速度而在數(shù)據(jù)主權(quán)。當(dāng)模型跑在自己的機(jī)器上沒有上傳、沒有等待審批、沒有API費(fèi)用那種自由度是小參數(shù)云服務(wù)完全給不了的。雖然每秒5個(gè)token算不上快但對個(gè)人日常使用來說這個(gè)速度已經(jīng)足夠陪你把一個(gè)想法聊完。如果你也想試不用等更好的硬件先把顯存賬算清楚選一個(gè)Q4_K_M的35B模型把Ollama和內(nèi)存配置好照這篇文章的路子走一遍。真正的門檻從來不是顯存而是愿不愿意動手。 8GB顯存跑35B本地大模型：量化部署與實(shí)戰(zhàn)調(diào)優(yōu)指南
8GB顯存跑35B參數(shù)的本地大模型這事聽起來就像用1TB的機(jī)械硬盤裝Windows能裝但誰信啊。我本來也不信直到自己動手在RTX 4060 8GB上把GLM-5.3-35B量化版跑起來還被群里人反復(fù)追問是不是偷偷用了云服務(wù)器。說實(shí)話我確實(shí)做好了全程看CPU慢慢擠牙膏的心理準(zhǔn)備但實(shí)測結(jié)果推翻了不少先入為主的判斷——消費(fèi)級顯卡本地大模型不是遙不可及8GB顯存跑35B級模型這件事雖然不像24GB旗艦卡那樣從容也確實(shí)有一條可復(fù)制的完整路徑。這篇文章就把這幾天的實(shí)測過程完整攤開怎么算顯存、怎么選量化、怎么調(diào)Ollama和llama.cpp、實(shí)際生成速度多少、踩了哪些坑以及Dify怎么把本地模型接進(jìn)工作流。如果你手頭也是一張8GB顯存的卡比如RTX 3050、3060、4060又不想為了跑個(gè)大模型就去租云GPU這篇實(shí)錄應(yīng)該能幫你省下至少一晚上的折騰時(shí)間。1. 為什么8GB跑35B聽起來像偽命題先把顯存賬單算清楚1.1 參數(shù)與顯存的樸素?fù)Q算35B模型默認(rèn)確實(shí)要70GB以上先說最基本的賬。模型的存儲和顯存占用通常按參數(shù)量乘以每個(gè)參數(shù)的字節(jié)數(shù)來估算。GLM-5.3-35B滿血版如果用FP16半精度浮點(diǎn)保存每個(gè)參數(shù)占2字節(jié)35B就是70GB。哪怕?lián)Q成BF16也還是這個(gè)數(shù)量級。70GB的模型單卡8GB自然是裝不下的這也是絕大多數(shù)人第一時(shí)間否決這個(gè)想法的根本原因。一張正經(jīng)的服務(wù)器顯卡比如A100 80GB才能做到無損加載。而消費(fèi)級顯卡里最頂?shù)腞TX 4090也就24GB8GB確實(shí)看起來差了太遠(yuǎn)。但這里很容易忽略一個(gè)前提模型放在內(nèi)存和顯存里不一定必須是FP16。從llama.cpp和Ollama流行起來之后量化這個(gè)詞被反復(fù)提及這條路就是從這打開的。1.2 量化用精度換體積失小得大的關(guān)鍵操作量化簡單說就是把模型權(quán)重從高精度數(shù)字壓縮到低精度數(shù)字。FP16的每個(gè)權(quán)重用16bit表示而量化后可以用4bit、5bit表示。聽起來像有損壓縮但實(shí)際效果比大多數(shù)人想的要好因?yàn)楝F(xiàn)在的GGUF量化不是簡單截?cái)喽菍?quán)重分組做縮放和補(bǔ)償把關(guān)鍵信息保留下來。市面上常見的量化等級量化等級每參數(shù)平均bit數(shù)35B模型落盤體積約體感質(zhì)量FP1616 bit70GB基準(zhǔn)Q8_08.5 bit37GB接近無損Q5_K_M5.5 bit24GB質(zhì)量很好Q4_K_M4.8 bit21GB甜點(diǎn)位Q3_K_M3.9 bit17GB明顯變傻Q2_K2.5 bit11GB基本沒法用我實(shí)測之后的感覺是Q4_K_M和FP16在普通問答、代碼生成上的差距很小有時(shí)甚至感覺不出來但降到Q3之后模型會開始答非所問邏輯鏈條斷裂。所以對8GB顯卡跑35B這件事Q4_K_M幾乎是唯一合理的選擇——體積21GB左右質(zhì)量損失控制在可接受范圍內(nèi)。1.3 KV Cache和臨時(shí)緩沖真正吃顯存的隱藏項(xiàng)量化把權(quán)重壓到21GB之后問題只解決了一半。推理過程中還有一個(gè)吃顯存的大戶叫KV Cache它用來緩存已生成內(nèi)容的注意力鍵值。上下文越長、模型層數(shù)越多KV Cache越大。GLM-5.3-35B這種體量的模型在8192上下文長度下KV Cache大約要占1.5到3GB具體取決于架構(gòu)細(xì)節(jié)。再加上CUDA context本身還要占幾百M(fèi)B到1GB顯存8GB顯存實(shí)際能用來裝權(quán)重的地方可能只剩6GB多一點(diǎn)。這意味著GPU最多只能承載35B模型的大約1/3層其余層數(shù)必須由CPU內(nèi)存承擔(dān)。這就是8GB能跑35B的另一個(gè)機(jī)制部分卸載或者說offload。拿我實(shí)測的配置來算筆賬Q4_K_M版本約21GB如果GPU加載其中30%的層大約6.3GB權(quán)重加上KV Cache和CUDA開銷剛好把8GB塞得很滿。CPU內(nèi)存?zhèn)纫袚?dān)剩下約15GB權(quán)重和約2GB KV Cache總共17GB左右。所以32GB內(nèi)存是起步門檻16GB大概率會卡到爆。這就是為什么8GB跑35B實(shí)際上不是偽命題而是顯存不夠內(nèi)存來湊的分布式解題思路。預(yù)算的分配重點(diǎn)也從買大顯存顯卡轉(zhuǎn)移到了買大容量高頻內(nèi)存。2. 實(shí)測配置與工具鏈這套組合最省心也最省錢2.1 硬件清單別小看內(nèi)存帶寬這次實(shí)測的硬件不是頂配反而是很典型的裝機(jī)配置部件型號備注GPURTX 4060 8GB還有一塊RTX 3050 8GB做對照CPUIntel i5-12490F6核12線程內(nèi)存32GB DDR4 3200雙通道雙通道必須開啟硬盤NVMe SSD 1TB模型落盤需要約22GB空間系統(tǒng)Windows 11 WSL2Ollama原生Windows版本為什么我反復(fù)強(qiáng)調(diào)內(nèi)存帶寬因?yàn)?GB顯存跑35B模型時(shí)大部分層其實(shí)跑在CPU內(nèi)存上。每生成一個(gè)token推理引擎都要把模型權(quán)重從頭到尾讀一遍。DDR4雙通道的帶寬大約25GB/s而GPU顯存帶寬有272GB/s。如果權(quán)限都在CPU側(cè)速度上限就被內(nèi)存帶寬卡死所以DDR5內(nèi)存或者四通道方案會有明顯優(yōu)勢。這也是后面調(diào)優(yōu)的核心邏輯。2.2 為什么主力用Ollama但llama.cpp也要裝Ollama現(xiàn)在的成熟度已經(jīng)很高了。它把模型下載、量化格式識別、GPU自動調(diào)度、API服務(wù)這些都封裝好了Windows下裝完就能用。我把它當(dāng)主力原因很樸素省事而且底層就是llama.cpp性能不會差太多。llama.cpp在我這里的定位是備用手術(shù)刀。當(dāng)我想手動指定GPU加載多少層、想查看更詳細(xì)的日志或者想測試不同量化文件時(shí)就會切到llama.cpp。兩個(gè)工具共存不沖突因?yàn)镺llama默認(rèn)端口是11434llama.cpp的server模式默認(rèn)端口是8080可以同時(shí)跑。安裝Ollama本身沒什么好說的官網(wǎng)下載Windows版一路下一步。裝完之后建議立刻做兩件事ollama --version ollama list然后把模型目錄挪到非系統(tǒng)盤避免C盤被撐爆。右鍵此電腦→屬性→環(huán)境變量新建OLLAMA_MODELSD:\ollama\models改完必須重啟Ollama服務(wù)才生效。Windows下可以打開任務(wù)管理器找到Ollama相關(guān)的進(jìn)程結(jié)束掉再重新啟動或者直接重啟電腦。2.3 拉取模型顯存不夠下載量來湊Ollama社區(qū)模型庫直接拉取是最快的方式ollama pull glm-5.3-35b:q4_k_m這個(gè)模型文件大約21GB具體耗時(shí)看網(wǎng)絡(luò)。拉取完成后用下面的命令確認(rèn)ollama list ollama show glm-5.3-35b:q4_k_m --modelfile如果官方庫沒有你想要的量化版本也可以從Hugging Face下載GGUF文件然后寫一個(gè)Modelfile導(dǎo)入。我的做法是放在本地目錄然后創(chuàng)建一個(gè)ModelfileFROM ./glm-5.3-35b-Q4_K_M.gguf TEMPLATE {{- if .System }} |system|{{ .System }}/s {{- end }} |user|{{ .Prompt }}/s |assistant| PARAMETER temperature 0.7 PARAMETER num_ctx 8192然后用ollama create導(dǎo)入ollama create myglm -f Modelfile這種方式的優(yōu)點(diǎn)是可控性強(qiáng)缺點(diǎn)是模板要自己摸。建議優(yōu)先用官方庫的現(xiàn)成標(biāo)簽把精力留在調(diào)參上。2.4 首次加載內(nèi)存搬運(yùn)工體驗(yàn)一切就緒之后運(yùn)行ollama run glm-5.3-35b:q4_k_m第一次啟動會有很明顯的等一會過程別急著敲鍵盤那是在把21GB的模型從SSD讀入內(nèi)存。512的SSD大概要讀一兩分鐘。加載完成之后可以另開一個(gè)終端看資源占用ollama ps nvidia-smi你會看到很奇妙的畫面顯存7GB多內(nèi)存18GB多GPU利用率很低但風(fēng)扇在轉(zhuǎn)。第一輪對話的首token延遲會比較長我這邊是4到8秒不等。不要誤會成卡死35B模型在這個(gè)配置下就是這樣的節(jié)奏。3. 完整實(shí)測過程從默認(rèn)限制到正常聊天的每一個(gè)設(shè)置3.1 去掉限制的正解把上下文和回復(fù)長度調(diào)到合理范圍很多人搜本地大模型去掉限制其實(shí)是遇到了同一個(gè)現(xiàn)象模型聊著聊著就截?cái)嗔嘶蛘咧挥涀∏懊鎺拙湓?。這個(gè)限制根本不是網(wǎng)絡(luò)層面的問題而是本地推理框架為了省顯存、內(nèi)存默認(rèn)把上下文長度設(shè)得很保守。Ollama默認(rèn)甚至可能只有2048或4096的上下文35B這種大模型回復(fù)長一點(diǎn)自然會被切斷?？茖W(xué)去掉限制的做法是把兩個(gè)參數(shù)調(diào)明白。第一個(gè)是num_ctx代表模型能看到的上下文長度第二個(gè)是num_predict代表單次最多生成的新token數(shù)。在Ollama里有兩種設(shè)置方式。環(huán)境變量方式一勞永逸OLLAMA_CONTEXT_LENGTH8192 OLLAMA_FLASH_ATTENTION1 OLLAMA_NUM_PARALLEL1Windows下把這些變量加進(jìn)系統(tǒng)環(huán)境變量然后重啟Ollama。num_ctx用8192而不是更大是我權(quán)衡過的結(jié)果8GB顯卡配32GB內(nèi)存8192已經(jīng)是比較舒服的上限再往上拉KV Cache會膨脹內(nèi)存會先扛不住速度也會跌得更難看。交互式會話里也可以隨時(shí)調(diào)整/set parameter num_ctx 8192 /set parameter num_predict 1024調(diào)完之后35B模型的長回復(fù)能力才算真正釋放出來。實(shí)測同一個(gè)總結(jié)任務(wù)默認(rèn)參數(shù)下輸出到一半就斷改完之后能完整輸出1000多字的分析這就是去掉限制的實(shí)際價(jià)值。3.2 不同GPU層數(shù)下的速度對比為了弄清楚8GB顯卡的極限我手動跑了幾組對比。Ollama會自動調(diào)度顯存但想精確控制時(shí)我改用llama.cpp的server模式通過-nolayers參數(shù)控制。這里記錄的是短問題約50字下的穩(wěn)定生成速度首token延遲單獨(dú)算配置GPU顯存占用CPU內(nèi)存占用生成速度GPU全部CPU推理0層上顯卡1GB28GB1.3 tokens/s10層上顯卡4.2GB23GB2.8 tokens/s18層上顯卡6.5GB20GB4.1 tokens/s20層上顯卡7.4GB19GB5.2 tokens/s嘗試22層上顯卡8.2GB18GB直接OOM結(jié)論很明確GPU層數(shù)越多越快但8GB顯存的上限就在20層左右。我后來長期使用的配置是20層顯存占用穩(wěn)定在7.2到7.6GB既不會OOM速度也最理想。如果再激進(jìn)一點(diǎn)把上下文長度降到4096可以擠到21層但收益已經(jīng)不明顯了。首token延遲的體驗(yàn)是這樣的20層配置下第一段回復(fù)大約需要5到7秒才出現(xiàn)之后每個(gè)token大約0.19秒。人眼閱讀速度大約是每秒4到6個(gè)字所以這個(gè)生成速度剛好夠正常閱讀談不上流暢但絕對可用。比起那種每個(gè)字等半天的體驗(yàn)已經(jīng)是天壤之別。3.3 實(shí)際使用體驗(yàn)?zāi)芰奶?、能寫代碼但別當(dāng)生產(chǎn)服務(wù)器我在實(shí)測里專門試了三類任務(wù)。第一類是中文日常問答比如讓它總結(jié)一篇幾百字的文章。速度在5到6 tokens/s體驗(yàn)接近一個(gè)慢一點(diǎn)但聰明的助手。第二類是Python代碼生成和debug35B模型在代碼上的表現(xiàn)明顯好于我在小模型上的經(jīng)驗(yàn)?zāi)芾斫庑枨蟛⑶医o出結(jié)構(gòu)完整的代碼但生成長文件時(shí)我不建議把num_ctx設(shè)太高否則后半段速度下降會很體感。第三類是翻譯8K上下文以內(nèi)中英互譯質(zhì)量相當(dāng)不錯(cuò)。但這里必須潑一盆冷水8GB跑35B只是能用不是好用。當(dāng)你有多個(gè)請求同時(shí)進(jìn)來或者想把上下文拉滿讀一篇長論文這個(gè)配置就會立刻露餡。并發(fā)方面OLLAMA_NUM_PARALLEL一定要設(shè)為1別想著同時(shí)跑兩個(gè)會話。模型本身的體積決定了單并發(fā)已經(jīng)占滿了內(nèi)存帶寬。4. 性能瓶頸分析與調(diào)優(yōu)把每一MB顯存都用到刀刃上4.1 為什么層數(shù)分配就是性能分配搞懂8GB跑35B的性能邏輯先要理解推理時(shí)的數(shù)據(jù)搬運(yùn)。每一次生成新token模型都要重新讀取一次當(dāng)前層級的權(quán)重。GPU顯存帶寬高所以放GPU的層讀取快CPU內(nèi)存帶寬低放內(nèi)存的層讀取慢。整體速度約等于短板決定而短板幾乎總是CPU內(nèi)存?zhèn)取Ｓ梦覍?shí)測的數(shù)據(jù)做個(gè)估算35B Q4_K_M大約21GB權(quán)重如果GPU只承擔(dān)20層大約7GB權(quán)重剩下的14GB權(quán)重在CPU側(cè)。DDR4雙通道帶寬約25GB/s純CPU側(cè)讀取14GB權(quán)重理論上限大約1.8個(gè)token/s。但因?yàn)镚PU側(cè)同步計(jì)算承擔(dān)了一部分實(shí)際跑出來5.2 tokens/s左右。這個(gè)數(shù)字為什么比純CPU理論值高因?yàn)閷又g是流水線式的不是嚴(yán)格串行搬運(yùn)GPU層和CPU層在重疊執(zhí)行效果接近兩個(gè)短板的加權(quán)組合加速。所以如果你也想抄這個(gè)方案可以對照自己配置預(yù)估速度內(nèi)存帶寬越高DDR5或四通道速度提升會非常明顯。加內(nèi)存容量能解決是否能跑的問題加內(nèi)存頻率才是解決跑得快不快的問題。4.2 顯存層面的終極調(diào)優(yōu)Flash Attention和context取舍Ollama的新版本支持Flash Attention我強(qiáng)烈建議開啟。它的作用是用更高效的注意力計(jì)算算法減少KV Cache的顯存占用。我開啟之后同一上下文長度下顯存占用下降了大約0.8到1GB等于白撿了2到3層GPU層的空間。環(huán)境變量設(shè)置OLLAMA_FLASH_ATTENTION1另外上下文長度是顯存占用里最靈活的參數(shù)。實(shí)測同一模型上下文長度KV Cache估算可上顯卡層數(shù)生成速度20480.6GB22層5.6 tokens/s40961.1GB21層5.4 tokens/s81922.2GB20層5.2 tokens/s163844.5GB16層4.0 tokens/s不要把上下文調(diào)到遠(yuǎn)高于自己的實(shí)際需求。很多人圖省事直接拉到32K結(jié)果模型雖然能加載但速度掉到?jīng)]法看內(nèi)存也瀕臨上限。我最終的平衡點(diǎn)是8192這個(gè)長度對絕大多數(shù)工作和代碼任務(wù)都夠用速度和資源占用也穩(wěn)。4.3 質(zhì)量參數(shù)Quantization與采樣參數(shù)的配合量化等級和采樣參數(shù)是兩回事但都影響最終輸出質(zhì)量。35B模型在Q4_K_M下的智力表現(xiàn)在線但采樣參數(shù)設(shè)置不當(dāng)會浪費(fèi)這個(gè)底子。我常用的參數(shù)組合temperature 0.7 top_p 0.9代碼生成類任務(wù)我會把temperature降到0.3以下減少隨機(jī)性創(chuàng)意寫作才拉到0.8以上。另外不要開repeat_penalty太高大模型本身對重復(fù)的控制已經(jīng)不錯(cuò)懲罰過高會導(dǎo)致輸出變得機(jī)械這也是很多人把模型調(diào)到變笨的常見原因。如果覺得質(zhì)量仍然不夠可以往上升一級用Q5_K_M約24GB。代價(jià)是需要再騰出3GB內(nèi)存上下文長度相應(yīng)縮到4096左右。我對比過同一段代碼生成Q5_K_M在復(fù)雜邏輯上確實(shí)略好但差距沒有量化等級之間那么大。日常使用我會保持Q4_K_M只有在做嚴(yán)肅寫作或復(fù)雜推理時(shí)才換Q5。5. 避坑實(shí)錄OOM、Windows路徑、Dify接入這些天踩過的坑5.1 顯存OOM看起來像崩潰其實(shí)是配置問題跑35B模型最常遇到的錯(cuò)誤是CUDA out of memory。我一開始傻乎乎地加GPU層數(shù)加到22層直接崩了。Ollama的崩潰表現(xiàn)不是彈紅字而是模型加載失敗或者會話直接卡死終端里沒有任何輸出。排查鏈路其實(shí)不復(fù)雜第一步先跑nvidia-smi看顯存是否被其他程序占用。Windows下瀏覽器開一堆標(biāo)簽頁尤其開了硬件加速可能占掉幾百M(fèi)B到1GB顯存。第二步看ollama ps確認(rèn)當(dāng)前加載的模型占用了多少。第三步把上下文長度從8192降到4096或者減少GPU層數(shù)重新加載。有一個(gè)經(jīng)驗(yàn)當(dāng)你發(fā)現(xiàn)Ollama加載35B模型時(shí)的GPU layers數(shù)字在自動調(diào)度并且接近滿載最好手動留出至少500MB顯存余量否則Windows桌面、瀏覽器這些日常程序一搶顯存立刻OOM。5.2 Windows路徑和WSL2的隱藏陷阱如果用的是WSL2最容易踩的坑是把模型放在/mnt/c盤。WSL2訪問Windows文件系統(tǒng)是跨文件系統(tǒng)讀寫性能比WSL2原生文件系統(tǒng)差很多加載模型時(shí)會明顯感覺慢甚至出現(xiàn)奇怪的IO錯(cuò)誤。正確做法是把模型放在WSL2的家目錄或者掛載的獨(dú)立ext4分區(qū)里。Windows原生版Ollama則要注意文件夾路徑不能有中文和空格否則部分版本會解析異常。另外Windows Defender防火墻經(jīng)常會把Ollama監(jiān)聽端口當(dāng)成危險(xiǎn)程序?qū)е戮钟蚓W(wǎng)內(nèi)其他機(jī)器訪問不到。如果Dify容器訪問宿主機(jī)Ollama失敗先查防火墻入站規(guī)則把11434端口放行。5.3 把35B接進(jìn)Dify本地模型終于成為工作流節(jié)點(diǎn)Dify接入本地Ollama模型是目前很多團(tuán)隊(duì)搭私有知識庫和Agent的高頻操作。我用的Dify版本是Docker Compose方式部署的整個(gè)流程大約十五分鐘。第一步確認(rèn)Ollama服務(wù)正常curl http://localhost:11434/api/tags看到返回模型列表就說明服務(wù)在線。第二步進(jìn)入Dify后臺選擇設(shè)置→模型供應(yīng)商→Ollama添加模型。這里有兩個(gè)關(guān)鍵點(diǎn)Base URL必須填http://host.docker.internal:11434。因?yàn)镈ify跑在Docker容器里localhost指向的是容器本身不是宿主機(jī)。模型名稱必須帶tag比如glm-5.3-35b:q4_k_m不是glm-5.3-35b否則校驗(yàn)會失敗。填完后點(diǎn)擊測試按鈕看到連接成功提示就可以了。之后在任何Agent工作流里都能選到這個(gè)模型同時(shí)Dify會通過Ollama的API調(diào)用本地推理。我實(shí)測在Dify里跑知識庫檢索加模型回答的完整流程35B模型速度依然能接受但并發(fā)請求多時(shí)Dify請求會排隊(duì)這是Ollama側(cè)單并發(fā)的上限導(dǎo)致的。如果你遇到Dify一直提示連接失敗先查三件事Ollama是否監(jiān)聽0.0.0.0、防火墻是否放行、模型名是否帶tag。按這個(gè)順序查90%的報(bào)錯(cuò)都能解決。5.4 借題聊聊花二三十萬買硬件做本地大模型值不值熱搜詞里有一條問如果本地花了二三十萬買硬件部署本地大模型會有運(yùn)維工作量嗎。這問題我太有發(fā)言權(quán)了。答案是會而且工作量一點(diǎn)也不小。服務(wù)器硬件涉及驅(qū)動兼容、CUDA版本管理、多卡通信、散熱、掉卡故障、權(quán)限控制、模型版本迭代每一樣都需要專人維護(hù)。相比之下單機(jī)單卡的消費(fèi)級方案運(yùn)維成本幾乎為零。但反過來消費(fèi)級方案的性能上限很明顯顯存小、內(nèi)存帶寬低、并發(fā)極低也沒有冗余。我的真實(shí)建議是個(gè)人折騰用消費(fèi)級單卡方案足夠小團(tuán)隊(duì)內(nèi)部使用可以先用一臺16GB顯卡的機(jī)器跑通流程真有高并發(fā)或大規(guī)模微調(diào)需求再考慮服務(wù)器級硬件那時(shí)候運(yùn)維預(yù)算也要一并算進(jìn)去。6. 個(gè)人結(jié)論8GB跑35B的真實(shí)邊界與最終配置參考6.1 什么樣的人適合這個(gè)方案這套方案適合三類人第一類是個(gè)人開發(fā)者想本地跑私有數(shù)據(jù)不想把代碼或文檔傳給云服務(wù)第二類是預(yù)算有限的學(xué)生或獨(dú)立研究者手里只有一張8GB游戲卡想體驗(yàn)30B以上大模型的真實(shí)水平第三類是小團(tuán)隊(duì)做技術(shù)驗(yàn)證先跑通Dify等工具鏈再決定要不要升級硬件。不適合的場景也很清楚高并發(fā)API服務(wù)、超長文檔的全文分析、需要實(shí)時(shí)流式交互的應(yīng)用。8GB顯卡跑35B模型的本質(zhì)是用時(shí)間換空間它能讓你在低預(yù)算下摸到35B模型的天花板但它不會變成一臺生產(chǎn)級推理服務(wù)器。6.2 可以直接抄作業(yè)的最終配置經(jīng)過反復(fù)調(diào)整下面是我穩(wěn)定使用一周的配置直接照抄就行環(huán)境變量 OLLAMA_CONTEXT_LENGTH8192 OLLAMA_FLASH_ATTENTION1 OLLAMA_NUM_PARALLEL1 OLLAMA_KEEP_ALIVE30m 模型 glm-5.3-35b:q4_k_m 啟動參數(shù)交互內(nèi)設(shè)置 /set parameter temperature 0.7 /set parameter top_p 0.9 /set parameter num_predict 1024硬件建議32GB DDR4起步能用DDR5更好GPU驅(qū)動更新到最新模型放SSD避免加載階段等太久。6.3 寫在最后的一點(diǎn)個(gè)人體感折騰了這么多天我最深的感受不是消費(fèi)級顯卡真能跑35B而是本地大模型的價(jià)值不全在速度而在數(shù)據(jù)主權(quán)。當(dāng)模型跑在自己的機(jī)器上沒有上傳、沒有等待審批、沒有API費(fèi)用那種自由度是小參數(shù)云服務(wù)完全給不了的。雖然每秒5個(gè)token算不上快但對個(gè)人日常使用來說這個(gè)速度已經(jīng)足夠陪你把一個(gè)想法聊完。如果你也想試不用等更好的硬件先把顯存賬算清楚選一個(gè)Q4_K_M的35B模型把Ollama和內(nèi)存配置好照這篇文章的路子走一遍。真正的門檻從來不是顯存而是愿不愿意動手。