最近跟风看了下DeepSeek开源的几个项目,
一个感想就是这样的团队可能其实还是挺难得的.
基本上属于需要有钱,玩得起硬件,但又不能是一个大公司,使得接触这些环境有条条框框和门槛.
再就是在有追求的同时,具有一定的实用主义精神,有ROI概念.
像基础的3fs.
一上来就是面向RDMA设计的.
这个成本本身就有一定,小点或者资金不是那么充裕的,一时半会也玩不起.
而在大公司里,大概有属于一类比较特殊/不通用的硬件资源,大多也只是某些特殊目的的项目有预算支持.
何况即使有,也大多是属于某些特定部门的专有资源.
倒不是说不够共享精神,可能实际上更多的是来自于行政上的条条框框数据隔离.
再就是复杂的成本归依问题使得不大可能是一个通常意义的基建环境.
除了硬件使用门槛之外,实现上也一方面实用主义,一方面也有一点要求的.
因为面向的是特殊场景,所以有些地方就没考虑通用场景.
都是针对于需求需要达到什么样的效果,就采用什么样的实现.
比较明显的就是DeepEP和DeepGEMM两个项目.
DeepEP给nvshmem 的驱动打了个patch,增加了receive队列以及相应的通知机制.
这个基本上就是DualPipe和DeepEP本身能够在带宽调度上面手动双工压榨的软硬件基础了.
而说到DualPipe这个项目,HN上有个评论算是蛮meme的.
A CEO who codes.当时第一印象就是当年Facebook现Meta炸子鸡时代,提到扎克伯格跟工程师一起写代码的都市创说.
虽然这一版的评论在当时被爆说比较负面,称根本在帮倒忙.
不过DualPipe的倒是比较亲和.
有人举了个例子说是跟中国厂家打交道,很多时候确实是老板亲自下场解决调试各种技术问题的.
基本上来说DeepSeek在HN上面的评价是少有的对于国产东西又相当一致性的高评价的话题.
从最初R1的时候,就是几乎少有的一面倒的贴服.
侧面可能也是说明对于OpenAI算是苦秦久矣.
而DeepSeep某种程度上也确实像是那个指出皇帝新装的小孩.
最近那个拆解成本摊薄说利润率500%+的可能某种形式上来说也是算是对OpenAI发布4.5对一种呛声.
比较时间点上刚好在OpenAI发布不久,并且强调成本高昂的时候,跳出来展示了自己成本.
当然,这个成本固然爆出了属于既得利益层面不太愿意公开,一般人也不太能算得出来的信息差的一方面.
但是,也必须承认这个只是inference的成本.
而且计算的机器成本和其他投入成本也是过于简化和纯粹的.
但确实对于价格的合理性植入了一个问号就是了.
至于训练方面,这个属于一个目前还算一个外行比较难评价的层面.
一方面是一般人也不太有条件去复现.
另一方面可能语料的组织形式本身也是一个具有advance的商业元素.
毕竟模型结构和fine tune的脚本一定程度上算是开放的了training的相当部分内容.
但是怎么喂的可能还是有一定的技巧在的.
加上像Meta的语料来源合规性问题,本身也是有非技术原因的复杂度在的.
不过虽然不能直接给出一些信息,DeepSeek也多少还是在关于自己FireFly2的集群架构论文多少有撕开一些东西.
一个是对比Nvdia DGX A-100的成本.
卡数相同集群规模,性能大致是后者的83%,但是总体硬件成本可以减少40%.
里面很大一部分开始缩减在于减少了IB的实用.
DGX的架构里但节点8卡一共用了9个IB,而FireFly2只用了一个IB加4个nvlink.
4个nvlink主要也是为了拓扑层级逐级归并引入的单节点双卡之间的互联.
诚然,从Nvdia的角度来说,因为是面向某种形态的通用场景,所以用上了一种比较奢侈的IB配置.
但是从另外一个角度来说,也可以说是Nvida是为了利润搞了某种形式的结构化捆绑销售,强卖了一部分过剩但是性能上并不容易扩展的硬件.
看DeepSeek也提到了DGX这几张IB其实还是环形结构的.
虽然提供了一个端对端比较高的带宽,但是某种形式上利用率是不太高的.
当然,Deepseek也提到了自身这种拓扑结构的一些问题.
但更多是CPU结构导致的一些局限性.
比如有PIC口不太够,导致8张卡里有两张需要共享一个口,成为了一个瓶颈点.
还有CPU本身点一些实现缺陷也导致PCI带宽跑不满成为瓶颈.
感觉这块如果说估计成本考虑如投入DPU和swich设计,替代IB的话还是有很大的成本提升空间的.
不过查了下数据中心交换机这块,国产厂商跟国外的技术差距还是比较大的.
看券商研报有列出一个datasheet,国内盛科通信能达到2.4T的交换容量,但是思科博通一线是在25.6T,差了一个数量级.
所以这块可能还是得等有同能能力的厂商之后才行.
看DeepSeek提到自己的下一代架构可能也会上8块独立NIC口,只不过不是IB而是通用RoCE方案,
不过没提到CPU选型,只提到了AMD的下一代CPU也有当前类似的瓶颈.
所以不知道会不是跟华为搞个专门通道DPU之类的去一体化解决GPU CPU和NIC的整合性问题.
不过感觉大概率不会是Deepseek亲自下场去搞.
就像发现DeepGEMM里发现undocumented的指令side effect也不是去搞个通用的compiler或者其他什么方案,而是简单粗暴的对原生binary做bit改写.
这种能用就暴力用的美学可能才是DeepSeek的风格.
没有评论:
发表评论