隨著多媒體業(yè)務(wù)越來越多的涌現(xiàn)，每個(gè)業(yè)務(wù)都有不同的差異性特征。各大視頻云廠商遇到的最大挑戰(zhàn)是如何打造多媒體分發(fā)網(wǎng)絡(luò)，使用最低成本為多業(yè)務(wù)提供最優(yōu)質(zhì)網(wǎng)絡(luò)體驗(yàn)。本次分享邀請(qǐng)到了華為云算法專家——楊昌鵬老師，為我們介紹云邊協(xié)同在視頻場(chǎng)景下的探索實(shí)踐。

文 / 楊昌鵬

整理 / LiveVideoStack

大家好，今天我會(huì)從云廠商的角度與大家分享一下怎么去做全域調(diào)度，本次分享的題目是——全域調(diào)度：云邊協(xié)同在視頻場(chǎng)景下的探索實(shí)踐。

首先自我介紹一下，我本人是視頻領(lǐng)域的新手，之前主要的研究方向是云資源相關(guān)的調(diào)度優(yōu)化，包括VM調(diào)度，容器調(diào)度。最近一段時(shí)間主要在做視頻相關(guān)的調(diào)度，包括帶寬資源的規(guī)劃和調(diào)度相關(guān)的算法研究。

本次分享，主要包括以上四個(gè)方面，其中核心模塊是后三個(gè)，接下來，我將為大家一一進(jìn)行介紹。

#01

全域調(diào)度簡(jiǎn)介

分享的第一部分是全域調(diào)度的簡(jiǎn)介，大家對(duì)這個(gè)詞可能會(huì)比較陌生，實(shí)際上這是在上周華為TechWave上發(fā)布的分布式云的概念，分布式云其實(shí)就是一張網(wǎng)，把客戶所有不同類的請(qǐng)求全部納管起來。對(duì)客戶來講我們是統(tǒng)一的架構(gòu)和管理界面，但對(duì)我們來說，這里面需要很多的調(diào)度技術(shù)，全域調(diào)度就是里面非常核心的模塊。

說到調(diào)度，一個(gè)友商同事曾說，調(diào)度的本質(zhì)是修路，其實(shí)我不太認(rèn)可。說到調(diào)度一定要有兩個(gè)對(duì)象，一個(gè)是資源，另一個(gè)是業(yè)務(wù)，這兩個(gè)東西如果脫離任何一個(gè)來講，都不合適。如果調(diào)度的本質(zhì)是修路的話，那應(yīng)該還要看你有預(yù)算。我們可以先從云廠商的角度來看調(diào)度，業(yè)務(wù)是多樣性的，典型的主要包括點(diǎn)播、直播、RTC。每種業(yè)務(wù)的時(shí)延要求、質(zhì)量以及其承載的規(guī)模都是不一致的，同時(shí)每種業(yè)務(wù)采用的基礎(chǔ)架構(gòu)也有不一致性。比如點(diǎn)播的形式，基本采取通過存儲(chǔ)上面的Cache來換帶寬。直播和RTC都是長(zhǎng)連接，做調(diào)度時(shí)需要注意的是端到端的時(shí)延，所以非常不一樣。

我們?cè)倏促Y源，資源層也分為兩塊，其一是計(jì)算資源，其二是帶寬資源。在視頻云上涉及到整個(gè)全鏈路資源，包括端側(cè)，邊緣側(cè)，中心節(jié)點(diǎn)，公有云。這些資源在算力上明顯是由低到高的，同時(shí)還會(huì)有一些帶寬資源，在時(shí)延和成本上都是不一致的。所以我們的業(yè)務(wù)種類有很多，資源種類也有很多。

一個(gè)非常樸素的想法是，我們?nèi)绾螌?shí)現(xiàn)多業(yè)務(wù)和多資源的協(xié)同匹配，這其實(shí)在現(xiàn)實(shí)中是有案例的。比如我們的快遞網(wǎng)絡(luò)，一家公司可能有做快的票單，也有做慢的票單，實(shí)際上它們也是資源的協(xié)調(diào)。例如有些線路上，快慢件可以放一輛車上，有些快慢可以放到不同的獨(dú)享車輛上，這些都是從資源利用率的角度上考慮的。實(shí)際上我們?cè)粕厦媾R的調(diào)整會(huì)更大一些，因?yàn)槲覀儽旧頉Q策的顆粒度和時(shí)長(zhǎng)會(huì)有更高的要求，可能是毫秒級(jí)的，同時(shí)云上的業(yè)務(wù)種類眾多，使得我們整個(gè)調(diào)度問題會(huì)變得非常復(fù)雜。

