編者按： 內(nèi)容視頻化已是當(dāng)下行業(yè)公認(rèn)的趨勢。飛速增長的音視頻數(shù)據(jù)量對計算帶來了巨大挑戰(zhàn)，而當(dāng)下云、端算力的局限性，也制約了音視頻數(shù)據(jù)的價值挖掘。本次分享將圍繞上述問題，介紹依托 5G 等基礎(chǔ)建設(shè)興起的邊緣計算如何為音視頻應(yīng)用松綁，以及網(wǎng)心科技在這一方向上的實踐歷程。

文 / 曾偉紀(jì)

整理 / LiveVideoStack

大家下午好，非常高興能夠再次來到 LiveVideoStack 和大家進行一個交流。我們借助云端的算力可以讓終端得到一個炫酷的體驗，這是我認(rèn)為過去十多年以來技術(shù)發(fā)展非常重要的一點，今天我的分享也和這個問題有關(guān)。

首先做個簡單的自我介紹，我早年在成立不久的騰訊云做過云端后臺的服務(wù)，后來在 2015-2016 年左右，我才開始做現(xiàn)在的這些事情，再后來我才知道，這叫邊緣計算，從那時候開始，我和音視頻結(jié)下了不解之緣，一直持續(xù)到今天。所以今天，我想給大家分享 “以泛在算力挖掘泛在價值”。

1、流失的泛在價值

首先，我們來看價值流失的問題。內(nèi)容視頻化是一個大趨勢，人是視覺動物，我們對視頻的接受程度和我們對視頻的喜愛程度是毫無疑問的。無處不在的視頻也就代表了無處不在的價值，這也是我們題目中所說的泛在價值。這個潛力有多大呢？我們來看一個數(shù)據(jù)。

來自 IDC 的統(tǒng)計數(shù)據(jù)顯示，到 2025 年創(chuàng)建的數(shù)據(jù)會達到 175ZB，這相當(dāng)于 2022 年的兩倍，而當(dāng)中以視頻為主的非結(jié)構(gòu)化數(shù)據(jù)占到 80%，視頻蘊含的價值將是巨大的，這也是我們今天所提到的泛在價值。這些價值又是怎么挖掘出來的？我們可以看一下數(shù)據(jù)的生命周期。

從上圖顯示，我們數(shù)據(jù)的創(chuàng)建正在更多的趨向于邊緣，同樣的數(shù)據(jù)的存儲也會向中心和邊緣轉(zhuǎn)變，而終端的占比會下降。但是我們整個數(shù)據(jù)的處理一直是偏中心，我們的消費又一直在端側(cè)，這樣就出現(xiàn)了算力的錯位。

我們知道視頻處理的數(shù)據(jù)量是非常大的，算力的需求也非常高，那么這樣的一個錯位就會導(dǎo)致在實際應(yīng)用中，數(shù)據(jù)追著算力跑，這就會產(chǎn)生大量的算力搬運成本。除了成本之外，其中產(chǎn)生的延時也限制了更多的實時的場景體驗；既然終端算力是有限的，為什么沒法放到云端呢？就是因為延遲。我們可以看到這么一組數(shù)據(jù)，所有生產(chǎn)的數(shù)據(jù)中，有 44% 根本沒有被采集，而被采集的數(shù)據(jù)中也只有 57% 的數(shù)據(jù)得到利用，也就是總共也只有四分之一多一點的數(shù)據(jù)最后能被挖掘，這顯然是一個巨大的價值流失。那么這個問題的原因是什么？

