基于異構算力節點協同的高效視頻分發

鄂金龍 何 林

1 （中國人民大學信息學院 北京 100872）2 （清華大學軟件學院 北京 100084）3 （清華大學網絡科學與網絡空間研究院 北京 100084）4 （中關村實驗室 北京 100081）

（ejinlong@ruc.edu.cn）

隨著人工智能、云計算等技術的快速發展，工業互聯網、元宇宙等新模式不斷涌現，算力成為重要生產力并開始與網絡深入融合，“算力網絡（computing power network）”應運而生. 它通過將各種計算節點互聯統籌調度，提供算力分布在全部網絡節點的一體化信息基礎設施，能夠實現計算和網絡資源的優化和高效利用[1-2]. 近幾年，算力網絡相關技術的發展在全球被普遍關注. 例如，美國計劃建造各種算力設施構成的國家級計算生態系統[3]；歐盟提出大力發展云計算、構建安全高效可持續數字基礎設施的指南[4]；而我國為了推動“新基建”戰略實施，由四部委聯合發布文件啟動 “東數西算”和大數據樞紐節點建設工程[5]. 盡管當前國內外對于構建和運營國家級算力網絡的基礎設施剛起步，這些政策正在有效推進網絡運營商和云服務商探索算力網絡應用于各領域業務場景[6-9].

算力網絡主要適用于計算密集型業務，目前最常見的是大規模數據處理場景，例如超級計算、人工智能訓練、區塊鏈應用等. 而各種流行的智能應用（智能駕駛、智能制造）和泛視頻類業務（視頻直播、VR/AR、云游戲等）在高性能算力需求的基礎上，要求網絡提供實時性和可靠性保障. 在超高清視頻（4K/8K）直播時，連續數據流傳輸還會對網絡帶寬提出很高需求. 由于互聯網無法保證算力節點間傳輸時延和帶寬確定性，將算力網絡應用于這類對時間敏感的計算密集型業務存在巨大挑戰. 對此，當前國內三大網絡運營商和阿里巴巴集團控股有限公司、騰訊計算機系統有限公司等云服務商都在構建視頻業務專網，中國移動還進一步發布了算力網絡視頻應用白皮書[10]. 這些初步探索為基于算力網絡的視頻傳輸指出發展方向，然而并未對“如何有效協同服務商間異構算力節點進行高效視頻分發”這個關鍵問題進行充分研究和系統驗證.

在典型的視頻直播場景，視頻流從直播源上傳到一個攝取服務器（ingest server），再通過視頻應用商部署的內容分發網絡（content delivery network，CDN）傳輸到位于不同地理區域的服務器節點，方便終端用戶就近獲取視頻流以減少播放時延. 為了根據用戶網絡帶寬狀況適配性調整碼率，需要在傳輸過程中完成實時視頻轉碼（transcoding）. 當CDN 服務器節點普遍具有足夠算力時，原本由攝取服務器負責的轉碼工作可以卸載（offloading）到視頻分發階段. 由于不同云服務商提供的節點所在區域和性能變化趨勢有不小差異，利用多云節點協同處理視頻分發能夠有效增加區域覆蓋并提升服務可用性，有助于保證視頻直播的高實時性. 然而，各云服務節點的架構和性能配置有所不同，使得對應的算力也各不相同；同時節點間網絡鏈路狀況也經常變化不定，特別是不同云的異地節點間難以達成專網連通. 因此為了克服這些節點計算、網絡的異構性和動態性，始終選擇傳輸和轉碼綜合性能最優的一組節點以實現低時延、高帶寬的視頻分發具有很強的挑戰性.

針對上述需求和挑戰，本文設計一套基于異構算力節點協同的高效視頻分發方案：首先，為了合理規劃直播源到目標用戶的傳輸路徑并選擇處理視頻轉碼的節點，通過在線獲取分析各云服務節點的算力資源情況和節點間的鏈路狀態，并結合視頻流的實時傳輸流量變化，基于強化學習（reinforcement learning，RL）模型快速決策選取各視頻塊傳輸和轉碼節點集合. 相比于當前常用的由攝取服務器處理轉碼以及隨機或輪詢（round robin）選擇傳輸節點等方案，這樣可以盡可能使用性能最優的節點以最大化視頻分發效率. 在此基礎上，針對同時分發的不同視頻間對計算和網絡資源的競爭，通過采用優先級排隊并自適應調整資源的調度機制來降低突發流量峰值導致的節點資源容量不足的風險. 此外，對于云服務節點設計分層日志同步容錯機制，保證節點故障后快速恢復數據一致性. 這2 個機制能夠有效提升方案在實際環境中執行的彈性和可靠性.

為了驗證方案的實際效果，本文部署多個云服務商全球分布式的異構算力節點，基于它們構建的CDN 實現一個完整的視頻分發系統. 大量超高清視頻直播實驗表明，采用此方案的視頻分發性能相比常用的視頻分發方案有明顯改進（視頻傳輸碼率平均提升18.3%，視頻塊處理時延平均降低25.2%）. 該方案不僅滿足高實時性需求的視頻直播，也適用于視頻點播（video on demand，VoD）、泛視頻類應用（如VR/AR 和云游戲）等涉及視頻分發過程的場景.

本文的主要貢獻包括3 個方面：

1）通過全面測量和調研，發現各云服務節點間網絡鏈路狀態存在不穩定性，并且這些異構的節點在算力上有很大不同，它是基于算力網絡的視頻分發面臨的主要挑戰（見第2 節）；

2）設計基于異構算力節點協同的高效視頻分發方案，利用強化學習決策出性能最優的傳輸和轉碼節點來最大化分發效率，通過對不同視頻分發任務采用優先級排隊調度并自適應調整節點資源，在節點間進行分層日志，同步保證在實際環境執行的彈性和可靠性（見第3 節）；

