你正在系統上部署一個模型。服務啟動了，提示詞也得到了響應。現在有個難題：這速度到底夠不夠快？
你的第一反應可能是發送curl命令、手寫一個asyncio腳本，或者隨手寫一個一次性的負載生成器。這些做法都存在同樣的問題：單進程性能有限、Python的GIL限制了並發能力，或者測出來的數據只是和你自己搭建的參照物比較而來。無論哪種方式，你最終得到的結果都難以完全信任，而且配套的工具一旦需求變化就得重寫。
你真正需要的是一個負載客戶端：既能讓真實伺服器達到飽和而不成為瓶頸本身，又能產出可直接使用的結果，配置時間只需五分鐘而不是五小時。這正是英偉達
AIPerf要解決的問題。
AIPerf有何不同
AIPerf是GenAI-Perf的官方繼任者，是一次從零開始的重寫。這些設計選擇，源自大規模運行大語言模型基準測試所積累的經驗教訓：
與舊架構徹底切割。AIPerf不再像GenAI-Perf那樣構建在Perf Analyzer之上。這是一次徹底的架構革新，也正因如此AIPerf才能實現如此規模的擴展能力。如果你正在遷移現有工作流，遷移指南涵蓋了關鍵的差異點。
客戶端本身不該成為瓶頸。包括GenAI-Perf在內的大多數基準測試工具都採用單進程架構，在真實並發或請求速率下會受限於GIL。AIPerf是一個多進程系統：工作進程負責生成負載，獨立的記錄處理服務負責處理結果，所有環節通過ZMQ協調。這種結構能夠避免AIPerf自身成為客戶端側的瓶頸，從而實現更準確的伺服器基準測試。
覆蓋你實際運行的各種工作負載。AIPerf支持15種以上的端點類型：聊天、響應、NIM排序、圖像生成等等——同時還支持ShareGPT等公開數據集，以及來自Mooncake、Baseten、WEKA（AgentX）等平台的流量回放格式。無論你是要做一次快速的合成壓測，還是要回放捕獲到的生產流量，都不需要更換工具。
負載形態由你自己掌控。AIPerf支持恆定、泊松和伽馬到達模式，並可調節突發程度，支持並發數與請求速率的漸進爬升，還支持包括vLLM/SGLang範圍比率的合成分布，用於處理可變的輸入序列長度/輸出序列長度。你掌控的不僅是負載的量，還有負載的形態。
你的第一次基準測試：在vLLM上進行合成ISL/OSL測試
在本次演示中，我們將使用通過vLLM部署的Qwen3-0.6B模型。這個模型選擇是刻意為之：它小到可以在單張GPU上運行，速度也足夠快，無需長時間等待即可疊代。這裡的重點不是專門針對Qwen3-0.6B做基準測試，而是建立起整套測量流程。一旦掌握了這個流程，換成其他模型或端點只需改動一個參數即可。
啟動伺服器
拉取並啟動vLLM，同時啟用推理解析器：
docker pull vllm/vllm-openai:latest
docker 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 venv
source venv/bin/activate
uv pip install aiperf
有一點平台注意事項：在aarch64架構上，crick依賴以源碼形式發布，需要C編譯工具鏈（Debian/Ubuntu上是build-essential，RHEL上是Development Tools）。如果安裝卡在這個包上，原因就在這裡。
運行基準測試
伺服器啟動、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個輸入Token和128個輸出Token。這重現了一種常用的靜態基準測試方式，即保持請求長度和輸出長度恆定。
--extra-inputs min_tokens:128 和 --extra-inputs ignore_eos:true 強制模型確實生成128個Token，而不是提前停止。如果沒有這兩個參數，輸出Token數量只是一個建議值——模型會在自然完成時就停止，這可能遠遠達不到你設定的目標輸出序列長度。這樣一來，吞吐量數據會比實際應有的水平偏低，而且在多次運行之間也無法復現。
--streaming如果你想測量首Token時間和Token間延遲，這個參數是必須的。沒有流式輸出，伺服器會先攢完整個響應再發送，這樣就沒有首Token或解碼Token事件可供測量。
你將看到什麼
我們會在下一節講解如何解讀這些數據。目前，先注意下圖2所示輸出的形態：按百分位劃分的延遲、以每秒Token數衡量的吞吐量，以及請求級別的統計數據，全部集中呈現在一處。這就是你後續對比一切結果的基線。
解讀數據：AIPerf呈現的內容
一次運行完成後，AIPerf會在控制台列印指標表格，並將完整結果寫入CSV和JSON文件。以下是你將看到的內容。
核心四項指標：
首Token時間（TTFT）——從請求發出到收到第一個Token所經過的時間。這是交互式應用場景中最主要的延遲信號。
Token間延遲（ITL）——生成過程中連續Token之間的時間間隔。即使首Token時間看起來正常，較高的Token間延遲也意味著解碼階段存在困難。
請求延遲——完整響應的端到端耗時，將預填充和解碼成本合併為一個數值。
輸出Token吞吐量——所有並發請求中每秒生成的Token數，這是產能規劃中最主要的吞吐量信號。
關於這些指標以及AIPerf報告的其他所有指標的完整定義，請參閱指標參考文檔。
獲取全貌。以上每項指標都會按百分位（p25、p50、p75、p90、p95、p99）分解報告，並附帶最小值、最大值、平均值和標準差。這些分解數據很重要，因為它們能揭示長尾分布：一台平均首Token時間健康、但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_tokens和ignore_eos。在靜態基準測試中，這兩個參數將輸出固定為恰好128個Token，以保持基線的純淨；而這裡我們特意放開這個限制，讓輸出分布可以自然變化。
--random-seed 42 使泊松到達時間和合成長度抽樣結果可復現。重新運行這條命令會產生完全相同的請求序列。
--streaming 依然是必需的。沒有流式輸出，伺服器會先攢完整個響應再發送，也就沒有首Token或解碼Token事件可供測量。
觀察這次運行得到的大語言模型指標，其分布明顯比靜態基線更為寬泛——這符合預期，因為更多請求同時爭奪GPU資源，且各請求的預填充長度不盡相同。
觀察下圖4中的圖表，可以看到泊松命令行引入的請求速率大致圍繞每秒10個請求波動，但並不完全精確等於該值。這種到達速率模擬了請求到達時間的抖動，而恆定模式則保證固定為每秒10個請求。
在下圖5中可以看到，請求長度圍繞512 Token均值存在波動，輸入序列長度的範圍在154到818個Token之間。
對比兩次運行的首Token時間可以發現，泊松運行的分布明顯更為分散。更多請求同時爭奪GPU資源，預填充長度各不相同，預填充和解碼操作也相互重疊。而單並發場景是一種理想化情形，一次只處理一個請求，能呈現最低的首Token時間，但代價是犧牲了吞吐量。
在上圖6中可以看到，單用戶運行的首Token時間波動性遠小於泊松實驗中變化更多的工作負載。
還有更多值得探索的內容
本次演示只涵蓋了基礎用法，但AIPerf同樣為更複雜的場景而設計。
同一個工具可以處理多節點Kubernetes部署、KV緩存復用預熱機制、生產流量回放、前綴合成、自定義數據集，以及跨並發級別的掃描配置。
如果你正在進行大規模分布式推理，請參閱《英偉達Dynamo 1.0如何支撐生產級多節點推理》。
AIPerf代碼庫中的教學是最快的入門方式。AIPerf代碼庫及文檔是了解新功能和參與貢獻的權威參考。
致謝
AIPerf是英偉達與外部貢獻者共同協作的成果。特別感謝：Loki Ravi、Dan Ferguson和Sheng Moua（來自AWS）持續的合作、跨公司驗證以及推動AIPerf標準化的努力；Aaron Batilo（來自Coreweave）貢獻了Weights & Biases導出器、接受長度的推測解碼數據集，並加固了並發情況下的掃描/額度調度可靠性；Shounak Ray（來自Baseten）為Baseten流量回放提供了忠實支持；Michael Feil（來自Baseten）實現了更快的流量加載以及會話親和性頭部支持；Cristian Lopez（來自Pinterest）在DAG基準測試方法論上進行了密切合作。我們也感謝Ben Hamm在AIPerf設計、規劃和實施過程中提供的產品指導。
Q&A
Q1：AIPerf是什麼？它主要用來做什麼？
A：AIPerf是英偉達推出的大語言模型推理基準測試工具，是GenAI-Perf的官方繼任者。它採用多進程架構，能夠在不成為客戶端瓶頸的前提下對推理伺服器進行準確的性能測試，支持15種以上端點類型和多種流量模式配置。
Q2：AIPerf和GenAI-Perf有什麼區別？
A：AIPerf是從零開始重寫的工具，不再依賴Perf Analyzer，實現了架構上的徹底革新。它採用多進程系統，工作進程與記錄處理服務分離並通過ZMQ協調，從而避免了GenAI-Perf存在的單進程GIL限制問題，能更好地支撐大規模並發測試。
Q3：使用AIPerf做基準測試需要注意哪些關鍵參數？
A：需要注意streaming參數以測量首Token時間和Token間延遲；min_tokens和ignore_eos參數可確保輸出Token數量達到目標值；arrival-pattern和request-rate參數可控制請求到達模式，模擬真實流量的突發和波動特性。
