您的位置:首頁>科技>正文

【鈦坦白】百度深度學習實驗室於洋:深度學習系統本身面臨的一些挑戰

在鈦媒體Pro專業用戶和付費用戶專享的“鈦坦白”線上課堂第33期, 我們再次請來三位鈦客分享對機器學習的思考 。 本期鈦客之一、百度資深工程師、Paddle API重構設計負責人于洋,

從事百度深度學習平臺PaddlePaddle開發工作。 加入百度後一直從事深度學習系統的研發, 主要負責深度學習系統的性能優化和功能開發工作。 2016年獲得百度年輕高潛人才(YTP)項目成員以及百度最佳個人。

本文根據於洋的分享整理。 全文需要成為鈦媒體專業用戶才可以查看。 進入鈦坦白九個專業群交流, 並查看更豐富的專業資料和資訊, 可點擊:http://www.tmtpost.com/pro註冊成為鈦媒體專業用戶。

以下根據於洋在鈦坦白的分享實錄整理:

大家晚上好, 我是來自於百度深度學習實驗室的於洋, 在百度主要從事百度深度學習系統PaddlePaddle的開發, 今天給大家帶來的分享題目是《深度學習系統本身所面臨的一些挑戰》。

先思考一個AI落地的真實問題

AI已經是一個很火的話題,

但是AI如何在中小企業落地, 其實牽扯到很多現實的問題。 比如一個最簡單的問題, 如何通過語音來控制電視, 我們認為有四種解法:

1、用AI HUB, 也就是說將神經網路的模型放到一個晶片或者是一個很小的機器裡讓這個機器去控制電視。 這個AI Hub不應該放到電視。 例如Amazon Alexa或者Google Home。 二者雖然實現了聲控, 但是人可能在屋裡到處走動, 不是身在何處都能喚醒Alexa的。

但這麼做其實不是特別經濟, 因為如果要讓AI去控制電視的話, 首先每一台電視都要具有神經網路的預測功能, 同時當使用者的真實資料預測完之後, 神經網路也要去根據使用者的新資料去重新訓練模型, 讓模型更好。 這就要求一個晶片既具備神經網路的推斷能力,

又具備訓練能力。

2、提供一個深度學習的API給大家, 比如百度提供一個深度學習訓練和預測的平臺。 大家願不願意把自己的資料放到百度或者穀歌的雲盤裡, 讓百度給大家提供機器學習訓練預測的API呢?

我想這在很多場景下是不現實的。 第一個原因是, 用戶要學會用API就很難, 要在IoT上調用API更難。 另一個原因是, 在百度PaddlePaddle團隊和其他企業進行交流的時候發現, 大部分企業都想用的是私有雲。 不使用公有雲的理由其實不是成本, 主要還是公有雲可能帶來的資料安全問題, 因為對於企業來說真正有價值的東西其實是訓練資料。

3、企業自己搭一個AI的專用集群, 或者說買一百台GPU機器只去跑深度學習的訓練,

這樣做是不是可行的呢?我想也是不可行的, 因為專用的AI集群的GPU是非常昂貴的, 大體上, 租用一個AWS GPU instance一年的費用和買一台一樣。 而專用集群的集群利用率並不會非常高, 因而很不划算。 至於專用集群的利用率為什麼不會很高, 我們稍後再講。

4、PaddlePaddle提出的目標是做一個通用的AI集群。 通用的意思是AI集群裡既可以跑神經網路的訓練任務也可以跑其他的任務, 對於各項任務既可以跑生產環境的作業, 也可以跑實驗性作業。 這樣一來, 一個企業裡各個業務的各個團隊都可以使用同一個機群, 甚至如果部署到雲上可以使不同企業一起用一個機群。 你不用的時候我用, 你的作業用GPU同時我的在用磁片, 從而使得機群的總體利用率大幅提升。

選擇專用集群還是通用集群?

下面這張圖是穀歌Deepmind的AlphaGo所使用的資源使用情況。 可以看到, 在最後分散式的時候使用了280塊GPU:

下圖是百度的GPU訓練機器, 我們的一台機器就可以支持16塊GPU顯卡, 最多可以擴展到64塊顯卡:

所以這種深度學習的專用集群地球上沒有幾個企業能真正玩得起。比如說百度的機器翻譯系統,在我們組訓練的時候,可能會用32塊K40的GPU做十天左右的訓練;穀歌的機器翻譯用了96塊K80做GPU訓練;AlphaGo其實用了50塊GPU訓練了一個月。這些昂貴的使用成本是初創企業所不能承受的,也是不應該承受的。

為什麼像百度、穀歌或者微軟之類的大公司可以承受這樣成本呢?其實原因還是比較簡單的,在這些公司,深度學習在產品線裡應用是比較廣的。比如大部分的百度產品線都使用了PaddlePaddle,利用深度學習提升這些產品的功能和使用者體驗。

大家如果調試過深度學習任務就可以很明顯知道, 深度學習任務是有一定的資源使用週期的。比如在實驗剛剛開始的時候,使用者可能從大量的資料中採樣出來一個小的樣本集合,在這個小的樣本集合裡調通一個比較好的模型。在這個階段裡,機器的使用量其實是不大的,可能只有單台機器或者幾塊顯卡。之後,為了驗證這個模型的效果,可能會將全量的資料進行線下的訓練,也就是用一個專用的深度學習集群去做訓練,在這個階段可能會提交幾十到上百個電腦機器的訓練任務,這些機器每一台都可能有數塊顯卡。

使用者的模型線上下訓練中得以驗證正確,在大資料集上可以再對模型進行一些精細化調整,從而將模型打造成可以用來做線上預測的狀態。線上預測時使用的機器數量明顯要少於訓練時的機器數量,這是因為預測的時候,其實不需要將神經網路的前饋和回饋全跑一遍,也不需要去反復的跑訓練集。

在這個預測模型上線之後,收集到使用者提供的新的資料和真實的回饋。我們將這些日誌進行收集,從而進行一些增量訓練,進而讓我們的模型越來越好。在增量訓練之後,就是更新預測模型,預測和增量訓練的再一個迴圈過程。

可以看到一個初創企業如果只有少數的幾個深度學習任務,由於深度學習任務的週期性,專用的深度學習集群一定不會有非常高的使用率,大體上能有20%的使用率就已經很不錯了。但像在百度、穀歌之類的大公司,有各種各樣的產品線,這些產品線都需要使用深度學習進行一些提升,所以這些任務雖然有週期性,但是任務和任務之間發生的時間是不同的,所以就形成了各個任務之間的一個疊加效應。

我看群裡面大家基本上都是相關領域的研究者或者創業創新的人員。針對創業創新的人員,其實部署一個專用的AI集群成本是非常高的,然而使用率是非常低的。專用的AI集群在我們看來只適合於大型的互聯網公司,而且這個互聯網公司要有多種多樣的AI業務,如果有少量的AI業務的公司或者是初創型企業,我們推薦使用通用集群去做深度學習的訓練集群。

PaddlePaddle從專用集群到通用集群的改變

PaddlePaddle在去年9月份開源之前也是運行在百度內部的一個專用AI集群中。 在這個集群裡面,它的機器都是同構的,也就是說大家的CPU型號包括顯卡的型號都是一樣的,也是基於MPI進行調度,內網運行環境也是隔離的,也是穩定的。所以在去年9月PaddlePaddle開源之前,百度對PaddlePaddle的要求只有一個,就是儘量快,在儘量短的時間內完成更多的任務。PaddlePaddle還有一個特點是因為百度本身是一個搜索企業,PaddlePaddle為了服務百度更多的產品線,它在自然語言處理方面打造得會更好。

PaddlePaddle的運行效率可謂是刻在PaddlePaddle基因裡的一件東西,我們在開源之後,和Caffe還有TensorFlow做了一些benchmark,結果如下面三張圖所示。PaddlePaddle和其他框架在單顯卡上的速度都差不多,但是在多顯卡的速度上,Caffe是明顯要慢的,Tensorflow和PaddlePaddle其實在多顯卡的聚合上也差不多,PaddlePaddle會稍微快一點。但是在LSTM上,PaddlePaddle可以顯示出明顯的優勢,如下圖可以看出,PaddlePaddle在單顯卡的時候就已經比Tensorflow在LSTM網路結構裡要快一些,LSTM在4GPU下,可以看到PaddlePaddle實際上比Tensorflow要快很多。