3）基于多云服務分布式節點構建CDN，實現視頻分發系統.通過大量視頻直播實驗，驗證方案在平均傳輸時延、視頻直播碼率的傳輸性能明顯優于常用視頻分發方案（見第4 節）.

1 相關工作

針對本文的研究主題，本節對算力網絡和視頻應用這2 方面的研究進展簡要描述.

1.1 算力網絡研究

算力網絡從云網融合發展而來，更注重網絡控制對云邊端異構資源的管理和不同集群的協調，實現廣泛的算力資源動態調度. 在國家最新發展規劃[11]的引領下，目前業界正積極推進算力網絡的研究和發展，其中三大網絡運營商作為主力軍致力于相關產業布局和技術推廣. 中國聯通和中國移動分別發布《算力網絡白皮書》[6-7]，對算力網絡的概念、架構等方面進行討論，并提出發展愿景和演進策略. 中國電信確立了“云網一體”的戰略方向，希望整合云網資源構建新型信息基礎設施[8]. 國內外標準組織也在積極制定相關標準. 如國際電信聯盟電信標準分局在2021 年通過算力網絡框架與架構標準Y.2501[12].中國通信標準化協會批準于同年設立工作組討論算力網絡技術及其應用，編制了系列行業標準，包括算力路由、算網編排等多個方面[13].

算力網絡的技術方案從網絡架構角度可以分為集中式架構和分布式架構. 其中集中式架構方案分離控制平面與數據平面，在控制平面進行全局統一算網編排調度[6-7]. 而分布式架構方案通過相鄰路由節點間交互同步算網狀態信息，采用網絡層協議擴展方式實現路由節點決策計算任務控制轉發[14]. 目前學術界正在圍繞算力網絡前沿技術開展研究. 如確定性算力網絡[2]利用確定性網絡技術實現計算任務的實時傳輸和計算. NSACS-PS[15]借鑒命名數據網絡的命名機制，實現算力服務的接入控制優化. 新型可擴展互聯網[16]支持網內泛在計算與內容就近響應，可以實現算網資源的融合利用.

1.2 視頻應用研究

盡管算力網絡當前被業界廣泛關注，但目前相關視頻應用的研究剛剛起步. 中國移動在算力網絡通用架構的基礎上針對泛視頻業務設計了一種算力網絡視頻應用架構[10]. 中興通訊也推出面向全場景視頻應用的視頻算力網絡架構和解決方案[17]. 此外，當前業界普遍在構建視頻專網，旨在為算力網絡視頻應用提供基礎設施，如中國電信的天翼視聯網、中國移動的公共服務視頻網以及騰訊會議、Zoom 等實時互動視頻服務的網絡支持.

除此之外，近年來學術界有很多視頻應用研究工作. 其中最熱門的研究集中在視頻適配碼率傳輸的優化. Pensieve[18]、NAS[19]等工作采用機器學習技術根據網絡鏈路帶寬情況決策傳輸使用的碼率，然而這些研究主要應用于從服務器端下載整個視頻的視頻點播服務. Salsify[20]、LiveNAS[21]等工作提出針對視頻直播場景的傳輸碼率優化策略，但它們都未對直播過程中視頻分發階段給出優化方案. VDN[22]提出一種集中式控制算法來優化CDN 用于直播視頻的分發性能. MP-DASH[23]和XLINK[24]分別基于多路徑TCP 和多路徑QUIC 技術增加視頻傳輸到目標用戶的路徑數目進而改善用戶體驗質量，不過這些研究難以滿足超高清視頻直播的實時編碼和傳輸需求.此外，Jigsaw[25]和Rubiks[26]都設計了分層編碼方式分別降低4K 和360°視頻的傳輸流量，但它們并未考慮編碼和傳輸開銷. 與上述研究工作不同，本文面向超高清視頻直播場景，集成不同云服務的節點構成算力網絡用于視頻分發，基于強化學習、優先級調度、日志同步等技術協同異構算力節點進行高效傳輸和轉碼，有效提升現有視頻分發方法的性能.

2 視頻分發中的算力網絡應用

本節探索將算力網絡引入視頻直播的視頻分發過程，調研和測量可用作算力節點的主流云服務節點在計算和網絡上的性能情況.

2.1 視頻分發的節點部署

圖1 描述了一個典型視頻直播場景的端到端工作流程，它主要包括視頻攝取和視頻分發2 個部分.其中視頻攝取是指從直播源（手機、電腦、網絡攝像頭等）將當前正在錄制的視頻流實時上傳到攝取服務器的過程. 這里直播源和攝取服務器間一般采用專用的流傳輸協議，如實時流傳輸協議（real time streaming protocol，RTSP）或 實時消息傳輸協議（real time messaging protocol，RTMP）等. 在目前流行的網絡架構中，攝取服務器通常需要部署在具有充足計算資源的云服務節點上，負責將直播源上傳的原始視頻流按2～10 s 的塊轉碼成多種分辨率等級（如最常用的包括720p、1080p、4K 等），以便后續根據觀看直播的用戶側網絡狀況適配性調整播放碼率，例如采用基于HTTP 的動態自適應流傳輸（dynamic adaptive streaming over HTTP，DASH）技術[27]. 在接下來的視頻分發過程中，攝取服務器將轉碼后不同分辨率的視頻塊都通過CDN 推送到服務用戶的各分布式節點，用戶按就近原則從訪問時延最小的服務節點獲取視頻流，以盡量減少播放時延.

Fig.1 End-to-end workflow for a typical live video streaming scenario圖1 典型視頻直播場景的端到端工作流程

