您正在系統上部署一個模型。它啟動了，提示訊息也得到了回應。現在最關鍵的問題是：這速度快嗎？
你的直覺可能會驅使你發送 curl 命令、手動編寫 asyncio 腳本，或再寫一個一次性的負載產生器。所有這些方法都存在同樣的問題：單一進程效能限制、Python 的 GIL 限制並發數，或者效能資料是相對於你自己建立的參考值而言的。無論哪種方式，最終你都會得到無法完全信任的結果，一旦需求發生變化，你就必須重寫這些工具。
你需要的是一款能夠充分測試真實伺服器效能而不成為瓶頸、能夠產生可供你採取行動的輸出結果、並且只需五分鐘即可配置完成（而不是五個小時）的負載客戶端。 NVIDIA AIPerf 就是這樣一款產品。
AIPerf的獨特之處
AIPerf 是 GenAI-Perf 的指定繼任者，它是從零開始重寫的。其設計選擇反映了大規模運行 LLM 基準測試的慘痛經驗教訓：
- 與舊架構徹底決裂。 AIPerf不像 GenAI-Perf 那樣基於 Perf Analyzer 運作。這種架構上的徹底變革，正是 AIPerf 能夠如此強大擴展的原因。如果您要遷移現有工作流程，遷移指南涵蓋了關鍵差異。
- 客戶端不應該成為瓶頸。大多數基準測試工具（包括 GenAI-Perf）都採用單一進程架構，在實際並發或請求速率下會受到 GIL 的限制。 AIPerf 是一個多進程系統：工作進程產生負載，獨立的記錄處理器服務處理結果，所有操作都透過 ZMQ 進行協調。這種結構可以防止 AIPerf 成為客戶端瓶頸，從而實現更準確的伺服器基準測試。
- AIPerf 的工作負載範圍與您實際運行的工作負載完全相符。它支援 15 種以上的端點類型：聊天、回應、NIM 排名、圖像生成等等，以及 ShareGPT 等公共資料集和來自 Mooncake、Baseten、WEKA (AgentX) 等的追蹤回放格式。無論您是執行快速的合成冒煙測試還是回放捕獲的生產流量，都不需要其他工具。
- 負載形狀由您掌控。 AIPerf支援恆定、泊松和伽馬到達模式，並可調突發性，支援並發性和請求速率的漸進式增長，以及包括 vLLM/SGLang 範圍比率在內的合成分佈，以適應可變 ISL/OSL。您不僅可以控制負載的大小，還可以控制其形狀。
您的首次基準測試：vLLM上的合成ISL/OSL
在本示範中，我們將使用透過 vLLM 提供的 Qwen3-0.6B 模型。選擇此模型是經過深思熟慮的；它足夠小，可以在單個 GPU 上運行，並且速度足夠快，可以無需等待即可進行迭代。重點並非專門對 Qwen3-0.6B 進行基準測試，而是建立測量循環。一旦建立了測量循環，切換到不同的模型或端點只需更改一個標誌即可。
啟動伺服器
拉取並啟動啟用推理解析器的 vLLM：
docker pull vllm/vllm-openai:latestdocker run --gpus all -p 8000:8000 -e HF_TOKEN vllm/vllm-openai:latest \ --model Qwen/Qwen3-0.6B \ --reasoning-parser qwen3 \ --host 0.0.0.0 --port 8000 |
安裝AIPerf
我們可以使用 UV 來安裝中央副本：
uv tool install aiperf |
或對於虛擬環境：
uv venv venvsource venv/bin/activateuv pip install aiperf |
平台說明：在 aarch64 架構上，此 crick 依賴項僅以原始程式碼形式提供，並且需要 C 工具鏈（build-essential 在 Debian/Ubuntu 上，Development Tools 在 RHEL 上）。如果安裝在該軟體包處停滯，原因就在於此。
運行基準測試
伺服器啟動並安裝好 AIPerf 後，我們現在可以執行第一個效能分析了：
aiperf profile \ --model Qwen/Qwen3-0.6B \ --endpoint-type chat \ --streaming \ --url localhost:8000 \ --synthetic-input-tokens-mean 128 \ --synthetic-input-tokens-stddev 0 \ --output-tokens-mean 128 \ --output-tokens-stddev 0 \ --extra-inputs min_tokens:128 \ --extra-inputs ignore_eos:true |
這裡有些旗幟的作用比它們看起來大得多：
--synthetic-input-tokens-stddev 0 並將 --output-tokens-stddev 0 工作負載限制為每個請求 128 個輸入詞元和 128 個輸出詞元。這重現了常用的靜態基準測試，該測試保持請求和輸出長度恆定。
--extra-inputs min_tokens:128 並 --extra-inputs ignore_eos:true 指示模型實際輸出 128 個 token，而不是提前停止。如果沒有這些指示，輸出 token 數量只是一個建議值。模型會在自然完成時停止，這可能遠低於您設定的目標 OSL。吞吐量最終會低於預期，並且無法在不同運行中復現。
--streaming 如果要測量 TTFT 和 ITL，則必須使用串流。如果沒有串流傳輸，伺服器會在發送之前將整個回應進行批次處理，因此無法測量首次詞元事件或解碼詞元事件。
你會看到什麼
我們將在下一節詳細講解如何解讀這些數據。現在，請注意下圖中的輸出結果：延遲按百分位數細分，吞吐量以每秒詞元數 (tokens/s) 為單位，以及請求級別的統計信息，所有數據都集中在一處。這就是您將用來比較其他所有數據的基準。
解讀數據：AIPerf揭示了什麼
運行完成後，AIPerf 會將指標表列印到控制台，並將完整結果寫入 CSV 和 JSON 檔案。以下是您現在看到的內容。
核心四項：
- 首次詞元到達時間 (TTFT) — 從發送請求到收到第一個詞元所花費的時間。這是互動式用例的主要延遲指標。
- ITL（詞元間延遲） ——產生過程中相鄰詞元之間的時間間隔。即使 TTFT 看起來正常，高 ITL 也意味著解碼階段有問題。
- 請求延遲－從頭到尾完成回應所需的時間。它將預填和解碼成本合併為一個數字。
- 輸出詞元吞吐量－每秒所有並發請求產生的詞元數量。這是容量規劃的主要吞吐量指標。
有關這些指標以及 AIPerf 報告的所有其他指標的完整定義，請參閱指標參考。
全面了解情況。以上各項指標均以百分位數細分（p25、p50、p75、p90、p95、p99）的形式呈現，並附有最小值、最大值、平均值和標準差。這些細分數據至關重要，因為它們可以突出顯示長尾分佈；例如，一台伺服器的平均 TTFT 值正常，但 p99 值異常，從整體上看似乎沒有問題，但在生產環境中可能出現故障。
除了核心四核心處理器之外，借助 DCGM 或 pynvml，AIPerf 還能將 GPU 功耗、使用率和記憶體消耗整合到同一次運行輸出中。這樣一來，將延遲峰值與記憶體壓力事件關聯起來就無需單獨進行效能分析，遙測資料已經存在。
更進一步：配置交通模式
現在我們已經熟悉了靜態基準測試，可以開始探索更動態的場景了。上一節展示了一個非常固定的流量模式，但實際的推理流量並非遵循靜態模式。為了使用更靈活的場景進行基準測試，我們可以使用 AIPerf 的一些合成工作負載參數來增加請求的變異性。
aiperf profile \ --model Qwen/Qwen3-0.6B \ --endpoint-type chat \ --streaming \ --url localhost:8000 \ --request-rate 10 \ --arrival-pattern poisson \ --synthetic-input-tokens-mean 512 \ --synthetic-input-tokens-stddev 128 \ --output-tokens-mean 128 \ --output-tokens-stddev 32 \ --random-seed 42 \ --request-count 200 |
與上述靜態基準測試相比，有幾點發生了變化。
--arrival-pattern poisson這--request-rate 10意味著請求平均每秒到達 10 個，請求間隔時間服從指數分佈。伺服器現在面臨的是突發和間歇性的請求，而不是單一的用戶流，這才是實際流量下排隊的真實情況。
--synthetic-input-tokens-stddev 128這會引入圍繞 512 個 token 平均值的波動，從而產生長短不一的提示訊息。伺服器在預填充過程中必須處理長度可變的提示訊息，而不是長度相同的提示訊息。
--output-tokens-stddev 32 增加了輸出端的方差。請注意，此指令中已移除 ` min_tokensand` 和 `or` ignore_eos。在靜態基準測試中，這些標誌將輸出限制為 128 個標記，以保持基線的簡潔性；我們特意解除了這一限制，以便輸出分佈可以有所不同。
--random-seed 42 使得泊松時間和合成長度抽樣結果可重複。重新執行此命令會產生相同的請求序列。
--streaming 這不是可選項。如果沒有串流傳輸，伺服器會在發送前將整個回應批量處理，因此無法測量首次詞元事件或解碼詞元事件。
從本次運行的 LLM 指標來看，分佈明顯比靜態基線更寬——這是因為同時有更多請求競爭 GPU 存取權限，並且每個請求的預填充長度都不同。
觀察下圖中的圖表，可以看出泊松命令列引入了一個中心值約為 10 個請求/秒（但不完全匹配）的請求速率。這種到達速率模擬了請求到達時間的抖動，與保證固定 10 個請求/秒的恆定模式相比，這種抖動更為明顯。
從下圖可以看出，請求長度有變化，中心值約 512 個標記，輸入序列長度範圍為 154 到 818 個標記。
比較兩次運行的 TTFT，可以看出泊松分佈運行的 TTFT 分佈範圍更廣。同時，更多請求競爭 GPU 訪問，預填充長度各不相同，並且預填充和解碼操作存在重疊。單並發情況是一種理想化的場景，每次只運行一個請求，以犧牲吞吐量為代價，實現了盡可能低的 TTFT。
從上圖可以看出，單一使用者執行的 TTFT 變化比泊松實驗中變化更大的工作負載要小。
還有更多值得探索的地方
本教程涵蓋了基礎知識，但 AIPerf 也適用於更複雜的場景。
該工具能夠處理多節點 Kubernetes 部署、鍵值快取重複使用預熱機制、生產流量追蹤回放、前綴合成、自訂資料集以及跨並發層級的掃描配置。
如果您正在大規模運行分散式推理，請參閱「NVIDIA Dynamo 1.0 如何協助生產級多節點推理」。
AIPerf 程式碼庫中的教學是最快捷的入門途徑。 AIPerf程式碼庫和文件是了解新功能和貢獻內容的權威參考資料。
致謝
AIPerf 是 NVIDIA 與外部貢獻者共同努力的成果。在此感謝以下人員：Loki Ravi、Dan Ferguson 和 Sheng Moua（AWS），感謝他們持續的合作、跨公司驗證以及為 AIPerf 標準化所做的努力；Aaron Batilo（Coreweave），感謝他提供的權重和偏差導出器、驗收長度規範解碼數據集以及並發環境下掃描/信用分發可靠性的強化； Feil（Baseten），感謝他提供的更快的追蹤載入速度和會話親和性標頭；Cristian Lopez（Pinterest），感謝他在 DAG 基準測試方法論方面的密切合作。我們也要感謝 Ben Hamm 在 AIPerf 的設計、規劃和實現過程中提供的產品指導。
中秋節好康活動火熱響應-「中秋團圓、電腦也團圓」快來留言拿大獎!!
9月搞畏獎開跑中，搞畏有獎放送中
現在就加入 ioioTIMES 臉書粉絲團 更多互動、更多好康攏抵加!!
我們有LINE TODAY頻道了，快來追踪我們吧!!--最新科技新聞 盡在你手
