对大模型演进方向的思考

原文： https://zhuanlan.zhihu.com/p/682434451

1 大模型发展的方向是“稀疏”

这里面稀疏指的是，每次执行具体的任务所消耗的资源与整体参数量的比值会越来越低。从以gemm为主到以gemv为主，可以算是一种稀疏（本质上这种稀疏允许了更大的context length的可能性)。MoE毫无疑问也是更稀疏的。从人理解世界的方式而言，稀疏应该是一个比较commen sense的思路。

2 训练和推理的界限会变得模糊

推理的过程中会进行着某种形式的训练 。本质而言，长seq_length带来的巨大的kv cache就是某种意义上的训练，但看起来并不是一种足够高效的方式，所以我感觉这未必会是终极形态。从具体的程序架构而言，在推理的执行模块，对于每层而言，out=op(in0,in1,attrs) 其中op只改变out的值并不足以作为一个足够优秀的抽象。推理框架需要更好的抽象。

3 推理中的诸多常见优化手段会落地在训练的特定结构中

4 通信库会被打开

暴露更细粒度的东西用以调度和融合，甚至不一定依赖通信库。

5 大模型为什么需要推理框架

大模型对于“为什么需要推理框架”这个问题的冲击是巨大的，在大模型兴起之前，TensorRT是对这个问题的一个标准回答，但大模型推理的核心需求与feature与TensorRT是不太适配的（至少在trt-llm之前），简单讲一下几个点：

5.1 batching的问题变得复杂（continue batching等）

原本只需在TRT上套一层很薄的triton即可，现在一方面是batching的策略本身更复杂，另一方面batching与框架未必能很好的解耦，因此如何完成大模型时代的batching层抽象是一个需要思考的点。

5.2 kv cache的管理

首先kv cache本身需要持续更新就是一个巨大的冲击，其次kvcache的显存管理看起来会是大模型推理中的一个核心点，当下最突出的体现是PagedAttention，很多人喜欢把PA和FA做比较，但在我看来本质不同（从系统实现视角来看），毫无可比性，FA的本质是融合算子的一种新的实现方式，但PA意味着对显存管理提出了全新的要求。PagedAttention不会是终点，系统设计如何抽象出这种管理，从而迅速吸纳新的方法是一个重要的演进方向。

5.3 模型表示

Onnx看起来不适合作为大模型的表示层，模型表达层看起来正在往torch API或者类torch API收敛，这对于模型研发的迅速迭代当然是友好的，但当大模型逐渐进入落地阶段，是否有新的idea或者收敛点值得关注。

5.4 推理功能

在大模型之前的时代，模型结构不断发散，但推理功能的形态是稳定的，因此推理框架演化的结果是重Builder，轻Runtime。但大模型时代恰恰相反，模型结构相对稳定，推理功能却花样迭出，因此需要一个灵活的，预留足够空间的Runtime模块，Builder的各种优化反而变得简单。