設想如果CDN 服務器節點都具有足夠的計算資源，那么視頻轉碼將不再局限于在特定的攝取服務器上完成，而是可以在視頻分發的過程中卸載到相對閑置的服務節點；與此同時，攝取服務器不再有特殊的高資源配置要求，可以利用靠近直播源的云服務節點完成視頻攝取，也為進一步降低整體傳輸時延提供機會. 為了實現這種設想，可以將算力網絡用于視頻分發過程，即部署一批具有一定計算能力的算力節點用作圖1 中CDN 服務器節點. 對于視頻服務商，按需租用云服務商的計算虛擬機實例相比購買物理服務器分布式部署有更高性價比.

事實上，國內主流云服務商（如阿里云、騰訊云和華為云）都提供不同大洲多個地理區域的計算節點實例（instance），特別有助于國內視頻服務商支持全球直播. 表1 給出了3 種主流云服務商在國內外不同區域提供計算節點的情況. 從表1 中可以看出，各云服務商計算節點位置分布呈國內密集、國外稀疏，且主要大城市（上海、新加坡）重合、某些大區域（非洲、南美洲）缺失的態勢. 考慮到單個云的計算節點區域（特別是國外）有限，顯然將不同云的節點集成使用可以有效增加覆蓋密度，進而降低訪問時延并提升服務可用性（例如集成上述3 個云的節點以避免缺失大區域內鄰近服務）.

然而，一個重要問題是如何整合這些不同云節點的算力，協同用于視頻分發服務. 表2 給出了上述3 種云服務商計算節點的幾種入門級CPU、內存及GPU配置（對于普通計算型選擇相同的CPU 4 核內存8GB配置，對于GPU 計算型選擇各自的最低配置），可看出比較明顯的CPU 主頻、GPU 型號和單位價格差異.值得注意的是，對于一個云服務而言并不是所有區域都有其全部節點配置類型可選. 事實上，各云服務不僅資源配置多樣，在系統架構上也有很大不同，因此這些計算節點對應的算力也會各不相同. 此外，盡管一些云服務商內部設計了不同區域節點間的專網連通機制，如騰訊云聯網（cloud connect network，CCN），然而這些云內專網的實際效果，以及更難以確定的不同云的節點間網絡狀況都有待進一步測試.

Table 1 Region Distribution of Computing Nodes Worldwide Provided by Three Mainstream Cloud Service Providers表1 3 種主流云服務商在全球提供的算力節點的區域分布

Table 2 Some Typical Resource Configurations of Three Mainstream Cloud Service Providers表2 3 種主流云服務商的幾種典型資源配置

2.2 云服務節點性能測量

為了檢驗云服務計算節點實例的實際網絡性能，這里選取國內最流行的2 種云服務：阿里云和騰訊云，它們各在全球5 個不同區域部署配置近似的節點實例（表2 中“阿里ecs.c6.xlarge”和“騰訊c6.large8”），對于節點的出入帶寬都不設額外限制（最高可達各云服務提供的最大帶寬）. 對于部署的各節點，采用Internet 包探索工具（packet Internet groper，PING）在一周內不同時段測量兩兩之間往返時延（round-trip time，RTT）100 次. 圖2 展示了具有代表性的8 組節點間平均、最大、最小RTT 的對比情況（按平均值由小到大排序，各節點標識中“A”和“T”前綴分別代表阿里云和騰訊云，后面的位置簡稱“SV”“SH”“NJ”“GZ”“HK”“VA”“BM”“FR”“SP”，分別表示硅谷、上海、南京、廣州、香港、弗吉尼亞、孟買、法蘭克福、圣保羅）.需要說明的是，由于任意兩個節點之間雙向PING 測量出的RTT基本一致，因此作為一個度量統計.

Fig.2 RTTs of representative cloud services’ computing nodes圖2 代表性云服務的算力節點間往返時延

從圖2 中可以觀測到，部署在不同大區域的節點間時延很大且表現出高度不穩定性，如阿里云廣州節點與騰訊云弗吉尼亞節點間（圖2 中“AGZ-TVA”）平均RTT超過300 ms 且波動接近25 ms，與此前對AWS、Azure 等國外云服務的測量結論[28-29]一致. 除此之外，不同云在同一地理位置部署的節點間時延非常短，如阿里云和騰訊云硅谷節點間（圖2 中 “ASV-TSV”）RTT僅為3 ms；而各云內部臨近區域部署的節點間時延也比較短，如騰訊云上海和南京節點間（圖2 中“TSH-TNJ”）RTT為10 ms. 對于某些節點間RTT 較大的情況可以通過第三方節點中轉數據有效降低時延，如通過騰訊云硅谷節點中轉可以降低阿里云廣州節點和騰訊云弗吉尼亞節點間RTT約26.2%. 考慮到這些測量中節點間都是通過公網連接，進一步將騰訊云節點通過內網IP 配置云聯網（僅支持國內節點連接）測試專網連通效果，最終發現，盡管搭建云聯網的節點間的路由不同于此前公網連接路由，但所有這些節點間的RTT都并沒有明顯變化. 由于到云服務內部專網支持的節點有限且實際效果不理想，因此后面僅考慮節點間通過公網傳輸.

考慮到云服務節點需要在視頻直播中用于轉碼，接下來考察不同配置節點處理視頻的性能. 具體地，參考表2 列出的節點資源配置，采用阿里云普通計算型和GPU 計算型2 種配置. 這里從Xiph 視頻庫[30]獲取2 個不同信息豐富度（information richness）的30幀4K 視頻（根據Jigsaw[25]的判斷方法區分為高豐富度和低豐富度），采用當前最常用的H.264 編碼技術[31]進行視頻編解碼（轉碼實際是解碼再編碼的過程）.為了減小誤差，2 種配置節點在不同時間對2 個視頻各進行20 次編解碼. 圖3 給出了這4 個測試用例的平均單幀編碼和解碼用時，其中“普通”和“GPU”分別代表2 種配置類型.

