AI算力池化赋能企业大模型价值探索

1. 大语言模型企业落地中的算力痛点

随着人工智能技术的飞速发展，自然语言处理（NLP）成为了热门的研究领域之一。在这一领域中，大语言模型（Large Language Models）凭借其强大的语言理解和生成能力，逐渐成为了研究和应用的热点，越来越多的企业开始将其应用于实际场景，如智能客服、虚拟助手、内容创作、内容审核、机器翻译等。

目前各大厂商都发布了自家的大模型，除了基于大模型改造或者重构现有的应用系统之外，一些大型的厂商选择将自家的大模型进行开源，因此大模型也逐渐被应用于医疗、金融、智能制造等领域。这些领域都需要处理海量的数据和实现复杂的任务，大模型能够提供更高效、更精准的解决方案，具有广阔的应用前景。

对于大部分企业来说，从头开始构建基础大模型不切实际，因为需要花费巨大的成本构建AI算力集群。据相关报道，GPT-3的训练使用了微软专门建设的 AI 计算系统，由1万个 V100 GPU 组成的高性能网络集群，如此大规模、长时间的 GPU 集群训练任务，对AI算力成本提出极致要求。好消息是目前已经有很多开源的大模型，企业只需要基于开源的大模型结合自身行业数据运用大模型微调技术就可以构建一个属于自己的行业大模型，大大的降低了大模型的使用门槛，但企业在尝试大模型的时候也面临了一些问题，主要包括以下几点。

（一）算力资源无法共享：不同业务部门基于开源基础大模型进行微调，构建自己的行业大模型，如果独自采购AI算力资源，各部门之间的算力资源无法实现共享，对于公司来讲无法实现物尽其用就是一种浪费；另外一方面，企业招聘AI工程师成本也非常高，如果由于不同业务部门AI算力资源不能共享导致AI工程师不能正常的开展工作，对于企业来讲也是一种损失。

（二）业务场景无法混部：部门内部也会出现开发训练推理部署环境隔离的情况，导致AI算力资源无法实现灵活复用。比如在白天的时候，开发和推理业务会比较繁忙，资源会出现瓶颈，但这个时候其实是可以把训练资源挪一部分给开发推理使用，毕竟训练任务都是长周期运行，短暂的减少部分训练资源也可以接受。到了晚上，AI开发工程师下班，同时推理业务也处于一天中的低谷期，这时可以把开发和推理资源挪给训练任务使用，从而加快训练的速度，弥补白天减少的训练时间。

（三）运营运维无法统一：不同部门、不同业务、不同场景下构建的AI算力基础设施缺乏统一的管理运维工具。AI算力是企业的重要资产，首先要做的就是知根知底，必须要有一个清晰AI算力资源大图，能够实时的监控到AI服务器、AI算力卡的分配、使用以及健康状态。同时由于任务类型差异、任务规模差异、任务优先级差异以及任务调度能力等多方面因素，会出现AI资源碎片、AI资源使用不均以及软件系统升级维护问题，最后就是无法从部门、业务、场景的维度出发，以每日、每周、每月、每季度的维度统计生成数据报表，为AI算力资源运营提供数据参考。

（四）异构厂商无法兼容：随着国产信创工作的推进，越来越多的企业也开始采购国产AI加速卡开展大模型业务。未来客户数据中心将会出现不同厂商的异构AI算力卡，如何更好地管理和使用各家的AI算力卡也是企业面临的一大挑战。

2. 算力调度解决方案

如何对稀缺、昂贵的算力资源充分利用，实现算力的最大化共享，降低其不可分配的碎片概率，可以考虑借鉴云计算的思路。首先通过虚拟化软件对不同节点上的GPU、AI芯片等进行切分，然后将切分后的资源上报给集群调度框架插件，最后集群调度框架插件根据任务对于资源的需求进行灵活的调度和分配，使能资源可按任务的实际需求进行有序供给。

目前业界的方案包括集群调度框架插件和节点虚拟化软件两部分构成，一般都是同一个厂商将这两部分打包成自己的解决方案。

（一）集群调度框架插件：通过高性能算力网络打通服务器间通路，使得分散在各服务器中的CPU、GPU、AI芯片等算力资源可以通过高速无损网络实现互联互通、透明共享。根据任务对于资源的需求，通过先进的调度策略将任务调度到不同的节点，如果任务要求整卡的资源，那么就会被调度到有空闲整卡的节点，如果任务要求细粒度卡的资源，则会被调度到有空闲虚拟卡的节点，从而实现资源的高效分配。

但不论是调度到整卡还是虚拟卡，集群调度框架插件只会按照任务的需求选择合适的AI算力进行分配，而无法决定任务是否真正在使用AI算力资源。比如要启动一个Jupyter开发任务，并为其分配了一张虚拟卡，但实际上连接到这个Jupyter服务的开发人员却没有运行AI应用程序，因此这张虚拟卡就被白白占用浪费。目前比较常见的集群调度框架插件有基于K8S开源的gpushare和elastic-gpu，基于Volcano开源的GPU Sharing以及宣称有GPU虚拟化能力的K8S类厂商。

