英特尔软硬一体的云架构优化

2022-07-20 06:19:04 来源：

（原标题：英特尔软硬一体的视频云架构优化）

　　来源：info 作者：王一鹏

　　如果说，在以音视频为载体传输信息、进行交互的技术领域，始终飘着一朵“乌云”，那么这朵“乌云”的名字，很可能既不是低延时，也不是高可靠，而是不断变化的应用场景。

　　从Web 2。0到移动端基础设施全面建成，我们完成了文字信息的全面数字化；而从2016 “直播元年”至今，图像、语音信息的全面数字化则仍在推进中。最简单的例证是，对于早期的流媒体直播而言，1080P 是完全可接受的高清直播；但对于今天的流媒体而言，在冬奥会这样的直播场景下，8k 可能是个刚性需求，相比于1080P，像素数量增长16倍。

　　而且，今天的流媒体业务，对视频流的要求不仅停留在分辨率上，也表现在帧率上。以阿里文娱2019年底推出的“帧享”解决方案为例，它将画面帧率推至120 FPS，同时对动态渲染的要求也很高。过往人们总说，帧率超过24 FPS，人眼就无法识别，因此高帧率没有实际意义。但高帧率是否能提升观看效果，与每帧信息量密切相关，近几年游戏开发技术的进步，以及以李安为代表的一众电影导演，已经彻底打破这一误解。

　　对于 RTC 来说，问题情境和对应的软件架构又截然不同。早期大家看赛事直播，20s 的延迟完全可以接受。但在 RTC 场景下，人与人的即时互动让使用者对延迟的忍耐度急剧降低，从 WebRTC 方案到自研传输协议，相关尝试从未停止。

　　当我们以为，所谓的场景问题，终于可以被抽象为有限的几个技术问题，并将延迟压入100ms 以内，可靠性提升至99。99%，新的场景又出现了。全景直播、VR 全球直播，云游戏……其中又以云游戏最为典型——云游戏简直是过去那些音视频场景性能要求的集大成者：有的游戏要求延时低至50ms 以内；有的要求 FPS 60以上；分辨率不消说，肯定是越高越好。同时云游戏场景夹杂着大量的动态渲染任务，无一不在消耗着服务器资源，增大着全链路的传输延时。

　　那么，如果从云游戏场景的性能要求出发，进而扩展至整个超视频时代的架构体系，该以怎样的思路来进行架构设计呢？只关注软件，可能不太行的通；硬件成为必须纳入考虑的一环。

　　以软件为中心并非最佳选择

　　要解释这个问题，必须重新回顾下常规的云游戏技术架构。下图主要参考自英特尔音视频白皮书、华为云游戏白皮书，并做了相应调整，基本与当前环境下，大部分云游戏架构的设计相符。

　　在这一架构内，至云游戏终端前，所有服务都在云端、公共网络上完成，保证用户无需下载游戏或是为了玩游戏购置高性能终端。游戏玩家的终端，主要负责对网络包进行处理、对渲染后的游戏画面进行解码、显示，并相应地输入指令，回传给服务器。

　　而在服务器端，链路相对复杂。云游戏管理平台是服务的起点，上下两条链路，都是云游戏的周边技术服务，与业务场景强相关，包括云游戏的直播录制、游戏日志 / 记录存储等。前者对时延忍耐度较高，可以走正常的流媒体服务体系，使用 CDN 分发音视频内容；后者属于正常的游戏服务器设计范畴，正常提供服务即可。

　　关键在于中间一层，也就是云游戏容器集群。这一部分要实现的设计基础目标是保障1s 至少完成24张游戏画面(24帧)的计算、动态渲染和编码传输，部分高要求场景需要帧率达到60 FPS，同时保证时延尽可能得低。

　　这部分的技术挑战非常大，以至于若仅以软件为中心思考，很难做出真正突破。从相关指标的演进历史来看，仅仅在4年前，移动端游戏本地渲染的基础目标还是30 FPS，如今虽然能实现60 FPS 甚至更高，但讨论的场景也从本地渲染切换成了云端渲染。在软件上，除非出现学术层面的突破，否则很难保证性能始终保持这样跨度的飞跃。

　　此外，渲染本来就是严重倚仗硬件的工作，渲染速度和质量的提升，主要依赖于GPU 工艺、性能以及配套软件的提升。

3D游戏渲染画面