Fig.3 Per-frame encoding and decoding time for four pairs of configuration and information richness圖3 4 種配置和信息豐富度組合下單幀編解碼用時

從圖3 中可以看出，視頻編解碼用時受其信息豐富度影響而不固定（豐富度越高用時越長），而使用GPU 處理可以明顯減少編解碼用時. 然而GPU 配置顯著增加了節點成本，例如阿里云近似常規資源配置（CPU 核數和主頻完全相同，內存容量相差1 倍）情況下，添加GPU 與否的每小時租用價格相差超過12 倍. 因此在選取節點時應該綜合考慮其性價比（后面將定義“單位價格處理速率”用于區域節點確定）.不同類型云服務節點難以估計對比的算力與前述的節點間變化不定的網絡狀況使得將這些節點構建成算力網絡用于視頻分發過程存在很大挑戰，亟需克服不同節點在計算和網絡上的異構性和動態性來設計視頻分發方案.

3 高效視頻分發方案設計

在觀測結論的指導下，本節設計一套基于異構算力節點協同的高效視頻分發方案. 首先基于強化學習模型決策用于各視頻塊的最優傳輸和轉碼節點，以最大化分發效率；在此基礎上對不同視頻塊通過優先級排隊調度提升節點彈性，并設計分層日志同步容錯機制保證節點故障后快速恢復.

3.1 視頻分發節點決策模型

用于視頻分發的云服務節點需要持續響應海量直播視頻處理和傳輸請求，此外，為了降低運營成本需要合理利用各節點資源，因此保證視頻傳輸實時性并提升節點資源利用率是選取分發（傳輸和轉碼）節點的主要考慮因素.

首先確定用于視頻分發的算力網絡節點集合.如2.1 節所述，協同多云節點能夠提升服務可用性，因此可以在所有合作云服務商全部可用地理位置（如表1 所示）部署節點實例. 考慮到國內云服務商普遍在國內提供較為密集的候選節點位置，可以去除包含候選節點位置較多的一些區域（如華北、華東等）的部分節點位置. 具體來說，先測量所有候選節點位置兩兩之間的RTT，設n個候選節點位置間的測量集合為取各節點位置到其它節點位置中最小的RTT值在各區域內根據該值進行排序并去除其中1/3 值較大的節點位置. 這樣減少部署性能較差的冗余節點，既可以降低視頻分發過程中的故障風險又能節約資源成本. 接下來對選定的節點位置各部署一個節點實例. 對于云服務商在各節點位置提供的不同類型的實例配置，這里選取其中單位價格處理速率最高的配置. 具體來說，使用所有m個類型配置的實例分別對同一代表性視頻進行編解碼，記錄其各自總用時{tk}(k=1,2,…,m)，并查詢各種配置的價格{ck}，通過1/（tkck）計算單位價格處理速率對所有實例配置排序，最終按結果值最高的配置進行實例部署.

為了有效調度所有部署的節點，還需要從這些節點中選舉出1 個節點作為控制器，以便統一編排所有節點的資源，響應視頻直播應用請求向各節點分配視頻傳輸和轉碼任務，并實時維護各節點的數據處理狀態. 為了減少控制器與其它節點頻繁交互消息的時延，需要最小化其到其它節點的最大時延.因此同上操作，測量所有部署節點兩兩之間的往返時延與前面不同的是這里取各節點到其它節點的最大RTT進行排序，取該值最小的節點作為控制器.考慮到各節點間網絡狀況不穩定，同時全局控制節點負載過大易出現單點故障，因此將采取根據節點間最新RTT 周期性按上述方式重新選舉（周期一般可設置為1 h）.

控制器需要持續獲取各節點當前的資源使用情況，以便將視頻傳輸和轉碼任務在線分配到合適的節點執行（每次執行任務后獲取節點資源使用情況）.對于計算和存儲資源，可以直接調用節點設備自帶的監控工具獲取CPU 和內存利用率. 而對于網絡帶寬資源，可以基于“網絡狀況通常在短時間尺度上保持穩定”這一科學發現[32]，根據最近數據傳輸平均速率的調和平均數（harmonic mean）估算所有節點間以及節點與鄰近的直播源或用戶間的鏈路帶寬. 具體來說，某鏈路x最近一小段時間（如1 min）內有l次數據傳輸，各次數據大小和傳輸用時分別為{sxi}和{txi}(i=1,2,…,l)，即對應的傳輸平均速率為rxi=sxi/txi，則根據調和平均數計算公式，該鏈路估算帶寬為

通過計算所有鏈路帶寬之和與節點額定帶寬的比值可以近似獲得節點帶寬利用率.

考慮到強化學習能夠根據狀態反饋實時更新決策，非常適合在線追蹤異構節點的計算和網絡資源變化，相比于當前由攝取服務器處理轉碼、隨機或輪詢選擇傳輸節點的方案能夠更合理地選擇最大化視頻分發效率的傳輸和轉碼節點，因此控制器維護一個RL 智能體，利用從各節點收集的計算、存儲和網絡帶寬資源使用情況，為每個劃分好的視頻塊決策傳輸和轉碼的最優節點（視頻流的分塊和調度過程見3.2 節）. 具體來說，RL 智能體以收集的節點資源使用情況為狀態（state）Si進行學習，確定傳輸和轉碼節點集合向量為需要決策的動作（action）ai. 這里的狀態Si包括5 個元素，分別為當前分發的視頻塊大小、直播源和目標用戶所在區域組合、各節點CPU 利用率集合、內存利用率集合和鏈路帶寬利用率集合. 注意當需要服務不同區域多個目標用戶時，則對不同目標分別做傳輸和轉碼決策. 決策動作向量ai應該包括分發源鄰近節點（即用作攝取服務器的節點）、目標鄰近節點（用戶鄰近的節點）、中轉節點以及轉碼節點這4 個編號元素，這里允許在分發過程中進行一跳中轉（前面測量表明中轉有機會降低時延），如無需中轉則設置為0. 轉碼節點是從源鄰近、目標鄰近和中轉節點中選取的用于轉碼的合適節點.

