先潑一盆冷水8GB 顯存跑 35B 大模型這聽(tīng)起來(lái)像是個(gè)不可能完成的任務(wù)甚至?xí)缓芏嗳酥苯哟虺伞皹?biāo)題黨”。35B 參數(shù)光 FP16 權(quán)重就要占 70GB 顯存8GB 連零頭都不夠。但我確實(shí)在消費(fèi)級(jí)顯卡上把它跑起來(lái)了而且不是只能出幾個(gè)字的那種“跑”是能正常對(duì)話、能寫(xiě)代碼、能分析文檔的完整可用狀態(tài)。這篇記錄我會(huì)把整個(gè)過(guò)程的原理、工具選擇、參數(shù)配置、實(shí)測(cè)數(shù)據(jù)和踩坑經(jīng)過(guò)全部攤開(kāi)包括每一步為什么這么做、中間出了哪些問(wèn)題、最后怎么解決的。先說(shuō)結(jié)論這條路走通靠的不是魔法而是三件事——量化壓縮、稀疏激活、顯存外擴(kuò)。這三板斧疊起來(lái)物理容量不夠的問(wèn)題就被繞過(guò)去了同時(shí)把顯卡的現(xiàn)有算力榨到極限。這篇文章適合手里只有 8GB 顯存、又想在本地玩轉(zhuǎn)大模型的折騰型用戶(hù)也適合被各種“本地部署”教程搞得一頭霧水、想搞清楚底層邏輯的初學(xué)者。我會(huì)盡量把每個(gè)決策背后的原因講清楚而不是丟給你一堆復(fù)制粘貼的命令。1. 為什么 8GB 能跑 35B三個(gè)繞不開(kāi)的核心原理1.1 量化是怎么把模型“壓縮”進(jìn)顯存的大模型的參數(shù)本質(zhì)上是一堆浮點(diǎn)數(shù)。原本用 16 位浮點(diǎn)FP16存儲(chǔ)35B 個(gè)參數(shù)就是 35B × 2 字節(jié) ≈ 70GB。8GB 顯存連零頭都裝不下。但量化做的事情很簡(jiǎn)單粗暴把這些浮點(diǎn)數(shù)的精度降下來(lái)。用 4 位整數(shù)INT4表示權(quán)重體積直接縮小到原來(lái)的四分之一左右35B 模型壓縮完大約 20GB 上下。不過(guò)這里有個(gè)非常容易踩的誤解很多人以為量化之后模型能力會(huì)斷崖式下跌。實(shí)際上現(xiàn)代量化方法比如 GPTQ、GGUF 的 Q4_K_M 級(jí)別在大多數(shù)任務(wù)上損失非常小日常對(duì)話、代碼生成、文本總結(jié)基本無(wú)感。我自己實(shí)測(cè)下來(lái)4bit 量化的 Qwen2.5-32B 和原版 FP16 在判斷題、改寫(xiě)、代碼解釋類(lèi)任務(wù)上幾乎沒(méi)有差別只有極個(gè)別需要精確推理的場(chǎng)景會(huì)露餡。20GB 依然塞不進(jìn) 8GB所以量化只是第一步。但它解決了最關(guān)鍵的問(wèn)題——讓模型能夠跑起來(lái)而不是卡死在“顯存不足”的報(bào)錯(cuò)上。1.2 稀疏激活與 MoE關(guān)鍵參數(shù)只有一小撮在干活第二個(gè)支柱是 MoE混合專(zhuān)家結(jié)構(gòu)。像 Qwen3-30B-A3B 這類(lèi) MoE 模型總參數(shù) 30B但每個(gè) token 進(jìn)來(lái)只激活其中的 3B 參數(shù)。好比一家公司有 30 個(gè)部門(mén)但每個(gè)任務(wù)只叫 3 個(gè)部門(mén)干活其他部門(mén)待命。這樣算力需求就比同規(guī)模稠密模型小一個(gè)數(shù)量級(jí)推理速度完全不可同日而語(yǔ)。實(shí)際表現(xiàn)上我 8GB 顯存跑 Qwen3-30B 的 token 生成速度是 50-60 token/s而跑同等參數(shù)量級(jí)的稠密模型只有 5-8 token/s。這個(gè)差距就是 MoE 的稀疏激活帶來(lái)的。很多人一聽(tīng)“30B”就被嚇住了其實(shí)智譜、Qwen 這些團(tuán)隊(duì)早就把 MoE 結(jié)構(gòu)下放到消費(fèi)級(jí)能做動(dòng)的規(guī)模了。1.3 顯存外擴(kuò)讓 CPU 內(nèi)存當(dāng)“備用倉(cāng)庫(kù)”最后一塊拼圖是 CPU 卸載offload。既然 8GB 放不下 20GB 的量化權(quán)重那就把塞不下的部分放到內(nèi)存里顯卡算一層、CPU 算一層兩層協(xié)同工作。Ollama 和 llama.cpp 這類(lèi)工具自帶這個(gè)能力會(huì)自動(dòng)把顯存放不下的層丟給 CPU 推理。這里有個(gè)天然的權(quán)衡CPU 推理速度遠(yuǎn)低于 GPU。如果完全不做部分卸載8GB 連精簡(jiǎn)到極致的 35B 都放不下。所以實(shí)際策略是把能塞進(jìn)顯存的全塞進(jìn)去剩下的才拋給內(nèi)存。顯存越大、能裝進(jìn) GPU 的層越多速度就越快。這也是為什么我建議 8GB 用戶(hù)盡量選量化等級(jí)更高、體積更小的版本而不是無(wú)腦上最高精度。注意CPU 卸載不是萬(wàn)能的。如果 CPU 太弱比如 4 核老古董或者內(nèi)存帶寬太低整體速度可能還不如一個(gè)跑在 8GB 顯存上的 7B 模型。這個(gè)權(quán)衡一定要提前想清楚別把硬件瓶頸找錯(cuò)了方向。2. 環(huán)境準(zhǔn)備與工具選型動(dòng)手前把坑填平2.1 為什么首選 Ollama 而不是直接上 llama.cpp本地部署大模型的工具五花八門(mén)Transformers、llama.cpp、Ollama、LM Studio 各有各的擁躉。我最終選了 Ollama核心原因是它在顯存管理和模型調(diào)度上做了大量自動(dòng)化處理——這對(duì)于只有 8GB 顯存、每個(gè)字節(jié)都要精打細(xì)算的場(chǎng)景來(lái)說(shuō)太關(guān)鍵了。llama.cpp 需要手動(dòng)指定 GPU 層數(shù)、并行度、上下文長(zhǎng)度參數(shù)調(diào)不好就是各種 OOMOllama 基本可以做到開(kāi)箱即用默認(rèn)配置已經(jīng)能自動(dòng)決定哪些層放顯存、哪些丟內(nèi)存。但 Ollama 不是沒(méi)有缺點(diǎn)。它的參數(shù)傳遞相對(duì)保守很多高級(jí)選項(xiàng)要通過(guò)環(huán)境變量才能啟用。比如要開(kāi)啟 Flash Attention得手動(dòng)設(shè)OLLAMA_FLASH_ATTENTION1要調(diào)整并行加載模型的數(shù)量得設(shè)OLLAMA_NUM_PARALLEL。這些配置知道的人少但不配置的話8GB 顯卡跑 35B 基本會(huì)卡在默認(rèn)的 CPU 推理上。2.2 Windows 11 下的環(huán)境配置全過(guò)程我在 Windows 11 上實(shí)測(cè)配置確實(shí)比 Linux 簡(jiǎn)單不少。Ollama 官方提供了 Windows 安裝包裝完直接就能用。需要注意幾個(gè)細(xì)節(jié)顯卡驅(qū)動(dòng)必須更新到最新版本。老驅(qū)動(dòng)對(duì) CUDA 12.x 的支持可能不完整會(huì)導(dǎo)致模型加載后 GPU 利用率始終為 0。內(nèi)存建議 32GB 起步。8GB 顯存跑 35B大約需要 12-16GB 的內(nèi)存來(lái)裝卸載出去的層外加系統(tǒng)本身占用16GB 內(nèi)存會(huì)比較緊張32GB 才夠從容。Ollama 默認(rèn)模型存儲(chǔ)路徑在 C 盤(pán)35B 模型動(dòng)輒 20GBC 盤(pán)不夠用的話要提前改環(huán)境變量OLLAMA_MODELS指到大容量分區(qū)。開(kāi)啟系統(tǒng)休眠會(huì)導(dǎo)致推理中斷在電源設(shè)置里把“睡眠”改成“從不”是基本操作。2.3 模型選型的取舍參數(shù)質(zhì)量與技術(shù)路徑權(quán)衡市面上 35B 級(jí)別的模型不算少但能在 8GB 顯存上真正絲滑運(yùn)行的不多。我建議優(yōu)先考慮Qwen3-30B-A3B其次是Qwen2.5-32B的 Q4_K_M 量化版以及采用類(lèi)似 MoE 結(jié)構(gòu)的其他 30B 檔模型。Qwen3-30B-A3B 的優(yōu)勢(shì)是激活參數(shù)只有 3B推理速度極快配合 Q4_K_M 量化后模型文件只有 20GB 上下卸載到內(nèi)存的部分不算多8GB 顯存能穩(wěn)穩(wěn)壓住。Qwen2.5-32B 是稠密模型雖然同樣能卸到內(nèi)存跑但速度瓶頸就明顯多了。至于為什么不是 35B 標(biāo)準(zhǔn)模型——5B 的差距本身沒(méi)什么意義關(guān)鍵是模型架構(gòu)和量化版本是否適配你手里的顯存。個(gè)人建議選模型之前先用ollama run跑一下小模型比如 7B確定 GPU 利用率正常、速度符合預(yù)期再上大模型。不然你很難分辨是模型問(wèn)題還是環(huán)境問(wèn)題。3. 顯存、算力與推理速度的三角平衡3.1 用計(jì)算弄清楚一張 8GB 顯卡到底能做什么8GB 顯存的物理上限不可繞過(guò)。我們用粗粒度估算Q4 量化后大約每 1B 參數(shù)占 0.6-0.7GB35B 需要約 20GB。就算把量化等級(jí)壓到 Q2也要 12GB 左右。想全部塞進(jìn)顯存數(shù)學(xué)上不可能。所以思路必須轉(zhuǎn)變成“能塞多少塞多少塞不下的交給別的部分”。顯存分配還有一個(gè)必須留的余量KV Cache。上下文越長(zhǎng)KV Cache 占的顯存越多。默認(rèn) 2048 token 上下文大概要 1-2GB8GB 顯存上這已經(jīng)是很大比例了。我在實(shí)際測(cè)試中發(fā)現(xiàn)把上下文長(zhǎng)度調(diào)到 8192 時(shí)顯存占用直接從 6.2GB 飆到 7.6GB其他層全被擠到 CPU 上推理速度肉眼可見(jiàn)地掉下來(lái)。這也是為什么我看網(wǎng)上好多人說(shuō)“我 8GB 跑 32B 很流暢”結(jié)果一問(wèn)上下文長(zhǎng)度是 512基本等于玩玩具。3.2 量化等級(jí)的選擇Q4 與 Q8 的實(shí)戰(zhàn)差距GGUF 量化等級(jí)從 Q2 到 Q8 都有體積、精度、速度三者在打架。實(shí)測(cè)對(duì)比Q4_K_M質(zhì)量可接受體積約 20GB8GB 顯存基本能跑出 50 token/sMoE或 5-7 token/s稠密。Q6_K體積約 26GB精度更高但顯存壓力明顯加大CPU 卸載量變多速度下降 30%-50%。Q8_0體積約 33GB質(zhì)量接近原版但在 8GB 顯存上基本沒(méi)法看加載時(shí)間極長(zhǎng)推理速度掉到 2-3 token/s。這個(gè)結(jié)論很清楚8GB 顯存玩 35B老老實(shí)實(shí)選 Q4_K_M 就好。別為了一點(diǎn)精度去賭 Q6 或 Q8最后多半會(huì)陷入“精度確實(shí)好一點(diǎn)但慢到不想用”的尷尬局面。3.3 Flash Attention 和緩存優(yōu)化看似不起眼實(shí)則是救命稻草Ollama 在 Windows 11 上默認(rèn)可能沒(méi)有啟用 Flash Attention這會(huì)導(dǎo)致 KV Cache 占用比激活后高出一截。在 8GB 顯存上這幾十 MB、幾百 MB 的差別就可能決定某個(gè)層能不能留在 GPU 上。實(shí)操做法在系統(tǒng)環(huán)境變量里新建OLLAMA_FLASH_ATTENTION1然后重啟 Ollama 服務(wù)。改完之后觀察nvidia-smi的顯存占用你會(huì)看到啟動(dòng)后顯存占用反而下降、GPU 利用率明顯上升的結(jié)果。這個(gè)操作相當(dāng)重要經(jīng)常能帶來(lái) 15%-20% 的速度提升而且完全免費(fèi)。另外把OLLAMA_KV_CACHE_TYPEq8_0也設(shè)上KV Cache 用 8bit 而非默認(rèn)的 16bit進(jìn)一步壓縮顯存占用。這兩招組合使用2GB 上下文級(jí)別的 KV Cache 可以壓縮到 1GB 左右給模型權(quán)重留出更多 GPU 空間。4. 完整實(shí)測(cè)過(guò)程從安裝到流暢對(duì)話的保姆級(jí)記錄4.1 安裝清單與版本信息我的實(shí)測(cè)環(huán)境如下供參考顯卡NVIDIA GeForce RTX 4060 8GBLaptop 版驅(qū)動(dòng)版本551.86Studio 驅(qū)動(dòng)操作系統(tǒng)Windows 11 23H2CPUIntel Core i7-13700H內(nèi)存32GB DDR5 4800MHzOllama 版本0.5.x運(yùn)行ollama --version查看安裝過(guò)程很簡(jiǎn)單去 Ollama 官網(wǎng)下載 Windows 安裝包一路默認(rèn)即可。重點(diǎn)在于配置環(huán)境變量# 設(shè)置模型存儲(chǔ)路徑避免C盤(pán)爆炸 setx OLLAMA_MODELS D:\ollama_models # 開(kāi)啟 Flash Attention setx OLLAMA_FLASH_ATTENTION 1 # KV Cache 用8bit量化省顯存 setx OLLAMA_KV_CACHE_TYPE q8_0提示setx設(shè)置的環(huán)境變量只對(duì)新啟動(dòng)的進(jìn)程生效。一定要重啟 Ollama 服務(wù)或者干脆重啟電腦否則配置不會(huì)加載。4.2 拉取模型并啟動(dòng) 35B 實(shí)測(cè)我用到的命令和輸出長(zhǎng)這樣ollama pull qwen3:30b-a3b ollama run qwen3:30b-a3b第一次 pull 耗時(shí)取決于網(wǎng)速——20GB 的模型哪怕是千兆帶寬也要半小時(shí)以上。建議放在晚上拉順手把網(wǎng)絡(luò)斷點(diǎn)續(xù)傳做好。模型拉取完成、運(yùn)行起來(lái)之后真正的測(cè)試才開(kāi)始。我用三個(gè)維度記錄實(shí)測(cè)數(shù)據(jù)加載速度首 token 延遲、生成速度token/s、顯存占用情況。加載耗時(shí)從執(zhí)行ollama run到模型進(jìn)入待輸入狀態(tài)大約 3-5 秒因?yàn)槟Ｐ统ｑv在內(nèi)存部分是顯存加載。首 token 延遲輸入一段 50 字左右的問(wèn)題約 0.8 秒出第一個(gè)字。生成速度穩(wěn)定在 50-60 token/s屬于“聊天無(wú)壓力閱讀滾動(dòng)跟得上”的水平。對(duì)比 Qwen2.5-32B Q4_K_M 的表現(xiàn)同樣長(zhǎng)度輸入生成速度掉到 6-8 token/s明顯感知到“一個(gè)字一個(gè)字往外蹦”。這說(shuō)明 MoE 架構(gòu)在 CPU 卸載場(chǎng)景下優(yōu)勢(shì)非常明顯——激活參數(shù)少CPU 負(fù)擔(dān)輕。4.3 顯存占用實(shí)測(cè)記錄用數(shù)據(jù)說(shuō)話用任務(wù)管理器或nvidia-smi -l 1實(shí)時(shí)監(jiān)控顯存占用記錄如下Qwen3-30B-A3B上下文 4096模型階段顯存占用GBCPU 內(nèi)存占用GB備注空閑無(wú)模型0.54.5系統(tǒng)基礎(chǔ)占用加載后待機(jī)6.813.2顯存接近滿(mǎn)載對(duì)話中短上下文7.013.5KV Cache 占用增加長(zhǎng)上下文8K7.715.8接近顯存極限結(jié)論很清晰8GB 顯存被榨到 96% 左右再往上就爆了。所以長(zhǎng)文檔總結(jié)、大代碼庫(kù)分析這類(lèi)任務(wù)不適合把上下文狠拉長(zhǎng)顯存會(huì)先崩掉。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 模型加載后 GPU 利用率始終是 0%這是我被問(wèn)得最多的一個(gè)問(wèn)題。通常原因是 Ollama 沒(méi)能調(diào)用 CUDA。排查兩步走第一步確認(rèn)驅(qū)動(dòng)支持。運(yùn)行nvidia-smi看右上角 CUDA Version 是不是 12.x。如果是 11.x 或者更老直接更新驅(qū)動(dòng)。第二步檢查 Ollama 日志。Windows 下日志文件在%LOCALAPPDATA%\Ollama\server.log打開(kāi)后搜CUDA或GPU關(guān)鍵詞看有沒(méi)有報(bào)錯(cuò)。常見(jiàn)的坑筆記本雙顯卡核顯獨(dú)顯用戶(hù)Ollama 默認(rèn)可能走核顯。在 Windows 的“圖形設(shè)置”里把 Ollama 的可執(zhí)行文件設(shè)為“高性能 NVIDIA 處理器”就能解決。這個(gè)問(wèn)題折騰了我一下午最后發(fā)現(xiàn)是系統(tǒng)默認(rèn)調(diào)度把負(fù)載丟給了核顯。5.2 加載到一半就 OOM模型直接消失顯存溢出是 8GB 用戶(hù)的家常便飯。這里分享一個(gè)經(jīng)驗(yàn)法則上下文長(zhǎng)度設(shè)為 2048 或 4096而不是默認(rèn)拉到 8192。KV Cache 是顯存殺手對(duì) 8GB 來(lái)說(shuō)每多出 1K 上下文就意味著要多付出約 200-400MB 顯存。如果已經(jīng) OOM正確操作是先把上下文調(diào)小然后設(shè)置OLLAMA_NUM_PARALLEL1禁止并行推理避免多個(gè)請(qǐng)求同時(shí)擠顯存。同時(shí)把OLLAMA_MAX_LOADED_MODELS1也設(shè)上防止之前加載過(guò)的小模型殘留在顯存里。5.3 回復(fù)質(zhì)量很差感覺(jué)在胡言亂語(yǔ)這一般跟量化等級(jí)和參數(shù)設(shè)置有關(guān)而不是模型本身出了問(wèn)題。Q2_K 這種激進(jìn)量化在 35B 上已經(jīng)明顯影響語(yǔ)義理解能力了至少要上 Q4_K_M。另外檢查一下有沒(méi)有在命令行里亂加溫度參數(shù)。Ollama 默認(rèn)溫度是 0.7但對(duì)中文創(chuàng)作類(lèi)任務(wù)我實(shí)測(cè)下來(lái)0.5 更穩(wěn)邏輯更緊湊追求發(fā)散創(chuàng)意可以調(diào)到 0.8。綜合來(lái)說(shuō)一個(gè)穩(wěn)定且質(zhì)量不錯(cuò)的啟動(dòng)配置長(zhǎng)這樣ollama run qwen3:30b-a3b --num-ctx 4096 --temp 0.5 --top-p 0.95.4 長(zhǎng)對(duì)話后變慢上下文膨脹帶來(lái)的連鎖反應(yīng)剛開(kāi)始對(duì)話很快聊了幾百輪之后越來(lái)越慢逐漸逼近 3-4 token/s。原因很簡(jiǎn)單上下文越長(zhǎng)KV Cache 越大顯存溢出越多卸載到 CPU 的層就越多。對(duì) 8GB 顯存來(lái)說(shuō)這個(gè)衰減幾乎是不可避免的。最實(shí)用的解決辦法是及時(shí)開(kāi)新會(huì)話。需要跨會(huì)話保留記憶的可以把之前對(duì)話的關(guān)鍵結(jié)論手動(dòng)粘到新會(huì)話開(kāi)頭相當(dāng)于給模型喂一段“摘要”。實(shí)測(cè)這種方法在犧牲少量上下文連續(xù)性的情況下能保住推理速度不崩。5.5 為什么別人能流暢跑 70B我只能 Q4這件事值得單獨(dú)說(shuō)。很多人發(fā)帖說(shuō)自己 8GB 顯存流暢跑 70B速度還很快讓人懷疑人生。打開(kāi)帖子細(xì)看不是用了極端的 2bit 量化就是把上下文砍到 512 token。這種“流暢”其實(shí)是定向過(guò)擬合出來(lái)的對(duì)短問(wèn)答來(lái)說(shuō)確實(shí)流暢但你讓他寫(xiě)一份 2000 字的周報(bào)他就露餡了不是撒謊就是復(fù)讀。與其追求“能跑多少 B”不如關(guān)注“能在多大上下文里保持什么質(zhì)量”。8GB 顯存下35B 短上下文對(duì)話是甜點(diǎn)位。超過(guò)這個(gè)范圍不如乖乖用一個(gè) 7B-8B 的小模型加外掛知識(shí)庫(kù)體驗(yàn)反而更好。6. 8GB 本地大模型的潛能邊界與擴(kuò)展玩法6.1 本地大模型不只是聊天玩具很多人以為本地部署大模型就是圖一個(gè)“不用聯(lián)網(wǎng)”實(shí)際玩下來(lái)你會(huì)發(fā)現(xiàn)遠(yuǎn)不止于此。我在 8GB 顯存環(huán)境下做了三個(gè)方向的擴(kuò)展體驗(yàn)都相當(dāng)能打本地知識(shí)庫(kù)問(wèn)答把文檔切塊后灌進(jìn)向量庫(kù)比如 Chroma配合本地大模型做 RAG。35B MoE 的推理質(zhì)量配合檢索能力足以應(yīng)付常見(jiàn)的問(wèn)題解答和文檔分析場(chǎng)景。代碼解釋與補(bǔ)全把一段復(fù)雜代碼丟給它讓它逐行解釋、指出潛在問(wèn)題。8GB 跑 Qwen3-30B 在代碼理解上的表現(xiàn)比 7B 模型高出一個(gè)檔次。離線寫(xiě)作助手把產(chǎn)品文案、周報(bào)、郵件模板這類(lèi)重復(fù)性寫(xiě)作丟給本地模型。不用聯(lián)網(wǎng)、數(shù)據(jù)不出本地對(duì)某些敏感場(chǎng)景而言本身就是剛需。擴(kuò)展玩法中需要注意的RAG 場(chǎng)景下要控制檢索文檔的分塊大小超出上下文長(zhǎng)度時(shí)不是讓模型硬撐而是先做摘要再繼續(xù)。這也回到了前面說(shuō)的“上下文是 8GB 顯存最稀缺的資源”。6.2 下一步硬件升級(jí)的方向判斷如果你覺(jué)得 8GB 實(shí)在不夠用、想升級(jí)我建議按這個(gè)優(yōu)先級(jí)思考先升級(jí)內(nèi)存到 32GB 以上。因?yàn)樾遁d到 CPU 的層需要內(nèi)存支撐內(nèi)存不夠模型根本加載不了。再把顯卡換到 16GB 顯存。16GB 配合 Q4 量化能全程 GPU 推理跑 32B 稠密模型體驗(yàn)質(zhì)變。最后再考慮 CPU 升級(jí)。如果你用的是 MoE 模型CPU 瓶頸影響很大但稠密模型下GPU 還是主導(dǎo)。這條路線背后邏輯很簡(jiǎn)單先解決“能不能跑”再解決“跑得快不快”最后解決“跑得好不好”。8GB 是入門(mén)線16GB 才是甜點(diǎn)這一點(diǎn)希望你能明確預(yù)期。6.3 數(shù)據(jù)安全與隱私價(jià)值再?gòu)?qiáng)調(diào)一次本地部署最大的隱形福利是數(shù)據(jù)不出設(shè)備。我用本地模型處理過(guò)幾份需要保密的測(cè)試數(shù)據(jù)整個(gè)過(guò)程完全離線心里踏實(shí)。相比之下在線 API 雖然方便但數(shù)據(jù)經(jīng)過(guò)第三方服務(wù)器敏感場(chǎng)景基本不適合。當(dāng)然也不是說(shuō)本地就一定絕對(duì)安全。模型文件本身、日志文件都要注意管理不要隨意共享。另外Ollama 默認(rèn)在 11434 端口提供 API如果所在網(wǎng)絡(luò)環(huán)境比較復(fù)雜建議改成僅本機(jī)訪問(wèn)。7. 寫(xiě)給后來(lái)者三個(gè)核心實(shí)操建議7.1 不要被參數(shù)規(guī)模帶偏“35B”數(shù)字很唬人但真正決定體驗(yàn)的是激活參數(shù)量、量化等級(jí)和設(shè)備基礎(chǔ)這三者的聯(lián)合關(guān)系?？吹?35B 先別急著下載先確認(rèn)自己的顯存能放什么等級(jí)的量化、CPU 能兜住多少卸載量。你用 8GB 跑 35B 不是為了跟人比參數(shù)是為了在有限的硬件里拿到最好的綜合體驗(yàn)。7.2 養(yǎng)成環(huán)境變量管理的習(xí)慣Ollama 的許多關(guān)鍵調(diào)優(yōu)都藏在環(huán)境變量里。建議在自己常用位置建一個(gè)配置文件Windows 下可以直接在系統(tǒng)設(shè)置里改把OLLAMA_FLASH_ATTENTION、OLLAMA_KV_CACHE_TYPE、OLLAMA_MODELS一次性設(shè)置好。以后不管拉什么模型都能自動(dòng)享受這些優(yōu)化不用每次重來(lái)。我自己因?yàn)樵缙跊](méi)意識(shí)到這個(gè)問(wèn)題反復(fù)測(cè)試花了不少時(shí)間提醒你好好避坑。7.3 測(cè)試標(biāo)準(zhǔn)要統(tǒng)一對(duì)比不同模型、不同量化等級(jí)時(shí)務(wù)必用同一套測(cè)試數(shù)據(jù)集同一批問(wèn)題、同樣的上下文長(zhǎng)度、同樣的生成參數(shù)。不然你測(cè)出來(lái)的“A 比 B 快”很可能只是上下文長(zhǎng)度不同或者溫度不一致帶來(lái)的假象。我每次測(cè)速都用一樣的 5 個(gè)中文問(wèn)題然后取平均 token/s這樣數(shù)據(jù)跨模型才有參考意義。8. 一個(gè)補(bǔ)充8GB 跑 35B 到底值不值聊了這么多最后把這個(gè)最實(shí)際的問(wèn)題擺到臺(tái)面。8GB 顯存跑 35B 到底值不值我的看法是作為實(shí)驗(yàn)和探索絕對(duì)值。它把一個(gè)“不可能”變成“可能”讓你真正理解顯存、量化、推理架構(gòu)這些概念是怎么在壓力下互相制衡的。但如果你只是想要一個(gè)日常隨手可用的 AI 助手8GB 跑 7B-8B 的模型會(huì)從容得多沒(méi)必要為了追求大參數(shù)而犧牲速度和穩(wěn)定性。這里分享一個(gè)我自己的典型使用配置日常輕量對(duì)話用 7B 模型響應(yīng)迅速、顯存無(wú)壓力需要深度分析、長(zhǎng)文本理解時(shí)切到 Qwen3-30B用慢一點(diǎn)的代價(jià)換高質(zhì)量回答。兩個(gè)模型在 Ollama 里可以共存ollama run命令切換就行非常方便。這種“小而快”與“大而準(zhǔn)”的組合才是 8GB 顯存環(huán)境下真正體面且穩(wěn)定的工作流。最后再分享一個(gè)小技巧如果你跑 35B 模型時(shí)發(fā)現(xiàn)生成速度比預(yù)期慢很多先別急著換硬件檢查一下模型是否真的運(yùn)行在 GPU 上。在對(duì)話界面輸入/set info查看模型運(yùn)行參數(shù)確認(rèn)gpu字段顯示為真。很多時(shí)候速度慢只是因?yàn)槟承┡渲脹](méi)生效模型全部在 CPU 上硬扛。把這篇文章里提到的幾個(gè)環(huán)境變量設(shè)好、測(cè)試一次你會(huì)發(fā)現(xiàn)差距比想象大得多。