凌晨3点47分,那个作业还是没能活到天亮
凌晨3点47分,屏幕右下角弹出一行红字:Cannot allocate memory。
陈曦盯着终端愣了半分钟。他跑了六个小时的图计算作业,在加载邻接表的阶段就被系统杀掉了——这份数据是组里费了好大劲才拿到的真实社交关系图,200亿条边,导师安排第二天组会要看结果,开题报告也指着这份数据。此刻他大概想明白了问题出在哪:内存预算从第一行代码起就没打算放过这台机器。明白归明白,作业还得重交,规模还得降。
做过图计算课题的研究生,几乎人人都有一次这样的凌晨。
这个方向在国内有着扎实的研究底子。以华中科技大学计算机学院的图计算团队为例:2021年11月,该校自主研发的图计算系统DepGraph斩获Graph500和Green Graph500榜单双料第一,拿下中国首个Graph500全球第一;2022年,张宇副教授带领的团队在自主研制的「亿图」图计算平台上研发出图学习模型GIDN,在国际开放图基准OGB挑战赛链接属性预测赛道,把药物联合作用预测和作者合作关系预测两项精度做到世界第一。做系统方向的学生对这些名字不会陌生,课堂上讲的计算与存储耦合、边切分、消息传递,在这些系统里都是真刀真枪的工程。
DepGraph能登顶全球榜单,靠的是多台高性能计算节点拼成的集群,靠的并非某一台神奇的单机。而且规模越大,越吃底层存储:2024年9月MLCommons发布MLPerf Storage v1.0基准测试,用3D U-Net、CosmoFlow、ResNet-50三种负载检验「存储能不能让GPU保持90%以上的占用率」,参测的存储系统里排名榜首的华为OceanStor A800,单套系统支撑255块GPU的数据吞吐。这个榜单给做系统的人上了一课——AI负载里,存储喂不上数据,计算再强也只能空转。这条规律放到图计算里同样成立。课程项目阶段,很多学生以为「一台机器加上CUDA加速」就能包打天下。等到提交前夜算例崩掉,才第一次认真思考:我的问题到底该用单机扛,还是用集群扛?CPU和GPU,各自又该承担什么?这篇文章从一次真实的内存耗尽说起,把这几笔账算清楚。
追因:内存账从第一行代码就写好了
稀疏图的内存模型
以PageRank为例,稀疏图的主导存储开销是邻接表。200亿条边、64位顶点编号,仅CSR格式的一份边数组就要吃掉约64GB;顶点的活跃标记、得分数组、迭代双缓冲,各按50亿顶点、每顶点8字节计,又是约40GB×3;再叠上内存碎片、缓存、框架元数据和操作系统的占用,总需求轻松越过180GB。这个数已经超过了绝大多数单机的内存上限——问题跟算法写得好不好无关,账就是这么算的。
稀疏图和稠密矩阵的区别正在于此。稠密线性代数可以把矩阵分块、循环加载,单机慢慢来;稀疏图的拓扑结构是随机访问的,要么整图驻留内存,要么换外存图算法、付出数倍的时间代价。图算法大多是访问次数与边数成正比的迭代型算法,所以内存预算有个好用的估法:边数×12字节×1.5到2,再加上算法状态,与可用内存比一比,超了就换分布式方案,切莫赌机器仁慈。
CUDA能救多少
GPU加速图遍历成立的前提是:图能在显存里完整驻留。CUDA的SIMT模型让一个线程处理一条边、一个warp协作处理同一顶点的邻居列表,访存合并得好时,BFS、SSSP这类算法的吞吐提升非常明显。但天花板同样明显——显存通常比主机内存小,整图往显存一塞,可处理规模先打一轮折扣;预处理阶段(读文件、顶点重编号、排序、构建CSR)吃的是CPU和内存通道带宽,GPU插不上手,预处理慢,后面一切都慢。
分布式方案才是出路
Gemini、DepGraph这类分布式图计算系统把图按边切分到多台计算节点,每个节点只保存一部分,跨分区的更新通过MPI消息传递,配合RDMA网络或InfiniBand互联完成。理论可处理规模接近各节点内存总和,这也是为什么登顶Graph500的系统清一色是多机集群。跨节点通信量与计算量的比值决定扩展效率,切分切得好,接近线性扩展;切得不好,通信把计算时间吃光。MLPerf Storage留下的教训换个场景依然有效:分区边界消息走的是网络,网络带宽和延迟直接决定每轮迭代的速度。
把单机工作站的能力边界摆在一起看:
- 几十亿条边的全内存图,加上算法状态和开发余量,这是单机踏实能干活的区间
- 百亿边以上,内存账怎么算都不够,该把「内存放不下」换成「边跨节点切分」的设计
- 再往上到万亿边,那是国家级平台的领域,实验室不必硬追
做图计算的第一原则是算内存账,第二原则是别赌机器仁慈。接下来再看另一个正在吃掉课题组算力的需求——大模型。
大模型内网部署:第二个方向的账
为什么必须跑在内网
计算机专业的课题组对大模型的需求很具体:代码补全、脚本生成、文献速读、实验记录问答。有一条硬约束摆在前头——很多代码和数据关联着未公开课题,用公有云API意味着课题数据出内网,这条线在多数组里是红线,本地部署把权重和推理全程留在楼里。其次是成本:API按token计费,几十号人高频调用账单可观;本地部署一次性投入,边际成本接近电费,还能按课题方向适配。五到十人共享一台推理节点,人均成本远低于API账单。
模型选型:Llama-3.3-70B-Instruct
开源权重、许可支持商用和内网部署的模型里,Llama系列绕不开。Llama-3.3-70B-Instruct是Meta于2024年12月6日发布的文本指令模型,约700亿参数,上下文窗口128K,中英文能力和指令跟随都不错,代码和文献场景都能胜任,当课题组公共助手规格足够。
显存估算:先算再买
估算公式:所需显存约等于参数量×量化字节数×1.2,系数1.2留给KV cache和系统开销。套到Llama-3.3-70B-Instruct上:
| 精度 | 每参数字节 | 估算显存 | 说明 |
|---|---|---|---|
| FP16 | 2 | 约168GB | 质量最稳,一般只在评测时用 |
| Q8 | 1 | 约84GB | 质量损失极小,占显存偏大 |
| Q4 | 0.5 | 约42GB | 内网部署的默认档 |
实际权重文件约40GB,跑起来还要给KV cache留空间。务实建议:单卡48GB显存可以跑,双卡32GB分摊更从容,单卡24GB就得继续降量化。Q4成为默认档的原因很朴素:量化是用一点质量换接近一半的显存,对代码和问答类任务,这点损失体感不明显。
速度量级:CPU和GPU差在哪
纯CPU推理每秒只能解码几个token,读一段文献摘要要十几秒,只能当应急;单卡GPU带宽高出一个数量级,常见单卡跑Q4的70B模型能到每秒30到80token,交互式使用完全够用。多人并发建议上显存带宽更高的卡,一次服务五到十人。
微调与推理,两笔不一样的账
LoRA轻量化微调在推理显存基础上只增加约8到10GB,单卡48GB就能边推理边适配。全参数微调是另一量级:权重、梯度、优化器状态同时驻留,显存需求通常是推理的3到4倍,70B全参数约需420GB以上,单机单卡做不到,得走多卡集群,这也是配置档位能否上探的分水岭。课题组本地部署的现实路线:Q4推理加LoRA适配,全参数留给集群。
软件栈:先把地基打对
MPI环境
Open MPI、MPICH、Intel MPI任选其一,配合编译器和进程绑定配置。mpiexec启动作业容易,把rank绑到合适的核、让通信走对网卡,才决定缓存命中和通信效率。
OpenMP
单节点内线程并行归OpenMP管。NUMA架构下做线程亲和绑定,把线程钉在本节点内存上,跨节点访存会让内存带宽直接打折。
CUDA工具链
nvcc、cuBLAS、cuSPARSE、Thrust,配合Nsight做性能剖析。自己写内核加速图遍历是一种玩法,调用现成图处理框架是另一种,从课程项目走向科研,多半就差这一步。
作业调度
Slurm或PBS Pro。多人共用排队是常态,跑三天的大作业必须能checkpoint、能续算。
数据层
HDF5或NetCDF配MPI-IO做并行IO。图数据先转CSR二进制再交给自研代码或开源框架,读原始文本格式是最不划算的时间开销。
大模型服务化
vLLM或llama.cpp把模型包装成内网API服务,前者吞吐优化好、适合多人并发,后者轻量、适合单工位。端口只开内网网段——大模型内网部署的闭环,到这一步才算走完。
按负载规模对号的四档思路
聊到这儿,该回答实际问题了:机器怎么配。这一行干久了最大的感慨是,机器闲置和人员等待的成本没法比——一个学生因为算力不够把一周的实验周期拖成三周,或者把开题前夜赌在一台刚好够用的机器上,损失的就不仅是电费。根据前面算的三笔账(内存账、显存账、通信账),按负载规模分四档整理成参考方案,大家对号入座。
第一档:十亿边级图算法开发原型与本地小模型
开题验证思路、跑课程项目、写并行代码的起步阶段,单机把OpenMP和CUDA流程跑顺,再配个小参数模型做代码辅助,这个组合就够。
- 适用场景:研究生起步阶段,十亿边以内的图算法开发与原型验证
- 推荐机型:
- UltraLAB A350 15696-MCE
- CPU:Intel Core Ultra 9 285K 24核(8性能核全核5.5GHz/16能效核全核3.8GHz)(5.5GHz/3.8GHz为全核超频实测优化频率)
- GPU:RTX Pro 5000 48G(48GB GDDR7,384bit,1.34 TB/s)
- 内存:96GB DDR5
- 存储:4TB NVMe
- 显存:48GB
- 显存带宽:1.34 TB/s
- UltraLAB A350 153128-MCT
- CPU:Intel Ultra9 285K(24核,8P核5.6GHz)(5.6GHz为全核超频实测优化频率),水冷
- GPU:RTX5090D v2 24GB(24GB GDDR7,384bit,1.34 TB/s),水冷
- 内存:128GB DDR5
- 存储:4TB NVME + 8TB SATA
- 显存:24GB
- 显存带宽:1.34 TB/s
- UltraLAB A350 15696-MCE
第二档:单机压百亿边与70B量化推理的攻坚主力机
要把单机性能榨干,单机硬吃几十亿边的大图,同时在组里提供大模型服务节点,CPU和GPU两头都不能瘸。
- 适用场景:攻坚期主力机,几十亿边全内存图计算与70B级大模型Q4推理服务
- 推荐机型:
- UltraLAB AE450 141384-MDD
- CPU:AMD霄龙9755(128核4.1GHz,512MB缓存)(4.1GHz为全核超频实测优化频率)
- 显示卡:Quadro T400(4GB GDDR6,64bit,80.00 GB/s)
- 计算卡:RTX Pro 5000 48GB(48GB GDDR7,384bit,1.34 TB/s)
- 内存:384GB DDR5
- 存储:系统盘 2×4TB NVME SSD;数据盘 20TB SATA
- 显存:显示卡4GB,计算卡48GB
- 显存带宽:显示卡80.00 GB/s,计算卡1.34 TB/s
- UltraLAB EX660 229512-MDT
- CPU:2×Xeon铂金8592+(128核2.9GHz)(2.9GHz为全核超频实测优化频率),工业水冷
- GPU:RTX 4090 48G(48GB GDDR6X,384bit,1.01 TB/s)
- 内存:512GB DDR5
- 存储:8TB NVME Gen5
- 显存:48GB
- 显存带宽:1.01 TB/s
- UltraLAB AR350 148192-MCT
- CPU:AMD锐龙9950X3D(16核,4.85.7GHz)(4.85.7GHz为全核超频实测优化频率),水冷
- GPU:RTX 4090 48G(48GB GDDR6X,384bit,1.01 TB/s),水冷
- 内存:192GB DDR5
- 存储:4TB NVME + 8TB SATA
- 显存:48GB
- 显存带宽:1.01 TB/s
- UltraLAB AE450 141384-MDD
第三档:课题组共享计算平台与私有算力云
多人共用、排队成为常态,图存储要进并行文件系统,内网大模型服务从单节点升级为并发服务,内存、存储、网络三条线要同时扩。
- 适用场景:课题组共享平台,跨节点图数据切分与五到十人并发的内网模型服务
- 推荐机型:
- UltraLAB AlphaPro660 241768-MDA
- CPU:2×AMD霄龙9755(256核4.1GHz)(4.1GHz为全核超频实测优化频率)
- 显示卡:RTX 1000(8GB GDDR6,128bit,192.0 GB/s)
- 计算卡:A100 80G(80GB HBM2e,5120bit,2 TB/s),水冷
- 内存:768GB DDR5
- 存储:系统盘 8TB NVMe(14GB/s);数据盘 20TB SATA
- 显存:显示卡8GB,计算卡80GB
- 显存带宽:显示卡192.0 GB/s,计算卡2 TB/s
- UltraLAB GX660M 227512-MD4A
- CPU:2×Xeon金牌6530(64核2.7GHz)(2.7GHz为全核超频实测优化频率)
- GPU:4×A100 80GB(单卡80GB HBM2e,5120bit,2 TB/s),水冷
- 内存:512GB DDR5
- 存储:8TB NVMe
- 显存:320GB(4×80GB)
- 显存带宽:4×2 TB/s
- UltraLAB AlphaPro660 241768-MDA
第四档:多模型并发服务与全参数微调
70B全参数微调、多模型高并发API、把大模型服务做成课题组的「水电煤」,多卡并行是刚需。
- 适用场景:私有算力云模型服务节点,多模型高并发与70B级全参数微调
- 推荐机型:
- UltraLAB GX660M 241768-PD4H
- CPU:2×AMD霄龙9755(256核4.1GHz)(4.1GHz为全核超频实测优化频率)
- GPU:4×H200 141GB(单卡141GB,显存带宽4 TB/s)
- 内存:768GB DDR5
- 存储:8TB NVMe
- 显存:564GB(4×141GB)
- 显存带宽:4×4 TB/s
- UltraLAB GA660M 230512-MD4H
- CPU:2×Xeon铂金8558(96核3.0GHz)(3.0GHz为全核超频实测优化频率)
- GPU:4×H100 80GB(单卡80GB,显存带宽2 TB/s),水冷
- 内存:512GB DDR5
- 存储:8TB NVMe
- 显存:320GB(4×80GB)
- 显存带宽:4×2 TB/s
- UltraLAB GX660M 241768-PD4H
如果我重来一次,我会怎么选
别信「加内存就能救」
单机硬吃百亿边以上的图,第一个小时就能看到内存曲线贴顶。与其赌它能不能跑完,不如一开始就按分布式切分写代码。
别指望CUDA绕过内存墙
GPU加速图遍历成立的前提是图能在显存里完整驻留。显存比内存小,预处理还靠CPU,CUDA解决不了「装不下」,只解决「装得下但跑不快」。
买卡前先算显存账
70B模型Q4要40GB出头,32GB单卡得双卡或降量化,24GB单卡想都别想。公式摆在那,买完才发现不够,是最贵的一种后悔。
checkpoint不值钱,丢一次就懂
训练任务写checkpoint,图计算定期快照分区状态。机器死机、断电、作业被误杀,都可能发生。自攒机在这件事上的隐性风险偏高:整机出厂前的长时间满负载烧机、出问题单点报修,对要交论文的人来说很值。
一台顶配不如拆两台
组里五个人抢一台顶配,排队时间和单机性能不成比例。一台攻坚主力加一台轻量服务节点,往往比单台堆满更划算。
常见问题FAQ
CPU还是GPU?
分阶段看。图预处理吃CPU主频和内存通道带宽,遍历计算吃GPU的CUDA核和显存带宽,本地大模型推理吃显存容量加显存带宽,微调在此基础上还要算力。一个课题三个阶段轮流当瓶颈,所以顶配单机的心法在于均衡,押一头,另一头就会在某个阶段卡死。
跑Llama-3.3-70B至少要多少显存?
Q4量化42GB起步。单卡48GB是底线,双卡32GB更从容,单卡24GB只能降量化或换更小的模型。想要长上下文或多并发,在这个数上继续加。
怎么判断自己的课题单机够不够?
打开图数据文件看边数,按每条边12字节估出图的体积,乘1.5到2加上算法状态,结果比内存小不少就单机,顶格或者超出就走分布式。这个过程十分钟,能省一个通宵。
MPI和CUDA是什么关系?
两个层次的并行工具。MPI管多台机器之间的进程通信,CUDA管单张显卡内部的线程并行。分布式图计算系统通常是MPI加CUDA的组合,CPU做控制面,GPU做计算面。
大模型内网部署和用API差在哪?
API省事,但数据出域、按量计费、模型行为不可控;内网部署数据不出楼、边际成本接近电费、可以LoRA定制风格,代价是需要一台显存够的推理节点和半个运维的人。
自攒机真的不香吗?
账面便宜,但NUMA拓扑、内存通道插满、7×24小时散热冗余、兼容性,每一项都是暗坑。整机厂的长时间满负载烧机和单点报修,自己攒机得拿毕业去赌。
结语
故事的最后,那份200亿边的图重新申请了机时,切了16个分区跑完,开题报告赶上了。但那个凌晨教会的东西比报告值钱:算力储备是买保险,保额决定deadline面前能不能睡着觉。当初要是多留三成内存余量、先算完显存账再买卡,那个凌晨本该在睡觉,谁愿意在复盘。这一课记下了。下一次,让机器替你记着。