AI 能陪你亲亲热热，

多亏了“存储硬汉”输出狠活儿！

文 | 史中

（一）AI 凭啥免费给你香香？

你有没有想过，这些国民级的 AI 应用凭啥能免费给你用？

现在咱人均都有四五个“在线卑微”的 AI 秘书。

她们化着淡妆站一排，从“霸王龙怎么搓澡”到“丧尸围城靠一根牙签如何突围”，无论多奇葩的问题，只要你问得出口，她们就必须捏着鼻子答。

而且，豆秘书（豆包）的答案不满意，你扭头就去找 D 秘书（DeepSeek），是一点儿情面都不看，比皇帝选妃还凶残，属实膨胀。

要知道，这些秘书们可都是免费的啊！一个个用爱发电、自带干粮住你家、 24 小时侍寝还被你挑三拣四。

可见 AI 这行有多卷。

当然，免费背后肯定是 AI 厂商在补贴嘛。但这里有个前提：成本不能离谱，太高谁也补不起呀！

AI 厂商的师傅们每天研究一件事儿——怎么高性价比地“开学校”！

教学质量要好：隔三差五把自家模型送学校回炉，争取学完之后色艺双绝，艳压群芳；

学费还得便宜：毕竟就算学出来是学贯中西博古通今的花魁，打工的收入还是辣么微薄。。。

从 2023 年开始，各家 AI 都狂暴地请来更好的名师（算法），研发新的教材（数据），盖更多的教室（GPU），使用更先进的教学管理制度（训练框架），争取让学生们学得又好又快又便宜。

忙活了一两年，赛博世界里一座座崭新的学校挺立，”教学性价比”嗷嗷提升。

够了吗？够了。。。又好像不够。。。

老师傅们不约而同地缓缓移动怀疑的目光。

他们发现，角落里不起眼的“图书馆”。。。仿佛似乎竟然。。。成了支撑 AI “性价比”的一根重要支柱！！！

此时从天空俯瞰，历史恰行至拐点，惊雷炸响，国产存储技术的命运齿轮开始缓缓转动。

（二）建图书馆的“天命人”

我们开动时光机，去往 2023 年的北京西二旗。

那真是平静的日子，袁清波还有空研究“保温杯里应该泡哪种枸杞”。。。不光是他，整个曙光存储的技术团队都在“泡枸杞”。

澄清一下，不是老师傅集体躺平摸鱼，正相反，他们有点儿“独孤求败”的意思。

这帮师傅就是“图书馆”的施工队。

所谓图书馆，就是——企业级存储系统。

那时候，曙光存储系统主要服务于大型的国企央企。这些企业的数据固然很重要，但要求和图书馆类似：存下来，别丢，想要的时候能找出来。

至于一个数据是 0.1 秒找到，还是 0.0001 秒找到，同时能找 10 万条数据还是 100 万条数据，还真没啥极致的讲究。。。

再看袁清波，是中科院计算所的博士后，主攻系统架构，他的很多同事都是中科院师兄弟，放眼全中国这是妥妥的明星阵容。虽说要正心诚意地开发每一代产品，但这个团队多少有点儿“性能过剩”的意思。

袁清波

灵明石猴栖身花果山，可不是为了量贩吃桃，而是有朝一日成为“天命人”。

这不，2024 年春节刚过，分布式存储产品 ParaStor 的产品经理乔雅楠就找到了袁清波，上来一顿虎狼之词：

“下一代分布式存储产品，能不能把带宽做到 190G 每秒，把 IOPS 做到 500 万？”

先按下暂停键，科普一下。

这句话的意思是说：

不夸张地说，曙光是中国存储产品的扛把子，性能本来就是“姚明级”的。但下一代产品的要求却要比现在翻两番，妥妥是让姚明穿着增高鞋踩高跷蹦起来扣篮。。。

这么强悍的性能，是准备存啥？？

咱们继续按下播放键。

袁清波听到这话，并不惊诧，而是 45 度仰天长叹，一副“该来的总算来了”的神情。。。

