用於推論的 AWS GPU 執行個體：如何選擇運算資源
分享這篇文章：
為推論工作負載配置最新、最強大的 GPU 執行個體的直覺通常是錯誤的，而這也是我看到團隊在 AWS 上犯下最昂貴的錯誤。使用以 H100 GPU 為核心打造的 P5 執行個體來服務一個 G6 執行個體就能輕鬆處理的模型，並不會在規模化時帶來更好的延遲表現，只是在你的工作負載根本不需要的運算資源上浪費預算。適合推論的執行個體取決於兩件事：你的模型記憶體占用量，以及在真實流量下的實際延遲與並行需求，而不是哪一代加速器最新。
將執行個體系列與記憶體需求相匹配，而非盲從炒作
VRAM 上限是第一道篩選條件，會立即排除大部分的決策空間。G5 執行個體以配備 24GB 記憶體的 A10G 為核心，能輕鬆處理較小型模型，並在推論的中階價格區間中具備優勢。一旦模型權重與 KV 快取超過單張 G5 GPU 可承載的範圍，通常下一步就是採用 G6e；G6e 以配備 48GB 的 L40S 為核心。具體來說，當你已經調整過批次大小與量化之後，負載下的 p95 延遲仍然是主要限制因素時，G6e 才是正確選擇，而不是在此之前。大約超過 40十億參數後，就無法避免升級到 P4d；P4d 建構於具備 NVLink 的 A100 之上，用於張量平行服務。在規劃時，有一個必須知道的硬性下限：最小的 P4d 規格是 24xlarge，包含八張 GPU，沒有更小的選項。如果你對於 30B 模型只需要一張 GPU 的容量，那麼無論該模型是否需要其記憶體頻寬，P4d 都不適合，因為你是在為八張 GPU 付費，卻只是為了取得單一工作負載所需的能力。
Inferentia2 是大多數團隊忽略的成本槓桿
Neuron SDK 的取捨
AWS 自家的基於 Inferentia2 的 Inf2 執行個體，對於 AWS Neuron SDK 支援的模型而言，提供該平台上最低的每次推論成本；inf2.xlarge 的運行成本大約比可比的 g5.xlarge 低 25%，而對於受支援的 Transformer 架構，在大規模使用時差距還會進一步擴大。限制是真實存在的，也值得坦誠說明：Neuron 需要編譯步驟，並且最適合已針對其調校的架構，特別是 Llama 系列、GPT-NeoX 以及 BERT 類模型。如果你的模型不屬於該受支援範圍，或者你經常在架構選擇上反覆迭代，那麼編譯與營運上的額外負擔目前還不值得。如果你是在真正的生產規模下運行受支援的架構，且一次性的編譯與工具投入可以分攤到數百萬次推論呼叫上，那麼相較於因慣性而繼續使用通用型 NVIDIA GPU，Inf2 通常能帶來更好的每 token 成本結果。
兩個會拖延上線時程的營運陷阱
GPU 配額預設為零
新的 AWS 帳戶一開始的 GPU vCPU 限制為零，而申請提高 P 系列或較大型 G 系列執行個體的配額，可能需要數個工作天處理。這是規劃時程上的問題，不是技術問題；這類細節會讓原本按時進行的上線，因為沒有人在基礎架構已建置完成並準備部署前申請提高配額，而變成等待一週。請在決定執行個體系列的當天就申請提高配額，而不是等到需要容量的前一天。
Spot 執行個體本身並不是一個服務層
Spot 容量可以將 GPU 成本降低 60% 到 70%，對於具備容錯能力、可檢查點保存的訓練或批次推論工作而言，是合理的選擇。但它不適合作為主要線上推論服務的預設方案，因為中斷風險與延遲 SLA 不相容；除非你已建立隨需備援路徑，能在請求處理途中失去 Spot 執行個體時吸收影響而不丟失流量。應將 Spot 視為疊加在具韌性服務架構之上的成本最佳化手段，而不是其替代品。
真正有效的決策順序
Size to VRAM first: know your model’s weight footprint plus realistic KV cache growth under your expected context lengths, and let that eliminate instance families before you look at a single price. Check Neuron SDK compatibility second, because if your architecture is supported and your volume justifies the compile overhead, Inferentia2 changes your cost baseline meaningfully. Request GPU quota increases as soon as the instance family is decided, not after the build is finished, since that delay is entirely avoidable and entirely common. Autoscale on GPU utilization and p95 time-to-first-token, not CPU, because CPU rarely bottlenecks a GPU-bound serving workload and autoscaling on the wrong signal means you scale too late or not at all. And pin your driver, CUDA, and inference server versions together using a known-good machine image rather than tracking “latest,” because an untested driver update landing silently in front of a production serving fleet is a self-inflicted outage waiting for a deploy window.
在 SIRAYA，最常發現這類問題的檢視方式其實很簡單：詢問為什麼某個工作負載會運行在目前的執行個體系列上，並確認答案是出於 VRAM 或延遲需求，還是只是上線時有人採用的預設選項，之後就再也沒有重新檢視。每次推論成本最低的團隊，並不是那些能使用最新硬體的團隊，而是那些根據實際工作負載進行規模配置，並隨著工作負載變化持續確認該配置仍然適用的團隊。