目前，云計算是現(xiàn)在計算的一個主流，那這個鍋是云計算的嗎？云計算實際上是開創(chuàng)了云端算力的模式，把云端算力投射到終端上，這是一個技術(shù)上的巨大飛躍。它的問題在于現(xiàn)在的云計算更多基于中心的超大規(guī)模的 IDC，所以這種中心化的布局現(xiàn)在遇到了瓶頸，需要進一步的發(fā)展，所以就產(chǎn)生了下沉的需求。比如 CDN 技術(shù)，就是將傳輸下沉到離端更近的地方，改善傳輸質(zhì)量?，F(xiàn)在我們做的多數(shù)據(jù)中心接入架構(gòu)，其實也是在做計算方面的下沉，但是就僅僅到這一步嗎？為什么我們不能再進一步？是因為沒有算力嗎？

根據(jù) 2022 年的 AWS Invent 大會上發(fā)布的數(shù)據(jù)，每一百臺出貨的服務(wù)器中，只有四臺是流向云計算廠商。另外，我們終端處理器的性能在這些年飆升的非?？?，而且，我們終端的出貨量也維持了很高的水平，在不斷上漲。所以 IDC 以外的算力應(yīng)該是普遍存在的，量也非常充足，因此這個端和邊的設(shè)備也是不背鍋的。

那么還有什么原因？會是網(wǎng)絡(luò)連接嗎？我們知道運營商的網(wǎng)絡(luò)非常復(fù)雜，而其實我們互聯(lián)網(wǎng)做的事情非常簡單，就是把所有電腦都連起來。在把所有電腦都連起來的方法中，做 Mesh 顯然最直接，也就是每兩臺電腦之間都拉根線，但是，為了不被網(wǎng)線淹死，我們的網(wǎng)絡(luò)更多會做成樹狀的結(jié)構(gòu)，底層做一個樹狀的收斂。

再具體到每個省會對應(yīng)到它附近的一個核心節(jié)點，全國的核心節(jié)點也就這幾個，在核心節(jié)點以下，其實都是層層的樹狀匯聚的，在核心節(jié)點之間，鑒于核心節(jié)點也不多，所以我們?yōu)榱诵?，就可以把它做?Mesh 的結(jié)構(gòu)?；谶@個結(jié)構(gòu)，我們就知道網(wǎng)絡(luò)里任意兩點之間大概率不是直聯(lián)，基本上只有核心點之間有 Mesh 的才是直聯(lián)。所以，實際上在城域網(wǎng)，同城的兩個節(jié)點互聯(lián)，只要上升到城域網(wǎng)，再下降回去就可以了，這個延遲大概是在 7 毫秒以內(nèi)。而如果是同省的話，就要上升到省級核心交換機，大概是 10 毫秒的延遲水平?？缡×艘院螅筒淮_定了，因為需要去經(jīng)過這些省，兩個省之間，如果掛在同一個核心節(jié)點下，那還稍微好一點，只要上升到省核心節(jié)點，再下沉就行了。

鑒于運營商的省公司是獨立運作的，互相之間的互聯(lián)經(jīng)常有不確定性。如果兩個省掛接在不同的全國核心下方，路徑顯然會更長，跨區(qū)實際上是長途跋涉。我們做 CDN 就是應(yīng)對這種網(wǎng)絡(luò)情況，在一個復(fù)雜的網(wǎng)絡(luò)拓?fù)渲袑ふ乙粭l相對靠譜、質(zhì)量好一點的路去把數(shù)據(jù)傳輸過去。我們一般是認(rèn)為資源下沉到同省是一個從成本和質(zhì)量上比較平衡的做法，因為同省內(nèi)的互聯(lián)是比較有保障的，那么跨中心就已經(jīng)不太靠譜。如果進一步，我們想要跨運營商呢？

這是國內(nèi)運營商互聯(lián)的情況，比如電信和聯(lián)通兩個點想要互聯(lián)，只有這幾條路可以走，首先路肯定是變長了；其次，由于三大運營商之間的關(guān)系，互聯(lián)基本上質(zhì)量難以保證，成功率基本看天。我們?nèi)プ鰝鬏?，走到跨運營商的步驟，基本上屬于死馬當(dāng)活馬醫(yī)，除非我們?nèi)ゲ少徱恍┍容^昂貴的互聯(lián)資源，比如三線機房，BGP 機房，這樣去找一條穩(wěn)妥的路去做互聯(lián)，當(dāng)然成功率就非常的高。講到這，我們就破案了。

