最近在整理硬件清單的時候我發(fā)現(xiàn)自己老是要跟人解釋同一個問題openrig 到底是個什么東西名字里帶個 rig很多人第一反應(yīng)是礦機架。其實方向完全不同它是我一直在維護的一套本地大模型推理機架方案關(guān)鍵詞是 open——開放的硬件選型、開放的軟件組合、可復(fù)制的部署流程。目標也很樸素讓開源大模型真正跑在自己手里而不是每次調(diào)用都交給第三方 API。這套方案適合三類人覺得 Token 費用越花越多的個人開發(fā)者、數(shù)據(jù)敏感不想出內(nèi)網(wǎng)的小團隊、想折騰本地推理又不想從零踩坑的工程新人。下面這篇文章我會從需求定位、硬件選型、推理引擎、量化策略、部署調(diào)優(yōu)到故障排查完整過一遍把我自己在這套機架上反復(fù)驗證過的東西寫出來。內(nèi)容偏實操基本照著抄就能搭起來。1. 需求定位先搞清楚誰在用再決定花多少錢買卡做這套方案之前我最不建議的事情就是先打開電商頁面搜顯卡。硬件這東西沒有絕對的“好”只有“匹配不匹配”。你得先想清楚這臺機器是給你一個人調(diào)試代碼用的還是給整個團隊提供服務(wù)的這兩個需求的硬件預(yù)算差了好幾倍。1.1 三種典型使用場景對應(yīng)三種硬件檔位我接觸到的本地推理需求大致分三類場景不同對硬件的要求就完全不同。單人研發(fā)調(diào)試比如驗證 prompt 效果、跑跑 RAG 實驗、給某個模型寫評測腳本。這類場景并發(fā)基本是 1上下文長度也不會拉滿一個 7B 到 14B 的模型就夠用了16GB 到 24GB 顯存的單卡就能玩得很舒服。我的建議是直接 24GB后面可以少操很多心。小團隊共享服務(wù)比如做內(nèi)部知識庫問答、代碼審查輔助、客服工單摘要。這種場景會有多個人同時用模型規(guī)模建議上 14B 到 32B硬件得按單卡 48GB 或者雙卡來規(guī)劃軟件層面也要用支持高并發(fā)調(diào)度的推理引擎。常態(tài)化生產(chǎn)服務(wù)比如每天有上千次請求的接口對響應(yīng)時間有硬性要求。那就得考慮 32B 以上模型加多卡并行同時配合 vLLM 這類吞吐優(yōu)化引擎做流量承接。使用場景推薦模型規(guī)模硬件檔位預(yù)算參考單人調(diào)試7B-14B Q416GB-24GB 單卡中低小團隊共享14B-32B Q4/Q824GB-48GB 單卡或雙卡中高生產(chǎn)服務(wù)32B-72B Q4雙卡及以上配合 vLLM高這套劃分不一定絕對但方向是對的。如果你想兼顧前兩種場景直接按“單卡 24GB 起步”去選不會錯太多。1.2 顯存需求可以算出來權(quán)重、KV cache、運行開銷很多人以為顯存需求就是模型文件大小這是最常見的誤解。實際上顯存里要裝三樣?xùn)|西模型權(quán)重、KV cache、CUDA 運行時開銷。我一般先用一個簡化公式估算權(quán)重占用模型權(quán)重占用GB≈ 參數(shù)量B× 每參數(shù)比特數(shù) ÷ 8舉個例子一個 7B 模型用 FP16 加載每參數(shù) 16 比特那就是 7 × 16 / 8 14GB這在 16GB 卡上已經(jīng)很緊張了。如果換 INT4 量化4 比特每參數(shù)理論上 3.5GB但考慮到嵌入層、歸一化層保留高精度以及量化分組開銷實際權(quán)重文件會在 4.4GB 左右。KV cache 是第二個變量。它的占用和上下文長度線性相關(guān)你把 context 從 8K 拉到 32KKV cache 會翻四倍。14B 模型在 8K 上下文下大約占 1-2GB拉到 32K 可能要 6-8GB。第三個是 CUDA 運行時、tokenizer、調(diào)度器這些雜項開銷留 1GB 左右比較穩(wěn)妥。所以完整公式應(yīng)該是總顯存需求 模型權(quán)重 KV cache 運行開銷。24GB 的卡跑 14B Q4權(quán)重約 8.8GB8K 上下文 KV cache 約 2GB剩下 13GB 做余量非常從容。但如果強行上 32B Q4光權(quán)重就 18GBKV cache 稍長一點就可能爆。1.3 為什么我堅持把模型放在本地有些人覺得調(diào)用大廠 API 更省事這個我承認但 openrig 一直堅持本地化有三個非?，F(xiàn)實的原因。第一是數(shù)據(jù)邊界。很多公司的數(shù)據(jù)管理制度比你想的嚴格代碼庫、客服記錄、內(nèi)部文檔這些內(nèi)容根本不適合發(fā)送到外部服務(wù)。本地推理讓數(shù)據(jù)從生成到處理的全生命周期都在自己的網(wǎng)絡(luò)里。第二是成本結(jié)構(gòu)。API 費用是按 token 計的日調(diào)用量上去以后賬單數(shù)字相當可觀。本地硬件是一次性投入只要有持續(xù)的工作負載回本周期往往比預(yù)期短尤其你用的是開源模型而不是收費 API 的時候。第三是可控性。本地模型可以自定義 system prompt、可以接自己的工具函數(shù)、可以隨時做 LoRA 微調(diào)甚至能為了某個具體場景把溫度、采樣參數(shù)調(diào)到比較激進的狀態(tài)。這些都是封閉 API 很難給到的自由度。2. 硬件選型顯存帶寬比算力更值得花錢很多第一次裝機器的人有個誤區(qū)以為大模型推理就是拼算力于是盯著 TFLOPS 買卡。實際跑起來你就會發(fā)現(xiàn)大語言模型推理的瓶頸很多時候根本不是算力而是顯存帶寬。2.1 GPU 三檔與核心參數(shù)速查我按自己的經(jīng)驗把主流選擇分成了三檔每一檔對應(yīng)的核心參數(shù)可以直接對照著看。入門檔以 RTX 4060 Ti 16GB 為代表顯存帶寬約 288GB/s優(yōu)勢是便宜、功耗低適合跑 7B 到 14B 的 4bit 量化模型但生成速度會慢一些大概每秒 40-60 token。主力檔是 RTX 3090 或 4090 24GB這是目前性價比最均衡的一檔。3090 經(jīng)過二手市場沉淀后價格合理顯存帶寬 936GB/s解碼速度相當可觀。4090 帶寬更高達到 1008GB/s但價格也貴不少。進階檔是 RTX 6000 Ada 或 A6000 48GB面向 32B 以上模型專業(yè)卡散熱和穩(wěn)定性更好缺點是貴。檔位顯卡顯存帶寬參考適合模型入門RTX 4060 Ti 16GB16GB288GB/s7B-14B Q4主力RTX 3090 / 409024GB936-1008GB/s14B Q4/Q832B Q4 極限進階RTX 6000 Ada / A600048GB768GB/s32B Q870B Q424GB 目前是性價比甜點這個結(jié)論在多個開源模型社區(qū)里也是共識。預(yù)算夠就直接上不要糾結(jié)。2.2 prefill 和 decode兩個階段的瓶頸完全不同Transformer 模型的推理過程分兩個階段很多人不區(qū)分它們導(dǎo)致調(diào)優(yōu)時摸不著頭腦。prefill 階段也就是用戶輸入提示詞后模型第一次計算的那一下是計算密集型。它要并行處理所有輸入 token這時候 GPU 的算力起主要作用TFLOPS 越高首 token 延遲越低。decode 階段則是逐 token 生成的階段每個新 token 都要把整個模型的權(quán)重重新讀一遍這個階段變成顯存帶寬密集型。顯存帶寬越高每秒吐的 token 就越多?？梢宰鰝€簡單估算7B Q4 的權(quán)重約 4.4GB在帶寬 936GB/s 的 3090 上理論上每秒最多生成 936 / 4.4 ≈ 213 個 token實際因為有緩存、碎片和計算重疊的損耗大概只能跑到一半也就是 100-130 token/s。這就解釋了一個現(xiàn)象為什么兩張顯卡算力差不多但顯存帶寬高的那張推理速度明顯更快。所以買卡的第一眼看顯存容量第二眼看顯存帶寬TFLOPS 反而是最次要的指標。2.3 雙卡平臺的配套工程PCIe、電源和散熱如果模型規(guī)模到了 32B 以上單卡 24GB 就不太夠了這時候需要雙卡方案。但雙卡不是簡單插兩張卡就行配套工程才是大頭。PCIe 通道分配是最容易翻車的點。兩張 GPU 要跑的順至少需要各 x8 通道。很多消費級主板的第二個 PCIe 插槽只有 x4甚至?xí)?M.2 硬盤搶占通道。選主板時一定要看清楚 PCIe 拆分能力BIOS 里要有 Bifurcation 選項能設(shè)成 x8/x8 或 x16/x16。專業(yè)工作站主板通常沒這個煩惱但消費級平臺就得認真查。電源余量也直接決定系統(tǒng)穩(wěn)不穩(wěn)定。按雙 3090 估算單卡滿載約 350W兩卡 700W加上 CPU 150-200W、主板內(nèi)存硬盤風(fēng)扇等 100W穩(wěn)態(tài)負載就到 1000W 左右而 GPU 瞬間功耗還可能沖到峰值所以電源建議直接上 1300W-1600W 白金或者以上別在這種地方省預(yù)算。散熱方面這就是 openrig 的形態(tài)優(yōu)勢了。開放式機架設(shè)計最大的好處就是風(fēng)道短、通風(fēng)量大GPU 的熱量不會被悶在機箱里反復(fù)循環(huán)。我用下來整機溫度比普通塔式機箱低 10 度左右滿載運行也不會因為熱降頻。如果接受不了開放機架的噪音退一步也要選前進后出的塔式大機箱加高風(fēng)壓風(fēng)扇。3. 推理引擎Ollama、vLLM 和 llama.cpp 怎么排兵布陣同樣的硬件不同推理引擎跑出來的效果差很多。這個部分往往被低估很多人裝好 CUDA 直接就跑根本沒考慮過引擎選型的問題。3.1 Ollama五分鐘跑起來適合原型驗證Ollama 是目前最不容易出錯的選擇一條命令裝好一條命令拉模型一條命令起服務(wù)。對新手來說它是絕佳的切入點。# 安裝 Ollama curl -fsSL https://ollama.com/install.sh | sh # 下載一個 14B 模型 ollama pull qwen2.5:14b-instruct # 讓服務(wù)監(jiān)聽所有網(wǎng)卡方便局域網(wǎng)內(nèi)調(diào)用 export OLLAMA_HOST0.0.0.0:11434 ollama serve啟動之后它默認提供一個 OpenAI 兼容接口這意味著你現(xiàn)有的很多代碼可以無縫切換。我用 Python 的 openai SDK 測試過只需要把 base_url 指到本地就能直接調(diào)通from openai import OpenAI client OpenAI( base_urlhttp://openrig.local:11434/v1, api_keyollama, ) resp client.chat.completions.create( modelqwen2.5:14b-instruct, messages[{role: user, content: 幫我總結(jié)這段日志}], temperature0.2, ) print(resp.choices[0].message.content)但 Ollama 也有短板它對單用戶場景優(yōu)化得不錯卻不太擅長高并發(fā)。多個請求同時進來時它默認是排隊串行處理吞吐量上不去所以適合原型驗證和輕量使用。3.2 vLLM并發(fā)吞吐才是生產(chǎn)環(huán)境的勝負手等 openrig 要正式接團隊需求的時候我換成了 vLLM。這個引擎有兩大核心優(yōu)化PagedAttention 和 Continuous Batching。前者把 KV cache 按頁管理讓顯存利用率大幅提升后者則允許請求動態(tài)插隊新請求不用等前面所有請求結(jié)束就能開始處理。治本的辦法是啟動時留出足夠的 KV cache 空間或者調(diào)低--max-model-len。根據(jù)我的經(jīng)驗24GB 單卡上跑 14B 模型max-model-len設(shè) 8192 比較穩(wěn)如果非要 32K 上下文就得把量化精度降到 Q4 或者換更大顯存的卡。6.5 模型加載像蝸牛磁盤速度與 mmap 機制現(xiàn)象是每次啟動服務(wù)模型加載要等好幾分鐘第一次請求遲遲不來。排查發(fā)現(xiàn)瓶頸根本不在 GPU而在磁盤。vLLM 默認使用 mmap 方式映射模型文件如果你把模型放在機械硬盤上讀取 10 多 GB 文件的耗時非?？捎^。llama.cpp 也有類似邏輯它會通過 mmap 按需加載頁面。解決辦法很簡單模型文件必須放 NVMe SSD 上機械硬盤完全不合格。另外啟動后可以先發(fā)一個最簡單的請求做預(yù)熱讓權(quán)重真正進入顯存后續(xù)請求的響應(yīng)速度會明顯提升。7. 寫在最后一套機架換來的可控性把 openrig 從一張零散清單變成穩(wěn)定運行的推理服務(wù)之后我最大的體會是本地推理的價值不在跑分而在于它把模型變成了自己的基礎(chǔ)設(shè)施。API 再怎么便捷數(shù)據(jù)始終在別人手里而這套機架一旦轉(zhuǎn)起來你隨時可以在上面做 RAG、跑 Agent、微調(diào)模型想怎么折騰都行。如果你也準備搭這么一套我的建議是先拿 Ollama 把 14B 模型跑通再決定要不要上 vLLM 和雙卡。先用最小成本確認需求再逐步擴建這條路最穩(wěn)妥。后面我還會繼續(xù)開放 openrig 的配置模板和調(diào)參記錄包括 RAG 接入和工具調(diào)用編排的部分有興趣的可以持續(xù)關(guān)注。