硬體

推論硬體是一串容量有限、速度各異的資源，不是單一效能數字。Tensor Core 的吞吐量會限制長提示 prefill 與影音生成等運算密集工作；video random-access memory（VRAM）的容量決定 weights 及工作狀態是否放得下，而 VRAM 頻寬往往限制自回歸 decode。一旦模型跨越多個裝置，interconnect 頻寬與同步成本也會進入關鍵路徑。選硬體時，應先用符合正式流量形狀的測試找出真正飽和的階段與資源，再為該瓶頸配置容量。

把每個推論步驟想成輸送帶：數值先從某個儲存層取出，交給 compute unit 轉換，必要時再傳到另一個裝置。若輸送帶供應不了運算元，再快的計算單元也只能閒置。小型 cache 距離運算最近、速度最快；往 VRAM、主機記憶體與儲存空間移動時，容量逐層增加，但存取成本也跟著上升。平衡的系統會把最常使用的工作集合留在運算附近，並盡量減少穿越較慢邊界的次數。

假設要部署一個長提示、短回答的語言服務。第一步不是看哪張 GPU 的峰值最高，而是先用模型參數量與精度估算 weights，再加入最長預期序列、目標 concurrency 與 batch 需要的 key-value cache、activation 及 runtime buffer，確認尖峰情境仍有餘裕。第二步把 prefill 與 decode 分開測：前者處理整段提示，可能先吃滿 Tensor Core；後者逐 token 讀取 weights，可能先吃滿 VRAM 頻寬。算力較高但容量或頻寬較低的裝置，可能在第一個 token 路徑勝出，卻在持續生成時落後，甚至在長 context 下直接發生 out-of-memory（OOM）。最後要比較的是完整工作負載範圍：不同序列長度、concurrency 量與尾端延遲是否都在服務目標內，而不是規格表上的單一冠軍。

接著讓模型大到超過一個裝置。單一節點內，GPU 能經高速連線頻繁交換 partial result，因此需要每層同步的切分仍可能有效；跨到第二節點後，每次同步都要走較慢網路，累積成本可能抵銷新增算力。相同的八張額外 GPU 可以拿來擴大一個 replica，也可以建立另一個獨立 replica。只有模型容量、key-value cache 空間或單一請求延遲真的要求更多裝置時，擴大 replica 才有必要；若模型已能在一個節點內有效服務，橫向複製通常能避免跨節點同步並處理更多彼此獨立的請求。模型大小、cache 餘裕、流量 concurrency 與演算法通訊模式必須一起決定 topology，不能只依 GPU 數量。

硬體層級還會一路延伸到機架之外。手機適合在沒有網路往返的情況下處理小型、即時且隱私敏感的工作；工作站可能利用大型 unified memory 或高階獨立顯示卡執行個人模型；資料中心則能把高功率 accelerator、穩定散熱與標準化網路整合成可擴充服務。替代晶片也可能針對記憶體頻寬、能源效率或特定 dataflow 取得優勢。真正的工程問題不是哪一個位置或廠商絕對勝出，而是哪一段流程能在當地的算力、容量、持續散熱、電池、軟體支援矩陣與可得供應下可靠執行。混合系統還要定義能力偵測、資料邊界與 fallback，讓終端裝置不足或離線策略不適用時，可以平順轉到中央服務。

採購比較必須把完整 instance 標準化，不能只比晶片名稱。先找出能容納 weights 與服務 headroom 的最小 instance 形狀，將主機 CPU、主機記憶體、儲存、網路、GPU 外型與 interconnect 都列入，並在相同 driver、runtime、engine、precision 及請求分布下量 sustained performance。雲端標價也要換算成滿足延遲目標時的每秒有效 token 或每千次請求成本，不能用理論峰值除價格。接著記錄區域容量、啟動時間、可否預留、故障替換與 multi-instance 分割方式：小模型若只用到整張卡的一小部分，現代 GPU 的合適 slice 可能更有效；模型需要大量 burst 或 cache 時，完整裝置才保有彈性。供應不穩也會讓優秀 benchmark 失去意義，因為無法在需要的區域與時間取得足夠相同 topology，服務就不能可靠擴充。

每一層邊界都要設計故障處理。VRAM 空間不足時，系統要限制 admission、降低 batch、縮短 context 或選較小模型，不能等 OOM 讓 replica 崩潰；節點內連線或跨節點網路退化時，要能辨識同步延遲並改用較少通訊的配置，必要時把工作切回獨立 replica；終端裝置缺少支援、過熱、低電量或執行太慢時，要有明確雲端 fallback，同時維持使用者同意與資料邊界。監控也要能區分 Tensor Core 飽和、VRAM 容量壓力、memory bandwidth 停頓、interconnect 壅塞、thermal throttling、模型載入輸入輸出與普通 queueing，否則所有問題只會表現成「延遲變高」。硬體選型只有在這些退化模式可觀測、可限制並可恢復時才算完成。

為每次硬體決策保存可重查的紀錄：正式流量的輸入輸出與 concurrency 分布、weights 和 cache 的記憶體算式、裝置與節點 topology、完整 instance 規格、driver 與 engine 版本、各階段 benchmark、價格計算 benchmark、容量取得方式，以及被淘汰方案的原因。這份文件要明確寫出假設，例如目標 precision、最長 context、可接受 P99、預期 cache hit 與跨節點通訊量。當流量形狀、模型大小、精度、kernel、雲端供應或價格改變時，就重新執行相同測試，而不是延用舊結論。若只有局部假設改變，也要先重跑受影響的 phase，再用端到端負載確認沒有把瓶頸推到其他層；若供應商替換 instance 內的主機或網路配置，即使 GPU 名稱相同也視為新候選。也要把測試日期與版次保留在紀錄中，避免後來的讀者把歷史結果誤當成目前保證。硬體選型從來不是永遠正確的產品排行，而是在一組可驗證假設下成立的工程判斷。