但是單純的單機和集群跑得快,已經不是PaddlePaddle現階段的目標。因為我們相信,只有在通用集群上跑得更快,才能服務更多的中小企業,也才能夠讓更多的人接受PaddlePaddle,也才能夠給社會帶來更大的價值。

通用AI集群應該怎麼搭建?

專用集群其實是更常見的一種集群配置模式。比如說我們公司有存儲的需求,我就配置一個Hadoop集群去使用HDFS,有線下處理的需求,我再用Hadoop的Map-Reduce集群去做線下處理。對於網站的話,網站前端大家會配置一個nginx集群,再使用kalfka將網站的一些日誌收集下來,再給AI處理。

專用集群的架構就是把幾個事情分別部署在不同的機器裡,這些機器是相互隔離,不能互相訪問的。這樣做的好處其實是顯而易見的,因為不同應用分別跑在不同的物理機裡,可以避免不同應用之間的相互影響,但是壞處也很明顯,就是成本會很高,每個集群其實物理硬體的利用率是不夠的。

下面我以一個語音辨識服務舉例,說明一個通用AI集群應該怎麼搭建。

下圖是一個通用集群的簡單示意圖,這個集群裡有很多GPU的伺服器,也有很多CPU的伺服器,他們都部署在一個集群裡。在這個集群的機器之上運行著Kubernetes。Kubernetes是一個穀歌開源的分散式的作業系統。在2007年的時候,穀歌就使用集群作業系統Borg,通過混合部署各種來源的各種任務,將CPU的利用率一直維持在75%到80%左右。而Kubernetes開發之前是Borg開發團隊中的一部分,Kubernetes的設計繼承了Borg項目多年總結的經驗,是目前最先進集群作業系統。

這對企業的成本是一個極大的降低。之前我們說過普遍專用集群的資源利用率大概在20%左右,如果我們使用一個集群作業系統去管理集群的任務,那麼硬體利用率可以提升到75%到80%左右,這樣一個通用集群就相當於普通的四個左右的專用集群。

通用集群資料還是存儲在HDFS上,在HDFS上有一些有標籤的資料,這些資料送給PaddlePaddle做線下訓練。在這個系統的前端就是一個語音辨識的服務,使用者去提交自己的語音後返回一段文字。在這個前端語音辨識API裡使用者即時提交的語音資料就形成了一個即時的日誌,這個日誌就會被其他的進程收集下來,比如使用Kalfka進行收集,再去做一些線上的預處理,進而將這些資料繼續傳遞給PaddlePaddle做訓練。這樣PaddlePaddle既可以支援線下的大批量的資料訓練,也可以支援線上的即時的資料訓練。

在目前眾多的深度學習平臺裡似乎沒有一個平臺再去考慮如何在通用集群裡更好地進行訓練。這是因為大部分的深度學習平臺都是大企業開發的,在大企業中,通用集群的訓練對他們來講並不重要,但這對初創企業是至關重要的。

通用集群對深度學習系統的挑戰

挑戰主要有這麼幾方面:

