AI 工程化
2021 年初，贾扬清在阿里云开始推广 AI 工程化这个概念，我非常认同。我在 21 年中做技术规划的时候，提出“AI 到生产力的转化，需要更高的工程化能力”，并且将 AI 工程化的实施总结为几大方向：
- 语义索引场景化
- 算力调度混合化
- 模型研发标准化
- 优化技术普惠化
- 模型超大规模化
- 架构系统智能化
我的 AI 工程化团队在这些方向上也取得了许多成果。
The AI Model
但 2022 年底 LLM 大流行以后，情况发生了一些变化。原因主要是 LLM 让 AI models 变成了 The AI model，虽然这个 model 很大，也多多少少有一些变种，但从工程实践的角度来看，它并不“复杂”。
很多时候，工程架构解决的是复杂性问题。
比如，TensorFlow、PyTorch、PaddlePaddle 这些训练框架简化了搭建和训练神经网络的复杂度，在一段时间内，各种结构的网络层出不穷，大部分都是依托这些框架来实现的。
而对于 LLM 来说，模型结构相对固定，虽然也使用了框架的一些外围能力，但是模型结构核心部分已经逐渐变成全手写以达成最佳性能，典型的实现包括 FlashAttention、TRT-LLM 等。
而且 LLM 的接口调用是自然语言，因而也变得极其简单，所有的 LLM 模型几乎可以使用同一套 API。
当时看起来 LLM 不需要太多的架构基建工作。
Prefix Caching 和 Kimi
我的这个认知在思考 prefix-caching 作用的时候，有了一些改变。
在《应该把 Prefix Caching 当作一种效果优化技术》这篇博客中，我提到 Prefix Cache Aware Scheduling 是一件非常值得做的事情。而且从 Kimi 发表的论文来看，他们已经在实践了，但其它的技术报告提到这些工程架构工作的不多。
DeepSeek V3
前几天 DeepSeek AI 发布了 DeepSeek V3 版本，我一边在吐槽这 670B 的模型参数太大，下载太慢，一边在阅读它的技术报告。结果发现他们在模型的部署上，玩得更高端，给了我一些新的震撼。
首先，prefilling 和 decoding 分开部署。prefilling 4 机 32 卡，decoding 40 机 320 卡。这样一来，我之前《LLM 推理优化 Continuous Batching 及其实现》这篇博客中提到的 Continuous Batching 就不再需要了。两阶段分开后，prefill 的计算过程（长度）是确定的，其算力利用是充分的，不再需要中间停下来插入新的请求。其实 prefilling 能够分开部署，跟 DeepSeek 以前的研究也是分不开的，DeepSeek V2 引入的 MLA 对 KV Cache 做了大幅度的低秩压缩，可以显著降低 KV Cache 从 prefilling 节点传递到 decoding 节点的带宽和延迟。
其次，MoE 专家分开部署。因为 MoE 专家的激活是 Token 级别的，也就是说每个 Token 会决定走哪个专家进行计算，分开部署就可能会带来负载均衡问题：有些专家太忙，有些专家太闲。DeepSeek V3 为了解决这个问题，还做了复杂的负载均衡策略。例如：快速识别较忙的专家，部署冗余的专家副本以承担压力；重新调整专家在不同节点的布局，尽量利用跨 GPU 带宽而减少跨节点带宽（因为 IB 比 NVLink 要慢）；单卡冗余部署多专家，但通过全局的路由计算来优化专家的动态激活数量。
DeepSeek V3 还实现了计算和通信重叠。为了掩盖分布式计算过程中进行集合通信时的开销，将计算任务分为微批。一个微批进行集合通信时，进行下一个微批的计算。
此外，DeepSeek V3 在推理时还将 TP（Tensor）、DP（Data）、SP（Sequence）、EP（Expert）不同维度的并行化融合到了一起。单拿出来一种并行化方法也许现在的框架还是支持的，但这些方法组合在一起，我怀疑目前也没有什么推理加速框架能直接处理。
从技术报告中揭露的这些细节可以看出，为了发挥出模型的极致性能，DeepSeek 在 AI 大模型的分布式部署上花费了很大的心思。这也让 DeepSeek V3 成为目前公开资料可以看到的最复杂、最精巧的大模型 infra 设计。
这些 idea 以前也许不是没有人想到，但是 infra 的演进是有很高研发和试错成本的。当 DeepSeek 将这些路走通以后，也许未来的很多大模型公司，大模型框架，都会往沿着这个方向继续演进。