這個(gè)復(fù)雜我們可以從兩個(gè)視角來看，一個(gè)是我們的云使用者來看，其實(shí)他的訴求是有“變”和“不變”兩種。第一個(gè)“變”是說，帶寬的資源需求量變化是非常大的，比如針對(duì)直播這樣的場(chǎng)景，晚上帶寬的需求量會(huì)突然變高。但是我們的用戶又希望在帶寬發(fā)生劇烈變化時(shí)，資源是可以及時(shí)獲取的。在春節(jié)時(shí)期，帶寬資源會(huì)有上百T的需求，那如何去應(yīng)對(duì)這種突發(fā)的資源請(qǐng)求呢？

另外業(yè)務(wù)的種類是不同的，不同的業(yè)務(wù)有對(duì)應(yīng)的SLA要求，甚至同一個(gè)產(chǎn)品，例如直播內(nèi)還有連麥，包括還有新的業(yè)務(wù)也在逐漸產(chǎn)生。它們?cè)诓煌瑘?chǎng)景下對(duì)時(shí)延的要求不一樣，那么我們?nèi)绾稳?yīng)對(duì)業(yè)務(wù)種類多樣性？

同時(shí)我們的業(yè)務(wù)本身地域上的分布式也是變化的，比如主播跟用戶的分布是非常不一致的。典型來講，我可能在華南地區(qū)和華東地區(qū)，我的用戶分布會(huì)比較多，那如何去應(yīng)對(duì)這些客戶的不同變化請(qǐng)求？

客戶對(duì)這種極致體驗(yàn)、低成本、高可靠性的訴求是一致的，他們永遠(yuǎn)希望云廠商以極低的成本和極致的體驗(yàn)來提供服務(wù)。

那從云廠商角度來看，也有兩個(gè)要求，其一是高質(zhì)量，我們首先要承諾給客戶最優(yōu)質(zhì)的的服務(wù)，同時(shí)在優(yōu)質(zhì)服務(wù)的前提下，盡量提高資源的復(fù)用效率。只有這樣，在資源效率提升以后，我們才會(huì)和客戶進(jìn)行降價(jià)，才會(huì)以更低的成本達(dá)到我們市場(chǎng)上的競(jìng)爭(zhēng)力。

上圖是從分布式云概念中截取的，分布式云里面涉及的資源有多種，包括華為云核心區(qū)，中心Region資源，包括熱點(diǎn)區(qū)域智能邊緣IEC資源，客戶機(jī)房布置的IES資源等。調(diào)度本質(zhì)問題變成了如何使得供給側(cè)和消費(fèi)側(cè)盡量的達(dá)到最優(yōu)平衡。這就需要做很好的用戶畫像，同時(shí)要對(duì)客戶整個(gè)計(jì)算資源、帶寬資源進(jìn)行提前的規(guī)劃和預(yù)測(cè)。

這其實(shí)是一個(gè)非常復(fù)雜的問題，為了方便大家理解，我來舉一個(gè)電力行業(yè)的例子。電力行業(yè)是怎么實(shí)現(xiàn)的呢？現(xiàn)在電力行業(yè)是非常智能的，我們大家用電、發(fā)電的循環(huán)迭代是非常快的，它其實(shí)在每一個(gè)環(huán)節(jié)都做了一系列的優(yōu)化才會(huì)使得整個(gè)系統(tǒng)是非常高效魯棒的。而云面臨的挑戰(zhàn)也是一樣的。

