本文整理自美图资深SRE工程师李彬在【WOT2023·深圳站】大会上的主题分享，更多精彩内容及现场PPT，请关注51CTO技术栈公众号，发消息【WOT2023PPT深圳】即可直接领取。

嘉宾 | 李彬

编辑 | 如烟

出品 | 51CTO技术栈（微信号：blog51cto）

日前，在51CTO主办的WOT全球技术创新大会上，美图资深SRE工程师李彬带来了主题演讲《美图：AIGC运维之旅的探索和挑战》，详细介绍了美图如何在多云环境中实施标准化管理和流程，从而更加高效一致地管理多云环境；深入探讨了美图在大模型训练过程中遇到安全与合规问题后，如何通过实施有效策略，确保训练集群的安全稳固。

本文将摘选其中精彩内容，统一整理，希望为诸君带来启发。

一、美图的AIGC之旅

美图是一家以美为内核、以人工智能为驱动的科技公司，主要包括两部分业务：一是影像与设计产品，如美图秀秀、美颜相机、wink等；二是美业解决方案，包括美图宜肤、美图魔镜等。

2017年，美图曾因“手绘自拍”功能风靡欧美，还推出了全球首款智能绘画机器人Andy。2022年底，美图上线AI绘画服务，并迅速在网络走红，此时美图也开启了算力追寻之路。

2023年6月，美图一口气发布以美图视觉大模型为核心的七款产品，包括AI口播视频工具开拍、桌面端AI视频编辑工具WinkStudio、AI数字人生成工具DreamAvatar等。

在AI智能领域进行一番探索后，美图总结出了AIGC的业务特点：第一，传播速度很快，留给公司的反应时间很短；第二，数据增长迅猛，容易产生爆款，对资源的需求量很大、很急迫；第三，企业如果想要快速抢占市场获得竞争优势，就需要在资源交付方面投入更多。

二、多元算力的选择和应用

美图AIGC的算力组成主要以GPU为主，包括T4、V100、A10组成推理集群的基础，A800、A100、H100组成大模型训练集群的基础框架。AIGC业务最火爆的时候，美图的GPU资源非常紧缺，因此也选择了部分NPU作为GPU算力的补充。

有了算力之后，我们首先会做一个全面的基准测试，它能够加速我们对GPU资源差异性的认知，同时也提供了可靠的数据帮助算法研发团队在算力选择以及算法优化上找到方向。

美图在面对多元算力的选择时，遇到了很多挑战：第一，多元算力的管理和维护工作很复杂；第二，在资源调度及优化方面需要投入更多建设；第三是兼容性的问题，美图在适配华为云昇腾这种异构算力时，在平台和算法适配方面投入很大的人力成本；第四，供应链方面，GPU厂商提供的高性能算力有限，而且会分散在不同的区域，这样就需要在资源管理方面加大投入；第五，采用多云架构，需要在故障管理、灾备、稳定性运行、性能、成本权衡等方面重点发力。

三、多云资源交付

美图在多云资源交付方面也面临颇多挑战。

第一是资源方面的需求量巨大，包括计算、存储、网络等方面的资源；第二，随着项目运营、社区传播活动的推进，业务数据可能面临爆发式增长，这时就需要具备高效的弹性伸缩能力；第三，对于性能的要求非常高，包括基础资源GPU以及高性能存储、网络等；第四，交付周期紧张，需要在短时间内交付一套或者多套完整可用的生产服务。

面对这一系列挑战，美图内部制定了一个交付标准，其中包括厂商交付、内部交付和持续协作能力，确保交付流程的顺畅。

厂商交付方面，我们制定了一份名为AIGC项目GPU资源供应商必备资质的清单。清单内容包括我们在GPU资源、CPU资源、容器、周边、网络、存储等方面的需求。通过这份清单，可以和厂商同步我们期望的交付内容、交付时间以及责任人等具体事项。

内部交付方面，我们针对每个GPU厂商制定了一份排期清单，具体内容涉及工作细化及人员分工，环境准备、基础设施建设及资源验收，还包括业务部署、业务测试以及流量引入。

持续协作方面，我们和供应商定期举行会议，同步项目进度以及交付过程中遇到的问题，此外还会根据非预期性的事件调整相应计划。

AIGC时代，算力需求爆发式增长，紧张的GPU算力资源促进了多云环境的诞生，而多云架构又促使我们在资源交付及使用方面制定一套自己的标准。同时，业务为了快速抢占市场，同样也需要按照这套标准快速交付资源。

按照上述流程， 美图在当时AIGC算力GPU资源最紧张的环境下，用两天半的时间对接了三个云厂、十多个region、若干AZ，并向业务方交付了近万张GPU卡的资源，最终得到了多云算力。