其實我們算力接入門檻主要的問題是跨運營商乃至跨省的連接質(zhì)量都難以保障，因此我們?nèi)プ鲈朴嬎慊A(chǔ)設(shè)施的構(gòu)建時，顯然我們的首選是把算力接入核心節(jié)點和互聯(lián)節(jié)點，圍繞著這幾點轉(zhuǎn)，它想下沉就很困難，需要克服很多網(wǎng)絡(luò)連接的問題。另一方面，如果想要把資源下沉，算力就很分散，分散的算力對業(yè)務(wù)開發(fā)也提出了更高要求。為了解決算力分割問題，邊緣計算就閃亮登場了。

2、邊緣計算與泛在算力

我們前面提到過，算力分布是不太合理的，這導(dǎo)致了很多價值的流失。那么現(xiàn)在為什么邊緣計算能夠興起？

邊緣計算興起的先決條件是網(wǎng)絡(luò)。我們網(wǎng)絡(luò)資源其實是在不斷下沉的，在固網(wǎng)這塊相對還是比較容易，然后現(xiàn)在的問題是我們比重越來越大的移動網(wǎng)絡(luò)。移動網(wǎng)絡(luò)在過去 3G、4G 時代，我們手機上發(fā)出一個數(shù)據(jù)包進入互聯(lián)網(wǎng)，需要上傳到省網(wǎng)才能接入，與公網(wǎng)還不一樣，固網(wǎng)加寬是可以接入手機網(wǎng)的，這個情況在 5G 時代才有所改變。5G 有了 UPF 和 MEC 技術(shù)，使得手機發(fā)出的數(shù)據(jù)包可以在城域網(wǎng)就接入互聯(lián)網(wǎng)，這就使得更短路徑連接成為可能。此外，5G 的空口改進，把帶寬的延遲水平大大地拉進到了和固網(wǎng)接近的水平，因此，我們在一個更靠近邊緣的地方去部署算力，去接入算力得到了一些必備的條件。

接下來就是邊緣的算力條件，這個我們之前講到過，邊緣不缺算力。

再下一步就是我們的應(yīng)用開發(fā)能力。你底層有了這些資源，那你怎么去用它呢？近年來，分布式技術(shù)的發(fā)展使管理大量邊緣節(jié)點成為可能。然后就像我們剛才提及的邊緣的復(fù)雜網(wǎng)絡(luò)條件隨著傳輸技術(shù)的發(fā)展，比如新的傳輸協(xié)議等等，使得邊緣的復(fù)雜網(wǎng)絡(luò)不再會是一個很難跨越的障礙。最后就是云原生等技術(shù)使分布式應(yīng)用開發(fā)難度降低，我們可以用起來大量異構(gòu)且分散的資源，所以就有了邊緣計算。

這是很多權(quán)威機構(gòu)對于邊緣計算的定義，其實就是把算力下沉，但它帶來的效果確實是實打?qū)嵉?。我們可以把算力部署到更多的位置，它可以覆蓋本身所處位置上的數(shù)據(jù)，同時它也可以以更低的延遲去覆蓋其他位置的數(shù)據(jù)。

那么再具體一點，根據(jù) Linux 基金會對邊緣計算的概括，邊緣計算類似于基于 5G、AI 一些硬件能力，以及云原生一些開發(fā)能力，邊緣計算可以運用到什么場景？互聯(lián)網(wǎng)沉浸式體驗，邊緣自治是典型的 Use case。

概括一下，云計算突破了終端對算力的限制，邊緣計算則填補了端與中心之間的算力真空，實現(xiàn)了算力泛在化，使得我們可以更好地去挖掘泛在價值。

3、網(wǎng)心科技邊緣計算實踐

