沒想到，你是這樣的端智能

好久之前，我仍是個保潔員，直到有一天上帝說不了解端智能的保潔員不是好保潔員，因而我向隔壁小哥偷學了端智能這項技術，寫下了這篇文章，若有錯誤，請找隔壁小哥~

本文將談談端智能以及端智能在西瓜視頻的發展。你可能已經據說過端智能，這猶抱琵琶半遮面的樣子真是使人心癢，今天咱就扯下它的面紗看看。

從雲智能到端智能

可能有不少人納悶不是要聊端智能麼？怎麼還牽扯到邊緣計算了，莫不是爲了湊字數？實際上從雲智能到端智能的延伸實際上也是雲計算到邊緣計算的擴展。咱們知道雲計算自身有着許多的優勢，好比龐大的計算能力，海量的數據存儲能力等等。如今不少對外提供服務的 APP 本質上都是依賴各類各樣的雲計算，好比直播平臺、電商等等。但新型用戶體驗追求更加及時，穩定性的服務，這就促使咱們想要將服務儘量的部署在物理設備所在位置，最終推進了邊緣計算的發展。

從雲智能到端智能，本質也是如此。以無人駕駛爲例，總不能在駕駛過程因爲網絡波動致使汽車中止對路況的計算吧，或者說在萬分之一秒內還不肯定是要剎車仍是加速吧？

那究竟什麼是邊緣計算呢？邊緣計算與所謂的端智能又有什麼聯繫？繼續往下看~

邊緣計算

邊緣計算是一種致力於使計算儘量靠近數據源，以減小延遲和帶寬使用的網絡概念。一般來講邊緣計算意味着在雲端運行更少的進程，將更多的進程移動到本地設備，好比用戶的手機，IOT 設備或者一些邊緣服務器等。這樣作的好處就是，將計算放到網絡邊緣能夠最大程度減小客戶端和服務器之間的通訊量及保持服務穩定性。

不難發現，邊緣計算本質是一種服務，相似於咱們如今的雲計算服務，但這種服務很是靠近用戶，可以給用戶提供更快速的響應，簡單點說就是幹啥啥快。

須要注意的是，邊緣計算並不是用來取代雲計算的，若是說雲計算更注重把控全局，那邊緣計算則聚焦於局部，本質上邊緣計算是對雲計算的一種補充和優化，能夠幫咱們從數據源頭近乎實時地解決問題，凡是在須要減小時延或追求實時目標的業務場景下，都有它的用武之地，好比：計算密集型工做，人工智能等場景。這裏的人工智能的場景就涉及到咱們下面要說的端智能了。

端智能的本質

對於人工智能，想必咱們已經見怪不怪了，尤爲是以頭條/抖音/快手爲表明的應用，都是將機器學習用到極致的產品，此外像掃地機器，無人車等硬件設備也是人工智能落地的最佳示例。那咱們要說的端智能又是什麼角色呢？

和從雲計算到邊緣計算的發展相似，人工智能的發展也經歷從雲到端的過程，咱們常說的端智能實際上就是把機器學習放在端側去作。這裏的端側是想相對於雲端而言的，除了咱們常見的智能手機外，端側設備也包括各類 IOT 設備，嵌入式設備等，如語言翻譯器、監控攝像頭等，固然無人車也屬於該領域。

從 2006 年開始，人工智能進入第三次發展階段，並以 AlphaGo 前後打敗李世石和柯潔宣告新時代的到來，這背後得益於：

• 大數據的發展及硬件算力提高，CPU、GPU 及專用計算單元；
• 深度學習算法及框架不斷演進，從 Torch、Caffe 到 TensorFlow、PyTorch 等。

與此同時，端側設備一樣在算力，算法及框架有了日新月異的發展：

