企业官网建设流程全解析

简介：《智算技术与算力规划设计及部署实施方案v2.0》面向智算中心建设方、架构师、运维及项目管理人员，聚焦算力基础设施从需求分析、规划设计到部署落地的完整链路，可用于方案编制、立项论证、技术选型与实施参考。文档围绕智算技术体系与算力资源规划展开，兼顾计算、网络、存储及配套设施的协同设计，并给出部署实施与运维保障的思路框架，帮助读者建立从业务需求到工程落地的系统认知。包内为1个PDF文件，整体约11.28MB，内容集中、便于检索与归档，适合作为项目前期调研和内部培训的参考材料。目前已有131人学习，说明其在智算中心规划与部署场景中具备一定的实用价值。对于需要快速梳理智算中心建设路径、完善实施方案文本或对照检查规划要点的读者，这份文档可作为较完整的框架性资料使用。

1. 从一份 v2.0 方案到一台能跑起来的机器：智算环境最容易翻车的地方

去年冬天跟一个智算中心的节点交付，方案文档封面上印着 v2.0，纸面上卡数、带宽、存储池、并发任务数都算得清清楚楚，真到机房上架那天才发现：框架要求的驱动版本比机器预装的高一个大版本，两台机器的网卡固件对不上，机柜实际功率比设计值高出两成。这类活儿从来不是装一个软件，而是把供电、系统、GPU 驱动、容器运行时、调度器、并行存储六层串成一条链，任何一环没对齐，上层就表现成「训练任务莫名其妙卡住」。装不好最典型的下场是卡只认出一半、多机通信超时、任务排队三天最后抛一个看不出所以然的错。这份笔记写给要交付算力节点、做算力规划、或者接手了别人半成品环境的人，从盘点、安装、配置一路走到验收，每步都留可复现的命令。

2. 环境盘点与版本选型：智算中心的算力账要先在表格里算平

方案文档里的算力规划通常按峰值写，落地时真正决定成败的却是那些不起眼的对照表：哪张卡插在哪个槽位、固件版本是多少、哪根线走参数面。我养成的习惯是设备还没进机房，先把三张表填满——硬件核对表、软件版本矩阵、网络与存储分配表。这三张表填不平，后面每装一步都要返工，最惨的是装到第三层才发现版本选错，前面全白干。

2.1 机房与硬件前置条件：功率、风道、槽位一个都不能含糊

八卡整机满载功率普遍在 6 到 10 千瓦之间，加 CPU、内存、网卡和风扇余量，一个塞满的算力柜做到 12 千瓦以上不稀奇。风冷机柜的单柜散热上限一般就压在 8 到 12 千瓦，方案里如果按「每柜四台八卡机」写，现场大概率要改成三台或者上冷板式液冷。这个账必须在采购前算，装完再改就是拆机柜的活儿。

上架顺序也有讲究：重设备靠下、交换机和存储靠上，参数面交换机的光模块发热大，别和 GPU 机器挤在同一段风道里。每台机器上架后立刻记录一张核对表，这张表是后面所有排错的基础。

带外管理口建议在装系统之前就配好，后面挂虚拟光驱、远程重启全靠它。常见做法是用 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 'Ops@2024#node21' ipmitool lan print 1 # 回读确认，防止写错网段

ipsrc static表示不依赖 DHCP，机房里 DHCP 出问题的时候带外还能进；lan print这一步别省，我见过写成10.10.3.21少一位、整柜机器全失联的情况，只能推着显示器车一台台接 KVM。

2.2 软件栈版本对照：先定框架，再倒推驱动

版本选型最容易犯的错是从驱动开始往上装，装到框架那层发现不匹配。正确顺序是反的：先确定业务要跑的框架版本，再由框架的 wheel 包倒推 CUDA 运行时，由运行时倒推驱动最低版本，最后由驱动倒推内核版本。这条链上只有最上面一层是业务决定的，下面全是被动选择。

我一般会锁成下面这样，具体数字按当期框架的官方对应表微调，但锁定原则不变：

这张表的关键不是数字，是「一次只动一个变量」。升级驱动就只升驱动，跑完验收再动下一层；同时升驱动和 CUDA，出了问题根本定位不到是哪一层的锅。项目里我见过有人图省事把整栈一起拉到最新，结果多机 all-reduce 带宽掉了三成，查了两天才发现是新驱动的某个默认开关变了。

2.3 三张网与存储分层：规划阶段就要定死

