「我們需要多少算力?」是多數企業第一次評估 AI 專案時,最常卡住、也最常被亂猜的一個問題——猜太少,專案跑到一半才發現硬體不夠;猜太多,多花的預算可能是好幾十萬。這篇提供一套實用的估算方法,不需要工程背景,照著幾個問題回答,就能大致抓出合理的算力需求區間。
先講結論:算力需求規劃不是從「我想要多強」出發,而是從「模型多大、多少人用、多常用」這三個變數反推。先抓對數量級(是單卡等級還是多卡叢集等級),比一開始就追求精確數字重要得多。
第一步:確認你要跑的模型規模
模型的參數規模(通常以 B 為單位,代表十億參數)是決定硬體需求最直接的因素。概略對應關係:
- 7B 到 13B 模型——推論用單卡(H100 80GB)綽綽有餘,輕量微調也能在單卡上完成
- 30B 到 70B 模型——推論建議雙卡起跳,全參數微調通常需要四卡以上
- 100B 以上模型——訓練需要八卡叢集甚至多節點架構,推論也建議多卡分散負載
如果你還不確定要用多大的模型,一個實用的原則是:先從能滿足需求的最小模型開始,而不是一開始就衝最大規模。多數企業應用場景(客服問答、文件摘要、內部知識庫),中小規模模型搭配適當的提示工程或檢索增強(RAG),效果往往已經足夠,不需要動用最頂級的巨型模型。
算力需求規劃,跟採購一套系統的邏輯很像
不熟悉 AI 技術的管理階層,可以用一個熟悉的類比來理解算力需求規劃:就像採購一套企業 ERP 或 CRM 系統,你不會先問「系統要多強」,而是先問「有多少使用者、要處理多少筆資料、尖峰時段的交易量多大」,再回推需要的伺服器規格與資料庫容量。算力規劃的邏輯完全相同——先定義清楚要解決的問題與使用規模,硬體規格是被這些需求推導出來的結果,不是憑感覺先決定一個「聽起來很強」的規格,再回頭找理由說明為什麼需要它。
第二步:算清楚訓練 vs 推論,需求完全不同
這是最容易被忽略、卻影響最大的變數。訓練(尤其是全參數訓練)是一次性、高強度的算力消耗,需要在有限時間內完成大量運算,通常需要多卡甚至叢集;推論(把訓練好的模型拿來實際使用)則是持續性、依用量規模的負載,單次運算量遠小於訓練,但因為要長期在線提供服務,考量的重點變成併發量與延遲,而不是原始算力峰值。企業常犯的錯誤是拿訓練等級的算力規劃邏輯,去套用在只需要推論服務的場景上,結果規格買得過大,長期租金浪費。
第三步:估算使用規模——多少人、多常用
如果是內部工具(例如員工使用的內部知識庫問答),同時在線人數與查詢頻率通常有限,單卡或雙卡的推論服務就能應付;如果是對外服務(例如客服 API、產品內建的 AI 功能),使用者規模可能是數千甚至數萬,需要考慮併發請求數與尖峰流量,規劃時要抓「尖峰負載」而不是「平均負載」,否則系統在流量高峰時容易回應緩慢甚至當機。
算力需求快速對照表
| 使用情境 | 建議起始規格 | 參考月租 |
|---|---|---|
| 個人研究、小規模實驗 | MIG 1/4 卡 | NT$15,000 起 |
| 7B–13B 模型推論/輕量微調 | 單卡(80GB) | NT$50,000 起 |
| 30B–70B 模型推論、雙服務分流 | 雙卡 | NT$100,000 起 |
| 70B 模型全參數微調 | 四卡 | NT$200,000 起 |
| 大型模型訓練、叢集節點 | 八卡 | NT$350,000 起 |
估算完之後,一定要拿真實流量驗證
前面三個步驟能幫你抓出一個合理的起始區間,但紙上估算終究是估算,實際部署後的真實表現,才是最終該依循的依據。建議在正式簽長約之前,先用時租或短期方案做一輪壓力測試——模擬預期的併發使用情境,實際觀察回應延遲、系統穩定性,以及達到什麼樣的使用量會開始出現效能瓶頸。這個驗證步驟能幫你確認估算方向對不對,也能在真正上量之前,提早發現規格不足或架構設計上的問題,調整成本遠低於正式上線後才發現問題。
第四步:預留成長空間,但不要一次買到位
企業導入 AI 的用量,幾乎都是隨著應用成熟度逐步成長的,很少一開始就能準確預測一年後的實際用量。比較務實的做法是先用能覆蓋現階段需求的最小規格起步,搭配可以隨用量成長逐步升級的租用方案,而不是為了「以防萬一」一開始就租最大規格——多花的預算在專案初期驗證階段,往往是不必要的沉沒成本。多數 GPU 主機服務商支援合約期間內升級規格並延續原有折扣,善用這個彈性,比一次到位更划算。
一個實際案例:從零開始估算
假設一家中型企業想導入內部客服 AI,情境設定是:公司內部約 200 名員工會使用,尖峰時段預期同時在線 20 到 30 人,問答內容以公司內部規章與產品文件為主,不涉及極端複雜的推理任務。照前面三個步驟走一遍:第一步,模型規模——這類任務不需要最頂級的巨型模型,搭配檢索增強(RAG)技術,7B 到 13B 等級的開放權重模型通常就能達到不錯的效果,不需要衝到 70B 以上;第二步,訓練還是推論——這是純推論場景,不需要規劃訓練等級的算力;第三步,使用規模——20 到 30 人同時在線的推論負載,單卡(80GB)搭配良好的服務架構設計,通常足以應付。整體規劃下來,這個情境的起始規格可能只需要單卡月租等級,而不是很多企業一開始直覺會想到的多卡叢集規模。這個案例的重點不是數字本身,而是示範怎麼把抽象的「我們需要算力」拆解成具體、可回答的問題。
常見的估算錯誤
企業在自行估算算力需求時,常見的幾個誤區包括:只看模型參數規模,忽略了實際的資料量與批次大小(同樣的模型,資料量越大,顯存需求也會增加)、把訓練跟推論的需求混為一談(如前面提到,兩者的規劃邏輯完全不同)、忽略了併發使用的疊加效應(單一使用者測試順暢,不代表十個人同時使用也順暢)、以及沒有預留除錯與實驗的緩衝資源(開發過程中的除錯、調參,同樣會佔用算力,不能把 100% 的規劃容量都算給正式上線服務)。
常見問題
不確定要用多大的模型,該怎麼開始估算?
建議先從能滿足核心需求的最小模型開始測試,實際跑過之後再依效果與延遲表現決定是否需要升級到更大的模型,不需要一開始就假設要用最大規模的模型。
推論服務要怎麼估算需要幾張卡?
主要看併發請求數與可接受的回應延遲,同一張卡能同時處理的請求數有上限,超過負載會拖慢回應時間。建議先用小規格上線,實際觀察流量模式後再依尖峰負載調整規格。
算力需求估算錯了,後續調整麻煩嗎?
多數 GPU 主機服務商支援合約期間內升級或調整規格,不需要重新簽約,操作上相對單純。先用保守規格起步、視需要擴充,通常比一開始就過度規劃更有效率。
企業自己沒有技術背景,估算容易出錯怎麼辦?
可以把你的應用場景(要跑什麼任務、預期使用人數、資料量大小)告訴有經驗的 GPU 主機服務商,由對方協助估算合適的規格,通常比自己從零開始學習估算方法更有效率。
訓練跟推論可以用同一套硬體規格嗎?
技術上可以,但不建議長期這樣配置——訓練是高強度間歇性負載,推論是持續性負載,混用同一套資源容易互相排擠,尖峰訓練時可能拖慢正式服務的回應速度,建議依用途分開規劃。
延伸閱讀
戰國策 GPU 主機・戰國策 AI 伺服器
不確定該租多少算力?讓有經驗的團隊幫您評估:NVIDIA H100 GPU 主機台灣機房直供,從 MIG 切分卡到八卡叢集,依實際需求彈性調整。