• 算力：CPU、GPU 性能提高，手機算力不斷增加，以及專門用於 AI 的神經網絡處理芯片逐漸成爲標配，已經可以不一樣程度上支持算法模型的運行；
• 框架：面向移動端的機器學習框架的誕生讓咱們能更輕鬆的在端側應用機器學習。在手機側，Apple 的 Core ML，Google 的 NNAPI 提供了系統級別的支持，除此以外業內也有不少優秀的端側框架：TensorFlow Mobile/Lite、Caffe二、NCNN、TNN、MACE、Paddle&Paddle Lite、MNN 及 Tengine 等；
• 算法：模型壓縮技術不斷髮展，其中量化已經很是成熟，基本可以實如今不下降精度的狀況下將模型縮小爲原來的 1/4~1/3；此外，針對端側的算法模型在不斷的優化事後，架構設計變得愈來愈成熟，對於端側設備的兼容性也越發友好。

固然，咱們都知道最終驅動雲智能和端智能發展的根本動力是實實在在的產品需求。從端智能的角度來看，由需求驅動的 AI 場景應用已經在軟硬件多方面成爲產品的主要賣點，好比手機攝像能力的提高，除了攝像頭等硬件的發展外，各類圖片處理算法的發展也功不可沒；再像抖音、快手等應用的各類模型特效，在簡化創做的同時也極大改善了產品的形態。

爲何要作端智能?

要知道爲何作端智能本質就是須要搞清楚當前雲智能面臨什麼樣的問題。正如以前所說，雲智能的發展創建在現代需求之上，它主要的優點是：

• 面向海量數據，這意味咱們能經過不斷的累積數據，尋求問題的最優解；
• 設備資源充足，算力強大；
• 算法規模龐大，空間不受限制；

但這種依賴雲端的架構方式也有着相應的缺陷：

• 響應速度：依賴於網絡傳輸，穩定性和響應速度沒法獲得保障，對於實時性要求高的狀況而言，該問題近乎於無解；
• 非實時性，脫離即時 Context，用戶敏感度差；

而端智能的優點剛好能做爲雲智能劣勢的補充：

• 響應速度快：在端側直接獲取數據進行處理，不依賴網絡傳輸，穩定性和響應度 OK；
• 實時性高：端側設備實時觸達用戶，不存在中間商賺差價，可以實時感應用戶狀態；

除此以外，因爲數據和生產和消費都是在端側完成，對於敏感數據能夠保證隱私性，規避法律風險；另外咱們能夠進行更精細化策略，有可能實現真正的實現千人千面。

端智能的侷限

前文咱們說了端側智能可以補充雲智能的幾個缺點，但它也有着本身的問題：

1. 和雲側硬件設備相比，端側資源&算力相對有限，沒法進行大規模持續計算，模型不宜過於複雜；
2. 端側每每只是單用戶數據，數據規模小，全局最優解難尋。此外因爲端側應用生命週期不可控，數據週期每每較短。

在這兩個條件的制約下，端智能每每意味着是隻作推理，即雲端訓練模型下發到本地後作推理。

固然隨着技術的演進，如今咱們也開始探索聯邦學習，它本質上是一種分佈式機器學習技術，主要但願在保證數據隱私安全及合法合規的狀況下，能夠有效解決數據孤島問題，讓參與方在不共享數據基礎上實現聯合建模，提高模型的效果。在這裏，端上能作的就不只僅是推理了還有學習過程。

5G 與端智能

以前有同窗提到過既然 5G 又快又好，那徹底不必搞端智能啊。這裏簡單談談我本身的理解。(若有不對之處，請找隔壁小哥)

5G 的高速鏈接和超低時延，目的在於幫助規模化實現分佈式智能，也就是雲-端智能一體化。來具體解釋下：5G 給端和雲之間的鏈接提供了更穩定，更無縫的的支撐，此時網絡就再也不是端雲互通的瓶頸了，但伴隨萬物互聯時代的到來，數據規模將會進一步暴增，進入超大數據規模的時代，此時服務端的算力就會成爲瓶頸，那麼此時在端側對於數據的預處理和理解也就更加劇要，這就須要端智能的介入。

舉個安防領域的例子，如今不少家庭攝像頭都支持雲存儲，若是咱們但願只在有人活動的時候纔會將視頻保存到雲端，該怎麼作呢？最好的方式是先在端側藉助 AI 進行圖像識別，而後將包含人的視頻片斷上傳到雲端，而不是先將全部視頻上傳到雲端再進行圖像處理（裁剪掉無用的視頻片斷），前者既能夠節省流量帶寬，又能夠節省雲側算力，這裏端側對視頻的處理也就是咱們剛纔說的對數據的預處理和理解。