在邊緣計算實踐上，網(wǎng)心 2014 年底就開始從迅雷業(yè)務(wù)改造入手，然后，我們的業(yè)務(wù)從直播切入，去做一些 TO B 的服務(wù)，從長視頻到中視頻再到短視頻的視頻點播，難度也是越來越大。除了音視頻，我們也在開始去拓展更多的邊緣計算場景。大家知道，邊緣計算的概念在 2016 年左右成型，在這兩年成為了風(fēng)口，而網(wǎng)心實際上已經(jīng)在這個方向做了快八年，中間也經(jīng)歷了云計算的大發(fā)展，整個行業(yè)加劇了競爭，同時也經(jīng)歷了技術(shù)變革。

接下來，看一下我們積累下來的整體服務(wù)架構(gòu)。我們在上層提供的產(chǎn)品服務(wù)，包括像云計算里的 CDN，以及函數(shù)計算、安全、存儲等服務(wù)。其實接入和在傳統(tǒng)云里的服務(wù)并沒有太大的區(qū)別，感知是很小的，但是它在特定的場景下，會比傳統(tǒng)的云服務(wù)效率更高。這些效率來自于底層，我們底層去覆蓋云邊端一系列的計算資源，云端自然不用說，在邊緣側(cè)我們會有更下沉的數(shù)據(jù)中心，我們還有來自運營商的一些邊緣機房，以及一些企業(yè)現(xiàn)場的機房，這都會被納入到計算網(wǎng)絡(luò)里。

在端側(cè)我們有一些自研的邊緣硬件資源，同時，我們也可以把很多生態(tài)的硬件納入到基層網(wǎng)絡(luò)中來，比如說家里很常見的 NAS，路由器，甚至于電視機，機頂盒還有個人 PC，我們有非常多這樣的生態(tài)節(jié)點。那么如何去把這些能力、形態(tài)、位置各異的底層資源包裝成一個通用的云服務(wù)，讓上層接入沒有太多感知？這其實就是靠中間邊緣計算平臺的這一層。

回顧網(wǎng)心邊緣計算落地的路線，是從邊緣 CDN 切入，基于邊緣 CDN 再去把底層的 IaaS 層開放出來，初期是面向邊緣傳輸?shù)?IaaS。接下來，我們會在此之上構(gòu)建一個邊緣容器平臺，能夠去做更多更廣泛的計算場景，不再僅僅是傳輸，最后是邊緣云原生，能夠讓上層的業(yè)務(wù)應(yīng)用更方便地接入到邊緣計算的網(wǎng)絡(luò)層。

首先，我們來看一下。第一步，我們做的邊緣 CDN 的事情。前面其實也提及過，CDN 做的事情實際上就是下沉，用戶的內(nèi)容更多是在中心的云機房，CDN 就是會把它進一步下沉，比如說下沉到省網(wǎng)的級別，來獲得一個更好的傳輸體驗。邊緣 CDN 原理是一樣的，只是我會把內(nèi)容去做更加進一步的下沉，下沉到城域網(wǎng)，甚至于下沉到接入網(wǎng)的邊緣設(shè)備上去。別看只是多了一兩層，但其實它的復(fù)雜度是成倍上升的。

我們來看一下，做這個事情需要突破的關(guān)鍵技術(shù)點。第一個是智能調(diào)度 / 部署，調(diào)度和部署關(guān)系非常大，部署是如何把要分發(fā)的資源去分布到這些設(shè)備上去，如果請求的時候，你能夠命中一臺附近的設(shè)備，顯然你的傳輸效果是比較理想的，這樣就不需要去做一個回源，去回到中心機房，產(chǎn)生很高昂的成本以及很高的延遲。既然我們把這個內(nèi)容進一步下沉到城域網(wǎng)，甚至接入網(wǎng)，我們網(wǎng)絡(luò)的深度、復(fù)雜度自然是一個指數(shù)級的提升。所以，在這塊，我們就需要更加細(xì)粒度的調(diào)度和部署的策略。

