GPU 雲伺服器怎麼選？訓練與推理算力選型與避坑指南

GPU 雲伺服器怎麼選？答案取決於你跑的是訓練還是推理，更取決於你最可能先撞上哪一堵牆。最常見的誤判是照著算力排行榜買卡，結果模型載入到一半才發現視訊記憶體差一截。在絕大多數深度學習任務裡，視訊記憶體比浮點算力更早成為瓶頸——本文把訓練和推理兩條選型邏輯分開講，再補上精度換算、CPU/網路配套、CUDA 相容、競價實例和多卡擴充套件，最後給你一套自己能動手的估算方法。

先分清：訓練和推理要的從來不是同一種卡

訓練和推理跑的是同一個模型，但瓶頸幾乎相反。把這一點想清楚，能省掉一半的試錯。

• 訓練瓶頸在算力與視訊記憶體頻寬：滿負荷矩陣乘，GPU 利用率常年在 90% 以上，並行度決定吞吐
• 訓練要裝下最佳化器狀態：全參微調除權重外還要存梯度和動量，視訊記憶體佔用通常是純推理的 5–8 倍
• 訓練對卡間通訊極敏感：多機訓練有相當比例的時間花在 all-reduce 上，互聯質量直接決定有效算力
• 訓練可容忍中斷：有 checkpoint 就能續，適合放在競價實例上
• 推理瓶頸在視訊記憶體容量與頻寬：單請求解碼本質是「把權重讀一遍」的記憶頻寬問題，不是算力問題
• 推理看併發與每卡吞吐：同樣的總 QPS 下，一張大視訊記憶體卡往往比多張小卡更省、更好運維

一句話概括：訓練買算力，推理買視訊記憶體和頻寬。 用錯方向最典型的情況是推理服務買了 8 張訓練卡，其實瓶頸是併發時的 KV cache，視訊記憶體不夠；或者團隊為了一次 7B 微調租了 8 卡 H100，其中 6 張在等通訊。

視訊記憶體是第一道牆：算力過剩之前你就撞滿了

把 OOM 出現的順序看清楚，就知道該買多少視訊記憶體：

1. 推理第一步：模型權重載入不進視訊記憶體。換卡，或者只能換更小的模型、更短的上下文
2. 推理第二步：權重放得下，KV cache 撐不住。表現為併發上不去，或長上下文請求被截斷
3. 訓練第一步：最佳化器狀態放不下。被迫上 ZeRO / FSDP 分片，step 時間通常上升 30%–60%
4. 訓練第二步：啟用值吃滿。被迫開 gradient checkpointing，用算力換視訊記憶體，單步時間再漲 20%–40%

另一個常被忽略的量是有效視訊記憶體頻寬。單流解碼速度的物理上限大致是：視訊記憶體頻寬 ÷ 權重體積。7B 模型 FP16 權重約 14GB，落在 2TB/s 級頻寬的卡上，理論上限約 140 token/s，落到 80–120 token/s；落在 1TB/s 級的消費級卡上，理論上限約 70 token/s，實測常在 40–60 token/s。同樣的模型，跨一個頻寬檔位，體驗差一倍——但視訊記憶體容量是及格線，頻寬才決定速度。

GPU 型別對照：資料中心卡、消費級卡、推理卡

消費級卡便宜，但有四個硬限制，選型時要明確知道：

• 無 ECC 視訊記憶體：長時間訓練可能積累無法察覺的資料錯誤，表現為訓練 loss 莫名發散
• 多數型號沒有 NVLink：多卡只能走 PCIe，通訊頻寬可能差近 20 倍
• 不支援 MIG：無法把一張物理卡切成多個實例分給不同租戶，多租戶服務很難做
• 虛擬化與企業支援需額外授權：商用多租戶場景要確認許可成本

精度怎麼改寫賬：FP32 / FP16 / BF16 / INT8 / INT4

精度是你手上最有效的「視訊記憶體摺扣旋鈕」，也是最容易踩坑的一環。先看它對視訊記憶體的直接影響：