對於 AR 來講，端智能爲 AR 提供交互能力，5G 則能知足 AR 須要的網絡傳輸能力，在這二者的加持下，具有互動性，高品質的 AR 技術會促進真實世界與虛擬環境的融合。

西瓜爲何作端智能?

上述內容純粹就是簡單介紹下端智能的前世此生，口水內容，簡單看一分鐘也就行。光說不練假把式，下面就簡單介紹下西瓜在端智能上的探索及落地，不少同窗知道咱們在搞，但不知道搞了個啥，今天咱就揭開這道神祕的面紗。首先來看咱們西瓜爲啥要作端智能。

在後文展開以前必須得先回答一個問題：西瓜爲何要作端智能？或者說，西瓜對於端智能的定位是如何的？

• 西瓜視頻做爲一款服務於廣大中長視頻消費用戶的產品，爲了知足不一樣細分羣體的需求必然要進行更精細化的產品運營策略，但以前咱們的的策略每每侷限於服務端策略或者實驗場景下得出的策略池，整個過程當中客戶端更多的做爲策略的接受者，被動響應且實時性不夠；
• 隨着西瓜視頻品質化專項的不斷推動，在不少場景下也取得了顯著的收益，伴隨而來問題就是簡單易行的策略已經再也不能知足咱們的胃口，要想再取得收益須要更細緻靈活的策略手段。
• 西瓜視頻一直在致力於爲用戶提供更優價值的內容，而播放做爲西瓜核心功能，致力於爲用戶打造更加智能化的播放器，創造更好的視聽環境，這無疑對咱們客戶端播放策略上提出了更高的要求。
• 對於視頻類產品而言，帶寬成本不容小視，咱們但願在不影響播放體驗的同時，能儘可能的減小無用帶寬的浪費。

介於上述幾個因素，咱們在用傳統客戶端技術解決問題的同時也對端側 AI 能力有了興趣，並於 20 年 8 月份開始調研，最終咱們確立下兩大目標：策略精細化和開源節流。

在這兩個目標的指導下，進一步結合西瓜的需求，咱們主要聚焦在下述兩個領域：

• 業務領域：充分發掘相關消費側(播放器)和創做側可優化決策點，下降業務成本，打造更智能化的決策體系；個別場景藉助端側 AI 能力打造更好的產品功能；
• 技術領域：嘗試端側 AI 能力和穩定性/編譯優化結合，自動分析並追蹤相關異常鏈；嘗試創建端側特徵庫，實現熱點功能/插件調度決策。

西瓜端智能

關於西瓜爲何下手端智能，大概是說明白了。但整體該怎麼下手落地呢?從表面上看無非就是將原有服務端的體系搬到客戶端來作，變化的只是先後端而已，但實際上從雲到端的遷移，不但涉及端雲技術鏈路的變化，並且更增強調不一樣領域工程師的合做：從客戶端角度出發，咱們關注工程架構及交互，但從算法角度來看，更加關注的數據和模型，這二者關注點的不一樣就決定了在端智能落地過程會存在比較大的困難。

基本流程

首先來簡單瞭解下端智能從雲到端的幾個階段：從雲到端，主要涉及算法、模型訓練、模型優化、模型部署以及端側推理預測。按照參與方來看主要涉及算法工程師和客戶端工程師，按照環境則能夠分爲雲端工程和客戶端工程，以下所示：

簡單歸納一下流程就是：首先算法工程師針對特定場景設計算法並訓練模型，而後對該模型進行優化，在下降模型體積的同時提升算法&模型執行效率，接下來在模型部署階段將優化過的模型轉換爲端側推理引擎支持的格式並部署到移動設備上，客戶端工程師針對該場景作算法移植及業務改造，並在合適的時機經過推理引擎加載模型並執行推理預測。

三座大山

上述咱們用一句話歸納了端智能落地的流程，但實際過程當中要遠比上圖提到的更復雜：

如上圖所示，不難發現端智能落地鏈路整體比較長，任何一個節點出現問題都會涉及比較長的排查路線；須要算法工程師和客戶端工程師的高度協做，但因爲算法和客戶端兩側的技術棧差別比較大，知識領域也存在比較大的差別，所以協做成本其實蠻大：

