案例分享 | Amazon EC2助力Deepfake檢測挑戰賽

2019年10月，AWS 宣佈將與 Facebook、微軟以及 Patnership on AI 共同組織首屆 Deepfake 檢測挑戰賽。

Deepfake 算法所使用的底層技術，與電影及主機遊戲中爲咱們帶來逼真動畫效果的方法徹底相同。遺憾的是，惡意人士使用這些無辜的算法模糊了現實與虛假之間的區別。Deepfake 視頻的本質，在於使用人工智能操縱音頻與視頻，致使最終結果呈現出人物作出或說出了客觀上並不存在的行爲或語言。關於 Deepfake 的更多詳細信息，請參閱 Partnership on AI 指導委員會關於 AI 及媒體完整性的說明。

在機器學習（ML）領域，生成對抗網絡（GAN）算法已經成爲構建 Deepfake 的最流行算法。GAN 中包含兩套神經網絡：一套爲生成網絡，經過向原始數據中添加噪聲以生成候選對象；另外一套爲判斷網絡，負責對數據進行評估直到創建起強大的合成/僞造識別能力。GAN 以對抗方式將兩套網絡匹配起來，借今生成能夠傳遞至實際數據的新的合成數據實例。這意味着最終得出的 Deepfake 數據，將擁有與普通數據集沒法區分的吻合性。

本次挑戰賽的目標，在於激勵世界各的研究人員創建起可以幫助檢測 Deepfake 以及媒體操縱行爲的創新方法。本輪競賽於2020年3月31日結束，並在 Kaggle 數據科學社區中大受歡迎。競賽結束後，Facebook 團隊在 AWS 上託管了 Deepfake 挑戰賽數據並面向全世界發佈，鼓勵更多研究人員繼續嘗試解決這一難題。

全球2300多支參賽隊伍總計提交了4200多種解決方案。參賽做品將由如下記錄丟失函數進行評分，分數越高表明效果越好（關於得分的更多詳細信息，請參閱競賽規則）。

下面來看本次競賽中使用的四組數據集：

• 訓練數據集：各參與隊伍使用此數據集訓練本身的模型。數據集中包含470GB 視頻文件，全部視頻皆附有真實與僞造標籤。
• 公開驗證數據集：包含來自測試數據集的400段視頻樣本。
• 公開測試數據集：供 Kaggle 平臺用於計算公開排行榜。
• 內部測試數據集：由Kaggle競賽平臺以外的 Facebook 團隊主辦方用於爲比賽結果打分。使用內部測試數據集評估得出的結果，將顯示在競賽的內部排行榜上。這套視頻中包含在格式與屬性方面，同訓練、公共驗證以及測試數據集極爲類似的視頻素材，且同時涵蓋真實天然視頻與僞造視頻兩大類別。

在競賽截止日期以後，Kaggle 各個團隊的兩份最終提交代碼交付給競賽主辦方。主辦團隊將在內部數據集上從新運行這些提交代碼，並將預測結果提交至 Kaggle 以計算最終內部排行榜得分。提供代碼將匹配兩種類型的計算虛擬機（VM）：基於 GPU 型與基於 CPU 型。大部分提交代碼由基於 GPU 型虛擬機處理。

Facebook 的比賽主辦團隊很快發現，遠超計劃的競賽參與規模給評估工做帶來了很多挑戰。在使用 p3.2xlarge Amazon Elastic Compute Cloud（Amazon EC2）P3實例的狀況下，每項提交代碼須要9個 GPU 小時才能處理完成，而競賽總計迎來4200多項提交代碼。換言之，他們大概須要42000個 GPU 小時（將近5年）的計算時間才能給出競賽評估結果。但這無疑會令比賽失去意義。爲此，他們須要想辦法在3周以內完成5年的總 GPU 計算量。

鑑於時間緊迫，主辦團隊必須克服制約因素，努力在指定的時間與預算範圍內完成評估。

運營效率

因爲團隊規模較小，爲了知足緊張的比賽時間並提升工做效率，實際解決方案必須具有較低的代碼要求。爲此，Facebook 主辦團隊決定使用 AWS Batch 以規劃及擴展計算工做負載。下圖所示，爲這套解決方案的基本架構。

AWS Batch 的最初設計主要面向開發人員、科學家以及工程師們的實際需求，幫助他們在不具有代碼編寫或雲基礎設施架構經驗的前提下，在 AWS 之上高效管理大量批處理計算做業。無需安裝及管理批處理計算軟件或服務器集羣，用戶將能夠專一於分析並解決問題。AWS Batch 還提供計劃調度與向外擴展選項，可以將批處理計算工做負載分發至多種 AWS 計算服務（例如 Amazon EC2 與競價實例）當中。另外，AWS Batch 提供的集羣資源管理方案無需額外成本。在本用例中，主辦團隊直接提交4200項計算做業，每項做業各自注冊爲單一 Kaggle 提交容器，且各自運行9個小時。使用這樣的實例集羣，所有做業都得以在三週時間以內快速處理完成。