為了做這個(gè)設(shè)計(jì)，我們做了一個(gè)全域調(diào)度系統(tǒng)，當(dāng)前的全域調(diào)度有三個(gè)模塊。一個(gè)是資源調(diào)度模塊，主要負(fù)責(zé)計(jì)算資源的調(diào)度，里面有CPU內(nèi)存相關(guān)的調(diào)度。資源調(diào)度我們開源版叫Arktos，在開源版本中，我么提供一系列的基礎(chǔ)調(diào)度算法，比如說基于時(shí)延、地理位置分布等等。當(dāng)然，內(nèi)部用的版本會(huì)更加高效，能夠支持多目標(biāo)優(yōu)化求解以及跨端邊云協(xié)同資源調(diào)度。

我們還做了一個(gè)流量調(diào)度模塊，這里主要包含帶寬資源規(guī)劃以及帶寬資源調(diào)度。帶寬資源調(diào)度支持地理位置、時(shí)延、QoS、成本的調(diào)度。

同時(shí)我們針對(duì)視頻邊緣場(chǎng)景下AI任務(wù)，設(shè)計(jì)云邊協(xié)同的推理和訓(xùn)練框架Sedna，后面會(huì)具體介紹。

#02

流量調(diào)度

下面我們進(jìn)入流量調(diào)度的部分，這和業(yè)務(wù)本身特征高度相關(guān)，是比較難的模塊。

對(duì)于流量調(diào)度來講，我們的終極目標(biāo)是如何設(shè)計(jì)滿足多業(yè)務(wù)、多目標(biāo)SLA、異構(gòu)數(shù)據(jù)特征下的調(diào)度引擎。這里的多業(yè)務(wù)不用多說，云上的業(yè)務(wù)本身就是多種多樣的。多目標(biāo)指的是給用戶感受到的是用戶體驗(yàn)，但云廠商看的是成本，這其實(shí)是一級(jí)指標(biāo)，這在數(shù)學(xué)上是很難寫出來的，所以會(huì)有一系列的二級(jí)指標(biāo)。比如用戶體驗(yàn)可以分為首幀時(shí)長(zhǎng)、卡頓次數(shù)等等，成本可以分為回源率、帶寬趨勢(shì)等，這些二級(jí)指標(biāo)從數(shù)學(xué)上可以優(yōu)化出來的。

另外整個(gè)系統(tǒng)是具有異構(gòu)特征的，例如用戶空間特征，不同地方分布是不一樣的，例如流量特征，在不同時(shí)間段是有波峰和波谷的，同時(shí)每個(gè)站點(diǎn)、主播、用戶的分布，以及計(jì)算資源、帶寬資源、網(wǎng)絡(luò)特征也都是不一樣的。所以在這么復(fù)雜的系統(tǒng)下，如何去做調(diào)度，這其實(shí)是非常難的問題。

華為云流量調(diào)度當(dāng)前包含幾個(gè)核心模塊，第一是帶寬規(guī)劃模塊，第二是帶寬調(diào)度模塊。這兩個(gè)模塊理解起來比較抽象，我會(huì)用一個(gè)比較簡(jiǎn)單的例子來解釋。在一個(gè)房間內(nèi)，有兩個(gè)老人和三個(gè)小孩，買了一個(gè)蛋糕，這要怎么分呢？那通常老人是不太愛吃甜食的，小孩比較喜歡，所以我會(huì)一比四切分開，兩個(gè)老人一塊蛋糕，小孩四分之三的蛋糕，這就是帶寬規(guī)劃。具體到每個(gè)老人和小孩分多少蛋糕，這就是帶寬調(diào)度。

首先根據(jù)不同業(yè)務(wù)的特征，大顆粒度的規(guī)劃一下，比如直播，晚上帶寬量會(huì)比較大，而RTC白天的量比較大，因?yàn)镽TC會(huì)支持很多在線教育，那在帶寬復(fù)用上會(huì)有一定的削峰填谷的機(jī)會(huì)。這里就像是把蛋糕大塊分好，把老人的和小孩的區(qū)分開，但每個(gè)小孩具體拿多少，需要再做實(shí)時(shí)的決策。