虽是久居山林的扫地僧，但技术师傅早有耳闻，曙光存储正在和很多头部 AI 厂商勾兑，要帮他们的“AI 学校”建“图书馆”。

这里，话头就和最开始接上了：训练个 AI，到底跟图书馆有啥关系嘞？

不妨跟着中哥钻进一座 AI 学校，咱们实地观摩下目前人类最牛的“万亿参数大语言模型”是肿么训练的！

我们先来到教学楼，这里热火朝天，有 1 万间教室，每个教室里都能坐下 1 亿个葫芦娃，他们在一本一本地飞速看书。

每个葫芦娃其实就是 AI 大脑的一个神经元。他们看的书，就是训练语料。

每看一本书，他们都会刷新一次自己对世界的认识，然后改一下手里的参数。

当所有的教材都看完之后，每个葫芦娃手里的最终参数也固定了下来，一万亿个参数汇合在一起，就组成了一个水灵灵的 AI 大秘书！

喂养这么一个怪兽级的模型，大概需要消耗 10PB 的语料。这是多少呢？

换成纸质书有 220 亿本，一本一本竖着放，也能绕地球赤道一圈。比香飘飘还狠。

一万亿个葫芦娃同时看书，场面如风卷残云：

可能这一秒要从图书馆调拨 500 万册语文书；下一秒钟就调拨 500 万册英语书。。。

这时候，压力给到了图书馆，如果供不上这么大的量，那学校只能停课干等，不就浪费了教学资源吗？！

所以，要想支持世界最强 AI 的训练，500 万 IOPS（也就是每秒 500 万次读写）的能力还真就是必须的↓↓↓

即便如此，还远远不够。

AI 学校并不真实，而是在赛博世界里构建的，每间教室其实就是一张显卡。这一万张显卡同时进行巨量又细密的计算，难免会出现 Bug。

这就好像：一万间教室突然有一个停电了，葫芦娃同学一慌，把之前看的书给忘了。。。

这一忘不要紧。因为最终的 AI 秘书由每一个葫芦娃手里的参数所共同支撑，有一个教室的学生学岔劈了，所有教室的学生都得重头再来。

没错，是倒回到新学期第一天，从第一本书开始。。。

就像下图↓↓↓

不用怀疑，现在人类的技术就是这么水。

为了让 AI 好歹能训练完，老师傅摸索出了一个并不优雅的办法：

每隔一段时间，就让所有葫芦娃暂停下，把手里的参数统一抄在本本上，作为一个“检查点”放在图书馆备着。

万一后面哪个教室掉链子，就全体滚回到最近的“检查点”开始，总比从头来要好！

就像酱↓↓↓

这里，压力又给到了图书馆！

检查点包括万亿参数，是一个巨巨巨巨大的文件，最大能到 5TB，相当于 3 套《四库全书》。

图书馆存这么多书，可得要点儿时间呢。。。关键是，如果完成这个存档需要 1 小时，那么下一个存档最早也要 1 小时之后才能开始。

这中间万一学校那边出错了，就相当于一个小时都白学了。一退就退一个钟头，这不又浪费了教学资源吗？！

也许有人觉得，一个小时还好吧。

给你算算，万卡集群的成本是几亿美元，核算折旧，加上电费、人力，每回滚一秒就是上百美元的损失，回滚两分钟就是近万美元的损失，回滚一个小时几十万美元就没了。。。

几十万美元用来买泡面，得吃几辈子呀？！

如果图书馆（存储系统）每秒能存储 190GB，那情况就完全不同了——存完一个 5TB 的检查点只需要 26.32 秒。

这意味着，每分钟都可以存一次档！存两次都行！

这就相当于开挂了呀↓↓↓

OK，科普结束，跳回现实。

乔雅楠粗略算了一下，如果达到每秒 190GB 吞吐能力，500 万 IOPS，对于 AI 厂商来说，每投入 1 快钱在这样的存储上，就能得到 10 快钱的收益。这种“一本十利”的买卖，谁能拒绝呢？

这笔账算完，技术团队的命数就定了——搞得出来要搞，搞不出来也得搞！

