4.1 KiB
现有的大模型推理框架都基于 Python 实现，这其中存在一些问题：
- Python 运行速度较慢，调度部分的开销不可忽视
- 通过 torch/nsys profile 证明
- 基于 PyTorch 的框架导致冷启动较慢
Candle's core goal is to make serverless inference possible. Full machine learning frameworks like PyTorch are very large, which makes creating instances on a cluster slow. Candle allows deployment of lightweight binaries.
- 现有的 Python 架构没有一套好的抽象，data plane 与 control plane 交叉，如果希望动态调整配置，基本上需要重启
- 调度层与推理 engine 层耦合
- etc...
现有的基于高效语言实现的推理框架存在的问题：
- 无法支持最新的加速器算子，现有的许多性能最优的算子（flash-infer, ...）都由作者直接向 vllm/sglang 等社区 push，且针对 cpp/rust 的文档约等于没有，想要自己手动 port 使用上这些最新算子具有很大的工程挑战
- 基于高效语言实现的推理框架尚未建立完善的社区生态的现状下，支持新模型的速度很慢，从而陷入恶性循环
- 这些基于高效语言实现的推理框架未经过充分的验证，大家在推出新模型时都只在现有主流推理框架 vllm/... 上经过充分测试，保证能够稳定的正确吐词。现有的基于高效语言实现的推理框架相比 PyTorch/vllm/... 存在精度问题，长推理下会吐词崩溃
由于上述这些问题，我们认为如果想要克服 Python 推理框架引入的问题，从零开始工程实现一个新的 Rust 推理框架是不现实的（社区已经有很多这样的工作），我们希望以 vllm 作为能够正确推理的标准，定义一套 IR，从而能够 vllm -> IR -> Rust framework，从而零成本的支持所有 vllm 支持的模型，且能够保持与 vllm 相同的推理结果保证推理正确性
Feedback
一个 IR 可以给不同的 backend 引擎，现有的 inference framework 有：
与 MLC LLM / TVM 的生态位差异：
- TVM 擅长静态图，大模型推理的 shape 高度动态
- MLC LLM / TVM 的核心想法是一次编译处处运行，效率并不一定高
vLLM 的核心优势：
- 资源管理，paged attention
- 动态调度
从某种角度来说，我们可以认为 vLLM 是一套大模型推理的前端调度、资源管理的分发决策器。
我们的核心目标是一套针对云服务提供场景的高效推理，与 TVM 的生态位不同，因此我们希望抽象的 IR 应该是：
- 针对分布式系统的大模型部署调优，因为单节点上算子在使用 cuBLAS, cuDNN 时已经达到了基本顶级的性能实现
inference 时高度动态的 shape 和 Alpa 这类工作做最优的计算切分（静态）的矛盾
以上为现阶段的工作，但是我个人的经验无法定义清楚上面这套工作的价值与贡献度，这一套 vllm -> IR -> Rust framework 需要通过实际工作发现其中的挑战，如果这个过程中没有足够的科研工作的挑战（而更多的是一些工程挑战的话），我认为我们定义的这套 IR，也能够帮助我们做自动化地大模型推理部署方案调优。
现有的大模型推理部署方案自动调优的工作都局限于有限的 search space：TP/PP/EP 的大小，可以归纳为简单的 profile+线性规划。我们希望能够 search 出一些更优的部署方案，而不是在有限的 space 内的调优，希望得到一些更偏向机制上的部署方案优化（而不仅是参数上）。
因此我会在当前考虑如何抽象这套 IR 时，考虑未来服务于这么一套自动化推理部署方案调优的工作，目前认为一套计算图抽象是相对可能的一个方案。