很多開發(fā)者在剛接觸本地大模型時(shí)第一個(gè)困擾往往不是“模型怎么調(diào)”而是“我這臺(tái)電腦到底能不能跑起來”。去社區(qū)問了一圈有人用 8GB 顯存跑 7B 模型很流暢有人說 16GB 顯存加載就 OOM還有人拿著 4070 問能不能微調(diào) 70B。你會(huì)發(fā)現(xiàn)網(wǎng)上關(guān)于本地 LLM 硬件需求的討論幾乎都是零散的個(gè)人經(jīng)驗(yàn)缺少一個(gè)從參數(shù)和公式出發(fā)的量化計(jì)算工具。本文就圍繞“Hardware requirement calculator for local LLMs”這個(gè)主題完整講解本地大模型硬件需求的計(jì)算邏輯并帶你從零實(shí)現(xiàn)一個(gè)可用的硬件需求計(jì)算器。文章會(huì)覆蓋精度格式FP32、FP16、BF16、INT8、INT4對(duì)顯存的影響、KV Cache 的估算方法、推理與訓(xùn)練兩種場(chǎng)景的差異、代碼實(shí)現(xiàn)步驟以及最終如何用計(jì)算結(jié)果指導(dǎo)選卡和配置。適合剛?cè)腴T大模型本地部署的開發(fā)者也適合需要做硬件選型評(píng)估的技術(shù)負(fù)責(zé)人。1. 為什么本地 LLM 需要硬件需求計(jì)算器先說一個(gè)常見的現(xiàn)象很多人在決定下載模型之前完全靠“別人說能跑”來做判斷。比如有人看到“7B 模型 Q4 量化只要 4GB 顯存”于是拿著 6GB 顯存的舊顯卡去下載結(jié)果加載到一半進(jìn)程被殺或者生成速度慘不忍睹。還有人在 CPU 上硬跑 70B 模型每個(gè) Token 等好幾秒以為是代碼寫錯(cuò)了其實(shí)是硬件帶寬遠(yuǎn)不達(dá)標(biāo)。要避免這種問題最好在下載模型之前就手算出一個(gè)“下限值”這個(gè)模型至少需要多少顯存、多少內(nèi)存推理速度大概會(huì)落在什么區(qū)間。硬件需求計(jì)算器的價(jià)值就在這里。它本質(zhì)上是一個(gè)基于模型參數(shù)、精度格式、上下文長(zhǎng)度、批處理大小等輸入項(xiàng)輸出顯存需求、內(nèi)存需求、推薦硬件檔位的工具。它能幫你解決三個(gè)問題我的顯卡夠不夠跑這個(gè)模型如果不夠量化到 INT4 之后夠不夠如果只是跑推理和做微調(diào)相比硬件差距有多大另外本地 LLM 部署并不是簡(jiǎn)單地“模型文件多大就要多少顯存”。模型加載后顯存里除了權(quán)重還有 KV Cache、激活值、CUDA Context 等一系列額外開銷。不考慮這些算出來的結(jié)果和實(shí)際情況會(huì)有很大偏差。2. 本地 LLM 硬件需求的基礎(chǔ)概念要理解計(jì)算器先要把幾個(gè)核心概念弄清楚。這一節(jié)的內(nèi)容會(huì)比較基礎(chǔ)但它們是后面所有估算公式的根基。2.1 模型參數(shù)量Parameters模型參數(shù)量是衡量 LLM 規(guī)模最直接的指標(biāo)。我們說“7B 模型”就是指模型有大約 70 億個(gè)參數(shù)。參數(shù)量直接決定了兩件事模型的學(xué)習(xí)能力和表達(dá)能力模型文件的大小和運(yùn)行時(shí)占用資源。常見模型規(guī)模對(duì)應(yīng)的參數(shù)數(shù)量如下模型規(guī)模參數(shù)量7B約 70 億13B約 130 億33B約 330 億70B約 700 億需要說明的是不同模型架構(gòu)在相同參數(shù)量下實(shí)際結(jié)構(gòu)會(huì)有差異比如 LLaMA 和 Mistral 層數(shù)、頭數(shù)都不同。但作為粗略估算參數(shù)量是最通用的起點(diǎn)。2.2 精度格式FP32、FP16、BF16、INT8、INT4同樣一個(gè)模型參數(shù)用多少位來存儲(chǔ)直接決定模型體積和顯存占用。大模型領(lǐng)域最常見的精度格式有FP3232 位浮點(diǎn)每個(gè)參數(shù)占 4 個(gè)字節(jié)。精度最高范圍最廣但顯存占用也最大?；旧蠜]有人在推理時(shí)用純 FP32 跑大模型更多是在訓(xùn)練時(shí)作為 Master Weight 存在。FP1616 位浮點(diǎn)每個(gè)參數(shù)占 2 個(gè)字節(jié)。精度比 FP32 低但因?yàn)轱@存減半是早期大模型推理的主流格式。它在數(shù)值范圍上有限制|x| 超過 65504 會(huì)溢出不過對(duì)推理影響通常不大。BF16BFloat1616 位浮點(diǎn)每個(gè)參數(shù)同樣占 2 個(gè)字節(jié)。BF16 的動(dòng)態(tài)范圍和 FP32 幾乎一樣犧牲了尾數(shù)精度但減少了溢出問題?，F(xiàn)在主流訓(xùn)練框架都推薦用 BF16因?yàn)榇竽Ｐ吞荻热菀壮霈F(xiàn)尺度差異。INT88 位整數(shù)量化每個(gè)參數(shù)占 1 個(gè)字節(jié)。把浮點(diǎn)權(quán)重縮放到整數(shù)范圍來存儲(chǔ)和計(jì)算顯存直接再減一半。推理時(shí)常用 Weight-Only 量化效果在小模型上會(huì)有所損失但在大模型上表現(xiàn)相當(dāng)好。INT44 位整數(shù)量化每個(gè)參數(shù)理論上只占 0.5 個(gè)字節(jié)。這是社區(qū)最常用的格式比如 GGUF Q4_K_M、GPTQ INT4 等。顯存占用極低但量化誤差相對(duì)更大。對(duì) 7B 模型來說INT4 量化后權(quán)重文件只有 3.5GB 左右很多 4GB 獨(dú)顯的機(jī)器也能跑起來。為了直觀我把每個(gè)參數(shù)占用的空間整理成表精度每參數(shù)字節(jié)數(shù)7B 模型權(quán)重大小FP324約 28 GBFP16 / BF162約 14 GBINT81約 7 GBINT40.5約 3.5 GB這就是為什么同一個(gè)模型官方通常建議 28GB 顯存但量化到 INT4 只要 4GB 左右就能跑。2.3 KV Cache 與推理開銷很多人只算了權(quán)重顯存忽略了一個(gè)重要部分——KV Cache。在大模型推理時(shí)每生成一個(gè) Token都要把當(dāng)前的 Key 和 Value 緩存下來供后續(xù) Attention 計(jì)算使用。這部分的顯存占用和輸入輸出長(zhǎng)度成正比也和模型層數(shù)、頭數(shù)、維度有關(guān)。粗略估算公式KV_Cache_Size 2 × num_layers × num_kv_heads × head_dim × seq_len × batch_size × bytes_per_element不過在實(shí)際工程中我們可以用一個(gè)更簡(jiǎn)單的經(jīng)驗(yàn)值來估算。通常 KV Cache 大約占模型權(quán)重的 10% 到 30%在長(zhǎng)上下文場(chǎng)景下甚至更高。這也是為什么有人短上下文跑得好好的把 max_length 從 4096 調(diào)到 8192 之后直接 OOM。除了權(quán)重和 KV Cache顯存還需要容納CUDA Context大約 300MB 到 1GB 不等激活值A(chǔ)ctivation和臨時(shí)計(jì)算緩沖輸入 Token 的 Embedding推理框架的額外固定開銷。所以安全的做法是把權(quán)重顯存和 KV Cache 算完之后再額外預(yù)留 1GB 到 2GB 作為緩沖。這也是社區(qū)很多人“按理論算剛好夠?qū)嶋H一跑就爆”的原因——緩沖不夠。2.4 推理與訓(xùn)練的區(qū)別同一塊顯卡跑推理和做微調(diào)完全是兩個(gè)世界。推理只需要保存模型權(quán)重和中間激活梯度不需要保留。所以顯存需求約等于“權(quán)重 KV Cache 額外開銷”。微調(diào)則還要保存梯度梯度和參數(shù)同尺寸、優(yōu)化器狀態(tài)不同優(yōu)化器大小不同、以及更長(zhǎng)的激活鏈。例如用 Adam 優(yōu)化器訓(xùn)練一個(gè) FP16 模型僅優(yōu)化器狀態(tài)就要額外占用 8 字節(jié)/參數(shù)Momentum 和 Variance 各 4 字節(jié)加上梯度的 2 字節(jié)/參數(shù)訓(xùn)練時(shí)單個(gè)參數(shù)的顯存開銷遠(yuǎn)大于推理。近似計(jì)算訓(xùn)練顯存 權(quán)重(2字節(jié)) 梯度(2字節(jié)) Adam狀態(tài)(8字節(jié)) 激活值等 ≈ 每參數(shù) 12 字節(jié)以上也就是說FP16 訓(xùn)練一個(gè) 7B 模型光是權(quán)重、梯度和優(yōu)化器狀態(tài)就需要 84GB 左右單靠一張 24GB 顯卡根本裝不下。這也是為什么 LoRA、QLoRA 這類參數(shù)高效微調(diào)會(huì)如此流行——它們把可訓(xùn)練參數(shù)量大幅壓縮從而把訓(xùn)練顯存需求降到普通消費(fèi)級(jí)顯卡能接受的范圍。3. 硬件需求計(jì)算器的核心計(jì)算邏輯理解了上面的概念我們就可以來設(shè)計(jì)計(jì)算器了。核心就是一組公式根據(jù)用戶輸入的模型參數(shù)、精度和運(yùn)行場(chǎng)景算出顯存和內(nèi)存需求。3.1 權(quán)重顯存計(jì)算公式非常簡(jiǎn)單weight_memory num_params × bytes_per_param例如 7B 模型FP16 精度7,000,000,000 × 2 14,000,000,000 字節(jié) ≈ 14 GBINT4 精度按 0.5 字節(jié)7,000,000,000 × 0.5 3,500,000,000 字節(jié) ≈ 3.5 GB這個(gè)部分是最確定的幾乎不會(huì)因?yàn)檫\(yùn)行環(huán)境不同而變化。3.2 KV Cache 估算嚴(yán)格計(jì)算 KV Cache 需要知道模型具體架構(gòu)但作為通用工具我們可以用模型參數(shù)量的比例來粗估。這里我用一個(gè)經(jīng)驗(yàn)系數(shù)kv_cache_factor取值范圍通常在 0.1 到 0.3 之間默認(rèn) 0.15。kv_cache_memory weight_memory × kv_cache_factor如果你想更精確一點(diǎn)可以讓用戶輸入層數(shù)、KV Heads、Head Dim 和序列長(zhǎng)度用公式直接計(jì)算。下面計(jì)算器代碼里我會(huì)同時(shí)提供兩種模式快速估算和精細(xì)估算。3.3 推理場(chǎng)景總結(jié)推理所需的總顯存total_vram weight_memory kv_cache_memory overhead其中 overhead 建議至少 1GB如果是 Windows 環(huán)境或者不用 WSL 的話可以再放大一些因?yàn)?Windows 的顯存管理策略不同驅(qū)動(dòng)也會(huì)占一部分顯存。3.4 訓(xùn)練場(chǎng)景適配 LoRA/QLoRA 時(shí)可訓(xùn)練參數(shù)量會(huì)大幅減少。QLoRA 通常只需對(duì)低秩矩陣做梯度計(jì)算所以我們可以用一個(gè)參數(shù)trainable_params_ratio來表示可訓(xùn)練參數(shù)占全量的比例。training_memory weight_memory weight_memory × (gradient_ratio optimizer_bytes_per_param / bytes_per_element) activated_memory不過這種精確建模會(huì)很復(fù)雜且不同框架差異大。計(jì)算器里我建議用簡(jiǎn)化模型直接輸出“推理所需顯存”然后按經(jīng)驗(yàn)系數(shù)顯示“全參數(shù)微調(diào)所需顯存約是推理的 5-8 倍”作為警告。對(duì)多數(shù)讀者來說這個(gè)信息量已經(jīng)足夠。3.5 內(nèi)存帶寬與生成速度除了顯存容量還有一個(gè)容易被忽視的硬件參數(shù)——內(nèi)存帶寬。大模型推理屬于“訪存密集型”任務(wù)尤其在低并發(fā)場(chǎng)景下GPU 每生成一個(gè) Token都要把整個(gè)模型權(quán)重從顯存讀一遍。所以理論最大生成速度約等于tokens_per_sec ≈ memory_bandwidth / model_size_in_bytes舉例一塊 4090顯存帶寬約 1008 GB/sFP16 的 7B 模型權(quán)重 14GB理論速度約為1008 / 14 ≈ 72 tokens/s如果是 INT4 量化權(quán)重 3.5GB理論上限約 288 tokens/s不過實(shí)際還會(huì)受計(jì)算單元限制和其他開銷影響但方向是對(duì)的。所以計(jì)算器也可以輸出一個(gè)預(yù)估生成速度區(qū)間對(duì)用戶體驗(yàn)有很大參考價(jià)值。4. 完整實(shí)戰(zhàn)從零實(shí)現(xiàn)一個(gè) LLM 硬件需求計(jì)算器下面進(jìn)入實(shí)戰(zhàn)環(huán)節(jié)。我會(huì)實(shí)現(xiàn)兩個(gè)版本一個(gè) Python 命令行版本適合快速腳本調(diào)用和二次開發(fā)一個(gè) HTML JavaScript 網(wǎng)頁(yè)版本適合直接雙擊打開使用方便沒有 Python 環(huán)境的同學(xué)。4.1 創(chuàng)建項(xiàng)目結(jié)構(gòu)llm-hw-calculator/ ├── calculator.py ├── index.html └── README.md4.2 Python 命令行版本先實(shí)現(xiàn)核心邏輯。打開calculator.py寫入以下代碼# 文件路徑llm-hw-calculator/calculator.py def bytes_per_param(precision: str) - float: 返回不同精度下每個(gè)參數(shù)占用的字節(jié)數(shù) mapping { fp32: 4.0, fp16: 2.0, bf16: 2.0, int8: 1.0, int4: 0.5, } if precision.lower() not in mapping: raise ValueError(f不支持的精度類型: {precision}可選: {list(mapping.keys())}) return mapping[precision.lower()] def estimate_weight_memory(num_params_billion: float, precision: str) - float: 估算模型權(quán)重的顯存占用單位為 GB num_params num_params_billion * 1e9 return num_params * bytes_per_param(precision) / (1024 ** 3) def estimate_kv_cache_memory(weight_memory_gb: float, seq_len: int, config: dict None) - float: 估算 KV Cache 顯存占用。 如果提供了模型結(jié)構(gòu)參數(shù)則用精細(xì)公式 否則使用經(jīng)驗(yàn)比例粗估。 if config: num_layers config[num_layers] num_kv_heads config[num_kv_heads] head_dim config[head_dim] batch_size config.get(batch_size, 1) # 2 表示 K 和 V 兩份緩存 kv_bytes 2 * num_layers * num_kv_heads * head_dim * seq_len * batch_size * 2.0 return kv_bytes / (1024 ** 3) # 經(jīng)驗(yàn)值KV Cache 約為權(quán)重的 10%~30%這里取 15% return weight_memory_gb * 0.15 def estimate_inference_vram(num_params_billion: float, precision: str, seq_len: int 4096, model_config: dict None) - dict: 估算推理所需顯存和生成速度相關(guān)指標(biāo) weight_mem estimate_weight_memory(num_params_billion, precision) kv_mem estimate_kv_cache_memory(weight_mem, seq_len, model_config) overhead 1.0 # CUDA Context 激活值等固定開銷 total_vram weight_mem kv_mem overhead return { weight_memory_gb: round(weight_mem, 2), kv_cache_memory_gb: round(kv_mem, 2), estimated_overhead_gb: overhead, total_vram_gb: round(total_vram, 2), } def estimate_training_vram(inference_result: dict) - dict: 全參數(shù)微調(diào)粗略估算通常是推理的 5-8 倍 factor_min 5 factor_max 8 return { training_vram_min_gb: round(inference_result[total_vram_gb] * factor_min, 2), training_vram_max_gb: round(inference_result[total_vram_gb] * factor_max, 2), note: 全參數(shù)微調(diào)需要保存梯度與優(yōu)化器狀態(tài)顯存通常是推理的 5-8 倍使用 LoRA/QLoRA 可大幅降低。 } def estimate_generation_speed(bandwidth_gb_per_s: float, num_params_billion: float, precision: str) - float: 理論最大生成速度tokens/s只考慮權(quán)重復(fù)讀耗時(shí) model_size_gb estimate_weight_memory(num_params_billion, precision) if model_size_gb 0: return 0.0 return round(bandwidth_gb_per_s / model_size_gb, 2) if __name__ __main__: # 例子7B 模型INT4 量化上下文 4096在 4090 上推理 example_vram estimate_inference_vram( num_params_billion7.0, precisionint4, seq_len4096 ) print( 推理顯存估算 ) for key, value in example_vram.items(): print(f{key}: {value} GB) print(\n 微調(diào)顯存估算 ) training_info estimate_training_vram(example_vram) for key, value in training_info.items(): print(f{key}: {value}) print(\n 生成速度粗算RTX 4090 約 1008 GB/s ) speed estimate_generation_speed( bandwidth_gb_per_s1008, num_params_billion7.0, precisionint4 ) print(f理論最大生成速度約: {speed} tokens/s)這段代碼的核心就是幾個(gè)純函數(shù)輸入輸出都很清晰。逐個(gè)解釋bytes_per_param精度映射表INT4 返回 0.5 字節(jié)。estimate_weight_memory權(quán)重顯存。estimate_kv_cache_memory優(yōu)先用精細(xì)公式缺少架構(gòu)參數(shù)時(shí)退回經(jīng)驗(yàn)比例。estimate_inference_vram匯總。overhead 固定 1GB這個(gè)值你可以根據(jù)自己的環(huán)境調(diào)整Windows 下建議 1.5GB。estimate_training_vram給出全參數(shù)微調(diào)的粗估區(qū)間。estimate_generation_speed理論最大速度強(qiáng)調(diào)“理論”因?yàn)閷?shí)際要打折扣。運(yùn)行結(jié)果類似 推理顯存估算 weight_memory_gb: 3.5 GB kv_cache_memory_gb: 0.52 GB estimated_overhead_gb: 1 GB total_vram_gb: 5.02 GB 微調(diào)顯存估算 training_vram_min_gb: 25.12 GB training_vram_max_gb: 40.19 GB note: 全參數(shù)微調(diào)需要保存梯度與優(yōu)化器狀態(tài)顯存通常是推理的 5-8 倍使用 LoRA/QLoRA 可大幅降低。 生成速度粗算RTX 4090 約 1008 GB/s 理論最大生成速度約: 288.0 tokens/s如果你用 FP16 跑同一個(gè) 7B 模型weight_memory_gb: 14.0 GB kv_cache_memory_gb: 2.1 GB estimated_overhead_gb: 1 GB total_vram_gb: 17.1 GB同樣是 7B 模型FP16 和 INT4 的總顯存差了 12GB 左右。這就是量化對(duì)本地部署的意義。4.3 支持模型結(jié)構(gòu)參數(shù)的精細(xì)模式上面的estimate_kv_cache_memory已經(jīng)預(yù)留了config參數(shù)。如果你想在計(jì)算器中嵌入某個(gè)具體模型的結(jié)構(gòu)信息可以這樣用。這里以 LLaMA-7B 為例llama_7b_config { num_layers: 32, num_kv_heads: 32, head_dim: 128, batch_size: 1, } # 在 seq_len4096 時(shí)KV Cache 約為 1.0 GB kv_cache estimate_kv_cache_memory( weight_memory_gb14.0, seq_len4096, configllama_7b_config ) print(f精細(xì)模式 KV Cache: {kv_cache:.2f} GB)實(shí)際上不同模型架構(gòu)的 KV Cache 計(jì)算方式逐步演進(jìn)。像 GQAGrouped Query Attention在 LLaMA 2 70B 中出現(xiàn)后KV Head 數(shù)量遠(yuǎn)小于 Query Head 數(shù)量KV Cache 會(huì)更小。這也是為什么部分大模型在長(zhǎng)上下文場(chǎng)景下尤其依賴 GQA。你的計(jì)算器如果有模型庫(kù)把這些參數(shù)配置成 JSON 是不錯(cuò)的選擇。4.4 HTML 網(wǎng)頁(yè)版本為了讓沒有 Python 環(huán)境的同學(xué)也能用我把同樣的邏輯做成一個(gè)純前端頁(yè)面。打開index.html寫入以下代碼!DOCTYPE html html langzh-CN head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 title本地 LLM 硬件需求計(jì)算器/title style body { font-family: -apple-system, BlinkMacSystemFont, Segoe UI, sans-serif; max-width: 720px; margin: 0 auto; padding: 20px; background: #f7f8fa; color: #333; } .card { background: #fff; border-radius: 12px; padding: 24px; margin-bottom: 16px; box-shadow: 0 2px 8px rgba(0, 0, 0, 0.06); } h1 { font-size: 1.5rem; } label { display: block; font-weight: 600; margin-bottom: 6px; } select, input { width: 100%; padding: 10px; margin-bottom: 16px; border: 1px solid #ddd; border-radius: 8px; font-size: 1rem; box-sizing: border-box; } button { background: #1677ff; color: #fff; border: none; padding: 12px 24px; border-radius: 8px; font-size: 1.05rem; cursor: pointer; } button:hover { background: #0958d9; } .result-item { display: flex; justify-content: space-between; padding: 8px 0; border-bottom: 1px solid #f0f0f0; } .result-item:last-child { border-bottom: none; } .warn { background: #fffbe6; border: 1px solid #ffe58f; border-radius: 8px; padding: 12px; margin-top: 12px; font-size: 0.9rem; } /style /head body div classcard h1本地 LLM 硬件需求計(jì)算器/h1 p根據(jù)模型參數(shù)、精度、上下文長(zhǎng)度估算推理所需顯存、微調(diào)顯存范圍和理論生成速度。/p /div div classcard label formodelSize模型參數(shù)量B/label input typenumber idmodelSize value7 step0.1 min0.1 label forprecision精度格式/label select idprecision option valuefp32FP324 字節(jié)/參數(shù)/option option valuefp16 selectedFP162 字節(jié)/參數(shù)/option option valuebf16BF162 字節(jié)/參數(shù)/option option valueint8INT81 字節(jié)/參數(shù)/option option valueint4INT40.5 字節(jié)/參數(shù)/option /select label forseqLen上下文長(zhǎng)度Tokens/label input typenumber idseqLen value4096 step512 min512 label forbandwidthGPU 顯存帶寬GB/s/label input typenumber idbandwidth value1008 step50 min50 button onclickcalculate()計(jì)算硬件需求/button /div div classcard idresult styledisplay:none; h2推理顯存估算/h2 div idinferenceResult/div h2微調(diào)顯存估算/h2 div idtrainingResult/div h2理論生成速度/h2 div idspeedResult/div div classwarn idwarning/div /div script const PRECISION_BYTES { fp32: 4.0, fp16: 2.0, bf16: 2.0, int8: 1.0, int4: 0.5, }; function calculate() { const modelSizeB parseFloat(document.getElementById(modelSize).value); const precision document.getElementById(precision).value; const seqLen parseInt(document.getElementById(seqLen).value); const bandwidth parseFloat(document.getElementById(bandwidth).value); if (!modelSizeB || modelSizeB 0) { alert(請(qǐng)?zhí)顚懩Ｐ蛥?shù)量); return; } const bytesPerParam PRECISION_BYTES[precision]; const numParams modelSizeB * 1e9; const weightBytes numParams * bytesPerParam; const weightGB weightBytes / (1024 ** 3); // KV Cache 粗估權(quán)重 15% const kvGB weightGB * 0.15; // 固定開銷 const overheadGB 1.0; const totalVRAM weightGB kvGB overheadGB; const trainMin totalVRAM * 5; const trainMax totalVRAM * 8; // 理論速度 const theoreticalSpeed bandwidth / weightGB; document.getElementById(inferenceResult).innerHTML div classresult-itemspan模型權(quán)重/spanspan${weightGB.toFixed(2)} GB/span/div div classresult-itemspanKV Cache估算/spanspan${kvGB.toFixed(2)} GB/span/div div classresult-itemspan固定開銷CUDA Context 等/spanspan${overheadGB.toFixed(2)} GB/span/div div classresult-item stylefont-weight:700;span推薦顯存下限/spanspan${totalVRAM.toFixed(2)} GB/span/div ; document.getElementById(trainingResult).innerHTML div classresult-itemspan全參數(shù)微調(diào)估算/spanspan${trainMin.toFixed(2)} ~ ${trainMax.toFixed(2)} GB/span/div ; document.getElementById(speedResult).innerHTML div classresult-itemspan理論最大生成速度/spanspan${theoreticalSpeed.toFixed(2)} tokens/s/span/div div classresult-itemspan實(shí)際體驗(yàn)參考/spanspan約 ${(theoreticalSpeed * 0.4).toFixed(2)} ~ ${(theoreticalSpeed * 0.7).toFixed(2)} tokens/s/span/div ; let warnText ; if (totalVRAM 24) { warnText 推薦顯存超過 24GB常見消費(fèi)級(jí)顯卡較難滿足。建議嘗試更大量化如 INT4或選擇更小模型也可以考慮云 GPU 實(shí)例。; } else if (totalVRAM 12) { warnText 推薦顯存超過 12GB建議確認(rèn)你的顯卡顯存是否足夠。若不足可以改用 INT4/INT8 量化并縮短上下文長(zhǎng)度。; } else { warnText 當(dāng)前配置在主流 8GB~24GB 顯卡上都有機(jī)會(huì)運(yùn)行。具體流暢度還要看內(nèi)存帶寬和系統(tǒng)顯存共享策略。; } document.getElementById(warning).innerText warnText; document.getElementById(result).style.display block; } /script /body /html這個(gè)頁(yè)面就是一個(gè)完整的計(jì)算器。用瀏覽器打開后輸入模型參數(shù)量選擇精度格式設(shè)置上下文長(zhǎng)度填顯卡顯存帶寬點(diǎn)擊按鈕就能得到結(jié)果。頁(yè)面里我另外加了一個(gè)“實(shí)際體驗(yàn)參考”取理論速度的 40% 到 70%這是考慮到 Attention 計(jì)算、采樣、接口傳輸?shù)拈_銷。這個(gè)比例不是精確值但比直接報(bào)理論速度更貼近真實(shí)體驗(yàn)。4.5 運(yùn)行與驗(yàn)證Python 版本運(yùn)行方式cd llm-hw-calculator python calculator.py如果看到類似下面的輸出說明代碼運(yùn)行正常 推理顯存估算 weight_memory_gb: 3.5 GB kv_cache_memory_gb: 0.52 GB estimated_overhead_gb: 1 GB total_vram_gb: 5.02 GB 微調(diào)顯存估算 training_vram_min_gb: 25.12 GB training_vram_max_gb: 40.19 GB note: 全參數(shù)微調(diào)需要保存梯度與優(yōu)化器狀態(tài)顯存通常是推理的 5-8 倍使用 LoRA/QLoRA 可大幅降低。 生成速度粗算RTX 4090 約 1008 GB/s 理論最大生成速度約: 288.0 tokens/s網(wǎng)頁(yè)版本直接用瀏覽器打開index.html即可不需要起服務(wù)也不需要聯(lián)網(wǎng)。4.6 結(jié)果解讀建議拿到計(jì)算結(jié)果后不要直接拿“推薦顯存下限”去對(duì)標(biāo)顯卡。我的建議是如果推薦顯存略小于你的顯卡顯存比如差了 1GB可以跑但盡量縮短上下文長(zhǎng)度同時(shí)關(guān)掉其他占用顯存的應(yīng)用。如果推薦顯存和顯卡顯存差不多建議使用 GGUF 的 k-quant 系列量化或調(diào)整 KV Cache 策略。如果要長(zhǎng)時(shí)間運(yùn)行服務(wù)要預(yù)留比計(jì)算值多 2GB 左右的余量因?yàn)橄到y(tǒng)和服務(wù)端框架會(huì)隨時(shí)間產(chǎn)生一些顯存碎片。5. 常見問題與排查思路開發(fā)和實(shí)際部署過程中很多人會(huì)遇到類似的問題。我整理成了一份表格方便你查閱。問題現(xiàn)象常見原因解決思路加載模型時(shí)直接 OOM顯存需求超過顯卡容量或者上下文長(zhǎng)度設(shè)置過大計(jì)算器先算一次改用 INT4/INT8 量化縮短上下文長(zhǎng)度加載成功但生成速度極慢內(nèi)存帶寬不足或權(quán)重未完全載入顯存而使用共享內(nèi)存檢查nvidia-smi確認(rèn)模型確實(shí)在顯存降低 KV Cache 或分批量化Windows 下 OOM同樣顯存 Linux 卻可以Windows 顯存管理策略和驅(qū)動(dòng)占用量不同適當(dāng)調(diào)大 overhead 值或使用 WSL2 運(yùn)行短上下文正常長(zhǎng)上下文卡死KV Cache 隨序列長(zhǎng)度線性增長(zhǎng)導(dǎo)致顯存溢出在 Framework 層面限制 max_length或使用支持 PagedAttention 的推理框架計(jì)算器說夠?qū)嶋H跑起來差一點(diǎn)忘記算 CUDA Context、驅(qū)動(dòng)占用、框架緩沖把 overhead 從 1GB 調(diào)到 1.5GB 再到 2GB 重新估算換量化格式后速度沒有明顯提升模型已經(jīng)變小但 Attention 計(jì)算占了主要耗時(shí)檢查是否滿足帶寬受限假設(shè)短序列下影響可能不大用 CPU 推理速度慢到不可用CPU 內(nèi)存帶寬遠(yuǎn)低于 GPU優(yōu)先用量化模型核數(shù)多少不是決定推理速度的唯一因素內(nèi)存帶寬更關(guān)鍵幾個(gè)排查步驟值得展開說。5.1 驗(yàn)證顯存占用在模型加載后打開另一個(gè)終端運(yùn)行nvidia-smi觀察四塊區(qū)域GPU 顯存 Used進(jìn)程列表中 Python / llama-server 進(jìn)程的顯存Volatile GPU-Util如果是多卡確認(rèn)模型是否只用了其中一張。如果nvidia-smi顯示的 Used 顯存和計(jì)算器估算差別很大通常是因?yàn)槟阌玫哪Ｐ筒皇怯?jì)算器對(duì)應(yīng)精度的版本推理框架有額外的顯存優(yōu)化如 KV Cache 重用或者上下文長(zhǎng)度設(shè)置和設(shè)備上的max_seq_len不一致。5.2 是否真的把所有模型權(quán)存放進(jìn)了顯存有些推理框架在顯存不足時(shí)會(huì)自動(dòng)把部分權(quán)重放到內(nèi)存。從性能角度看這種模式雖然在短時(shí)間能運(yùn)行但每層之間都有 PCIe 或共享內(nèi)存的傳輸速度會(huì)嚴(yán)重退化。你可以用nvidia-smi看 CUDA Memory 的分配情況或者在日志里看框架是否打印出類似 “offload to CPU” 的信息模型文件是否被 mmap 映射到了內(nèi)存。如果確認(rèn)有 offload最直接的解決辦法是減小模型或用更高程度量化。5.3 訓(xùn)練顯存不夠時(shí)怎么辦如果你做的不是推理而是微調(diào)顯存不夠時(shí)優(yōu)先考慮LoRA只訓(xùn)練注入的低秩矩陣顯存開銷小很多QLoRA加載的模型先量化到 INT4再訓(xùn)練低秩適配器梯度累積不用一次性把 batch 都放進(jìn)顯存混合精度BF16 或 FP16 訓(xùn)練減少一半顯存梯度檢查點(diǎn)用時(shí)間換空間。你會(huì)發(fā)現(xiàn)推理場(chǎng)景的“量化”在訓(xùn)練場(chǎng)景里同樣有效而且 QLoRA 是當(dāng)前社區(qū)最熱門的低成本全參微調(diào)替代方案。如果你的模型是 70B 級(jí)別QLoRA 配合兩張 24GB 顯卡是可行的但全參數(shù)微調(diào)則可能需要多塊 A100 或 H100。6. 最佳實(shí)踐與工程建議這一節(jié)是本文最有工程價(jià)值的部分建議結(jié)合自己的使用場(chǎng)景去對(duì)照。6.1 計(jì)算器參數(shù)本身要?jiǎng)討B(tài)調(diào)整不要死守默認(rèn)參數(shù)。比如KV Cache 經(jīng)驗(yàn)系數(shù) 0.15 只適合中等上下文2048~4096。如果上下文是 8192 或 16384系數(shù)應(yīng)上調(diào)到 0.25 甚至 0.35。overhead 1GB 是最小值。生產(chǎn)環(huán)境建議 2GBWindows 建議 1.5~2GB。帶寬不是唯一瓶頸。如果你用的是 4090權(quán)重訪存確實(shí)主導(dǎo)如果模型比較小如 1B 到 3B計(jì)算密集型操作可能成為瓶頸實(shí)際速度會(huì)比理論值低更多。6.2 量化精度選擇的原則選擇量化精度時(shí)不能一味“越低越好”。我的建議7B 模型如果顯存有 8GB優(yōu)先 Q8/Q6效果和 FP16 差距很小如果顯存只有 4GB才考慮 Q4。13B 模型Q5/Q6 是甜點(diǎn)量化效果和 FP16 接近顯存需求又在可控范圍內(nèi)。70B 級(jí)別Q4 是唯一可行選擇。但如果模型對(duì)輸出質(zhì)量要求高可以試試 Q4_K_M 和 Q4_K_S 之間的差異。生成長(zhǎng)文本、代碼任務(wù)時(shí)量化損失會(huì)更明顯尤其是復(fù)雜邏輯和多步推理場(chǎng)景。如果是簡(jiǎn)單問答、摘要INT4 的差距更容易接受。6.3 選型時(shí)不要只看顯存容量很多人在選顯卡時(shí)只看顯存忽略了帶寬和算力。其實(shí)對(duì)于本地 LLM 推理顯存帶寬的作用比很多人想象中大得多。以 7B FP16 模型為例顯卡顯存帶寬理論最大速度RTX 3060360 GB/s約 25 tokens/sRTX 4070504 GB/s約 36 tokens/sRTX 40901008 GB/s約 72 tokens/sM2 Ultra800 GB/s約 57 tokens/s注意這只是權(quán)重讀取的理論速度實(shí)際會(huì)更低但橫向?qū)Ρ仁强煽康膸挿独碚撍俣壬舷抟卜?。因此如果你的主要用途是本地大模型在滿足顯存容量的前提下盡量選帶寬更高的顯卡這一步比一味堆顯存更實(shí)際。6.4 生產(chǎn)環(huán)境建議如果你要把本地 LLM 做成服務(wù)給團(tuán)隊(duì)使用除了顯存計(jì)算還要注意并發(fā)請(qǐng)求數(shù)并發(fā)增加會(huì)擴(kuò)大 KV Cache 總和計(jì)算器里的 batch_size 要乘以并發(fā)數(shù)顯存泄漏長(zhǎng)時(shí)間運(yùn)行的服務(wù)建議定期監(jiān)控nvidia-smi --query-gpumemory.used --formatcsv發(fā)布前做壓力測(cè)試模型熱加載切換模型時(shí)如果顯存沒釋放可以先 kill 進(jìn)程再重新啟動(dòng)多用戶隔離盡量用支持 PagedAttention 的推理框架如 vLLM能更高效管理 KV Cache日志與監(jiān)控在容器或 systemd 服務(wù)中記錄顯存峰值方便后面調(diào)參。6.5 謹(jǐn)慎處理存儲(chǔ)與下載一個(gè)經(jīng)常被忽略的事實(shí)是模型文件下載后占用的是磁盤空間。如果做量化轉(zhuǎn)換中途還要存放未量化模型。例如 70B FP16 模型原始文件 140GB量化過程可能需要額外 140GB 臨時(shí)空間。所以磁盤最少要有模型文件大小的 2 倍空間再做量化轉(zhuǎn)換優(yōu)先使用 SSD因?yàn)榧虞d模型時(shí)有大量隨機(jī)讀取如果從 Hugging Face 下載提前配置好緩存路徑避免把系統(tǒng)盤占滿。6.6 用計(jì)算器輔助自動(dòng)決策如果你是運(yùn)維或平臺(tái)開發(fā)計(jì)算器邏輯還可以嵌入部署腳本。比如用戶選擇模型和精度后腳本自動(dòng)判斷當(dāng)前 GPU 可用顯存是否滿足不滿足就拒絕啟動(dòng)或者在啟動(dòng)時(shí)自動(dòng)切到更低的量化格式。這種做法雖然簡(jiǎn)單但能避免很多“部署后崩掉”的問題。7. 擴(kuò)展方向與下一步學(xué)習(xí)路線本文實(shí)現(xiàn)的計(jì)算器核心邏輯已經(jīng)能覆蓋絕大多數(shù)本地 LLM 硬件評(píng)估場(chǎng)景但還有幾個(gè)方向可以繼續(xù)完善。7.1 接入更多推理框架參數(shù)不同推理框架的顯存行為差異很大llama.cpp / GGUF有 mmap可以通過--n-gpu-layers控制多少層放到 GPUvLLM有 PagedAttentionKV Cache 可以動(dòng)態(tài)劃分Hugging Face Transformers默認(rèn)行為是把所有參數(shù)加載到指定設(shè)備ExLlamaV2專門針對(duì)量化模型優(yōu)化顯存占用和速度表現(xiàn)都更理想。你的計(jì)算器可以在輸出里增加“不同框架推薦參數(shù)”這是很有價(jià)值的信息。7.2 引入模型結(jié)構(gòu)數(shù)據(jù)庫(kù)如果計(jì)算器能內(nèi)置常見模型的架構(gòu)信息層數(shù)、頭數(shù)、維度、KV Head 數(shù)KV Cache 估算精度會(huì)大幅提升。這部分?jǐn)?shù)據(jù)可以直接從模型目錄的config.json里獲取。{ hidden_size: 4096, intermediate_size: 11008, num_attention_heads: 32, num_hidden_layers: 32, num_key_value_heads: 32 }讀取這些字段后代入精細(xì)公式KV Cache 計(jì)算就會(huì)比經(jīng)驗(yàn)比例準(zhǔn)確得多。7.3 從靜態(tài)計(jì)算到動(dòng)態(tài)監(jiān)控更進(jìn)一步計(jì)算器可以不做成“一次性估算工具”而是做成“部署后監(jiān)控面板”。部署模型時(shí)記錄初始顯存運(yùn)行過程實(shí)時(shí)記錄顯存峰值和 Token 速度再用這些數(shù)據(jù)回填優(yōu)化估算模型。這種思路適用于企業(yè)內(nèi)部的 LLM 服務(wù)運(yùn)維平臺(tái)能逐步建立更貼近自己的硬件選型基線。7.4 加上成本模型如果你考慮云 GPU 實(shí)例建議在計(jì)算器里同時(shí)引入“按需價(jià)格”維度。例如 24GB A10G 和 48GB A6000 的價(jià)格差、性能和顯存的關(guān)系做成簡(jiǎn)單的性價(jià)比指標(biāo)。這樣同一個(gè)模型你不僅知道需要什么硬件還能知道用哪類實(shí)例更劃算。8. 寫在最后本地 LLM 部署的“硬件夠不夠”這個(gè)問題其實(shí)完全可以量化不需要賭運(yùn)氣。通過精度、參數(shù)量、KV Cache 和帶寬這幾個(gè)核心參數(shù)你就能在下載模型前對(duì)顯存需求、生成速度和訓(xùn)練可行性心里有數(shù)。本文實(shí)現(xiàn)的硬件需求計(jì)算器無論是 Python 腳本還是網(wǎng)頁(yè)版本都保持了極低的依賴和較高的可移植性你可以直接復(fù)制到自己的項(xiàng)目中用。在實(shí)際使用中我建議你把“計(jì)算器估算值 實(shí)際 nvidia-smi 觀察值 生成速度實(shí)測(cè)值”三份數(shù)據(jù)放在一起對(duì)比。很快你就會(huì)發(fā)現(xiàn)顯存需求不再是個(gè)模糊概念而是能用公式推演、用監(jiān)控驗(yàn)證的工程指標(biāo)。如果你正在部署本地模型不妨先用這個(gè)計(jì)算器跑一遍再?zèng)Q定下載哪個(gè)量化版本。要知道在 8GB 顯卡上硬上 FP16 的 13B 模型和用 Q4 量化版跑流暢對(duì)話體驗(yàn)完全是兩個(gè)層次。選對(duì)硬件和精度可能比多花半個(gè)月調(diào)參更有效果。