Rokid 通过引入阿里云函数计算和弹性容器实例 ECI，进行了一系列的云架构改造，实现了成本和性能上的平衡，还有效提升了整个系统的可拓展性。
Rokid 创立于 2014 年，是一家专注于人机交互技术的产品平台公司。Rokid 通过语音识别、自然语言处理、计算机视觉、光学显示、芯片平台、硬件设计等多领域研究，将前沿的 Al 和 AR 技术与行业应用相结合，为不同领域的客户提供全栈式解决方案，有效提升用户体验、助力企业增效、赋能公共安全，其 Al、AR 产品已在全球八十余个国家和地区投入使用。
Rokid 在数字文化领域，围绕展陈导览解决方案，主要形成了三维建图、场景创作、场景体验三个业务模块，每个模块都有不同的平台支撑。
-
三维建图：制作展陈导览的第一步是取景，通过设备获取场地的真实布景，然后通过算法处理，进行三维建模，之后可以经过创作器进行下一步的内容创作。
-
场景创作：在三维建模生成的视频流上创作，通过 Web3D 渲染引擎，将创作内容与场景紧密结合，结合硬件设备，在 AR 设备使用时，形成一体化的体验效果。
-
场景体验：AR 设备在使用时，根据定位服务，锚定在场景中的位置，根据位置的不同会显示不同的空间内容，达到扩展现实场景的效果。
整体的产品架构图如下：
三维建图、场景创作、场景体验三个场景都涉及到了的图像处理，需要大量的 GPU 资源，其中场景体验在设备运行时提供实时服务，主要功能是定位服务，对服务的实时性要求很高。
为了支撑 GPU 算力的需求，Rokid 在开发的初期就决定使用云资源承载。最初是购买了 ECS 的 GPU 机型，用于业务的开发和测试。但该场景下存在很大的问题：在三维建图时，一般都会一次性采集展陈环境的所有场景资料，视频量巨大，通过 ECS 串行处理耗时非常久，通常一个 1 小时的视频资料，通过一台 ECS GPU 机器处理需要耗费约 3 小时。
为了解决该问题，Rokid 做的第一步是并行化，通过拆分 CPU 和 GPU 处理逻辑和优化任务编排方式，尽可能地让可以并发处理的部分拉起更多的资源，加大并发量。通过这一系列的优化，视频的处理时间得到了明显提升。
在并发资源方面，Rokid 选择的 GPU 计算资源是 ECI。相对于 ECS，ECI 可选的资源粒度更加多样，特别是在小规格的选择上，对于切分的小块视频，通过并发的使用小规格 ECI 实例并行处理，大大缩短了整体视频的处理时长。为此，Rokid 内部平台还开发了一套针对阿里云 ECI 资源的调度模块，方便内部快速地申请和释放 ECI 资源。通过对 ECI 资源的灵活使用，在保证高峰期任务处理并发度的同时，也保证了算力成本的可控，使用流程上得到了初步的优化。但是通过一段时间的使用，发现还是有很多的不足之处，主要问题有以下几点：
-
ECI 资源的申请和释放都依靠使用人员主动操作，有时在使用完毕后会忘记及时释放资源，导致资源闲置浪费。此外，开发和维护 ECI 的调度程序也产生了一些额外的运维工作。
-
三维建模的任务经过拆分后，分成了好几个步骤，每个步骤的任务都需要异步执行，需要一个系统维持任务的调用关系，在上一个步骤完成后，拉起下一个步骤的任务继续运行。这种处理方式会耗费额外的资源。
-
在运行过程中，会存在异常情况。例如：有时是因为申请的计算资源规格过小导致计算负载较高，有时是存储异常或存储空间写满，还有些情况是程序本身存在性能瓶颈。由于程序的整体状态缺乏监控机制，使得出现异常情况时不能第一时间发现，且排查过程不够直观，需要通过多种工具才能获取运行指标分析数据。
-
GPU 算力在云上规模有限，在高峰期会存在 ECI 资源弹不出的情况，影响开发效率。
为了解决上面问题，Rokid 尝试了一些优化：针对上述第 2 点，Rokid 维护了一个总的调度系统，进行任务编排；针对第 3 点，通过引入阿里云 ARMS Tracing、Promethues、Grafana 等组件，结合 ECI 硬件指标，统一收集到日志服务 SLS，形成统一的监控报表，再配以监控指标的告警，初步地满足了 Rokid 的使用需求。但对于第 1 点和第 4 点，很难通过增加云产品或者内部应用程序来解决。
为此 Rokid 开始寻找云上新的产品，以求根本解决业务痛点问题。经过调研发现，Serverless 架构的函数计算各项能力都能很好地满足 Rokid 的使用场景。
函数计算是事件驱动的全托管计算服务。使用函数计算，无需采购与管理服务器等基础设施，只需编写并上传代码或镜像。函数计算会准备好计算资源，保证弹性、可靠地运行任务，并提供日志查询、性能监控和报警等功能。函数计算提供 CPU、GPU 的算力，秒级计费，用户只需要为实际资源使用付费。资源自动根据设定的时间、请求量等指标自动弹性伸缩，无需维护调度、负载均衡、重试机制、异步回调等组件，提供了开箱即用、用完即走、按量付费的极致 Serverless 能力。
函数计算 GPU 架构如下：
函数计算底层依托阿里云的公有云计算资源集群，可提供非常充足的计算资源。
-
Serverless GPU 虚拟化技术（上图左半部分）：通过阿里云的 cGPU 技术，可将单卡 GPU 资源切分成多种更小粒度的资源规格，实现了算力强隔离、显存强隔离、故障强隔离。
-
Serverless GPU 两级资源池（上图右半部分）：实现了热资源池。用户在函数计算选择 GPU 规格创建函数后，在有请求时，函数计算会实时从预热资源池获取资源，配合对应的镜像程序快速启动函数。启动完毕后即可对外提供服务。同时函数计算 GPU 资源池为平台所有，用户只需为自己使用的资源付费。
函数计算在第一次运行实例时会涉及到资源的拉起，弹性交付时间在 1 秒（热启动）～20 秒（冷启动）。Rokid 的三维建图场景是离线任务，单个视频的处理时间是在分钟级，对于秒级别的启动时延完全可以接受。
通过接入函数计算，就解决了 Rokid 平台的大部分问题：
-
Rokid 不再需要手动申请 ECI 资源，使用结束之后也无需手动释放。函数计算会根据请求流量，动态的拉起与请求量匹配的后端 GPU 算力资源，在请求处理结束后（一段时间没有新请求的情况下）自动释放资源。
-
整个三维建模在拆分后涉及好几个步骤，每个步骤都是异步执行。通过函数计算的异步系统，在一个步骤的任务完成后，可以自动触发下一个任务。
-
函数计算控制台内置了指标监控、异常告警、链路追踪、调用日志、异步配置的功能，可以满足 Rokid 从开发、运行监控到运维全函数生命周期的功能需求。函数计算底层依托阿里云大计算池，加上预热和资源评估的后端算法，可以最大程度地保证资源供给。
接入函数计算后，Rokid 的云产品技术架构如下：
函数计算资源利用率监控图如下，从监控图可以看出，在有任务进入时，GPU 计算利用率可以达到 60% 甚至接近 100%。
Serverless 理念的函数计算确实给 Rokid 带来了很多的便利，在高峰期资源的扩展性和成本节约方面都做到了当前云产品的极致。但对于 Rokid 的场景体验功能，也就是需要实时提供定位服务的模块，函数计算还无法完全满足需求。
函数计算在第一次拉起实例资源时，会存在 1 秒（热启动）～20 秒（冷启动）的启动时间，这个时间对于实时定位服务模块是不可接受的。实时定位是在使用者身处展陈场地时，AR 设备通过实时定位，获取空间位置的 AR 拓展信息，接口响应的时间对客户的体验非常重要，定位请求需要在 1 秒以内返回。
为解决这个问题，Rokid 场景体验模块采用 ECI 部署，通过每天的定时任务，在高峰期提前弹出更多的 ECI 实例，在低峰期仅保留少量的 ECI 实例，以此达到服务体验和成本的平衡。
场景体验采用 ECI 后，Rokid 的业务架构图如下：
通过一系列的云架构改造，Rokid 三维建图模块如今已成功运行在函数计算的 GPU 资源上，场景体验模块部署在 ECI 资源环境中，在成本和性能上实现了平衡，还有效提升了整个系统的可拓展性，达到了系统初始设计时设定的目标。该改造自 2023 年 2 月上线以来，已取得了显著的效果。其中三维建图模块降本明显，相比最初的 ECS 架构，算力成本降低了 40%。更为重要的是，依托函数计算的实时并发处理能力，显著缩短了子任务的排队时间，进而加速了任务整体的完成周期，极大提升了系统效率和用户体验。
尽管现有的函数计算方案在处理实时场景时面临挑战，但仍有应对策略。目前 GPU 支持的模型一般都很大，镜像都在 G 级别。因此，第一次资源拉起无法立即达到 CPU 资源 100 ms 级别的启动速度。为解决这一问题，Rokid 在函数计算中引入了预留实例，该功能允许计算资源在闲置时被释放，同时可保留内存中已运行的程序镜像。这样，当有新的请求时，系统仅需提供计算资源即可快速响应，省去了硬件资源初始化和函数镜像拉取与启动的时间，确保服务的及时响应能力。
Rokid 在 3D 模型处理、音视频后期处理方面也正在尝试大规模使用函数计算。经过展陈展览项目的实践，Rokid 相信以函数计算为代表的 Serverless 一定是云计算的未来，通过 Serverless，云计算的使用者不再需要关注底层的 Iaas 层运维和调度，在保证成本最优的情况下能够得到最大限度的拓展能力，且在整个服务的生命周期内，都能使用云产品提供的原生能力，简单、快速地定位和解决问题。