譯者注：如果你對如何在公司產品中引入和運用深度學習模型有濃厚的興趣，下文也許會給你帶來一些幫助。
三年來，我們一直在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做斗爭。然而，我相信每一個參與構建產品的人都會為我們取得的成就感到自豪。我希望所有負責鞏固和發展這一系統的團隊成員也會享受這一挑戰。
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網站上部分文章為轉載，并不用于任何商業目的，我們已經盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯系我們，我們將根據著作權人的要求，立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。
