大模型计算方式会如何变革，一直是一个持续思考的问题，简单记录一些思路，逻辑并不严谨，不怕打脸，一年后再看。
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的各种优化反而变得简单。
综合几点来看，大模型对于推理框架的设计哲学的改变是革命性的，已有的成熟的推理框架显得过于陈旧，难以完成这些变化，而新的推理框架又过于简单(以vllm为代表)，24年的博弈会非常精彩。
6 关于AI编译器
一种比较有市场的说法是，大模型时代模型结构基本收敛，因此定制算子足以满足需求，换而言之AI编译器路线就没什么意义了。个人对于这种说法并不认同，首先模型的核心结构虽然收敛了，但模型细节还是处在不断微调之中，而大模型推理中算子融合的粒度非常大，如何让融合算子灵活地支持细节的微调，个人认为是需要AI编译器的。
另外，AI编译器其实有两个兼容（这里的兼容指的是低成本的扩充，不知道该用什么词）的方向，向上兼容模型结构，向下兼容不用硬件，而第一个兼容方向从市场实际应用程度而言，目前其实是比较失败的，这也意味着推理基础软件的话语权基本掌握在芯片厂商手上，说的更直白点，最好的推理框架只能是芯片厂商做的。大模型如果说降低了AI编译器的难度的话，那就意味着兼容各种底层硬件的大模型推理框架是能做出来的，再结合上面那一点对于推理框架的讨论，也许会有开源社区/第三方公司取代芯片公司的主导权。