此外，就是全聯(lián)通網(wǎng)絡(luò)。邊緣的網(wǎng)絡(luò)是非常復(fù)雜的，不僅是剛才所說的延遲等問題，還存在大量的內(nèi)網(wǎng)穿透、防火墻穿透等問題，這塊也是需要花非常多的精力去解決的。

接下來是，HARQ 加上多路徑傳輸。這其實也是為了應(yīng)對在 IDC 以外，無 SLA 網(wǎng)絡(luò)，我們必須采取更激進的策略才能保證傳輸?shù)姆€(wěn)定性。

最后，就是節(jié)點自適應(yīng)和鏈路自適應(yīng)。我們在 IDC 里做應(yīng)用的時候，我們的設(shè)備往往都相對比較標(biāo)準(zhǔn)，它有多少能力，它的算力有多少，以及它的帶寬有多少，這些都是事先能夠確定的。但是在邊緣網(wǎng)絡(luò)里，這些設(shè)備是多種多樣的，甚至有很多設(shè)備是無法預(yù)先得知的，我能給你多少算力，我能具備多少帶寬，這些東西都需要我們自己有一套探測和自適應(yīng)的機制去保證既能夠把設(shè)備能力充分利用，又避免把它用的太狠了，出現(xiàn)質(zhì)量問題。

在解決了這些問題之后，我們才構(gòu)建起來一個可用的邊緣 CDN 網(wǎng)絡(luò)，在我們的服務(wù)場景下，質(zhì)量可以和傳統(tǒng) CDN 不相上下，這在我們客戶的 QoE 數(shù)據(jù)中也得到了驗證。但是只做一個 CDN 可能是不夠的，它更多的意義是什么呢？

我們知道，CDN 已經(jīng)很卷了。如果我們只是千辛萬苦做出來一個邊緣 CDN，我們把質(zhì)量稍微提高一點，價格稍微降低一點，這顯然不是我們的星辰大海。在 2018 至 2019 年，我們的邊緣 CDN 基本上成型了，下一步的著力點是平臺，一個新的復(fù)雜技術(shù)體系的落地往往會是一個上面應(yīng)用、下面平臺的關(guān)系，也就是說往往需要先有一個可行的應(yīng)用場景，然后去打開切入點，等應(yīng)用場景不斷發(fā)展成熟之后，沉淀出一些平臺的產(chǎn)品來，其實我們的路線也正是這樣的。邊緣 CDN 作為一個比較好落地的應(yīng)用積累了我們對底層平臺的需求認(rèn)知，我們從場景中沉淀出通用能力下沉到底層平臺。回過頭來，我們以不斷完善的底層能力去提升上層應(yīng)用的表現(xiàn)，同時，我們組合底層積累的不同能力就可以去創(chuàng)新出新的應(yīng)用場景。

接下來，我們來看一下我們的邊緣計算平臺。這其實和云計算的 IaaS 層面非常相像。因為邊緣資源的特殊性，它也有一些自己的技術(shù)特點。

前面也提及過，平臺是一個聯(lián)通上下兩層的東西，這里面會有一個中間層。計算機科學(xué)中有一個很經(jīng)典的中間層定律，計算機科學(xué)領(lǐng)域的任何問題都可以通過增加一個間接的中間層來解決。我覺得這還有點不太完整，如果一層不夠，那就兩層。

接下來，我們在這個層里面到底做了什么事。其實剛才也提到，我們做 CDN 很重要的一個目標(biāo)是通過一些具體的應(yīng)用去了解底層的需求，去沉淀能力，其實可以看到我們在底層的邊緣計算平臺上去做這樣的一些事情，很多也是和剛才 CDN 做的事情比較類似，就是沉淀下來通用的一些需求。