在這個(gè)環(huán)節(jié)，我們其實(shí)做了個(gè)數(shù)學(xué)抽象，我們認(rèn)真研究了不同業(yè)務(wù)下的問題的特性，不管是直播、RTC還是點(diǎn)播，從數(shù)學(xué)問題抽象來講是類似的。可能業(yè)務(wù)的同學(xué)感覺到問題是不一樣的，但從數(shù)學(xué)描述上是一樣的，只不過是約束不一樣。比如，RTC和直播的區(qū)別在哪，RTC的約數(shù)就是200毫秒的時(shí)延，但直播可以允許是400毫秒，從數(shù)學(xué)上本質(zhì)是一樣的。所以之前看到同行做了三張網(wǎng)沒有協(xié)同，這其實(shí)是一個(gè)非常大的資源浪費(fèi)，華為云在做的是實(shí)現(xiàn)整個(gè)資源上的協(xié)同，不管點(diǎn)播、直播、RTC，我們?cè)谕军c(diǎn)、同帶寬上實(shí)現(xiàn)了資源環(huán)節(jié)上的協(xié)同。這才能保證在極致的體驗(yàn)下，給客戶更低的成本。

帶寬調(diào)度是一個(gè)實(shí)時(shí)的環(huán)節(jié)，實(shí)時(shí)的問題其實(shí)是非常BUG的，因?yàn)樾枰芸斓臎Q策，但很快決策的結(jié)果就是暴力拍規(guī)則，規(guī)則的缺點(diǎn)是對(duì)整個(gè)系統(tǒng)的效率上不是最優(yōu)的。所以我們即使在實(shí)時(shí)調(diào)度模塊，我們?cè)O(shè)計(jì)成了雙層架構(gòu)。

系統(tǒng)從架構(gòu)設(shè)計(jì)上會(huì)有Global模塊和Local模塊。Global模塊收集的信息可以盡量多，求解的速度可以慢一些沒關(guān)系，但因?yàn)槭侨忠曇?#xff0c;所以最后得到的solution里從全局來看是比較優(yōu)的。隨后，把全局最魯棒的信息，放進(jìn)Local模塊再做詳細(xì)的調(diào)度。舉個(gè)例子，Global的環(huán)節(jié)可能選擇了五個(gè)站點(diǎn)，比如上海地區(qū)接入5個(gè)CDN，這五個(gè)站點(diǎn)是成本和體驗(yàn)上的最優(yōu)。在Local環(huán)節(jié)做實(shí)時(shí)調(diào)節(jié)權(quán)重，這樣能夠彌補(bǔ)全局環(huán)節(jié)預(yù)測(cè)的不準(zhǔn)確性。

下面分幾個(gè)環(huán)節(jié)介紹流量調(diào)度，第一個(gè)是帶寬的規(guī)劃。

帶寬規(guī)劃就是解決每個(gè)業(yè)務(wù)應(yīng)該如何劃分帶寬，大家知道，點(diǎn)播直播RTC如果共站點(diǎn)會(huì)產(chǎn)生一些問題，點(diǎn)播的量很大，峰值時(shí)間段突然上升，如果是共站點(diǎn)就會(huì)把RTC擠下來，因?yàn)镽TC是最優(yōu)質(zhì)的服務(wù)，需要最先保障。舉個(gè)例子，在高速公路上，類似RTC這種優(yōu)先級(jí)比較高的，一定要設(shè)立專用通道，無論何時(shí)保證它是最優(yōu)先的，如果不解決這個(gè)問題，就會(huì)下降體驗(yàn)。所以我們做了帶寬規(guī)劃，對(duì)RTC直播體驗(yàn)專門保障。但這是很困難的，微軟NSDI最近的一篇論文顯示他們的這塊的技術(shù)已經(jīng)落地，其中的求解規(guī)模相當(dāng)大，在數(shù)學(xué)上非常難求解，尤其是95計(jì)費(fèi)使得整個(gè)問題非線性化的。我們?cè)趩螀^(qū)域內(nèi)做了嘗試，難點(diǎn)1（上圖）整塊的求解之后，我們的體驗(yàn)和成本都有很大的提升。

這個(gè)問題的難點(diǎn)還體現(xiàn)在，帶寬需求本身是動(dòng)態(tài)變化的，提前做需求規(guī)劃就要做提前預(yù)測(cè)，時(shí)間上可能預(yù)測(cè)不準(zhǔn)，比如什么時(shí)候到達(dá)峰值，峰值到達(dá)多少。目前預(yù)測(cè)準(zhǔn)確率只能達(dá)到90%左右。