彈性

競賽時間緊迫，也就表明各實例的運行週期不會太長，所以要求計算資源具有出色的彈性。例如，主辦團隊可能估計至少須要全天候並行運行85個 Amazon EC2 P3 GPU 才能完成提交代碼評估。爲了解決從新啓動及其餘可能致使時間浪費的意外情況，可能還須要額外增長50%的冗餘容量。爲了實現這些目標，Facebook 必須有能力迅速擴大評估時所使用的 GPU 與 CPU 數量，並在做業完成後及時收縮規模，且僅按實際資源使用量支付費用。單從預算及運營角度出發，這種方式的實際效率要遠遠高於在本地獲取、安裝與配置計算資源。

安全性

安全性又是另外一個重要問題。面對如此衆多的競賽參與者，提交內容當中可能包含病毒、惡意軟件、殭屍程序或者 Rootkit。在沙箱雲環境中運行這些容器可以有效避免相關風險。若是評估環境受到各種感染因素的影響，則能夠終止該環境並輕鬆完成重建，而不致令任何生產系統遭遇停機或數據丟失等問題。

隱私與保密

隱私與保密都屬於同安全問題密切相關的重要因素。爲了解決這些問題，全部提交代碼及數據都被保存在具有虛擬私有云（VPC）且使用 AWS 身份與訪問管理（AWS Identity and Access Management，簡稱IAM）權限限制機制的 AWS帳戶當中。爲了保證所提交模型的保密性以及評分的公平性，將由一位專門的工程師負責執行評估工做，且其不會觸及各團隊提交的任何Docker鏡像。

成本

主辦團隊須要考慮的另外一項重要因素，正是成本。根據初步估算，42000個小時的 Amazon EC2 P3 實例運行週期將花費約125000美圓。

爲了下降 GPU 計算成本，主辦團隊經過評估意識到 Amazon EC2 G4（採用英偉達 Tesla T4 GPU）實例類型相較於P3實例（採用 Volta 100 GPU）在處理此工做負載方面更具成本效益。在雲端 GPU 實例當中，Amazon EC2 G4 也是一類適合用於部署機器學習模型的高效通用 GPU 實例。

這些實例針對機器學習應用程序部署（推理）進行了優化，優化範圍涵蓋圖像分類、對象檢測、推薦引擎、自動語音識別以及語言翻譯等等，經過多個層面推進 AI 創新、優化延遲水平。

主辦團隊使用 G4 實例類型進行了一系列測試運行，並發現單次代碼提交測試的運行時間爲 P3 實例運行時間的兩倍以上，所以總計算時長將增長到約90000個小時。然而，G4 實例每小時的使用成本要比 P3 實例低83%。儘管使用 G4 實例的狀況下各項做業的運行時間更長，但整體計算成本仍然從125000美圓快速下降至不足50000美圓。下表所示，爲 G4 實例類型在處理單項推理做業時的成本效益：

主辦團隊分享稱，大部分提交代碼的評估完成時間要比預期更短。最初預測基於早期提交的模型，但該模型的體量要大於所有提交模型的平均大小。約有80%的運行採用 G4 實例類型，但也有部分運行必須在 P3 實例上實現 —— 這是由於兩種實例類型的可用 GPU 內存略有差異。最終數字爲：25000個 G4（GPU）計算小時、5000個 C4（CPU）計算小時以及800個P3（GPU）計算小時，整體計算成本爲20000美圓。通過約兩週的全天候評估，主辦團隊成功完成了這項極具挑戰性的任務，且在預期時間段內只花掉50000美圓初期預算的一半不到。

總結

主辦團隊最終在極短期內完成了對4200多項提交代碼的全面評估，並在充分知足公平性標準的前提下將預算控制在合理範圍內。主辦團隊還成功複製了評估環境，成功率爲94%，從而充分知足了雙輪賽制提出的實際需求。

因爲技術的不肯定性，軟件項目每每極易產生風險；種種內在複雜性與約束條件的存在，更是令軟件項目雪上加霜。憑藉 Amazon EC2 上極具深度與廣度的 AWS 服務選項，你們能夠顯著減小技術不肯定性以解決您所面對的獨特挑戰。以此爲基礎，Facebook 團隊在單獨一位軟件工程師的幫助下，按時在預算範圍內完成了 Deepfake 評估挑戰。工程師首先選擇了低代碼解決方案 AWS Batch（豐富的案例證實，其可以從容處理更大規模的高性能計算類工做負載），然後經過 AI 推理優化型 EC2 G4 實例類型將評估成本下降達三分之二。

AWS 一直認爲，不存在百試百靈的單一解決方案。任何最佳解決方案都是由多個構建單元所靈活構成，咱們能夠藉此組織起既知足實際需求、又符合優先級排序的解決方案。