化全攻略)
先說結(jié)論70B 模型放進(jìn)單張 A100 80G 跑起來早就是常規(guī)操作連 RTX 4090 這種 24G 消費卡通過 4bit 量化加 CPU offload也能跑出能用的速度。很多人一聽“70B”就默認(rèn)得上多卡集群其實沒必要。這件事的關(guān)鍵就一句話把權(quán)重從 16bit 壓到 4bit再用推理框架把顯存和調(diào)度玩明白。這篇文章想聊的就是把“讓 70B 模型跑在單卡上”這件事拆成一套可以照著做的五層技術(shù)棧。從硬件選型、量化格式、推理引擎、顯存策略到批處理調(diào)度每一層解決什么問題、怎么選、怎么調(diào)我都會給到可直接落地的方案。適合誰看想低成本做私有化部署的工程師、在邊緣節(jié)點跑大模型的研究人員、以及手里只有一兩張卡但想跑滿血開源模型的個人開發(fā)者。1. 內(nèi)容整體設(shè)計與思路拆解1.1 為什么非要在單卡上跑 70B算力、成本與場景需求70B 模型指的是參數(shù)量達(dá)到 700 億的 Transformer 模型比如 Llama 2 70B、Llama 3 70B、Qwen 2.5 72B 這一檔。這類模型在 BF16 精度下光權(quán)重就要占約 140GB 顯存。想直接加載至少需要 2 張 80GB 的 A100/H100或者 4 張 40GB 的 A100通信還得靠 NVLink不然數(shù)據(jù)搬運能把性能拖沒。但真實部署場景里不是所有人都有多卡集群。我見過不少團(tuán)隊預(yù)算就夠買一兩張卡或者干脆是租的云 GPU 實例按小時計費的那種。他們想要的不是跑滿大規(guī)模訓(xùn)練而是把模型服務(wù)跑起來給內(nèi)部工具、客服系統(tǒng)、邊緣節(jié)點用。這種場景下單卡方案的價值就體現(xiàn)出來了成本低、部署簡單、不需要考慮多卡通信也更容易做到數(shù)據(jù)不出域的私有化部署。還有一個更現(xiàn)實的場景開發(fā)調(diào)試。你在多卡集群上改代碼哪怕一個小改動都得等幾十分鐘排隊。但把量化后的 70B 模型塞進(jìn)本地一張卡隨時改隨時跑效率完全不是一個量級。所以單卡跑 70B 不是“能不能”的問題而是“怎么選型”的問題。核心思路是用量化換顯存用推理優(yōu)化換速度最終在成本和效果之間取一個平衡點。1.2 五層技術(shù)棧怎么拆一套可替換的工具鏈五層技術(shù)棧是我在實踐中總結(jié)出來的一個分層思路每一層負(fù)責(zé)一個獨立的問題而且層與層之間可以隨意替換。層級定位典型工具與技術(shù)解決的核心問題L1 硬件適配層底層物理資源A100/H100/RTX 4090、顯存帶寬、NVLink、PCIe顯存裝不裝得下算力夠不夠快L2 壓縮量化層模型瘦身GPTQ、AWQ、GGUF、FP8、INT8/INT4把 140GB 權(quán)重降到 35-70GBL3 推理引擎層計算分發(fā)vLLM、TensorRT-LLM、SGLang、llama.cpp算子優(yōu)化、圖優(yōu)化、模型格式兼容L4 顯存策略層運行時內(nèi)存管理PagedAttention、KV cache 量化、CPU offload、CUDA Graph顯存碎片、峰值占用、KV cache 爆炸L5 調(diào)度與批處理層系統(tǒng)吞吐優(yōu)化Continuous Batching、前綴緩存、投機(jī)解碼單卡吞吐上不去、響應(yīng)延遲高分層的好處是你完全可以只替換其中一層其他層不動。比如你用 GPTQ 量化模型跑著不舒服想換成 AWQ只需要重新下模型文件vLLM 不需要改代碼你嫌 vLLM 太重型想換 llama.cpp量化格式改成 GGUF 就行硬件不用換。這跟搭積木一個道理。每一層都有明確的接口和邊界出了問題也能快速定位是哪一層的鍋而不是整個系統(tǒng)推倒重來。1.3 先量化還是先換卡兩個方向的價值取舍很多人第一反應(yīng)是“顯存不夠就加卡”但加卡的成本是量化的幾十倍。我們算一筆賬一張 80GB 的 A100 二手市場也得兩三萬云上租用一小時幾十塊長期跑下來每年幾萬而量化的成本是零所有主流量化工具都是開源的。量化能帶來的收益非常直接。70B 模型從 BF16 壓到 INT8權(quán)重從 140GB 降到 70GB一張 80G 卡能放下壓到 INT4只需要 35-40GB一張 24G 消費卡在配合 offload 后也能跑。代價也不是沒有。量化是一個有損壓縮過程模型表達(dá)能力會下降一點在數(shù)學(xué)推理、代碼生成這些對精確性要求高的任務(wù)上損失會更明顯一些。但大部分對話、摘要、分類場景4bit 量化的損失完全可以接受感知上甚至察覺不出來。我的建議是如果條件允許兩張卡那就先用 BF16 跑通如果只有一張卡優(yōu)先考慮量化這是性價比最高的方案。別一上來就買卡先把量化和推理優(yōu)化吃透很多問題根本不需要多卡解決。2. 核心細(xì)節(jié)解析與實操要點量化層的原理與選型2.1 量化在壓什么從 FP16 到 INT4 的數(shù)值變換量化的本質(zhì)是把一個高精度數(shù)值映射到低精度整數(shù)關(guān)鍵公式是這樣的量化q clamp(round(r / scale) zero_point) 反量化r ≈ (q - zero_point) * scale其中scale是縮放因子zero_point是零點偏移clamp是把結(jié)果限制在目標(biāo)整數(shù)范圍內(nèi)。如果量化到 INT8范圍是 -128 到 127量化到 INT4范圍只有 -8 到 7。這里最核心的取舍是 group size也就是多少個數(shù)值共享一組 scale 和 zero_point。group size 越小量化粒度越細(xì)精度損失越小但存儲縮放因子的開銷也越大。主流模型一般用 128也就是每 128 個權(quán)重共享一組量化參數(shù)。這個值可以在量化腳本里直接配。用生活類比來說量化就像是把一張高清照片壓縮成 16 色位圖顏色數(shù)量變少了但整體輪廓還是看得清如果你把 16 色再壓成 4 色細(xì)節(jié)丟失就更明顯。量化誤差就來源于檔位不夠?qū)е潞芏嘣静煌臄?shù)值被映射到了同一個整數(shù)值上。另外要區(qū)分兩個概念權(quán)重weight量化是只壓縮模型的靜態(tài)參數(shù)推理過程中不變化的那些數(shù)值激活activation量化是壓縮計算過程中的動態(tài)中間結(jié)果。70B 這種大模型跑單卡核心是權(quán)重量化它能直接砍掉顯存的 60% 到 75%激活量化更難做搞不好精度崩得快。2.2 GPTQ、AWQ、GGUF、FP8 怎么選主流格式 PK量化格式的選型直接決定了你能用哪個推理框架所以必須先理清楚。格式位寬產(chǎn)物類型主要生態(tài)特點GPTQINT4/INT8單文件或分片權(quán)重vLLM、TensorRT-LLM、ExLlama通用性強(qiáng)基于二階梯度信息補償誤差A(yù)WQINT4權(quán)重文件vLLM、SGLang、TGI激活感知保護(hù)敏感通道小模型上更穩(wěn)GGUF多檔位如 Q4_K_M、Q5_K_M單文件llama.cpp、Ollama支持 CPUGPU 混合加載適合消費級顯卡FP88bit 浮點權(quán)重文件TensorRT-LLM、vLLM 新版本H100/Ada 架構(gòu)原生支持轉(zhuǎn)換無需校準(zhǔn)集GPTQ 是我用得最多的格式。它的思路是用校準(zhǔn)集計算每層權(quán)重的二階梯度信息Hessian 矩陣找到一組新權(quán)重使得量化前后輸出的誤差最小。這個方案在 70B 這個體量上表現(xiàn)很穩(wěn)vLLM 對它的支持也最好。AWQ 在 GPTQ 基礎(chǔ)上做了改進(jìn)核心思路是基于激活值看出哪些權(quán)重通道更敏感然后對敏感通道施加更小的量化策略。在 7B-13B 這類小模型上AWQ 通常比 GPTQ 的精度表現(xiàn)更好但在 70B 上兩者差異不大看個人習(xí)慣選。GGUF 是 llama.cpp 生態(tài)的格式我通常把它定位成“消費級顯卡專用”。它最大的好處是支持把一部分層留在 GPU 計算一部分層放到 CPU 上顯存不夠就用內(nèi)存湊。Q4_K_M 這種檔位的量化效果和 GPTQ 的 4bit 在一個水平線上。FP8 是新一代硬件上的選項H100、RTX 4090 這些顯卡本身就支持 FP8 運算不需要校準(zhǔn)集直接轉(zhuǎn)精度就行。它保留了浮點數(shù)的動態(tài)范圍在部分任務(wù)上精度比 INT8 更接近原版。但要注意FP8 只是把顯存砍了一半對 70B 來說壓完還是 70GB單卡只能上 80G 的卡。我的建議很直接如果你用 vLLM優(yōu)先 GPTQ 或 AWQ如果你只有消費級顯卡直接 GGUF如果你的卡是 Hopper 架構(gòu)且顯存足夠大試試 FP8。2.3 量化質(zhì)量怎么看不要只看一張輸出截圖量化完事千萬別急著開心先驗證精度損失。這是我的血淚教訓(xùn)——曾經(jīng)有一個 13B 模型量化完對話看起來挺正常一跑數(shù)學(xué)題直接崩答案全是胡編。評估量化質(zhì)量建議按這個優(yōu)先級來困惑度Perplexity在標(biāo)準(zhǔn)測試集上對比量化前后的困惑度變化。變化在 1-2 以內(nèi)屬于優(yōu)秀超過 5 就要警惕?；鶞?zhǔn)測試用 HumanEval代碼、GSM8K數(shù)學(xué)、MMLU綜合這些數(shù)據(jù)集跑一遍量化后分?jǐn)?shù)掉多少肉眼可見。人工抽樣針對你的實際業(yè)務(wù)場景挑 50 條 prompt逐條對比量化前后的輸出質(zhì)量。校準(zhǔn)集在這里很關(guān)鍵。GPTQ 和 AWQ 都需要一個校準(zhǔn)集來估計權(quán)重分布校準(zhǔn)集最好跟你實際要跑的數(shù)據(jù)分布相近。比如你拿來做代碼模型的量化校準(zhǔn)集里就別全是新聞?wù)Z料。還有一個容易踩的坑有些人拿量化模型去跑測試集而這套測試集的題目恰好被跑進(jìn)了校準(zhǔn)集里結(jié)果測出來分?jǐn)?shù)奇高自欺欺人。正確做法是校準(zhǔn)集和測試集嚴(yán)格分開別讓模型“作弊”。3. 實操過程與核心環(huán)節(jié)實現(xiàn)從模型到單卡推理服務(wù)3.1 顯存預(yù)算先算明白一張表把賬做清楚動手跑模型之前先花兩分鐘算一下顯存賬這事后能省你好幾個小時排錯。公式一權(quán)重顯存權(quán)重顯存(GB) 參數(shù)量 × 每個參數(shù)字節(jié)數(shù) / 1024370B 模型在 BF16 下每個參數(shù)占 2 字節(jié)算出來約 140GBINT8 下每個參數(shù) 1 字節(jié)約 70GBINT4 下每個參數(shù) 0.5 字節(jié)約 35GB再加上量化參數(shù)和格式頭開銷實際在 36-40GB 之間。公式二KV cache 顯存每 token 的 KV cache 字節(jié)數(shù) 2 × 層數(shù) × KV heads 數(shù) × head 維度 × 每個元素字節(jié)數(shù)拿 Llama 2 70B 舉例80 層、8 個 KV heads、head 維度 128、BF16 存儲每個 token 約 0.32MB。如果上下文長度 8192KV cache 約 2.68GB如果上下文長度 32768直接到 10GB 以上。所以總顯存預(yù)算就是權(quán)重 KV cache 激活值 CUDA context 余量。最終建議按下表做預(yù)判模型精度權(quán)重占用A100 80G 可行性RTX 4090 24G 可行性BF16約 140GB不可行不可行INT8/FP8約 70GB可跑KV cache 空間有限不可行INT4GPTQ/AWQ約 38GB很舒適需要配合 offloadGGUF Q4_K_M約 35GB很舒適需要配合 offload一個容易被忽略的點CUDA context會固定占掉幾百 MB 到 1GB 的顯存這不是你代碼里能控制的是從 PyTorch/CUDA 初始化開始就存在的固定開銷。還有顯存碎片問題在大模型推理里尤其明顯后面細(xì)說。3.2 路線一vLLM GPTQ/AWQ單卡上最省心的組合vLLM 是目前用下來最順手的方案它對量化模型的支持非常成熟而且集成了 PagedAttention 和 Continuous Batching省去很多自己造輪子的精力。第一步安裝依賴并準(zhǔn)備量化模型pip install vllm模型方面可以從 Hugging Face 上下載已經(jīng)量化好的 GPTQ/AWQ 格式模型。如果沒有現(xiàn)成的也可以用 AutoGPTQ 或 AutoAWQ 自己量化但建議新手先跑現(xiàn)成的驗證鏈路通了再自己動刀。第二步寫個最簡單的推理腳本from vllm import LLM, SamplingParams llm LLM( modelyour-model-path, quantizationgptq, gpu_memory_utilization0.9, max_model_len8192 ) params SamplingParams(temperature0.7, max_tokens512) outputs llm.generate(什么是模型量化, params) print(outputs[0].outputs[0].text)跑起來之后vLLM 的日志會顯示權(quán)重占了多少顯存、KV cache 留了多少。這一步就是驗證預(yù)算的時刻如果日志顯示 KV cache 只有幾百 MB那說明權(quán)重加格式開銷已經(jīng)把顯存壓得差不多了需要調(diào)小max_model_len或者換更高壓縮比的量化格式。如果要對外提供 API 服務(wù)直接用自帶的 OpenAI 兼容接口python -m vllm.entrypoints.openai.api_server \ --model your-model-path \ --quantization gptq \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192注意--tensor-parallel-size 1這個參數(shù)它代表只用單卡。默認(rèn)情況下 vLLM 會自動檢測可用的 GPU如果你機(jī)器上有多張卡而不設(shè)置這個參數(shù)它會把模型打散到多卡上跑這一下子又回到了多卡通信的復(fù)雜度里。3.3 路線二llama.cpp GGUF把消費級顯卡的潛力榨干如果你只有 RTX 4090 或者 RTX 3090 這種 24G 卡還想跑 70B不要想 GPTQ 了直接上 GGUF llama.cpp 是更現(xiàn)實的路。第一步去 Hugging Face 下載 GGUF 格式文件選 Q4_K_M 這一檔。下載完啟動服務(wù)llama-server -m llama-2-70b.Q4_K_M.gguf \ --ctx-size 8192 \ --n-gpu-layers 40這里--n-gpu-layers控制了把多少層放到 GPU 上算剩下的層交給 CPU。24G 顯存一般能塞下 40 層左右70B 總層數(shù)約 80 層剩下的 40 層跑 CPU。這個配置在 RTX 4090 上實測生成速度大約在 8-12 token/s 之間屬于“能用但不快”的水平。如果全部層都走 GPU前提是你有一張 48G 以上的卡速度能到 25-35 token/s。為什么 GGUF 能在 24G 卡上跑而 GPTQ 不行因為 GGUF 的設(shè)計目標(biāo)就是“能跑就行”它對 offload 的支持是天然的CPU 和 GPU 之間的張量搬運被封裝成底層算子不需要自己處理。這是 GGUF 最大的價值。有一個細(xì)節(jié)要注意--n-gpu-layers并不是越大越好要留出一些顯存給 KV cache 和計算圖。如果你發(fā)現(xiàn)啟動后立刻 OOM就減小這個數(shù)值直到顯存夠用為止。這是個試錯過程量化模型的層大小不完全一致不同模型能塞下的層數(shù)也不一樣。3.4 調(diào)參方法論四個參數(shù)決定單卡性能vLLM 有四個參數(shù)基本決定了單卡推理的性能上限整理如下參數(shù)作用經(jīng)驗建議gpu_memory_utilization允許 vLLM 使用的顯存比例0.85-0.9 之間太低會浪費顯存太高容易崩潰max_model_len最大上下文長度按業(yè)務(wù)場景設(shè)別一味拉大KV cache 按 token 數(shù)線性增長max_num_seqs并行處理的序列數(shù)從 8 開始調(diào)吞吐優(yōu)先就往上加延遲敏感就往下減enable_prefix_caching是否緩存共享前綴的 KV多輪對話、長文檔問答場景強(qiáng)烈建議開啟gpu_memory_utilization我一般設(shè) 0.9留 10% 給 CUDA context 和碎片緩沖。設(shè)得太高比如 0.97短期看起來顯存利用率上去了但一旦觸發(fā)新的顯存申請就容易 OOM。max_model_len是最容易被忽視的坑。很多人習(xí)慣直接設(shè) 32K但 70B 模型在 INT4 下加 32K 上下文KV cache 輕松超過 12GB直接吃掉大頭顯存。如果你的業(yè)務(wù)根本不涉及長文檔老老實實設(shè) 8K 就夠了把剩下的顯存留給并發(fā)。實際調(diào)參建議先固定gpu_memory_utilization0.9和max_model_len通過max_num_seqs控制并發(fā)用壓測工具看吞吐和延遲曲線找到你業(yè)務(wù)的甜點區(qū)。4. 常見問題與排查技巧實錄4.1 啟動報 CUDA out of memory但權(quán)重明明裝得下這個問題排在所有坑的第一名幾乎每個上手跑 70B 的人都遇到過。明明算好了權(quán)重 38GB80G 的卡應(yīng)該輕松裝下結(jié)果一啟動直接 OOM。原因基本是這幾個第一KV cache 忘了算進(jìn)去默認(rèn)配置下它會貪婪地吃掉剩余顯存第二CUDA context 和 PyTorch 的緩存分配器制造了額外開銷尤其是 PyTorch 的緩存機(jī)制會讓顯存看起來瞬間被占滿第三顯存碎片當(dāng)并發(fā)序列多了之后不連續(xù)的空閑顯存無法被利用。解法優(yōu)先級調(diào)低max_model_len從 8K 開始別再往大設(shè)。調(diào)低max_num_seqs比如從 8 降到 4。調(diào)整gpu_memory_utilization到 0.85給系統(tǒng)留足緩沖。如果顯存確實不夠只有走 GGUF offload 方案。另外一個建議先跑一個最小的 hello world只生成 10 個 token確認(rèn)服務(wù)能起來之后再逐步加配置。很多人一上來就開 32K 上下文加高并發(fā)那當(dāng)然必炸。4.2 量化后生成質(zhì)量變差尤其是數(shù)學(xué)題和代碼量化不是無損的所以質(zhì)量變差是正常的但如果差得離譜就要排查原因了。最常見的原因是校準(zhǔn)集不匹配。GPTQ 和 AWQ 在做量化時都需要一個校準(zhǔn)集來摸清權(quán)重分布如果校準(zhǔn)集跟你實際應(yīng)用的數(shù)據(jù)分布相差太遠(yuǎn)量化參數(shù)就會嚴(yán)重失真。比如你用新聞?wù)Z料校準(zhǔn)的模型跑代碼生成任務(wù)那就是硬撐著。另一個原因是 group size 沒選好。group size 128 是平衡選擇如果你為了減少量化參數(shù)選了 256 或更大精度損失會明顯增加。在顯存允許的前提下盡量選小的 group size。還有一個容易忽略的原模型本身質(zhì)量就不行。有些開源模型的基座能力有限量化后損失會被放大。這種情況建議換個更好的基座模型或者用更高比特的量化檔位比如從 Q4 升到 Q5、從 INT4 換成 INT8。評價量化質(zhì)量一定要用可量化的指標(biāo)不要拿一兩個生成樣例說事。跑一下 perplexity 或者 GSM8K對比量化前后的分?jǐn)?shù)再決定要不要重新做量化。4.3 單卡推理吞吐上不去顯存看著還夠但速度就是慢如果你發(fā)現(xiàn)生成速度特別慢第一反應(yīng)不是換卡而是排查框架配置。第一個嫌疑是沒開啟 Continuous Batching。這是 vLLM 的核心特性默認(rèn)開啟但某些古老版本或特定調(diào)用方式下可能沒生效。它做的事情是當(dāng)一個請求生成完了不需要等批量里的其他請求全部完成而是立刻插入新請求把 GPU 的算力槽位填滿。第二個嫌疑是前綴緩存沒有開。多輪對話場景下每個新請求都帶了完整的歷史消息如果每次重新計算前幾輪對話的 KV cache浪費極其嚴(yán)重。開啟enable_prefix_caching之后共享前綴的 KV 可以直接復(fù)用在長對話場景里吞吐能提升好幾倍。第三個嫌疑是模型在做 CPU offload。GGUF 方案如果 GPU 顯存不夠大部分層被放到了 CPU 上GPU 每算一層都要通過 PCIe 從內(nèi)存搬數(shù)據(jù)速度自然上不去。想驗證很簡單看 nvidia-smi 的 GPU 利用率如果利用率一直很低但內(nèi)存被大量占用基本就是在等搬運數(shù)據(jù)。這種情況下要么減少--n-gpu-layers騰出算力要么直接換更大顯存的卡。如果以上都沒問題再考慮投機(jī)解碼。投機(jī)解碼的思路是用一個小模型先草稿式生成幾個 token然后大模型一次性驗證。在部分場景下吞吐能提升 1.5-2 倍但效果和任務(wù)類型強(qiáng)相關(guān)不是所有的任務(wù)都適用需要實測。4.4 問題速查表把上面這些問題匯成一張表方便排查癥狀可能原因優(yōu)先排查方向啟動 OOMKV cache 設(shè)太長 / GPU 利用率設(shè)太高調(diào)低 max_model_len、調(diào)低 max_num_seqs生成質(zhì)量崩壞校準(zhǔn)集不匹配 / group size 太大換校準(zhǔn)集、重新量化、升檔位速度慢且 GPU 利用率低CPU offload 過重調(diào)高 --n-gpu-layers 或換大顯存卡并發(fā)后開始 OOM顯存碎片 / 并發(fā)數(shù)過大調(diào)低 max_num_seqs、換新版本 vLLM多輪對話特別慢前綴緩存未開啟打開 enable_prefix_caching數(shù)學(xué)題答錯量化損失敏感 / 基座弱換高比特檔位、換更強(qiáng)基座最后再分享一個我個人的習(xí)慣任何大模型推理項目我都先在 24G 消費卡上用 7B 模型把整條鏈路、參數(shù)配置、代碼框架全部跑通然后再換 70B 模型。這樣做的好處是排錯成本極低因為 7B 在消費卡上有充足余量問題更容易定位。等你把 7B 上的每一步都調(diào)明白了換 70B 時只需要更新模型路徑和顯存預(yù)算剩下的都是水到渠成的事。這套五層技術(shù)?？雌饋韺訑?shù)多但實際落地時就是你機(jī)器上裝一個推理框架、下載一個量化模型、設(shè)置好四個參數(shù)的事。先把第一步邁出去讓模型先跑起來再慢慢調(diào)優(yōu)。單卡跑 70B 這件事難度沒有想象中那么高關(guān)鍵在于想清楚每一層在解決什么問題然后按順序把它們逐個搞定。 70B大模型單卡部署：量化壓縮與推理優(yōu)化全攻略
先說結(jié)論70B 模型放進(jìn)單張 A100 80G 跑起來早就是常規(guī)操作連 RTX 4090 這種 24G 消費卡通過 4bit 量化加 CPU offload也能跑出能用的速度。很多人一聽“70B”就默認(rèn)得上多卡集群其實沒必要。這件事的關(guān)鍵就一句話把權(quán)重從 16bit 壓到 4bit再用推理框架把顯存和調(diào)度玩明白。這篇文章想聊的就是把“讓 70B 模型跑在單卡上”這件事拆成一套可以照著做的五層技術(shù)棧。從硬件選型、量化格式、推理引擎、顯存策略到批處理調(diào)度每一層解決什么問題、怎么選、怎么調(diào)我都會給到可直接落地的方案。適合誰看想低成本做私有化部署的工程師、在邊緣節(jié)點跑大模型的研究人員、以及手里只有一兩張卡但想跑滿血開源模型的個人開發(fā)者。1. 內(nèi)容整體設(shè)計與思路拆解1.1 為什么非要在單卡上跑 70B算力、成本與場景需求70B 模型指的是參數(shù)量達(dá)到 700 億的 Transformer 模型比如 Llama 2 70B、Llama 3 70B、Qwen 2.5 72B 這一檔。這類模型在 BF16 精度下光權(quán)重就要占約 140GB 顯存。想直接加載至少需要 2 張 80GB 的 A100/H100或者 4 張 40GB 的 A100通信還得靠 NVLink不然數(shù)據(jù)搬運能把性能拖沒。但真實部署場景里不是所有人都有多卡集群。我見過不少團(tuán)隊預(yù)算就夠買一兩張卡或者干脆是租的云 GPU 實例按小時計費的那種。他們想要的不是跑滿大規(guī)模訓(xùn)練而是把模型服務(wù)跑起來給內(nèi)部工具、客服系統(tǒng)、邊緣節(jié)點用。這種場景下單卡方案的價值就體現(xiàn)出來了成本低、部署簡單、不需要考慮多卡通信也更容易做到數(shù)據(jù)不出域的私有化部署。還有一個更現(xiàn)實的場景開發(fā)調(diào)試。你在多卡集群上改代碼哪怕一個小改動都得等幾十分鐘排隊。但把量化后的 70B 模型塞進(jìn)本地一張卡隨時改隨時跑效率完全不是一個量級。所以單卡跑 70B 不是“能不能”的問題而是“怎么選型”的問題。核心思路是用量化換顯存用推理優(yōu)化換速度最終在成本和效果之間取一個平衡點。1.2 五層技術(shù)棧怎么拆一套可替換的工具鏈五層技術(shù)棧是我在實踐中總結(jié)出來的一個分層思路每一層負(fù)責(zé)一個獨立的問題而且層與層之間可以隨意替換。層級定位典型工具與技術(shù)解決的核心問題L1 硬件適配層底層物理資源A100/H100/RTX 4090、顯存帶寬、NVLink、PCIe顯存裝不裝得下算力夠不夠快L2 壓縮量化層模型瘦身GPTQ、AWQ、GGUF、FP8、INT8/INT4把 140GB 權(quán)重降到 35-70GBL3 推理引擎層計算分發(fā)vLLM、TensorRT-LLM、SGLang、llama.cpp算子優(yōu)化、圖優(yōu)化、模型格式兼容L4 顯存策略層運行時內(nèi)存管理PagedAttention、KV cache 量化、CPU offload、CUDA Graph顯存碎片、峰值占用、KV cache 爆炸L5 調(diào)度與批處理層系統(tǒng)吞吐優(yōu)化Continuous Batching、前綴緩存、投機(jī)解碼單卡吞吐上不去、響應(yīng)延遲高分層的好處是你完全可以只替換其中一層其他層不動。比如你用 GPTQ 量化模型跑著不舒服想換成 AWQ只需要重新下模型文件vLLM 不需要改代碼你嫌 vLLM 太重型想換 llama.cpp量化格式改成 GGUF 就行硬件不用換。這跟搭積木一個道理。每一層都有明確的接口和邊界出了問題也能快速定位是哪一層的鍋而不是整個系統(tǒng)推倒重來。1.3 先量化還是先換卡兩個方向的價值取舍很多人第一反應(yīng)是“顯存不夠就加卡”但加卡的成本是量化的幾十倍。我們算一筆賬一張 80GB 的 A100 二手市場也得兩三萬云上租用一小時幾十塊長期跑下來每年幾萬而量化的成本是零所有主流量化工具都是開源的。量化能帶來的收益非常直接。70B 模型從 BF16 壓到 INT8權(quán)重從 140GB 降到 70GB一張 80G 卡能放下壓到 INT4只需要 35-40GB一張 24G 消費卡在配合 offload 后也能跑。代價也不是沒有。量化是一個有損壓縮過程模型表達(dá)能力會下降一點在數(shù)學(xué)推理、代碼生成這些對精確性要求高的任務(wù)上損失會更明顯一些。但大部分對話、摘要、分類場景4bit 量化的損失完全可以接受感知上甚至察覺不出來。我的建議是如果條件允許兩張卡那就先用 BF16 跑通如果只有一張卡優(yōu)先考慮量化這是性價比最高的方案。別一上來就買卡先把量化和推理優(yōu)化吃透很多問題根本不需要多卡解決。2. 核心細(xì)節(jié)解析與實操要點量化層的原理與選型2.1 量化在壓什么從 FP16 到 INT4 的數(shù)值變換量化的本質(zhì)是把一個高精度數(shù)值映射到低精度整數(shù)關(guān)鍵公式是這樣的量化q clamp(round(r / scale) zero_point) 反量化r ≈ (q - zero_point) * scale其中scale是縮放因子zero_point是零點偏移clamp是把結(jié)果限制在目標(biāo)整數(shù)范圍內(nèi)。如果量化到 INT8范圍是 -128 到 127量化到 INT4范圍只有 -8 到 7。這里最核心的取舍是 group size也就是多少個數(shù)值共享一組 scale 和 zero_point。group size 越小量化粒度越細(xì)精度損失越小但存儲縮放因子的開銷也越大。主流模型一般用 128也就是每 128 個權(quán)重共享一組量化參數(shù)。這個值可以在量化腳本里直接配。用生活類比來說量化就像是把一張高清照片壓縮成 16 色位圖顏色數(shù)量變少了但整體輪廓還是看得清如果你把 16 色再壓成 4 色細(xì)節(jié)丟失就更明顯。量化誤差就來源于檔位不夠?qū)е潞芏嘣静煌臄?shù)值被映射到了同一個整數(shù)值上。另外要區(qū)分兩個概念權(quán)重weight量化是只壓縮模型的靜態(tài)參數(shù)推理過程中不變化的那些數(shù)值激活activation量化是壓縮計算過程中的動態(tài)中間結(jié)果。70B 這種大模型跑單卡核心是權(quán)重量化它能直接砍掉顯存的 60% 到 75%激活量化更難做搞不好精度崩得快。2.2 GPTQ、AWQ、GGUF、FP8 怎么選主流格式 PK量化格式的選型直接決定了你能用哪個推理框架所以必須先理清楚。格式位寬產(chǎn)物類型主要生態(tài)特點GPTQINT4/INT8單文件或分片權(quán)重vLLM、TensorRT-LLM、ExLlama通用性強(qiáng)基于二階梯度信息補償誤差A(yù)WQINT4權(quán)重文件vLLM、SGLang、TGI激活感知保護(hù)敏感通道小模型上更穩(wěn)GGUF多檔位如 Q4_K_M、Q5_K_M單文件llama.cpp、Ollama支持 CPUGPU 混合加載適合消費級顯卡FP88bit 浮點權(quán)重文件TensorRT-LLM、vLLM 新版本H100/Ada 架構(gòu)原生支持轉(zhuǎn)換無需校準(zhǔn)集GPTQ 是我用得最多的格式。它的思路是用校準(zhǔn)集計算每層權(quán)重的二階梯度信息Hessian 矩陣找到一組新權(quán)重使得量化前后輸出的誤差最小。這個方案在 70B 這個體量上表現(xiàn)很穩(wěn)vLLM 對它的支持也最好。AWQ 在 GPTQ 基礎(chǔ)上做了改進(jìn)核心思路是基于激活值看出哪些權(quán)重通道更敏感然后對敏感通道施加更小的量化策略。在 7B-13B 這類小模型上AWQ 通常比 GPTQ 的精度表現(xiàn)更好但在 70B 上兩者差異不大看個人習(xí)慣選。GGUF 是 llama.cpp 生態(tài)的格式我通常把它定位成“消費級顯卡專用”。它最大的好處是支持把一部分層留在 GPU 計算一部分層放到 CPU 上顯存不夠就用內(nèi)存湊。Q4_K_M 這種檔位的量化效果和 GPTQ 的 4bit 在一個水平線上。FP8 是新一代硬件上的選項H100、RTX 4090 這些顯卡本身就支持 FP8 運算不需要校準(zhǔn)集直接轉(zhuǎn)精度就行。它保留了浮點數(shù)的動態(tài)范圍在部分任務(wù)上精度比 INT8 更接近原版。但要注意FP8 只是把顯存砍了一半對 70B 來說壓完還是 70GB單卡只能上 80G 的卡。我的建議很直接如果你用 vLLM優(yōu)先 GPTQ 或 AWQ如果你只有消費級顯卡直接 GGUF如果你的卡是 Hopper 架構(gòu)且顯存足夠大試試 FP8。2.3 量化質(zhì)量怎么看不要只看一張輸出截圖量化完事千萬別急著開心先驗證精度損失。這是我的血淚教訓(xùn)——曾經(jīng)有一個 13B 模型量化完對話看起來挺正常一跑數(shù)學(xué)題直接崩答案全是胡編。評估量化質(zhì)量建議按這個優(yōu)先級來困惑度Perplexity在標(biāo)準(zhǔn)測試集上對比量化前后的困惑度變化。變化在 1-2 以內(nèi)屬于優(yōu)秀超過 5 就要警惕?；鶞?zhǔn)測試用 HumanEval代碼、GSM8K數(shù)學(xué)、MMLU綜合這些數(shù)據(jù)集跑一遍量化后分?jǐn)?shù)掉多少肉眼可見。人工抽樣針對你的實際業(yè)務(wù)場景挑 50 條 prompt逐條對比量化前后的輸出質(zhì)量。校準(zhǔn)集在這里很關(guān)鍵。GPTQ 和 AWQ 都需要一個校準(zhǔn)集來估計權(quán)重分布校準(zhǔn)集最好跟你實際要跑的數(shù)據(jù)分布相近。比如你拿來做代碼模型的量化校準(zhǔn)集里就別全是新聞?wù)Z料。還有一個容易踩的坑有些人拿量化模型去跑測試集而這套測試集的題目恰好被跑進(jìn)了校準(zhǔn)集里結(jié)果測出來分?jǐn)?shù)奇高自欺欺人。正確做法是校準(zhǔn)集和測試集嚴(yán)格分開別讓模型“作弊”。3. 實操過程與核心環(huán)節(jié)實現(xiàn)從模型到單卡推理服務(wù)3.1 顯存預(yù)算先算明白一張表把賬做清楚動手跑模型之前先花兩分鐘算一下顯存賬這事后能省你好幾個小時排錯。公式一權(quán)重顯存權(quán)重顯存(GB) 參數(shù)量 × 每個參數(shù)字節(jié)數(shù) / 1024370B 模型在 BF16 下每個參數(shù)占 2 字節(jié)算出來約 140GBINT8 下每個參數(shù) 1 字節(jié)約 70GBINT4 下每個參數(shù) 0.5 字節(jié)約 35GB再加上量化參數(shù)和格式頭開銷實際在 36-40GB 之間。公式二KV cache 顯存每 token 的 KV cache 字節(jié)數(shù) 2 × 層數(shù) × KV heads 數(shù) × head 維度 × 每個元素字節(jié)數(shù)拿 Llama 2 70B 舉例80 層、8 個 KV heads、head 維度 128、BF16 存儲每個 token 約 0.32MB。如果上下文長度 8192KV cache 約 2.68GB如果上下文長度 32768直接到 10GB 以上。所以總顯存預(yù)算就是權(quán)重 KV cache 激活值 CUDA context 余量。最終建議按下表做預(yù)判模型精度權(quán)重占用A100 80G 可行性RTX 4090 24G 可行性BF16約 140GB不可行不可行INT8/FP8約 70GB可跑KV cache 空間有限不可行INT4GPTQ/AWQ約 38GB很舒適需要配合 offloadGGUF Q4_K_M約 35GB很舒適需要配合 offload一個容易被忽略的點CUDA context會固定占掉幾百 MB 到 1GB 的顯存這不是你代碼里能控制的是從 PyTorch/CUDA 初始化開始就存在的固定開銷。還有顯存碎片問題在大模型推理里尤其明顯后面細(xì)說。3.2 路線一vLLM GPTQ/AWQ單卡上最省心的組合vLLM 是目前用下來最順手的方案它對量化模型的支持非常成熟而且集成了 PagedAttention 和 Continuous Batching省去很多自己造輪子的精力。第一步安裝依賴并準(zhǔn)備量化模型pip install vllm模型方面可以從 Hugging Face 上下載已經(jīng)量化好的 GPTQ/AWQ 格式模型。如果沒有現(xiàn)成的也可以用 AutoGPTQ 或 AutoAWQ 自己量化但建議新手先跑現(xiàn)成的驗證鏈路通了再自己動刀。第二步寫個最簡單的推理腳本from vllm import LLM, SamplingParams llm LLM( modelyour-model-path, quantizationgptq, gpu_memory_utilization0.9, max_model_len8192 ) params SamplingParams(temperature0.7, max_tokens512) outputs llm.generate(什么是模型量化, params) print(outputs[0].outputs[0].text)跑起來之后vLLM 的日志會顯示權(quán)重占了多少顯存、KV cache 留了多少。這一步就是驗證預(yù)算的時刻如果日志顯示 KV cache 只有幾百 MB那說明權(quán)重加格式開銷已經(jīng)把顯存壓得差不多了需要調(diào)小max_model_len或者換更高壓縮比的量化格式。如果要對外提供 API 服務(wù)直接用自帶的 OpenAI 兼容接口python -m vllm.entrypoints.openai.api_server \ --model your-model-path \ --quantization gptq \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192注意--tensor-parallel-size 1這個參數(shù)它代表只用單卡。默認(rèn)情況下 vLLM 會自動檢測可用的 GPU如果你機(jī)器上有多張卡而不設(shè)置這個參數(shù)它會把模型打散到多卡上跑這一下子又回到了多卡通信的復(fù)雜度里。3.3 路線二llama.cpp GGUF把消費級顯卡的潛力榨干如果你只有 RTX 4090 或者 RTX 3090 這種 24G 卡還想跑 70B不要想 GPTQ 了直接上 GGUF llama.cpp 是更現(xiàn)實的路。第一步去 Hugging Face 下載 GGUF 格式文件選 Q4_K_M 這一檔。下載完啟動服務(wù)llama-server -m llama-2-70b.Q4_K_M.gguf \ --ctx-size 8192 \ --n-gpu-layers 40這里--n-gpu-layers控制了把多少層放到 GPU 上算剩下的層交給 CPU。24G 顯存一般能塞下 40 層左右70B 總層數(shù)約 80 層剩下的 40 層跑 CPU。這個配置在 RTX 4090 上實測生成速度大約在 8-12 token/s 之間屬于“能用但不快”的水平。如果全部層都走 GPU前提是你有一張 48G 以上的卡速度能到 25-35 token/s。為什么 GGUF 能在 24G 卡上跑而 GPTQ 不行因為 GGUF 的設(shè)計目標(biāo)就是“能跑就行”它對 offload 的支持是天然的CPU 和 GPU 之間的張量搬運被封裝成底層算子不需要自己處理。這是 GGUF 最大的價值。有一個細(xì)節(jié)要注意--n-gpu-layers并不是越大越好要留出一些顯存給 KV cache 和計算圖。如果你發(fā)現(xiàn)啟動后立刻 OOM就減小這個數(shù)值直到顯存夠用為止。這是個試錯過程量化模型的層大小不完全一致不同模型能塞下的層數(shù)也不一樣。3.4 調(diào)參方法論四個參數(shù)決定單卡性能vLLM 有四個參數(shù)基本決定了單卡推理的性能上限整理如下參數(shù)作用經(jīng)驗建議gpu_memory_utilization允許 vLLM 使用的顯存比例0.85-0.9 之間太低會浪費顯存太高容易崩潰max_model_len最大上下文長度按業(yè)務(wù)場景設(shè)別一味拉大KV cache 按 token 數(shù)線性增長max_num_seqs并行處理的序列數(shù)從 8 開始調(diào)吞吐優(yōu)先就往上加延遲敏感就往下減enable_prefix_caching是否緩存共享前綴的 KV多輪對話、長文檔問答場景強(qiáng)烈建議開啟gpu_memory_utilization我一般設(shè) 0.9留 10% 給 CUDA context 和碎片緩沖。設(shè)得太高比如 0.97短期看起來顯存利用率上去了但一旦觸發(fā)新的顯存申請就容易 OOM。max_model_len是最容易被忽視的坑。很多人習(xí)慣直接設(shè) 32K但 70B 模型在 INT4 下加 32K 上下文KV cache 輕松超過 12GB直接吃掉大頭顯存。如果你的業(yè)務(wù)根本不涉及長文檔老老實實設(shè) 8K 就夠了把剩下的顯存留給并發(fā)。實際調(diào)參建議先固定gpu_memory_utilization0.9和max_model_len通過max_num_seqs控制并發(fā)用壓測工具看吞吐和延遲曲線找到你業(yè)務(wù)的甜點區(qū)。4. 常見問題與排查技巧實錄4.1 啟動報 CUDA out of memory但權(quán)重明明裝得下這個問題排在所有坑的第一名幾乎每個上手跑 70B 的人都遇到過。明明算好了權(quán)重 38GB80G 的卡應(yīng)該輕松裝下結(jié)果一啟動直接 OOM。原因基本是這幾個第一KV cache 忘了算進(jìn)去默認(rèn)配置下它會貪婪地吃掉剩余顯存第二CUDA context 和 PyTorch 的緩存分配器制造了額外開銷尤其是 PyTorch 的緩存機(jī)制會讓顯存看起來瞬間被占滿第三顯存碎片當(dāng)并發(fā)序列多了之后不連續(xù)的空閑顯存無法被利用。解法優(yōu)先級調(diào)低max_model_len從 8K 開始別再往大設(shè)。調(diào)低max_num_seqs比如從 8 降到 4。調(diào)整gpu_memory_utilization到 0.85給系統(tǒng)留足緩沖。如果顯存確實不夠只有走 GGUF offload 方案。另外一個建議先跑一個最小的 hello world只生成 10 個 token確認(rèn)服務(wù)能起來之后再逐步加配置。很多人一上來就開 32K 上下文加高并發(fā)那當(dāng)然必炸。4.2 量化后生成質(zhì)量變差尤其是數(shù)學(xué)題和代碼量化不是無損的所以質(zhì)量變差是正常的但如果差得離譜就要排查原因了。最常見的原因是校準(zhǔn)集不匹配。GPTQ 和 AWQ 在做量化時都需要一個校準(zhǔn)集來摸清權(quán)重分布如果校準(zhǔn)集跟你實際應(yīng)用的數(shù)據(jù)分布相差太遠(yuǎn)量化參數(shù)就會嚴(yán)重失真。比如你用新聞?wù)Z料校準(zhǔn)的模型跑代碼生成任務(wù)那就是硬撐著。另一個原因是 group size 沒選好。group size 128 是平衡選擇如果你為了減少量化參數(shù)選了 256 或更大精度損失會明顯增加。在顯存允許的前提下盡量選小的 group size。還有一個容易忽略的原模型本身質(zhì)量就不行。有些開源模型的基座能力有限量化后損失會被放大。這種情況建議換個更好的基座模型或者用更高比特的量化檔位比如從 Q4 升到 Q5、從 INT4 換成 INT8。評價量化質(zhì)量一定要用可量化的指標(biāo)不要拿一兩個生成樣例說事。跑一下 perplexity 或者 GSM8K對比量化前后的分?jǐn)?shù)再決定要不要重新做量化。4.3 單卡推理吞吐上不去顯存看著還夠但速度就是慢如果你發(fā)現(xiàn)生成速度特別慢第一反應(yīng)不是換卡而是排查框架配置。第一個嫌疑是沒開啟 Continuous Batching。這是 vLLM 的核心特性默認(rèn)開啟但某些古老版本或特定調(diào)用方式下可能沒生效。它做的事情是當(dāng)一個請求生成完了不需要等批量里的其他請求全部完成而是立刻插入新請求把 GPU 的算力槽位填滿。第二個嫌疑是前綴緩存沒有開。多輪對話場景下每個新請求都帶了完整的歷史消息如果每次重新計算前幾輪對話的 KV cache浪費極其嚴(yán)重。開啟enable_prefix_caching之后共享前綴的 KV 可以直接復(fù)用在長對話場景里吞吐能提升好幾倍。第三個嫌疑是模型在做 CPU offload。GGUF 方案如果 GPU 顯存不夠大部分層被放到了 CPU 上GPU 每算一層都要通過 PCIe 從內(nèi)存搬數(shù)據(jù)速度自然上不去。想驗證很簡單看 nvidia-smi 的 GPU 利用率如果利用率一直很低但內(nèi)存被大量占用基本就是在等搬運數(shù)據(jù)。這種情況下要么減少--n-gpu-layers騰出算力要么直接換更大顯存的卡。如果以上都沒問題再考慮投機(jī)解碼。投機(jī)解碼的思路是用一個小模型先草稿式生成幾個 token然后大模型一次性驗證。在部分場景下吞吐能提升 1.5-2 倍但效果和任務(wù)類型強(qiáng)相關(guān)不是所有的任務(wù)都適用需要實測。4.4 問題速查表把上面這些問題匯成一張表方便排查癥狀可能原因優(yōu)先排查方向啟動 OOMKV cache 設(shè)太長 / GPU 利用率設(shè)太高調(diào)低 max_model_len、調(diào)低 max_num_seqs生成質(zhì)量崩壞校準(zhǔn)集不匹配 / group size 太大換校準(zhǔn)集、重新量化、升檔位速度慢且 GPU 利用率低CPU offload 過重調(diào)高 --n-gpu-layers 或換大顯存卡并發(fā)后開始 OOM顯存碎片 / 并發(fā)數(shù)過大調(diào)低 max_num_seqs、換新版本 vLLM多輪對話特別慢前綴緩存未開啟打開 enable_prefix_caching數(shù)學(xué)題答錯量化損失敏感 / 基座弱換高比特檔位、換更強(qiáng)基座最后再分享一個我個人的習(xí)慣任何大模型推理項目我都先在 24G 消費卡上用 7B 模型把整條鏈路、參數(shù)配置、代碼框架全部跑通然后再換 70B 模型。這樣做的好處是排錯成本極低因為 7B 在消費卡上有充足余量問題更容易定位。等你把 7B 上的每一步都調(diào)明白了換 70B 時只需要更新模型路徑和顯存預(yù)算剩下的都是水到渠成的事。這套五層技術(shù)?？雌饋韺訑?shù)多但實際落地時就是你機(jī)器上裝一個推理框架、下載一個量化模型、設(shè)置好四個參數(shù)的事。先把第一步邁出去讓模型先跑起來再慢慢調(diào)優(yōu)。單卡跑 70B 這件事難度沒有想象中那么高關(guān)鍵在于想清楚每一層在解決什么問題然后按順序把它們逐個搞定。