四、多云管理和稳定性运营

拥有多云的算力后，美图是如何在多云管理和稳定性运营方面发力的呢？

第一，架构选型。我们充分利用了云原生，以K8S为底座来构建我们的多云生态。在资源规格及配比方面，我们会严格按照标准去执行。总而言之，我们对厂商的云原生成熟度要求是非常高的。

第二，多云纳管。美图内部研发了多云容器管理平台，实现对多云集群的统一纳管。我们的服务只要开启了多集群部署，就可以把它一键部署到当前的多云环境中。当然，也允许我们的服务进行多集群差异化的配置。

第三，基础设施完善。我们建立了统一的模型库，对元数据、模型存储、权限、入口、分发等进行统一。此外，我们还建立了统一的镜像分发平台，业务镜像在该平台上完成配置，这样就可以定时、增量地分发到不同云厂商的镜像仓库中。

第四，稳定性运营建设。我们在每个节假日会制定按需重保的工作列表，通过预操作确保节假日云的稳定性；我们还建立了SRE的稳定性运营平台，可以定期生成SRE稳定性运营周报、巡检报告等等，报告包含核心业务的监控、数据等。

在稳定性运营建设方面，我还想分享两点确保成本最优的策略：

第一是GPU资源运营。通过建立GPU大盘，从云厂商、区域、GPU卡类型、计费类型以及卡单价等多个维度给GPU资源确定优先级。我们会定期复盘，把一些业务从低优先级的区域动态地调度到高优先级区域，并且会定期清理一些未使用的资源、降低一些低利用率的资源规格，从而保证成本最优。

第二是业务运营。美图产品的大部分应用场景都是用户上传图片或视频后生成对应的效果。我们会结合这些功能单次生成的成本以及每日服务器的成本，最终确定每日的毛利，然后通过持续地关注ROI，保证业务稳定并且成本更优。

五、多云流量调度 & 弹性伸缩

了解美图在多云管理以及稳定性运营方面的挑战和应对策略后，接下来聊聊多云的流量智能调度以及弹性伸缩。

美图有两个非常典型的算法模型。第一个是同步算法：流量经过算法网关后，会被分发到不同的云中，在这个场景下，我们统一了算法网关并做了一些流量分发的动作；第二个是异步算法：流量经过算法网关后，会把它的任务写到消息队列中，在其他云的资源启动后，我们会读取消息队列中的任务，然后通过推理，把结果通过当地网关统一上传，这个场景的特点就是统一队列以及当地上传。

接下来结合两个真实的业务场景，分享一下美图在流量调度以及弹性伸缩方面遇到的痛点以及采取的解决方案。

痛点场景一：当产品过了火爆期后，如何合理地调度之前囤积的GPU卡呢？针对这个场景，我们首先要做到以下几点：一是尽量选择便宜且更合适的卡；二是减少不必要的网络开销，比如网络成本、存储成本等等；三是在保证业务稳定性的前提下做好成本优化工作。

对于这个痛点场景，我们采取的第一个最佳实践方案是针对同步算法做基于5XX的回源策略调度。

当一个用户流量经过网关后，它会按照优先级依次请求到包月集群、按需集群。当包月集群的资源负载非常高的时候，可能会出现一些5XX的状态码或者一些自定义的状态码。根据这些状态码，网关会把这个请求再次分发到按需集群，也是低优先级的集群。这个场景会造成用户等待时间增加，对业务是有损的。但这个场景可以大幅优化成本，所以我们征得业务方的同意后，针对不同的算法把它调度到类似的流量架构上。

第二个最佳实践方案是在异步算法方面做一些工作。我们做了多集群联动弹性伸缩，评估了每朵云的性价比。每朵云都有一个弹性伸缩的中控，比如某朵云想扩容，首先会上报中控，接着这个扩容动作会交给优先级最高的云，让它完成扩容。在缩容场景下也一样，让低优先级的云完成缩容的动作。这个架构画起来比较简单，但是实现过程非常复杂，因为需要考虑很多边界场景。

除了以上提到的两个最佳实践，我们内部还形成一个默认的调度准则，即基于服务亲和性的调度，主要体现在网络和存储方面。比如某服务依赖A云，我们就尽可能避免将这个服务调度到B云上，以此减少跨云网络传输成本。

