关于Deepseek-v3/R1的随记

xiaoqianWX

最近deepseek挺火的，但是很多内容看了半天跟没看一样甚至不如不看，有很多奇奇怪怪的理解不知道是哪来的，所以想根据自己的一些经验稍微写一点点（无基础向）内容

1. 什么是LLM/LLM的本质是什么

        LLM就是通过神经网络，输入一串字，转化为token（可以理解为一个字一个词），在这一串token预测下一个token是什么的概率。挑一个概率大的token塞到这一串的尾部，反复这个循环

        今天，主流的LLM均采用transformer架构（也就是利用了attention机制

        LLM中大致可以分为普通的dense架构，和MoE（Mixture of Experts）架构，本质上就是在预测一个token的概率时，MoE模型指向对应的n个expert，而非激活全部权重，MoE和dense的模型在预测token的本质上没有任何区别

        对于LLM的入门，建议去b站搜索一下3blue1brown的deep learning系列视频，肯定比我讲的明白

2. Deepseek相比原先的LLM有什么改进

        首先，Deepseek在1年半以来发布了多个LLM，期间逐步改进了各种方面的很多东西，这些改进最终的目的是在提高模型性能的同时优化训练和推理的成本：

        1. MLA和推理架构：
        LLM推理的本质是预测下一个token，也就是需要对前面的整串内容计算attention，而需要储存起来这些计算出来的结果（也就是KV-cache）到显存中，内容长度越长，他就越大
        在推理的过程中，需要反复计算attention，计算attention时需要把模型的权重和KV-cache拉进GPU的核心中，然后再把更新后的KV-cache丢回到显存里，在今天的GPU架构中，这一过程主要受到GPU的显存带宽限制，而非算力限制。

        那么，很显然如果一台巨大的服务器一次只能支持1个用户使用是不明智的，如果我们一次对多条内容同时处理呢（也就是增加batch size），这样会不会有性能上的优化？
        答案是有的，这样在牺牲单个stream（用户得到的输出速度）的情况下，大大提升了这个服务器的总吞吐量（比如原来1个用户得到每秒100token，吞吐量就是1*100=100token/sec，而现在20个用户得到了每秒50token，那吞吐量就是20*50=1000token/sec）
        但是，你不能无限执行这个操作，因为每一串内容都有自己的KV-cache，而你的显存大小是有限的

        Deepseek开发的MLA（Multi-head Latent Attention，多头潜注意力机制）将KV-cache的大小进行压缩的同时不明显损失信息，从而可以实现在一台机器上塞下更多条内容，在Deepseek-v2上显著优化了总throughput

        在上图中我们可以看到Deepseek-v2在理想环境下（通过对比Deepseek67B的数据和社区的Llama 3.1 70b对比得出）在8*H800的推理吞吐量达到了约56000token/sec，但是他的代价是什么呢？单个用户收到的速度很低

        这也成为了Deepseek-v2主要受到诟病的点之一，虽然他的API成本仅有每百万token仅有0.14input/0.28output（和20B大小的dense模型价格接近），但是在单个用户的速度仅有约21token/sec的情况下，很多受益于高速推理的应用场景无法正常使用（毕竟没人想写一段代码等5分钟）