速度上，Ampere 及以後的卡在 Tensor Core 上 FP16 與 BF16 吞吐基本一致（所以選 BF16 不損失效能，只損失一點舊卡相容性）；INT8 通常是 FP16 的 1.5–2 倍，INT4 在 Ampere 上可達 2–4 倍。但端到端不會線性加速：訪存、kernel 支援和反量化開銷會吃掉一部分，實測常見收益是 1.3–1.8 倍，不是理論值。

• 精度換視訊記憶體是線性且可靠的，因為權重體積直接按位元組數縮放
• 精度換速度不是線性的，取決於你的模型形狀、batch 與 kernel 覆蓋率
• 訓練不要用 INT8/INT4：最佳化器狀態、梯度尺度和小更新量在高動態範圍下容易出問題

量化對效果的影響要分情況：INT8（對稱/分組量化）在大多數任務上指標波動在 0.5% 以內，可以放心上生產；INT4（GPTQ、AWQ）要按任務測，程式碼生成、長鏈推理和數學題掉點明顯，而閒聊、分類、檢索類任務基本無感。量化前一定要在自己的評測集上跑一遍。

算一遍你自己的視訊記憶體：拿模型估一次

下面三個公式能覆蓋絕大多數場景，先套公式得出下界，再加 20%–30% 餘量，這就是你的目標視訊記憶體。

• 7B 推理 FP16：7×10⁹ × 2 位元組 = 14GB 權重 → 含預留約 17GB → 24GB 卡可跑，16GB 卡必須 INT8 或砍上下文
• 7B 推理 INT4：約 3.5GB 權重 → 起步 4.5GB → 一張 16GB 卡能扛幾十路併發
• 70B 推理 FP16：140GB 權重 → 單卡無解 → 2×80GB 做張量並行（TP=2），或 141GB 卡勉強裝下但沒空間給 KV cache
• 7B LoRA 微調 BF16：權重 14GB + 少量最佳化器狀態 + 啟用 → 24GB 卡開 gradient checkpointing 能跑，40GB 更寬裕
• 7B 全參微調 Adam：7×10⁹ × 16 位元組 = 112GB → 至少 2×80GB；ZeRO-3 分攤到 4×40GB 也能跑，但通訊開銷會明顯拉長單步時間

推理側還必須單獨算 KV cache，這是長上下文場景真正的隱形殺手：

• Llama-2-7B（32 層、hidden 4096、無 GQA）：每 token 約 512KB，4K 上下文單請求約 2GB，32 併發就要 64GB
• Llama-3-8B（32 層、GQA 8 個 KV head）：每 token 約 128KB，4K 上下文單請求約 0.5GB
• 結論：同樣權重體積，GQA 讓你在相同視訊記憶體上把併發翻數倍。評估服務容量時一定要把這個乘進去

還有一個高頻翻車點：batch size 不是線性縮放視訊記憶體。線性層和啟用值是線性增長，但 PyTorch 預設會盡量複用視訊記憶體，Attention 內部的中間張量是平方級增長。序列長度從 2K 提到 8K 時，啟用值視訊記憶體增長可能超過 4 倍。如果你的任務是長序列訓練，先按 8K 上下文算視訊記憶體，而不是按預設 512。

別隻看 GPU：CPU、主存、儲存與網路怎麼配

GPU 決定上限，配套決定你能用到幾成。很多「GPU 很便宜」的機器，實際利用率上不去，就是因為這裡沒配對。各機型的視訊記憶體、CPU/記憶體配比與可選卡型，見 GPU 雲伺服器。