此时，镜头缓缓转向对面的袁清波。背景音乐的鼓点儿已经由远及近，保温杯里震起涟漪。。。

生活不止眼前的枸杞，曙光存储团队的师傅们已不再是花果山散仙，而是拯救人工智能于水火的“天命人”。

Mission Accepted！

（三）从头盖一座图书馆

话说，曙光存储老师傅之所以敢接这么凶残的任务，还有个朴素的原因：当时某顶尖美国存储厂商已经放出风来，他们的下一代产品可以达到 190G 带宽。

呵，都是一个鼻子两个眼，美国人能做出来，中国人做不出来？？

原地鼓捣了俩礼拜，技术团队已经非常有信心了：

基于现有的服务器硬件，每秒要吞下 190G，只有一个办法，让电流传输超过光速~~

所以，做不出来。

今天的浅黑故事就到这里，再见。

等等。。。刚才好像有个限定条件：“基于现有的服务器硬件”。

“如果咱自己从头设计一套‘存储专用服务器’，有没有戏呢？”

袁清波被自己的想法吓了一跳。

他们可是软件工程师啊！过去对图书馆做升级，从来都是在既有的房间里改“软装”，现在竟然要把“图书馆本身”推倒重盖，这也太膨胀了。

但老师傅冷静一想，几乎可以肯定：美国同行如果没有推翻相对论，也必须得重新设计服务器。。。至于他们咋设计的，咱也不知道，咱也没法问。。。

然而，既然做了中国存储行业的扛把子，摸石头过河不就是曙光的“天命”吗？！

估计你已经好奇图书馆里是啥样子了。

咱们这就钻进去，和老师傅们一起设计设计。

先介绍主要人物：

书：数据

书架：硬盘

图书管理员：CPU

管理员的桌子：内存

借书还书的窗口：网卡

咱们一步一步来。先讲讲过去“旧图书馆”的样子：

简单说，通用服务器的设计目标不是“图书管理”，而是“算数”。

所以，这里的 CPU 不应叫图书管理员，更应该叫算数员。

只要有题目从窗口进来，算数员就算，算好后返回给窗口。

大多中间步骤数据用完就扔了。只有重要的结果才会归档，所以书架放在旁边即可。

（这里的金色地毯代表硬件通路，数据只能从这里走。）

但是，如果用这个布局直接做图书馆，就有一点儿别扭了。

因为图书馆的管理员没有那么花哨的计算，主要职能就是“搬运”——把从窗口送进来的书籍放到书架上，以及把书架上的书籍送到窗口。

于是咱可以把布局微调，把图书管理员的桌子做大一些，让书架和桌子之间的路宽一些。

这样想要什么书，管理员放在桌子上“滴”一下，就直接送到窗口了。

除了基础布局，额外的通路设计也很有讲究。

袁清波给我举了个例子：

图书馆里其实有两组管理员（两颗 CPU），每组管理员都有距离自己较近的窗口（网卡）、桌子（内存）和书架（硬盘）。

假设：一个找书的需求从窗口 A 进来，可它要找的那本书离 B 组 4 号管理员更近。

那么，B 组 4 号管理员就得先从架子上把书拿下来，放在自己面前的桌子上，A 组再过来一个管理员，绕到 B 桌，把东西拿回来 A 桌，再从 A 窗口送出去。

这会导致一个问题：这本书会有相当一段时间滞留在桌上。

要是只有一本也就罢了。在每秒几百万次的请求中，如果很多书滞留在桌面，就会让桌面空间吃紧。

它们像管道里的淤泥一样，影响整个图书馆的周转速度。

估计你也想到了办法：

如果想办法在这里加几条通道，让 A 桌管理员能更方便地拿到 B 做的东西，不就能大大减少桌面面积（内存）被占用的时间了吗？

但相信你已经有了感觉：硬件布局和通路设计，这两件事儿对整个存储系统的*性能上限*影响巨大。

OK，我们继续回到技术师傅身边。

他们仰头，前面出现三座大山：

第一座，把这个服务器给设计出来；

第二座：说服领导同意用“专用存储服务器”开发下一代存储产品；

