⬆⬆⬆ 點擊藍字web
關注咱們算法
AI TIME歡迎每一位AI愛好者的加入!windows
1、What:如何理解移動與邊緣設備上AI system?微信
AI system是溝通上層算法應用以及底層硬件的橋樑,因爲新的算法、模型、AI應用的出現,底層就會有新的硬件產出,好比AI chip、GPU,這須要有更好的系統去溝通上層與底層,支撐上層的應用,並優化應用的性能。講者在WWW2019上發表的文章中指出,愈來愈多的深度學習應用運行在手機等終端設備上,這說明,隨着5G以及邊緣技術的發展,終端設備上的計算性能愈來愈強,愈來愈多的計算任務,好比ML和DL的推斷甚至訓練,更傾向於在終端設備上完成。網絡
2、WHY:爲何在Camera 上作視頻分析?oracle
研究動機在於,把更多的計算從集中式的雲服務器上off load到攝像頭自己。現代化社會在城市、學校、商場等都部署了大量的攝像頭,其採集的不少數據具備社會、商業價值,但分析視頻數據須要昂貴的計算設備以及開銷,好比GPU/TPU,使得攝像頭的計算資源沒有被充分利用,所以如何設計更好的模型、系統來分析這些視頻數據,同時在用戶隱私保護,減小網絡帶寬,開銷等方面得到很大的收益,成爲系統研究者關注的熱點問題之一。框架
視頻分析是一個成熟強大的技術手段,好比在道路上檢測行人車輛有助於智慧城市作城市規劃;在商場中檢測客戶的行走方向、駐留時間有助於商場作商品陳列規劃等。經常使用的視頻分析的場景集中在urban 以及residential areas,主要依賴於兩大硬件設施即,wired electricity以及 good internet。然而,在更加複雜,更natural的應用場景下不能高效應用。基於此,講者的出發點在於進一步研究將視頻分析的應用場景遷移到 rural , off-grid areas 的場景中,以適應沒有電的區域。dom
3、HOW:如何在有限能耗下實現高效的視頻分析?機器學習
爲了實現上述目標,徐夢煒等人提出了自治攝像頭的概念。該自治攝像頭具備兩個特色:
energy–independent: 即徹底基於綠色能源,太陽能或者風能;
compute- independent:主要在本地攝像頭上完成計算,不需上傳至服務器處理。
![](http://static.javashuo.com/static/loading.gif)
圖1 典型的自治攝像頭硬件配置
主要採用太陽能面板充能,以及內置可充電電池商用攝像頭採集和處理圖片,同時使用LoRa網絡協議將處理結果上傳雲端供客戶使用,其優勢在於能耗低,傳輸距離遠,缺點在於傳輸速率低。
爲了支撐自治攝像頭的運行,講者提出一種名爲elf的視頻分析處理系統,其針對性地爲object counting這一關鍵的視頻分析類型提供服務。好比,捕捉馬路上每小時經過的車輛,或者農場上羊的數量。那麼elf系統如何在自治攝像頭上運行?首先用戶須要安裝一個query到camera上,其中query須要指定兩個條件:object category 以及 time window。而後在運行時,攝像頭會不停的捕捉視頻,而且採樣特定的圖片幀,以這些圖片做爲輸入運行神經網絡,最終彙總每一個time window的運行結果。爲了在資源能耗十分有限的狀況下,提供儘量準確且有意義的結果,elf採用帶有置信區間(with confidence interval, CI) 的estimation來表示最終的處理結果。
能耗限制也給設計實現elf系統帶來了一個重要挑戰:如何在有限的能量之下,儘量準確地爲用戶提供一個counting的結果? 針對該挑戰,講者主要從如下三個方面進行分析。
Energy model:即energy budget,即便用的能量不能超過該限定。
Trade-offs:首先frame sampling,採樣的圖片以更低頻的方式進行處理,好比0.1fps;其次,NN selection,不使用最準確神經網絡,而是能耗更小的神經網絡模型。
Target:使每個time window 的處理結果的置信區間寬度儘量小(24-hr)。
![](http://static.javashuo.com/static/loading.gif)
圖2 elf系統的overview
攝像頭捕捉到一些視頻流,經過採樣將圖片輸入到神經網絡中,綜合每個神經網絡與圖片的處理結果, aggregate每個error 獲得一個完整的置信區間和object counts。
一)
如何在一個time window中作energy planning?
elf系統的核心在於如何設計reinforcement learning planner,其目的是決定每個time window中需處理圖片的幀數,以及對該time window進行神經網絡選擇,以最小化置信區間的寬度。講者將planner 的決策稱之爲count action,包括有NN Selection 和 # of frames to process。
![](http://static.javashuo.com/static/loading.gif)
![](http://static.javashuo.com/static/loading.gif)
![](http://static.javashuo.com/static/loading.gif)
圖3單一time window 中count action/outcome 對比曲線
圖中,橫座標爲energy,縱座標爲置信區間的寬度,趨勢爲使用越多的energy就能捕捉數量越多的幀數,處理結果就會越準確,意味着置信區間的寬度會愈來愈小。
其中,energy的計算公式以下:
Energy Consumption = E(NN) * frame_num
其表示,每個神經網絡處理一張圖片所需的energy與圖片數量的乘積。
從結果對比中,可獲得一個十分重要的observation,即:
當能耗較少(<1KJ)時,採樣的幀數(便可處理圖像的數量)限制告終果,所以可以使用一些不精確的神經網絡模型;
當能耗增長(1KJ< ~ <3KJ)時,(可處理圖像的質量)決定告終果;
當能耗繼續增長(>3KJ)時,yolov3的結果更好。
在不一樣能耗下,可以使用的最優神經網絡模型是不一樣的,應動態選擇最優模型作count actions。所以,考慮將圖中不一樣曲線的最優結果組成一個virtual曲線,稱之爲Energy/CI front,則系統可在Energy/CI front上尋找決策點,以最小化的置信區間寬度。
![](http://static.javashuo.com/static/loading.gif)
圖4 Energy/CI front的設計依據
然而,該構思引入了兩個直觀的問題:
Question1
問題1:如何構建Energy/CI front?
答:根據所選視頻每一幀圖片的處理結果以及神經網絡模型自己的準確率以獲得置信區間。
Question2
問題2:結果依賴所選視頻的characteristics。
答:置信區間還與所選擇視頻的characteristics相關,好比說,若是object比較多,獲得的方差標準差就會比較大,CI widths會比較大,具備較大的不肯定性。
二)
如何在cross- windows作energy planning?
上述介紹了在同一個time window中count action的決策結果,但在不一樣的時間段中,曲線的趨勢也不一樣(以下圖所示),這就要求planner需分別爲每個時間段作決策,而且不一樣時間段所使用的能耗也應異構。
![](http://static.javashuo.com/static/loading.gif)
圖5 Cross-windows 中count action/outcome 對比曲線
講者介紹了Oracle Planner,(best performance but unrealistic)。其核心思想在於,假設在已知每個time window 的Energy/CI fronts 的分佈的狀況下,將整個energy分紅多個小部分,採樣貪心算法,將每一個小部分的energy 分配給不一樣的time window,從而使time window 具備最大的置信區間寬度的減小量。
顯然Oracle Planner存在嚴重的問題,即沒法預先知道視頻的內容以及Energy/CI fronts的分佈。針對該問題,講者提出了 learning-based planner來學習Oracle planner,模型的框架圖以下所示。
![](http://static.javashuo.com/static/loading.gif)
圖6 learning-based planner的結構圖
A learning-based planner具備如下四個特色。
basis:強化學習策略;
rational:
視頻自己的時間以及daily的局部性;
offline training -> online prediction:
根據oracle planner 與online planner 輸出結果之間的差距優化決策;
Enforce energy budget:爲將來每個time window 預留30幀圖片處理能耗,以保證其在statistic 這個方法具備較準確的置信區間。
4、EVALUATION:實驗要驗證什麼?
elf系統實如今異構硬件上,主要硬件爲樹莓派4和MCU。硬件設備爲何要設計成異構的?主要是由於樹莓派可用於運行神經網絡,其能耗較高,大部分時候只須要喚醒MCU捕捉圖像,而使樹莓派處於睡眠狀態不消耗能量,只在一個time window結束時喚醒作圖像處理,可最小化能量的使用。
![](http://static.javashuo.com/static/loading.gif)
圖7 elf 測試系統的硬件原型
到目前爲止,實驗到底要驗證什麼?講者從如下三點對elf系統進行了全面對比。
(1)elf系統可否在能耗有限的狀況下,provide 有效的counts,並縮小置信區間的寬度?
分別在5段長視頻中,研究不一樣能耗限制下(1/2/3行分別表示天天10Wh/20Wh/30Wh的供能),elf系統中不一樣的baselines 模型的平均CI width。
![](http://static.javashuo.com/static/loading.gif)
圖8 有限能耗下平均CI width對比
(2)elf系統中關鍵designs驗證,即counts action 以及 learning-based planner 的優點對比?
處理結果只比Oracle planner的寬度寬5%,且每一個time window中處理的幀數與Oracle planner 很是接近。
![](http://static.javashuo.com/static/loading.gif)
圖9 與Oracle planner 處理幀數對比
(3)若採用更好的硬件加速器(處理每幀圖片時可以使用更少的能耗),對比研究elf系統的performance?
加速器可減小每一幀圖片使用的能耗,從而使CIs減小,說明加速器能有效提高elf系統性能。
![](http://static.javashuo.com/static/loading.gif)
圖10 不一樣加速器下CIs對比
綜上,講者提出了elf系統來爲town camera 上神經網絡的運行提供支撐,經過研究如何在一個window 和 cross-windows之間做fine-grained的energy planning,最終在有限能耗下實現高效的監控視頻分析。
5、提問與回答
請問這種攝像頭有可能成爲之後智能手機的主流嗎?
咱們這個工做主要仍是針對一些rural area的監控攝像頭設計的,可能在智能手機上沒有很好的應用。你們感興趣能夠看我mobicom 18的工做,是講智能手機上的視覺應用的。
喚醒樹莓派的能耗高嗎?
很高。首先,有些開發板實現了Linux的suspend/resume功能的話,這個on/off的能耗會低一些,但和MCU比仍是很高;其次,樹莓派沒有實現suspend/resume功能,意味着每次都是完整的開機/關機,大約須要好幾秒到幾十秒,能耗很是高。
移動端的AI計算,識別的準確率越低,那麼,可能的風險須要其餘的系統來彌補,那麼應用的難度就越大;好比:汽車自動駕駛,可能要增長防撞或防禦等級才行;是否有這個方面的綜合評估?
我以爲這個問題很好也很現實,你很適合作system research :) 不過通常學術工做只會考慮一個小點,你說的這些可能會在論文裏說起,但不會作很深刻的探究。其實如今也有人在研究是否能夠trust機器學習在單個樣本上的輸出,以指導後續的相關措施,我相信這是很重要的問題;
移動端AI識別中的人臉識別和號牌識別,也受到上面的限制,好比:識別好牌的燈光、位置角度等,須要欄杆、門檻等,可是,若是在車上增長一個發射裝置,好比相似Zigbee應用的有緣RFID就能夠解決這個問題,固然,問題是這類的植入裝置成本越低越好。外部AI識別和內部植入,是兩個方向,請教兩個方向是否作過對比?
這個問題也很好,基本上每一個方向都有各自領域的人在作,學術界其實主要關心把東西作出來,而後能達到怎樣的效果,具體哪一種方式更好可能還留待產業界的檢驗。我自己只作過基於視覺的系統問題,因此尚未作過這兩個方向的具體比較。
整理:劉美珍
審稿:徐夢煒
排版:田雨晴
本週直播預告:
![](http://static.javashuo.com/static/loading.gif)
![](http://static.javashuo.com/static/loading.gif)
![](http://static.javashuo.com/static/loading.gif)
![](http://static.javashuo.com/static/loading.gif)
AI Time是清華大學計算機系一羣關注人工智能發展,並有思想情懷的青年學者們創辦的圈子,旨在發揚科學思辨精神,邀請各界人士對人工智能理論、算法、場景、應用的本質問題進行探索,增強思想碰撞,打造一個知識分享的彙集地。
![](http://static.javashuo.com/static/loading.gif)
更多資訊請掃碼關注
(點擊「閱讀原文」下載本次報告ppt)
(直播回放:https://b23.tv/3mfiFG)
本文分享自微信公衆號 - AI TIME 論道(lundaoAI)。
若有侵權,請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」,歡迎正在閱讀的你也加入,一塊兒分享。