## 1. 评测对象与总判断 本篇是一次单机容量盘点，对象为一台在评测期内同时承担白班推理与夜班训练的海光 DCU 服务器。评测要回答的问题只有一个：当生产单位用，这台机器能撑到哪一步，什么时候才应该去申请第二台。 硬件清单与每项配置对业务的含义： | 部件 | 配置 | 对业务的实际含义 | | --- | --- | --- | | 加速卡 | 8 × K100_AI，单卡 64GB | 总显存 512GB，8B 级模型单卡宽裕，32B 级靠切分 | | 卡间互联 | HCCS 高速互联 | 单机内张量并行、模型分片的通信不构成瓶颈 | | CPU | 双路 96 核，8 NUMA | 核数充足，NUMA 拓扑影响内存带宽与加载速度 | | 主机内存 | **125GB** | 全篇最短的板，第 5 节单独展开 | | 网络 | 单口普通以太网，无 IB/RoCE | 决定扩展路线，第 4 节单独展开 | 盘点初期注意力全在卡上：512GB 显存，直观感受是能干大事。评测期内被主机内存和网络先后纠正过认知，最终得到的短板排序是：**网络 >> 主机内存 > 单卡显存**。卡反而是这台机器上最不需要担心的部件。 先给总判断，依据在后文逐条给出：这台机器是一个合格的"单机生产单元"，32B 级以内的事基本都能干；最大的隐患不在卡上，在 125GB 主机内存上；无 IB 的网络把扩展路线锁定为"单机内榨干"而非"横向堆机器"。 ## 2. 能力分级：能干、紧张、做不了 同样 512GB 显存，任务选对游刃有余，选错怎么调参都是灾难。评测期内验证过的任务按三档归类。 能干档： | 任务 | 依据 | | --- | --- | | 8 × TP1 服务集群 | 0.6B / 8B 级模型一人一张卡，8 个独立实例，吞吐线性堆 | | 32B bf16 推理 | TP2 或 TP4，卡间 HCCS 管够，单机内切分无通信焦虑 | | 32B 级全量微调 | 8 卡总显存 512GB，工作集约 130GB，分片后每卡 16-30GB，容量从容 | | 8 卡以内分布式训练 | 数据并行、单机 FSDP/ZeRO，规模刚好 | 紧张档——最值得单列，因为排期时最容易被误判成"能干"： | 任务 | 紧张的原因 | | --- | --- | | 大模型 CPU 侧加载/保存 | 权重 62GB 的模型，CPU 拷贝一次内存就过半 | | dataloader 多 worker + 大 prefetch | 每个进程独立吃内存，8 卡训练时叠加很快 | | CPU offload 类训练 | 125GB 的机器做不起这笔交易，见第 5 节 | 做不了档： | 任务 | 原因 | | --- | --- | | 百 B 级模型推理 | 权重本身超过 512GB 总显存，切不进来 | | 跨机张量并行 | 普通以太网带宽撑不住 TP 通信量 | | 参数量超过显存总量的训练 | 125GB 内存兜不住 offload，卡也装不下 | 32B 全量微调一项附一条实测注脚：模型 bf16 权重约 62GB，加优化器状态和激活，训练工作集约 130GB，8 卡分片后每卡 16-30GB，显存侧从容。前提是**分片真的生效**——评测期内记录到 FSDP 分片未生效、单卡试图独扛全量工作集而 OOM 的一次事故。结论是容量账要算，分片是否真发生更要验证，验证手段是看每张卡的实际占用，不采信日志里的"成功"字样。 ## 3. 单机内：HCCS 让卡间通信近似免费 单机范围内，HCCS 高速互联使卡间通信可以按"免费"处理。TP2、TP4 的张量并行，单机 FSDP 的 all-gather / reduce-scatter——这些在 NVIDIA 集群上需要 NVLink 才舒服的操作，在本机单机内全部成立。实测中 32B 推理走 TP4、训练走 8 卡分片，卡间通信从未成为瓶颈。 这一条的正面价值：单机内做并行策略设计时，不必为通信留焦虑，注意力可以全部放在显存与内存的账上。 ## 4. 出了机器：以太网封死横向扩展 一出机器边界，条件完全改变。无 IB、无 RoCE，只有普通以太网，逐项对照： | 场景 | 单机内（HCCS） | 跨机（普通以太网） | | --- | --- | --- | | 张量并行（TP） | 完全可行 | 梯度/激活同步量巨大，带宽直接卡死 | | 数据并行梯度同步 | — | 每步全量 all-reduce，以太网扛不住，训练时间被通信吃掉 | | 模型文件分发 | 同盘或本机拷贝 | 62GB 权重走以太网，一次分发是分钟级等待 | 结论明确：**这个配置下多机数据并行不现实**。梯度同步的带宽需求是刚性的，普通以太网给不了。扩展路线由此锁定为"单机内榨干"——把 8 张卡的每一份显存、每一个实例安排到位——而不是横向堆机器。 这个认知一旦建立，排期决策反而简化：业务量上涨时，先检查单机还有没有空卡、能否换更小的模型、批次与并发还有多少调优空间，而不是条件反射地申请新机器。评测期内的所有业务峰值，都靠单机内的实例编排消化。 ## 5. 125GB 主机内存：四个消费大户与四条规则 显存 512GB 的观感容易掩盖主机内存的紧张。大模型工作流里有大量环节发生在内存上，三个大户： - **加载/保存权重**：safetensors 从磁盘读入要过一遍 CPU 内存再进卡，62GB 的模型峰值就要 60-70GB； - **dataloader**：多 worker、大 prefetch、长序列数据集，每个 worker 都是独立的内存消耗者； - **CPU offload**：优化器状态甚至参数挪到内存，按 GB 直吃。 对应四条实测总结出的规则： 1. **大权重操作前看 `free -g`，不同时开两个加载任务。** 两个 60GB 级加载并行，125GB 直接见底。 2. **CPU offload 是拿内存换显存的交易，125GB 的机器不照抄 NVIDIA 教程开 ZeRO-Offload。** 那些教程默认 512GB 乃至 1TB 主机内存；照抄的结果是用一个新的 OOM 换掉旧的。 3. **模型集中缓存目录与工作目录同盘，减少拷贝。** 跨盘搬运权重既慢，又会在路径上多出副本。 4. **swap 不是解药。** 训练时内存页在 swap 里进出，性能损失是灾难级的；宁可减 worker 数，不让系统开始 swap。 ## 6. 两次复现事件 ### 6.1 OOM 发生在 CPU 侧 训练启动后不久进程被杀，8 张卡显存均有大量余量——第一观感是"显存明明够，怎么崩"。`dmesg | grep -i oom` 给出记录：内核 oom-killer 选中了训练进程，被吃爆的是主机内存，路径是 dataloader 多 worker 加大 prefetch。调整方式为错峰加载——权重加载完成后再起 dataloader，调小 workers 与 prefetch，多任务错开启动时间。调整后同样的任务稳定跑通，显存侧全程未紧张。 这次事件之后固定了一条诊断顺序：OOM 先分清卡侧还是 CPU 侧。两者的改法完全不同，方向错了调参到天亮也无用。 ### 6.2 八卡排满后没有回旋位 8 张卡全部被业务实例占满后，某实例异常需要临时起验证任务，结果无卡可用，只能下线一个线上实例腾位置，业务抖动一次。复盘的结论是排卡按"8 卡 = 8 份容量"做满了规划，没给运维动作留余量；全占的代价是任何排障、任何新版本验证、任何临时需求都以牺牲线上业务为前提。 修正为一条硬规则：**排卡永远留一张救生艇**。7 张卡跑业务，1 张卡留给排障、冒烟测试与临时验证。表面损失 12.5% 算力，换来"任何故障都不必停业务"，实测这笔账成立。 ## 7. 多机判据与收束 单机有天花板，何时值得跨出这一步，评测采用的判据是三条且**三条同时满足才动**： | 判据 | 自查问题 | | --- | --- | | 模型装不下单机总显存 | 512GB 真的放不下，还是切分策略没做对？ | | 单机吞吐撑不住业务峰值 | 并发调优空间用尽了吗，还是真的到顶？ | | 训练需要跨机流水线并行 | 并行策略在单机 8 卡内真的无法表达吗？ | 门槛设高的理由是跨机带来一整套新的运维成本：跨机梯度同步对网络的要求（本配置下基本是绝路）、多台机器的驱动与依赖长期对齐、跨机任务的排卡与故障恢复。评测期内三条判据从未同时满足：峰值靠单机内编排消化，模型规模在 32B 以内，训练策略单机 8 卡内均可表达。若某天三条全部命中，说明业务量级已变，届时新增的运维复杂度才是合理投入。 把全篇账目收束成五行： - **能干**：8 × TP1 服务集群、32B bf16 推理（TP2/TP4）、32B 级全量微调、8 卡以内分布式训练； - **紧张**：125GB 主机内存是工作流的真瓶颈，加载、dataloader、offload 都压在它身上； - **做不了**：百 B 级模型、跨机张量并行、参数量超过显存总量的训练； - **扩展哲学**：无 IB 的网络把路线锁定为"单机内榨干"，多机数据并行在此配置下不现实； - **两条硬规则**：OOM 先分清卡侧与 CPU 侧；排卡永远留一张救生艇。 单机 8 卡的定位是一个团队的生产单位。它不是无限大，但把容量账算清——什么放得下、什么放不下、瓶颈在哪个部件——比急着堆机器重要得多。账算清了，才知道什么时候该安于单机，什么时候才真正该走向多机。