• CPU：資料載入、解壓、增強都是 CPU 密集工作。每張 GPU 配 4 vCPU 是底線，2 vCPU 的機器會讓 GPU 餓著，實測利用率常掉到 50%–70%
• 主存：至少裝得下正在讀的資料分片。經驗值是主存 ≥ 全部 GPU 視訊記憶體之和，並配合 pinned memory 加速主機到視訊記憶體的複製
• 儲存：本地 NVMe 順序讀通常 1–2GB/s；直接從物件儲存讀要靠高併發堆吞吐，單流往往只有幾百 MB/s。做法是先把資料同步到本地 NVMe 再開始訓練
• 網路：單機內網至少 10Gbps 起步。多機訓練看網絡卡是不是 100Gbps RDMA（InfiniBand / RoCE）——用 25Gbps 共享網絡卡做梯度同步，往往比單卡算力還慢

推理側的重點不一樣：多併發請求下，CPU 負責解 token 後的排程、預處理和批處理合併。建議讓 vLLM / SGLang 這類框架跑在 CPU 核數充足的機型上，再疊一張或幾張大視訊記憶體推理卡——GPU 少而 CPU 足的組合，對小模型高併發場景往往比堆卡更划算。

NVLink 與 PCIe：多卡訓練時差距有多大

NVLink 3 的頻寬約是 PCIe 4.0 的 18–19 倍，這個差距在張量並行裡會被放大：每一層前向和反向都要做 all-reduce，通訊量隨層數線性增長。通訊走 PCIe 時，通訊時間可能吃掉 30%–60% 的單步時間，你的卡貴了一倍，有效算力反而沒提升。

• 單卡任務：互聯無所謂，直接選視訊記憶體和算力都夠用的型號
• 2–8 卡訓練：優先同節點 NVLink / NVSwitch 機型，這是訓練卡價格溢價的主要來源
• 跨節點：張量並行留在節點內，跨節點用資料並行，或用流水線並行把計算切開
• 消費級多卡：先跑 nvidia-smi topo -m 看拓撲。顯示 PIX（走 PCIe）還是 NV#（走 NVLink），吞吐可能差幾十個百分點

CUDA 與驅動相容：最容易翻車的一環

規格選對了但跑不起來，多半是軟體棧的問題。簽約前把這幾件事問清楚，比事後 debug 划算得多。

• 驅動向後相容，但框架往往要求較新驅動：CUDA 12.x 執行時一般需要 r525 或更高版本的驅動
• PyTorch 官方 wheel 自帶 CUDA 執行時，容器裡的系統 CUDA 版本要和 wheel 匹配，不是升驅動就行
• cuDNN 與 NCCL 要對齊：列印不出 torch.cuda.nccl.version() 通常就是 NCCL 沒裝對，多機訓練會掛在初始化階段
• 架構支援是硬門檻：Turing 無 BF16，Hopper 起才有 FP8，Blackwell 起才有 FP4。新卡配老框架可能要原始碼編譯擴充套件
• 典型報錯 CUDA driver version is insufficient for CUDA runtime version，幾乎都是驅動或映象混裝問題，不是程式碼 bug

自己驗證只要一條命令：nvidia-smi 看驅動和識別到的卡，python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.is_available(), torch.cuda.get_device_capability())" 看框架側是否就緒，再跑一次 NCCL 的 all-reduce 微基準（nccl-tests）確認通訊正常。十臺機器裡有一臺通訊慢，你都會是那個倒黴的使用者，所以要逐臺驗，不要抽樣。

競價 GPU：把訓練成本打到按需的幾分之一

競價實例（Spot / 搶佔式）常見的折扣區間是按需價格的 1/3 到 1/10，具體以官方實時報價為準。對訓練這種「可重入」的負載，這是最直接的省錢手段。除了競價，計費模式本身就決定了長期賬單，五類配置的價位區間見 雲伺服器價格指南。

• 適合：超參搜尋、批次資料標註、離線評測、checkpoint 間隔不超過 15 分鐘的訓練
• 不適合：線上推理服務、不可中斷的長訓練、狀態存在本地且沒有外部備份的任務
• 多卡必須放在同一臺實例上：回收時整組一起釋放。否則被回收後剩下 1/4 的卡繼續計費，「長尾殘留」是競價實例最常見的隱形浪費
• 訓練指令碼要做到可重入：定期儲存 checkpoint，框架側通常有自動捕獲和恢復的選項（如 PyTorch 的 elastic 模式）