每次執行動作ai后會產生新狀態Si+1，從而啟動新一輪的學習和決策.Si→ai映 射由模型的控制策略Π(Si,ai)決定，在狀態觀察和動作執行的迭代過程中更新. 為了讓RL 智能體從過去的經驗中學習，每個動作都與一個獎勵（reward）函數相關聯，該函數主要考慮視頻直播的實時性，以最小化正在分發的所有視頻流{vx}在傳視頻塊的最大傳輸完成時間（即尾時延）為目標. 這里視頻塊傳輸總用時tOT包含各段節點間傳輸用時以及轉碼計算用時，即

其中s為視頻塊大小，BWop、BWpe、BWeq、BWqd分別依次為直播源o、源鄰近節點p、中轉節點e、目標鄰近節點q、目標用戶d之間的鏈路帶寬（當沒有中轉節點時s/BWpe+s/BWeq用s/BWpq替代），tC為確定的轉碼節點的計算用時. 因此獎勵函數設置為當前狀態相比上一個狀態在所有在傳視頻塊傳輸尾時延上的降低情況，即

在此基礎上，RL 智能體利用神經網絡（neural network，NN）來表示其控制策略Πξ(Si,ai)（ ξ為一組參數）. 如圖4 所示，狀態Si的各元素分別輸入2 個相似的多層神經網絡，其中一個稱為Actor，它基于提取的特征輸出動作ai，另一個稱為Critic，它用于判斷動作價值（NN 具體層數和每層單元數根據實際情況調整）. 每個神經網絡的輸入層都采用一維卷積神經網絡（1-dimensional convolution neural network，1D-CNN）來提取集合序列的特征，而圖4 描繪的全連接（FC）層都采用tanh 激活函數來增強學習能力，Actor 網絡的輸出層以softmax 作為激活函數，生成選擇每個動作的概率分布（提供概率最大的動作）；而Critic 網絡的輸出層是一個線性神經元，它估計從當前狀態開始的預期總獎勵. Actor 網絡根據Critic 網絡計算出的最優價值VΠ(Si)迭代更新策略函數，最終決策出視頻傳輸和轉碼的最優節點.

Fig.4 A reinforcement learning model for deciding transmission and transcoding nodes圖4 用于決策傳輸和轉碼節點的強化學習模型

為了保證視頻傳輸的實時性，RL 模型需要適應在線決策，盡快收斂（即穩定地生成合理的決策），訓練目標是最大化模型獲得的總累積獎勵. 策略梯度（policy gradient）[33]是實現這一目標的有效方法，但它可能會遇到由于大量策略變化導致的收斂困難問題.鑒于此，我們使用鄰近策略優化（proximal policy optimization，PPO）[34]這種快速收斂算法來訓練模型，以避免在每一步中過多地更改策略的參數更新. 具體來說，用優勢函數（advantage function）Aξ(Si,ai)制定累積折扣獎勵的梯度，其表示狀態Si中特定動作ai的預期獎勵與從策略 Πξ中提取動作的平均預期獎勵的差異. 在實踐中，Actor 網絡參數 ξ的每次更新都遵循策略梯度

其中 α是學習率. 對于給定的四元組(Si,ai,r,Si+1)，通過獎勵函數和價值估算Aξ(Si,ai)（后面簡寫為Aξ）

其中比率rξ被函數c(·)限制在區間[1?ε,1+ε]，模型將平滑更新策略參數避免決策跳躍.

使用快速收斂的訓練算法，RL 智能體在最初仍然需要經過一段時間學習才能做出合理決策. 此時可以采用輪詢的方式選取傳輸中轉節點和轉碼節點，但無法保證視頻分發和節點資源利用效率. 為了避免冷啟動，可以讓RL 智能體利用歷史節點選取的學習經驗. 已有工作表明，在多個NN 模型中對相同神經元的參數進行平均可以實現聚合這些模型的經驗[35]. 因此，這里通過融合先前對象模型的NN 參數來進行多模型聚合. 具體來說，假設總共有nm個決策模型，每個模型包含nc個單元（所有模型的NN 結構都相同）. 所有的NN 參數可以用一個矩陣 Ξi j表示，其中每個元素 ξij表示第i(i=1,2,…,nm)個模型中第j(j=1,2,…,nc)個單元的參數. 接下來按照聯邦學習的原理進行加權平均運算來計算聚合模型中的每個元素

其中 ρi代表模型i的經驗權重. 通常對同一直播源歷史傳輸視頻塊進行的決策有更多可供借鑒的經驗，因此為相應模型設置優先權重.

3.2 多任務調度與可靠通信機制

