原文：https://zhuanlan.zhihu.com/p/730537639
LLM推理框架在这大半年的时间里面经历了非常快的演进与迭代，本文整理一下自己从AI芯片公司的视角对LLM推理框架的一些思考。
AI芯片公司的交付界面
AI芯片公司需要投入巨量的资源打造自己的软件生态已经是一个大家都会接受的结论了。而打造软件生态就必须要思考一个问题，那就是AI芯片公司在某个场景下最核心的交付界面在哪里。芯片公司当然可以从最底层撸到应用层，即便抛开资源问题不谈，这么做还是面临个严重的问题，那就是用户失去了自己根据业务灵活进行开发的空间。所以芯片公司和用户都希望找到的一个理想的交付界面是，在这个软件层次之下，包含了和硬件强相关的各种细节，在这个软件层次之上，用户可以灵活定义自己的业务。
在大模型爆发之前的推理场景，这个最优交付界面非常明显，那就是推理框架，代表当然就是TensorRT。TensorRT可以说是一个非常完美的交付界面，对下来说，和NV硬件有关的各种细节，包括Kernel编写，算子融合，私有格式，多流调度都可以放在这个界面之下，对上来说，所以业务的需求都能收敛到很简单的一点，那就是在模型结构确定的情况下，尽可能快速地完成推理。再往下一层到算子库，一是用户自己组网很麻烦，二是很多硬件细节兜不住（比如算子融合的策略），再往上一层到服务层（Triton Server），一来并不是所有业务都需要，二来和硬件解耦，对构筑软件生态的护城河帮助也不是那么大了。所以对于NV的竞争者来说，进攻推理场景的策略也很明确，那就是做出来TensorRT在自己硬件上的平替产品，甚至接口越像越好，可以看到很多国产芯片公司也是这么做的。虽然细节上不乏槽点，但大思路应该没什么问题。
LLM时代发生的变化
而进入LLM推理场景之后，一开始大家的思维惯性应该是和之前一样，试图主要从框架层面去构筑硬件护城河。而随着技术的迭代，大家基本也都或多或少意识到了问题，在框架层面去平替NV会很困难，说得具体一点就是国产芯片公司想拿着自己的框架去和大模型创业公司说，来吧，用我们自研的这个框架跑我的卡，对方很难愿意买单（即便TCO差距不大）。
究其原因在于，LLM推理框架的实现内部已经深度耦合了各种业务细节，或者说框架在很多问题上的实现体现了业务的取舍。
当用户在NV的硬件上把当前的业务比较好地run起来之后，换一个框架重新进行适应和调整的难度其实很大。
这些取舍大概包括：
-
prefill与decode的SLO的取舍；
-
SLO与成本的取舍，比如攒batch的激进程度；
-
资源管理的弹性程度；这会大大增加系统的复杂度与维护难度，而其收益却与服务的规模相关，所以也可以算是一个取舍；
-
prefix caching的激进程度；代价与上一条类似，收益与业务形态相关；
-
对长序列的支持力度；长序列优化的很多手段对于上述几点都会产生影响；
-
量化；
这些因素决定了，除非硬件有代差优势，不然芯片公司几乎不可能在不知道用户具体取舍偏好的前提下，做得比用户现在用的框架更好。所以会发现在各种开源LLM推理框架遍地开花（那NV的软件壁垒应该不那么高才对）的情况下，国产芯片公司发现要从NV的蛋糕上面切一块似乎还更难了。（这里说的是大量卖卡给牌桌上的真正的玩家，卖个几张给用户，把LLM跑起来玩一玩当然就不用考虑这些取舍了）。
第一种是参考TensorRT-LLM走开源或者半开源的路线，至少将和业务耦合相对比较强的部分开源出来。但这么做有效果的前提是开源得开出影响力，不然用户似乎也不会愿意陪你玩儿。国内的某头部玩家也许可以考虑这么玩儿，其他家似乎不太容易做出影响力。
第二种是将交付界面网上走一层，走标准化的服务层的接口。但如果你还是卖卡给用户，让他自己部署然后调服务，似乎也没解决啥问题。更激进的做法是芯片公司直接自己做云卖token，做云就可以拿到用户的真实场景benchmark，然后自己考虑平衡点，反正最后能做到足够便宜就行。这对技术实力，包括硬件和软件的要求就不是一般高了（想要真的赚钱的话）。
第三种是将交付界面下移到算子层。这条路其实是最可行的，因为LLM的算子非常的清晰，就是那么几个。但这条路目前最大的问题在于，框架和算子的软件分界问题，虽然已经迭代出了flashinfer这样的算子库同时被vllm和sglang作为可选的后端，但应该说软件抽象还并没有收敛到一个很清晰的状态。从vllm当前的实现来看，其实也增加了tpu和xpu的后端，不过都是从executor层就开始和gpu进行分叉，这应该说还是一个非常丑陋的软件抽象，因为会引入很多无意义的代码复用，我认为不应该是最终的软件形态。如果往理想的方向思考，我目前想到的难点大概有：