第二個(gè)是接入環(huán)節(jié)。

接入環(huán)節(jié)其實(shí)是指派問題的變形版，工程上最簡(jiǎn)單的辦法是做就近接入，缺點(diǎn)是也許可以保證一個(gè)區(qū)域的時(shí)延，但不能保證另一個(gè)區(qū)域的時(shí)延，這是組合優(yōu)化的問題。華為聯(lián)合香港大學(xué)數(shù)學(xué)系一起對(duì)這塊做了系統(tǒng)研究，取得了較好的效果，最終能夠在全網(wǎng)環(huán)境下快速求解。這個(gè)問題的難度受幾個(gè)點(diǎn)影響，比如Areas的1號(hào)節(jié)點(diǎn)想要接入Nodes的1號(hào)、2號(hào)、3號(hào)......N號(hào)節(jié)點(diǎn)（上圖），歷史數(shù)據(jù)可能有顯示接入1號(hào)、2號(hào)節(jié)點(diǎn)的、但沒有顯示接入N號(hào)節(jié)點(diǎn)的。這時(shí)的做法應(yīng)該是首先在稀疏數(shù)據(jù)額下做精準(zhǔn)的Qos預(yù)測(cè)。總體來說，華為在這個(gè)問題上有了更好的思路并且已經(jīng)基本攻克，但是規(guī)模還比較小，我們認(rèn)為這是視頻的根技術(shù)，或者說核心問題。

第三個(gè)環(huán)節(jié)是回源問題，本質(zhì)上是路徑優(yōu)化問題。如何系統(tǒng)地解決需要我們將問題拆開來看，除了要找到一條路徑之外，還要到一個(gè)轉(zhuǎn)發(fā)節(jié)點(diǎn)。這里普及一個(gè)小知識(shí)，回源的意思是一個(gè)用戶請(qǐng)求視頻接入之后，發(fā)現(xiàn)這里沒有流，就要從其它地方將流拉回來，在物流、航空行業(yè)也存在這個(gè)問題，但它們都具有自己特性。

剛才的三個(gè)問題是基礎(chǔ)版本問題，但視頻調(diào)度尤其在和業(yè)務(wù)高度相關(guān)的調(diào)度，帶寬規(guī)劃是多業(yè)務(wù)的，但實(shí)時(shí)流量調(diào)度是針對(duì)每個(gè)業(yè)務(wù)的，這其實(shí)很像煙囪結(jié)構(gòu)（底層資源共享，頂層感知每個(gè)業(yè)務(wù)特性）。

整個(gè)視頻的成本來自兩個(gè)部分，接入成本和回源成本（BTS Costs）。回源降低成本的核心難點(diǎn)是在QoS保障的情況下實(shí)現(xiàn)不同特征的流的調(diào)度。華為和清華大學(xué)一起提出了Aggcast架構(gòu)來解決該問題。右圖是上線后的效果。帶寬回源成本降低了30%，同時(shí)體驗(yàn)也是更好的狀態(tài)。

#03

資源調(diào)度

資源調(diào)度主要指計(jì)算資源的調(diào)度，在視頻云的場(chǎng)景下會(huì)遇到很多類似例子，比如離線轉(zhuǎn)碼業(yè)務(wù)希望能用更便宜的資源進(jìn)行大規(guī)模離線轉(zhuǎn)碼，可以通過跨AZ調(diào)度，采用競(jìng)享機(jī)器進(jìn)行離線轉(zhuǎn)碼；視頻AI模型訓(xùn)練和推理時(shí)，會(huì)有跨云邊資源協(xié)同，這需要調(diào)度能夠跨云邊進(jìn)行調(diào)度。

我們做了一個(gè)全域資源調(diào)度器。當(dāng)前的開源版本是Arktos，開源鏈接是https://github.com/CentaurusInfra/arktos。

這里有幾個(gè)核心模塊，底層是Flow Monitor，可以實(shí)時(shí)監(jiān)控每個(gè)DC上整個(gè)資源池的狀態(tài)，如果資源利用率高可以動(dòng)態(tài)擴(kuò)容，遷移VM。資源收集器可以收集每個(gè)資源池的狀態(tài)，包括成本、地理位置，拓?fù)浣Y(jié)構(gòu)信息會(huì)全部反饋到央神經(jīng)大腦（Global Scheduler）。