由于算力網絡節點需要面向多直播源提供視頻分發服務，當不同視頻流同時發起分發任務處理請求時，需要設計合理的調度機制以緩解它們對計算和網絡資源的競爭. 首先確定每次請求處理任務的劃分. 為了使各任務視頻塊可以單獨在不同節點進行轉碼，在劃分時視頻塊間不能有編解碼依賴. 考慮到視頻編碼過程同時涉及幀內編碼（intra-frame coding）和幀間編碼（inter-frame coding），顯然不能以視頻幀為分塊單位. 事實上，主流視頻編碼技術（如H.26x、VPx）的編碼序列中都包含一系列幀間編碼單元，稱為圖片組（group of pictures，GOP），不同的GOP之間不存在任何幀編碼依賴，適合作為劃分任務的視頻塊.

如圖5 所示，直播源通過消息隊列遙測傳輸（message queuing telemetry transport，MQTT）協議向控制器發送視頻分發請求，并按GOP 劃分視頻塊. 對于每個視頻塊，在實際執行任務前可以保守估算分發和編碼完成用時，定義虛擬完成時間tVT，

Fig.5 The input-queued scheduling process for distribution requests of multiple video streams圖5 多視頻流分發請求排隊調度過程

其中s為視頻塊大小，BWop、BWpq、BWqd分別為對源、目標以及之間鏈路此前測量的帶寬，為在源鄰近節點（攝入服務器）處轉碼的計算用時，易知tVT為執行該任務的最大用時（中轉或更換轉碼節點若降低該用時則在實際中采用）. 此外，直播中各視頻塊都有一個需要播放期限Td，設當前時間為Tc，據此計算各視頻塊的允許等待時間tW為

為了使視頻流暢播放，這里采用優先級排隊調度機制，即在一個優先隊列中根據允許等待時間tW對請求視頻塊進行排序（注意每次有請求到達時需更新隊列中視頻塊的Tc為當前時間再進行計算比較），tW小的視頻塊將插隊優先處理，以盡量保證臨近期限的視頻塊能按時播放.

在此基礎上，為了降低突發流量峰值導致資源容量不足的風險，進一步設計節點資源配置自適應策略，對視頻分發請求“削峰填谷”提升節點的彈性.這里以各節點實例部署時確定的初始資源配置（包括表2 描述的CPU 和內存配置，加上設定的網絡鏈路最大帶寬）為1 個資源單元，作為它們此后增減資源的最小單位（注意不同節點的資源單元對應的具體資源配置可以不同）. 對于使用中的任意節點實例z，定義主控資源利用率為計算、存儲和網絡帶寬資源利用率中的最大值，即

每次處理請求在給定區域選取用于傳輸或轉碼的節點實例時，都選擇其中主控資源利用率UDz的最小的節點，以此始終保持均衡利用不同節點的資源，使它們能應對各種程度的流量峰值壓力. 當同一區域內所有節點實例的主控資源利用率都大于一個特定的擁塞閾值 θc（即）時，需要為其中最大的節點實例增加一個資源單元；而當同一區域內各節點實例主控資源利用率都小于一個特定的空閑閾值時，則回收所有節點實例的額外資源單元（注意 θc和 θl取值需要根據實際節點實例資源配置和處理數據大小分布確定）.

考慮到節點間網絡狀況不穩定，還需要設計良好的容錯機制以減少節點斷連故障恢復時間. 首先，為了預防控制器發生故障，可以按照3.1 節所述控制器選舉方法從剩余部署節點中選出1 個節點作為備用控制器. 一旦當前控制器發生故障宕機，將備用節點作為新的控制器，用于與各節點繼續交互分配處理任務. 當前分發視頻塊的各源鄰近節點在收到控制器更換的廣播后將備用控制器信息附帶在向對應直播源發送的完成分發響應里，此后直播源仍通過MQTT 協議發送視頻分發請求到備用控制器. 此后周期性重新選舉的控制器通知備用控制器，備用控制器同樣將消息附帶在對請求的響應中傳遞給直播源.備用節點處理完當前收到請求后，停止作為控制器，而直播源此后將請求發給新選舉的控制器處理. 而對于其它節點發生故障，可以從控制器復制日志來恢復數據一致性. 這里基于Raft 共識協議[36]的日志同步機制，當有新的數據處理請求到達時，在日志中追加條目，并通知其它節點在日志中復制該條目后更新狀態機. 采用這種機制可以保證在少于半數節點宕機時節點網絡仍可以正常處理數據.

當前采用日志同步的主流的分布式存儲框架（如OpenStack Swift）一般直接在節點間同步整個日志，然而這樣會消耗很大帶寬資源，影響數據處理任務的傳輸時延. 為了解決這一問題，本文設計一種分層日志同步機制，利用Merkle 樹[37]來組織相關日志條目和目錄的散列值. 具體來說，如圖6 所示，根據日志條目內容和完整路徑為每個日志條目生成一個MD5 散列值. 在此基礎上，一個目錄的散列值可以通過連接其下一層所有日志條目和子目錄（非級聯的方式）散列值計算得出. 例如，目錄d中有n個日志條目和m個子目錄散列值分別為H(fi)和則可以遞歸計算目錄d的散列值為

其中“ +”表示字符串連接操作，而H′(d)表示目錄d完整路徑的MD5 值（如果d為空目錄，則H(d)=H′(d)）.通過這種方式，所有日志條目和目錄的散列值可以按照目錄樹（directory tree）結構被記錄在一個特殊的文件中. 注意每次更新一個日志條目時，其在目錄樹中所有祖先節點的散列值都將隨之變化，因此它們需要被重新計算.

4 系統驗證分析

本節根據第3 節設計的高效視頻分發方案實現面向視頻直播場景的系統，通過在真實環境下部署算力網絡進行測量及利用仿真實驗對其性能進行評估.

Fig.6 Data consistency recovery based on layered log synchronization圖6 基于分層日志同步的數據一致性恢復

4.1 系統實現與實驗設置

