NVIDIA AIPerf 將首 Token 延遲與 Token 間延遲列為不同推論指標，測量定義可見官方指標文件。
症狀：只看模型參數量選 GPU，部署後才發現延遲或併發不符合預期。
最快解法：先用目標模型、上下文長度、併發模式與延遲目標測試負載，再按有效吞吐與 GPU 利用率估算資源；早期或流量波動時先按需租用，負載穩定後再比較長期承諾或自建。
這篇適合正把模型從原型移到線上服務的工程師，也適合負責雲端預算的技術主管。關注 NVIDIA GTC Berlin 2026 的團隊，可用下文把大會資訊轉成可執行的算力評估計畫。
最後更新於 2026 年 10 月 10 日；會議安排依 NVIDIA GTC Berlin 官方 FAQ 核對，推論指標依 NVIDIA 官方文件核對。活動尚未舉行，因此不把未來發布或現場展示寫成已確認的算力結論。
先按服務情境界定 GPU 推論部署需求
運行一個大型語言模型服務要準備多少 GPU 算力，沒有脫離負載條件的通用答案。模型格式與量化方式會影響能否載入及所需記憶體；上下文長度影響輸入規模與快取需求；併發請求則可能增加記憶體壓力、排隊與延遲。只拿參數量對照硬體規格，無法回答服務是否達到你的目標。
先辨別負載型態，再決定測試方式：
- 離線批次處理：工作可排程，通常能接受較長完成時間。重點是總處理量、批次大小及工作能否中斷後續跑。
- 互動式應用：使用者等待回覆，首 Token 延遲與生成速度會直接影響體感；併發上升時也要觀察排隊。
- 持續在線 API：需要處理流量起伏與故障風險。除了平均需求，還要看實際尖峰、備援安排及閒置期間的資源成本。
這三種情境不能共用同一個估算值。若你還沒有生產流量紀錄，就先把服務等級、請求模式和可接受延遲寫成測試條件，不要先買或租設備再倒推需求。
離線驗證：確認模型能在目標環境運行
在做吞吐測試之前，先排除「模型根本無法按預期啟動」的問題。確認模型格式、推理框架與模型版本相容，也要核對 GPU 記憶體是否足以載入權重及執行推論所需的額外空間。使用 TensorRT-LLM 時，請以官方文件中的安裝、支援與執行說明核對實際環境，不要把框架支援某項功能等同於你的模型和部署配置必然可用。
記錄依賴版本、啟動參數、模型載入訊息、錯誤日誌及資源占用。尤其留意驅動程式、容器映像、運算精度與模型轉換流程是否一致。開發機能啟動，不代表雲端生產環境具有相同的驅動、權限、掛載方式或網路設定；部署紀錄應能重現，不能只留下「本機正常」這種結論。
低流量試跑：如何做大模型吞吐測試？
大模型吞吐測試要重現預期請求，而非只跑一組方便取得的短提示詞。從匿名化後的實際請求中整理輸入長度、輸出長度、請求到達模式與併發情境；若仍沒有生產資料，明確標示這是測試假設，待取得真實流量後再覆核。
記錄首 Token 延遲、Token 間延遲、請求吞吐量、輸出 Token 吞吐量與錯誤率。這些指標回答的問題不同：首 Token 延遲反映使用者何時看到回覆起始；Token 間延遲協助判斷生成期間是否順暢；請求吞吐量與輸出 Token 吞吐量則分別觀察請求完成能力與生成工作量。指標定義應以NVIDIA AIPerf 推論指標參考為準，避免把不同測試口徑的結果直接比較。
測試時讓請求速率與最大併發量符合預期流量，不要混為一談。NVIDIA 提供請求速率與最大併發設定說明，可據此設計測試負載；命令列選項則應對照AIPerf 官方參數文件。每次測試都保存設定與原始紀錄，否則測得的吞吐與延遲難以重現。
注意：不同輸入長度、輸出長度、併發和請求排程下的結果不宜直接橫向比較。先固定測試條件，再比較框架、配置或執行環境。
持續在線服務：把尖峰、排隊與利用率納入估算
並發量與上下文長度都會改變 GPU 選型。較長輸入增加處理工作；同時進行的請求會競爭運算與記憶體資源。若只用平均流量估算，尖峰期間可能排隊或逾時；若用最大假設負載長期配置，又可能讓資源在低流量時閒置。
因此，資源數量應從觀測與壓測推導：先確認服務目標，再用代表性負載測出單一部署在該條件下的有效吞吐，接著對照實際尖峰與容許排隊程度估算實例需求。再將故障時的備援安排與 GPU 利用率納入檢查。NVIDIA 的GPU 遙測指標文件可協助你觀察 GPU 資源使用狀況，但利用率高低本身不是服務品質結論：仍需和延遲、吞吐、排隊及錯誤率一起判讀。
大模型推論成本應按請求量還是 Token 量估算？
兩者都要記錄，但不能用單一口徑取代另一個。請求量有助估算請求處理頻率；輸入與輸出 Token 量則反映每次請求的工作規模。短問答與長上下文請求即使請求數相同，資源需求也可能不同。應先以真實或具代表性的請求樣本統計兩類資料，再使用壓測結果確認吞吐與延遲，而非套用未驗證的固定「每請求成本」。
雲端 GPU 成本估算：先拆項，再選計費方式
| 成本或方案 | 該核對的內容 | 較適合的情況 | 容易忽略的地方 |
|---|---|---|---|
| GPU 執行時間 | 實際使用時數、停止規則與目前公開費率 | 試跑、工作量起伏或尚未確定需求 | 閒置中的執行個體是否仍計費 |
| 儲存與網路 | 模型及映像儲存、資料傳輸與相關收費條件 | 模型需長期保留或跨環境傳輸 | 成本不一定只來自 GPU |
| 長期承諾 | 承諾期、折扣條件及用量是否穩定 | 使用模式持續且可預測 | 流量下降時仍可能承擔固定支出 |
| 自建硬體 | 採購、部署、電力、維護與資源閒置 | 長期負載穩定且有維運能力 | 初期投入及故障處理責任由團隊承擔 |
雲端 GPU 成本估算應把 GPU 執行時間、模型與映像儲存、網路傳輸、監控和維運工時分開記帳。不同服務商的計價單位及附加費用可能不同；本篇沒有可核實的當前單價，因此不提供假設價格。估算時直接查你選定服務的現行官方計費頁，將測得的執行時間、儲存用量與傳輸量代入，再用實際帳單覆核。
按需使用適合試跑、短期工作與流量不穩定的階段，優點是保留調整空間；缺點是仍須管理開關機、閒置資源與成本波動。長期承諾較適合用量穩定、能接受承諾條件的工作負載；缺點是流量低於預期時，彈性可能較差。不能只比較單位價格，還要將實際利用率、服務冗餘和管理成本一起算進去。
雲端部署前需要測哪些推論效能指標？
至少把延遲、吞吐、錯誤與資源遙測放在同一份紀錄中：首 Token 延遲和 Token 間延遲描述回應體感；請求吞吐量、輸出 Token 吞吐量及錯誤率描述服務處理結果；GPU 遙測補充資源使用情況。測試條件要同時記錄輸入與輸出長度、請求速率、最大併發及推理框架，否則無法判斷結果是否適用於你的線上流量。
把 GTC Berlin 議題轉成部署決策
NVIDIA GTC Berlin 官方 FAQ可用來核對會議安排；截至本文更新日，活動尚未舉行。會議議題適合作為追蹤技術方向的背景，不能代替模型相容性測試、推理文件或服務商計費條件。資源選型須由你的測試紀錄支持，不能預先假定大會將公布何種產品、性能或價格。
實際操作時，可逐項完成這份負載測試清單：
- [ ] 寫下模型版本、格式、推理框架與啟動依賴，並確認目標環境可以載入。
- [ ] 整理代表性輸入與輸出長度；資料不足時標明測試假設，之後以實際請求更新。
- [ ] 設定請求速率、最大併發與延遲目標，保存可重現的壓測參數。
- [ ] 同步記錄首 Token 延遲、Token 間延遲、請求吞吐、輸出 Token 吞吐、錯誤率及 GPU 遙測。
- [ ] 以實際尖峰流量對照有效吞吐，納入排隊、備援及資源閒置，再估算執行個體需求。
- [ ] 將 GPU 時數、儲存、網路傳輸及維運項目逐一對照現行計費頁；上線後用帳單覆核估算。
先完成負載測試，再選資源，最後覆核帳單。若目前主要靠臨時租用高價 GPU 反覆試錯，常見代價是資源規格尚未驗證、空閒時仍在計費，以及本機與生產環境不一致；但若工作負載是長期高強度推論，或必須直連特定實體介面，Mac 並不能取代相應 GPU 伺服器。若你需要的是短期 Apple Silicon 開發、相容性驗證或測試環境，可先了解 Kvmzen 的 Mac 雲端租用方案及Mac 雲端租用價格資訊，再依工作負載決定是否適合租用；大型模型的生產推論仍應以實測結果選擇相符的 GPU 方案。