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