電子發燒友網報道（文/周凱揚）在大型數據中心里，視頻處理或許是當下占比最高的關鍵工作負載，疫情期間，人們在視頻細分的產品上所花時間越來越多。對于云服務廠商來說，視頻市場帶來的紅利仍然在持續，但對于視頻網站和視頻app等產品來說，他們面臨的服務器成本壓力也在與日俱增。
比如隨著流量激增，Teams、Zoom和騰訊會議等服務都出現了崩潰的事故，有的視頻網站面臨巨額的服務器費用和下跌的營收，也開始采取壓縮畫質等策略。盡管服務器端的摩爾定律依然在延續，但面對視頻處理的計算需求，已經開始有些力不從心了，哪怕在專業處理圖形的GPU加持下也是如此。如果不采用特定領域的ASIC硬件加速器，成本壓力將會繼續堆積。

全球最大視頻網站的策略

作為全球最大視頻網站Youtube的所有者，照理說谷歌面臨的壓力是最大的，但Youtube從疫情至今，卻基本維持著穩定的狀態，而且視頻質量也是同行中最高的那一檔。能維持住這樣服務器壓力，靠的并不是傳統的CPU+GPU商用服務器組合，而是谷歌自研的視頻處理芯片VCU。

谷歌預見了真正大規模視頻處理和其他消費級服務器用例的根本差異，尤其是在數據多樣性、質量要求、吞吐量和成本上。所以谷歌打算從計算資源最昂貴的一塊，也就是視頻處理這塊著手，設計自己的VCU處理單元，解決從視頻共享、照片與視頻云存儲、直播到云游戲等一眾業務上的視頻處理難題。

VCU的設計思路

谷歌的VCU全名為視頻編碼單元，單個芯片集成了10個編碼核心、3個解碼核心。從谷歌VCU芯片的布圖規劃也可以看出，大部分區域都分配給了編碼器核心，其次是四通道的LPDDR4內存，不僅提供邊帶錯誤糾正，也提供芯片所需的帶寬。

每個VCU服務器系統由10塊板卡組成，每塊板卡上配有2個VCU芯片。谷歌將一切非轉碼的處理工作丟給非VCU服務器，而VCU服務器則盡可能靠近視頻上傳的位置，降低延遲從而降低轉碼所需時間。

但我們要知道一點，視頻處理專用的服務器成本之所以如此之高，并不是只有GPU價格高、性能要求高等原因，還有就是低利用率的問題。并非所有的轉碼工作都能用滿芯片的硬件資源，所以谷歌采用了固件管理的隊列來啟用并發轉碼。
比如某個操作是“將這一幀的畫面編碼為VP9位流，”那么應用程序負責將指令寫入隊列中，固件則只負責隊列調度和編解碼器核心的激活。如此一來編程只發生在應用層面，避免了ASIC這類硬件先天缺乏FPGA那樣靈活的可編程性，也符合數據中心快節奏的軟件迭代速度，同時又確保了沒有一個編碼核心能閑下來。

谷歌也給出了VCU與主流方案的差距，比如與純英特爾SkylakeCPU轉碼或4個英偉達T4 GPU轉碼的對比，8個VCU的配置在進行H.264或VP9轉碼時，性價比最高可達前兩種方案的20倍以上。

專用視頻處理硬件的未來

對于流量快速增長，負載持續增加的大規模數據中心和云服務來說，谷歌這種方案無疑是最省成本的。阿里巴巴、亞馬遜等云服務廠商紛紛開始了自研服務器芯片計劃，這點人盡皆知，但從設計上就可以看出，這些芯片還是面向在通用服務器或AI服務器的，與視頻沾邊的應用也大部分是AI視頻識別類的。

而目前最讓視頻產品頭疼的轉碼這塊，卻少有ASIC產品的出現，不少加速卡做成了PCIe的尺寸規格，但其實仍是基于CPU，尤其是編解碼性能稍強的英特爾CPU。反倒是Xilinx的AlveoU200/250 FPGA加速卡在性能上更有優勢，但考慮到這些加速卡高昂的價格，目前云服務平臺還沒有普及開來，甚至還在用老版的UltraScaleFPGA。

與此同時，AV1這類壓縮率更高編碼的編碼標準提出了更高的硬件要求，谷歌的VCU雖然性價比極高，也沒有支持AV1這一標準，或許我們會在下一代VCU上看到。