阿里面试惊现难题：大模型服务吞吐率太小咋整？

我是丁师兄，专注于智能驾驶方向大模型落地，公众号：丁师兄大模型。

大模型1v1学习，已帮助多名同学上岸国内外大厂

---

想象一下，就像咱们家里的水管，正常来讲水应该哗哗地流，可要是这管子太窄了，水就只能滴滴答答，让人干着急！

当下咱们面临的大模型服务吞吐率太小，不就类似于这窄窄的水管吗？当面试官问你有没有办法把大模型服务吞吐这个“管子”拓宽，让数据像奔腾的江河一样顺畅流淌，你准备怎么解决？

01面试官心理分析

当面试官问你这个问题的时候，其实面试官主要是想考验你如下 3 个方面：

• 第一，在实际业务中，你有没有做过大模型服务性能的调优？
• 第二，你是否了解大模型服务吞吐率跟哪些因素有关？
• 第三，展开你实战用过的优化技术，说明是怎么解决这个问题的？

02面试题剖析

大模型服务的吞吐率太小到底该如何解决？我们沿着面试官的心理预期，我们来逐步回答一下。

首先我们看一下吞吐率是怎么计算的：吞吐率 = 处理的请求N / 延时

也就是：在一定时间内，服务处理的请求数除以消耗的时间。那我们看一下分母，模型处理的延时跟什么有关，是不是模型的 forward 的时间。我们当然希望模型 forward 实际计算的时间尽可能的小。

再看一下分子，怎么能让分子变大？

处理的请求 N 跟 2 个因素有关：一是模型一次能处理的条数，也就是 batch size。二是服务的实例数量，也就是部署了多少个节点。一个节点能处理 N，那 k 个节点理论上能看*N。这两个因素都直接增大了分子。

分析到这里，我们首先回答出面试官心里预期之一：大模型服务的吞吐率跟 2 个因素有关，一是模型单次推理的延迟，二是模型一次能处理的请求数量。

因此让吞吐率提高的方法是尽量降低模型的推理延迟，同时增大模型的并行处理请求的能力。到这里只是回答到了第一层，最基本的概念。

继续分析，大模型的单次推理延迟，有几个方向：

首先是可以减少计算量，可以采用权重+激活量化来解决。如果 profile 到服务的计算资源还有空余，比如 GPU 的利用率只有 60%，也可以用投机采样方法来做，即用一个小模型来猜测+大模型验证的方式。

另一个方向是提高访存的利用率，这要结合所使用模型计算量来分析，如果模型不是计算密集型的，即计算速度比访问内存速度快得多，这时候主要就是受到内存(HBM)访问的瓶颈。

在 self-attention 中，大部分都是属于这种情况。因此减少访问内存次数，可以极大提升单次推理速度，flash attention 就是这个思想。

大模型的并行处理能力，有两个优化方向：

一是在显存运行的情况下，增大模型一次处理的batchsize。这里就有多种方法，静态的 batching，动态 batching，以及连续的 batching 等等，差别就是合并 batch 的方式不同而已。二是在业务条件允许下，水平扩展，增加节点数。

这里就要考虑都 scaling 的问题，即增加节点数后，要尽可能最大化利用每个节点的计算能力，这就需要考虑到负载均衡的问题。比如用 K8S+GPU 利用率监测+QLB 负载均衡来调优。回答到这里，就算回答到了第二层，即从概念到具体解决方法。

最后进阶一下，用业务中实际用过且行之有效的技术来让面试官信服。这里要注意一点，就是一定要注意重点，选最重要，适合落地的方法来讲，这也是考验你技术选型的能力，切忌主次不分。

回到问题，如果是优化吞吐率，影响最大的因素肯定是模型处理的并行度，单次推理延时影响的是单个用户的体验，而并行度是高并发情况下的多个用户的体验。

另外，从实际工程经验来看，如果增大 batch size，会以 10～30% 的单次时延增加，换来数倍甚至数十倍的吞吐率加速。

最后一层回答就以现目前最流行，加速最明显的 continuous batching 技术，来详细讲解是如何和实际业务模型结合的，至于它的前身，static batching，dynamic batching 就可以一笔带过了。

为什么有这个方法，原因是大模型服务不能假定固定长度的输入序列，也不能假定固定长度的输出序列。因此对于 static batching 或者 dynamic batching 来说，生成输出的变化可能会导致 GPU 严重未充分利用。

因此在 OSDI 2022 上发表的 Orca 是第一篇解决这个问题的论文。它采用了迭代级调度，一旦批中的一个序列完成生成，就可以在其位置插入一个新的序列，从而实现比静态批处理更高的 GPU 利用率。

如上图所示，使用连续批处理完成七条序列。左图显示了单个迭代后的批，右图显示了多次迭代后的批。一旦一个序列产生结束序列标记，我们在其位置插入新的序列（即序列 S5、S6 和 S7）。这实现了更高的 GPU 利用率，因为 GPU 不需要等待所有序列完成才开始新的一个。

实际在代码实现时，还需要根据服务是流式输出还是一次性输出做进一步优化。如果是流式输出，则需要利用异步协程的 async 和 await 来实现计算资源的切换，实现在 token 粒度级多用户输出。

更进一步，在这个过程中，tokenize 和 detokenize 也可以用异步协程来实现，进一步提高编解码速度。在回答过程中，你可以画图或者结合用例给面试官讲解出来，体现你对这个算法的熟练掌握程度。

到此为止，才可以算得上是一个优秀的面试回答了。

END

---

我是丁师兄，专注于智能驾驶方向大模型落地，公众号：丁师兄大模型。

大模型1v1学习，已帮助多名同学上岸国内外大厂