简介《智算技术与算力规划设计及部署实施方案v2.0》面向智算中心建设方、架构师、运维及项目管理人员聚焦算力基础设施从需求分析、规划设计到部署落地的完整链路可用于方案编制、立项论证、技术选型与实施参考。文档围绕智算技术体系与算力资源规划展开兼顾计算、网络、存储及配套设施的协同设计并给出部署实施与运维保障的思路框架帮助读者建立从业务需求到工程落地的系统认知。包内为1个PDF文件整体约11.28MB内容集中、便于检索与归档适合作为项目前期调研和内部培训的参考材料。目前已有131人学习说明其在智算中心规划与部署场景中具备一定的实用价值。对于需要快速梳理智算中心建设路径、完善实施方案文本或对照检查规划要点的读者这份文档可作为较完整的框架性资料使用。1. 从一份 v2.0 方案到一台能跑起来的机器智算环境最容易翻车的地方去年冬天跟一个智算中心的节点交付方案文档封面上印着 v2.0纸面上卡数、带宽、存储池、并发任务数都算得清清楚楚真到机房上架那天才发现框架要求的驱动版本比机器预装的高一个大版本两台机器的网卡固件对不上机柜实际功率比设计值高出两成。这类活儿从来不是装一个软件而是把供电、系统、GPU 驱动、容器运行时、调度器、并行存储六层串成一条链任何一环没对齐上层就表现成「训练任务莫名其妙卡住」。装不好最典型的下场是卡只认出一半、多机通信超时、任务排队三天最后抛一个看不出所以然的错。这份笔记写给要交付算力节点、做算力规划、或者接手了别人半成品环境的人从盘点、安装、配置一路走到验收每步都留可复现的命令。2. 环境盘点与版本选型智算中心的算力账要先在表格里算平方案文档里的算力规划通常按峰值写落地时真正决定成败的却是那些不起眼的对照表哪张卡插在哪个槽位、固件版本是多少、哪根线走参数面。我养成的习惯是设备还没进机房先把三张表填满——硬件核对表、软件版本矩阵、网络与存储分配表。这三张表填不平后面每装一步都要返工最惨的是装到第三层才发现版本选错前面全白干。2.1 机房与硬件前置条件功率、风道、槽位一个都不能含糊八卡整机满载功率普遍在 6 到 10 千瓦之间加 CPU、内存、网卡和风扇余量一个塞满的算力柜做到 12 千瓦以上不稀奇。风冷机柜的单柜散热上限一般就压在 8 到 12 千瓦方案里如果按「每柜四台八卡机」写现场大概率要改成三台或者上冷板式液冷。这个账必须在采购前算装完再改就是拆机柜的活儿。上架顺序也有讲究重设备靠下、交换机和存储靠上参数面交换机的光模块发热大别和 GPU 机器挤在同一段风道里。每台机器上架后立刻记录一张核对表这张表是后面所有排错的基础。核对项记录内容漏掉的后果整机功率铭牌功率与满载实测值机柜 PDU 过载跳闸GPU 槽位卡序列号与 PCIe 槽位对应关系换卡后拓扑错乱通信走错路径网卡信息型号、固件版本、PCIe 代数多机带宽只跑到一半带外管理BMC 地址、账号、固件版本远程装系统时只能干等本地盘NVMe 数量与挂载规划数据盘和系统盘混用写满根分区带外管理口建议在装系统之前就配好后面挂虚拟光驱、远程重启全靠它。常见做法是用 ipmitool 把网络固定下来再把账号密码改成统一的运维口令# 带外口固定地址装在单独的管理 VLAN 里 ipmitool lan set 1 ipsrc static ipmitool lan set 1 ipaddr 10.10.30.21 ipmitool lan set 1 netmask 255.255.255.0 ipmitool lan set 1 defgw ipaddr 10.10.30.1 # 改掉默认口令别用出厂那套 ipmitool user set password 2 Ops2024#node21 ipmitool lan print 1 # 回读确认防止写错网段ipsrc static表示不依赖 DHCP机房里 DHCP 出问题的时候带外还能进lan print这一步别省我见过写成10.10.3.21少一位、整柜机器全失联的情况只能推着显示器车一台台接 KVM。2.2 软件栈版本对照先定框架再倒推驱动版本选型最容易犯的错是从驱动开始往上装装到框架那层发现不匹配。正确顺序是反的先确定业务要跑的框架版本再由框架的 wheel 包倒推 CUDA 运行时由运行时倒推驱动最低版本最后由驱动倒推内核版本。这条链上只有最上面一层是业务决定的下面全是被动选择。我一般会锁成下面这样具体数字按当期框架的官方对应表微调但锁定原则不变层组件我一般锁的版本锁定理由框架PyTorch2.3.x与 CUDA 12.1/12.4 的 wheel 有明确对应运行时CUDA Toolkit12.412.x 系列兼容面宽驱动向下兼容驱动GPU 驱动550 系列支持 12.4且修了上一版显存统计偏差容器containerd1.7.x1.6 对 cgroup v2 的支持不完整编排Kubernetes1.28.x设备插件与调度插件适配成熟通信库NCCL随框架自带单独升级最容易和驱动打架这张表的关键不是数字是「一次只动一个变量」。升级驱动就只升驱动跑完验收再动下一层同时升驱动和 CUDA出了问题根本定位不到是哪一层的锅。项目里我见过有人图省事把整栈一起拉到最新结果多机 all-reduce 带宽掉了三成查了两天才发现是新驱动的某个默认开关变了。2.3 三张网与存储分层规划阶段就要定死智算节点的网络不是一张网是三张。参数面跑梯度同步要求低延迟高带宽用 IB 或者 RoCE200G 起步存储面跑训练数据读取和并行文件系统对齐100G 到 200G 以太管理面跑带外、调度、监控万兆就够。三张网走不同 VLAN、不同物理口最忌讳为了省交换机把参数面和业务面混在一起跑。网络用途典型带宽配置要点参数面梯度同步、集合通信200G/400G不承载业务流量不做 bonding存储面训练数据与 checkpoint 读写100G/200G与文件系统客户端带宽对齐管理面带外、调度、监控采集10G单独 VLAN做双口 bond存储按热度分三层热数据放全闪并行文件系统供训练直接读温数据放对象存储做数据集归档冷数据落大容量机械盘。规划阶段要算的是「训练集大小 × 并发任务数」不是单看总容量。一个常见的误判是存储池做得很足但客户端带宽只配了 25G八卡机一起读数据时 GPU 利用率掉到三成卡在那儿等 IO。3. 从裸机到 GPU 可识别操作系统、驱动与容器运行时安装这一层是纯手工活命令写错一个参数后面全得重来。我的做法是把所有操作写成脚本先在测试节点上跑通再批量推到生产节点中间不留「这台机器我手动改了点东西」的空间。3.1 操作系统安装与内核参数固化系统盘做 RAID1数据盘单独规划根分区给到 200G 以上——容器镜像和日志很快就能吃掉这个量。装完系统第一件事不是装驱动是固化内核参数这些参数决定了后面容器能不能稳定跑起来。# 关 swap容器内存统计和 kubelet 都依赖这一项 swapoff -a sed -ri /\sswap\s/s/^#?/#/ /etc/fstab # 统一时钟多机集合通信对时间偏差很敏感 systemctl enable --now chronyd # 内核参数大模型加载会创建大量内存映射默认值顶不住 cat /etc/sysctl.d/99-ai-node.conf EOF vm.max_map_count 262144 # 默认 65530加载大模型容易触发 OOM vm.swappiness 1 # 尽量不用 swap net.core.rmem_max 134217728 # 高速网卡收包缓冲 net.core.wmem_max 134217728 net.ipv4.ip_forward 1 # 容器网络需要 kernel.pid_max 4194304 # 多进程训练时 PID 消耗很快 EOF sysctl --system # 文件句柄和进程数上限训练进程开文件比想象中凶 cat /etc/security/limits.d/99-ai.conf EOF * soft nofile 1048576 * hard nofile 1048576 * soft nproc 1048576 * hard nproc 1048576 EOFvm.max_map_count是最容易被忽略的一项默认六万多加载 70B 级别的模型时映射数瞬间打满进程直接被杀日志里只有一行 exit 137不查内核参数根本找不到原因。rmem_max和wmem_max要在高速网卡启用前设好后面再调需要重启网络容易把已连上的会话断掉。如果方案里要做设备直通或者 RDMA内核启动参数还要补上intel_iommuon iommupt这两项写进 grub 之后必须重启才生效。大页内存按框架建议预留1GB 大页的页数按单卡显存的八分之一到四分之一估写进启动脚本# 预留 64 个 1GB 大页具体数量按框架和模型规模调整 echo 64 /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages grep HugePages_Total /proc/meminfo # 回读确认3.2 GPU 驱动与 CUDA 工具链安装驱动安装翻车的概率最高原因基本集中在三处开源驱动没屏蔽、内核头文件版本不匹配、装完没重启就验证。先把开源驱动拉黑再装编译依赖最后静默安装驱动。# 1) 屏蔽开源显卡驱动否则装完厂商驱动会被它抢回去 cat /etc/modprobe.d/blacklist-nouveau.conf EOF blacklist nouveau options nouveau modeset0 EOF dracut --force # 2) 编译依赖kernel-devel 版本必须和 uname -r 完全一致 dnf install -y gcc gcc-c make dkms \ kernel-devel-$(uname -r) kernel-headers-$(uname -r) # 3) 静默安装--no-opengl-files 防止覆盖系统图形库 chmod x driver-550.xx.run ./driver-550.xx.run --silent --dkms --no-opengl-files # 4) 重启后验证卡数、驱动版本、显存、功耗上限一起看 nvidia-smi --query-gpuindex,name,driver_version,memory.total,power.limit \ --formatcsv--dkms是关键参数它把驱动注册进 DKMS 框架内核升级后自动重编省掉「重启回来驱动没了」的经典事故。--no-opengl-files在纯计算节点上必加不加会覆盖系统自带的图形库某些监控和远程桌面组件直接起不来。驱动装完必须重启再验证nvidia-smi能出结果不代表状态正常。要重点看两处卡数是否等于物理卡数功耗上限是否被限流。前者少了说明有卡没识别可能是供电或者 PCIe 链路问题后者偏低说明散热策略保守或者 BIOS 里设了功耗墙满载跑训练会直接降频。3.3 容器运行时与设备插件让容器里也看得见卡裸机能识别卡只是第一步业务跑在容器里容器看不见卡等于白装。链路是 containerd 接上 GPU 运行时再让 Kubernetes 的设备插件把卡数上报成可调度资源。# 让 nvidia-ctk 改写 containerd 配置并设为默认运行时 nvidia-ctk runtime configure --runtimecontainerd --set-as-default systemctl restart containerd # 冒烟测试不进 Kubernetes先确认运行时这一层通了 ctr -n k8s.io run --rm --gpus 0 \ registry.local/base/cuda:12.4.0-base nvidia-smictr这条命令的价值在于分层定位它能跑通说明 containerd 和驱动没问题问题只可能在 Kubernetes 设备插件它跑不通就往上查不用在编排层瞎猜。这个习惯帮我省过好几个小时。设备插件一般用 DaemonSet 部署节点上要打标签区分机型避免八卡训练任务被调度到推理节点# 按卡型和用途打标签调度时靠标签选节点 kubectl label node gpu-node-01 acceleratora100-80g pooltrain kubectl label node gpu-node-02 acceleratorl20-48g poolinfer # 训练节点加污点防止普通业务蹭资源 kubectl taint node gpu-node-01 dedicatedtrain:NoSchedule标签和污点要一起用只打标签不设污点普通业务照样能被调度上去半夜把卡占满。反过来只设污点不打标签训练任务又选不到机器。两者配套调度规则才立得住。4. 算力调度与三张网的配置让卡被切成想要的形状、让数据跑满带宽资源和网络配好之后节点才算真正可用。这一步的配置直接决定集群的利用率和稳定性参数写得松资源浪费写得紧任务排队。4.1 GPU 资源声明与切分策略训练任务和推理任务的资源声明逻辑完全不同。训练要整卡独占、多机并行/dev/shm必须放大推理可以做 MIG 切分或者共享按显存碎片分配。apiVersion: v1 kind: Pod metadata: name: train-demo spec: nodeSelector: accelerator: a100-80g # 锁定机型避免调度到异构节点 tolerations: - key: dedicated operator: Equal value: train effect: NoSchedule containers: - name: trainer image: registry.local/ai/pytorch:2.3-cu124 command: [torchrun, --nproc_per_node8, train.py] resources: limits: nvidia.com/gpu: 8 # 整机独占多机训练必须整卡 cpu: 96 memory: 1024Gi requests: nvidia.com/gpu: 8 # requests 等于 limits保证 QoS cpu: 96 memory: 1024Gi volumeMounts: - name: shm mountPath: /dev/shm volumes: - name: shm emptyDir: medium: Memory sizeLimit: 64Girequests和limits写成一样Pod 的 QoS 等级才是 Guaranteed节点资源紧张时不会被优先驱逐——训练任务被驱逐一次几天的 checkpoint 全废。/dev/shm那段更关键容器默认只有 64MB 共享内存PyTorch 的 DataLoader 多进程一开始搬运就报Bus error很多人以为是数据集问题其实是这个默认值。推理场景要做切分用 MIG 把一张卡切成多个实例每个实例独立分配显存和算力# 把 80G 卡切成 7 个 10G 实例推理任务按实例申请 nvidia-smi mig -cgi 19,19,19,19,19,19,19 -C nvidia-smi mig -lgi # 列出切出来的实例切分比例要按模型显存占用算切得太碎会导致每个实例都放不下模型切得太粗又浪费。4.2 参数面网络调优与并行存储挂载网络这块的经验是小包正常不代表链路正常一定要用大包压测。MTU 不一致是最隐蔽的坑配置时两端必须同步改。# IB 网卡 MTU 一般 4096RoCE 走以太通常 9000两端必须一致 ip link set dev ib0 mtu 4096 # 管理面双口做 bond参数面不做 bond 而是多口并行 nmcli con mod bond0 ipv4.method manual \ ipv4.addresses 10.10.30.21/24 \ bond.options modeactive-backup,miimon100 nmcli con up bond0参数面不做 bonding 是有原因的集合通信库自己会做多口聚合和负载均衡上层再做 bond 反而可能干扰它的路径选择。管理面做 active-backup 就够追求的是可靠不是带宽。存储挂载要把锁参数带上多机同时读同一份数据时没有文件锁会出现读到半截文件的情况# 并行文件系统挂载flock 参数保证多机并发读一致 mount -t lustre 10.20.30.11o2ib:/trainfs /mnt/trainfs \ -o flock,localflock,noatime # 挂载后立刻验证带宽别等训练跑起来才发现慢 fio --nameread --directory/mnt/trainfs --rwread \ --bs1M --size8G --numjobs8 --group_reportingnoatime减少元数据写入在百万级小文件的数据集上差别很明显。fio那一步是我必做的客户端带宽不达标就回去查存储面网卡和交换机端口别把问题留到训练阶段。4.3 多租户配额与优先级一个智算中心通常不止一个团队在用没有配额先到先占后到的排一天。资源配额和优先级类要一起配apiVersion: v1 kind: ResourceQuota metadata: name: team-a-quota namespace: team-a spec: hard: requests.nvidia.com/gpu: 32 # 最多占 32 张卡 requests.cpu: 512 requests.memory: 4Ti配额按团队分优先级类按任务类型分在线推理给高优先级离线训练给低优先级并且允许被抢占。这样紧急任务进来时能挤掉可中断的训练任务不至于整个集群被长任务锁死。5. 现场排查智算节点部署最常见的五个翻车点装过十几批节点出问题的位置高度集中。这五条基本覆盖了八成现场故障每条都按现象、原因、解决记下来。第一条宿主机nvidia-smi正常容器里报 no devices found。现象是容器启动就退出日志里一行设备找不到。原因通常是 containerd 没有把 GPU 运行时设为默认或者 cgroup v2 环境下设备权限没放开。解决是先跑nvidia-ctk runtime configure --runtimecontainerd --set-as-default并重启 containerd再确认/etc/containerd/config.toml里 runtime 段落确实写进去了最后用ctr run --gpus 0单独验证运行时这一层。第二条多机训练起不来集合通信卡在初始化。现象是单机八卡跑得好好的一上多机就超时日志里是unhandled system error或者直接挂住。原因集中在三处参数面网卡 MTU 两端不一致、网卡固件版本不同、通信库没指定用哪张网卡。解决是逐台核对ip link show的 MTU用厂商工具刷成同一版固件并在启动脚本里显式指定网卡列表别让它自己猜。第三条训练进程莫名被杀退出码 137。现象是跑到一半进程消失日志末尾没有任何异常堆栈。原因是内存超限被系统杀掉常见触发点就是容器/dev/shm只有 64MB。解决是把共享内存挂成内存盘并给到 32G 以上同时检查 Pod 的 memory limits 有没有超过节点实际可分配量。第四条重启之后nvidia-smi报驱动与库版本不匹配。现象是装完好好的重启回来所有 GPU 相关命令全报错。原因是系统自动更新拉了新内核而驱动没有跟着重编。解决是安装时带--dkms并且把内核包加入版本锁定禁止自动升级。这一条是血泪经验机房凌晨重启一次第二天全组人等驱动重装。第五条节点状态 NotReady设备插件一直重启。现象是节点加进集群后卡在 NotReady设备插件的 Pod 反复 CrashLoop。原因是插件上报的 GPU 数量为 0 时会把自己标成不健康而数量为 0 往往是驱动没装好或者设备节点权限不对。解决是先看插件日志里的设备枚举结果再回宿主机确认/dev/nvidia*是否存在、权限是否为 666权限不对就补 udev 规则。6. 验收怎么跑把「能跑」变成一串可复现的命令验收最怕的是「我看了一眼 nvidia-smi 有输出就签字了」。真正能交给下一个人的验收是一串别人照着敲也能得出同样结论的命令。我一般分四层跑卡是否可见、单卡算力是否达标、多卡带宽是否达标、存储吞吐是否达标。单卡算力用一段矩阵乘粗测跑出来的数字和卡型手册上的峰值比低太多就说明功耗墙或者散热有问题import time import torch # 16384 方阵做 FP16 矩阵乘粗略估算有效算力 a torch.randn(16384, 16384, dtypetorch.float16, devicecuda) b torch.randn(16384, 16384, dtypetorch.float16, devicecuda) for _ in range(3): # 预热避开首次编译和显存分配开销 torch.matmul(a, b) torch.cuda.synchronize() t0 time.time() for _ in range(10): torch.matmul(a, b) torch.cuda.synchronize() tflops 10 * 2 * 16384 ** 3 / (time.time() - t0) / 1e12 print(fmeasured TFLOPS: {tflops:.1f})预热那三轮不能省第一轮会触发显存分配和内核加载算出来的数字偏低。测出来的值对照该卡型的 FP16 峰值一般能达到六到八成算合格低于五成就要查功耗和散热。多卡带宽用集合通信测试工具跑 all-reduce这是多机训练的真正瓶颈# 8G 消息、2 台机器、每机 8 卡看 bus bandwidth 是否接近网卡线速 all_reduce_perf -b 8G -e 8G -f 2 -g 1-b和-e指定消息大小范围-f是步进倍数-g是每进程卡数。带宽数字要对比参数面网卡的物理带宽跑出来只有一半八成是走了 PCIe 路径没走网卡。验收项整理成一张表逐项打勾缺一项不签字验收项命令合格线卡识别nvidia-smi -L卡数与物理卡数一致容器可见ctr run --gpus 0 ... nvidia-smi容器内能看到全部卡单卡算力矩阵乘脚本达到该卡型 FP16 峰值的六成以上多卡带宽all_reduce_perf接近参数面网卡线速存储吞吐fio顺序读达到存储面带宽的七成以上调度可用提交一个占满整机的 Pod正常调度并跑完这套流程吃过亏才立起来的。早些年交付一批节点只验了宿主机nvidia-smi就交了结果业务方一上容器全部报设备找不到返工两天。从那以后我每次交付都强制走一遍这四层验收哪怕工期再紧也不跳过最后一层——签完字再发现问题的成本比多花半天高得多。希望帮到你。本文还有配套的精品资源点击获取