智算节点的网络不是一张网，是三张。参数面跑梯度同步，要求低延迟高带宽，用 IB 或者 RoCE，200G 起步；存储面跑训练数据读取，和并行文件系统对齐，100G 到 200G 以太；管理面跑带外、调度、监控，万兆就够。三张网走不同 VLAN、不同物理口，最忌讳为了省交换机把参数面和业务面混在一起跑。

存储按热度分三层：热数据放全闪并行文件系统，供训练直接读；温数据放对象存储，做数据集归档；冷数据落大容量机械盘。规划阶段要算的是「训练集大小 × 并发任务数」，不是单看总容量。一个常见的误判是存储池做得很足，但客户端带宽只配了 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 EOF

vm.max_map_count是最容易被忽略的一项，默认六万多，加载 70B 级别的模型时映射数瞬间打满，进程直接被杀，日志里只有一行 exit 137，不查内核参数根本找不到原因。rmem_max和wmem_max要在高速网卡启用前设好，后面再调需要重启网络，容易把已连上的会话断掉。

如果方案里要做设备直通或者 RDMA，内核启动参数还要补上intel_iommu=on iommu=pt，这两项写进 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 modeset=0 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-gpu=index,name,driver_version,memory.total,power.limit \ --format=csv

--dkms是关键参数，它把驱动注册进 DKMS 框架，内核升级后自动重编，省掉「重启回来驱动没了」的经典事故。--no-opengl-files在纯计算节点上必加，不加会覆盖系统自带的图形库，某些监控和远程桌面组件直接起不来。

驱动装完必须重启再验证，nvidia-smi能出结果不代表状态正常。要重点看两处：卡数是否等于物理卡数，功耗上限是否被限流。前者少了说明有卡没识别，可能是供电或者 PCIe 链路问题；后者偏低说明散热策略保守或者 BIOS 里设了功耗墙，满载跑训练会直接降频。

3.3 容器运行时与设备插件：让容器里也看得见卡

裸机能识别卡只是第一步，业务跑在容器里，容器看不见卡等于白装。链路是 containerd 接上 GPU 运行时，再让 Kubernetes 的设备插件把卡数上报成可调度资源。

# 让 nvidia-ctk 改写 containerd 配置并设为默认运行时 nvidia-ctk runtime configure --runtime=containerd --set-as-default systemctl restart containerd # 冒烟测试：不进 Kubernetes，先确认运行时这一层通了 ctr -n k8s.io run --rm --gpus 0 \ registry.local/base/cuda:12.4.0-base nvidia-smi

ctr这条命令的价值在于分层定位：它能跑通说明 containerd 和驱动没问题，问题只可能在 Kubernetes 设备插件；它跑不通就往上查，不用在编排层瞎猜。这个习惯帮我省过好几个小时。

设备插件一般用 DaemonSet 部署，节点上要打标签区分机型，避免八卡训练任务被调度到推理节点：

# 按卡型和用途打标签，调度时靠标签选节点 kubectl label node gpu-node-01 accelerator=a100-80g pool=train kubectl label node gpu-node-02 accelerator=l20-48g pool=infer # 训练节点加污点，防止普通业务蹭资源 kubectl taint node gpu-node-01 dedicated=train: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_node=8", "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: 64Gi

requests和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 一般 4096，RoCE 走以太通常 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 "mode=active-backup,miimon=100" nmcli con up bond0

参数面不做 bonding 是有原因的：集合通信库自己会做多口聚合和负载均衡，上层再做 bond 反而可能干扰它的路径选择。管理面做 active-backup 就够，追求的是可靠不是带宽。

存储挂载要把锁参数带上，多机同时读同一份数据时，没有文件锁会出现读到半截文件的情况：

# 并行文件系统挂载，flock 参数保证多机并发读一致 mount -t lustre 10.20.30.11@o2ib:/trainfs /mnt/trainfs \ -o flock,localflock,noatime # 挂载后立刻验证带宽，别等训练跑起来才发现慢 fio --name=read --directory=/mnt/trainfs --rw=read \ --bs=1M --size=8G --numjobs=8 --group_reporting

noatime减少元数据写入，在百万级小文件的数据集上差别很明显。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 --runtime=containerd --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, dtype=torch.float16, device="cuda") b = torch.randn(16384, 16384, dtype=torch.float16, device="cuda") 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(f"measured 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就交了，结果业务方一上容器全部报设备找不到，返工两天。从那以后我每次交付都强制走一遍这四层验收，哪怕工期再紧也不跳过最后一层——签完字再发现问题的成本，比多花半天高得多。希望帮到你。

本文还有配套的精品资源，点击获取