文章目錄
1. MLPerf Inference Rules
1.1 Inference Division
MLPerf Inference分爲封閉分區（Closed Division）和開放分區（Open Division）。
-
封閉分區需要使用等同於參考實現的預處理，後處理和模型。封閉分區允許校準量化，但不允許任何再訓練。
-
開放分區只限制使用相同的數據集，它允許使用任意的預處理或後處理和模型，包括重新訓練。
MLPerf Inference爲每個Benchmark都提供了參考實現。這些參考實現本身並沒有進行優化，也不是爲了測量軟件框架或硬件平臺的“真實”性能。它們的目標是讓硬件和軟件供應商基於參考實現進行優化，並將優化後的結果作爲MLPerf Inference的優化解決方案提交給MLPerf。
1.2 Test Scenarios
MLPerf Inference有2個基本概念: sample和query。
- sample（樣本）是運行inference的單位，例如一個image或sentence。
- query（查詢）是一組進行Inference的N個sample。例如單個query包含8個image。
爲了能夠對各種推理平臺和用例進行代表性測試，MLPerf定義了四種不同的場景，如下所述。
single stream：模擬例如用戶使用智能手機拍照的真實場景。在測試中LoadGen發送初始查詢，然後在處理上一個查詢後不斷髮送下一個查詢。每次查詢只包含1個sample，可以理解爲batchsize=1。single stream度量標準是第90百分位延遲。注意，最後衡量的結果是Tail Latency而不是average Latency。multiple stream：評估例如檢測障礙物的多攝像頭汽車系統的真實場景。LoadGen運行多次測試來測量系統能夠支持的最大stream數，度量標準是支持的流的數量。（每個query中的Sample的數量等於stream的數量）server：評估在線請求數據中心服務，衡量服務器吞吐量這樣的實際場景。LoadGen使用多個query來確定系統可以支持的每秒查詢（QPS）中的最大吞吐量值，指標是QPS。（每個query只包含1個Sample）offline：評估實際場景，例如批處理系統。LoadGen運行單次測試來測量系統吞吐量。在測試開始，LoadGen一次發送所有query給Inference系統。
Load Generator是MLPerf的負載生成器，用於生成query，跟蹤query的Latency並驗證結果的準確性。每次運行LoadGen都會使用四種模式之一來評估系統的性能，最後提交的結果可以是{models, scenarios}的任意組合。
1.3 General rules
1）系統和框架必須可用
如果要測量公開可用且廣泛使用的系統或框架的性能，則必須使用公共可用且廣泛使用的系統或框架版本。
如果要測量實驗性的框架或系統的性能，則必須讓你使用的系統和框架可獲得並且可複製。
2）必須共享Benchmark implementations
用於基準實施的源代碼必須是開放源代碼，允許商業實體自由使用基準測試。只要結果被積極使用，代碼就必須可用。
3）所有隨機數必須基於固定隨機種子和確定性隨機數發生器，以保證每次生成的隨機數都是固定的。固定種子將在基準提交截止日期前一週公佈。
4）不能夠以任何形式編碼input dataset信息。
5）測試結果的可複製性是強制的，無法複製的結果不能作爲有效結果。
1.4 Data Sets Rules
1）對於Inference Benchmak測試，MLPerf 提供了以下數據集：
- accuracy數據集，用於確定提交是否符合質量目標，並用作驗證集
- speed/performance 數據集，是用於測量性能，它是accuracy數據集的子集。
- 對於除GNMT之外的每個Benchmark測試，MLPerf提供了用於量化的calibration數據集，它是訓練數據集的一部分。每個參考實現都有一個使用checksum來驗證數據集的腳本verify_dataset.sh以保證每次運行測試時數據集保持不變。
2）預處理和後期處理(Pre- and post-processing)
所有imaging測試都將未剪切的未壓縮位圖作爲benchmark的輸入，NMT採用文本。
與參考模型匹配的預處理是不計入infernece時間的，包括：
- 調整圖片大小到模型處理的大小（resize 例如：SSD-large）
- 可以重新排序channel （reorder channels）
- 填充圖片到任意大小（pad to arbitrary size but don’t be creative)
- 對圖片做單一地、一致地裁剪（do a single, consistent crop）
- 參考模型提供的對圖片進行的歸一化、均值操作
- 將圖像數據從fp32量化到int8
3）對於一次query需要處理多個樣本的場景 (i.e., server, multi-stream, and offline)，允許以任意順序遍歷測試數據。
1.5 Model Rules
CLOSED: 如下表所示，MLPerf Inference v0.5基於多個框架提供參考實現和替代實現。Benchmark實現的Model必須使用與參考實現或替代實現等效的模型（Model Equivalence）。
OPEN：基準測試實現可以使用不同的模型來執行相同的任務。允許再培訓。
1）Model Equivalence
只要滿足延遲和準確度並使用參考權重，就允許所有實現。
規則允許的實現主要有：
- 使用任意框架和運行時：TensorFlow，TensorFlow-lite，ONNX，PyTorch等
- 任意的數據順序
- 允許輸入時的權重和在內存中的權重不同。
- 數學上等效的變換（例如Tanh與Logistic，Relu6與Relu8）
- 用數學上等效的稀疏操作替換密集操作
- 爲不同的OP操作選擇不同的精度
- 融合或者拆分OP操作
- 在一個或多個batchsize之間動態切換
- 矩陣乘法或卷積算法的變動 (Variation in matrix-multiplication or convolution algorithm provided the algorithm produces asymptotically accurate results when evaluated with asymptotic precision)
- 允許使用混合精度
- 將具有1001個類的ImageNet分類器減少到1000個類
規則不允許的實現有：
- 替換全部的權重 (Wholesale weight replacement or supplements)
- 丟棄非零的權重元素 (Discarding non-zero weight elements)
- 緩存查詢或響應 (Caching queries or responses)
- 合併相同的query (Coalescing identical queries)
- 在inference運行並開始統計Latency時修改權重
- 硬編碼查詢總數
- 通過調度“軟丟棄”查詢
- 在實驗中能短暫提高性能，但不適用於長期運行服務的技術是不允許的，離線場景除外。
- 利用LoadGen的實現知識來預測server場景中即將到來的間歇或峯值
2） Model權重量化
對於Closed分區，MLPerf爲參考實現提供了fp32格式的weights和biases。MLPerf爲除GNMT之外的每個Benchmark提供了calibration數據集，提交者僅可以使用提供的calibration數據集來進行量化。支持的量化範圍爲：
- INT8
- INT16
- UINT8
- UINT16
- FP11 (1-bit sign, 5-bit exponent, 5-bit mantissa)
- FP16
- bfloat16
- FP32
注：只能使用基準所有者提供的校準數據集進行校準。允許卷積層爲NCHW或NHWC格式。不允許進行其他再培訓。
對於Open分區，每次運行必須將權重和偏差初始化爲相同的值，只要能達到相應的精確度，就允許任何量化方案。
1.6 總結
問題1：在MLPerf inference rules中允許對模型做哪些改動？在哪些方向/點上可以調整和修改？
回答：
根據上面允許的規則：從融合或者拆分OP操作和權重量化中推測，可以使用TensorRT和INT8量化。OP操作其實就是圖中的節點，TensorRT所做的加速就是對節點進行融合以及INT8量化。
根據上面不允許的規則：丟棄非零的權重元素,可以推測，不允許對Model進行剪枝。
1）可以使用TensorRT引擎來加速Inference，並且進行int8量化。
2）不能夠使用剪枝（pruning）來壓縮Model。
最後，由於所有的測試數據是由Loadgen統一加載，並生成相應場景(Laod)，因此不能夠使用DALI加速數據預處理。
下圖爲MLPerf Inference分別在Closed分區和Open分區的規則總結：
2. MLPerf Submission Rules (Training and Inference)
提交結果之前需要先申請加入inference submitters working group。需要注意的是，必須在提交截止日期前五週通知推理提交者工作組主席參加MLPerf Inference比賽（應該在7月底）。
2.1 Submission Result Set
提交結果集中的所有結果必須使用相同的框架和系統生成。可以提交一個、多個或所有基準的結果。結果之間軟件和硬件的唯一區別應該是基準實現。
2.2 System Reporting
如果系統在雲中可用，則應在雲中進行基準測試。當雲中沒有所需的系統時，允許在內部進行基準測試。
1）With Cloud Hardware
報告從Docker容器部署以及創建執行基準測試的一系列步驟。
報告雲規模（cloud scale），雲規模指雲系統的成本。
2）With On-premise Hardware
報告用戶重現結果時需要的硬件和軟件的所有信息。
2.3 Directory structure
提交的結果應採用具有以下結構的目錄：
submission.json
code/
<benchmark_name>/
README.md
setup.sh
preproc_dataset.sh
run_and_time.sh
...
results/
<system_desc_id>/
<benchmark>/
result_0.txt #log file
...
result_n.txt
entry.json
文件submission.json記錄組織的信息，應包含數據如下：
$ cat submission.json
{
"org": "Google",
"poc_email": "[email protected]"
}
code目錄存放Benchmark的代碼實現。
result目錄存放測試的結果日誌，system_desc_id目錄對應軟硬件測試平臺名稱，
result下的benchmark目錄的名稱必須是{ resnet, ssd, maskrcnn, transformer, gnmt, ncf, minigo }其中一個。該目錄放的是測試結果日誌。
entry.json描述整個軟硬件測試平臺的信息。entry.json文件包含的元數據如下所示：
$ cat entry.json
{
"division": "closed",
"status": "cloud",
"hardware": "n1-highmem-96 w/8xV100",
"framework": "TensorFlow 1.12.0",
"interconnect": "Single server with NVLink Ring topology",
"os": "Ubuntu 16.04 LTS",
"libraries": "CUDA 10, cuDNN 7.3, NVIDIA Driver 410.72. See Docker for more info",
"compilers": "N/A",
"nodes": [
{
"num_nodes": 1,
"cpu": "Intel Skylake",
"num_cores": 48,
"num_vcpus": 96,
"accelerator": "Tesla V100-SXM2-16GB",
"num_accelerators": 8,
"sys_mem_size": 624,
"sys_storage_type": "PD-SSD",
"sys_storage_size": 200,
"cpu_accel_interconnect": "PCIe",
"network_card": "GCE Standard",
"num_network_cards": -1,
"notes": "Boot device:200GB|PD-SSD;Data Disk:8x375G|local nvme RAID 0;Temp:50GB|PD-SSD"
}
]
}
注：加入inference submitters working group後，發現Inference的提交格式基本上是沿用了training的格式，目前還有許多未確定的地方，成員還在討論中。
3. 參考鏈接
- https://mlperf.org/inference-overview
- https://github.com/mlperf/inference_policies/blob/master/inference_rules.adoc
- https://github.com/mlperf/policies/blob/master/submission_rules.adoc
- https://docs.google.com/document/d/1YNGymVFuQdoH7tPFHWk6siSkFdvyHqKi3FuBTXaoxfM/edit#