上图是我24年7月在Deepseek Discord里反馈的内容，然而问题就出在，如果想要显著提升单个用户的速度，那就要显著提高推理成本（因为吞吐量明显降低），在他们当时有的推理方案下，没有其他的办法

        在Deepseek-v3中，为了解决这一问题，他们将社区常用的在一台机器上部署整个模型的方案改掉，既然训练可以分布在很多台机器上，只要有高速互联让信息可以传过来就可以，那么推理为什么不行呢？Deepseek将输入token的处理（生成KV-cache）和预测下一token（decoding）的过程分离开，用n*32*H800处理输入token，减小个别长输入对整个部署的速度的影响，将每个expert部署到单独的一张H800上，大幅优化单个用户速度的同时不损失总吞吐量，再加一些冗余expert部署给高概率的expert使用，总共320*H800用于预测token

        看到这里，可能会好奇，为什么要使用MoE而非dense？其实在前面的几部分中已经解答了这个问题，MoE的本质是基于当前的GPU架构下显存带宽有限，利用总参数量换取更小的激活参数（也就是更小的带宽占用）下同等的性能，同时降低训练的开销。而MoE模型，比如Deepseek-v3的推理部署有更高的灵活性。总体来讲，在高度优化的推理架构下，Deepseek-v3/R1的推理开销平均下来约等于70-100B的dense模型，但Deepseek-v3的性能显著优于目前已知的70-100B模型。

        但是：社区目前的解决方案还不能达到Deepseek自己的方案的效率，或者说，相差甚远。因为长久以来开源的LLM，如Llama和阿里的Qwen，主要都是dense模型。因此社区的推理方案对dense模型的优化度很高，没有怎么优化过MoE模型。以Deepseek-v2为例，在理想化环境下，官方可以达到56000token/sec的吞吐，而社区目前最快的SGLang v0.4也仅有约12000token/sec，是4倍的差距。各个小推理服务商尝试复刻Deepseek自己的Deepseek-v3推理架构难度更大，因为一个部署就需要至少32+320*H100，而为了稳定性也至少需要2个部署，也就是需要服务商至少分配700多张H100给一个模型。

       
        2. fp8训练和H800优化
        长久以来LLM均采用了bf16进行训练，虽然自H100（和RTX 40系）推出以来支持了fp8运算，但训练的稳定性和是否相比bf16有性能下降没有大规模实验证明过。Deepseek-v3首次使用了fp8进行大规模预训练，证明了fp8训练的可行性和稳定性不劣于bf16。
        在H100上，fp8的运算速度是bf16的2倍，而fp8因为大小减半，显存占用和带宽占用都减半，因此可以说在同样训练算力下仅使用了约一半的H800小时数，这就是deepseek降低训练成本的关键。

        同时，Deepseek因为用的是出口限制版的H800而非原版H100，有明显的互联性能下降，所以deepseek自己优化了卡间通讯，降低通讯带来的瓶颈，使得H800的性能与H100在训练上没有明显差距。


3. Deepseek-R1
        24年9月，OpenAI推出了o1-preview和o1-mini，随后又在12月推出o1，这也是首次在LLM上验证了test-time compute(应该翻译成推理时计算）可以利用类似“思考”的过程，输出很多token逐步解决问题，实现进一步提高LLM在编程、数学、物理等领域的性能。test-time compute本身在机器学习上并非陌生的概念，但是o1的表现在特定领域十分亮眼，一些原本被认为LLM不可能解决的问题成功被o1解决了。

        Deepseek-R1以Deepseek-v3为基础，在此之上先使用了多个（人工或模型合成的）CoT(Chain of Thoughts，思维链条）进行强化学习，然后再次之上再进行SFT等正常post-training手段，实现了连贯、用户可读的CoT的同时展示了与o1接近的性能。

        R1虽然模型开源，且有技术报告，但也并不是说开放到你对着他能直接复刻一个出来，事实上，依然有很多关键的点没有公开。比如最重要的CoT数据是如何合成的，训练性能具体是怎么优化的（代码），以及使用的hyperparameters。而其他不少细节是社区已知或多少猜出来只是没有确认的。就好比说要煮一锅饺子，他告诉你需要有饺子，把饺子放进开水里然后熟了捞出来就好。而人人都知道煮饺子顾名思义是放开水里煮，而他并没有告诉你关键的饺子怎么包（训练数据）和煮多久（训练代码和hyperparameters）才能煮出好吃的饺子。


暂时想不到还能写点什么了，后面再补吧，如果有疑问或者好奇什么请回复，我试着看我能不能解答

天一色md5

我一个朋友讲的deepseek，可能对多数会员来说更加通俗一些：https://www.bilibili.com/video/B ... ge.video_card.click