前幾天一個(gè)朋友拎著一張 24GB 顯存的顯卡來(lái)找我開(kāi)門(mén)見(jiàn)山想跑 70B 模型。我第一反應(yīng)是先問(wèn)他“你準(zhǔn)備用哪個(gè)量化方案”因?yàn)樵趩慰ōh(huán)境下70B 模型的 FP16 原始權(quán)重就要超過(guò) 140GB不量化根本連起點(diǎn)都摸不到。而量化之后又會(huì)牽扯出一連串推理優(yōu)化問(wèn)題上下文窗口能開(kāi)多大、批量能塞多少、KV cache 會(huì)不會(huì)爆、用 llama.cpp 還是 vLLM。這幾層問(wèn)題疊在一起其實(shí)不是“跑一個(gè)模型”而是一整套五層技術(shù)棧的選擇題。這篇內(nèi)容就是針對(duì)“讓 70B 跑在單卡”這件事的完整拆解從顯存預(yù)算、量化方案、模型格式、推理引擎一直到 KV cache 和運(yùn)行參數(shù)每一層我都把原理和實(shí)操放到一起講。適合想在單張顯卡上部署大模型的工程師、做私有化推理的同學(xué)也適合手里只有一張 4090 或 48GB 顯卡卻想折騰大參數(shù)模型的玩家?？赐昴阒辽倌芑卮鹑齻€(gè)問(wèn)題為什么非要量化、量化到多少合適、跑起來(lái)之后哪些參數(shù)最容易讓顯存爆炸。1. 先算一筆顯存賬70B 為什么天然排斥單卡1.1 光權(quán)重就已經(jīng) 140GB其它開(kāi)銷還沒(méi)算模型占用顯存的第一大頭永遠(yuǎn)是權(quán)重本身。70B 參數(shù)指的是參數(shù)量不是字節(jié)數(shù)。顯存占用取決于每個(gè)參數(shù)用多少位來(lái)存FP32 是 4 字節(jié)所以 70B 參數(shù)就要 70B × 4B 280GBFP16/BF16 是 2 字節(jié)要 140GBINT8 是 1 字節(jié)要 70GBINT4 是 0.5 字節(jié)理論上只要 35GB。單卡環(huán)境里常見(jiàn)的顯存是 24GB4090、3090 級(jí)別和 48GBA6000、L40S 級(jí)別前者連 INT8 權(quán)重都裝不下后者也只能勉強(qiáng)容納 INT4 級(jí)別的權(quán)重。所以“讓 70B 跑在單卡”這句話的潛臺(tái)詞其實(shí)就是“把權(quán)重壓到 INT4 或等效精度再把其它開(kāi)銷壓縮到極致”。但這只是權(quán)重賬。真正跑推理的時(shí)候還有三塊開(kāi)銷KV cache注意力緩存的中間結(jié)果、激活值前向計(jì)算圖的中間張量、以及 CUDA context 和框架本身的基本占用。后兩項(xiàng)加起來(lái)隨架構(gòu)不同能吃掉 2GB 到 8GB 不等有時(shí)候你明明算好權(quán)重只要 40GB實(shí)際一加載就報(bào) OOM就是因?yàn)橥私o這些“隱形住戶”留位置。1.2 單卡不是沒(méi)顯存是沒(méi)有“臨時(shí)空間”把 70B 壓縮進(jìn)單卡很多人第一反應(yīng)是“量化到 INT4 就完事了”。實(shí)際上權(quán)重塞進(jìn)去之后真正限制你的是臨時(shí)空間。推理和訓(xùn)練不一樣訓(xùn)練是一次性把整個(gè)批次灌進(jìn)顯存推理是逐 token 生成。每生成一個(gè) token注意力層的 K 和 V 緩存都會(huì)累計(jì)增加。也就是說(shuō)輸入越長(zhǎng)、對(duì)話輪次越多、批量越大KV cache 就越大。權(quán)重是固定成本KV cache 是隨時(shí)間增長(zhǎng)的可變成本。單卡環(huán)境里這兩者在爭(zhēng)奪同一塊顯存。所以“能裝下”和“跑得動(dòng)”是兩回事。你用 INT4 把權(quán)重壓到 38GB 左右看著 48GB 顯卡剩余 10GB似乎挺寬?？梢坏┥舷挛脑O(shè)到 16K、批量推到 4KV cache 直接吃掉 5GB 以上再疊加激活值和 CUDA contextOOM 就像定時(shí)炸彈。這也是后面每一節(jié)都要圍繞“顯存總預(yù)算”來(lái)設(shè)計(jì)的原因。1.3 五層技術(shù)棧的整體劃分我把單卡跑 70B 這件事拆成五層每層解決一類獨(dú)立問(wèn)題層級(jí)解決的核心問(wèn)題常用手段對(duì)應(yīng)章節(jié)第 1 層權(quán)重精度讓權(quán)重體積從 140GB 降到可接受范圍FP16、BF16、INT8、INT4、FP8第 2 節(jié)第 2 層量化方法在壓體積的同時(shí)盡量保住質(zhì)量GPTQ、AWQ、GGUF Q4、校準(zhǔn)集第 2 節(jié)第 3 層模型格式與轉(zhuǎn)換讓模型能被指定推理框架讀取HuggingFace 權(quán)重、GGUF、ONNX第 3 節(jié)第 4 層推理引擎與內(nèi)存調(diào)度分配顯存、管理 KV cache、控制批處理llama.cpp、vLLM、PagedAttention第 4 節(jié)第 5 層運(yùn)行參數(shù)調(diào)優(yōu)在顯存預(yù)算內(nèi)平衡質(zhì)量、速度和并發(fā)context length、batch、gpu offload第 5 節(jié)這五層是層層依賴的關(guān)系權(quán)重精度決定你剩下多少顯存給 KV cache量化方法決定壓縮后的模型質(zhì)量格式必須匹配框架框架的調(diào)度方式?jīng)Q定并發(fā)能力而最后一層參數(shù)設(shè)置則是前面所有選擇的最終校驗(yàn)。很多人失敗的原因就是把精力全放在第一層權(quán)重一量化就著急跑結(jié)果在第四、第五層瘋狂撞墻。2. 量化選型FP8、INT8、INT4 與三種主流方法2.1 位寬不是越低越好得看精度損失曲線先列一張我常用的位寬對(duì)照表精度權(quán)重占用70B相對(duì) FP16 的壓縮率主要問(wèn)題FP16/BF16140GB1x單卡放不下FP870GB2x受硬件和框架支持限制消費(fèi)卡收益一般INT870GB2x可以跑但精度損失比 FP8 略明顯需校準(zhǔn)INT4約 35-40GB約 3.5x壓縮率高但敏感層容易崩質(zhì)量FP8 是最容易被誤會(huì)的一檔。它在 H100 這類原生支持 FP8 的卡上有收益但在消費(fèi)級(jí)顯卡上經(jīng)常是“名義上支持、實(shí)際跑得慢”甚至框架里根本沒(méi)有優(yōu)化要讓 70B 跑到單卡FP8 的 70GB 權(quán)重體積已經(jīng)超出了 48GB 的承受范圍所以真正的主力是 INT8 和 INT4。INT8 適合 48GB 顯卡跑一些對(duì)質(zhì)量敏感但又想保住體面的場(chǎng)景權(quán)重 70GB 對(duì) 48GB 還是放不下因此單卡 70B 幾乎唯一現(xiàn)實(shí)的路線就是 INT4 系列。需要注意INT4 不是把每個(gè)參數(shù)機(jī)械地砍掉一半而是用少量高位寬參數(shù)去補(bǔ)償?shù)捅忍亓炕瘞?lái)的誤差。這個(gè)“補(bǔ)償”體現(xiàn)在 group size、scale 和 zero point 上直接決定了實(shí)際文件會(huì)比剛才的“35GB理論值”多出幾 GB。2.2 GPTQ、AWQ 和 GGUF 的 Q4三套量化方法該怎么選常見(jiàn)的 INT4 量化方法有三種我簡(jiǎn)單說(shuō)說(shuō)它們的設(shè)計(jì)思路和適用場(chǎng)景。GPTQ 是一套基于 Hessian 矩陣的逐層量化方法。它會(huì)在量化每一層時(shí)用一小批校準(zhǔn)數(shù)據(jù)來(lái)估計(jì)權(quán)重的重要程度把量化誤差分配到不那么重要的參數(shù)上。優(yōu)點(diǎn)是量化速度快、社區(qū)生態(tài)成熟vLLM 和 HuggingFace 的集成度都高缺點(diǎn)是如果你后續(xù)跑的任務(wù)類型和校準(zhǔn)數(shù)據(jù)差異很大質(zhì)量會(huì)略受影響。AWQ 的思路不一樣它不看權(quán)重而看激活值。AWQ 認(rèn)為某些通道的激活值波動(dòng)大這些通道對(duì)應(yīng)的權(quán)重應(yīng)該保留更高的精度。它不需要反向傳播用激活值統(tǒng)計(jì)信息就能完成量化。我實(shí)測(cè)下來(lái)AWQ 在長(zhǎng)文本任務(wù)里往往比同精度的 GPTQ 更穩(wěn)特別是代碼生成和數(shù)學(xué)題這種對(duì)細(xì)節(jié)敏感的場(chǎng)景。GGUF 里的 Q4 又不太一樣。它是 llama.cpp 體系下的量化格式Q4_K_M 這類名字里的“K”代表 k-quants 混合量化。簡(jiǎn)單說(shuō)它會(huì)根據(jù)每個(gè)張量?jī)?nèi)部的結(jié)構(gòu)分配不同位寬注意力層的部分張量用 6bitFFN 的某些部分用 4bit這樣整體文件還是約 4bit 的量級(jí)但關(guān)鍵部分精度更高。對(duì)比起來(lái)方法配套框架量化依據(jù)適合場(chǎng)景GPTQvLLM、Transformers權(quán)重重要性 校準(zhǔn)集服務(wù)化部署、離線批量推理AWQvLLM、部分服務(wù)框架激活值統(tǒng)計(jì)長(zhǎng)文本、代碼、高精度要求GGUF Q4llama.cpp混合比特分配本地部署、邊緣端、單機(jī)調(diào)試一句話總結(jié)你想用 vLLM 做并發(fā)服務(wù)優(yōu)先 GPTQ 或 AWQ你想在單機(jī)上用最簡(jiǎn)單可靠的方式跑通GGUF 加 llama.cpp 最省心。2.3 量化參數(shù)怎么設(shè)group size、校準(zhǔn)數(shù)據(jù)和 KV cache 量化選了方法之后還有一組參數(shù)要定其中最容易踩坑的是 group size。group size 是指多少個(gè)權(quán)重參數(shù)共享一個(gè)量化縮放因子。常見(jiàn)值是 128想做更精細(xì)的量化可以降到 32。數(shù)值越小量化顆粒度越細(xì)精度越好但存儲(chǔ)開(kāi)銷越大速度也可能變慢因?yàn)橐x更多 scale 信息。對(duì) 70B 模型來(lái)說(shuō)group size 從 128 降到 32文件體積可能從 38GB 跳到 41GB 以上這多出來(lái)的 3GB 很可能直接擠爆你的顯存預(yù)算。校準(zhǔn)數(shù)據(jù)也值得認(rèn)真對(duì)待。它通常是一批文本用來(lái)統(tǒng)計(jì)權(quán)重或激活的數(shù)值分布。這里有一個(gè)很反直覺(jué)的點(diǎn)校準(zhǔn)數(shù)據(jù)不需要很多但一定要貼近你的真實(shí)任務(wù)。比如你要做的是代碼補(bǔ)全卻用長(zhǎng)篇新聞文本做校準(zhǔn)那么生成代碼時(shí)精度就可能不如預(yù)期。我習(xí)慣從目標(biāo)任務(wù)的真實(shí)數(shù)據(jù)里隨機(jī)抽一二百條樣本截成 512 或 1024 token 的片段用作校準(zhǔn)集不貪多。還有不少人主動(dòng)把 KV cache 也量化掉。llama.cpp 里有專門(mén)的 KV cache 量化選項(xiàng)vLLM 也支持 kv cache 的 FP8/INT8 存儲(chǔ)。這件事有利有弊它能立刻省出接近一半的緩存顯存但代價(jià)是長(zhǎng)上下文下的質(zhì)量下降。我的建議是只有在上下文長(zhǎng)度或并發(fā)量確實(shí)需要那部分顯存時(shí)才開(kāi) KV cache 量化并且先在目標(biāo)長(zhǎng)度下做一輪質(zhì)量對(duì)比不要默認(rèn)開(kāi)啟。3. 實(shí)操鏈路從原始權(quán)重到 GGUF再到 llama.cpp / vLLM3.1 一條能跑的鏈路先用 GGUF 打通再考慮框架實(shí)戰(zhàn)里最容易讓人心態(tài)崩的時(shí)刻不是模型太大而是“所有安裝都正確但就是跑不出結(jié)果”。所以我推薦的第一條鏈路是 GGUF llama.cpp原因是它有最完整的單機(jī)工具鏈從權(quán)重轉(zhuǎn)換到量化再到運(yùn)行每一步都有獨(dú)立命令出了問(wèn)題也好定位。第一步先把模型權(quán)重格式統(tǒng)一。如果你手頭是 HuggingFace 格式的模型可以用 llama.cpp 倉(cāng)庫(kù)里的轉(zhuǎn)換腳本導(dǎo)出 GGUFpython convert_hf_to_gguf.py 你的模型目錄 \ --outfile 模型名-f16.gguf \ --outtype f16轉(zhuǎn)換時(shí)注意不要跳過(guò)參數(shù)核查特別是 hidden_size、head 數(shù)這些腳本本身能大部分自動(dòng)識(shí)別但你至少要確認(rèn)輸出日志里的維度和你模型架構(gòu)對(duì)得上不然量化出來(lái)的文件跑起來(lái)會(huì)全是亂碼。第二步量化。llama.cpp 自帶的 quantize 工具會(huì)把 F16 的 GGUF 壓成 Q4_K_M 或其它比特檔位./llama-quantize 模型名-f16.gguf 模型名-q4_k_m.gguf q4_k_m這里 q4_k_m 后面還能跟 group size 參數(shù)比如 q4_k_m 的變體但先用默認(rèn)即可。第三步驗(yàn)證。量化完先別急著上服務(wù)跑一次文本生成觀察輸出質(zhì)量./llama-cli -m 模型名-q4_k_m.gguf \ -c 4096 \ -ngl 999 \ -p 寫(xiě)一段關(guān)于單卡推理的代碼建議如果輸出通順、沒(méi)有大量重復(fù)字符或亂碼說(shuō)明鏈路是通的如果輸出明顯劣化先回查校準(zhǔn)集或 group size而不是懷疑顯卡。我見(jiàn)過(guò)很多新手一看到輸出差就認(rèn)為是量化方法的問(wèn)題其實(shí)是命令行里少了關(guān)鍵的重復(fù)懲罰參數(shù)。3.2 llama.cpp 運(yùn)行參數(shù)ngl、ctx、batch、mlock 的作用跑通之后真正決定體驗(yàn)的是幾個(gè)運(yùn)行參數(shù)。-ngl控制有多少層放到 GPU。設(shè)為 999 表示“盡量全放 GPU”它會(huì)自動(dòng)把能放下的層都放進(jìn)去如果顯存不夠剩余層會(huì)回退到 CPU。24GB 顯卡跑 40GB 的 Q4 權(quán)重時(shí)-ngl的值決定了你會(huì)看到多少 offload 警告。-c是上下文長(zhǎng)度也就是 KV cache 的基礎(chǔ)大小。默認(rèn)可能比較小但當(dāng)你把 70B 模型真正用于長(zhǎng)對(duì)話時(shí)這里必須按第 4 節(jié)的計(jì)算公式來(lái)設(shè)。-b是 batch size也就是單次前向傳播處理多少個(gè) token。這個(gè)參數(shù)調(diào)大可以提升吞吐但會(huì)顯著增加激活值顯存。單卡上我一般從 256 開(kāi)始試OOM 就往 128 降。--mlock是鎖內(nèi)存防止進(jìn)程的內(nèi)存被換出到 swap。這個(gè)參數(shù)在不 offload 的情況下影響不大但只要開(kāi)了 CPU offload它能讓速度穩(wěn)定很多。命令行參數(shù)在不同版本可能改名比如有些版本用llama-cli有些老版本還用main。如果你查閱的資料和你安裝的版本輸出對(duì)不上先用--help看當(dāng)前版本實(shí)際支持的參數(shù)名不要照抄過(guò)時(shí)教程。3.3 vLLM 跑量化模型離線批處理入口如果你要做的是并發(fā)推理服務(wù)或想在同一張卡上服務(wù)多個(gè)請(qǐng)求llama.cpp 的串行方式就不太夠用了。vLLM 是更好選擇它對(duì)量化模型有原生支持入口代碼很簡(jiǎn)潔from vllm import LLM, SamplingParams llm LLM( model/path/to/awq-or-gptq-weights, quantizationawq, # 可選 awq 或 gptq dtypefloat16, gpu_memory_utilization0.85, max_model_len4096, enforce_eagerTrue, ) params SamplingParams( max_tokens512, temperature0.6, top_p0.9, ) outputs llm.generate( [寫(xiě)一篇關(guān)于單卡推理優(yōu)化的短文], params, ) print(outputs[0].outputs[0].text)這里gpu_memory_utilization0.85的含義是為模型和 KV cache 預(yù)留最多 85% 顯存剩下的留給 CUDA context 和激活值。max_model_len是一把雙刃劍設(shè)得越大能處理的長(zhǎng)文本越多但 KV cache 預(yù)留就越大。很多人在 vLLM 上遇到 OOM首先不是量化問(wèn)題而是max_model_len默認(rèn)或誤設(shè)得太大。第一次跑 vLLM 時(shí)建議用enforce_eagerTrue它會(huì)禁用 CUDA graph 優(yōu)化雖然吞吐略低但好處是顯存占用更可預(yù)測(cè)、更容易定位問(wèn)題。等確認(rèn)穩(wěn)定后再關(guān)掉它把速度榨出來(lái)。4. 顯存管理的隱形大頭KV cache、上下文窗口與批處理4.1 一條 KV cache 公式讓你不再靠直覺(jué)設(shè)置參數(shù)我見(jiàn)過(guò)太多人把“上下文長(zhǎng)度”當(dāng)成靈感參數(shù)隨便填一個(gè)然后看著 OOM 一臉無(wú)辜。KV cache 的計(jì)算有明確公式先記住這個(gè)KV cache 大小 2 × 層數(shù) × KV頭數(shù) × 頭維度 × 上下文長(zhǎng)度 × 批量大小 × 每值字節(jié)數(shù)乘以 2 是因?yàn)?Key 和 Value 各一份。以一個(gè) 70B 級(jí)別的模型為例通常有 80 層、8 個(gè) KV 頭、每個(gè)頭 128 維如果上下文長(zhǎng)度 4096、批量 1、FP16 存儲(chǔ)那么2 × 80 × 8 × 128 × 4096 × 1 × 2 字節(jié) ≈ 1.34GB單個(gè)請(qǐng)求就吃掉 1.34GB看起來(lái)還好。但把這四個(gè)變量放大就不一樣了上下文長(zhǎng)度翻到 8192KV cache 變 2.68GB批量從 1 變成 8又是 8 倍增長(zhǎng)。在 48GB 卡上Q4 權(quán)重約 40GB剩下 8GB如果 KV cache 已經(jīng)吃了 5GB激活值再占 2GB剩下的空間就非常緊張。這就是為什么“70B 量化后能裝下但一開(kāi)長(zhǎng)上下文就崩”。4.2 上下文與批處理性能提升的另一面是內(nèi)存翻倍很多人調(diào)參數(shù)時(shí)總想讓吞吐更高于是把批處理大小調(diào)大但忽略了批量對(duì)內(nèi)存的影響。在 Transformers 這類非連續(xù)批處理實(shí)現(xiàn)里批量從 1 升到 4KV cache 直接乘以 4如果你做的是動(dòng)態(tài)批處理峰值內(nèi)存會(huì)陡然上升然后掉下來(lái)再上升很容易在某個(gè)瞬間觸頂。vLLM 引入的 Continuous Batching連續(xù)批處理比傳統(tǒng)方案聰明得多每個(gè)序列只要沒(méi)結(jié)束就繼續(xù)占用 KV cache結(jié)束時(shí)立刻釋放不需要等整批結(jié)束。這讓吞吐明顯提升但總 KV cache 依然是所有并發(fā)請(qǐng)求之和。單卡部署 70B 時(shí)我一般會(huì)把并發(fā)上限壓到很低很多時(shí)候“跑得穩(wěn)”比“跑得多”更值得優(yōu)先考慮畢竟單個(gè)用戶一次對(duì)話就可能在長(zhǎng)上下文下占用數(shù) GB 緩存。4.3 PagedAttention、offload 與顯存碎片vLLM 的高吞吐還得益于 PagedAttention。它的思路和操作系統(tǒng)虛擬內(nèi)存很像把 KV cache 劃分成固定大小的塊按需分配而不是給每個(gè)請(qǐng)求預(yù)留一整塊連續(xù)空間。這讓顯存利用率高了不少也減少了碎片問(wèn)題。對(duì)于單卡 70B 場(chǎng)景這一點(diǎn)特別有用因?yàn)楸緛?lái)可用顯存就緊巴巴的碎片再多一點(diǎn)就徹底跑不動(dòng)了。如果 24GB 卡連 INT4 權(quán)重都放不滿就必須面對(duì) offload 策略。offload 是把部分層放到 CPU 內(nèi)存GPU 只放核心層。llama.cpp 的-ngl設(shè)成某個(gè)層數(shù)就是在做這件事。CPU 和 GPU 之間反復(fù)搬數(shù)據(jù)的代價(jià)是速度大幅下降一個(gè) 70B 模型可能出現(xiàn)幾分鐘才生成一個(gè) token 的情況。所以如果你的目標(biāo)是要可用盡量選 48GB 以上顯存或者選更小尺寸的模型硬要在 24GB 上跑 70B更多是“證明能跑”而不是“實(shí)際能用”。有人會(huì)問(wèn)張量并行能不能解決單卡放不下的問(wèn)題可以但標(biāo)題限制是“單卡”張量并行需要多卡通信不在討論范圍。真正單卡場(chǎng)景能做的是把權(quán)重量化、把 KV cache 精打細(xì)算、把不需要的層 offload這三板斧用完還是不行就該考慮換硬件或換模型而不是繼續(xù)迷信“優(yōu)化到極致就能塞下”。5. 單卡推理的實(shí)戰(zhàn)排坑從 OOM 到質(zhì)量劣化的一次性檢查5.1 開(kāi)跑前的自查清單每次在單卡上部署大模型前我都會(huì)花兩分鐘過(guò)一遍清單這比反復(fù)試錯(cuò)高效得多權(quán)重顯存是否在預(yù)算內(nèi)INT4 的 70B 通常 38GB 到 42GB不要只看理論值要按實(shí)際文件大小算。KV cache 是否按公式算過(guò)根據(jù)目標(biāo)上下文長(zhǎng)度、批量大小和存儲(chǔ)精度算出精確占用。CUDA context 和激活值是否有預(yù)留至少留 2GBvLLM 場(chǎng)景要留 10% 到 15%。校準(zhǔn)集是否貼近真實(shí)任務(wù)如果不是量化模型的輸出質(zhì)量可能無(wú)法接受?？蚣馨姹臼欠衿ヅ鋖lama.cpp、vLLM 的更新速度極快量化格式和參數(shù)都有變動(dòng)老版本可能讀不出新格式。5.2 高頻故障速查表癥狀最常見(jiàn)原因解決方向啟動(dòng)即 OOM權(quán)重 KV cache 超過(guò)顯存減小上下文長(zhǎng)度或批量開(kāi) KV cache 量化運(yùn)行一段后 OOMKV cache 隨序列增長(zhǎng)到峰值降低 max_model_len減少并發(fā)請(qǐng)求數(shù)生成速度極慢大量層被 offload 到 CPU提高 -ngl / 減少 offload或換更大顯存卡輸出明顯變差量化過(guò)度或校準(zhǔn)集不匹配換 group size32換 AWQ或重做校準(zhǔn)長(zhǎng)文本后輸出亂碼位置編碼緩存或 KV cache 溢出檢查上下文長(zhǎng)度設(shè)置檢查重復(fù)懲罰參數(shù)多請(qǐng)求時(shí)吞吐驟降批處理過(guò)大、碎片過(guò)多開(kāi) PagedAttentionvLLM限制最大并發(fā)這里說(shuō)一個(gè)我踩過(guò)很多次的坑有時(shí)不是模型不行而是把真實(shí)任務(wù)里的文本喂進(jìn)去后上下文長(zhǎng)度觸到了顯存天花板于是系統(tǒng)把舊 token 截?cái)嗟⒁饬C(jī)制并不清楚該截?cái)嗄男┪恢媒Y(jié)果就是輸出質(zhì)量和邏輯突然崩壞。排查時(shí)先用一個(gè)短 prompt 驗(yàn)證模型本身再慢慢加長(zhǎng)輸入就能區(qū)分是量化質(zhì)量問(wèn)題還是上下文截?cái)鄦?wèn)題。5.3 穩(wěn)定運(yùn)行的實(shí)測(cè)配置參考最后給兩組我實(shí)際用過(guò)的配置作為大家調(diào)試的起點(diǎn)。48GB 單卡例如 A6000 / L40S跑 70B Q4_K_M 權(quán)重llama.cpp 里我會(huì)用-ngl 999 -c 8192 -b 512 --mlock這個(gè)配置能保證權(quán)重全量進(jìn) GPU8K 上下文對(duì)大多數(shù)問(wèn)答和文檔摘要都?jí)蛴萌绻罄m(xù)要上 vLLM我會(huì)把gpu_memory_utilization設(shè)為 0.9max_model_len設(shè)為 8192并設(shè)置單請(qǐng)求并發(fā)數(shù)不超過(guò) 4。24GB 單卡例如 4090只適合“體驗(yàn)型”部署llama.cpp 中用-ngl 80 -c 4096 -b 256 --mlock這里的-ngl 80不是固定值而是根據(jù) 38GB 權(quán)重和 24GB 顯存算出來(lái)的一個(gè)“能塞多少塞多少”的量實(shí)際層數(shù)以日志為準(zhǔn)。注意這種配置下生成速度會(huì)明顯低于 GPU 全量加載所以它更適合驗(yàn)證推理流程不適合對(duì)外提供穩(wěn)定服務(wù)。我自己折騰單卡 70B 的過(guò)程里最大的感受是優(yōu)化順序比優(yōu)化技巧更重要。先把顯存預(yù)算按公式算清楚再?zèng)Q定量化精度、上下文長(zhǎng)度和批量大小最后才去調(diào)框架參數(shù)反過(guò)來(lái)先堆量化再亂調(diào)上下文問(wèn)題會(huì)像海浪一樣一波接一波?，F(xiàn)在每次跑大模型我第一件事永遠(yuǎn)是打開(kāi)一個(gè)計(jì)算表格把參數(shù)填進(jìn)去而不是先敲運(yùn)行命令這會(huì)省掉一大半排錯(cuò)時(shí)間。