第三座：说服工程技术中心把这服务器给造出来。

先搞“第一座山”。

设计硬件，好像就是在纸上画画图，但实际远非这么轻松愉快。一颗 CPU 或者一条内存在某种情况下的具体性能，是很难估算准确的。

要想确切了解，只有把硬件拿来实地测试。

袁清波他们开始搭建环境，一点点儿调整图书馆里“桌椅板凳”的位置和远近。通过观察性能变化，罗列出所有瓶颈，再从所有瓶颈里寻找最“卡脖子”的部分依次解决。

这种微调，很像玩儿华容道，在方寸里里左挪一下右挪一下，每挪一下都牵连到最终结局。

越做实验，袁清波他们就对硬件的脾气越清楚；越清楚，信心就越足。

团队在肝设计方案

老师傅私下憋了很久才敢和领导提出“把图书馆推倒重盖”。

听到这个“非分请求”，领导提出疑问：“新搞一套服务器肯定要成本，团队努努力，还用标准服务器克服一下有没有可能？”

“绝不可能！”袁清波拍案而起。

噗地一声，他从怀里掏出电脑，把最近几个月做的各种实验数据一一列举，跟打辩论一样，摆出了十来条“旧硬件存在物理极限”的证据。

领导还没来得及反应，他又话锋一转：“再说，咱也不是没这个实力！”敲下键盘，肝了几个月搞出来的新服务器设计图出现在屏幕上。

釜底抽薪+贴脸杀，领导好像没有不答应的道理。。。

拿到了金牌令箭，接下来就要挖“第三座山”——找工程技术部商量生产问题。

这是“外交大使”乔雅楠的任务。

工程技术部的同事听明来意，其实有点儿错愕，设计硬件，不是我们的活儿吗？你们咋给干了？

本来愉快地答应就行，但他们发现一些小问题：

存储团队设计的硬件，有很多附加的逻辑和通路，这会提高硬件的制造成本呀！

这些额外的连线，真的有必要吗？

乔雅楠赶紧把测试软件拿来，逐一现场演示这些附加的线路都是干啥用的。工程技术部的师傅们点了点头，随即又摇了摇头：“应该还有性价比更高的设计方法吧？”

他们说得有道理，但现实情况是门外的 AI 客户已经嗷嗷待哺，来不及了呀！！存储团队干脆一拍胸脯：“先这么生产，多出来的成本，我们包了！”

就这样，第三座大山终于被推为平地。

新的服务器拿去量产时，已经到了 2024 年秋天。190G/s 带宽终于稳了，老师傅回头一看，这边还剩一位爷——500 万 IOPS！

乔雅楠

（四）在 0 和 1 的世界里雕花

我猜还有浅友没搞清带宽和 IOPS 的区别。

这里再用图书馆打个比方：

IOPS，指的是图书馆每秒借出去的书有“多少本”；

带宽，是指图书馆每秒钟借出去书的总厚度有“多少页”。

有啥区别呢？

假设图书馆每秒借出的书摞在一起是 1900 万页。

如果大多数书都很厚， 每本书有 1900 页，那 1900 万页总共也就 1 万本。把这些书借出去，管理员们每秒只需要“滴” 1 万次。这对于光速工作的 CPU 来说压力不大。

但同样总共 1900 万页，如果每本书只有 5 页，那每秒钟管理员就得“滴” 400 多万次，工作量瞬间多400倍，比在产线上打螺丝还累了！

肿么办？

一个所有人都能想到的办法就是：加管理员（CPU）呗。。。

但袁清波的“加”字还没说出口，就被乔雅楠的 PUA 给打断了：“我对你们这群大神有信心，现有资源肯定能撑住 500 万！”

袁清波点点头：“嗯，我也对自己有信心！”

咱们继续钻进图书馆里，看老师傅要怎么搞 IOPS。

话说，在图书馆（服务器）里拢共有 256 个管理员（CPU 核心）。这些管理员如果被充分调度，干到 500 万 IOPS 是绰绰有余的。

但问题恰恰是：图书馆的日常工作中，调度并不充分！“等待”和“绕路”是常态。

举两个