　　而更为复杂的游戏性能以及整体时延的控制，则对整个处理、传输链路提出了要求。仅以时延为例，它要求在编码、计算、渲染、传输等任何一个环节的处理时间都控制在较低范围内。同样是在3 - 4年前，有业界专家分享，他们对 RPG 类云游戏的传输时延容忍度是1000 ms，但事实证明，玩家并不能忍受长达1s 的输入延迟。反观今日，无论是通过公有云 + GA 方案，还是通过自建实时传输网络方案，即便是传输普通音视频流的 RTC 服务也只能保证延时100ms 以内，而云游戏的计算量和带宽需求数倍于普通音视频服务。

　　以上仅仅是冰山一角。对于架构设计而言，除了高性能、高可用、可扩展性三类设计目标外，成本也是必须要考虑的平衡点——需要1000台服务器的架构，和需要100台服务器的架构，压根不是一个概念。2010年前后，云游戏基本不存在 C 端商业化可能，虽然整体时延和性能指标可以满足当时的要求，但代价是一台服务器只能服务一个玩家，单个玩家服务成本上万。云游戏“元老” Onlive 公司的失败，在当时非常能说明问题。

　　而到了2020年，行业硬件的整体性能提升后，一台服务器可支持20 - 50路并发，性能提升了几十倍。

　　那么，如果我们将硬件变成架构设计的核心考虑要素，会是什么样的呢？大致如下图所示(为了不让图示过于复杂，我们只保留了云游戏核心服务链路，以作代表)。

　　可以看到，仅在云服务器部分，就有大量的硬件和配套软件需要参与进来，要关注的性能点也相对复杂。而这仅仅是云游戏一个应用场景下的音视频架构，当我们将场景抽象并扩展，最终覆盖到整个超视频时代的时候，以下这张来自英特尔技术团队的架构图，可能更加符合实际。英特尔将音视频体系架构在软件和硬件层面分别进行了展示：一部分叫做 Infrastructure(基础设施层)，如图一所示；另一部分则称其为 Infrastructure Readiness (基础设施就绪)，指的是基础设施就绪后，建立在其上的工作负载，如图二所示。两张图的首尾有一定重合，表示其头尾相接。

图一：基础设施层

图二：基础设施就绪后的工作负载

　　可以看到，基础设施层主要包括硬件、配套云服务、云原生中间件以及各类开源基础软件。而在工作负载层面，是大量的软件工作，包括核心的框架、SDK 以及开源软件贡献(UpStream)。这也是为什么英特尔以硬件闻名，却维持着超过一万人的软件研发团队。

　　拆解软硬一体的音视频架构方案

　　基础设施层

　　在基础设施层，我们的首要关注对象就是硬件，尤其是对于音视频服务来说，硬件提升对业务带来的增益相当直接。

　　但相比于十年前，当前的硬件产品家族的复杂度和丰富度都直线上升，其核心原因无外乎多变的场景带来了新的计算需求，靠CPU 吃遍天下的日子已经一去不复返了。以前面展示的英特尔硬件矩阵为例，在音视频场景下，我们主要关注 CPU、GPU、IPU，受限于文章篇幅，网卡一类的其他硬件不在重点讨论范围内。

　　在 CPU 方面，英特尔已更新至强® 第三代可扩展处理器，相比第二代内存带宽提升1。60倍，内存容量提升2。66倍，采用 PCIe Gen 4，PCI Express 通道数量至多增加1。33倍。其中，英特尔® 至强® Platinum 8380处理器可以达到8通道、 40个内核，主频2。30 GHz，英特尔支持冬奥会转播8k 转播时，CPU 侧的主要方案即是 Platinum 8380。

　　英特尔 CPU 另外一个值得关注的特点，在于其配套软件层面，主要是 AVX-512指令集。AVX-512指令集发布于2013年，属于扩展指令集。老的指令集只支持一条指令操作一个数据，但随着场景需求的变化，单指令多数据操作成为必选项，AVX 系列逐渐成为主流。目前，AVX-512指令集的主要使用意义在于使程序可同时执行32次双精度、64次单精度浮点运算，或操作八个64位和十六个32位整数。理论上可以使浮点性能翻倍，整数计算性能增加约33%，且目前只在 Skylake、 Ice Lake 等三代 CPU 上提供支持，因此也较为独特。

