大模型价格战下的推理优化

无名小足

每个人都说自己超越了GPT4,但是每个人公布的榜单数据都无法相互校正. 《Benchmarking Benchmark Leakage in Large Language Models》[1]这篇论文解释了一些原因。

大模型的价格战始于DeepSeek-V2的MLA, 然后很快的基本上每家都跟进了, 一个靠技术上的降本在有些人眼里就成了靠补贴, 然后有的人开始真补贴, 又有贴不起的开始骂街的, 当然也有开始默默抄作业了, 还有抄作业都抄不会的。

对于国内的大模型推理市场, 高峰到来应该在9月前后, 伴随着新的iPhone发布,以及后续的骁龙8 Gen4的Android手机发布, 还有英伟达和联发科搞的芯片, 还有几个月时间能做些什么呢?

本质上这个问题是算力/算法/架构这三块的妥协, 因此先分别介绍一下这三块的可行性方案,最后在系统性的考虑一下。

1. 算法

从算法上来看, 一方面是从模型结构来看主要分几块FFN的优化, Attention的优化以及Transformer框架的替代优化

FFN优化这一块主要是MoE相关的工作, 例如Mixtral, DeepSeek Shared-Expert, 当然还有SnowFlake的Dense-MoE. Attention优化主要是大家都在用的GQA以及最近比较热的DeepSeek MLA,  目测有几家都准备抄作业的, 当然还有一些已经抄了Shared Expert的. Transformer框架替代主要是一些Mamba的工作,通过在不同层内插入Mamba替代Transformer. 当然还有一个工作是Google的MoD来降低Token的attention计算量。

具体参考《继续谈谈MLA以及DeepSeek-MoE和SnowFlake Dense-MoE》

关于Dense-MoE的收益

另一方面是从数据层面来看,例如刚才用Kimi/豆包/百川测试了一下, 通常会根据输入内容做一个改写,然后在线实时检索一些文档, 并构成一个更完整的Prompt

当然还有一些app要么没有联网实时搜索要么就是ASR准确度有问题, 就不多说了。

我们注意到对于热门的提问,通过搜索改写查询文档并且将其向量化以后,甚至是计算中的KV Cache都可以缓存到一些内存数据库, 当下一个用户问相关问题的时候,然后利用SplitWise的方式, 直接可以把这些KV Cache进行Prefill了. 另外还可以把这些Prompt Summary以后做Cache等. 这也是通常数据层面中采用RAG/Prompt Summary的方式, 当然这里衍生出一个多模态数据库的场景,也是前几天飞刀老师提到的, 后面会花一些时间来谈谈范畴论视角下的现代数据库设计。

2. 算力

对于算力的优化, 主要是一些量化的方法. 但是量化这个事情是药三分毒. 有时候想想大模型好不容易训练涨两三个点就被量化撸掉了,总有一点膈应吧? 除了量化意外还有一些方法,例如LoRA这类的参数裁剪,或者稀疏Attention,以及一些知识蒸馏的方法。

潜在的很有价值的算力节省方式是Speculative Decoding, 通过一些较小规模的模型生成多个token然后让大一点的模型进行验证, 同时还可以并行的对生成的token进行一些安全对齐的工作,例如国内的一些安全性的策略。

3. 架构

架构层面来看, 主要是KV Cache的管理, 例如SplitWise, 利用高算力的卡跑Prefill, 低算力大带宽的卡做Decoding

那么在算力不够的时候, 是否我们还可以更极致的去做一些异构的事情,用H800一类的做Prefill然后用Intel SPR/EMR这些带AMX的CPU来做Decoding呢?

然后就是很常见的FlashAttention这样的算子优化.Inflight-Batching的一些对多个请求的Token并行编排, 然后PP/TP/SP的并行策略等。

另外一些PageAttention的内存管理, vLLM+Ray这样的一些框架配合RDMA将CPU实例中的内存也池化出来,并且通过CPU Offload部分算力需求, 例如TTS中需要ffmpeg需要从GPU中更快的将Token结果返回并实时生成语音. 另一方面也可以在Token生成的时候用一些xgboost的决策树来快速对模型的安全性进行评估,过滤有毒Token, 甚至是做一些更简单的浅层Attention的Offload。

4. 系统

从系统层面来看, 更应该从端到端的能力上来评估. 端侧苹果M4差不多有38T的算力, Intel也有45T, 后续联发科和英伟达一起折腾一个50T左右的手机芯片估计也不是什么难事. 那么这些端侧算力能做什么呢?

第一个就是Voice的音纹处理,ASR中的Mel-Spectrum并附带几个浅层Attention计算都可以放在端侧做, 一些简单的词表Embedding也可以放端侧, 对于图形视频的一些CNN乃至最后返回的TTS模型也可以在端侧构建.

另一种潜在的方式是端侧进行Speculative Decoding, 通过部署一个3B左右的模型进行, 然后产生多个Token后交由云端的一个更大的模型Verify, 当然这也需要RTC网络直接从端侧DMA到显存中, Google这样的DirectTCPX就有了用武之地了, 另外就是模型结构上来看,Medusa的工作也是值得参考的

另一个潜在的优化是结合MoD的方式,然后通过一些CPU实例构建多机的PP并行,然后通过MoD做Early Exit跳转. 这是一个非常重要的工作必须现在去做, 否则等突然上量了以后,推理卡的供应会更加紧张,而CPU实例是最好的替代,并且后续可以通过公有云经营去平抑短时间的流动性紧缺.

在大模型架构层面去从系统的角度考虑推理的算力优化, 无论是MLA的工作还是Dense-MoE或者是Google MoD, Medusa, SplitWise这样的工作,再来反推寻找出一个合适的大模型架构, 只可惜大多数的草台班子大概只知道有什么抄什么, 或者利用泄漏的数据打个榜,天天自嗨超越GPT-N, 摊手

转自：zartbot