大道求索，无问西东 - 从 DeepSeek 看 MLSys 的 2025
这个春节想必做科研的同学过得应该不太开心，本来只想过个好好的年，结果又是 DeepSeek R1，又是最强多模态 Janus，年还没过完，又来了 Qwen 2.5 Pro 和 OpenAI Deep Research。
所以在文章开始之前，不管 DeepSeek 有多好，我都要表示严厉批评。这帮人给搞科研的同学制造焦虑，坏人道心，不让人好好过年，罪大恶极！虽然我在国外本身也不过中国春节，但是也要帮国内的同学发声。
尽管这件事情本身不值得焦虑，相比 DeepSeek 带来的焦虑，他确实开始了一个 ML System 的新时代，对我在 MLSys 这个生态位的科研工作者带来了更多机会。
本文可能会探讨下面四个大家可能感兴趣的问题：
- DeepSeek 的出现，给私有模型部署带来了什么机会和问题？
- DeepSeek 对 AI 模型供应商提供了什么机会和挑战？
- DeepSeek 的训练代价到底有多高，个人用户有必要训练，以及真的能训练吗？
- DeepSeek 的模型比起一年前的大模型，产品开发有什么机遇和挑战？
DeepSeek 给「我」的冲击
简单来说，DeepSeek 和 GPT o1 一样，在不同的时间点，各自走通了 RL 的路线。奠定了未来一到两年，除非基础模型出现重大突破创新的前提下，我们都会在 RL(Reinforcement Learning)[1] + CoT(Chain of Thoughts)[2] + MoE(Mixture of Experts)[3] 的路线上发展。
与其说这一波技术创新说是大变革，更像是中美两边的 AI 企业在明争暗斗中达成了共识。算法层面上，DeepSeek 破解了迷雾重重的 OpenAI Strawberry Project。从现在开始，所有人将正式开始一场公平的竞争。
首先我先从一个自私的视角出发：「我」怎么看 DeepSeek 这一波的爆红。对「我」有什么影响。
「我」是谁？
当然我不是想试着回答这个复杂度哲学问题。而是想声明我的视角。
一年前我刚博士入学的时候，参与的项目是我们组 Yao Fu 的 ServerlessLLM，在大规模部署的时候降低了 LLM Inference 的延迟。现在我同时和我们组的 Congjie 一起在 Cerebras 上进一步降低在特殊硬件上 LLM Inference 的延迟。
所以，从 MLSys 在读博士生态位上，我有幸在我们组的学习交流中，得到了宏观和微观的两个视角：
- 宏观整体上，我关注整个模型的部署：大规模部署的大语言模型，应该如何处理负载均衡、快速模型切换、模型推理加速等问题
- 微观细节上，我认真思考了模型的细节：大模型在 GPU，以至于新的 AI Chip 上，如何将 Transformer 的性能打到极致
这两个学术视角更多的是 Model Inference 而不是 Model Training。而我的爱好，结合了自己的特长，补足了这个空白。我这一年训了很强的语言模型，也训练了一些简单的多模态模型。还做了很多 AI 相关应用，例如我比较骄傲的 多模态 RAG 项目 autoreader，我半年前其实就用类似于 ReFT 的算法，在图片的基础上标注了 「Fact」 和 「Reasoning」，从而训练了质量极高的多模态 MoE + CoT 模型，双盲测试比 OpenAI 4o 好 23%。
那么我另外两个视角也随之产生：
- 训练参数量较小的多模态模型的视角
- AI Model 和全栈产品中，如何高效运作，稳定对接
所以，这四个视角让我对开篇的四个问题有一定的发言权。
- DeepSeek 的出现，给私有模型部署带来了什么机会和问题？
- DeepSeek 对 AI 模型供应商提供了什么机会和挑战？
- DeepSeek 的训练代价到底有多高，个人用户有必要训练，以及真的能训练吗？
- DeepSeek 的模型比起一年前的大模型，产品开发有什么机遇和挑战？
而我的答案，其实就是本文的标题：大道求索，无问「西东」。
且听我慢慢分析。
学术思考：大模型推理，我的机会在哪
前两个问题和我的学术研究相关度更高，在开始之前，我会引用一些我在 [2412.07067] MoE-CAP: Cost-Accuracy-Performance Benchmarking for Mixture-of-Experts Systems 工作中进行的一些分析。
私有模型部署
刚过年的这一周，是一波巨大的热潮，DeepSeek 的 Alignment 做得其实并不够好，很多违反道德和法律的问题，DeepSeek 的模型也能给出答案。我对此不做过多评价，毕竟技术永远都是一把双刃剑。但不论怎么说，确实让大家私有部署大模型的热情前所未有的高涨。即便是不违反法律的角度，可能确实也有很多用户会有赛博洁癖：毕竟你也不希望一个上一秒扮演你去世亲人的机器，下一秒就在扮演别人的女朋友吧。从这个角度想，这个事情未免太过于变态了。
不论我们能不能达成「私有部署的需求在未来几年会上升」的共识。我们都不妨观察这一波大家的部署方案，开始分析 DeepSeek 和之前的部署有什么区别。我认为其最大的区别就在于 MoE 这一个关键技术上。而我的暴论是：私有设备上，优化带宽是 MoE 部署的真正瓶颈。
在评估模型部署和硬件的适配性的时候，我们最常用的指标是 MBU(Memory Bandwidth Utilization) 和 MFU（Sparse Model FLOPS Utilization）。而这两个指标，在 MOE 中，其实是虚假的指标。
这里我们使用一张图来解释说明这个问题。传统的 MBU 和 MFU 指标在计算时会假设每个输入 token 都会经过所有的专家(experts),导致对资源使用的严重高估。比如在图中的场景(a)中，实际上每个 token 只使用了一个专家，但传统指标会认为用了所有专家,造成了 3 倍的过度估计。同样在场景 (b) 和 (c) 不同激活方式的场景中也存在 1.5 倍到 3 倍的过度估计问题。
而新提出的 SMBU/SMFU 采用了更精确的计算方式。我们只计算实际被激活的参数大小，而不是简单地使用整个模型的大小。这种方式可以准确反映路由机制实际选择的专家数量，也能很好地处理共享专家的情况。更重要的是，这种计算方式既适用于稀疏模型，也适用于密集模型(将密集模型视为特殊情况处理)。因此具有更好的通用性和准确性。这对于硬件资源的规划和系统优化都具有重要的实践意义。
而对个人用户来说：大部分时候 batch size 其实是 1，一次只来一个 token。
可能这个时候，对 DeepSeek 结构有一定认识的同学已经反应过来了，上面的图我们举例的是 3 个 Expert 的例子。而 DeepSeek R1 虽然是一个 671 B 的超大模型，但是实际上，他是一个 256 + 1（share） 中激活 8 + 1（share）的 MoE 模型。这里的 「+ 1」是 （c） 中提到的 Share Expert。这个稀疏程度带来的问题是，在个人用户 batch size = 1 的时候，我们的瓶颈根本不在计算上。那么，我们真的有必要买性能更好，但是带宽没有提升的计算设备吗？
我想，这一个灵魂拷问，很大程度上在一周前狠狠狙击了 NVIDIA 的股价。所以，我们更详细地进行了分析：
对着这张图，很大程度上可以指导一个部署误区：「要买 10 多张顶级显卡，才能部署满血版 671 B 模型」。其实某种意义上，很多人买了卡……是当显存扩容条用的，只是因为 NVIDIA 没有超大显存的设备，才不得不从。换句话说，如果个人用 DeepSeek，买的卡越多，亏的越多。
这个图上第一组点是蓝色的点，代表设备可以用上的最高带宽。是硬件厂商有能力达到的峰值带宽。对 GPU 来说，就是 GPU L1 Cache 到 HBM 的带宽，这部分带宽是限制了 MoE 的瓶颈。我们要频繁将 expert 的权重载入 L1 Cache 中完成计算，之后再换出。然实际上，因为模型的稀疏性，erpert 中，参数权重矩阵的维度并不像 Llama 为代表的稠密矩阵那么高。导致了对单一 expert 计算来说，我们的设备早就算力过盛了。
既然硬件厂商吝啬显存大小，那么我们看看如果我们自己做了妥协，我们用 PCIe 的速度去载入数据，分批次载入模型权重，会得到什么结果呢？这就是橙色的这一组点。用了橙色的这组点之后，其实硬件的内存就再也不是瓶颈了，现在大型服务器上加更多的内存条已经不是技术问题，内存大小是 TB 级别的服务器有很多。我们的这种妥协加剧了一个 MoE 模型推理中的带宽受限问题。
那么接下来，我们看最后一组点，绿色的模型点。对于每一个 MoE 模型，我们分析了相同参数，如果我们设计了稠密模型，实际需要的带宽需求。
这里我们构建了一个简单的随机过程来模拟计算带宽，假设每次需要用到的 expert 非常随机，那么可以计算出每一个模型实际上需要的带宽是多少，在我们能租用的起的设备上测试之后，实验结果和理论分析也互相应证，测试结果见下图。（在这里感谢 RunPod 的廉价设备，帮你们免费推广，希望回头能送俺点代金券！）
所以我们对比可以看到，这一波带宽的降低，某种意义上对红色区域的所有硬件有利。这部分硬件才能不收内存带宽限制，「无痛推理」DeepSeek 的模型。前提是显存够用的话。
但这里有一族例外，Apple Silicon 家族的各位，使用了廉价 LPDDR5 设计 unified memory 实现超大显存的芯片。他们其实是可以用特殊方式实现几乎无痛 offloading 的，某种意义上，如果 Apple Silicon 乐意放出更多的大显存芯片，我觉得他们很容易成为 MoE 时代的大赢家。尽管他们的 Bandwidth 够不到模型的需求，但是差距其实并不算多。
Apple Silicon 真正的问题其实在他们下一代芯片设计思路可能陷入的误区上。这里，我们更换一下 X 轴，换成芯片的功耗，可以看到 Apple Silicone 走入了一个误区。
在带宽上接近原地踏步，而功耗上越来越高。诚然，Arm 架构给他们带来了一骑绝尘的功耗表现，但是他们现在的发展方向在图上在东西方向摇摆，而不是在南北方向打通。
上面我们提出来了一系列问题，其中最大的问题是带宽。在硬件厂商不吝啬显存，用精准刀法逼迫我们采购更多设备的时候，我们组又一位英雄，早在一年前已经预料到了这个问题。在 [2401.14361] MoE-Infinity: Offloading-Efficient MoE Model Serving[4] 提出了高性能的 offloading 方案，某种意义上将所有的橙色点向上提升了一大截。表现到 token/s 这种暴力课件的肉眼指标上，会有 2-20 倍的性能提升。
而我这边会从另一个视角上看这个问题，在第一张图上，其实我藏了两个点没有画出来。并不是我不像画，而是因为这两个点真的画不下。[5] 因为真的有芯片在片上带宽上，已经领先了 NVIDIA 好几个数量级。途中看到的 21 PB/s 其实有一点小问题，实际可用的带宽并没有真的这么高，但是确实已经远远够用了。不然，他们也拿不到一秒数千 token 的惊人成绩。[6]
重新回顾上面的几张图片，对我来说，这些图的东西走向，我确实不在乎，也没办法在乎。毕竟让硬件厂商加显存这种事情，不是我一个人动动嘴就能解决的。而降低模型参数量这种事情，更多的是算法选手应该研究的问题，他们可以把模型向左边移动，让更多的蓝色设备不需要 offloading，就能承担起一个大模型。
但是做更好的 expert offloading 策略，想办法让橙色的这一组点不断接近我们的 peak bandwidth，是作为一个系统人的视角能看到的。这也是我开篇提到的，大道求索，无问西东。
模型供应商大规模部署
刚刚讨论完了私人设备的部署的种种可能，那么对大规模部署，又有什么问题呢？
我们顺着刚刚的分析模型接着思考，本质上，如果有一个厂商需要给很多人提供 inference 业务，唯一的区别就是 batch size 的增加。
batch size 增加了，计算的 FLOPS 是随之线性增长的，毕竟每个 token 需要得到的计算量一定是固定的。但是不同的是，我们 bandwidth 是有上限的，不同的 token 可能会激活相同的 experts。同时，如果 batch size 足够大，尽管大家各自需要激活各自的 expert，但是 expert 一共也就那么多，总量是固定的。
所以两方面的问题并存，一方面是，我们会重新回到计算为瓶颈的推理问题上，在极端的情况下，MoE 模型的优势全无，会退化成类似 dense model 的模式。这里我重新分析了上面的图
这张图上，所有的 MoE 模型迅速向 Dense Model 接近。所以对云厂商来说，大家几乎没的选，该上 NVIDIA 还是得上 NVIDIA。 这张图我也补充了两簇点，我们对不同的 CPU 也做了分析。这个时候分析可能略微有点迷惑啊，为什么要在这里提到 CPU 呢？
因为这个问题其实涉及采购性价比。
上面的图片我们可以换一个视角来试着理解：不同稀疏度的模型点，和原点连接能看到不一样的斜率。硬件的价格其实是显存大小、算力、带宽共同决定的。我们可以做一个抽象粗糙的分析：
嗯，姑且叫 CAP Model 好了，我们为了服务一种类型的模型，其实在 Cost, Accuracy 和 Performance 之间权衡。
在进行硬件采购决策时,我们需要综合考虑以下三个核心指标:硬件价格、推理性能和模型能力。通常情况下,模型能力与参数量密切相关,参数量越大的模型,理论上能捕捉更复杂的模式,从而具备更强大的能力。 然而,在实际部署中,这三个指标并非孤立存在,而是相互制约和影响。 例如,为了追求更强的模型能力,可能需要更大的显存和更强的算力, 这无疑会推高硬件成本。 同时,推理性能也直接影响着用户体验和系统的吞吐量,对实时性要求高的应用, 性能至关重要。
传统的基准测试往往侧重于评估硬件的两个维度，例如各种 Leaderboard 和 Benchmark 相关的论文。然而,在MoE模型等新型模型架构出现后，部署过程变得更加复杂。这实际上是一个高维度优化问题。在这种情况下，我们需要考虑模型的稀疏度在 batch size 提升的时候，会产生复杂的影响波动。这就让之前的各种 Benchmark 失效。此外，我们也是第一次将三个维度拉出来共同分析。
实际部署的时候，我们面临两种常见的优化场景:
- 给定硬件,选择最佳稀疏度模型: 在硬件资源固定的情况下,我们希望找到一个在给定硬件上能够提供最佳推理性能和模型能力的模型, 尤其要关注模型的稀疏度。 不同的稀疏度会影响显存占用和计算效率。
- 给定模型,选择最佳硬件: 如果模型已经确定,我们需要选择合适的硬件来满足其显存需求,并确保在预算范围内实现最佳推理性能。 这需要评估不同硬件在特定模型下的表现。
在进行硬件选择时，我们可以通过图示来辅助分析。绘制了一张坐标图，横轴代表硬件显存大小参数，纵轴代表模性能指标。这种图表中,我们可以观察硬件和模型之间的关系。
模型与硬件的适配: 如果硬件框与模型的稀疏度曲线首先在右侧相交,这意味着硬件显存不足,无法容纳整个模型。这时,我们需要采取以下措施之一:
- 更换更大显存的硬件: 使用显存容量更大的GPU是最直接的解决方案。
- 多卡并行: 采用多个相同硬件进行堆叠,扩展硬件的“宽度”,将模型分割到不同的硬件上进行推理。
- 降低模型稀疏度: 如果允许,可以考虑调整模型结构,降低模型的参数量,从而减少显存需求。
性能瓶颈分析: 如果硬件框与模型的推理性能曲线首先在顶部相交,说明性能达到了瓶颈,无法进一步提升。 这时,需要识别性能瓶颈所在,并针对性地优化。因为我们有两种性能相关的指标，一个是带宽，另一个是算力。所以在不同的 batch size，我们有不同的分析优先级。
- 小Batch场景: 对于batch size较小的场景，带宽(memory bandwidth)往往是主要的性能瓶颈。这种情况下，可以考虑选择带宽更高的硬件。
- 大Batch场景: 对于batch size较大的场景,硬件算力(FLOPS)通常成为限制因素。 这时,可以考虑选择具有更强算力的硬件，例如采用更高端的GPU。
说了这么多，总结上面的讨论。在私有化部署和低延迟的 MoE 的部署中，有一些被我们忽略的硬件可能会有非常高的性价：支持 AVX 512（或者 AVX10），AMX 的 CPU 和 超大 unified memory 的 Apple Silicon。同时，之前盲目堆积 GPU 部署大模型的暴力模式会很快被淘汰。
写这篇文章的时候，清华团队就放出了单卡部署量化 R1 的工作，4090单卡跑671B DeepSeek-R1，清华团队开源项目再破大模型推理门槛 - 知乎 进一步证明了我们工作的意义：帮大家看到硬件真正的需求。
机会
回归前两个问题，首先是第一个问题：DeepSeek 的出现，给私有模型部署带来了什么机会和问题？
私有化部署真正应该采购的是大内存/显存/统一内存设备，推理的瓶颈在带宽上。尽管最近几年 MoE offloading 的相关工作已经频繁出现在各种系统和 AI 顶会上了，但是现在 MoE 模型的推理性能还不能达到大家的需求。我们还有很多机会
同时对 MoE 的 KV Cache 管理也是巨大的挑战，如果 GPU 上已经没有充裕的空间管理 KV Cache，大模型的记忆应该何去何从。这些都是我们可以思考的问题。
那么另一个问题：DeepSeek 对 AI 模型供应商提供了什么机会和挑战？
在去年的文章中，我讨论过 AI 模型部署的供应上的困境。当时得到的结论是: 在 2024，各种云服务厂商内卷价格后，直接部署模型已经不能获得盈利了。 这个观点现在依旧成立，具备大量硬件计算资源的厂形成了算力和价格的垄断，大预言模型部署的范式依旧存在(Batch size 提升之后，稀疏模型和稠密模型的计算范式还是会收敛)。
但是新的挑战在于我们可能要进一步细分在线推理和离线推理业务，就和我们曾经关注 PD 分离一样。在线推理的场景中，我们更关注 P99 和 延迟，而离线业务中，我们会更关注 throughput。这两种业务并存的时候，batch size 设置成更低的数值可以满足更低延迟的高质量在线需求，用上更多的低成本硬件可以提升可用硬件的数量；在离线业务中，我们到底有多少可用资源这个问题也被明显低估，传统意义上我们闲置的 CPU 到底还能做些什么。
开发思考：大模型训练和应用上，2025 我们能做什么
说完了学术上的东西，我想简单谈一谈我的日常：用模型，测模型，玩模型。
大模型训练
这个部分其实我本来有很多想说的话，但是实际上，最近模型训练的成本也在不断被刷新。在半年多前，我自己瞎搞了类似 OpenAI 的 RL 方案。在特定的数据集上，小样本 fine tune 达到了超越 GPT-4o 的效果。我当时非常自满，在特定数据集上，我雇佣一批人进行对图片上读到的 facts 和 reasoning 进行了标注。结合我自己从 Pixtral 的模型基础上，模仿 Mistral 的 MoE 架构拓展的模型。两者结合，效果惊人。
可惜我的自满和膨胀只持续了三个月不到。
圣诞节，OpenAI 公布了他们的 Fine Tune，效果良好。紧接着是字节的 ReFT，和 DeepSeek R1 的放出，这几波把我自满的资本瞬间扫空。我唯一的优势，可能就是个人确实跑过全流程，知道每个环节如何操作罢了。
类似的复现工作也很多，所以这里我引用了 minimind 项目来评估训练上的开销：
项目中有一个部分值得我们进行深入分析和讨论：
| Model Name | params | pretrain | sft_mini_512 | sft_512 | sft_1024 | sft_2048 | RLHF |
|---|---|---|---|---|---|---|---|
| MiniMind2-Small | 26M | ≈1.1h ≈1.43￥ |
≈1h ≈1.3￥ |
≈6h ≈7.8￥ |
≈4.58h ≈5.95￥ |
≈7.5h ≈9.75￥ |
≈1h ≈1.3￥ |
| MiniMind2 | 104M | ≈3.9h ≈5.07￥ |
≈3.3h ≈4.29￥ |
≈20h ≈26￥ |
≈15h ≈19.5￥ |
≈25h ≈32.5￥ |
≈3h ≈3.9￥ |
关于这部分具体的价格开销，我会安排在另一篇文章里进行详细的 profile。这里我只简单陈述我看到的机会和挑战，看起来，现在训练模型更简单了，RL 用更少的数据样本完成了对模型的调整和完善，但是也带来了问题。
pretrain、SFT、RLHF 这些细节配置比例的调整确实还是值得我们慢慢摸索和研究的。
大模型应用
如果思维链的长度被加长，复杂 AI workflow 会被进一步延长执行时间。如何更好调度将会是一个重要的问题。
传统的大模型中，我们常用 TTFT（time to first token）描述延迟。然而最近的大模型应用趋势可以明显看到，大家会在模型的前面再拼接一段<think>标签引导的思考，从而让真正的 TTFT 更长。
这种时候，在等待的时间，我们有没有更好的协作模式和调度机制呢？这也是我眼下看到的机会和挑战。
不过我也不好说，我最近手头上有一对复杂 GPU Workflow 在研究部署和调度，非常头大。DeepResearch，LLM+OCR 等等让我确定 LLM 开始脱离了原来单纯的语言模型，变成越来越基础的组件。
我缺失的机会在哪
思前想后，本文说了一堆乱七八糟的问题。DeepSeek 很大程度上解决了 AI 应用从模型到架构的很多问题。解决了很多我想解决的问题，让我更加明确了我的两个严重短板
- 我缺乏大规模部署 AI 应用的机会和场景
- 缺乏参与大模型训练的经验。我自己只有一些小规模模型的复现经验，但是模型尺度增加，通信、容灾都会成为问题
回归本文的观点，2025 MoE 对我的影响是让我找到了这一年的规划：
- 学术上，我不需要等待硬件厂商发布更大显存的硬件，先去想办法解决 offloading，将这部分在推理和训练上都更好的用起来，让 MoE 的门槛降低。大道求索，无问西东。
- 开发上，摆脱过去一年简单应用的开发模式，在用模型的角度上，用得更个性化，训模型的角度读后，发掘更多的特定领域能力。专注深度，把通用型这种宽度能力交给大厂来思考。纵深南北，无问西东。
- 纵深看，我学术和开发都有幸和我热爱的技术结合，所以，勇闯南北，无问西东。
题外话
需要高清大图，欢迎随时和我进行联系！