企業 AI 容量規劃：如何調整本地基礎設施規模

本地 AI 最昂貴的錯誤是購買錯誤的硬體。規模過大意味著數十萬美元的閒置計算。規模過小意味著性能瓶頸，破壞了本地的商業案例。與雲端不同，你無法通過配置更改來調整 GPU 集群的規模——你要訂購交貨期長達 8 到 16 週的硬體。

本指南介紹了結構化的容量規劃流程：盤點工作負載、計算計算需求、考量儲存和網路，以及規劃增長。目標是一個具體、可辯護的硬體建議——而非模糊的「買些 GPU」。

第一步：盤點你的 AI 工作負載

在選擇任何硬體之前，建立將在你的本地基礎設施上運行的每個 AI 工作負載的完整清單。這包括當前正在運行的工作負載（即使它們在雲端）和未來 18 個月內計劃的工作負載。

對每個工作負載，記錄：

欄位	示例值	為何重要
工作負載名稱	客服聊天機器人	識別
類型	推理	決定 GPU 使用模式
模型	Llama 3.1 14B（Q4 量化）	決定 VRAM 和計算需求
每日請求數	50,000 次查詢	決定吞吐量需求
峰值 QPS	每秒 15 次查詢	決定並發 GPU 實例
平均輸入令牌數	800 個令牌	影響延遲和吞吐量
平均輸出令牌數	400 個令牌	影響延遲和吞吐量
延遲要求	首個令牌低於 3 秒	決定所需 GPU 等級
資料敏感性	高（包含客戶 PII）	確認本地需求
可用性需求	99.9%（每年 8.7 小時停機）	決定冗餘需求
增長預測	12 個月內翻倍	決定餘量

將此清單建立為試算表。它成為所有後續規模調整決策的基礎。

常見差距： 組織盤點其主要工作負載，但忘記了支援工作負載。基於 RAG 的聊天機器人不只需要推理計算，還需要：

文件攝入的嵌入生成（在 GPU 上運行）
檢索的重排模型（在 GPU 上運行）
向量資料庫（在 CPU 上運行，需要快速儲存）
文件處理管道（混合 CPU/GPU）

這些都消耗必須規劃的資源。

第二步：計算計算需求

VRAM 規模調整

VRAM（GPU 記憶體）通常是關鍵約束。模型必須裝入 VRAM 才能運行——沒有優雅的降級，只有加載失敗。

按大小和量化的模型 VRAM 需求：

模型大小	FP16（無量化）	INT8	INT4 (GPTQ/AWQ)
70 億參數	約 14 GB	約 7 GB	約 4 GB
140 億參數	約 28 GB	約 14 GB	約 8 GB
320 億參數	約 64 GB	約 32 GB	約 18 GB
700 億參數	約 140 GB	約 70 GB	約 35 GB

這些數字只代表模型權重。在推理時，你還需要 VRAM 用於：

KV 緩存： 隨上下文長度和批次大小擴展。對於處理 8 個並發請求的 8K 上下文 14B 模型，額外增加約 4 到 8GB。
激活記憶體： 通常 1 到 3GB，取決於批次大小。
框架開銷： PyTorch、vLLM 或 TensorRT-LLM 各自增加 1 到 2GB 的基準記憶體。

經驗法則： 在模型權重大小之外預留 30% 到 40% 的 VRAM 餘量。需要 8GB 重量儲存的 14B INT4 模型應規劃為總共 11 到 12GB 的 VRAM 使用量。

吞吐量規模調整

計算你需要多少 GPU 實例來服務你的目標每秒查詢數（QPS）：

測量單實例吞吐量。 對於 L40S 上的 14B INT4 模型，每個 GPU 預計約每秒 70 到 110 個令牌。平均輸出 400 個令牌，即每個 GPU 每秒大約 0.17 到 0.28 個請求。
計算所需實例數。 如果你的峰值 QPS 是 15，而每個 GPU 處理每秒 0.2 個請求：15 / 0.2 = 75 個 GPU？不——這個計算是針對順序生成的。使用批次推理（vLLM、TensorRT-LLM），單個 GPU 可以服務 4 到 8 個並發請求，每個請求的吞吐量降級最小。實際容量：14B 模型帶批次處理每個 GPU 每秒 1 到 2 個請求。
添加餘量。 目標是峰值時 60% 到 80% 的 GPU 使用率，而非 100%。在 100% 使用率時，任何流量突增都會導致延遲降級。對於上面的例子：15 QPS / 每個 GPU 1.5 QPS / 0.7 使用率目標 = 約 14 個 GPU。

GPU 使用率目標

不要規劃 100% 的 GPU 使用率。原因如下：

目標使用率	含義
90-100%	沒有餘量。任何突增 = 延遲降級或請求丟棄。
70-80%	健康的生產目標。處理流量的正常變化。
50-60%	保守。適用於有嚴格 SLA 的關鍵工作負載。
低於 50%	可能過度配置。考慮更小的硬體或整合工作負載。