業(yè)務(wù)拆解與部署模塊是當(dāng)有多個(gè)請(qǐng)求時(shí)，迅速?zèng)Q策應(yīng)該放在什么位置。

Global Scheduler包括兩個(gè)模塊（開源中沒有）。第一，資源聚類決策，根據(jù)地理位置對(duì)分布式云中的計(jì)算資源進(jìn)行聚類，例如客戶希望VM服務(wù)的是上海地區(qū)用戶，我們要根據(jù)地理位置做出決策；第二，分布式云選擇決策，根據(jù)聚類結(jié)果，針對(duì)每個(gè)資源組進(jìn)行打分，最后快速根據(jù)打分情況決策VM放置位置和數(shù)量。

決策好放置位置后，要進(jìn)行實(shí)時(shí)管理和調(diào)度，分為三個(gè)過程。

第一，資源與性能檢測(cè)器，可以實(shí)時(shí)監(jiān)測(cè)整個(gè)資源器中資源占用情況；第二，單地域資源管理器，當(dāng)根據(jù)Qos監(jiān)控發(fā)現(xiàn)不滿足業(yè)務(wù)數(shù)據(jù)時(shí)，可以在AZ或者邊緣節(jié)點(diǎn)上進(jìn)行資源伸縮的動(dòng)態(tài)決策；第三，多地域資源彈性伸縮器，本地資源也無法滿足時(shí)可以跨云邊調(diào)度。在離線轉(zhuǎn)碼業(yè)務(wù)下，實(shí)現(xiàn)了時(shí)延降低17%的同時(shí)降低33%的成本。

#04

云邊協(xié)同訓(xùn)練/推理

視頻上AI任務(wù)越來越多，視頻在端側(cè)編碼后會(huì)立刻傳到邊緣側(cè)，在邊緣側(cè)會(huì)做許多特性任務(wù)包括視頻審核、智能封面、智能視覺等一系列AI任務(wù)。但是邊緣側(cè)計(jì)算資源十分有限，隨著AI任務(wù)越來越多，會(huì)面臨如何在計(jì)算資源有限情況下完成更多AI任務(wù)的問題。有一個(gè)非常樸素的想法是：邊緣側(cè)計(jì)算資源有限，那是否可以在邊緣側(cè)做推理，云側(cè)做訓(xùn)練。這樣做就可以在很大程度上降低資源成本，同時(shí)滿足客戶對(duì)帶寬及時(shí)延的要求，也可以保護(hù)數(shù)據(jù)隱私。其中涉及到的技術(shù)有協(xié)同推理、增量學(xué)習(xí)和聯(lián)邦學(xué)習(xí)。

華為云邊協(xié)同推理框架Sedna，正是為了解決云邊協(xié)同推理和訓(xùn)練開發(fā)和部署難的痛點(diǎn)。Sedna整體框架已于KubeEdge AI SIG社區(qū)開源，鏈接為https://github.com/kubeedge/sedna。

Sedna有幾個(gè)核心部分：第一，Lib庫(kù)，面向AI開發(fā)者和應(yīng)用開發(fā)者，暴露邊云協(xié)同AI功能給應(yīng)用；第二，Workers，在云側(cè)和邊緣側(cè)執(zhí)行訓(xùn)練或推理任務(wù)；第三，GlobalMgmt，負(fù)責(zé)跨云邊的管理和協(xié)同，KubeEdge來做消息協(xié)同；第四，LocalController，主要負(fù)責(zé)本地通用管理，包括模型、數(shù)據(jù)收集。

Sedna是基于KubeEdge。KubeEdge是Cloud Native Computing Foundation（CNCF）正式開源項(xiàng)目（已晉升孵化階段），20+公司正在使用，是一個(gè)非常活躍的開源計(jì)算邊緣平臺(tái)。