（二）节点虚拟化软件：通过用户态或内核态的方式对AI算力资源进行虚拟化，可以实现算力和显存维度的简单或任意比例切分，能够实现单机多卡的聚合，如果是多机多卡等跨节点的资源需求则依赖任务管理模块将作业切分成多个分布式的任务，然后任务被集群调度框架插件调度到合适的节点，因此节点虚拟化软件和集群调度框架插件必须同时使用才能在一定程度上解决以上问题，目前比较常见的节点虚拟化软件有cGPU、qGPU等云厂商的GPU虚拟化方案，以及开源的GPU Manager。

3. 算力池化解决方案

相较于集群调度框架插件和节点虚拟化软件构成的算力调度解决方案，趋动科技的OrionX AI算力资源池化解决方案是基于软件定义的技术在硬件AI算力之上实现的资源池化，可以实现真正意义上的AI应用与算力的解耦。

这就意味着AI应用可以任意部署，正在运行的AI算力任务可以热迁移，无需跟AI服务器绑定，可以将AI应用部署在CPU的服务器上，通过远程调用的方式访问AI服务器算力，在需要AI算力的时候可以在整个数据中心按需取用。具体表现为AI应用真正运行时才从整个数据中心的AI资源池中分配合适的算力资源，当AI应用执行完成之后，就会把算力资源重新释放到数据中心AI资源池中，让其他的AI应用能够使用。对于AI应用跨节点的资源需求，可以不依赖上层任务管理模块将作业拆分成多个任务，而是直接将多个节点的AI算力资源进行聚合使用。

正因为OrionX是用户态实现的软件定义的AI算力池化方案，因此不需要侵入操作系统内核，同时暴露所有的API便于上层管理平台对接，不管是物理机、虚拟机还是容器、K8S场景，都可以很好的适配。

图：趋动科技OrionX算力池化解决方案

OrionX支持主流的训练和推理框架，通过算力池化技术满足大模型在预训练、监督微调、人类反馈强化学习过程中对于AI算力资源的需求，同时基于共享的理念构建的开发、训练和推理一体化AI算力资源池，帮助企业提升资源利用率5-8倍。

总之，AI算力池化解决方案可在实现多厂商AI算力硬件统一管理、统一运营、统一调度、统一使用的同时，结合软件定义AI算力技术实现AI算力的统筹分配、资源池化、高效保障和运维管理，提高企业的人效和物效，加速企业的业务创新，赋能企业在大模型场景下的价值探索。

4. 算力池化下的大模型应用场景

（一）大模型开发及训练场景：通过资源动态调用、动态释放以及队列优先级等功能，代替传统独占GPU卡的方式，可以让开发和训练资源混合部署，实现资源弹性伸缩，打破GPU资源孤岛，节省GPU卡数量，提升算力运行效率；在大模型训练场景下，还可以利用故障检测和热迁移的能力保障训练的稳定运行，利用作业优先级合理调度算力资源。

（二）大模型微调场景：通过远程调用实现CPU和GPU资源的合理配比，将通用算力和AI算力解耦，从而节省GPU卡资源；还可以通过跨机聚合把多机碎片化的资源进行用于训练任务，大大简化了传统分布式训练任务的配置工作。

（三）大模型推理场景：通过灵活切分可以实现多个大模型并行运行在同一张GPU卡上，基于进程级的封装和隔离避免大模型之间的资源争抢，提升GPU卡的利用率，还可以在不增加硬件的情况下通过显存超分实现业务的叠加，大大提升系统的吞吐量。

（四）大模型算力服务场景：通过自定义算力设备可以屏蔽底层硬件资源型号，实现资源抽象定义，为最终用户提供容易理解的各种规格的自定义算力型号，并通过多级资源池对多K8S集群算力资源进行统一管理和分配，打破资源孤岛，更好地支持多租户的算力管理。

（五）运维场景：通过客户端热迁移和故障卡的自动隔离功能，可以有效保证大模型训练任务连续性，减少业务宕机时间；通过服务端热迁移满足运维人员对于负载均衡、碎片整理以及下线维护等运维场景需求，通过逻辑资源组满足统一AI算力池化后的隔离管理需求，支持多部门基于同一资源池高效开展AI业务。

（六）信创场景：通过异构混部实现海光、寒武纪、华为等国产不同厂商AI算力共池管理，通过交叉拉远让AI业务灵活的访问到整个AI算力池中所有不同厂商的算力资源，基于CUDA on DCU支持将CUDA业务无缝迁移至DCU平台，加速信创改造。

5. 客户案例

目前，趋动科技的OrionX AI算力资源池化解决方案已经在金融、互联网、教育、制造等行业被广泛应用在大模型场景的价值探索。

客户基于开源的LLama、ChatGLM、Baichuan等大模型结合企业内部的私有数据进行微调，之后又将微调后的模型服务于企业内部各业务部门，提升员工的办公效率；也有一些客户部署Stable Diffusion用于素材创作，直接为企业创造价值；还有一些高校的客户基于OrionX AI算力资源池化解决方案构建自己的行业大模型，比如南京农业大学就基于自身对于古籍领域的数据积累，打造了荀子古籍大语言模型。