(以下全文僅限鈦媒體專業用戶開放,點選連結:http://www.tmtpost.com/pro註冊鈦媒體專業版)

……

以上內容希望能夠讓大家明白,PaddlePaddle為什麼要做通用集群下的可伸縮訓練。

PaddlePaddle的規劃和目標

PaddlePaddle開源了以後,和作為百度內部的一個項目有非常大的差別,我們從原來只追求高性能和功能,漸漸的要過渡到下圖所示的幾個目標。我們所有的事情只有一個最重要的點,也就是中間的那個橘色的方塊,我們希望讓大家的業務變得awesome,變得非常炫,非常給力。我們評價PaddlePaddle“給力”的標準不是發了多少論文、被多少媒體提及,而是解決用戶痛點,讓用戶爽。

在這裡我也想介紹一些我們其他的工作,比如說我們寫了一本深度學習實戰手冊,目前已經寫完了八章,點選連結前往:http://book.paddlepaddle.org/ 在這個手冊裡,我們舉了八個例子,教大家深度學習應該怎麼入門和怎麼在真實的場景中使用。

每一個例子都是精心設計過的,比如說其中的一章情感分類。所謂情感分類就是將一個文本分類成正向情感還是負向情感,實際上就是一個簡單的文本分類問題。單純套用文本分類的模型,我們可以去解決如下圖所列各種各樣的問題。

PaddlePaddle作為一個年輕的開源深度學習系統,也面臨著非常多的挑戰。我們會以更加開放的心態來迎接所有的挑戰。PaddlePaddle作為一個開源軟體,所有的開發,包括設計和討論全在Github進行,目前已經有不少百度之外的團隊參與到開發中來了。其中有從事AI的公司,也有做分散式作業系統技術的公司。大家一起在Github上借review設計和提交代碼討論交流。

我們也希望可以看到更多的企業構建出更多支援AI的通用集群,幫助越來越廣泛的企業將他們的業務變得更好,更awesome。同時PaddlePaddle作為源於百度企業裡的深度學習框架,我們也會促進開源儘量多的工業界成熟模型,來説明更多其他企業來提升自己的業務。

鈦坦白群友互動:

1.請問人工智慧公眾服務如何保障使用者的隱私和資料安全?

於洋:我其實也不是這方面的專家,我談一下自己的想法。就PaddlePaddle而言,我們的策略是提供一個能夠在私有雲或者說在本地直接部署的PaddlePaddle,這樣使用者就不需要將敏感的資料傳遞給PaddlePaddle這個平臺。有一些論文給出的方案,是將深度學習訓練直接部署在手機上,將增量訓練好的模型上傳給伺服器,這樣使用者的資料就不需要從手機去上傳到伺服器,而是直接在手機上進行訓練優化。

2.如何保障訓練服務對併發任務的資源配置的公平性?

於洋:現在有一些開源的集群作業系統,比如Kubernetes使用這些集群作業系統,我們可以直接去調度CPU數和GPU數,也就是計算資源的數量,這樣每個用戶都可以有自己的一個配額。當用戶的配額超過了他應該用的配額的時候,他的任務就只能等待,當用戶的配額小於他實際上使用的配額,他就有可能會被調度,這些調度策略現在有非常成熟的開源平臺,都可以提供。

3.訓練的硬體高投入在本地部署時有辦法解決嗎?

於洋:訓練硬體的高投入我覺得還是有辦法解決的,解決的辦法就是我前面說的,將這個企業的大部分機器都放在一個特別大通用集群裡,這個集群既可以跑深度學習的任務,也可以跑其他的比如說web服務之類的東西。這樣深度學習的機器雖然說你買GPU很貴,但是他平時也可以被其他的任務所利用,不會完全浪費。

4.配額靠經濟杠杆在多用戶間協調嗎?有沒有定價策略,中小企業用得起嗎?

於洋:我記得亞馬遜的公有雲,也就是AWS上面應該是提供競價實例的,也就是說大家一塊去拍賣一個機器,誰出的價高誰就可以在這個時間段去用這個機器。這樣經濟杠杆就起作用了。

(本文獨家首發鈦媒體,根據百度資深工程師、Paddle API重構設計負責人于洋在鈦坦白上的分享整理)

………………………………

鈦坦白第33期,AI已來之機器學習2,今晚7點繼續!

報名聽課、交流:

鈦坦白目前有醫療健康、人工智慧、文娛社交、VR/AR、區塊鏈、支付創新、體育、雲計算、SaaS等九個專業群。

1、鈦媒體Pro專業版用戶,可以點選連結http://www.tmtpost.com/pro,登錄帳號,線上免費、任意選擇自己要進入的群,按提示操作;

推薦鈦客、贊助、合作:

請與鈦坦白負責人佳音聯繫,郵箱jiayinge@tmtpost.com

所以這種深度學習的專用集群地球上沒有幾個企業能真正玩得起。比如說百度的機器翻譯系統,在我們組訓練的時候,可能會用32塊K40的GPU做十天左右的訓練;穀歌的機器翻譯用了96塊K80做GPU訓練;AlphaGo其實用了50塊GPU訓練了一個月。這些昂貴的使用成本是初創企業所不能承受的,也是不應該承受的。

為什麼像百度、穀歌或者微軟之類的大公司可以承受這樣成本呢?其實原因還是比較簡單的,在這些公司,深度學習在產品線裡應用是比較廣的。比如大部分的百度產品線都使用了PaddlePaddle,利用深度學習提升這些產品的功能和使用者體驗。

大家如果調試過深度學習任務就可以很明顯知道, 深度學習任務是有一定的資源使用週期的。比如在實驗剛剛開始的時候,使用者可能從大量的資料中採樣出來一個小的樣本集合,在這個小的樣本集合裡調通一個比較好的模型。在這個階段裡,機器的使用量其實是不大的,可能只有單台機器或者幾塊顯卡。之後,為了驗證這個模型的效果,可能會將全量的資料進行線下的訓練,也就是用一個專用的深度學習集群去做訓練,在這個階段可能會提交幾十到上百個電腦機器的訓練任務,這些機器每一台都可能有數塊顯卡。

使用者的模型線上下訓練中得以驗證正確,在大資料集上可以再對模型進行一些精細化調整,從而將模型打造成可以用來做線上預測的狀態。線上預測時使用的機器數量明顯要少於訓練時的機器數量,這是因為預測的時候,其實不需要將神經網路的前饋和回饋全跑一遍,也不需要去反復的跑訓練集。

在這個預測模型上線之後,收集到使用者提供的新的資料和真實的回饋。我們將這些日誌進行收集,從而進行一些增量訓練,進而讓我們的模型越來越好。在增量訓練之後,就是更新預測模型,預測和增量訓練的再一個迴圈過程。

可以看到一個初創企業如果只有少數的幾個深度學習任務,由於深度學習任務的週期性,專用的深度學習集群一定不會有非常高的使用率,大體上能有20%的使用率就已經很不錯了。但像在百度、穀歌之類的大公司,有各種各樣的產品線,這些產品線都需要使用深度學習進行一些提升,所以這些任務雖然有週期性,但是任務和任務之間發生的時間是不同的,所以就形成了各個任務之間的一個疊加效應。

我看群裡面大家基本上都是相關領域的研究者或者創業創新的人員。針對創業創新的人員,其實部署一個專用的AI集群成本是非常高的,然而使用率是非常低的。專用的AI集群在我們看來只適合於大型的互聯網公司,而且這個互聯網公司要有多種多樣的AI業務,如果有少量的AI業務的公司或者是初創型企業,我們推薦使用通用集群去做深度學習的訓練集群。

PaddlePaddle從專用集群到通用集群的改變

PaddlePaddle在去年9月份開源之前也是運行在百度內部的一個專用AI集群中。 在這個集群裡面,它的機器都是同構的,也就是說大家的CPU型號包括顯卡的型號都是一樣的,也是基於MPI進行調度,內網運行環境也是隔離的,也是穩定的。所以在去年9月PaddlePaddle開源之前,百度對PaddlePaddle的要求只有一個,就是儘量快,在儘量短的時間內完成更多的任務。PaddlePaddle還有一個特點是因為百度本身是一個搜索企業,PaddlePaddle為了服務百度更多的產品線,它在自然語言處理方面打造得會更好。

PaddlePaddle的運行效率可謂是刻在PaddlePaddle基因裡的一件東西,我們在開源之後,和Caffe還有TensorFlow做了一些benchmark,結果如下面三張圖所示。PaddlePaddle和其他框架在單顯卡上的速度都差不多,但是在多顯卡的速度上,Caffe是明顯要慢的,Tensorflow和PaddlePaddle其實在多顯卡的聚合上也差不多,PaddlePaddle會稍微快一點。但是在LSTM上,PaddlePaddle可以顯示出明顯的優勢,如下圖可以看出,PaddlePaddle在單顯卡的時候就已經比Tensorflow在LSTM網路結構裡要快一些,LSTM在4GPU下,可以看到PaddlePaddle實際上比Tensorflow要快很多。

但是單純的單機和集群跑得快,已經不是PaddlePaddle現階段的目標。因為我們相信,只有在通用集群上跑得更快,才能服務更多的中小企業,也才能夠讓更多的人接受PaddlePaddle,也才能夠給社會帶來更大的價值。

通用AI集群應該怎麼搭建?

專用集群其實是更常見的一種集群配置模式。比如說我們公司有存儲的需求,我就配置一個Hadoop集群去使用HDFS,有線下處理的需求,我再用Hadoop的Map-Reduce集群去做線下處理。對於網站的話,網站前端大家會配置一個nginx集群,再使用kalfka將網站的一些日誌收集下來,再給AI處理。

專用集群的架構就是把幾個事情分別部署在不同的機器裡,這些機器是相互隔離,不能互相訪問的。這樣做的好處其實是顯而易見的,因為不同應用分別跑在不同的物理機裡,可以避免不同應用之間的相互影響,但是壞處也很明顯,就是成本會很高,每個集群其實物理硬體的利用率是不夠的。

下面我以一個語音辨識服務舉例,說明一個通用AI集群應該怎麼搭建。

下圖是一個通用集群的簡單示意圖,這個集群裡有很多GPU的伺服器,也有很多CPU的伺服器,他們都部署在一個集群裡。在這個集群的機器之上運行著Kubernetes。Kubernetes是一個穀歌開源的分散式的作業系統。在2007年的時候,穀歌就使用集群作業系統Borg,通過混合部署各種來源的各種任務,將CPU的利用率一直維持在75%到80%左右。而Kubernetes開發之前是Borg開發團隊中的一部分,Kubernetes的設計繼承了Borg項目多年總結的經驗,是目前最先進集群作業系統。

這對企業的成本是一個極大的降低。之前我們說過普遍專用集群的資源利用率大概在20%左右,如果我們使用一個集群作業系統去管理集群的任務,那麼硬體利用率可以提升到75%到80%左右,這樣一個通用集群就相當於普通的四個左右的專用集群。

通用集群資料還是存儲在HDFS上,在HDFS上有一些有標籤的資料,這些資料送給PaddlePaddle做線下訓練。在這個系統的前端就是一個語音辨識的服務,使用者去提交自己的語音後返回一段文字。在這個前端語音辨識API裡使用者即時提交的語音資料就形成了一個即時的日誌,這個日誌就會被其他的進程收集下來,比如使用Kalfka進行收集,再去做一些線上的預處理,進而將這些資料繼續傳遞給PaddlePaddle做訓練。這樣PaddlePaddle既可以支援線下的大批量的資料訓練,也可以支援線上的即時的資料訓練。

在目前眾多的深度學習平臺裡似乎沒有一個平臺再去考慮如何在通用集群裡更好地進行訓練。這是因為大部分的深度學習平臺都是大企業開發的,在大企業中,通用集群的訓練對他們來講並不重要,但這對初創企業是至關重要的。

通用集群對深度學習系統的挑戰

挑戰主要有這麼幾方面:

(以下全文僅限鈦媒體專業用戶開放,點選連結:http://www.tmtpost.com/pro註冊鈦媒體專業版)

……

以上內容希望能夠讓大家明白,PaddlePaddle為什麼要做通用集群下的可伸縮訓練。

PaddlePaddle的規劃和目標

PaddlePaddle開源了以後,和作為百度內部的一個項目有非常大的差別,我們從原來只追求高性能和功能,漸漸的要過渡到下圖所示的幾個目標。我們所有的事情只有一個最重要的點,也就是中間的那個橘色的方塊,我們希望讓大家的業務變得awesome,變得非常炫,非常給力。我們評價PaddlePaddle“給力”的標準不是發了多少論文、被多少媒體提及,而是解決用戶痛點,讓用戶爽。

在這裡我也想介紹一些我們其他的工作,比如說我們寫了一本深度學習實戰手冊,目前已經寫完了八章,點選連結前往:http://book.paddlepaddle.org/ 在這個手冊裡,我們舉了八個例子,教大家深度學習應該怎麼入門和怎麼在真實的場景中使用。

每一個例子都是精心設計過的,比如說其中的一章情感分類。所謂情感分類就是將一個文本分類成正向情感還是負向情感,實際上就是一個簡單的文本分類問題。單純套用文本分類的模型,我們可以去解決如下圖所列各種各樣的問題。

PaddlePaddle作為一個年輕的開源深度學習系統,也面臨著非常多的挑戰。我們會以更加開放的心態來迎接所有的挑戰。PaddlePaddle作為一個開源軟體,所有的開發,包括設計和討論全在Github進行,目前已經有不少百度之外的團隊參與到開發中來了。其中有從事AI的公司,也有做分散式作業系統技術的公司。大家一起在Github上借review設計和提交代碼討論交流。

我們也希望可以看到更多的企業構建出更多支援AI的通用集群,幫助越來越廣泛的企業將他們的業務變得更好,更awesome。同時PaddlePaddle作為源於百度企業裡的深度學習框架,我們也會促進開源儘量多的工業界成熟模型,來説明更多其他企業來提升自己的業務。

鈦坦白群友互動:

1.請問人工智慧公眾服務如何保障使用者的隱私和資料安全?

於洋:我其實也不是這方面的專家,我談一下自己的想法。就PaddlePaddle而言,我們的策略是提供一個能夠在私有雲或者說在本地直接部署的PaddlePaddle,這樣使用者就不需要將敏感的資料傳遞給PaddlePaddle這個平臺。有一些論文給出的方案,是將深度學習訓練直接部署在手機上,將增量訓練好的模型上傳給伺服器,這樣使用者的資料就不需要從手機去上傳到伺服器,而是直接在手機上進行訓練優化。

2.如何保障訓練服務對併發任務的資源配置的公平性?

於洋:現在有一些開源的集群作業系統,比如Kubernetes使用這些集群作業系統,我們可以直接去調度CPU數和GPU數,也就是計算資源的數量,這樣每個用戶都可以有自己的一個配額。當用戶的配額超過了他應該用的配額的時候,他的任務就只能等待,當用戶的配額小於他實際上使用的配額,他就有可能會被調度,這些調度策略現在有非常成熟的開源平臺,都可以提供。

3.訓練的硬體高投入在本地部署時有辦法解決嗎?

於洋:訓練硬體的高投入我覺得還是有辦法解決的,解決的辦法就是我前面說的,將這個企業的大部分機器都放在一個特別大通用集群裡,這個集群既可以跑深度學習的任務,也可以跑其他的比如說web服務之類的東西。這樣深度學習的機器雖然說你買GPU很貴,但是他平時也可以被其他的任務所利用,不會完全浪費。

4.配額靠經濟杠杆在多用戶間協調嗎?有沒有定價策略,中小企業用得起嗎?

於洋:我記得亞馬遜的公有雲,也就是AWS上面應該是提供競價實例的,也就是說大家一塊去拍賣一個機器,誰出的價高誰就可以在這個時間段去用這個機器。這樣經濟杠杆就起作用了。

(本文獨家首發鈦媒體,根據百度資深工程師、Paddle API重構設計負責人于洋在鈦坦白上的分享整理)

………………………………

鈦坦白第33期,AI已來之機器學習2,今晚7點繼續!

報名聽課、交流:

鈦坦白目前有醫療健康、人工智慧、文娛社交、VR/AR、區塊鏈、支付創新、體育、雲計算、SaaS等九個專業群。

1、鈦媒體Pro專業版用戶,可以點選連結http://www.tmtpost.com/pro,登錄帳號,線上免費、任意選擇自己要進入的群,按提示操作;

推薦鈦客、贊助、合作:

請與鈦坦白負責人佳音聯繫,郵箱jiayinge@tmtpost.com

Next Article
喜欢就按个赞吧!!!
点击关闭提示