視頻分發原型系統包括視頻源和用戶客戶端、一組云服務節點構建的算力網絡，以及選舉出的控制器節點，所有平臺均采用Python 實現. 控制器通過心跳報文與各節點保持長連接，收集節點資源使用情況并發送視頻分發節點決策結果，其實現基于遠程過程調用框架gRPC. 對于維護節點間日志同步的Raft 共識協議，系統引入一個開源程序[38]實現. 視頻轉碼過程采用主流的視頻編碼技術H.264 及音頻編碼技術AAC，這里基于FFmpeg 工具實現. 系統中的RL 智能體使用TensorFlow 構建神經網絡模型. 具體來說，基于網格搜索（grid search）[39]設置FC 層的層數為2，每層單元數為32，學習率 α和折扣因子 γ分別為0.1 和0.95；使用Adam 優化器[40]來更新梯度下降.

為了對這些實現的系統進行性能評估，接下來在3 種不同云服務（阿里云、騰訊云和華為云）提供計算虛擬機實例的全球各區域按3.1 節的規則選取節點位置，并部署單位價格處理速率最高的節點實例. 其中3 種云服務使用節點最多的實例配置分別為阿里云ecs.c6.xlarge（CPU 4 核2.5 GHz，內存8 GB）、騰訊云gn7.large20（CPU 4 核2.5 GHz，內存20 GB，GPU 1/4*NVIDIA T4）和華為云s6.xlarge.2（CPU 4 核2.6 GHz，內存8 GB）. 面向視頻直播這一應用場景，系統主要關注視頻傳輸碼率這個指標. 接下來將采用現有視頻分發的基本方法和一種直觀改進方法作為比較基線，前者是在確定的攝入服務器進行視頻轉碼，此后直接傳輸視頻塊到用戶鄰近的CDN 服務器節點；后者與本文方案類似，采用分布式算力網絡并根據RTT選取離直播源和目標用戶附近節點作為源鄰近節點和目標鄰近節點；而中轉節點以及轉碼節點都采用輪詢選取方式（其中中轉節點可以輪空不選而在源和目標間直接傳輸）.

與2.2 節測量類似，這里從Xiph 視頻庫[30]獲取的10 個不同信息豐富度的30 幀4K 視頻（高豐富度和低豐富度各5 個，都經過H.264 編碼）用作實驗測試視頻源. 不同于實際運行時由直播源實時錄制每次隨機生成的視頻流，本實驗采用記錄重放（trace replay）并通過視頻拼接方式使所有測試視頻都播放相同時間（10 min），以此保證不同測量環境的一致性和確定性. 此外，為了評估在線調度算法的可擴展性，收集1 個云服務處理請求的大規模數據集，選取其中1 個處理請求的突發期共2003 個數據的請求時間. 從Xiph 視頻庫下載視頻并按3.2 節方法劃分出足夠數量的視頻塊（大小在10～100 MB），用以搭配上述突發期請求時間，模擬多視頻分發請求競爭環境.

4.2 性能評估實驗

首先測量系統的端到端性能，以視頻傳輸碼率作為評估指標. 這里將本系統方案（“模型決策節點”）和4.1 節描述的2 種比較基線（“默認視頻分發”和“輪詢選取節點”）分別用于分發上面提到的高低信息豐富度各5 個視頻. 為了測試性能穩定，在一天的不同時間分別運行每個測試用例10 次. 圖7 描述了3 種方案的平均、最大、最小視頻傳輸碼率在2 種信息豐富度下的比較情況. 由圖7 可見，由于涉及更多視頻轉碼用時，高豐富度視頻在各種方案下傳輸碼率均小于低豐富度視頻. 不過相對2 種比較基線，模型決策節點能夠有效選取適合轉碼和傳輸的節點，在視頻傳輸碼率上有明顯提升（相比基線中性能較好的“輪詢選取節點”方法，在低、高豐富度情況下可以分別增加20.9%和15.6%）.

Fig.7 Comparisons of video transmission bitrates achieved by the model-deciding-node approach and two baselines with different information richness圖7 模型決策節點方案和兩種比較基線在不同信息豐富度情況下視頻傳輸碼率對比

進一步以視頻塊處理時延（即將視頻塊從直播源同步到目標用戶的端到端時延）作為評估指標. 這里選取實驗中傳輸碼率最低的高信息豐富度視頻（按3.2 節描述方法劃分為124 個視頻塊），測量 “模型決策節點”和2 種比較基線（“默認視頻分發”和“輪詢選取節點”）用于該視頻分發過程中各視頻塊處理時延變化情況，實驗結果如圖8 所示. 從圖8 中可以看到，由于視頻碼率在分發中不斷變化，同時不同視頻塊的大小具有差異（10～20 MB），幾種方案產生的時延都有較劇烈的變化. 不過模型決策節點時延相比其他2 種比較基線明顯更低（平均分別減少21.2%和29.3%），且在視頻分發過程中沒有出現卡頓或丟包（視頻塊處理時延過大或為零）等情況，因此可以有效滿足高實時性需求的超高清視頻直播場景.

Fig.8 Comparisons of video chunks’ processing latency variations achieved by the model-deciding-node approach and two baselines圖8 模型決策節點方案和兩種比較基線用于典型視頻分發過程中視頻塊處理時延變化情況

事實上，模型決策節點方案對于涉及視頻分發過程的視頻點播和泛視頻類業務同樣適用. 這些場景下視頻提前從直播源上傳到某個云服務節點，模型決策節點方案和比較基線在響應用戶獲取請求的視頻分發過程中無需考慮直播源與源鄰近節點間的傳輸（相當于式（2）中第一項=0）. 顯然此時包括視頻傳輸碼率和視頻塊處理時延在內的端到端性能對比情況都與上述實驗結果近似，這里不再贅述.

