如何評測AI系統？
最近，隨著MLPerf走進大家的視野，AI系統（這裡指完成AI任務的軟硬體系統）的Benchmark這個話題備受關注。從目前的進展來看，對於機器學習訓練（Training）系統，MLPerf可以說基本解決了對比評測的問題；而對於推斷（Inference）系統來說，設計Benchmark非常困難，很多問題目前還看不到答案。
???
自從MLPerf推出以來，相關的討論非常活躍。用圈內一位大佬的話說，「一個小小的工作組會議，來了矽谷ai晶元的一半大佬，還有圖靈獎得主坐鎮...」。可見其受重視的程度。
MLPerf的概述是這樣的：「The MLPerf effort aims to build a common set of benchmarks that enables the machine learning (ML) field tomeasure system performance for both training and inference from mobile devices to cloud services. We believe that a widely accepted benchmark suite will benefit the entire community, including researchers, developers, builders of machine learning frameworks, cloud service providers, hardware manufacturers, application providers, and end users.」
而MLPerf的目標（如下圖）基本上和傳統的Benchmark類似。
source：MLPerf.org
MLPerf的想法應該有兩個來源，一個是哈佛大學的Fathom項目（Fathom: Reference Workloads for Modern Deep Learning Methods）；另一個是斯坦福的DAWNBench（An End-to-End Deep Learning Benchmark and Competition）。MLPerf借鑒了前者在評價中使用的多種不同的機器學習任務，以保證Benchmark具有足夠的代表性；同時借鑒了後者使用的對比評價指標，保證公平性。如下面兩個圖所示。
source：MLPerf.org
從評價指標（Metrics）來看，第一點基本是針對訓練任務的，即訓練一個模型達到一定精度所需的時間。第二點是給出一個綜合評分（score），不過這個具體怎麼執行好像還沒有定論。第三個實際是一個成本的指標，這裡也強調了對於Mobile主要給出功耗，而對於Cloud則直接給出使用的成本，應該是和DAWNBench類似。比如下圖這樣的結果，
另外，MLPerf還提出了一個Closed and Open Model Divisions的概念。Closed Model Division使用確定的模型和參數，以保證測試的公平性。而Open Model Division則會放寬一些限制，讓大家可以有一定的發揮空間，鼓勵軟硬體的創新。
source：MLPerf.org
到此為止，我們可以認為，如果目前的機器學習方法不發生大的變化，對於訓練系統的評估，MLPerf已經提供了一個相對完備和公平的方法。雖然目前MLPerf還不能稱為一個大家公認的標準，從目前參與的玩家來看，還有很多巨頭在「觀望」，或者由於各種原因他們未來也不會支持這個Benchmark。但從技術上來說，我認為「如何評估機器學習訓練系統」這個問題已經基本解決了（當然還有很多細節需要完善，未來也需要根據演算法和模型的變化不斷更新）。即使未來大家不會統一使用MLPerf，對於Training系統的基本的Benchmark思路也應該是差不多的。同時，在Training應用中，Intel的CPU，Nvidia的GPU和Google的TPU還可以作為很好的對比基線。
做訓練系統軟硬體的公司，現在有了一個比較公平的競技場，好東西可以更容易證明自己，只要跑跑MLPerf的Benchmark，看看完成這些訓練要多少時間，多大成本就行了。當然，PR公司和2VC公司能混的日子也不多了。
???
不過，如果我們把視野轉到Inference系統的評估，則情況要複雜很多。雖然MLPerf並沒有把自己限制在Training任務上，也希望能夠覆蓋Inference系統的評估，但目前顯然還沒有找到很好的方法。因此，MLPerf工作組的主要成員，Google的Cliff Young，在MLPerf的論壇中專門提出了「InferenceBenchmark」這個討論的題目。在郵件開始他指出，最初他們也試圖把Inference包括在Benchmark當中，但逐漸發現它和Training在很多方面都有所不同，很難在短期拿出一個比較理想的方案。關於具體的困難和值得討論的問題，他也做了詳細的說明。這部分非常值得思考，這裡我引用一下：
What"s the metric? Is there an equivalent to "time to target accuracy" in the inference space, such as "inferences per second at or above the threshold accuracy"? Do we measure both latency and throughput? What about power?
第一個是「使用什麼指標的問題」。Training系統的性能可以使用「達到特定精度的時間」這個簡單的標準來衡量。但Inference系統卻很難找到一個簡單的指標，這一點我在之前的文章中也有過討論。Latency，Throughput，Power，Cost，等等，哪個指標合適？再放到不同的應用場景情況就更為複雜。
Does an inference set get distributed with already-trained weights? If not, how do you ensure comparability across measurements?
第二個問題關於模型使用什麼參數，參數如果不同如何進行對比？
What does one do about quantized arithmetic, or other related implementation techniques?
第三個是實現優化帶來的問題。比如，如果兩個系統的量化比特不同，怎麼對比？
What do we do about hardware variation? We"re in an era where the underlying hardware might be vastly different. Do we allow retraining to help target the device? If a device can"t support a feature (e.g., some activation function), what accommodations are allowed?
第四個是硬體差異性的問題。Inference系統的硬體往往有比較大的差異，Benchmark在設計的時候如何應對？
How many different inference markets or sub-benchmarks are there? For the moment, training seems to be unified, but inference already looks like it is splitting into Cloud and edge (mobile, IoT, battery-powered) segments. Do we need multiple inference benchmark suites?
最後一個問題非常關鍵，就是Inference的應用是千差萬別的。和目前Training應用相對單一不同，Inference首先就可以分為Cloud和Edge端應用，而再細分又可以分成很多類別，而它們又有各自的特點。我們是否需要針對每個應用做不同的Benchmark呢？
除了上述問題，我還可以舉出很多例子，而這些問題大部分是源於Inference應用領域的差異性和實現選擇的多樣性。再引用一位朋友的評論，「領域處理器的benchmark不好做，BDTI的DSP benchmark做了很久，也不是很成功」。這個問題確實非常困難，我覺得短期可能很難有統一的Benchmark出現。
未來Inference的Benchmark很可能要綁定應用。也許有這樣一種可能，隨著某個Inference應用的成功，逐漸形成一些公認的指標或者出現行業標準，那麼Benchmark就比較容易了。在這之前，大家還是可以自說自話，我們也只能看得雲里霧裡。
- END-
題圖來自網路，版權歸原作者所有
本文為個人興趣之作，僅代表本人觀點，與就職單位無關
TAG:StarryHeavensAbove |