1. 為什么大家開始用 CPU 跑 LLaMA1.1 LLaMA 是什么為什么能上 CPU先說一句很多人的誤區(qū)LLaMA 雖然名字里帶著“大”但它并不是只能在數(shù)據(jù)中心里靠 A100/H100 才能轉(zhuǎn)起來的大模型。LLaMA 是 Meta 在 2023 年開源的 Transformer 架構(gòu)大模型系列從 7B、13B、33B 一路到 65B/70B開源社區(qū)很快就圍繞它搭起了一整套推理工具鏈。正是這套工具鏈把“LLaMA 只能跑 GPU”的印象徹底打破了。最關(guān)鍵的一步是 GGUF/GGML 格式的出現(xiàn)。傳統(tǒng) PyTorch 權(quán)重用 FP16/BF16 存儲(chǔ)單個(gè) 7B 模型就要占 14GB 顯存CPU 端幾乎沒法直接碰。后來 llama.cpp 項(xiàng)目把權(quán)重重排、分塊、量化打成 GGUF7B 模型的 4-bit 版本只有 3.7~4.2GB內(nèi)存 8GB 以上的普通電腦就有機(jī)會(huì)完整加載。于是標(biāo)題里那句“LLaMA Now Goes Faster on CPUs”就變得順理成章了CPU 推理追求的不是“超過 GPU”而是把硬件門檻拉低到真正的日常級(jí)別。從實(shí)用角度看現(xiàn)在用 CPU 跑 LLaMA 的典型場(chǎng)景主要有三類。第一類是開發(fā)調(diào)試工程師在本地先把 Prompt、參數(shù)和輸出格式調(diào)通再?zèng)Q定要不要上 GPU 集群第二類是隱私敏感環(huán)境數(shù)據(jù)不離開本機(jī)也不經(jīng)過第三方接口適合處理內(nèi)部文檔和代碼片段第三類是預(yù)算受限的臨時(shí)環(huán)境比如云上只開了 8 核 CPU 的虛擬機(jī)也能在幾分鐘內(nèi)部署一個(gè)小型對(duì)話模型。這些場(chǎng)景的共同點(diǎn)是性能不追求極致但“能跑、可改、不花錢”的彈性非常重要。所以這篇文章的核心不是讓你用 CPU 去挑戰(zhàn) GPU 的算力而是告訴你在 2024 到 2025 年這個(gè)時(shí)間點(diǎn)CPU 推理在 7B~13B 量級(jí)模型上已經(jīng)進(jìn)入了“日?？捎谩眳^(qū)間。只要知道瓶頸在哪、怎么選量化、怎么調(diào)參數(shù)一臺(tái)兩三千塊錢的辦公主機(jī)就能跑出每秒 5~10 個(gè) token 的速度用來做摘要、寫作輔助、代碼補(bǔ)全這類輕量任務(wù)完全夠用。1.2 選 CPU 推理的三個(gè)真實(shí)理由第一個(gè)理由是成本。公司或個(gè)人手里往往已經(jīng)有現(xiàn)成的 CPU 服務(wù)器或高配電腦沒有必要為跑一次實(shí)驗(yàn)立刻買 GPU。GPU 不只硬件貴配套的電源、散熱、機(jī)箱甚至機(jī)房電費(fèi)都要跟著漲。CPU 推理可以把這些存量資源盤活尤其是 7B 模型這種量級(jí)用 CPU 跑的成本幾乎可以忽略。第二個(gè)理由是隱私與數(shù)據(jù)安全。本地推理意味著模型權(quán)重和輸入數(shù)據(jù)都在自己手里不需要把內(nèi)容上傳給模型托管平臺(tái)。對(duì)于代碼片段、發(fā)票信息、內(nèi)部郵件這類數(shù)據(jù)留在本地方是很多團(tuán)隊(duì)的首要需求。llama.cpp 這樣的純本地推理框架天然適合這種場(chǎng)景。第三個(gè)理由是環(huán)境兼容性好得離譜。x86 的 Windows/Linux 能跑ARM 的樹莓派和 Apple Silicon 也能跑甚至在沒有 GPU 的老服務(wù)器上只要系統(tǒng)內(nèi)存夠大就能部署。兼容性好的另一層意思是你不用再跟 CUDA 版本、顯卡驅(qū)動(dòng)、顯存占用這些歷史包袱糾纏一個(gè)可執(zhí)行文件加一個(gè)模型文件所有的事就都齊了。2. 影響 CPU 推理速度的關(guān)鍵因素2.1 內(nèi)存帶寬是真正的天花板如果你想用一句話判斷 CPU 跑 LLaMA 快不快這句話就是LLM 生成 token 時(shí)每次都要把模型權(quán)重完整地從內(nèi)存里讀一遍。這個(gè)規(guī)律決定了 CPU 推理的天花板不是 CPU 的計(jì)算頻率而是內(nèi)存帶寬。我解釋一下原因。大模型生成是一個(gè) token 一個(gè) token 來的每個(gè) token 的計(jì)算過程里神經(jīng)網(wǎng)絡(luò)的每一層都要按順序和全部權(quán)重做矩陣運(yùn)算。即使用了 4-bit 量化權(quán)重總量擺在那兒例如 4GB 的量化模型一次 token 生成理論上就要從主存搬運(yùn)約 4GB 數(shù)據(jù)。內(nèi)存帶寬越高搬運(yùn)越快你體驗(yàn)到的生成速度就越快。拿參數(shù)來算賬會(huì)清楚很多。DDR4-3200 雙通道內(nèi)存的理論帶寬大約是 51.2GB/s用 4.1GB 的 Q4 模型來跑理論上限約等于 51.2 ÷ 4.1也就是 12.5 token/s。實(shí)際還要算上并行開銷、緩存命中、內(nèi)存控制器爭(zhēng)用所以能跑到 6~9 token/s 就已經(jīng)算正常。換句話說如果你看到有人在 8 核 CPU 上用 7B 模型跑出 25 token/s不用懷疑那多半是內(nèi)存帶寬特別高比如 Apple Silicon 的統(tǒng)一內(nèi)存帶寬接近 100GB/s跑 4-bit 7B 才能有這個(gè)成績(jī)。這里還要區(qū)分兩個(gè)階段Prompt 處理階段主要是矩陣乘多核 CPU 的計(jì)算能力更關(guān)鍵生成階段才是權(quán)重掃內(nèi)存內(nèi)存帶寬成了唯一瓶頸。實(shí)際表現(xiàn)是生成時(shí) CPU 占用率反而會(huì)下降但風(fēng)扇依然狂轉(zhuǎn)因?yàn)殡U(xiǎn)了很久的內(nèi)存控制器忙著搬運(yùn)數(shù)據(jù)。如果你發(fā)現(xiàn)自己的 CPU 有多核卻用不滿別急著調(diào)線程先看看內(nèi)存是不是跑在雙通道上、頻率是不是被 BIOS 降到 2133 了。內(nèi)存帶寬這回事情按經(jīng)驗(yàn)優(yōu)先級(jí)排個(gè)序雙通道 高頻 低延遲。DDR4-2400 升到 DDR4-3600 能帶來約 15~20% 的生成提速而你從 6 核換到 8 核 CPU 帶來的提升往往還沒有這么明顯。尤其是在 13B 模型上內(nèi)存帶寬對(duì)速度的影響幾乎就是生死線。2.2 指令集與線程數(shù)不是越多越好除了帶寬CPU 的指令集擴(kuò)展也對(duì) LLaMA 推理速度影響巨大。GGUF 量化格式在 x86 CPU 上需要把 4-bit 權(quán)重反量化回浮點(diǎn)數(shù)再計(jì)算這一步強(qiáng)依賴 SIMD 指令。AVX2 是絕對(duì)的分水嶺支持 AVX2 的 CPU 跑 Q4_K_M效率比只支持 SSE 的老 CPU 高出幾倍而 AVX-512 在部分服務(wù)器 CPU 上還能再快一截但因?yàn)闀?huì)觸發(fā)降頻在桌面端反而忽快忽慢。llama.cpp 的官方編譯版本會(huì)默認(rèn)啟用一些通用優(yōu)化如果你自己編譯一定要用 Release 模式并且?guī)?native 優(yōu)化參數(shù)。具體做法后文會(huì)寫。這里想先糾正一個(gè)慣性思維不是把線程開到最大就能得到最大速度。生成階段受帶寬限制線程數(shù)超過物理核心數(shù)以后超線程虛擬核心反而會(huì)爭(zhēng)搶內(nèi)存控制器性能甚至?xí)雇?。我自己常用的方法是先取物理核心?shù)比如 8 核 16 線程就設(shè)-t 8然后跑一個(gè)短采樣再試-t 12和-t 16速度哪個(gè)高就用哪個(gè)。個(gè)別 CPU 上 16 線程比 8 線程還慢不用驚訝。Prompt 處理階段更吃多核這時(shí)可以考慮單獨(dú)調(diào)--threads-batch讓前處理階段用更多線程生成階段保持受限兩頭都能兼顧。2.3 量化精度選擇速度、質(zhì)量與內(nèi)存的三方平衡GGUF 家族里量化標(biāo)記看起來像暗號(hào)Q4_0、Q4_K_S、Q4_K_M、Q5_K_M、Q6_K、Q8_0。簡(jiǎn)單拆解一下Q 后面的數(shù)字代表平均每個(gè)權(quán)重占多少 bit字母后綴代表分類分組的策略。K 系列用了 k-quant 方法對(duì)不同張量分配不同 bit 數(shù)效果比普通線性量化更好。如果你只想記一個(gè)結(jié)論那就是7B 量級(jí)模型優(yōu)先選 Q4_K_M。原因有三個(gè)內(nèi)存占用合適速度接近 Q4_0質(zhì)量明顯優(yōu)于 Q4_0。Q5_K_M 質(zhì)量更好但文件體積和讀取量都漲一檔生成速度會(huì)回落 10~20%。Q8_0 在 CPU 上除非內(nèi)存特別富裕否則生成速度下降更明顯多數(shù)情況下不劃算。如果你的內(nèi)存實(shí)在吃緊比如 6GB 內(nèi)存還想跑 7B 模型可以試著用 Q3_K_M 或 Q2_K但要做好質(zhì)量明顯下降的準(zhǔn)備尤其是中文長(zhǎng)文本和代碼任務(wù)很可能出現(xiàn)句式破碎、邏輯不通。遇到這種情況我更建議換一個(gè)小一點(diǎn)的模型而不是死守 7B 硬上低比特。量化只能幫你在同一模型里省內(nèi)存救不了“模型本身太大”的窘境。3. 從零編譯 llama.cpp 到成功加載模型3.1 環(huán)境準(zhǔn)備與源碼編譯實(shí)戰(zhàn)要體驗(yàn) CPU 提速最穩(wěn)的路線是用 llama.cpp 而不是 Python 推理框架。llama.cpp 是 C/C 實(shí)現(xiàn)不用裝 PyTorch不依賴 CUDA資源開銷小啟動(dòng)速度快并且所有優(yōu)化都針對(duì) CPU 設(shè)計(jì)。理論上 Windows、Linux、macOS 都能用我下面的命令以 Linux 和 macOS 為主。先克隆倉(cāng)庫git clone https://github.com/ggerganov/llama.cpp cd llama.cpp然后創(chuàng)建 Release 構(gòu)建目錄并編譯cmake -B build -DCMAKE_BUILD_TYPERelease cmake --build build --config Release -j 8-j 8是編譯并行度根據(jù)你的 CPU 核心數(shù)調(diào)整比如 16 核就-j 16。在 Linux 下編譯完成后可執(zhí)行文件會(huì)集中放到build/bin常見的幾個(gè)分別是llama-cli、llama-server、llama-quantize、llama-bench。Windows 下建議安裝 Visual Studio 的 C 生成工具然后打開“x64 Native Tools Command Prompt”進(jìn)入 llama.cpp 目錄再執(zhí)行相同命令。需要注意的是編譯路徑不要帶中文和空格否則 CMake 配置階段可能報(bào)一些莫名其妙的錯(cuò)誤。編譯時(shí)如果你確認(rèn) CPU 是近幾年的 x86 型號(hào)可以加一個(gè)-DGGML_NATIVEON 讓編譯器針對(duì)本機(jī)指令集自動(dòng)優(yōu)化速度通常能再提升幾個(gè)百分點(diǎn)。但這樣做出來的可執(zhí)行文件不能隨意拷貝到別的電腦上否則可能直接觸發(fā)非法指令崩潰。3.2 拿到 GGUF 模型文件的三種方式第一種方式是直接從 Hugging Face 下載別人轉(zhuǎn)好的 GGUF 文件。以常見的 Qwen2.5-7B-Instruct 為例huggingface-cli download Qwen/Qwen2.5-7B-Instruct-GGUF qwen2.5-7b-instruct-q4_k_m.gguf --local-dir ./model如果沒有安裝 Hugging Face CLI也可以翻到模型頁面找到下載鏈接用 wget 或 curl 直接拉wget https://huggingface.co/Qwen/Qwen2.5-7B-Instruct-GGUF/resolve/main/qwen2.5-7b-instruct-q4_k_m.gguf第二種方式是“自己動(dòng)手轉(zhuǎn)換”。如果你手上只有一個(gè) PyTorch 格式的 HF 權(quán)重目錄可用 llama.cpp 自帶的轉(zhuǎn)換腳本先轉(zhuǎn) GGUF FP16再量化python convert_hf_to_gguf.py ./qwen2.5-7b-instruct --outfile ./qwen2.5-7b-f16.gguf ./build/bin/llama-quantize ./qwen2.5-7b-f16.gguf ./qwen2.5-7b-q4_k_m.gguf q4_k_m這個(gè)流程的好處是你能親眼看到“從原始權(quán)重到量化模型”的完整變化也方便自己拿不同量化等級(jí)做對(duì)比。轉(zhuǎn)換時(shí)記得把convert_hf_to_gguf.py換成倉(cāng)庫當(dāng)前路徑下的實(shí)際位置轉(zhuǎn)換腳本可能需要安裝ggufPython 包缺了就順手 pip 裝一下。第三種方式是官方或第三方已經(jīng)提供完整 GGUF 目錄的鏡像站點(diǎn)。無論是哪種方式核心原則是確保 GGUF 文件與模型架構(gòu)、聊天模板匹配。llama-cli 在加載時(shí)一般能自動(dòng)識(shí)別模板但如果你下載的是一個(gè)裸的基座模型而不是指令模型生成內(nèi)容大概率是在續(xù)寫而不是對(duì)話別懷疑是程序壞了。3.3 核心運(yùn)行參數(shù)逐個(gè)說llama.cpp 最基礎(chǔ)的運(yùn)行命令長(zhǎng)這樣./build/bin/llama-cli \ -m ./model/qwen2.5-7b-instruct-q4_k_m.gguf \ -p 用一句中文解釋什么是CPU推理 \ -t 8 \ -c 4096 \ -n 512 \ --mlock \ --temp 0.7 \ --repeat-penalty 1.15逐項(xiàng)解釋。-m指定模型路徑-p是輸入提示詞-t是線程數(shù)先按物理核心數(shù)來-c是上下文長(zhǎng)度普通任務(wù) 4096 足夠開得越大 KV cache 占用越多-n是生成 token 數(shù)的上限--mlock把已加載模型鎖在物理內(nèi)存里防止系統(tǒng)把內(nèi)存頁換到磁盤造成掉速--temp和--repeat-penalty是采樣參數(shù)前者控制隨機(jī)性后者壓制重復(fù)病句。如果只想做普通的單輪生成上面的命令就夠了。想要交互式對(duì)話加參數(shù)-i -cnv進(jìn)入多輪聊天模式這樣每次輸入用戶消息模型都會(huì)參考前文繼續(xù)回復(fù)./build/bin/llama-cli -m ./model/qwen2.5-7b-instruct-q4_k_m.gguf -t 8 -c 4096 -i -cnv交互模式下按CtrlC退出注意不同版本的按鍵定義略有區(qū)別。我這里特別提示一句第一次運(yùn)行看到“l(fā)lama_new_context_with_model: n_ctx 4096”這樣的日志不要慌張它只是在告訴你上下文配置好了。接下來最要緊的是觀察兩行信息一行是“l(fā)lama_model_load: model size”告訴你實(shí)際加載的模型體積另一行是“l(fā)oad time”如果加載耗時(shí)超過幾十秒說明磁盤或內(nèi)存可能有問題也可能是--mlock參數(shù)沒生效。4. 實(shí)際跑分與調(diào)優(yōu)思路4.1 不同硬件環(huán)境下取得的實(shí)測(cè)速度我把自己在幾類硬件上跑 7B/8B 量化模型的實(shí)際數(shù)據(jù)整理成一個(gè)表供你對(duì)照參考。這里的數(shù)值都是在 llama.cpp 默認(rèn) Release 編譯、量化等級(jí) Q4_K_M、上下文 4096 的條件下得到的近似結(jié)果不代表某一顆 CPU 的絕對(duì)極限。CPU/設(shè)備內(nèi)存配置模型生成速度token/s備注AMD Ryzen 5 5600XDDR4-3600 雙通道Qwen2.5-7B Q4_K_M8~10生成階段線程并沒有吃滿Apple M2Mac mini16GB 統(tǒng)一內(nèi)存Llama-3-8B Q4_K_M25~30內(nèi)存帶寬優(yōu)勢(shì)明顯雙路 Xeon E5-2678 v3DDR4-2133 八通道Llama2-13B Q4_K_M6~8老服務(wù)器NUMA 影響較大Intel i5-4460DDR3-1600 雙通道7B Q4_K_M3~4無 AVX2體感非常慢從表里能看出決定生成速度的第一要素是內(nèi)存帶寬而不是 CPU 品牌或核心數(shù)。Ryzen 5 5600X 的單核性能不差但它受限于雙通道 DDR4 帶寬最終只能跑到每秒 8~10 token。Apple M2 的強(qiáng)項(xiàng)在于統(tǒng)一內(nèi)存帶寬非常寬等效帶寬接近 100GB/s所以即便核心數(shù)量不多token 生成速度也能比傳統(tǒng) x86 平臺(tái)高出三倍。老平臺(tái)的問題則更明顯。i5-4460 那臺(tái)機(jī)器不僅內(nèi)存帶寬低而且還缺少 AVX2 指令集跑 4-bit 量化模型時(shí)反量化速度嚴(yán)重拖后腿體感從模型開始輸出到第一個(gè)字出來都要等好幾秒。如果你手里的 CPU 是 2015 年以前的入門級(jí)型號(hào)建議先確認(rèn)有沒有 AVX2沒有的話優(yōu)化空間會(huì)非常有限。4.2 調(diào)整線程與批處理的優(yōu)先級(jí)當(dāng)你面對(duì)一臺(tái)完全未知的機(jī)器調(diào)整順序應(yīng)該按作用大小來。先把量化模型換好這是基準(zhǔn)再確認(rèn)內(nèi)存是不是雙通道、頻率有沒有被鎖然后才去試線程數(shù)和批處理大小而不是盲目堆參數(shù)。線程數(shù)的測(cè)試方法很簡(jiǎn)單用同一段 prompt 分別跑-t 4、-t 6、-t 8、-t 12記錄每個(gè)配置下的生成 token/s。我實(shí)測(cè)的經(jīng)驗(yàn)是生成速度的差異通常只在 10% 以內(nèi)極端情況下還會(huì)出現(xiàn)線程越多越慢的情況。Prompt 處理速度則明顯受線程數(shù)影響這時(shí)你需要調(diào)整--threads-batch參數(shù)讓它高于-t比如生成用 8 線程批處理用 16 線程。批處理大小對(duì)應(yīng)的參數(shù)是-b和-ub比如你可以加-b 512 -ub 512。批處理越大模型在 prompt 階段一次掃描的 token 數(shù)越多前處理時(shí)間越短但同時(shí)會(huì)臨時(shí)占用更多內(nèi)存并提高延遲峰值的波動(dòng)脈動(dòng)。我的建議是只有在 Prompt 明顯很長(zhǎng)或首 token 延遲不能接受時(shí)才把-b從默認(rèn)值提高到 512 或 1024日常短 Prompt 用默認(rèn)值就足夠。4.3 KV Cache 對(duì)內(nèi)存的壓力很多人只算模型文件大小卻忘了上下文本身也要吃內(nèi)存。KV Cache 存的是模型在推理過程中為每個(gè) token 保留的鍵值向量長(zhǎng)度越大緩存越大。公式大約是這樣KV 緩存字節(jié)數(shù) ≈ 層數(shù) × KV 頭數(shù) × 頭維度 × 上下文長(zhǎng)度 × 2K 和 V 兩組× 2FP16 需要 2 字節(jié)。以 Llama-3-8B 為例它大約有 32 層、8 個(gè) KV 頭、每個(gè)頭維度 128如果上下文設(shè)為 8192KV 緩存會(huì)占到大約 1GB。如果你同時(shí)加載了一個(gè) 5GB 的量化模型內(nèi)存總量很容易沖到 7GB 以上。這也是為什么運(yùn)行時(shí)要根據(jù)實(shí)際內(nèi)存來設(shè)-c而不是隨手開到 32768。關(guān)掉不需要的長(zhǎng)上下文能省下的內(nèi)存遠(yuǎn)比換一個(gè)更小的量化模型要現(xiàn)實(shí)。如果你的 llama.cpp 版本支持 Flash Attention記得加-fa 1。FA 會(huì)重新計(jì)算部分注意力矩陣而不是全程緩存長(zhǎng)上下文下既能降低 KV 緩存占用又有機(jī)會(huì)減少部分計(jì)算量。對(duì)于 7B 模型來說短上下文下提升不明顯但 8192 以上時(shí)值得一試。5. 常見問題與避坑記錄5.1 高頻報(bào)錯(cuò)與解決方案速查我在實(shí)踐和幫朋友排查時(shí)遇到的報(bào)錯(cuò)九成都能歸到下面這張表里?，F(xiàn)象原因解決方案Illegal instruction (core dumped)可執(zhí)行文件用了當(dāng)前 CPU 不支持的指令集比如在沒 AVX2 的機(jī)器上跑了帶 AVX2 的二進(jìn)制源碼重新編譯不拷貝別人的可執(zhí)行文件檢查 BIOS 是否關(guān)閉了相關(guān)指令擴(kuò)展failed to allocate memory模型加 KV Cache 總需求大于可用內(nèi)存調(diào)小-c或-b換 Q3/Q4 量化關(guān)閉其他內(nèi)存大戶生成速度極慢甚至不到 1 token/s沒有 AVX2 指令集或線程設(shè)置過多優(yōu)先確認(rèn)指令集其次降低線程數(shù)最后換更小量化加載模型后系統(tǒng)開始瘋狂 swap--mlock沒生效或內(nèi)存不足確認(rèn)物理內(nèi)存足夠用free -h檢查剩余空間輸出是亂碼或中英文混雜終端編碼或聊天模板不匹配在 UTF-8 終端下運(yùn)行換 prompt 模板或重新轉(zhuǎn)換模型雙路服務(wù)器提速不明顯NUMA 跨節(jié)點(diǎn)訪問導(dǎo)致遠(yuǎn)端內(nèi)存延遲高用taskset/numactl綁定 CPU 和內(nèi)存節(jié)點(diǎn)盡量一個(gè)模型跑在一個(gè) NUMA 域內(nèi)如果你的問題沒有列在里面先跑一行帶--verbose的命令把加載信息完整看一遍。llama.cpp 啟動(dòng)時(shí)會(huì)把模型超參數(shù)、上下文大小、內(nèi)存占用都打印出來大部分答案就在日志里。報(bào)錯(cuò)解決不了時(shí)別急著懷疑代碼先重新下載一個(gè)干凈模型文件很多莫名其妙的崩潰都是文件損壞或是不完整下載導(dǎo)致的。5.2 我這幾條獨(dú)家經(jīng)驗(yàn)踩過不少坑第一不要一上來就追求大模型。在 CPU 上13B 比 7B 更吃內(nèi)存帶寬速度會(huì)掉到 7B 的三分之二左右。如果你只有 16GB 內(nèi)存我建議老老實(shí)實(shí)跑 7B/8B 模型把速度做穩(wěn)之后再考慮更大參數(shù)量的模型。第二線程數(shù)設(shè)置請(qǐng)務(wù)必實(shí)測(cè)。同一顆 CPU 在-t 8和-t 16之間可能只有 5% 差距但在老款超線程 CPU 上成績(jī)很可能開倒車。別相信別人說的“16 線程一定比 8 線程快”內(nèi)存帶寬才是老大。第三檢查內(nèi)存頻率非常值錢。很多人主板上明明插著 3200MHz 的內(nèi)存卻因?yàn)橥碎_ XMP 或 BIOS 里默認(rèn) 2133MHz白白損失 20% 帶寬。你在 BIOS 里把內(nèi)存頻率調(diào)上去之后再跑一次llama-bench看數(shù)字變化往往會(huì)驚掉下巴。第四啟動(dòng)時(shí)加--mlock但不一定加--no-mmap。--mlock避免換頁--no-mmap則是讓模型一次性完整讀入內(nèi)存。虛擬內(nèi)存比較混亂的環(huán)境里我可以保底使用但如果內(nèi)存緊張--no-mmap會(huì)導(dǎo)致加載失敗所以只在確有必要時(shí)打開它。5.3 如何判斷自己的 CPU 該選哪種量化先用固定命令跑一個(gè)基準(zhǔn)測(cè)試比如./build/bin/llama-bench -m ./model/q4_k_m.gguf -t 8llama-bench 會(huì)分別給出 Prompt 處理速度和生成速度它比手動(dòng)掐秒表靠譜得多。然后在同一臺(tái)機(jī)器上換另一個(gè)量化文件比如 Q5_K_M 和 Q8_0分別跑一遍對(duì)比生成速度。如果 Q8_0 比 Q4_K_M 慢 25% 以上說明你的內(nèi)存帶寬已經(jīng)到瓶頸繼續(xù)增大量化位寬帶來的質(zhì)量提升根本不劃算。選量化的黃金法則可以概括成一句話內(nèi)存裝得下、速度可接受時(shí)挑你情感上能接受的質(zhì)量檔位。7B 模型上我更推薦 Q4_K_M 做日常主力Q5_K_M 做質(zhì)量敏感任務(wù)Q8_0 只在內(nèi)存實(shí)在寬裕時(shí)才考慮。請(qǐng)記住CPU 推理追求的是“綜合可用”而不是單一指標(biāo)上的極致。6. 從“能跑”到“好用”的幾點(diǎn)體會(huì)最近這半年我在本地 CPU 上跑 LLaMA 的次數(shù)越來越多甚至有些正式原型驗(yàn)證工具也直接用 llama.cpp 當(dāng)后端。最讓我意外的不是模型能跑起來——這是早就可以做到的事而是當(dāng)我把內(nèi)存帶寬、量化粒度、線程調(diào)度這些因素理解清楚之后一臺(tái)普通機(jī)器的推理速度居然還能再壓出近一倍的差距。有一次我在一臺(tái) 8 核 16 線程的臺(tái)式機(jī)上跑 Qwen2.5-7B一開始生成速度只有 5 token/s可把我煩得不行。仔細(xì)排查后發(fā)現(xiàn)兩個(gè)問題一是內(nèi)存跑在 2133MHz二是線程數(shù)設(shè)成了 16。把內(nèi)存頻率調(diào)到 3600MHz、線程改回 8再重新編譯帶 native 優(yōu)化參數(shù)的 llama.cpp生成速度硬生生提到了 10 token/s。這個(gè)過程看起來不起眼但工程實(shí)踐中“順暢可用”和“勉強(qiáng)能跑”往往就差這幾步調(diào)整。如果你也想在自己的機(jī)器上復(fù)現(xiàn)整套流程我建議從 7B 模型加 Q4_K_M 開始先把一條命令跑通再逐步嘗試不同線程數(shù)和內(nèi)存配置。量化和推理框架的發(fā)展速度很快說不定過幾個(gè)月 CPU 上的 token 速度又會(huì)被刷新一遍但內(nèi)存帶寬、指令集和量化選擇這些底層邏輯不會(huì)變。把底層邏輯吃透以后無論換模型還是換框架你都能快速判斷什么改動(dòng)真正值得做什么只是表面繁榮。