　　在视频编解码、转码等流程中，因为应用程序需要执行大规模的整型和浮点计算，所以对 AVX-512指令集的使用也相当关键。

　　而 GPU 方案在云游戏场景中，通常更加引人瞩目，英特尔® 服务器 GPU 是基于英特尔 Xe 架构的数据中心的第一款独立显卡处理单元。英特尔® 服务器 GPU 基于23W 独立片上系统(SoC)设计，有96个独立执行单元、128位宽流水线、8G 低功耗内存。

　　所谓片上系统 SoC，英文全称是 System on Chip，也就是系统级芯片，SoC 包括但不仅限于 CPU、GPU。就在今年，前 Mac 系统架构团队负责人、苹果 M1芯片的“功臣” Jeff Wilcox 宣布离开苹果，担任英特尔院士(Intel Fellow)、设计工程事业群(Design Engineering Group)CTO，并负责客户端 SoC 架构设计，也在行业内引起了众多关注。

　　当然，只有 GPU 硬件本身是不够的，英特尔® Media SDK 几乎是搭配 GPU 的必选项。英特尔® Media SDK 提供的是高性能软件开发工具、库和基础设施，以便基于英特尔® 架构的硬件基础设施上创建、开发、调试、测试和部署企业级媒体解决方案。

　　其构成可参考下图：

　　 IPU 是为了分担 CPU 工作负载而诞生的专用芯片，2021年6月，英特尔数据平台事业部首席技术官 Guido Appenzeller 表示：“IPU 是一种全新的技术类别，是英特尔云战略的重要支柱之一。它扩展了我们的智能网卡功能，旨在应对当下复杂的数据中心，并提升效率。”

　　具体落地在音视频场景里，IPU 要负责处理编码后的音视频流的传输，从而解放 CPU 去更多关注业务逻辑。所以，CPU + GPU + IPU 的组合，不仅是在关注不同场景下的需求满足问题，实际上也在关注架构成本问题。

　　工作负载层

　　从基础设施过渡到工作负载，实际上有一张架构图，更详细的展示了相关技术栈的构成：

　　在这张架构图中，横向是从源码流输入到分发的整个流程，期间包含了编码、分析等处理动作；而纵向则展示了要服务于这条音视频处理流程，需要搭配的硬件和软件体系。

　　 OneAPI 作为异构算力编程模型，是桥接基础设施和上层负载的关键一层，这不必多言。而到了负载层，软件则分成了蓝色和紫色两个色块。蓝色代表直接开源软件，紫色则代表经过英特尔深度优化，再回馈(Upstream)给开源社区的开源软件。

　　在蓝色部分，OpenVino 是个很有意思的工具套件，它围绕深度学习推理做了大量的性能优化，并且可以兼容 TensorFlow、Caffe、MXNet 和 Kaldi 等深度学习模型训练框架。当音视频体系需要加入 AI 技术栈以服务超分辨率等关键需求时，OpenVino 会起到关键作用。

　　紫色部分的 x。264/x。265是一个典型。作为音视频行业最主流的编码标准，英特尔使其开源的主要贡献者，而且 AVX-512指令集也专门围绕 x。264/x。265做了优化和性能测试。

　　另一个值得关注的核心是编码器，它横跨了蓝色区域和紫色区域，既有行业通用的 ffmpeg，也有英特尔自研的 SVT，二者同样引人关注。

　　关于编解码器的选型思考

　　在流媒体时代，著名开源多媒体框架 ffmpeg 是业界在做编解码处理时，绝对的参考对象。说白了，很多编解码器就是 ffmpeg 的深度定制版本。到了 RTC 时代，出于更加严苛的及时交互需求，自研编解码器尽管难度颇高，但也在研发能力过硬的企业中形成了不小的趋势。

　　可归根结底，在推进以上工作时，软件始终是思考的出发点，从业者们多少有些忽略对硬件的适配。

　　 SVT 的全称是 Scalable Video Technology ，是开源项目 Open Visual Cloud 的重要组成部分，针对英特尔多个 CPU 进行了高度优化，因此在英特尔硬件体系上，性能表现非常突出。SVT 设计最朴素的初衷，是针对现代 CPU 的多个核进行利用率方面的提升，比如依仗硬件上的多核设计并行对多个帧同时处理，或对一张图像分块进而并行处理，大大加快处理速度，避免多核 CPU 空转。