第一點是異構(gòu)資源適配抽象，我們其實接入的資源非常多，操作系統(tǒng)就不用說了，包括 CPU 的架構(gòu)就有很多種比如 X86、ARM、MIPS、RISC-V 等各種設(shè)備。我們需要去把這些設(shè)備一個個接入進來，我們要能夠有一些在上面運行的像 Agent 這樣的程序，通常我們會開發(fā)相應(yīng)設(shè)備的固件，或者說我們對固件比較成熟的設(shè)備去開發(fā)一些插件來把它們接入到算力網(wǎng)絡(luò)中來，同時我們還需要去做一些虛擬化或者是容器化的事情，去抽象這些資源，使得應(yīng)用開發(fā)不要太痛苦。

第二點是邊緣自治。邊緣自治針對的是什么問題呢？邊緣的設(shè)備和中心中控的機群連接是不太穩(wěn)定的，所以我們邊緣需要做一些自治邏輯，好讓這些設(shè)備在和中心連接不上的情況下，不要輕舉妄動。

第三點是 SLA 分級保障。前面也提及過，我們的資源是多種多樣的，它們的能力以及它們的質(zhì)量穩(wěn)定性也是千差萬別的。我們?yōu)榱四軌蛉ズ喕覀儜?yīng)用上去做調(diào)度、去分配任務(wù)的邏輯，我們會把不同能力、不同質(zhì)量的資源去做分級的運營，同時我們也會有一些針對不同類型資源的激勵運營手段，去提升每一類資源內(nèi)的自身能力和質(zhì)量。

第四點是大規(guī)模異構(gòu)資源管理。這其實主要是針對節(jié)點數(shù)量，之前也提及過我們目前的節(jié)點是百萬級別的，這個管理起來也是頗具難度的。

第五點是調(diào)度裝箱。我們希望最大化利用我們的資源，這其實和各大云廠做的虛擬機的調(diào)度裝箱沒有本質(zhì)的區(qū)別，當(dāng)然它的場景會更加復(fù)雜一些，因為我們的節(jié)點是分開在邊緣里的。首先，它的能力差異就很大，調(diào)度面臨的情況就非常復(fù)雜，其次，你想要去做一些應(yīng)用遷移之類的事情，它也不像傳統(tǒng)云計算技術(shù)，在 IDC 里遷移是非常方便的，在邊緣就沒有那么方便，甚至兩個點中間可能間隔的是整個城域網(wǎng)或者是整個省網(wǎng)，這自然是需要去定制一些策略，做一些取舍。

第六點是安全，這也是一個非常大的挑戰(zhàn)。傳統(tǒng)云計算，在 IDC 里面能保證一個物理隔離，閑雜人等不能隨隨便便進入 IDC。在邊緣的話，這種保障就沒有那么強，物理接觸的可能性會非常高。所以，這塊我們也需要做更多的封裝需要更加全面的一些安全措施。

我們看完中間這一層，再來看底層的資源。這些年，我們在底層資源做了非常多的探索，底層資源也有了非常多演變。最開始，我們基于自研的硬件去構(gòu)建邊緣計算網(wǎng)絡(luò)。隨著平臺能力的不斷發(fā)展，我們不斷地把更多資源納入進來，包括之前提及的一些家庭端的其他設(shè)備以及一些在端和云中間這一側(cè)的企業(yè)機房設(shè)備等等。

經(jīng)過這些年的積累，我們已經(jīng)積累出了一個相對來說全覆蓋的邊緣計算網(wǎng)絡(luò)，無論它的節(jié)點位置，還是節(jié)點能力都是非常豐富的。

