随着Stable Diffusion等AI生图方案逐步普及，越来越多的场景被开发和落地。其中面向游戏C端玩家的AI生图营销活动场景正在被逐步验证：在某个游戏社区中，玩家一键从手机上传一张照片，AI会将自动识别该照片中的元素并替换成游戏中相应的角色或物品，替换后的照片可以进一步被玩家传播，进而扩大活动影响力。这样的活动已经被应用于游戏新版本发布、展会等场景，能有效提升玩家与游戏之间的粘性，让玩家成为游戏的推广大使，为游戏拉新。

本文将探讨如何高效地搭建方案架构——游戏AI生图活动，以下为要点：

包含了游戏风格与素材的AI模型，并调试出相应的推理算法。

有效触达游戏玩家的客户端，可以是游戏客户端本身，也可以是社交媒体，比如常见的游戏玩家聚集地，海外有Discord，国内有Fanbook、微信等。

一套能快速伸缩承载高并发出图请求的后端架构：本方案选用EKS，搭载了EFS、Bottlerocket、GPU时间分片虚拟化和Karpenter等组件作为演示的后端架构。

方案架构

方案上大致可以划分两大部份：

客户端和请求接入层：

首先我们选择Discord作为我们的客户端。Discord是一款集语音、视频以及文字聊天于一体的服务软件。最早服务于电子游戏社区，但现在也用于AI、Web 3.0、艺术、音乐等领域。用户可以在Discord上创建和加入各种类型的服务器，与其他用户进行实时的聊天和交流。Discord服务器是Discord的核心功能，每个服务器里还能有自己的频道，用户可以在频道内与其他用户进行实时的文字、语音和视频聊天。在我们的场景里面，游戏玩家正是通过这些频道发起生图请求，并通过Discord服务器传递到接入层中。

接入层实现了一个Discord bot，该bot包含两部分功能：1，更新command，command是用于引导游戏玩家便捷输入照片和提示词，并获得相应的输出照片。2，对来自游戏玩家的请求做筛选过滤和初步处理，在3秒钟之内（Discord协议规定）做出初步响应，同时把符合条件需要生图的请求转发给SQS。

接入层的Discord bot的实现参考了Amazon Blog:An elastic deployment of Stable Diffusion with Discord on AWS，采用的是API Gateway+Lambda的Serverless架构，该架构提供了事件驱动型计算服务，使用者无需预置服务器便可快速构建自动扩展的程序。Discord bot是SQS消息队列的生产端，通过SQS来实现与后端AI推理层的解耦。

后端AI推理集群：

SQS的消费端是基于EKS构建起来后端AI推理集群。

首先，是一个controller模块，它会从SQS消费来自游戏玩家的消息以及相应的消息回调接口，之后按频道把消息分发到不同的Stable Diffusion（SD）生图服务中，等待生图完成后，会再把生成的图片等结果发送到指定的消息回调接口，至此，一条游戏玩家生图请求就算最终完成了。

其次，是sd-svc服务，每一个服务托管了一种我们预设好的Stable Diffusion模型和算法组合，在本文后续部份，我们将会用AUTOMATIC1111/stable-diffusion-webui来托管我们的模型和算法。AUTOMATIC1111/stable-diffusion-webui是一款当前流行的基于Stable Diffusion打造的工具应用，通过它可以方便进行文生图和图生图，并集成各种社区的插件，比如LoRA和ControlNet等。它自带Web界面，也同时支持Web API访问，本文中将使用Web API来访问。

在模型选择上，我们将选择一个已经事先训练好的包含魔兽世界游戏素材的模型rpg_V4.safetensors，以及一个ControlNet Canny模型control_v11p_sd15_canny做为演示。在实际项目中，您还可以根据实际的游戏，利用该游戏素材，训练出具备该游戏特色的模型（关于Stable Diffusion模型训练，不是本文重点，如果感兴趣，可以参考如Hugging Face的训练一个diffusion模型文档）。

在面向C端游戏玩家的场景，如何在满足高并发的服务的同时，也兼顾成本效益，这是绕不开的话题，为此我们做了以下优化：

bottlerocket-images-cache+高性能EBS：实现快速集群扩容。一般的扩容过程是：请求新增Node→启动并初始化Node→启动Pod→拉取Container镜像→启动进程初始化→开始提供服务，由于Stable Diffusion用到的pytorch框架以及相应依赖的工具包还有模型十分巨大，一个包含这些完整工具链+模型的镜像往往会达到10G以上，再加上Stable Diffusion webUI本身在第一次启动还有初始化过程，会导致集群扩容过程缓慢，一次扩容往往会达到10分钟以上。这样的扩容速度在面向C端场景里面，会显得比较滞后。我们的做法是：提前预设好优化过的容器镜像，并通过bottlerocket-image-cache把镜像制作成snapshot，做为volumn 被Node在启动时挂载，同时适当提升该volumn的IO吞吐，从而节省了大量的启动和初始化时间。在我们的实验环境里，总共13GB（运行环境78G+2G的Checkpoint模型文件+1.3G的ControlNet模型文件）的镜像在优化之后，搭配IO吞吐为500MB的GP3 EBS，从请求Node到可以开始提供服务（已加载ckpt模型）一共花了1:40分钟。

EFS：实现模型文件一份存储和被动态加载。所有pod都可以通过挂载同一个EFS文件系统，实现动态加载模型的效果，运维人员只需要维护一份模型文件即可。同时EFS优秀的IO吞吐（Gbit/s级别）也保障模型加载的速度。

GPU分片：提升GPU使用率，降低成本。如果您选用的GPU卡性能很强劲，而且AI推理的任务比较简单，无法占满该GPU卡，那么可以考虑让多个推理任务同时复用一张GPU卡来提升GPU卡的使用率。利用NVIDIA/k8s-device-plugin的时间分片能力可以很方便的管理GPU的算力。在我们的实验环境中，我们把一张型号为A10g的显卡切分为3个分片，每个分片各跑一个pod，在推理任务接连不断满负荷的情况下，GPU的利用率可以提升9%（相同工作量的任务，总完成时间减少11.9%）。

Karpenter+Spot：更高的集群利用率加上更好的成本方案，进一步优化成本。

总结

在游戏领域，AI生图营销活动正迅速兴起。本文以方案架构为基础，探讨了面向玩家的AI生图活动的工程化解决方案。通过在Discord等平台引入AIGC生图服务，玩家能够将照片转化为游戏元素，增强了互动与推广效果。这些创新措施共同提升了活动的性能与可扩展性，为玩家创造了流畅而个性化的体验，同时降低了运营成本。

原标题：生成你在游戏中的形象——面向游戏运营活动的AI生图解决方案

原链接：https://aws.amazon.com/cn/blogs/china/generate-your-image-in-the-game-an-ai-image-generation-solution-for-game-operations/

免责声明：市场有风险，选择需谨慎！此文仅供参考，不作买卖依据。