痛点场景二：我们某个APP突然做了一个运营推广，但业务没有及时扩容，导致最终效果不佳。在这个场景下，我们总结出以下几个问题：一是服务弹性不够及时且速度较慢，主要体现在机器初始化流程非常长、镜像体积大、模型文件大以及服务冷启动非常久；二是常规的弹性伸缩策略无法满足当前AIGC的业务场景；三是我们也在思考这种运营推广类的需求应该如何定制策略，保证推广能够顺利进行。

针对痛点场景二我们采取以下解决方案：

1、提供多种弹性指标的选择。我们不仅提供基础指标，比如CPU、网络、内存，也提供业务QPS、队列MQ的长度指标。同时允许用户通过自定义的Prometheus指标来满足特殊的弹性场景。

2、在提升弹性速度方面，把容器的基础镜像放入虚机来降低pod的启动时间。

3、对虚机系统镜像做预热。当前的K8S集群可能会纳管多个可用区的节点，我们会把这个系统镜像在这些可用区提前预热，减少机器初始化时间。

4、我们会做一些亲和性的配置，比如我们的服务都会配置一个优先包月的策略，这个场景下一个包月机器有两个重要特点：一是包月机器没有购买初始化的流程，第二是包月机器在一些容器镜像上面会有一定的预热。

在冷启动和多模型方面，我们制定了运行时动态模型加载的方案。比如一个AIGC请求进入Server后，会携带不同AIGC的请求参数，算法处理服务在启动时会默认加载五个模型到内存中，然后它会根据请求参数的不同进行动态切换，把某一个模型切为我们的主模型进行推理。在这个场景下，有这样几个特点：

1、模型是天然预热的，而且能够实现动态切换。

2、我们会根据大盘中模型的使用频率，动态地将当前一些算法服务中的模型切为主模型进行推理。

3、针对小流量业务，采用小业务的混合部署来提升整体的利用率，比如将五个业务所依赖的模型都加载到一个pod里面，通过动态参数来切换处理能力。

4、 在应对运营推广带来突发流量的场景下，我们做了基于运营事件的弹性伸缩。美图内部也有一套统一推送平台，有运营推广的时候它会发送包含以下内容的信息：推广app、推广服务对象以及预估量。我们会根据这些信息预估针这个服务所需要扩容的数量，从而提前完成扩容动作，确保运营推广能够顺利进行。

六、大模型安全和成本建设

最后分享一下美图在大模型方面的安全和成本建设。

从SRE的角度看，我们在大模型方面遇到两个比较大的痛点。第一，安全方面，我们担心模型、用户数据、训练数据被泄露；第二，成本方面，大模型训练集群的成本非常昂贵，我们也始终致力于将算力榨干；此外大模型训练的上手成本非常高，所以我们也努力建设一部分应用工具来简化这个流程。

在安全方面，我们给出以下解决方案。

首先在隔离策略方面，我们完成了环境隔离，集群是按照大团队的维度授权的；在数据隔离层面，训练数据、模型和产物存储在不同的介质上来做区分；在网络隔离层面，我们直接掐掉集群的公网，一些依赖配置都是由平台提前配置好的；在权限层面，我们讲究所见即所得，细化到资源读写层面；在流程把控方面，比如基础权限下发、资源申请、资源删除都需要走OA审批。

其次在数据加密层面，我们做了镜像加密、模型加密，另外在运行时加密方面，我们也在努力寻找更合适的方案；我们还要求平台都增加必要的日志审计功能，所有资源开通、删除以及权限变更都要有记录；最后我们也会根据一些特定的场景增加一些必要的录屏功能。

接下来分享一下成本问题的解决方案：

1、监控告警、巡检建设：如果发现当前GPU空载率比较高，我们会判断是否出现训练任务中断等情况。

我们也会进行一些异常监控，比如GPU卡异常、掉卡监控以及一些常见的ECC错误监控；通过巡检报告，确保不遗漏集群任何时间点的运行状况；另外，除了资源层面，我们也做了涉及大模型训练资源所依赖的网络、存储等方面的告警，保证不丢失任何一个异常点。

2、在易用工具建设方面，我们内部开发了Piczoo平台，这个平台主要在算力资源管理、权限管理以及一些环境初始化做更多的建设和努力。

我们也二次开发了一个大模型任务提交工具，算法研发同学通过这个工具可以很轻松地把训练任务提交到大模型训练集群中，利用这个工具也可以快速查看任务状态以及任务运行日志等。

3、严格的项目流程控制。当前大模型训练资源非常紧缺，但是美图有很多项目都需要使用这样的资源，那么就会出现一些项目排队的情况。我们会通过一些严格的项目流程控制，来保证这些项目之间无缝地使用GPU资源，以此减少大模型集群的空跑期。

总之我们所做的所有降本增效的工作，都是为了让企业获得更大的竞争优势。