【AI问爱答】第六期问答节选
本期主题
提升GPU性能是模型训练变快的最佳途径吗？哪些方法能实现GPU的高效利用？
回答专家：
王超，阿里云智能计算集群灵骏负责人
深度问答
Q1：怎么选择适合特定AI任务的GPU架构和型号？
王超：AI时代来临以后，我们把GPU计算的相关地位抬得非常高，实际上GPU参与计算已经有二十多年的历史了。
这里说的GPU选型，是我们focus在训练这一特定场景或者大模型训练场景里讨论GPU怎么选型。今天的大模型大部分是指基于transformer结构的LLM模型，包括一些DiT模型，已经不再指传统的ResNet或者CNN这些模型了。那么focus在transformer结构的模型里面选择GPU其实很简单，scaling law中的scaling 是什么意思？scaling其实原则上有两个意思，一个叫scaling up，另一个叫scaling out。我们可以把scaling up理解为摩尔定律，把scaling out理解为香农定律。当摩尔定律走到尽头时，半导体走到尽头时，我们只能通过scaling out，通过香农定律，通过通讯的方式来扩展所有的计算。所以在transformer结构下的LLM大模型其实没有什么GPU选型，就选最好的内核GPU，最强劲的内核GPU，来满足仿真型模型训练的需求。
把问题变一变，GPU的选型不光是指大语言模型中训练场景的需求。比如传统的搜索推荐类的模型，甚至搜索推荐类的推理场景，那么选型就非常丰富了。比如推理场景，这里有一个简单的换算关系，不管性能如何，先要把一个模型塞入一张GPU，然后才能推理，那么根据显存、模型的size来换算，如果做了八位的量化，那1B的参数就是1GB的显存。通常72GB的显存才能把一个72B的模型load进去，如果一张GPU有72GB以上的显存，那么可能用一张就可以了，如果一张GPU显存不够，那还需要两张或者四张，就需要考虑GPU本身的计算能力。计算能力其实跟我们服务客户的体感是强相关的。比如客户输入了一个问题，多久可以把这个回答反馈出来，首包的速度，以后每秒生成的token能不能赶上客户阅读的速度。人阅读文字，可能是一秒钟20个字左右，至少要达到这样的速度，才让客户有好的体感，否则就像看幻灯片一样，非常卡了。所以在不同的场景里，GPU选型会有一些特定的规则。当然在阿里云的官网上，新上线的AI产品助手——产品博士，他都会给一些建议。
模型训练其实我们讨论的是两点，一个是性能，一个是性价比。简单理解就是今天如果在一个赛车的场景，那我们可能只讨论性能，不考虑燃油经济性的问题，对吧？但如果我们今天是买一个家用车，那肯定要考虑燃油经济性的问题，考虑性价比的问题。
实际上很多低端点的GPU，在性价比上或许是一个比较好的选择。但模型训练场景中所有的GPU都会有一个特点，就是在一台机器里的GPU，有一个超越以太网的更高速的互联，把GPU连在一起。在训练场景中，首先要满足scaling law里面scaling out这一基本条件。比如在训练场景中，我们使用英伟达的A100，它有类NV link互联，其他很多厂商的GPU，它也有name的命令和技术在互联的。这种GPU才是训练场景中的有可选性的列表选项。
比如英伟达的A10或者是一些桌面的显卡，它本身是一个PCI-Express结构的。即使一台服务器中有四张卡或八张卡，它本身是没办法进行高速互联的。实际上它就不是我们在训练场景中的一个好选择。
Q2：GPU是如何让模型训练更快？哪些因素会影响GPU的发挥？
王超：首先满足scaling up把一颗GPU本身发挥到极致，如果今天可以突破摩尔定律或者可以做一个足够大的GPU，一个任务用一个GPU来跑，那么显然不需要把多个GPU连在一起，今天物理学的限制，使得我们必须把上万颗GPU连在一起做一个任务。我们先考虑单一GPU怎么发挥算力。第一个就是怎么样把GPU本身所包含的上万个计算单元全部用满。第一个层面就是算子本身，我们的算子本身是不是高效，算子本身需要用cuda的接口，大量开源的算子其实都是基于cuda接口做的。有些算子可以拿来直接用，有些在训练场景中需要独特的算子，那就要手写算子，并且在cuda接口会比较通用一些，大家可以跑起来的。当然其他家的接口，比如M9.com的接口也非常优秀，先把算子本身做好，剩下就是并行计算，怎么让所有的GPU不能闲着。
训练本身是一个并行计算，每计算一个step后会同步权重，这时就牵扯到框架层面的事情了。我们常说5D并行的策略，本质上是让计算跟通讯变得更高效。这里面核心的一个原理，其实就是让计算和通讯是overlap的，也就是说在通讯传递这些权重的时候，计算不会等待，如果在传输过程中计算等待，那么GPU就是闲着的，而且最短板的那一颗GPU所造成的等待，因为它是木桶效应，所有的GPU都在等他。
物理上，需要一个足够大带宽的网络，让我们权重通讯的时间更短。第二，一个很核心的问题是我们要避免长尾效应的出现。虽然路修得很宽，但是有一辆车跑到了最后，这是要极力避免的，大家都在等他最后一个人完成通讯的同步。第三个就是并行策略。当我们有比如模型并行、pipeline并行，这个就是我们曾经说的TP、PP、DP、EP这些并行的策略。这些并行的策略就是在通讯的时候，GPU已经进入下一次计算了，把计算跟通讯拆开。如果我们的算子又高效，然后整个通讯跟计算又是完全overlap的，那就可以让整个模型的训练达到最快的速度。
Q3：诸如共享单车类的典型客户，在上下班晚高峰对GPU使用率高，但平时较少，是否有针对GPU高效利用的解决方案？
王超：这个问题不是GPU特有的一个问题，在CPU时代就有这个问题。如果所有的用户都处于同一个时区的话，那就有典型的潮汐效应。白天是峰，晚上是谷。所以在CPU时代我们有一些技术叫离在线混布或者是晚上跑一些离线任务。
在GPU场景这个问题会非常明显。因为GPU白天的计算量非常大，而且今天GPU还是一个生产力工具。不光是白天的工作量非常大，工作日的负载量远远大于休息日。那么就要找到一些任务，把整个GPU在非在线的时候，用离线的任务把它堆满。
这个对GPU是非常适合的一个场景，因为GPU有大量的离线任务。我们可以把整个GPU集群化。白天的时候，使用这个集群做推理，做一些轻量化的训练。比如说SFT或者Finetune，这是一种典型的训推一体。其实不是一体的，是白天推理，晚上训练。
二是GPU可以处理很多其他的事儿。比如说渲染性的任务，大量的图形图像的处理可以在晚上去做。
三是GPU还可以做很多其他的方式。比如有很多金融公司用GPU的数据在算当天的量化交易。他们在休息以后晚上做。我们可以找一些周期性的离线业务，把GPU放在晚上使用，来达到分时的效果。GPU的分时，我们并不是把一个资源去分时，而是把任务去分时。我们把一些在线的任务，实时的任务放在高峰期去做，把谷期的资源拿来去做一些离线的任务。
Q4：在多模态的场景中，如何有效管理和利用GPU内存资源？
王超：多模态也好，DiT图形图像模型也好，包括MoE的模型也好，都是未来的趋势。甚至可能未来会从Density这个模型转向MoE模型，这些模型的size都非常大。在今年英伟达的峰会上，黄仁勋也公布了GPT-4模型的size。它是一个1.8TB的多模态的模型，对推理的要求非常高。去年3月份GPT-4出来的时候，当时世界上没有一台GPU服务器可以把这个模型推动的。可以推测他肯定是用多台机器推理一个模型。单机部署的GPU服务器可能没有办法推动这种超大型模型。即使在推理场景中，我们也要做到集群化的部署，用多台机器来推理这个模型。当然我们可以通过一些模型剪枝的技术，模型压缩的技术、量化的技术来缩小模型的size，但是它本身也会降低效果。
所以现在所有的前沿技术不管是chunk prefill，还是splitwise，所有的技术都已经开始去做集群型的分布式的推理。通过网络的技术，通过KV Cache迁移的方式，来达到整个集群算力的最大的有效利用。
所以在多模态模型实时推理的场景，需要更多地去考虑一些分布式推理的技术。当然这些技术比较前沿，可能只有超大的多模态的模型才会去考虑。而这些超大型的多模态的模型，目前只有少数的几家做仿真性模型的厂商手里才有，目前还没有这种尺寸开源模型。
Q5：GPT 4o mini小模型对GPU的使用压力更小吗？
王超：其实并不是所有的问题用大模型都会比小模型好，但是在通用型的overall的全局场景里，模型的size和训练的参数量还是决定了模型的效果（相关）。剪枝以后的小模型可能在一些特定场景里效果还不错，但这种模型个人判断会比较趋向于to B，因为to B客户需要熟悉的领域比较集中，垂直性比较好一些，效果会比较好。如果我们是一个to C的模型，那泛化能力太强了。所以回到GPT-4o，因为他当时是to C的，和所有人聊天，他的模型size一定不会小。如果说并发的话，其实延迟也很严重。
Q6：多模态进一步的发展涉及到更多的实时推理跟部署，GPU哪些技术特性对实时性影响会比较大？
王超：本质上这一代的A技术对于实时性的要求已经弱化了非常多，和上一代大数据场景里对于实时性的要求已经不可同日而语。上一代大数据场景里面，我们可能会经常要求大数据和计算是布在同一个region内的，或至少布在同一个城市里，一旦跨region产生的延时就非常严重。但是AI这个场景里面，对于实时性的要求已经远弱于大数据时代了。我们可以看见很多前端应用，背后的模型调用是API方式，那API方式的模型的推理可能产生于大洋彼岸。所以这里的实时性的推理其实更多的是趋向于客户的使用体感。
模型所产生的内容和终端用户在实时交互，所以很多情况下要考虑用户体感的问题。比如他问一个模型以后，多长时间可以给他一个回复。从视觉的角度来说，多长是一个合适的值。人一秒钟能读多少个字，对吧？从听的角度来说，人能接受的打电话的延时是多长的时间？多快的语速他可以接受？我们要考虑到人类、人体生物本能的一些事情，来决定我们计算的速度和响应的速度。
Q7：GPU的能效与模型训练和运营成本强相关，如何提高GPU的能效比？
王超：在能效上我们把训练和推理分开看。训练一方面是要我们把本身算子的性能做好，把一张卡本身的计算效率做高。第二个我们做计算跟通讯的overlap，尽量让计算不要停止，不要等待通讯。抛开这两方面以后，我们怎么样去增加训练的东西呢？
整个训练是一个持续几十天的过程。中间当我们训练的规模越大的时候，会遇到越来越多的意外情况。比如前一段时间发布的Llama3.1 405B的这个模型的时候，Meta团队也公布了一个他们的工程日记，明确写到在1.6万卡的训练的任务size下，他们使用了1.6万张H100来训练Llama3.1 405B这个模型，一共训练了42天，其中中间意外中断413次。大家可以理解平均每3小时就会中断一次任务。每次中断任务，有些是GPU本身、有些是网络通讯、有些是CPU侧出现了故障。不管怎么样，今天的训练还是一个零容错的形式，所以一旦出现故障任务就会停。
那么问题来了，每一次出现故障我们要重新load check point，会耽误掉一些时间，我们今天只是16000卡的任务，如果10万卡的任务，可能是每20分钟一次，然后重新load任务要20分钟的话，我们就可以不用训练了。所以真正在训练的过程中，稳定性是非常重要的东西。有时候我们可以牺牲5%的最高速度，来保障不要把任务停掉。稳定性一方面包括硬件的容错设计，比如说网络做双向连，我们可以避免网络的容错。第二个就是我们要做check point的加速和异步。我们可以让每一个step都存check point，重新load任务的时候就不会损失训练的时间。第三个优化load任务的时间，一个可能405B的模型，我们启动任务就要十分钟。那1TB的模型启动任务要多久呢？当我们把故障率降下来，把每一次重新启动任务的时间缩短，那就可以把更多时间省下来，用来做训练。因为规模的增大，故障的概率就会跟着规模一样指数级增加。所以我们节约成本，更多要考虑容错的问题，故障的问题。
尽管现在开始用集群来推理了，大部分情况下，故障还是发生在一台机器或者几台机器之内。所以容错就没有那么重要。更多时候是考虑到这个GPU本身能不能用吧？这里面有几点，一个是更好的量化平衡，训练的时候可能使用十六位的精度，但推理的时候是不是要做八位精度的量化。这样降低一半的显存，这个模型的效果是否还可以让我们满意。第二个问题就是因为整个serving的状态，是一个分布式的系统，要考虑前端的load balance和后端承载任务的计算单元之间的平衡，不要出现局部的热点。
那我们怎样更快地load不同的模型在同一个物理资源上。我们本身肯定不是用同一种模型服务所有的客户。可能要在一个机器上切换，对于整个分布式系统也要做得有效率，而不是集中在单点上说这个模型每秒的token数是多少。在实际的操作过程中，token不可能是24小时不停在一个模型上去产生，所以要考虑到流转的效率。
局限到说单一的模型，怎么样在一台卡上把效率提高？可能要考虑到比如说引擎层面的问题。除了用NV的tensor RT，开源的vLLM，阿里云整个PAI平台还有自研的blade引擎，包括现在有一些第三方的开源引擎做得也不错。这个要基于你实际模型的效果去实验不同的引擎，是不是能带来本身单一任务的提速。以上综合考虑才能决定效率的提升。但是我觉得大部分客户，或者说这个世界上95%的客户，其实不需要考虑这些问题，原则上去购买通义的token应该是最具性价比的一个方式。这样的话有很多工程算法以及相关的运营工作流人员都不用去做整体的方案。
Q8：中小企业如何根据自身业务选择GPU和模型？
王超：如果客户有这方面的诉求，那他可能需要具备一些基础的知识，云上面其实针对于不同的模型，也有不同的推荐的GPU的型号。很多的情况下，只是说这个实例可以把任务跑起来。但是实际上不同的客户的serving状态，对于跑起来的效果要求也是千差万别。比如说如果你是一个DiT的模型，要生成一张图片，那客户能容忍这个图片的排队的时间是多少？一个图片几个小时还是15分钟，几个小时客户也在容忍，但to B不能有这种形式吧，所以一定要基于不同的任务形态去想这个问题。
这取决到一个问题，就是你最终服务的SLA到底要达到什么样的效果，会完全改变你对于GPU的选择，如果你不是一个特殊的私有化模型，大部分情况下是一个开源的模型。那其实你还是应该把选型的事交给模型服务团队。因为我们的模型并不是只基于token去售卖的，每一个不同的token背后都有相对应的SLA。
Q9：阿里云平台提供了什么样的GPU资源？
王超：阿里云的云平台上几乎有现在所有主流的GPU的选型。因为AI火热，有些GPU可能库存的水位不够高，经常会遇到开不出来的情况。我们有单机和集群两种形态的资源来提供。在每一种资源上，我们会有裸金属的形态，有VM的形态，有容器化的形态。在上面也有任务化，基于PAI这个平台有任务化的形态，基于百炼有更高级别的形态的选择。比如说训练的场景，我们原来有A800的显卡、H800的显卡。那推理场景中我们有A10显卡、L20显卡，都可以满足大部分通用场景的一些诉求。
Q10：微调一个模型需要占多少GPU显存呢？
王超：讨论微调的时候，其实不应该去考虑GPU显存，更多考虑你有多少token需要去计算，有多大的计算量。理论上，比如说正常的训练情况下，一张卡可能装3到5个B的参数量是吧？那么假设通义千问72B这个开源模型，我们就用它来调，可以大概得出至少需要4台机器才可以把一个72B的模型load进去。
如果你为了提高速度，可能在并行展开多个DP对吧？那是取决于你计算的token数和你需要计算的时间。如果你的token数非常大，并且处理后生成的数据输出也非常大时，那你可能要并行展开多个DP来节约你的时间。如果你的token数比较小，那可能4台机器都可以做finetune。
现在很多观点也认为计算量非常小的finetune可能带来模型效果的改变会很少，实行的意义也不大。这个最终取决于你希望模型最终达到的终态效果是什么样的。可能在某些场景里，比如说在DiT场景里面，通过loRa的技术做一些个人的数字证件照，这些场景里面finetune是非常有意义的。但我觉得在大语言模型或者多模态的模型里面finetune可能效果就没有那么强。
热门跟贴