資料也要跟著這個思路設計：資料集放物件儲存（不要放在會被一起回收的實例本地盤），checkpoint 同步寫回物件儲存。這樣任意時刻實例消失，你最多損失 15 分鐘的計算進度，而不是一整晚。

多卡擴充套件怎麼選：資料並行到流水線並行

選擇順序其實很固定，按「視訊記憶體不夠的原因」從上往下走：

1. 權重和最佳化器裝不下 → ZeRO-3 / FSDP，視訊記憶體隨卡數近似線性下降，通訊開銷可接受
2. 單層權重灌不下（通常 70B 以上）→ 張量並行，把每層權重切到多張卡，必須同節點 NVLink
3. 卡數超過單機容量 → 流水線並行，按層切分，配合 Slurm 或 Kubernetes 排程層
4. 引數規模還想繼續漲 → MoE 把引數稀疏化，視訊記憶體壓力下降，但負載均衡和 All-to-All 通訊是新的坑

推理側的多卡思路不一樣，通常優先張量並行把一個大模型塞進節點，再用多副本橫向擴，而不是資料並行——推理沒有梯度同步，資料並行的收益遠不如訓練場景。vLLM / SGLang 裡對應的是 --tensor-parallel-size 與 --data-parallel-size 的組合。

選型避坑：最常踩的 8 個坑

1. 只看 TFLOPS 不看視訊記憶體——最常見的誤判，直接導致 OOM 或被迫上分片
2. 預設消費級卡能扛生產——無 ECC、無 MIG、許可受限；長訓練有靜默錯誤風險，商用要確認
3. 忘了算 KV cache——短上下文測試透過，上線後長上下文直接打滿，擴容又來不及
4. 多卡只寫卡數不看拓撲——nvidia-smi topo -m 裡是 PIX 還是 NV#，差別是幾十個百分點的吞吐
5. 混裝不同代際的卡——最慢的一張決定所有集合通訊速度
6. 用競價實例跑線上推理——回收時服務直接掛，且沒有優雅下線的視窗
7. 一上來就籤長約——先按小時計費跑通真實負載，拿到 step 時間或 tokens/s 的實測值再轉長約
8. 忘記 checkpoint 與資料備份——GPU 故障、誤刪實例、資料丟失的恢復成本遠高於一個月的實例費用

這八條裡，前四條與技術判斷有關，後四條更多是運維習慣。真正讓預算超支的通常是第 6 和第 7 條：該用便宜卡的用錯了、該籤長約的沒先測。

下一步：24 小時內驗證你的選型

選型不該靠猜。用下面五步，一個工作日就能拿到一個有實測資料支撐的決定。

1. 量視訊記憶體峰值：在現有環境跑 50 步訓練或 100 個推理請求，記下 nvidia-smi 裡的最高佔用和框架的 max_memory_allocated
2. 算出下界：用第 4 節的公式算權重 + 最佳化器 + KV cache，再加 20%–30% 餘量，得到目標視訊記憶體
3. 篩出 2–3 個候選型號：對照 GPU 型別表，核對 CUDA 驅動、映象裡的 PyTorch 版本和是否支援 NCCL
4. 按小時開一臺最小規格：跑 30 分鐘真實負載，記錄單步時間（tokens/s）和總時間，換算成「每小時訓練成本」或「每百萬 token 成本」
5. 把結論寫成對比表再籤長約：訓練主體用競價 + 末段切按需，推理用按需 + 長約混合，兩種模式的賬要分開算

需要按你自己的模型和併發量算一遍，把引數量、精度、上下文長度、併發數、是否全參微調發過來，我們可以給出候選規格區間和視訊記憶體估算；GPU 的具體報價以官方實時報價為準，不同區域和機型差異較大。