接下來具體評估方案中4 個重要機制. 對于RL模型決策機制，主要關注其收斂速度以及訓練算法和模型聚合機制對其的影響. 這里采用策略梯度算法進行訓練和采用PPO 算法進行無模型聚合的訓練作為比較方法，將連續10 個決策中本方案性能都優于比較基準作為模型收斂的信號. 基于這個設定，圖9繪制了在分發上述視頻過程中，本系統的RL 模型和2 種對比方法的收斂時間（產生第1 個決策的時間）的累積分布函數（cumulative distribution function，CDF）.顯然，圖9 中對比情況驗證了本系統模型在實際環境中的快速收斂性.

Fig.9 Effect of model training algorithm and model aggregation mechanism on the convergence time圖9 模型訓練算法和模型聚合機制對收斂時間的影響

對于多任務優先級排隊調度機制，以“平均數據傳輸用時”指標評估其在處理突發請求時的時效性.這里將其與2 種常用的調度算法“先入先出算法”和“分組公平共享”用4.1 節描述的數據集進行對比，其中“分組公平共享”是指同時調度一組（最多10 個）任務來共享鏈路帶寬資源. 注意本系統計算虛擬完成時間采用各鏈路實際帶寬（一般為100～200 Mbps）.圖10 描述了多任務優先級排隊調度機制與其他2 種對比算法的傳輸用時比率隨著處理視頻請求數量增加的變化趨勢. 從圖10 中觀察到，2 個比率都會很快收斂到0.5 左右，并在之后保持穩定. 這個提升效果表明本系統的調度機制能保證大量同時到達的視頻處理請求的及時性.

Fig.10 Performance comparison between the multi-task scheduling mechanism and two common scheduling algorithms圖10 多任務調度機制和兩種常用調度算法的性能對比

對于節點資源配置自適應機制，采用同樣的數據集進行仿真來評估其有效性. 這里統一設定節點資源單元（見3.2 節定義）的配置為最多節點實例的初始資源配置（CPU 4 核2.5 GHz，內存8 GB，網絡鏈路最大帶寬100 Mbps）. 根據對資源變化情況和視頻的數據分析，擁塞閾值 θc和空閑閾值 θl可以分別設置為60%和20%. 圖11 描述了資源使用波動最大節點的資源單元數量在執行視頻處理任務過程中的變化情況. 從圖11 中可以看出，在整個過程節點使用的資源單元數量都相當少（平均少于2 個，短時間內最多需要3 個），同時數量變化總體呈現穩定趨勢. 與每個節點僅使用單一資源單元相比，節點資源配置自適應機制可以使視頻數據的整體處理用時減少35.9%.

Fig.11 Adaptive change of resource unit number and the corresponding reduction of video processing time圖11 資源單元數量自適應變化和視頻處理降低用時

對于分層日志同步機制，通過測量日志同步時延來評估其是否具有給故障節點帶來快速恢復數據一致性的能力. 主要將其與主流框架OpenStack Swift的方案（即“日志整體同步”）在故障節點數nf=1,2,3時的同步性能進行對比. 圖12 描述了2 種同步機制的時延隨著日志條目數量呈數量級增加（103～107）的變化趨勢. 從圖12 中觀察到，分層日志同步機制的日志同步時延隨著日志條目數量增加而趨近平緩，同時隨著故障節點數量增加，相比于對比方案的時延降低幅度明顯增大. 當有3 個節點發生故障時，采用本系統機制同步107條日志僅需10 min 左右，與對比方案相比能夠降低68.5%的同步時延. 該實驗結果表明分層日志同步機制能夠滿足故障節點快速恢復數據一致性的需求.

Fig.12 Reduction of delay brought by the layered-logsynchronization mechanism with different fault node numbers nf圖12 不同故障節點數 nf時分層日志同步機制降低時延

最后監測作為系統核心的控制器在一段時間內各種資源使用率的變化情況. 如3.1 節所述，在運行過程中控制器周期性選舉產生，大多數時間的資源配置為最多節點實例采用的CPU 4 核2.5 GHz，內存8 GB，網絡鏈路最大帶寬100 Mbps. 將4.1 節描述的各種視頻隨機拼接成一個60 min 視頻，其中劃分的各視頻塊的分發請求由控制器決策處理. 圖13 描述了控制器在處理視頻塊過程中CPU、內存和網絡帶寬（包括出入流）使用率的變化. 從圖13 中可以觀測到，在面對密集的處理任務時，控制器各種資源使用率仍平穩地維持在很低程度（6%以下）. 單一控制器即可滿足大規模的視頻分發應用. 配置相近的備用控制器的資源使用率情況基本一致，也能夠穩定處理相當規模的視頻分發請求，這里不再贅述.

Fig.13 Variations of the controller’s resource utilization rate during processing video distribution圖13 控制器在處理視頻分發過程中資源使用率變化

5 結 論

本文提出了一種基于異構算力節點協同的高效視頻分發方案，通過設計強化學習模型規劃視頻傳輸路徑并合理選取處理轉碼節點；采用優先級排隊對不同視頻任務進行調度并自適應調整節點資源以降低對計算和網絡資源的突發競爭；設計分層日志同步容錯機制在節點故障后快速恢復數據一致性，在多云服務分布式節點實現高效視頻分發. 大量超高清視頻直播實驗證明，與現有視頻分發方法相比，本方案性能有明顯改進. 未來的工作一方面是結合云原生技術來提升多資源編排彈性，另一方面是構建算力網絡內生的可信安全機制.

作者貢獻聲明：鄂金龍設計方案、完成實驗并撰寫論文；何林提出意見并修改論文.