• 客戶端工程師對機器學習的算法和原理相對較少，這就意味着在不少時候客戶端把這塊當作黑盒，沒法針對端側設備的狀況和業務邏輯給出必定的參考意見，也沒法有效發現模型推理異常問題，對整體的運行結果不可預期；而若是涉及到算法移植這塊，問題就更多了，雞同鴨講的狀況也不是不存在；
• 算法工程師缺乏對端側設備的瞭解，端側設備環境不如服務端環境單一，設備環境複雜度，如何針對端上設計出更高效的模型，避免側推理影響到端側性能指標是重中之重；算法移植到端側是否符合預期也有待考量。

除此以外，端側推理引擎如何兼容複雜的端側設備，保證高可用性，實現一體化監控和模型部署等等也是端智能在落地過程要重點解決的問題。

端雲一體部署

前文咱們提到端智能在落地過程當中的三個問題：鏈路長，協做成本高，推理部署複雜。來具體分析看下問題及相應的解決策略：

• 對於算法設計到模型訓練，公司內的 MLX 平臺提供了模型訓練到服務端部署的能力，但並不支持雲上模型訓練到部署端上的鏈路，咱們須要將端上和 MLX 平臺進行打通可以實現模型部署及模型格式轉換；
• 傳統上端智能在端側依賴算法和模型兩部分數據，以前算法須要在雲測設計完成後移植到端側，存在必定的移植成本，且缺少快速部署、更新的能力；同時算法和模型屬於分離狀態，在算法和模型屢次迭代後，版本管理相對複雜，兼容性難以保障，若是算法和模型可以綁定動態下發，在減小協做成本的同時也能夠簡化鏈路；
• 端側環境複雜(尤爲是 Android 設備，各類配置不一，硬件環境也更爲複雜)， 推理引擎相當重要。在開始落地以前，咱們調研了 TensorFlow Lite、TNN、MNN 及 Paddle-Lite 以及公司內部的 ByteNN，最終咱們選擇 ByteNN。

爲何是 ByteNN?

1. ByteNN 做爲抖音、TikTok 的統一 AI 基礎引擎庫，已經在不少產品接入了，不須要額外增長體積；

2. 針對 ARM 處理，Adreno/Mali GPU，Apple GPU 進行定向性能調優，支持多核並行加速，性能 OK；

3. 終端兼容性廣，覆蓋了所有 Android 設備及 iOS，可用性較高；

4. 支持 GPU、GPU、NPU、DSP 等處理器，有廠商加持，通用性不成問題。

阻礙在面前的三座大山已然明瞭，要作的事情也很清晰。對於端智能，咱們和平臺 Client Ai 團隊的想法不謀而合，開始共同推進端智能在字節業務策略上的探索及落地。

藉助 Pitaya 方案，咱們能夠將更多的精力放在算法設計和業務場景挖掘中。Pitaya 是啥呢？簡單來講，它是將雲上 MLX 環境和端側環境打通，將算法和模型統一以算法包的形式部署到端上，並對端側特徵工程予以支持；同時端側內部集成運行容器，並驅動推理引擎(ByteDT、ByteNN)工做的一整套方案，其基本架構大概以下：

如今總體鏈路簡化了很多，咱們能夠更聚焦於業務場景的算法設計了，同時藉助於高效的運行容器，能夠實現算法包的快速部署，提升總體的迭代效率，端雲之間的聯動性更強：

西瓜視頻智能預加載

西瓜視頻橫屏內流在交互上能夠理解爲是一個橫屏版的抖音，是西瓜的核心消費場景，以下圖所示：

做爲西瓜視頻的核心場景，其播放體驗相當重要。爲了實現較好的視頻起播效果，該場景上了視頻預加載策略：在當前視頻起播後，預加載當前視頻後的 3 個視頻，每一個 800K。

800K 是實驗值，旨在不影響卡頓的狀況下儘量的下降成本，衆所周知，預加載在顯著提升播放體驗的同時也會帶來帶寬成本上的提高。對於 800K 你們可能沒有直觀感覺，以 720P 視頻爲例，假設平均碼率是 1.725Mbps，那麼 800K 的視頻大小也就是 4 秒左右。