KubeEdge是基于k8s的，意味著和云原生高度兼容，同時(shí)其可擴(kuò)展性非常強(qiáng)，采用聲明式API，CRD(Custom Resource Definition)，自定義Controller。比起原生k8s有增量?jī)?yōu)勢(shì)。我們實(shí)現(xiàn)了邊云協(xié)同，將云的能力延伸到邊緣，包括AI協(xié)同、數(shù)據(jù)協(xié)同、應(yīng)用協(xié)同、管理協(xié)同。KubeEdge易維護(hù)，輕量化、插件化邊緣框架，離線自治，自動(dòng)容災(zāi)，支持異構(gòu)硬件，與硬件解耦。

Sedna框架定位為“后端能力”,“被集成”，可集成到不同產(chǎn)品。

面向客戶分為兩類：

1、AI開發(fā)者，如果想使用邊云協(xié)同服務(wù)和功能，可以使用Sedna框架；

2、應(yīng)用開發(fā)者，可以直接使用邊云協(xié)同AI能力。

Sedna的定位不包括：

1、替代現(xiàn)有的AI框架，如TensorFlow，Pytorch，Mindspore等，我們是可以兼容的，因?yàn)镾edna是一個(gè)框架；

2、替代現(xiàn)有的邊緣平臺(tái)，如KubeEdge；

3、研究特定領(lǐng)域的算法，如人臉識(shí)別，文本識(shí)別等。

Sedna當(dāng)前包含三個(gè)模塊。

第一，邊云協(xié)同推理，在邊側(cè)資源受限時(shí)，如何提升整體推理性能。開發(fā)一個(gè)AI模型可能有多個(gè)版本，低精度版本或者高精度版本，可以通過Sedna把低精度版本布置在邊緣側(cè)，把高精度版本布置在中心云側(cè)。當(dāng)有某個(gè)圖像識(shí)別任務(wù)時(shí)，通過邊緣側(cè)輕量級(jí)模型進(jìn)行推理，如果置信區(qū)間比較低，將任務(wù)推到中心云大模型，從而實(shí)現(xiàn)比較好的整體推理性能。

第二，邊云協(xié)同增量學(xué)習(xí)。增量學(xué)習(xí)和遷移學(xué)習(xí)比較類似，增量學(xué)習(xí)是針對(duì)小樣本和非同分布下的模型，使得整個(gè)模型越用越聰明。舉個(gè)例子，有一個(gè)AI任務(wù)通過邊緣側(cè)模型做推理，發(fā)現(xiàn)效果很差，推到中心側(cè)后采用其它方式完成識(shí)別任務(wù)，完成后繼續(xù)在中心側(cè)訓(xùn)練后再推到邊緣側(cè)。Sedna在這部分支持比較好，易用性強(qiáng)。

第三，邊云協(xié)同聯(lián)邦學(xué)習(xí)，比如在做銀行類業(yè)務(wù)時(shí)，它希望數(shù)據(jù)不出邊緣，但同時(shí)要做AI訓(xùn)練，就可以采用聯(lián)邦學(xué)習(xí)框架，每個(gè)邊緣側(cè)都是一個(gè)模型，訓(xùn)練后將梯度同步到中心側(cè)，中心側(cè)訓(xùn)練后再推到邊緣側(cè)。

#05

總結(jié)

本次分享主要介紹了三個(gè)板塊。

1、流量調(diào)度：通過流量調(diào)度系統(tǒng)，可以支撐多業(yè)務(wù)、多目標(biāo)、異構(gòu)數(shù)據(jù)特征的調(diào)度；

2、資源調(diào)度：資源調(diào)度可以支持跨AZ的資源調(diào)度和云邊協(xié)同調(diào)度；

3、KubeEdge Sedna框架：框架面向AI和業(yè)務(wù)研發(fā)人員，提供邊云協(xié)同推理、邊云協(xié)同增量學(xué)習(xí)和邊云協(xié)同聯(lián)邦學(xué)習(xí)能力，為邊云協(xié)同AI技術(shù)挑戰(zhàn)的解決奠定基礎(chǔ)。

以上是我分享的內(nèi)容，謝謝！

詳情請(qǐng)掃描圖中二維碼或點(diǎn)擊閱讀原文了解大會(huì)更多信息。

總結(jié)

以上是生活随笔為你收集整理的全域调度：云边协同在视频场景下的探索实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。