既然我們在中間層和底層資源做了很多工作，在上層我們是希望將來我們邊緣應(yīng)用開發(fā)能夠越來越方便。我們會向上發(fā)展去做 iPaaS 層的探索，把云原生帶到邊緣計算的場景里來。具體的話，是去做一些與行業(yè)標(biāo)準(zhǔn)接軌的邊緣服務(wù)治理，包括更好地容器化和編排，以及通過 Sidecar 等多種方式封裝跨云邊端通信能力。我們希望通過邊緣云原生能力去降低邊緣計算應(yīng)用的全生命周期成本。相關(guān)的系統(tǒng)已經(jīng)開始支撐自有業(yè)務(wù)。將來，如果成熟的話，我們也希望能夠?qū)⑺_放出來，希望在不久的將來，我們能夠在這方面給大家?guī)砀嗟姆窒怼?/p>

4、未來可期

基于我們對邊緣計算的探索和現(xiàn)在整個邊緣計算行業(yè)的發(fā)展，我們認(rèn)為接下來的這些場景可能會在短時間內(nèi)成為現(xiàn)實。

第一個場景是邊緣上的人工智能。邊緣 AI 也是現(xiàn)在邊緣落地很火的一個場景。前陣子，非常多的硬件廠商針對這樣的 AI 場景推出了很多邊緣計算盒子。從具體的場景來說，一個是邊緣推斷，比如我們可以將一些復(fù)雜的算法模型，比如之前提及的一些復(fù)雜的特效，如果我們可以在低延遲的邊緣上去運行這樣的一些特效，其實就能夠把這些體驗投射到終端上。

另一個是聯(lián)邦學(xué)習(xí)，我們通過在邊緣上去進行數(shù)據(jù)的處理，來去確保原始數(shù)據(jù)既不被中心收集，去保護用戶隱私，又能夠很好地去完成學(xué)習(xí)的過程。所有的像這樣的一些場景，它都能很好地運用邊緣計算的特點。這些場景落地所需要的工作如下：首先是解決服務(wù)治理的問題，我們怎么把這些應(yīng)用，把這些算法去部署到邊緣上，去管理它；其次是數(shù)據(jù)的傳輸，云邊端之間如何很好地去傳輸源數(shù)據(jù)和結(jié)果數(shù)據(jù)，特別是在一些實時場景中，傳輸技術(shù)要求還是非常高的；最后是需要有對應(yīng)的算力，而且算力的成本也是要比較合理。

第二個場景是視頻處理。這是離我們非常近的，整個行業(yè)里已經(jīng)有很多這樣的落地應(yīng)用了，比如云端轉(zhuǎn)碼、云端視頻剪輯和實時特效。云端視頻剪輯很火，各大視頻平臺都有云剪輯的工具。實時特效其實是視頻處理和 AI 交界的東西。這塊需要的能力也主要是邊端需要有相應(yīng)的算力，例如轉(zhuǎn)碼的算力、針對視頻運算需要的計算能力等。其次，也是傳輸，實時的超低延遲的視頻傳輸現(xiàn)在也是非?；鸬囊粋€賽道，RTC 技術(shù)發(fā)展的也非?？臁?/p>

第三個場景是實時演算，比如云渲染、現(xiàn)在大家都看到的云游戲和未來的元宇宙。元宇宙，我們可以把它理解成一個大號版的游戲。元宇宙里有更加復(fù)雜的場景、模型，甚至說需要大量的 AI 處理。這對運算顯然提出了更高的要求，同時，只要了解過 VR 的都知道，我們需要一個比較好的 VR 體驗效果，延遲需要降低到一定的水平。顯然，邊緣計算在這一塊是不可或缺的，所以行業(yè)也普遍認(rèn)為元宇宙將來的技術(shù)底座就是邊緣計算。我們和做邊緣 CDN 一樣，我們也會結(jié)合自身的優(yōu)勢去深耕這樣的場景，并且將這些能力進一步沉淀到底層平臺，去更好地服務(wù)我們整個行業(yè)。

最后，我們來總結(jié)一下。當(dāng)我們的泛在算力類似于水電是隨時可獲取的，那就沒有一個 T 的算力解決不了的問題，如果有，那就兩個 T。

我今天的分享就到這里，謝謝！