方便起見，咱們經過一個圖來展現 3*800 的流程：

不難發現，只有在首個視頻的狀況下才會一次性預加載三個視頻，再日後就變成了增量預加載 1 個視頻的操做，端上始終保留 3 個視頻的預加載。

爲何是端智能的方案?

上述方案足夠粗暴簡單，但也存在很多侷限，即帶寬和播放體驗平衡不夠：

• 某些狀況下用戶不會看完 800K 的緩存視頻，簡單瀏覽標題或前幾秒內容後就劃到下一個，形成帶寬浪費；
• 或者當用戶想要認真觀看視頻時，有可能由於沒有足夠的緩存，容易致使起播失敗或者卡頓，進而影響用戶體驗。

此外上線預加載方案的時候，咱們的數據分析師也提到：減小預加載大小雖然能夠下降成本，可是卡頓劣化嚴重，短時間採用 3*800K 的固定方案，長期推進動態調整預加載大小方案上線。

除了傳統對預加載任務管理機制的優化外，咱們開始從新思考如何衡量預加載的有效任務率？

最理想的狀況是預加載的大小和播放大小一致，這樣視頻預加載的效率就是 100%。若是咱們預加載了 1000K，但用戶只看了 500K，那預加載的效率就是 50%，這浪費的 500K 可都是金燦燦的 💰；最糟糕的狀況是咱們預加載 1000K，但用戶壓根沒看，很差意思，此時預加載的效率就是鴨蛋了，咱們白白浪費了大把的鈔票。如今咱們來具體定義下用來評估預加載效率的公式：

不難發現，最理想的預加載策略就是使預加載大小和播放大小盡可能的匹配，用戶在起播階段會看多少，咱們就預加載多少，這樣既能提升播放體驗，又能減小帶寬浪費。

那如何來作呢？咱們但願基於端側 AI 的能力，對用戶操做行爲進行實時分析，進而實現調整預加載策略，在提升用戶播放體驗的同時，避免帶寬浪費。

優化方案

如上述公式所示，提升視頻預加載效率的關鍵就是預測用戶播放時長，使視頻預加載的大小和視頻播放大小盡量的接近。但預估每一個視頻用戶會看多久是一件很難的事情，會有不少個因素，好比用戶對視頻的感興趣程度，心理狀態等等。

拋開這些複雜的因素和變量，咱們來從新思考視頻預加載的行爲和用戶的瀏覽行爲之間的相關性。咱們假設存在兩種典型行爲的用戶：

• 快速滑動，短暫瀏覽: 用戶處於走馬觀花狀態，後續每一個視頻只會簡單瞄一眼，主動切換視頻的頻率較高；
• 慢速滑動，仔細觀看: 用戶傾向於觀看每一個視頻，主動切換視頻的頻率較低。

若是咱們在端上可以根據用戶的瀏覽行爲，經過模型判斷出用戶在接下來的瀏覽中是傾向於那種行爲的話，那是否是可幫助咱們進一步來優化視頻預加載策略了呢？此時預加載的流程就變成了以下所示：

除了經過端智能的方案提升預加載的效率，實現更精準的預加載調度外，在端上也有配套的業務調整和優化方案，好比聚合推理參數，模型觸發時機調整，預加載任務管理完善等手段，二者互爲補充。其中涉及到端智能的流程以下所示：

特徵工程

咱們經過線上用戶埋點數據，提取橫屏內流相關埋點數據進行標記並進行相關性分析，屢次迭代後最終篩選出與用戶瀏覽行爲的相關特徵。此外，藉助 Pitaya 端上特徵的能力，能夠方便的從不一樣的數據源中獲取實時特徵，並將其轉化成模型輸入的數據。

算法選型

機器學習的算法不少，從傳統的的決策樹、隨機森林到深度神經網絡，均可以用來實現端側 AI 的能力。但須要根據端側設備的狀況，在能知足場景效果和需求的前提下，重點考慮模型的體積和性能：模型體積越小越好，性能越高越好。好比在該場景下，用 DT 和 NN 均可以對用戶模式進行分類，但要綜合評估模型體積，性能和效果，最後決定採用那種算法。