使用率也取決於工作負載模式。有峰值時間（上午 9 點到下午 5 點）的面向客戶的聊天機器人，即使峰值達到 70% 到 80%，平均使用率也在 30% 到 40%。全天候運行的內部文件處理管道可以持續維持 70% 到 80%。

第三步：考量儲存需求

GPU 計算受到所有關注，但容量規劃最常出問題的是儲存規劃。

儲存類別

模型權重

每個模型版本都需要儲存。14B FP16 模型約 28GB。如果你保留 5 個版本（當前 + 4 個回滾版本），每個模型 140GB。乘以你服務的模型數量。

訓練資料集

如果你在本地進行微調，訓練資料需要快速儲存。大小差異很大：

文本微調資料集：通常 1GB 到 50GB
RAG 的文件語料庫：10GB 到 1TB 以上
圖像/多模態資料集：100GB 到 10TB 以上

模型檢查點

在微調期間，定期保存檢查點。14B 模型的完整檢查點約 28GB。如果你在 5,000 步訓練運行中每 500 步保存一個檢查點，那就是 10 個檢查點 × 28GB = 每次訓練運行 280GB。如果不清理，檢查點會迅速積累。

向量資料庫

RAG 工作負載需要向量儲存。粗略估計：100 萬個文件塊，具有 1,536 維嵌入，需要約 6GB 的向量儲存，加上可能使原始大小翻倍或三倍的元資料和索引。

稽核日誌和遙測

每個推理請求和回應都應為了合規和監控而記錄。單個請求/回應對平均 2 到 5KB。在每天 50,000 個請求的情況下，每天 100 到 250MB，或每年 36 到 91GB。不是很大，但會累積，如果你需要即時稽核能力，就必須在快速可靠的儲存上。

儲存規模調整工作表

儲存類別	計算	示例
模型權重	模型數 × 版本數 × 大小	3 個模型 × 5 個版本 × 28GB = 420GB
訓練資料集	所有資料集之和	50GB + 200GB = 250GB
檢查點	每月運行數 × 檢查點數 × 大小	4 次 × 10 × 28GB = 1,120GB
向量資料庫	塊數 × 嵌入大小 × 3（開銷）	200 萬 × 6KB × 3 = 36GB
稽核日誌	每日請求數 × 大小 × 保留期	5 萬 × 3KB × 365 天 = 55GB
合計		約 1.9TB
含 50% 餘量		約 2.8TB

模型權重和活躍訓練資料使用 NVMe SSD——機械硬碟無法跟上 GPU 資料加載速度。典型配置是每個 GPU 伺服器配置 2 到 4TB NVMe 儲存，加上用於存檔儲存的更大 NAS 或 SAN（舊檢查點、歷史稽核日誌）。

第四步：網路需求

網路規劃取決於你是在運行多節點訓練還是僅推理工作負載。

多節點訓練

如果你在多台伺服器上訓練或微調模型（分散式訓練），你需要節點之間的高速互連。訓練期間的 GPU 通信是連續且延遲敏感的。

InfiniBand HDR（200 Gb/s）或 NDR（400 Gb/s）： 多節點 GPU 訓練的標準。每台伺服器需要一個 InfiniBand HCA，你需要一個 InfiniBand 交換機。成本：每台伺服器 5,000 到 15,000 美元 + 交換機 10,000 到 30,000 美元。
RoCE（基於匯聚以太網的 RDMA）： 使用帶有 RDMA 功能的標準以太網 NIC 的更便宜替代方案。大多數工作負載的性能是 InfiniBand 的 80% 到 90%。成本：每台伺服器 2,000 到 5,000 美元，使用現有網路交換機。

僅推理

如果你只運行推理（無分散式訓練），標準網路就足夠了：

25 GbE： 適用於大多數推理工作負載。無瓶頸地處理模型加載和客戶端請求/回應流量。
100 GbE： 如果你頻繁傳輸大型資料集或服務具有大型上下文視窗的非常高 QPS 時有用。

標準 1 GbE 對模型加載來說太慢（通過 1 GbE 加載 28GB 模型需要約 4 分鐘——對故障轉移場景來說是不可接受的）。

到客戶端的頻寬

計算推理服務為客戶端提供服務所需的頻寬：

平均回應：400 個令牌 × 約 4 字節/令牌 = 每個回應 1.6KB
在 15 QPS 時：每秒 24KB——可忽略不計
但逐令牌串流回應增加連接開銷：如果服務即時聊天介面，計劃 100 到 500 個並發 WebSocket 連接

客戶端頻寬很少是瓶頸，但連接數量可能是。確保你的推理伺服器（或其前面的負載平衡器）配置了足夠的並發連接數。

第五步：電力和冷卻

這是讓紙面上看起來很好的本地專案失敗的步驟。

電力需求

配置	GPU 功率	系統總計	所需電路
4 × RTX 4090 工作站	1,800W	約 2,500W	1 × 20A 208V
8 × L40S 伺服器	2,800W	約 4,000W	1 × 30A 208V
8 × A100 伺服器	3,200W	約 4,500W	1 × 30A 208V
8 × H100 伺服器	5,600W	約 8,000W	2 × 30A 208V 或 1 × 60A

