譯者注:如果你對如何在公司產品中引入和運用深度學習模型有濃厚的興趣,下文也許會給你帶來一些幫助。
三年來,我們一直在EyeEm公司開發計算機視覺產品-這些產品處理數十億的圖片。作為一個從零起步在幕后從事底層開發的工程師,這項工作帶來的技術挑戰讓我痛并快樂著。這段經歷讓我收獲很多:學會如何管理開發過程、處理與不同團隊的關系尤其是完成初創公司中充滿挑戰性的工作。
下文對EyeEm計算機視覺產品的發展歷史做一個梳理,其中既有不得不面臨的挑戰、開發中獲得的經驗也有對未來的展望。
當我三年前加入EyeEm時,目標是為了開發一個搜索引擎,幫助用戶搜索公司完整的目錄圖片。方法就是對圖像做標記并打分-當時圖像庫中有6千萬張圖片,并且還在快速增長中,做索引能夠幫助用戶方便查找圖片。這就是AI瘋狂的開始:初出茅廬,非常興奮又忐忑不安。
任務的目標是為每一張圖片顏值打分并進行分類。后來又增加了給圖片加標題功能。
搜索項目由一個多功能團隊負責。管理員選擇圖片,研究人員開發打分和標記算法。工程師則將這些集成到搜索引擎中,并要求其底層架構具有擴展性。
對于初創的公司來說,大量的新項目都是同時開始。在這個階段,一個團結的工程師團隊會讓每人獲益。各司其職的方法有助于更有效分享知識、更輕松復用組件、并且創建以有效的工程文化。
這兩個各自獨立團隊的作用和責任始終如一:
知識交流一般通過非常輕量級的檢查清單形式,其中包含輸入和輸出的格式,尤其是對以前版本的更改、應用和硬件需求、以及測試的覆蓋。這一般都是研發人員和工程師直接交流,只有在輸出發生大規模更改,影響內部或者用戶界面特性時才會提高交流的等級。
橫向交流合作值得信任:
“交流是為了用快的方式解決問題以使公司獲益。”
設計的個系統是給EyeEm庫中及新流入的圖片進行分類打分。
像很多初創公司一樣,在從開發單一應用起步后,公司開始轉向分布式架構。新的服務稱為Panopticon,該名字來源于18世紀的一種單看守監獄。
Panopticon的作用是從一隊列中讀入包含上載圖片ID的信息,對原始圖片進行歸納,存儲結果并發送給搜索系統,這樣逐一在所有的隊列上進行標記和打分。
研發團隊決定使用的框架是Caffe。團隊具備Python經驗,知道如何編寫服務。Python支持該項目中所需要的快速迭代。RabbitMQ 已經作為消息系統在使用, Cassandra似乎非常適合于需要永久存儲的數據-既不要刪除,只通過ID不要掃描就可以進行訪問。運行研發部門開發的深度學習算法,需要亞馬遜的GPU平臺,這由一個簡單的自動擴展功能組來管理。至于公司其他的基礎設施,使用Chef進行管理。
因為Panopticon是基于隊列的,簡單的方法是根據id逐次處理大批量圖片集。為了保存來自于互相隔離不同模型的結果,機器需要配置輸入不同的模型、接入不同的隊列。
一時涌現了大量的問題。雖然從中學到了不少經驗,但是依然有一些基礎問題難以解決:
后文會討論到,品質評分模型的輸出格式至少更改了四次,需要對輸出多做研究。
Panopticon運行良好,但只用來處理 EyeEm的圖片。 接下來是開發The Roll,一個幫助用戶組織和查找照片的iOS應用。這款應用對整個相冊進行打分和分類,與EyeEm庫沒有任何關系。這個新項目需要開發一個平臺無關的系統,可以利用現有模型里處理任何輸入的圖片。在短暫的頭腦風暴會后,給系統取了一個非常有創意和合適的名字:Espresso!,該系統包含了基于Caffe的模型。
Espresso是EyeEm產品中單獨的也是的推理系統,對Panopticon快速進行重構,不是運行模型,而是使用模型。在Espresso上進行快速迭代,以修復在Panopticon中發現的問題,并注意調整新出現的問題。
會在隨后的段落中詳細討論上述每一項。
Panopticon(EyeEm特有的)與 Espresso 的一個顯著差別是中間件。前者API是基于隊列,后者則完全依賴HTTP。 panopticon不必急于處理傳入的圖片,而Espresso需要迅速進行回復-這就是隊列的好處。模型也成長很快。
一個GPU可以一次處理一張或者一批圖片,時間大約為幾百毫秒。除非有多個GPU否則需要順序處理每一個請求。當收到大規模請求時,不能讓這些請求無限制堆積起來,這就需要確保給用戶合理的響應時間。
Espresso有一個非常簡單的看守機制。需要設置在特定時間內能夠接受的大請求數。超過這一門限值后的請求會返回HTTP 429錯誤(過多請求)。如果門限值設為10,當應用在短時間內收到了11條請求時,前10條請求會進入到隊列中,第11條請求會被丟棄。
如果進行標記的時間是大約500毫秒,看守門限值設為10,那么可以保證響應時間為5秒。盡管這是一個弱保證,但是對于客戶這已經足夠了
The Roll的推出是成功的。可以監控到請求的數量是平穩增長的,只要429錯誤增加就會啟動新的機器來均衡負載。在應用發布后的幾天里,每秒平均能處理上千張圖片。
在The Roll發布的幾個月里,這一切都工作正常。
初,研發團隊開發的所有模型都封裝在一個單獨的Python庫中,先后用在Panopticon和Espresso中。在推出The Roll的時候,我們意識到模型的需求開始改變,需要底層設施提供支持。
舍棄Caffe轉而使用 Theano (和Keras,以及Tensorflow),這樣就需要每個模型在其虛擬環境中運行,并按照正確的需求進行初始化。這也意味著不能在每臺GPU機器上運行單一的Python應用:每個模型運行單一的Python進程,但是仍然需要為客戶提供與以前API一致的接口。單獨包裝每個模型是很繁瑣的,但是必須重新設計架構以支持這種轉變。
保持各種可操作性意味著需要更高的兼容性,舍棄在每臺GPU機器的單一進程運行中多個模型的方案,而是采用一個Python進程運行一個模型,這稱為minion。Minion與以前的Espresso運行一樣的代碼,但是不提供多個輸出,只服務單一輸出。這就需要開發新的協調者應用,來查詢minion,合并它們的響應,為客戶提供一致的API。該協調者應用有一個名字叫 Espresso杯(為了明確,還稱其為協調者)。
在GPU上執行推理的快方式,是把多個輸入合并為單個批處理傳入到模型中,而不是多次單獨進行運算。例如,如果單個推理花費的時間是500ms,兩張圖片合并批處理的時間是800ms,那么同時批處理的照片越多,效率越高。在處理管道中,來自于不同請求的圖片合在一起進行批處理,處理的結果又進行分離,各自進行響應。
在The Roll的次迭代時,批處理交給負責The Roll API的機器,“first line”作為 Espresso的客戶,接收來自用戶的請求。系統收到用戶的條新請求時,就會生成一個新的批處理。在設定的超時前,請求會添加到新的批處理中,如果超時,就直接發送出去:API越繁忙,批處理的規模越大越有效率。
The Roll API作為Espresso的客戶,以批處理方式進行工作,對于固定數量的Espresso機器,批處理的規模只取決于公共API機器的數量。如果來自用戶的兩張照片同時到達,而只有一臺API機,就會創建一個單一批處理,而不管Espresso服務多少機器。另一方面,如果讓服務器承擔批處理任務,那么批處理取決于處理能力。如果兩張照片同時到達,而只有一臺Espresso機,就進行批處理,如果有兩臺Espresso機,則同時分別進行處理。
批處理一般只出現在處理過程的后階段。
The Roll只是曇花一現,其很多特點隨后都集成到EyeEm應用中。但是,新版本的分類和評分模型還是不斷出現,更為重要的是,新的業務目標需要完全嶄新的模型。
2017年初,在成熟的分類和評分模型之上,又產生了標題模型,內部相片品質模型和個人化評分系統,該系統中引入了人物提取器、個人化訓練模型和打分模型。在單臺機器上運行多個模型,這不得不需要在GPU上進行順序處理,這會增加總的響應時間。并且,GPU內存也太繁忙,需要減少批處理的規模。
在需要數月的遷移過程中,我們決定:
當每天都要處理如此多的系統問題時,難以把注意力集中在高級架構上。努力尋求統一的有機方法來處理新的和已有的模型,在上游研發部門和下游用戶間游刃有余,與緊迫的時間表和如影隨形的bug做斗爭。然而,我相信每一個參與構建產品的人都會為我們取得的成就感到自豪。我希望所有負責鞏固和發展這一系統的團隊成員也會享受這一挑戰。
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點, 并不代表本站贊同其觀點和對其真實性負責,本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺,網站上部分文章為轉載,并不用于任何商業目的,我們已經盡可能的對作者和來源進行了通告,但是能力有限或疏忽,造成漏登,請及時聯系我們,我們將根據著作權人的要求,立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。