推理預測

首先來看決策的時機，每滑到一個視頻而且在該視頻(非首刷視頻)起播後觸發算法包，等待決策結果並調度後續預加載任務。簡要流程以下所示：

在觸發推理時，主要依賴兩部分數據：一種是已經觀看過視頻的數據，另外則是後續未觀看視頻的詳情數據。前者是 Pitaya 主動經過埋點日誌獲取，後者則是須要業務方聚合後主動透傳。同時端上也須要考慮容錯機制，以便在算法包異常和推理失敗的狀況及時回滾策略。

預加載任務調度

決策結果給出後，咱們會根據最近兩次推理結果進行調度，主要是實現對預加載任務數量的調整(保留有效任務)及每一個預加載視頻大小的調整(增量調整)。此處涉及業務細節較多，就不作過多解釋了。

端側性能監控

除了端側常規的監控外(性能、業務指標)，還涉及模型指標的監控，好比執行成功率、推理耗時、PV/UV，固然也包括 accuracy 等模型的效果指標。

問題&挑戰

西瓜從去年 12 月份開始落地該場景，到明確拿到收益並全量上線，最終大概歷 1.5 個雙月，加上春節假期得有 2 個雙月了，這是爲啥呢?從開始的實驗大規模負向到正向收益，咱們遇到了那些問題？

推理耗時

前期屢次實驗中(v1.0~v3.0)咱們發現智能預加載組比線上策略在首幀耗時等指標上有劣化，好比首幀耗時上升 2ms 等。在經過各類技術手段及數據分析後，咱們最終定位出端上聚合推理參數、推理耗時等因素會間接影響大盤指標。爲此，咱們在端上提出了多種優化手段，如步長推理、異步調度、首推預熱、模型優化等方案，最終打平了相關指標，並肯定顯著收益。

帶寬成本

帶寬成本覈算受多個因素影響，容易存在誤差，尤爲是在像西瓜視頻這麼複雜的業務場景下，如何準確衡量該方案帶來的帶寬收益很是複雜。咱們在播放器及視頻架構團隊多位同窗的支援下，最終明確實驗組（95 分位）帶寬成本比線上組平均下降 1.11%。

峯值模型

不少狀況下，用戶的習慣是呈現階段性，爲了咱們也定向提出峯值模型，用於在用戶使用的高/低峯時間段內作出更細緻化的決策。（限於業務相關性太大，具體就不作解釋了。有想了解的同窗能夠加入字節一塊兒作同事！）

實驗收益

經過一系列的週期實驗和策略驗證，最終明確了智能預加載的收益:

• 總帶寬 -1.11%，預加載帶寬 -10%；
• 中視頻播放失敗率 -3.372%，未起播失敗率 -3.892%，卡頓率 -2.031%，百秒卡頓次數 -1.536%，卡頓滲透率 -0.541%。

除此以外，實驗組其它指標也有正向收益，但限於不夠顯著，咱們在此就不一一說明了。

現狀&總結

西瓜端智能現狀

當前智能預加載在 Android 端已經全量上線，同時 iOS 端也在接入過程當中。對於西瓜視頻而言，智能預加載只是個起點，咱們正在探索更多場景的可能性，爲用戶提供更智能化的播放體驗。

不管是雲智能仍是端智能，最終帶給咱們的是解決問題的新思路，坦率的說我也不知道端智能對將來意味着什麼，但當下肯定的是咱們能夠更好的將它和業務場景結合在一塊兒，尋求更好業務成果。

端智能也不是銀彈：不是說咱們用了它就完事大吉，就必定能夠拿到很好的結果。要想真正的發揮業務價值，更好的服務用戶，須要咱們更多的思考，將端智能放在該放的地方。

新思路，新嘗試

對於不少客戶端工程師而言，可能會存在疑問，咱們應該如何面對端智能，或者說它和咱們以前解決問題的方式有什麼不一樣？端智能不是一個從 0 到 1 的新生物，它只是雲智能發展到如今的天然延伸而已，其背後的體系仍是機器學習那一套，對於客戶端而言，它提供了一種全新的思考方式：從規則驅動到數據驅動，再到模型。咱們能夠藉助它在適當的業務場景尋求結合點，最終得到更好的成果。