在購買硬體之前，請與你的設施團隊確認：

伺服器機房/資料中心的可用電力容量。許多企業伺服器機房是為每機架 2 到 5kW 的基於 CPU 的伺服器設計的，而非每機架 8 到 15kW 的 GPU 伺服器。
電路可用性。 單個 8xH100 伺服器可能需要其專用電路。
UPS 容量。 你的不間斷電源必須處理 GPU 負載加上安全關機的運行時間。

冷卻需求

GPU 產生與其功耗成正比的熱量。每瓦 GPU 功率需要大約 0.3 到 0.5 瓦的冷卻能量（取決於 PUE——電力使用效率）。

配置	散熱量	冷卻方式
4 × RTX 4090	約 2.5kW	標準室內空調足夠
8 × L40S	約 4kW	建議排內冷卻
8 × H100	約 8kW	需要排內冷卻或後門熱交換器
16 × H100（2 台伺服器）	約 16kW	可能需要液冷或專用冷卻基礎設施

如果你的伺服器機房冷卻容量已達上限，添加 GPU 伺服器可能需要花費 2 萬到 10 萬美元以上的 HVAC 升級。在決定購買硬體之前，請檢查冷卻容量。

規模調整工作表

將所有內容整合到一個規模調整表中：

工作負載	模型	量化	QPS	VRAM/實例	所需 GPU 數	GPU 類型	儲存
客服聊天機器人	14B	INT4	15	12 GB	14	L40S	50GB 模型
文件處理	7B	INT4	5	6 GB	4	L40S	200GB 語料庫
嵌入生成	0.3B	FP16	50	2 GB	2	L40S	共享
重排	0.4B	FP16	50	2 GB	2	L40S	共享
每月微調	14B	FP16	不適用	80 GB（訓練）	4	A100 或 L40S	1.5TB 檢查點
合計					26 個 GPU		約 2TB NVMe

在這個例子中，3 到 4 台伺服器上的 26 個 L40S GPU 可以處理推理工作負載，微調工作負載要麼在非峰值時間共享同一硬體，要麼在專用的 4-GPU 伺服器上運行。

估計總成本： 4 台 8-GPU L40S 伺服器 × 79,000 美元 = 316,000 美元，加上儲存、網路和支援基礎設施：總計約 38 萬到 42 萬美元。

常見容量規劃錯誤

錯誤 1：購買 H100，而 L40S 就足夠了

H100 是最好的 GPU，但價格是 L40S 硬體的 4 倍。如果你的工作負載是推理密集型且模型低於 300 億參數，L40S 以 25% 的成本提供 80% 到 90% 的實際性能。H100 的優勢——HBM3 頻寬、NVLink、MIG——對大型模型訓練和多租戶推理最重要。如果你不做這些，你在為不會使用的能力付費。

錯誤 2：儲存規模過小

模型檢查點是最常見的儲存驚喜。單次微調運行可能產生 200 到 500GB 的檢查點。為「充足儲存」預算 2TB NVMe 的組織，在開始微調實驗幾週內就會發現空間不足。預算比初始計算建議多 2 到 3 倍的儲存。

錯誤 3：忽略電力和冷卻約束

硬體到達、上架，然後跳閘。或者伺服器機房溫度在幾小時內升至 35 攝氏度以上。在購買硬體之前，不是之後，始終與你的設施團隊確認電力和冷卻容量。

錯誤 4：不規劃多模型服務

大多數組織從一個模型開始，但很快擴展到服務不同用例的 3 到 5 個模型。如果你只為單個模型調整基礎設施規模，6 個月內就會超出容量。至少規劃你初始模型數量的 2 到 3 倍。

錯誤 5：按平均值而非峰值規模調整

平均 5 QPS 但在工作時間峰值達到 20 QPS 的工作負載，需要按 20 QPS 加餘量調整規模。按平均值調整意味著在使用最重要的時間段性能降級。

錯誤 6：忘記冗餘

如果你的 GPU 數量恰好能服務你的工作負載，失去單個 GPU 就意味著服務降級。對於 99.9% 以上可用性需求的工作負載，計劃 N+1 冗餘——每台伺服器至少一個備用 GPU，或可在維護或故障期間承載負載的備用伺服器。

規劃時間範圍：18 到 24 個月

GPU 集群不是可以輕易擴展的。向現有伺服器添加 GPU 可能不可行（取決於機箱），添加新伺服器需要採購、上架、佈線和配置，從決策到生產需要 2 到 4 個月。

為預計增長的 18 到 24 個月調整初始部署規模。第一年有 20% 的多餘容量，比等待硬體採購時面臨容量危機要好。

但不要嘗試預測超過 24 個月的需求。AI 硬體格局變化迅速——你兩年後會購買的 GPU 可能還不存在，工作負載模式也會隨著你的組織 AI 使用成熟而改變。

為你能看到的做規劃。為你看不到的預留空間。