那對於客戶端工程師而言，該如何切到這個領域呢，或者說，若是咱們想了解端智能能夠作點什麼?

瞭解基礎

正如咱們上面不少次提到的同樣，端智能只是雲智能發展的天然延伸，其背後仍然基本的機器學習，對於大多數的客戶端工程師而言，咱們的目標不是成爲機器學習領域的專家，能夠不去深刻研究各類算法模型，但系統的學習下理論只是仍是頗有必要的：

• 瞭解人工智能發展的過程，知道爲何當前深度學習成爲主流方向；
• 學習曾經流行的一些經典算法及可以解決的問題領域，你會發現以前一些問題的思考方式在當前深度學習中仍然是貫通的；
• 瞭解常見的神經網絡架構，知道不一樣網絡層(好比 CNN 中的卷積層/池化層等)的做用，總體又是怎麼組織起來的。

模型移植與實踐

系統性的知識基本上能夠經過閱讀該領域中的經典書籍而得到。除此以外還要多動動手，咱們能夠先找幾個示例，一步一步把訓練好的模型經過量化處理後移植到客戶端上去跑跑，也能夠嘗試在開源項目的基礎上去修改算法&模型，好比嘗試手寫數字識別，進行人臉檢測等，固然也能夠嘗試下量化交易，用本身的作的模型預測股票價格(固然，賠了別找我 😁)。

性能優化

端側設備，尤爲以手機爲例更注重交互，且受硬件限制較多，好比電量，存儲空間，算力等，這就意味着咱們的算法模型必需要具備很高的執行效率，同時模型體積不益過大，對應而來的就是性能優化在端智能領域一樣很是重要。

對於大部分客戶端工程師而言，除了傳統的基於業務場景的優化方案以外，還可能涉及到推理優化和部署。對於推理優化，除涉及到模型、框架外，也有須要根據硬件進行優化的狀況，好比 Neon/SSE/AVX 指令集優化、高通(Qualcomm GSP/GPU)、華爲(Huawei NPU)等硬件加速技術。

擁抱 AIOT

不管是邊緣計算仍是端智能，其載體不只僅是手機，還包含各類各樣的嵌入式設備。好比像安防領域的指紋鎖、監控攝像頭、無人機等等。對於咱們而言，能夠拿來練手的設備也不少，能夠是樹莓派，也能夠是搭載 TPU 芯片 Coral 開發版以及英特爾 ®Movidius™ 神經計算棒等等，利用他們能夠作出不少好玩的東西。

加入咱們

走過路過不要錯過，如今進入廣告時間，感謝兩位」廣告主「的打賞：直播中臺和西瓜視頻團隊，來看看咱們最近招聘需求吧：

直播中臺：咱們是負責爲字節跳動旗下的全部 App 提供直播服務的團隊，包括但不限於抖音、火山、今日頭條、西瓜視頻、皮皮蝦、懂車帝、番茄小說、番茄暢聽等。直播團隊不只僅負責直播平臺技術研發，爲直播提供穩定的基礎服務；還負責直播業務研發，致力於爲用戶提供最極致的直播體驗。

若是你對技術充滿熱情，想要和咱們一塊兒打造最極致的直播體驗，歡迎加入直播中臺，不管是社招大牛仍是 2022 屆秋招新生，內推都可以聯繫郵箱：liudongdong.rd@bytedance.com，郵件標題：姓名-工做年限-直播中臺-Android/iOS。

西瓜視頻：歡迎加入字節跳動西瓜視頻客戶端團隊，咱們專一於西瓜視頻 App 的開發和技術建設，若是你也想一塊兒攻克技術難題，迎接更大的技術挑戰，歡迎加入咱們！西瓜視頻客戶端團隊正在熱招 Android、iOS 架構師和研發工程師，在北京、上海、杭州、廈門四地，社招、校招、實習均有職位開放，歡迎投遞簡歷至郵箱：liaojinxing@bytedance.com，郵件標題：姓名-西瓜視頻-工做地點-Android/iOS。