适用场景：在 Windows 本机（非 WSL）部署 OpenClaw，手动配置自定义模型与 API Key，并安装 Office（Word/PPT）处理技能。

一、前置确认

打开 PowerShell（Win+X → Windows PowerShell），允许本地脚本执行：

1

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Node.js 不需要提前安装，安装脚本自动处理（依次尝试 winget → Chocolatey → Scoop → portable zip 兜底）。

二、一键安装 OpenClaw

1

iwr -useb https://openclaw.ai/install.ps1 | iex

脚本自动完成：检测环境 → 安装 Node.js 24 → 全局 npm 安装 openclaw → 添加 PATH。

安装完成后重新开一个 PowerShell 窗口，验证：

1
2

openclaw --version
openclaw doctor

PATH 问题排查：如果提示 openclaw is not recognized，运行 npm config get prefix，把输出路径加入用户环境变量 PATH，重开终端即可。

三、初始化 Gateway

跳过交互式 onboard，直接初始化：

1

openclaw onboard --non-interactive --skip-health

安装 Gateway 服务（随 Windows 登录自启）：

1
2

openclaw gateway install
openclaw gateway status --json

如果 Scheduled Task 因权限被拒，脚本自动 fallback 到用户 Startup 文件夹，功能相同。

当前会话手动启动 Gateway：

1

openclaw gateway run

四、配置自定义模型与 API Key

配置文件路径：%USERPROFILE%\.openclaw\openclaw.json

用记事本 / VS Code 打开，填入 provider 信息：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

// ~/.openclaw/openclaw.json
{
  // API Key 存入环境变量（不要明文写死）
  env: {
    CUSTOM_API_KEY: "sk-your-key-here"
  },

  // OpenAI 兼容接口（适用于 Azure、阿里云百炼、火山方舟等）
  providers: {
    "my-provider": {
      kind: "openai-compatible",
      baseUrl: "https://your-api-endpoint/v1",
      apiKey: { env: "CUSTOM_API_KEY" }
    }
  },

  agents: {
    defaults: {
      workspace: "~/.openclaw/workspace",
      model: {
        // 格式：provider-id/model-name
        primary: "my-provider/your-model-name"
      }
    }
  }
}

如果使用 Anthropic 原生 API Key，更简单：

1
2
3
4
5
6
7
8

{
  env: { ANTHROPIC_API_KEY: "sk-ant-your-key" },
  agents: {
    defaults: {
      model: { primary: "anthropic/claude-sonnet-4-6" }
    }
  }
}

保存后 Gateway 自动热重载，无需重启。

连通性验证：

1

openclaw agent --local --agent main -m "Reply with: CONFIG-OK"

五、安装 Office 技能（Word / PPT）

根据使用场景选择对应技能，搜索命令：

1
2

openclaw skills search "office"
openclaw skills search "word"

方案 A：纯文件操作（跨平台，推荐）

1
2
3
4
5

# Word / DOCX
openclaw skills install word-docx

# DOCX + PPTX 同时支持
openclaw skills install office-document-editor

能力：创建、读取、编辑 .docx / .pptx 文件，支持样式、表格、段落、修订追踪、格式保留、Git 版本集成。

方案 B：COM 自动化（需本机安装 Office/WPS）

1

openclaw skills install tiangong-wps-word-automation

能力：通过 Windows COM 接口控制 Word/WPS 程序——读取内容、替换文本、插入标题/页眉页脚、分页、合并文档、导出 PDF/TXT、替换图片。

⚠️ 仅适用于已安装 Microsoft Office 或 WPS 的 Windows 机器。

验证技能安装：

1

openclaw skills list

六、全流程验证

1
2
3
4
5
6
7
8
9
10
11

# Gateway 状态
openclaw gateway status

# 打开 Web 控制台（浏览器）
# http://127.0.0.1:18789

# 快速对话测试
openclaw agent --local --agent main -m "你好"

# 综合诊断
openclaw doctor

七、常见问题速查

第二章讲过 ARM 服务器 CPU，第六章讲过鲲鹏在国产芯片里的位置——明天这台机器，就是把那些 PPT 上的名词变成手能摸到的铁的机会。

本文使用约定

• 🎤 = 建议停下来给新人手把手讲的知识点
• 📷 = 建议拍照存档的点（实机照片我现场补，先留位）
• > TODO = 这台实机的具体配置，明天对着铭牌/BMC 核对后回填
• 资料权限：互联网公开 = 该段技术参数引自《KunLun 2280 V2 服务器技术白皮书》（河南昆仑技术有限公司，文档版本 07，2026-03-04），属公开资料，可对外讲解。

⚠️ 型号确认：本文技术细节以 KunLun 2280 V2 白皮书为准。明天先看实机铭牌确认型号；若铭牌为其他贴牌名（如 S920X20），以实物为准、白皮书作参考——它们是同一鲲鹏 920 平台。

0. 下机房之前（备课 + 安检）

进机房不是开盖就拆。先把这几件事过一遍：

• 防静电：戴防静电手环（anti-ESD wrist strap），金属触点贴紧手腕，鳄鱼夹接到机柜接地点；条件允许再穿防静电服（anti-static smock）。🎤 给新人讲清楚为什么——CMOS、内存颗粒怕静电击穿，几百伏的人体静电肉眼无感但足以打坏芯片。手环把人体和机柜拉到同一电位，防静电服则抑制衣物摩擦起电。

• 断电规则：支持热插拔的部件（硬盘、电源、风扇）现场可演示热插拔；不支持热插拔的部件（CPU、内存、PCIe 卡、FlexIO/OCP 卡、BMC 插卡）必须先正常关机、断电。🎤 让新人记住”哪些能带电插、哪些不能”这条线。

  资料权限：互联网公开。白皮书明确：FlexIO 卡 1、FlexIO 卡 2 及 BMC 插卡都不支持热插拔，更换需将电源模块下电；硬盘支持热插拔。

• 工具：十字螺丝刀、防静电袋、手电（看槽位丝印用）、手机（拍照）。
• 重量预期：🎤 满配 21~27kg，2U 单人搬运吃力，搬运/上架要两人。

  资料权限：互联网公开。满配净重：8×2.5 英寸 21kg；16×2.5 英寸 24kg；24×2.5 英寸 24kg；12×3.5 英寸 27kg；包装材料另 5kg。

TODO(✅)：确认这台是高配定制化机器：7280Z(80C_2.9GHz_SMT_TDP325W)*2+64G*32+NVME*2+25G*2(OCP)。

📷 防静电装备：防静电手环佩戴 + 鳄鱼夹接地点特写、防静电服穿着，作为安全规范示范照。
📷 进机房第一张：整机在机柜里的位置 + 机箱头部标签（铭牌 / 合格证 / 快速访问标签 / SN 产品序列号 / 防压标签）。

1. 先建立整体认知（白皮书 1 产品概述 / 2 产品特点）

资料权限：互联网公开。

在拆细节之前，先让新人退后两步看整台机器，建立”这是什么、用在哪”的认知：

• 定位：KunLun 2280 V2 是基于鲲鹏 920 处理器的 2U 2 路机架服务器，面向互联网、分布式存储、云计算、大数据、企业业务。🎤 关键词”通用计算”——不是 AI 训练机、不是纯存储机，是跑业务/数据库/虚拟化的主力机型。对比一下：GPU 服务器后面板会插满 PCIe，功耗散热是另一个量级。

• 2U 是什么概念：1U = 44.45mm，2U 约 89mm 高（白皮书机箱高 86mm）。🎤 让新人用手比一下，联系第七章”机架/U”。
• 鲲鹏 920 = ARM 架构 SoC：🎤 今天最值得讲的一点——x86 之外的另一条路线，ARMv8 指令集。而且鲲鹏 920 是 SoC，把 DDR5 控制器、PCIe 5.0、100GE/25GE/10GE/GE 网络接口都集成进了处理器内部。联系第二章”指令集架构”、第六章”ARM 服务器 CPU”。
• 高核 / 低核两种机型：🎤 这是白皮书新增的区分，明天先认准是哪种——
  • 高核：单 CPU ≥64 核，32 个内存槽（DDR5），最多 12 个 PCIe 标准槽。

🎤 顺带讲几个能体现”服务器级”设计的特点（白皮书”产品特点”）：白金电源 50% 负载效率最高 94%、PID 智能调速、硬盘错峰上电降低启动功耗、SSD 比机械盘省电约 80%。

TODO：7280Z(80C_2.9GHz_SMT_TDP325W)*2+64G*32+NVME*2+25G*2(OCP)。

2. 三层视角：服务器到底由什么组成（重点 · 白皮书 3 物理结构 / 4 逻辑结构）

这是明天最该讲透的一节。先给新人一个能套到任何服务器上的”三层”心智模型，再对着这台机器一一指认。

🎤 第一层 · 物理结构（东西怎么摆）：2U 机箱从前到后大致是——前面板/前置硬盘 → 中部基础板（CPU+内存+风扇）→ 后部电源 + IO 模组。

资料权限：互联网公开。白皮书”部件说明”列出的主要部件：IO 模组 1/2/3、电源模块、机箱、PSU 导风罩、超级电容、导风罩、风扇板、前置硬盘背板、风扇支架、风扇模块（4 个）、前置硬盘、散热器、DIMM 内存、理线架、基础板、CPU 托架、扩展板、FlexIO 卡 1（归属 CPU1）、FlexIO 卡 2（归属 CPU2）、BMC 插卡、M.2 硬盘模组、开箱检测模组。

🎤 第二层 · 逻辑结构（数据怎么流）：

资料权限：互联网公开。白皮书逻辑结构要点：

• 两路鲲鹏 920 处理器，高核每 CPU 16 个 DDR5、低核每 CPU 8 个 DDR。
• 两路 CPU 之间通过 2 组 HCCS 总线互连，最高 30Gbps，总速率 480Gbps。🎤 这就是第二章讲的”多路互联”，跨 CPU 访问内存有延迟差——NUMA 的由来。
• CPU 的 PCIe 资源经 PCB 或线缆接到 PCIe Riser 卡，Riser 决定槽位规格和 PCIe 版本。
• CPU1、CPU2 各挂 1 张 FlexIO 网卡（4×GE / 2×25GE·10GE / 1×100GE）。
• 集成 Hi1711 BMC 管理芯片，独立外出 VGA、管理网口、串口、USB。

🎤 收尾点：让新人记住这张图——之后讲每个部件，都回到”它在物理上摆哪、在逻辑上连谁”。

📷 开盖俯视全景图（这张图后面反复回来指）；标出基础板、扩展板、CPU 托架、内存区、风扇区、IO 模组的位置。

3. 前面板（白皮书 5.1）

带新人从正面开始，这是最直观的一面。

资料权限：互联网公开。前面板组件（8×2.5 英寸配置）：UID 按钮/指示灯、健康状态指示灯、电源按钮/指示灯、故障诊断数码管、FlexIO 卡在位指示灯（1、2）、硬盘/指示灯、USB 3.0 接口、USB Type-C 接口/指示灯、VGA 接口、标签卡（含 SN 标签）。

🎤 逐个讲：

• UID 按钮/指示灯：Unit Identification，在一排机器里定位”就是这台”。🎤 现场按一下看蓝灯亮。

  资料权限：互联网公开。短按 UID 开/关定位灯；长按约 5 秒可复位 iBMC 管理系统；BMC 触发的闪烁只持续 255 秒后自动熄灭；也可通过 BMC 命令或 WebUI 远程控制。

• 健康状态指示灯：🎤 这是新人最该记住的”一眼看健康”灯。

  资料权限：互联网公开。绿色常亮 = 正常；红色 1Hz 闪 = 严重告警；红色 5Hz 闪 = 紧急告警。

• 故障诊断数码管：🎤 服务器特有——开机自检/故障时显示代码，比 PC 的”滴滴”报警精确得多。
• FlexIO 卡在位指示灯（1、2）：绿色常亮=卡在位且可识别，熄灭=不在位或故障。
• 前置 USB 3.0 / USB Type-C / VGA：本地维护接口。

TODO：核对这台前面板的硬盘配置（8×2.5，实物为12×3.5）、是否带前置 IO 模组。

📷 前面板整体 + 指示灯特写（最好拍一张正常运行全绿状态）；UID 灯点亮前后对比；故障诊断数码管特写。

4. 后面板（白皮书 5.2）

转到机器背后。🎤 后面板是”对外接口的总出口”。

资料权限：互联网公开。后面板组件：IO 模组 1/2/3、电源模块 1/2、电源模块指示灯/接口、FlexIO 卡 1（归属 CPU1）及指示灯、FlexIO 卡 2（归属 CPU2）及指示灯、VGA 接口、USB 3.0 接口、Mgmt 管理网口及指示灯、UID 按钮/指示灯、串口。其中 VGA / USB / 管理网口 / UID / 串口这几个位于 BMC 插卡上。

🎤 逐个讲：

• 电源模块（PSU）：🎤 重点演示热插拔——拔掉一个电源，机器不断电、告警亮、另一个接管。这是新人最该亲眼看到的可靠性设计。

  资料权限：互联网公开。电源热插拔、1+1 冗余备份；白金电源；2000W AC 白金电源在输入 200~220V AC 时输出降额到 1800W；单电源无冗余、不建议单电源使用；同一台电源型号必须相同。

• 后面板这一排 BMC 接口：🎤 强调管理网口（Mgmt）是独立于业务网口的带外管理口，讲 BMC 时还要用。
• FlexIO 卡 1/2：业务网口来自这里，分别归属 CPU1/CPU2。🎤 注意它不支持热插拔。
• IO 模组 1/2/3：PCIe 扩展卡从这里露出挡板。

📷 后面板整体，标清每个口是什么；拔出一个 PSU 的过程（确认 1+1 冗余后再操作）。

TODO：确认 PSU 数量与功率: 2000W/PSU，2个、当前 IO 模组各插了什么卡：25G OCP网卡，见下图。

5. 开盖：基础计算组件（重点 · 白皮书 5.3）

⚠️ 涉及 CPU、内存、PCIe 卡的拆装，必须先关机断电。前面的硬盘/电源/风扇热插拔演示做完，再进入这部分。

5.1 基础板与 CPU（5.3.1 接口介绍）

资料权限：互联网公开。该平台为”天池架构”，基础计算组件的典型应用为基础板；CPU 集成在基础板上，不能单独更换。基础板上密布 CPU 北向/南向 UBC/UBCDD 高速连接器、电源入口连接器、NC-SI、HBRT、RTC 电池座、开箱检测连接器等。

🎤 讲给新人：

• 指出散热器位置，鲲鹏 920 封装在散热器下，现场不开盖看 die，重点讲它在基础板上的位置。
• 🎤 关键认知：CPU 焊在基础板上、不能单独换——这和 PC/部分 x86 服务器”CPU 可插拔”不同，整板维护。
• 双路互联：🎤 回到第 2 节那张图，两颗 CPU 通过 2 组 HCCS 互连，引出 NUMA（第二章）。

📷 基础板俯视，指出两个 CPU 散热器、内存区、各类连接器。

5.2 内存（重点中的重点 · 白皮书 5.3.2）

这是明天最值得手把手讲的部分。白皮书分四小节，正好对应四个知识点：

① 内存槽位编号（5.3.2.1）

资料权限：互联网公开。

• 高核：最大 32 个内存槽，1 个处理器 8 个内存通道，每通道 2 个 DIMM。编号形如 DIMM000~DIMM171（CPU1 为 DIMM0xx，CPU2 为 DIMM1xx）。
  ~~ > - 低核：最大 16 个内存槽，1 个处理器 4 个内存通道，每通道 2 个 DIMM。 ~~

🎤 拿手电照基础板丝印，带新人念出槽位编号，讲清”编号 → CPU → 通道 → DPC”的对应关系。
📷 内存区域全景 + 槽位丝印特写。

② 内存安装原则（5.3.2.2）

资料权限：互联网公开。

• CPU1 对应的内存槽至少配 1 根。
• 不允许混用不同规格（容量/位宽/rank/高度/厂家），多根内存必须相同 P/N 编码。
• 平衡配置性能最佳；单 CPU 配单数根（3/5/7）= 通道不平衡；两 CPU 装不同数量 = 处理器不平衡，都不推荐。
• 空槽必须装假模块（保证风道）。

🎤 这是新人最容易踩坑的地方——内存不是随便插哪个槽都行。现场对照实机已插内存验证安装顺序。

③ 内存参数（5.3.2.3）

资料权限：互联网公开。

• 高核：DDR5，额定 4800MT/s，单条 32/64/96/128GB，整机最多 32 条、最大 4096GB；速度 1DPC 4800 / 2DPC 4400。
• 低核：单条 32/64GB，整机最多 16 条、最大 1024GB（32/40 核机型整机最大 2048GB）。

🎤 联系第三章”DDR 演进”——讲清 DDR5、4800MT/s、DPC（每通道几条）对频率的影响。

④ 内存保护技术（5.3.2.4）

资料权限：互联网公开。支持：ECC（含 SEC/DED 单错纠正/双错检测）、单设备数据校正（SDDC）、内存巡检（Demand & Patrol Scrubbing）、地址奇偶检测、内存过热调节、数据加扰（Data Scrambling）。

🎤 讲 ECC——服务器内存和家用内存的关键区别，联系第三章”ECC 与可靠性”。

🎤 本节收尾：让新人理解”槽位编号 + 安装原则”是运维加内存时必查的东西，插错了要么不认、要么掉速、要么风道乱。

6. 散热组件（白皮书 5.5）

🎤 2U 机器靠前后风道散热：前进冷风，穿过硬盘→内存→CPU→后部，热风从后排出。

资料权限：互联网公开。

• 4 个热插拔风扇，支持 N+1（转子）失效；同台风扇必须相同 P/N。
• 风扇支持可变转速：一般以最低速转动，入风口或机器温度升高时自动提速（PID 智能调速）。
• 散热组件含风扇板（供电+调速背板）和风扇模块。

🎤 现场可演示拔一个风扇 → 其他风扇提速 + 告警。提醒新人：机房噪音大、风扇全速尤其吵是正常现象（联系第五章”散热”）。

📷 风扇模组 + 风道方向（用手感受前进后出）。

7. 存储组件（重点 · 白皮书 5.6）

存储是另一个适合手把手的部分。

7.1 硬盘配置与编号（5.6.1 / 5.6.2）

资料权限：互联网公开。支持 SAS/SATA/NVMe 硬盘，多种配置：8×2.5、8×2.5 SAS/SATA（兼容 4×2.5 NVMe）、16×2.5、24×2.5、12×3.5 等；前置 + 后置 + M.2 多种组合。

🎤 带新人对照前面板盘位念硬盘编号，讲：

• 盘位编号规则：物理位置和软件里看到的盘符怎么对应——这是换盘时别拔错盘的关键。
• 盘型：2.5”/3.5”、SAS/SATA/NVMe 的区别，联系第四章”存储接口”。

📷 前置硬盘背板整体 + 单个盘位编号丝印特写。

2.5 SATA SSD

2.5 U.2 NVMe SSD

3.5 SATA HDD

TODO：填实际硬盘配置——几块盘、容量、接口、用途（系统盘/数据盘）。

7.2 硬盘指示灯（5.6.3）

🎤 每个盘位有三个灯：Active（绿）/ Fault（红）/ Locate（蓝）。

资料权限：互联网公开。SAS/SATA 硬盘指示灯状态：

Active(绿)	Fault(红)	Locate(蓝)	含义
熄	熄	熄	硬盘不在位
常亮	熄	熄	在位且无故障
4Hz 闪	熄	熄	正常读写
1Hz 闪	1Hz 闪	熄	正在重构
常亮	常亮	熄	硬盘故障
熄	常亮	熄	硬盘被拔出
常亮	熄	1Hz 闪	硬盘被定位

NVMe 硬盘另有”热插拔过程 / 允许拔出”等状态（Fault 灯不同频率闪烁）。

🎤 换盘 SOP：管理软件里定位 → 点亮该盘 Locate（蓝）灯 → 现场确认编号 → 热拔热插。现场演示点亮某块盘的定位灯。

📷 硬盘指示灯各状态特写（至少拍”在位无故障”和”定位中”）。

7.3 后置硬盘 / M.2 / RAID（5.6.4 ~ 5.6.6）

资料权限：互联网公开。

• 后置硬盘模组：IO 模组 1/2 支持后置 2×3.5 或 2×2.5；IO 模组 3 支持后置 4×2.5（其中 IO3 后置 4 盘支持硬 RAID）。
• M.2 硬盘模组：内置，常用作系统盘。
• RAID 级别比较表（N=成员盘数，M=子组数）：

RAID	可靠性	读	写	硬盘利用率
0	低	高	高	100%
1	高	高	中	50%
5	较高	高	中	(N-1)/N
6	较高	高	中	(N-2)/N
10	高	高	中	50%
50	高	高	较高	(N-M)/N
60	高	高	较高	(N-M×2)/N

🎤 RAID 是重头戏——联系第四章”RAID 与企业存储”，对着这张表讲”容量利用率 vs 冗余 vs 性能”的取舍。提一句：SAS/SATA 走 RAID 控制卡，支持超级电容掉电保护。

TODO：确认这台是否配 RAID 卡、跑什么 RAID 级别、有无后置盘和 M.2。现场可进 BMC 看逻辑卷。

8. 扩展组件：存储扩展 / IO 扩展 / FlexIO（白皮书 5.7 ~ 5.9）

🎤 这部分讲”按需扩展”，体现通用服务器的灵活性。

资料权限：互联网公开。

• 存储扩展组件（5.7）：硬盘背板（如 24×2.5 NVMe 背板，带 UBC 连接器 + MiniSAS Port A/B + 电源/低速连接器），把更多盘连到 CPU/RAID 卡。
• IO 扩展组件（5.8）：PCIe Riser + 扩展卡。高核最多 12 个、低核最多 10 个 PCIe 标准槽，规格覆盖 PCIe 5.0 / 4.0 的 x16 / x8，全高全长/全高半长/半高半长按 IO 模组不同而异。🎤 讲 Riser 的作用——把主板 PCIe 通道”立起来”接更多卡。
• FlexIO 卡（5.9）：该平台特色，灵活配网口、不占标准 PCIe 槽。单板最多 2 张，单张提供 4×GE 电口 / 2×25GE·10GE 光口 / 1×100GE 光口，均支持 PXE；25GE 与 10GE 光口靠换光模块切速率。

📷 打开 IO 区域拍 Riser 和插的卡；拍 FlexIO 卡及其挡板。

TODO：列出这台实际插了哪些 IO 卡（网卡型号/速率、RAID 卡等）、FlexIO 卡端口配置。

OCP3.0 网卡（支持NCSI Sharelink Management）

PCIe 网卡（普通网卡）

9. BMC 插卡 & 系统管理（重点收尾 · 白皮书 5.10 + 9 系统管理）

明天的收尾高潮：带外管理。🎤 这是服务器区别于 PC 的灵魂功能之一。

资料权限：互联网公开。

• BMC 插卡（5.10）：本产品用 Hi1711 BMC 插卡，外出 VGA、管理网口、USB、串口、USB Type-C；板上 COM_SW 跳线可切换面板串口连到 BMC 还是 OS。
• iBMC 系统管理（第 9 章）：
  • 管理接口：IPMI 1.5/2.0、Redfish、SNMP、HTTPS、DCMI 1.5、命令行。
  • 故障诊断：临终截屏与录像、屏幕快照、Syslog/Trap/邮件告警、FDM 基于部件的精准故障诊断。
  • 远程维护：虚拟 KVM（KVM over IP）+ 虚拟媒体、RAID 带外监控配置、Smart Provisioning 免光盘装 OS。
  • 智能电源：功率封顶、动态节能。
  • 管理网口：1 个 10/100/1000Mbps RJ45。

🎤 用笔记本连管理网口，登录 iBMC Web，现场演示：

• 看实时温度、风扇转速、电源功率、健康状态。
• 看硬件告警日志（FDM 精准定位到部件）。
• 远程 KVM——不插显示器键盘也能操作这台机器的”屏幕”。🎤 这个最让新人惊艳，讲清运维为什么离不开它。
• 远程开关机 / 重启。

📷 iBMC 登录界面 + 能看到温度/风扇/功率的仪表盘页面。

⚠️ 截图/拍照前确认不泄露内网 IP、SN、账号密码。

TODO：提前找运维要 iBMC 管理 IP 和登录账号，别现场卡壳。

10. 收尾：规格、兼容性、认证（白皮书第 6、7、10 章）

回到会议室或现场总结，把”摸过的铁”和”纸面规格”对上。

资料权限：互联网公开。

• 技术规格（6.1）：2U 机架；鲲鹏 920 双路（高核≥32 核 / 低核 40 或 32 核）；内存最高 4800MT/s RDIMM；前面板 2×USB3.0 + VGA + USB-C，后面板 2×USB3.0 + VGA + 3.5mm 串口 + RJ45 管理网口；4 个热插拔风扇 N+1；集成显卡 32MB 显存，最高 1920×1200@60Hz / 16M 色。
• 环境规格（6.2）：工作温度 5~40℃（ASHRAE A1/A2/A3）；工作湿度 8~90%RH 无冷凝；风量 ≥204CFM；工作海拔 ≤3050m（超 900m 按高度降额）。🎤 用这条解释机房为什么要恒温恒湿、为什么有冷热通道。
• 物理规格（6.3）：机箱 86mm×447mm×798mm；装 IEC 297 通用机柜（宽 482.6mm、深 ≥1000mm）；满配净重 21~27kg。
• 电源规格（6.4）：热插拔 1+1；外部空开推荐 高核 AC 32A / DC 100A，低核 AC 32A / DC 63A。
• 认证（第 10 章）：中国 CCC（GB 17625.1-2022、GB 4943.1-2022、GB/T 9254.1-2021 A 级）、CQC（CQC3135-2011）、航空运输鉴定 IATA DGR 64th 2023。

🎤 讲两个观念：① 兼容性列表——国产服务器什么 OS/硬件经过认证才能配，不能乱配（白皮书 7 软硬件兼容性）；② 认证对采购合规的意义（联系第九章）。

附：明天的动线清单（打印带去）

热插拔的先演示，断电拆的放后面：

1. □ 进门：机箱头部标签（铭牌/SN）、机柜位置 📷
2. □ 整机认知：2U / 通用计算 / 鲲鹏 920 ARM / 高核·低核 🎤
3. □ 三层视角讲解 + 画逻辑图 🎤（重点）
4. □ 前面板：健康灯、UID 灯、故障数码管演示 📷🎤
5. □ 后面板：BMC 接口、FlexIO、PSU 热插拔演示 📷🎤
6. □ 风扇：风道、风扇热插拔演示 📷🎤
7. □ 前置硬盘：编号、三色指示灯、Locate 定位灯演示 📷🎤
8. □ —（关机断电）—
9. □ 开盖俯视全景 📷
10. □ 基础板 / CPU（焊死不可换）/ HCCS / NUMA 🎤
11. □ 内存：槽位编号、安装原则、参数、ECC 🎤（重点）
12. □ IO 扩展 / Riser / FlexIO 📷🎤
13. □ —（恢复供电、开机）—
14. □ BMC：登录 iBMC、远程 KVM、FDM 告警日志演示 📷🎤（高潮）
15. □ 规格 / 环境 / 认证对照总结 🎤

全文 TODO 汇总（明天对实机回填）：高核/低核、核数主频 TDP、硬盘配置与编号、RAID 卡与级别、后置盘/M.2、IO 卡清单、FlexIO 端口配置、PSU 数量与功率、iBMC 管理 IP 与账号、OS 版本。
回填并配齐现场照片后，把本文从”备课模板”升级成”实机档案”。

资料来源：《KunLun 2280 V2 服务器技术白皮书》，河南昆仑技术有限公司，文档版本 07（2026-03-04）。本文引用的技术参数均来自该公开白皮书，资料权限：互联网公开。原始链接：https://www.kunlunit.com/static/resource/kunlun-2280-v2-whitepaper

这篇只解决四件事

1. 装 Homebrew，并把它切到清华源（避免被官方源卡住）。
2. 装 Node.js / npm，npm registry 切到国内源。
3. 手动从官网下载 VS Code 安装。
4. 手动装 Claude Code 插件，并在用户级 settings.json 里填好自定义 API。

不装 Claude Code CLI——本文只面向插件用户，CLI 用得到再单独折腾。

1. 安装 Homebrew（清华源）

官方安装脚本要从 GitHub 拉脚本和仓库，国内常常超时。按清华 TUNA 镜像的官方做法来：先设好环境变量，再用镜像版安装脚本装，这样首次安装拉仓库就直接走清华。

macOS 自带 bash、git、curl，但还需要 Command Line Tools。如果没装过，先跑 xcode-select --install。

第一步，在终端设置环境变量，让安装脚本从清华拉 brew 本体和 core 仓库：

1
2
3

export HOMEBREW_BREW_GIT_REMOTE="https://mirrors.tuna.tsinghua.edu.cn/git/homebrew/brew.git"
export HOMEBREW_CORE_GIT_REMOTE="https://mirrors.tuna.tsinghua.edu.cn/git/homebrew/homebrew-core.git"
export HOMEBREW_INSTALL_FROM_API=1

第二步，从清华克隆安装脚本并执行：

1
2
3

git clone --depth=1 https://mirrors.tuna.tsinghua.edu.cn/git/homebrew/install.git brew-install
/bin/bash brew-install/install.sh
rm -rf brew-install

第三步，把 brew 的路径写进 shell 配置（Apple Silicon 默认装在 /opt/homebrew，Intel 在 /usr/local，且无需这步）：

1
2
3

# 仅 Apple Silicon（uname -m 输出 arm64）需要
test -r ~/.zprofile && echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile
eval "$(/opt/homebrew/bin/brew shellenv)"

第四步，把上面那两个 git 源环境变量也持久化进 profile，这样以后每次 brew update 都会自动走清华，不会被改回 GitHub：

1
2

test -r ~/.zprofile && echo 'export HOMEBREW_BREW_GIT_REMOTE="https://mirrors.tuna.tsinghua.edu.cn/git/homebrew/brew.git"' >> ~/.zprofile
test -r ~/.zprofile && echo 'export HOMEBREW_CORE_GIT_REMOTE="https://mirrors.tuna.tsinghua.edu.cn/git/homebrew/homebrew-core.git"' >> ~/.zprofile

第五步，把 bottle 二进制包下载也切到清华（不然装包还是会去 GitHub 拉预编译包）：

1
2
3

echo 'export HOMEBREW_API_DOMAIN="https://mirrors.tuna.tsinghua.edu.cn/homebrew-bottles/api"' >> ~/.zprofile
echo 'export HOMEBREW_BOTTLE_DOMAIN="https://mirrors.tuna.tsinghua.edu.cn/homebrew-bottles"' >> ~/.zprofile
source ~/.zprofile

最后验证：

1
2

brew update
brew --version

自 brew 4.0 起 HOMEBREW_INSTALL_FROM_API=1 已是默认行为，大部分人其实无需克隆 homebrew-core 仓库、也无需设 HOMEBREW_CORE_GIT_REMOTE，只要 HOMEBREW_API_DOMAIN 走镜像即可。但设上 core 源不影响使用，遇到要跑 brew cat 之类开发命令时反而省事，这里就一并配齐。

2. 安装 Node.js 和 npm

直接用 brew 装 LTS 版本就够用。

1
2
3

brew install node
node -v   # v22.x.x 之类
npm -v    # 10.x.x 之类

把 npm registry 切到国内镜像（淘宝维护的 npmmirror，是目前最稳定、和官方同步最及时的国内源）：

1
2
3
4
5

npm config set registry https://registry.npmmirror.com

# 验证
npm config get registry
# 应输出 https://registry.npmmirror.com/

如果你坚持用清华源，可以试 https://mirrors.tuna.tsinghua.edu.cn/npm/，但 npm 的同步频率不如 npmmirror 高，遇到新发布的包可能拉不到。我个人长期用 npmmirror。

到这里，命令行基础工具就备齐了。

3. 手动安装 VS Code

不用 brew install --cask——国内访问 VS Code 官方下载有 CDN 加速节点，手动下反而更快、版本更新。

1. 浏览器打开 https://code.visualstudio.com/
2. 点击 Download Mac，选 Apple Silicon 或 Intel chip（uname -m 查：arm64 是 Apple Silicon）
3. 下载下来是一个 .zip，双击解压得到 Visual Studio Code.app
4. 把它拖到 /Applications 文件夹——不放进 Applications 系统会反复弹”是否移到应用程序”
5. 第一次打开时 Gatekeeper 会确认一下，点”打开”

可选但推荐的一步：装好以后，在 VS Code 里按 Cmd + Shift + P，搜索并执行 Shell Command: Install 'code' command in PATH，这样终端里就能用 code . 在当前目录打开 VS Code。

4. 手动安装 Claude Code 插件

VS Code 应用内的插件市场是直连微软 Marketplace，国内不一定稳。两种装法挑一种顺手的：

方式一：插件市场（顺利的话最快）

1. VS Code 左侧活动栏点扩展图标（或 Cmd + Shift + X）
2. 搜 Claude Code，发布者是 Anthropic
3. 点 Install

方式二：手动下 VSIX（市场连不上时备用）

1. 浏览器打开 https://marketplace.visualstudio.com/items?itemName=anthropic.claude-code
2. 右侧 “Resources” 区域点 Download Extension，得到一个 .vsix 文件
3. 回到 VS Code，按 Cmd + Shift + P，执行 Extensions: Install from VSIX...，选刚下的文件

装完左侧活动栏会多一个 Claude 图标，点开会提示登录或填 API Key——这一步先不管，下一节统一用配置文件搞定。

5. 配置自定义 OpenAI Compatible API

Claude Code 插件读 用户级的配置文件 ~/.claude/settings.json，里面 env 段定义的环境变量会在每次启动时注入到 Claude 进程里。把自定义 API 信息塞这里就行——既不污染全局 shell 环境，也方便迁机器。

5.1 准备目录和文件

1
2

mkdir -p ~/.claude
touch ~/.claude/settings.json

5.2 填入 API 配置

用 VS Code 打开它：

1

code ~/.claude/settings.json

填入下面的内容，把三个 xxx 换成你提供商给的实际值：

1
2
3
4
5
6
7
8
9
10
11

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://your-provider.com",
    "ANTHROPIC_AUTH_TOKEN": "sk-xxxxxxxxxxxxxxxxxxxx",
    "ANTHROPIC_MODEL": "anthropic/claude-opus-4.7",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "anthropic/claude-opus-4.7",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "anthropic/claude-sonnet-4.6",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "anthropic/claude-haiku-4.5",
    "CLAUDE_CODE_SUBAGENT_MODEL": "anthropic/claude-haiku-4.5"
  }
}

字段含义：

前提：你的提供商必须直接支持 Anthropic Messages API 格式（路径是 /v1/messages）。市面上常见的 OpenRouter、One-API、New-API、各种自建网关默认都开了这条兼容路径。如果你的提供商只有 OpenAI 格式（/v1/chat/completions），那需要在中间架一层 LiteLLM 之类的转换代理——这超出本文范围，先不展开。

5.3 重启 VS Code，验证

把 VS Code 完全退出（Cmd + Q，不是关窗口），然后从终端重新启动：

1

code .

打开 Claude 插件面板，问一句 “你好”，能正常返回就成了。

6. 一些容易踩的坑

端点路径写错了

ANTHROPIC_BASE_URL 要写到域名级别，例如 https://api.example.com，不要写成 https://api.example.com/v1 或 https://api.example.com/v1/messages。SDK 内部会拼路径，重复拼会变成 /v1/v1/messages 直接 404。

改了配置没生效

VS Code 的窗口进程在启动时读一次环境变量，之后改 settings.json 需要完全退出（Dock 上图标消失）再重开，不只是关窗口。

Key 报 401

先用 curl 直接打你的端点确认 Key 本身是好的：

1
2
3
4
5
6
7
8
9

curl -X POST "$ANTHROPIC_BASE_URL/v1/messages" \
  -H "Content-Type: application/json" \
  -H "x-api-key: $ANTHROPIC_AUTH_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-sonnet-4-6",
    "max_tokens": 64,
    "messages": [{"role": "user", "content": "ping"}]
  }'

anthropic-version 这个头不是日期戳，而是 API 的稳定版本号，官方至今一直就是 2023-06-01，它不会随模型更新而变，照抄就行——真正要跟模型对应着改的是请求体里的 model 字段。

返回正常 JSON，就说明端点和 Key 都没问题，问题在插件配置；返回 401，先去提供商后台核对 Key。

模型名对不上

不同网关给 Claude 模型起的别名不一样——有些用官方 ID（claude-sonnet-4-5），有些自己改名（anthropic/claude-sonnet-4、claude-3.5-sonnet-latest）。报 model not found 时去提供商文档里翻一下它支持的模型列表，把 ANTHROPIC_MODEL 换成对应名字。

小结

整套流程下来，本机就有了：

• 走清华源的 Homebrew，装包不再卡。
• 走 npmmirror 的 Node.js / npm，未来要装 JS 工具链都顺。
• 官网下载安装的 VS Code，更新最及时。
• 手动装好的 Claude Code 插件，靠用户级 ~/.claude/settings.json 接到自定义 API。

整套配置不污染全局 shell 环境，换台机器把 ~/.claude/settings.json 拷过去就能继续用。

存储 benchmark 的几个层级

graph TB  L1[块设备 / RAW<br/>fio / iozone]  L2[文件系统<br/>fio + ext4/xfs/zfs]  L3[NAS / 网络文件<br/>SPECsfs / fio over NFS]  L4[分布式存储<br/>IO500 / Gluster bench / Ceph bench]  L5[GPUDirect Storage<br/>gdsio / NVIDIA fio plugin]  L1 --> L2 --> L3 --> L4 --> L5

各层关注点不同。测 SSD 性能用 fio 直对块设备；测分布式文件系统用 IO500。

fio —— 块/文件存储基准事实标准

fio 是 Jens Axboe（Linux block layer 作者）写的，块/文件存储测试事实标准。

关键参数

1
2
3
4
5
6
7
8
9
10
11
12

fio \
  --name=test \
  --filename=/dev/nvme0n1 \   # 直接对块设备
  --rw=randread \              # 模式
  --bs=4k \                    # 块大小
  --iodepth=128 \              # 队列深度
  --numjobs=8 \                # 并发线程
  --runtime=300 \              # 持续秒数
  --time_based \
  --group_reporting \
  --ioengine=libaio \          # 引擎（io_uring 也常用）
  --direct=1                    # 绕过 page cache

五个标准 workload

1
2
3
4
5

seq_read：     大块顺序读     → 测带宽 GB/s
seq_write：    大块顺序写     → 测带宽 GB/s
rand_read：    4K 随机读      → 测 IOPS / 延迟
rand_write：   4K 随机写      → 测 IOPS / 延迟（写最痛苦）
70/30 mix：    70% 读 30% 写  → 模拟真实数据库

看哪几个数字

1
2
3
4
5

IOPS：      每秒 IO 操作数
bw：        带宽（MB/s 或 GB/s）
clat avg/95/99/99.9：  完成延迟分布
clat stddev：          延迟抖动（越小越稳）
util：      设备利用率（高 ≠ 满，注意 multipath）

P99/P999 延迟比平均延迟更重要——用户感知的是”慢请求的尾巴”。

一些经验值

新代次（PCIe Gen5 NVMe）一颗盘 IOPS 已经够干掉传统 RAID 阵列。

跑 fio 的几个坑

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

1. direct=1 必须加
   → 不加 direct，page cache 会让"随机读"变成"内存读"

2. fio 之前 fio --filename=... --rw=write --io_size=400G 预热
   → SSD 没写过的页（trim 状态）读出来很快但是假象

3. 队列深度 iodepth：
   → 单线程 NVMe 测 IOPS 至少 32-128
   → SATA SSD iodepth=32 即可（HBA 队列限制）

4. 多线程 numjobs：
   → 测带宽用 numjobs=多个、bs 大
   → 测 IOPS 用 numjobs=多个、bs=4k

5. runtime 至少 5 分钟
   → SSD 有 SLC cache，开始几秒数字虚高
   → 真实长时持续 IOPS 通常 30-50% 峰值

6. 不要测整盘 100% 容量
   → 写满后 GC 触发，性能崩
   → 留 10-20% OP（over-provisioning）

SPECsfs —— NAS / 文件存储基准

SPEC SFS 2014 / SPECstorage Solution 2020 是 NAS 选型主基准。

1
2
3
4
5
6
7
8
9

4 个 workload pattern：
  SWBUILD     软件构建（小文件密集）
  VDA         视频数据采集（大顺序写）
  EDA         电路设计（混合读写）
  AI_IMAGE    AI 训练数据集（小文件随机读）

指标：
  ops/sec（操作数）
  ORT（Overall Response Time，关键阈值）

NetApp / Pure / IBM / Huawei OceanStor 等存储厂家在 SPEC 官网定期提交结果——是 NAS 招标的硬指标。

IO500 —— 分布式存储榜

IO500 半年度榜单，分布式 / HPC 存储事实尺。

1
2
3
4
5
6
7
8
9
10
11
12
13

工作负载：
  IOR easy / hard：    带宽
  mdtest easy / hard：  元数据
  find：               遍历

子分数：
  Bandwidth + Metadata = IO500 score（GiB/s × kIOPS）

榜单：
  Frontier (ORNL Lustre)：     ~5000 IO500 score
  WekaFS in 多家 site
  GPFS / Spectrum Scale
  Ceph

待补充：2026 年最新 IO500 榜单。

GPU 集群验收里通常会跑 IOR / mdtest 而不是完整 IO500——要的就是带宽和元数据上限。

GPUDirect Storage 基准

GPUDirect Storage (GDS) 让 NVMe 数据直通 GPU 显存，绕开 CPU bounce buffer。

1
2
3

# NVIDIA 自带 gdsio 工具
gdsio -d 0 -D /mnt/wekafs -w 8 -s 1G -i 1024K -I 0 -x 0 -T 60
# -d device, -D dir, -w workers, -s size, -i I/O size, -I direction(read), -T runtime

1
2
3
4

观察：
  GiB/s：           直通带宽
  CPU 利用率：       应该接近 0（成功 bypass）
  HBM 占用：         数据应该出现在 GPU 显存

1
2

传统路径：     SSD → DMA → CPU RAM → PCIe → GPU HBM    （瓶颈：CPU bounce + PCIe 一圈）
GDS：         SSD → DMA → PCIe → GPU HBM             （直接，~3-5× 带宽）

LLM checkpoint / dataloader 用 GDS 显著提升——这就是为什么 WekaFS / DDN / VAST 等 AI 存储厂商都强调 GDS 认证。

网络基准

iperf / iperf3 —— TCP/UDP 吞吐

1
2
3
4
5
6

# 服务端
iperf3 -s

# 客户端
iperf3 -c <server_ip> -t 60 -P 8 -O 5
# -t 60s, -P 8 并发流, -O 5 omit 前 5s 预热

1
2
3
4

观察：
  GBits/sec：    总吞吐
  Retransmits：  重传（网络丢包指标）
  RTT：          基础延迟

qperf / netperf —— 延迟 + 吞吐综合

1
2
3
4
5

# qperf 服务端
qperf

# 客户端
qperf <server> -t 30 tcp_bw tcp_lat

netperf 更老牌，cloud 自己测试常用。

ib_write_bw / ib_read_bw / ib_send_lat —— InfiniBand RDMA

perftest 套件：

1
2
3
4
5

# 服务端
ib_write_bw -d mlx5_0 -F

# 客户端
ib_write_bw -d mlx5_0 -F <server_ip> --report_gbits

1
2
3
4
5

ib_write_bw：    单向 RDMA Write 带宽
ib_read_bw：     单向 RDMA Read 带宽（通常稍低于 Write）
ib_send_bw：     SEND 操作带宽
ib_write_lat：   单向 RDMA Write 延迟
ib_send_lat：    SEND 延迟

1
2
3
4
5
6
7

NDR 400G InfiniBand 单端口 期望：
  ib_write_bw：    ≈ 380-395 Gbit/s（理论 400G 的 ~95%）
  ib_write_lat：   < 1 μs（机内）
  
跨柜（OSFP 光缆 + Quantum-2 交换机）：
  ib_write_bw：    ≈ 360-390 Gbit/s
  ib_write_lat：   ~2-5 μs

低于这个数就要排查 cable / FEC / GPU NUMA / firmware。

NCCL-tests —— 集合通信

GPU 集群验收必跑。NVIDIA SA 视图里：

关键指标：

1
2

busbw (bus bandwidth)：考虑算法因子后的"真实"带宽，跨规模可比
algbw (algorithm bandwidth)：原始数据量 / 时间

1
2
3
4
5
6
7

# 单机 8 卡
all_reduce_perf -b 1G -e 16G -f 2 -g 8

# 多机（结合 mpirun + slurm）
mpirun -np 64 -hostfile hosts.txt \
  -x NCCL_DEBUG=INFO -x NCCL_IB_HCA=mlx5_0,mlx5_1 \
  all_reduce_perf -b 1G -e 16G -f 2

常用环境变量：

1
2
3
4
5

NCCL_IB_HCA       指定 HCA
NCCL_TESTS_SPLIT  拆分通信器
NCCL_ALGO         算法（Tree / Ring）
NCCL_PROTO        协议（Simple / LL / LL128）
NCCL_DEBUG=INFO   排障

busbw 期望值（H100 / B200 单机 8 GPU）

1
2
3
4

H100 SXM5 8 GPU AllReduce busbw：    ~370-400 GB/s（NVLink 4 域内）
B200 SXM5 8 GPU AllReduce busbw：    ~700-900 GB/s（NVLink 5 域内）
NVL72 72 GPU AllReduce busbw：       ~700-900 GB/s（NVLink 5，72-domain）
跨节点 8节点 H100 over IB NDR：       ~80-100 GB/s（IB 限制）

低于这个值优先排查：

1
2
3
4
5

1. NVLink 拓扑（nvidia-smi topo -m）
2. PCIe Gen5 x16 是否 lane 全开
3. NCCL_TOPO_FILE / NCCL_GRAPH_FILE 是否被错误使用
4. NUMA binding（mpirun 加 PE=12 / map-by 等）
5. ATS / PCIe ACS 是否关闭

SHARP —— InfiniBand 内 in-network compute

NVIDIA Quantum-2 / Quantum-3 交换机支持 SHARPv3：AllReduce 在交换机内完成，减少 NIC 流量。

1
2
3
4
5
6
7
8

普通 RDMA AllReduce：
  每节点把数据通过 NIC → 交换机 → NIC 给其他节点 → 累加
  N 节点 = N 倍流量
  
SHARP：
  数据进交换机后在芯片内累加，结果广播回去
  N 节点 ≈ 2 倍流量
  → 大规模 AllReduce 性能跃升

跑 NCCL-tests 时打 NCCL_COLLNET_ENABLE=1 启用 SHARP 路径。

一张速查

一些验收脚本骨架

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 节点级（单机）
fio --name=4krand --filename=/dev/nvme0n1 \
    --rw=randread --bs=4k --iodepth=128 --numjobs=8 \
    --runtime=300 --time_based --direct=1 --group_reporting

iperf3 -c $NEIGHBOR -t 60 -P 8

ib_write_bw -d mlx5_0 -F $NEIGHBOR --report_gbits

# 单机 8 卡 collective
all_reduce_perf -b 1G -e 16G -f 2 -g 8

# 多机（slurm）
sbatch nccl_test.slurm    # 内含 mpirun + all_reduce_perf 多 size

小结

• 存储 benchmark 用 fio 是事实标准，必须 direct=1、足够队列深度、足够时长
• NAS 看 SPECsfs，分布式存储看 IO500
• 网络 TCP 用 iperf3，RDMA 用 perftest 套件，集合通信用 nccl-tests
• ib_write_bw 应跑到端口理论的 ~95%，低于 90% 就要排查
• NVLink 域内 AllReduce busbw 是 GPU 集群验收最重要数字
• SHARP 让 InfiniBand 大规模 AllReduce 翻倍快

下一篇讲 AI 基准——MLPerf、cuBLASMatmulBench、nvbandwidth、NeMo 烧机。

TOP500 用什么标尺

1
2
3

TOP500 自 1993 年起，每年 6 月（ISC）/ 11 月（SC）发布
排名标尺：HPL Linpack（FP64 LU 分解 GFLOPS）
HPL 2.0 规范 2008 年定稿，沿用至今

TOP500 创始人之一的田纳西大学教授 Jack Dongarra 认为 Linpack 性能已经过时，大家也意识到单看 CPU 性能的弊端，开始使用 HPCG（The High Performance Conjugate Gradients）性能来全面衡量超算性能。Linpack 更考验超算的处理器理论性能，而 HPCG 更看重实际性能，对内存系统、网络延迟要求也更高。

HPL —— Linpack 怎么跑

HPL 解一个 N×N 稠密线性方程组（双精度）。计算量 ≈ 2/3 N³ + 2 N²。

GPU 时代用 NVIDIA 优化版的 HPL（容器名 nvcr.io/nvidia/hpc-benchmarks），底层调 cuBLAS / NCCL。

关键参数 HPL.dat

按 NVIDIA SA benchmark 实战经验：

1. N（矩阵规模 / Problem Size）

1
2
3
4
5
6
7

原则：填满所有 GPU 显存（85-92%）
公式：显存占用 (Bytes) = N² × 8（FP64）

单机 8× A100 80GB（总 640 GB）：
  N ≈ √(640 × 1024^3 × 0.9 / 8) ≈ 268,328
  
注意：N 必须是 NB 的整数倍。

2. NB（数据块大小 / Block Size）

1
2
3

现代 NVIDIA GPU 推荐 NB 远大于传统 CPU 的设定
A100 / H100 / H200：    2048、3840、4096
B200 / B300：           尝试 2048-4096，跑几个值取最高

3. P × Q（进程网格）

1
2
3
4
5
6
7

P × Q = 总 MPI 进程数 = 总 GPU 数
P ≤ Q 且尽量接近正方形（或 P 是 Q 的一半）
避免 1×8 这种极度狭长

单机 8 卡：       P=2, Q=4
4×8=32 卡：      P=4, Q=8
NVL72：         P=8, Q=9

其他

1
2
3

PMAP：     1 (Row-major) 或 0 (Column-major)，NVIDIA 优化版脚本通常自动管理
BCAST：    广播算法，尝试 1 或 2
DEPTH：    Look-ahead 深度，GPU 上通常 0 或 1

跑分目标

1
2
3
4

HPL 效率 = 实测 GFLOPS / 理论峰值 GFLOPS
单机 8× A100 / H100：典型 70-80%
NVL72：             典型 65-75%（受 NVLink + IB 影响）
万卡集群：           典型 55-70%

低于 60% 一般有问题——下面是典型排查路径。

调优排查（来自 NVIDIA SA 实战 guide）

问题 1：性能远低于理论峰值（效率 < 60%）

1
2
3
4
5
6
7
8
9
10
11
12
13

原因：显存未充分利用
  → 增大 N，逼近 OOM 临界点（90% 显存利用）

原因：降频
  → sudo nvidia-smi -pm 1            # 持久模式
  → sudo nvidia-smi -lgc <Max_Clock> # 锁最高加速频率

原因：NUMA 拓扑绑定不当
  → MPI 启动加 NUMA binding 参数
  → 用 NVIDIA bind.sh 等脚本，确保 GPU 分到最近的 CPU 物理核

原因：P/Q 不合理
  → 交换 P 和 Q 的值，调整比例

问题 2：多节点扩展性极差

1
2
3
4
5
6
7
8
9
10

原因：InfiniBand/RoCE 未全速运行
  → ib_write_bw 测试节点间 RDMA 是否达标

原因：GPUDirect RDMA 未生效
  → lsmod | grep nv_peer_mem
  → 没加载会经 CPU 内存回环，延迟暴涨

原因：NCCL 调优
  → NCCL_IB_HCA 指定 HCA
  → NCCL_DEBUG=INFO 查看实际链路

HPCG —— “真实性能”基准

1
2
3
4
5

[HPCG](https://www.hpcg-benchmark.org/) 每半年发布榜单
求解 SpMV（稀疏矩阵向量乘）+ 多重网格预条件
对内存带宽、延迟、网络通信极度敏感
   
HPCG 性能通常 = HPL 性能的 1-3%

为什么 HPCG”低得多”？

1
2
3
4
5
6
7
8

HPL：稠密 BLAS-3 操作，几乎都是 GEMM
   → 计算密度高，HBM/cache 复用极好
   → GPU Tensor Core 不能用（只支持 FP16+）但 FP64 cuBLAS 已经很优

HPCG：稀疏访存为主
   → memory-bound，HBM 带宽决定上限
   → 内存延迟、网络延迟一一暴露
   → 真实科学计算更像 HPCG

跑 HPCG 时 GPU 利用率（nvidia-smi 看）只有 30-50%——这不是 bug，是 workload 性质决定。

历史事件

1
2
3
4
5

天河 2 号之前是 HPCG 性能第一名
2016 上半年：     中国天河 2 号第一，日本 K 第二
2016 下半年起：   日本 K 超算夺第一（K 超算在 TOP500 排名第七）
富岳（Fugaku）：   2020 年起 HPCG 长期第一
                 富岳 HPCG ~16 PFLOPS（vs Linpack 442 PFLOPS）

待补充：2026 年最新 HPCG 榜单数据。

HPL-MxP —— 混合精度 HPL

1
2
3
4

[HPL-MxP](https://hpl-mxp.org/) 原名 HPL-AI（2019 年）
用 FP16/FP32 做主体计算，FP64 修正
利用 Tensor Core 大幅加速
针对 LU 分解的迭代细化方法

为什么需要 HPL-MxP？

1
2
3
4
5
6
7
8
9

HPL 只能用 FP64 cuBLAS
  → V100 起 FP64 算力远低于 Tensor Core 算力
  → H100 FP64 67 TFLOPS vs Tensor FP16 1979 TFLOPS（相差 30×）
  → "大半算力闲着"

HPL-MxP：
  主迭代用 FP16/BF16 Tensor Core 算
  最后用 FP64 修正残差到精度
  → 能跑出 5-10× 于纯 FP64 HPL 的成绩

NVIDIA SA 集群验收里 HPL 和 HPL-MxP 都会跑——前者是历史延续可比，后者是真实 AI/HPC 混合负载的体现。

1
2
3
4

2024-11 HPL-MxP 榜单 TOP（参考）：
  Frontier (MI250X)：       11.4 EFLOPS（混合精度）
  Aurora：                  10.6 EFLOPS
  El Capitan：              16.7 EFLOPS（最新提交）

待补充：2026 年 HPL-MxP 最新数据。

NVL72 / NVL576 上跑 HPL

NVIDIA 在 GB-NVL72 / HGX B200/B300 都有官方 step-by-step benchmark guide（NDA / Partner，公开版可在 docs.nvidia.com 检索 DGX/HGX benchmark guide）。

1
2
3
4
5
6

典型流程：
1. 节点 prep：DCGM diag、nvbandwidth、cublasMatmulBench
2. 单机 HPL：8 卡 / 节点
3. 多机扩展：rail-optimized IB + NCCL-tests 通过
4. NVL72 整柜 HPL（72 GPU 单 NVLink domain）
5. HPL-MxP 跑 Tensor Core

NVL72 整柜 HPL 要求所有 72 GPU 在同一个 NVLink domain 内一次跑过——这是 GB200 NVL72 区别于”8 节点 HGX H100 + IB”的本质：72 GPU 之间 collective 走 NVLink，HPL 多节点扩展性损失更小。

Green500 —— 能效榜

Green500 与 TOP500 同源：

1
2
3

排名标尺：HPL GFLOPS / Watt
2024-11 第一：JEDI（NVIDIA H100 + Grace）≈ 72 GFLOPS/W
2024-11 富岳：约 14 GFLOPS/W

GPU 集群通常 60-72 GFLOPS/W，纯 CPU 集群 10-20 GFLOPS/W——HPC 已经实质 GPU 化。

HPC 三张榜怎么选

1
2
3
4
5
6
7
8

HPL：     "我家硬件 FP64 峰值多少"——历史延续，TOP500 主榜
HPCG：    "我家硬件真实跑多少"——内存/网络瓶颈
HPL-MxP：  "我家硬件 AI 友好场景多少"——Tensor Core 时代
Green500： "我家硬件能效如何"——TCO 视角

HPC 中心日常：       三张榜都看
GPU 集群验收：       HPL + HPL-MxP 必跑，HPCG 选跑
AI 集群验收：        HPL-MxP / NCCL-tests / MLPerf

一些命令与文档

1
2
3
4
5
6
7
8
9
10
11

# NVIDIA hpc-benchmarks 容器（HPL/HPL-MxP/HPCG）
docker run --gpus all --rm -it \
  -v $PWD:/workspace \
  nvcr.io/nvidia/hpc-benchmarks:24.09 bash

# 容器内跑 HPL
mpirun -np 8 --map-by node:PE=12 \
  ./hpl.sh --dat HPL.dat

# 跑 HPL-MxP（NVIDIA 容器自带）
./hpl-mxp.sh --m=2048 --n=2048 ...

1
2
3
4

查 TOP500：       https://www.top500.org/
查 HPCG：         https://www.hpcg-benchmark.org/
查 Green500：     https://www.top500.org/lists/green500/
NVIDIA HPC bench：https://docs.nvidia.com/ → DGX/HGX Benchmark Guide

一张速查

小结

• HPL（Linpack）测 FP64 峰值，TOP500 标尺，效率 65-80% 算合格
• HPCG 测真实场景，性能通常是 HPL 的 1-3%
• HPL-MxP 用 Tensor Core 跑混合精度，AI 时代的”新 HPL”
• 跑 HPL 关键三参数 N / NB / P×Q，效率低主排查显存、降频、NUMA、IB
• Green500 看能效，GPU 集群比 CPU 集群高 5-10×

下一篇讲存储与网络 benchmark——fio / iperf / ib_write_bw / SPECsfs 实战。

SPEC CPU2017 ——CPU 性能的事实标尺

SPEC CPU 2017 2017 年发布，取代 2006 版。今天数据中心 CPU datasheet 几乎都用它。

四个子套件

graph TB  ROOT[SPEC CPU 2017]  ROOT --> SR[SPECrate<br/>多任务并行<br/>测吞吐]  ROOT --> SS[SPECspeed<br/>单任务<br/>测响应时间]  SR --> SRINT[SPECrate Integer<br/>10 个整数程序]  SR --> SRFP[SPECrate Floating Point<br/>13 个浮点程序]  SS --> SSINT[SPECspeed Integer<br/>10 个整数程序]  SS --> SSFP[SPECspeed Floating Point<br/>10 个浮点程序]

实际报告里看到的几个常用名字：

1
2
3
4

SPECrate2017_int_base / _peak    多核整数吞吐
SPECrate2017_fp_base  / _peak    多核浮点吞吐
SPECspeed2017_int_base/peak      单线程整数响应时间
SPECspeed2017_fp_base /peak      单线程浮点响应时间

base 用规定编译选项（公平比较），peak 允许厂家激进优化（看上限）。真实采购看 base。

怎么读 SPECrate

1
2
3
4
5
6

某 2-socket 服务器 SPECrate2017_int_base = 800
代表：在 2 socket × 64 core × 2 SMT = 256 线程上
      跑 10 个整数 workload 的几何平均吞吐 = 基准的 800 倍

→ 比对 base 越高越快
→ 单核数字 = 800 ÷ 256 ≈ 3.1（"线程效率"参考）

注意：单核高 ≠ 总吞吐高，反之亦然。Intel Xeon SP / AMD EPYC / Ampere AmpereOne 等都有自己 sweet spot——选型时分清自己的 workload 是 throughput-bound 还是 latency-bound。

SPEC CPU 看哪几列

读 SPEC CPU 报告（每条 SUT 一份 PDF + HTML）时关键列：

比较时一定保证：编译器版本、HT 开关、Power Profile 一致——否则结果不可比。

国内查 CPU 性能时的常见情况

1
2
3
4
5
6
7
8
9

1. 国产 CPU 厂家通常给 SPEC CPU 2006（旧版）数字
   → 不能直接和 Intel/AMD 的 2017 数字比
   → 需要换算（一般 2006 → 2017 大致 0.5-0.6× 缩放，参考意义）

2. ARM Server CPU（鲲鹏 920、AmpereOne）
   → 编译器要支持 SVE/NEON，不然性能掉一半

3. RISC-V Server CPU（少量）
   → 公开 SPEC CPU 数字仍稀缺

待补充：鲲鹏 920 / 海光 / AmpereOne 在 SPEC CPU2017 base 公开数字。

SPECpower：能效

SPECpower_ssj2008 测的是”性能 / 瓦”——服务器能效之标尺。

1
2
3
4

ssj_ops（操作/秒）/ Watt
从 100% 负载逐档降到 0%（idle）
用 PTDaemon 同步采集功率
最终一个综合分数：overall ssj_ops/W

数据中心选型 TCO 模型几乎都引用 SPECpower 数字——电费占数据中心 OPEX 30-40%，能效高 10% 一年省几百万电费。

SPECjbb 2015：Java 中间件

jbb 全称 Java Business Benchmark。模拟 ERP / 中间件场景：

1
2
3

multi-JVM、多线程、java heap 几十 GB
随机请求、模拟订单/库存/客户
指标：max-jOPS（最大吞吐）/ critical-jOPS（带 SLA 约束的吞吐）

SPECjbb 2015 是 OLAP-like Java 服务器选型主流尺——金融、电信、政府常用。新版还在持续维护，比退役的 SPEC Web2005 时效性强。

TPC-C —— OLTP 经典

TPC 系列里最经典：模拟电商订单系统。

1
2
3
4

仓库（Warehouse）数 W
订单生成（New-Order）每分钟数 = tpmC
要求 90% 事务在 5s 内完成、ACID 一致性
价格披露 → $ / tpmC

20 世纪 90 年代，TPC（事务处理性能委员会）成立，Benchmark（基准测试）随之走上历史舞台。tpmC 值在国内外被广泛用于衡量计算机系统的事务处理能力，为”每分钟内系统处理新订单个数”的英文缩写。TPMC 测试及发布的成本极高（百万美元级），只有少数厂商的少数设备会在 TPC 官网上发布测试数据。未在官网上发布的数据都是评估出来的。

历史里程碑

1
2
3

2010 IBM Power 780：           10 M tpmC
2013 Oracle SuperCluster：     30 M tpmC
2017+ Oracle Exadata：         50-100 M tpmC（云超大配置）

tpmC 在 2026 年的位置

正式 TPC-C 提交几乎已停滞——发布门槛太高、云时代少有厂家愿意花钱跑。国内合同里”要求 X 万 tpmC”基本是评估值，不是 TPC 官网真实发布。

1
2
3
4

评估方法：
  根据 SPEC CPU 数字 + 内存 / 存储配置
  按经验公式估算 tpmC
  → 数字接近 TPC-C 官网早年的同档系统

国采、国企招标里仍把 tpmC 作”硬指标”，但实际意义不如 HammerDB 真跑一遍。

HammerDB / sysbench —— 现代 OLTP 测试事实标准

正式 TPC-C 太贵 → 业界用开源工具跑”TPC-C-like” workload：

graph LR  HDB[HammerDB<br/>开源, GUI/CLI]  SB[sysbench<br/>开源, CLI]  HDB --> ORACLE[Oracle / MySQL / PG / MS SQL / Db2]  SB --> MYSQL[MySQL / PostgreSQL / TiDB]

HammerDB 实现了 TPROC-C（TPC-C 风格）和 TPROC-H（TPC-H 风格），跑出来的指标叫 NOPM（new orders per minute），和 tpmC 同含义但不发布到 TPC 官网。

实操要点

1
2
3
4
5

仓库数（warehouse）：       至少 100，实测最好 500-2000（避免被单仓库锁住）
虚拟用户数（vuser）：       从 1 ramp 到 max，看曲线
预热时间：                  5-10 min
持续时间：                  至少 10-20 min
观察指标：                  NOPM, TPM, P99 延迟

1
2
3
4
5
6
7

典型对比：
  Intel Xeon 8480C 2-socket + 1.5TB RAM + NVMe + Oracle 19c
    → HammerDB NOPM ≈ 8-12 M
  AMD EPYC 9654 2-socket 同配置
    → NOPM ≈ 10-15 M
  鲲鹏 920 2-socket + openGauss
    → NOPM ≈ 4-7 M

待补充：上面数字仅作量级参考，具体看实际配置和调优。

TPC-H / TPC-DS —— 数据仓库 / 大数据

1
2
3

TPC-H：     22 个复杂分析查询，scale factor 1GB-100TB
TPC-DS：    99 个查询，更接近真实数仓 / BI workload
指标：      QphH@SF（每小时查询数 × scale factor）

云时代 TPC-DS 比 TPC-H 更主流——特别是 数据湖 / Spark / Presto / Trino / ClickHouse 都用 TPC-DS 自我对标。

选型场景

1
2
3
4

单机数据库（Oracle/Db2/MySQL/PG）：HammerDB TPROC-H
分布式数仓（GreenPlum/TiDB/StarRocks/Doris）：TPC-DS @SF1000-10000
云数仓（Snowflake/BigQuery/Redshift）：TPC-DS 公开 benchmarks
湖仓（Iceberg/Hudi/Delta + Trino/Spark）：TPC-DS 是"事实公约数"

数据库基准的真相 —— “选型不能只看 benchmark”

数据库性能受实际数据分布影响巨大：

1
2
3
4

benchmark：    数据均匀生成、查询模板固定、并发可控
生产：         数据极度不均、热点 key、查询千差万别、并发峰谷波动
              → benchmark 跑得好，生产可能跑不动
              → benchmark 跑得一般，生产可能反而合适

成熟做法：

1
2
3
4

1. 先跑标准 benchmark 排除明显短板
2. 用真实业务数据做"冒烟测试"（部分库 dump）
3. 用真实查询日志重放
4. 再做 POC（4-8 周生产试运行）

没有 POC 就不敢决定数据库选型——这是 DBA 圈的共识。

CPU + 数据库选型时的几条经验

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

1. SPECrate2017_int_base 反映"多核吞吐"
   → 数据库 / 中间件场景看它最直接
   
2. SPECspeed 反映"单线程响应"
   → CPU-bound 单线程 task（数据库 query 优化器、序列化）看它

3. SPECpower 反映"性能/瓦"
   → 算 TCO 时核心，3 年电费可能比硬件贵

4. SPECjbb 反映"Java 中间件"
   → Java 应用服务器（WebSphere/JBoss/Tomcat）选型直接对应

5. tpmC 在国内合同里仍存在但实际意义有限
   → 真要测 OLTP，HammerDB 是事实标准

6. CPU 频率 ≠ 性能
   → 看微架构代次（Intel 5/6 代、AMD Zen4/5、ARMv9）+ 内存通道 + AVX/SVE 支持

7. NUMA 拓扑必影响数据库性能
   → 单 socket > 双 socket（少量 workload，看场景）
   → 可以用 numactl 绑核做对照测试

一些命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

# Linux 看 CPU
lscpu                           # 拓扑 / 频率 / NUMA / flag
cat /proc/cpuinfo | head -50    # 详细
numactl --hardware              # NUMA 详情

# 单核基准（速测）
sysbench cpu --threads=1 --cpu-max-prime=20000 run

# 多核基准
sysbench cpu --threads=$(nproc) --cpu-max-prime=20000 run

# 内存带宽
sysbench memory --memory-block-size=1M --memory-total-size=10G run
mbw 1024                        # 简易内存带宽

# OLTP 快速测试（MySQL）
sysbench oltp_read_write --tables=10 --table-size=1000000 \
  --mysql-host=127.0.0.1 --mysql-user=root \
  --threads=64 --time=120 run

# HammerDB CLI（TPROC-C）
hammerdbcli auto bm-tprocc-pg.tcl    # 全脚本驱动

一张速查

小结

• SPEC CPU2017 是 CPU 通用计算的事实标尺，看 base、看 rate vs speed
• SPECpower / SPECjbb / SPECstorage 各有领域
• TPC-C / tpmC 在合同里仍重要，实际选型用 HammerDB / sysbench
• 数据库选型不能只看 benchmark，必须 POC 真实数据
• 看曲线、看 P99、看长时间持续，不只看峰值

下一篇专题讲 HPC 基准——HPL、HPCG 与 TOP500 的实战。

为什么需要基准测试

服务器场景里，”快”是个多维概念：

1
2
3
4
5

CPU 整数运算 vs 浮点运算 vs 内存带宽 vs 数据库 TPM
存储 顺序读 vs 随机写 vs 队列深度 vs 延迟
网络 带宽 vs 延迟 vs P99 抖动 vs 集合通信
GPU 单精度 vs Tensor FP16 vs FP8 vs FP4
集群 单卡持续 vs 万卡 AllReduce vs 真实训练 token/s

不同 workload 看不同维度。”用谁的数据当尺“决定了选型结果——这就是为什么 30 多年来工业界形成了一系列第三方公认的基准组织。

两大主流基准体系

graph TB  ROOT[服务器基准测试两大体系]  ROOT --> TPC[TPC<br/>事务处理性能委员会<br/>1988 成立]  ROOT --> SPEC[SPEC<br/>标准性能评估机构<br/>1988 成立]  TPC --> TPCC[TPC-C<br/>OLTP 经典]  TPC --> TPCH[TPC-H<br/>决策支持/分析]  TPC --> TPCDS[TPC-DS<br/>大数据分析]  TPC --> TPCx[TPCx-AI / TPCx-HS<br/>AI 与 Hadoop]  SPEC --> SPECCPU[SPEC CPU<br/>处理器整数/浮点]  SPEC --> SPECjbb[SPEC jbb<br/>Java 中间件]  SPEC --> SPECpower[SPECpower<br/>能效]  SPEC --> SPECstorage[SPEC SFS<br/>NAS 文件存储]  SPEC --> SPECMLPerf[SPECaccel /<br/>SPEChpc]

TPC（Transaction Processing Performance Council）：1988 年成立，主战场是数据库 / OLTP / 数据分析。代表测试：TPC-C（OLTP）、TPC-H（决策支持）、TPC-DS（大数据）。tpmC 这个国内常听到的”每分钟事务数”就是 TPC-C 的指标。

SPEC（Standard Performance Evaluation Corporation）：同样 1988 年成立，覆盖更广——CPU、Java 中间件、Web 服务、能效、存储、HPC、ML。SPEC CPU2017 是当前 CPU 性能 datasheet 的事实标尺。

两家都是非营利第三方，结果必须在官网发布才算数——这是第三方背书的核心价值。

按 workload 分类的基准

整理一张实战中真正会用到的”benchmark 全景”：

注意：TPC-W（Web）、SPEC Web2005 等测试在云时代基本退役——因为现实业务的 Web 服务太复杂，单一 benchmark 失去意义。

基准结果”怎么读”

基准报告里常见的几个指标维度：

1
2
3
4
5
6

绝对值：     TFLOPS / TPM / IOPS / token-per-sec
单位价格：   $ / TPM、$ / TFLOPS
单位功耗：   TPM / W、TFLOPS / W
百分位延迟： P50 / P90 / P99 / P999
扩展性：     N 节点时性能 / 单节点性能（理想 = N）
持续 vs 峰值：burst 能跑多高、稳定能跑多久

只看绝对值容易被销售带偏——真正成熟的采购方看 $/TPM、性能/瓦、扩展性曲线。

一份典型 benchmark 报告应有什么

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

1. 系统配置（SUT, System Under Test）
   - CPU 型号 / 核数 / 频率
   - 内存容量 / 通道 / DIMM 频率
   - 存储介质 / RAID / 文件系统
   - 网络型号 / 交换机
   - GPU 型号 / NVLink 拓扑（AI 场景）
   - OS / kernel / 驱动 / 微码版本
2. 软件栈
   - 编译器 / 优化等级 / BLAS 库版本
   - DBMS 版本 / 应用版本
3. 测试方法
   - 数据集大小 / scale factor
   - 预热 / 持续时间 / 重复次数
4. 结果
   - 主指标 + 次要指标
   - 性能曲线（不只单点）
5. 价格披露（TPC 强制）
6. 能效披露（SPECpower / 部分 TPC）

TPC 报告强制披露完整 SUT + 价格——这是为什么 TPC-C 报告动辄上百页 PDF。SPEC 也要求公开 config，但价格披露不是强制。

测试结果”为什么会差很多”

同一颗 CPU、同一种 benchmark，不同厂商提交结果可能差 1.5-3×：

1
2
3
4
5
6
7

编译器选项：     -O3 vs -O2，AVX-512 开关，PGO/LTO
内存配置：       通道数、DIMM rank、是否 1DPC
NUMA 绑定：      自动 vs 手工 numactl
BIOS 设置：      Turbo / SMT / power profile / prefetch
OS tuning：     transparent hugepage、cpu governor、swappiness
存储调优：       I/O scheduler、queue depth、direct IO
网络调优：       MTU、RSS、IRQ affinity、DCQCN

这些”调优”在销售文档里通常一笔带过，但实际上决定了结果的可比性。所以读 benchmark 报告时，配置详情比绝对数字更重要。

TOP500：HPC 的”奥运会”

每年 6 月 / 11 月发布两次的 TOP500，是世界上最大公开 HPC 系统排行榜：

• 排名标尺：HPL Linpack（FP64 峰值 LU 分解）
• 1993 年开始，已经 30 多年
• 中国曾长期占榜单一半以上份额，2020 年后受出口管制影响数量下降

1
2
3
4
5
6

2024-11 榜单 TOP 5（参考）：
  El Capitan (LLNL, AMD MI300A)：       1742 PFLOPS
  Frontier (ORNL, AMD MI250X)：         1353 PFLOPS
  Aurora (ANL, Intel Ponte Vecchio)：    1012 PFLOPS  
  Eagle (Microsoft Azure, NVIDIA H100)：561 PFLOPS
  富岳 (RIKEN, A64FX)：                 442 PFLOPS

待补充：TOP500 最新 2026 年榜单数据。

但Linpack 早就被 HPCG 补充——后者更看重真实工作负载（内存、网络、不规则访存）。Jack Dongarra（TOP500 创始人之一）2014 年就推动 HPCG 排行榜：HPCG 性能通常是 Linpack 性能的 1-3%。

MLPerf：AI 时代的新基准

MLCommons 维护，2018 年起步，AI 算力的”事实标准”：

graph LR  ML[MLCommons MLPerf]  ML --> T[Training<br/>训练]  ML --> I[Inference<br/>推理]  ML --> H[HPC<br/>科学计算]  ML --> S[Storage<br/>存储吞吐]  ML --> P[Power<br/>能效]  ML --> C[Client / Mobile / Tiny<br/>端侧]

每轮提交分 Closed（严格规则、可比性强）和 Open（自由优化、展示创新）。NVIDIA / Google / Intel / AMD / Huawei 等都按轮次提交。

07-Benchmark 目录里 NVIDIA SA 视角的视图：

NVIDIA 通常以 DGX/HGX/GB200 系统提交 MLPerf；详细工程报告在 NVIDIA blog 与 GitHub repo nvidia/MLPerf*，复现工件包含 NeMo / Megatron / TensorRT-LLM 等。

后面的 05-AI 基准测试 专门展开。

专用 / 厂家 benchmark

除两大公开体系外，还有大量”专用基准”：

1
2
3
4
5
6

Oracle / SAP：   厂家自己的 ERP/数据库 benchmark
SAP SD：        销售-分销模块用户数（SAP 标尺）
TPC-H 变体：    实际生产中常被改成 sysbench-tpch
LLM 专用：      lm-evaluation-harness 等评测精度
推理服务：      vLLM benchmark / Triton perf_analyzer
NVIDIA NCCL-tests：集合通信 SoTA 工具

这些不一定上 TPC / SPEC 官网，但在自家生态里是实际选型依据。

实战中”benchmark 怎么用”

数据中心采购或集群验收时，benchmark 一般分三阶段：

graph TB  L1[1. 节点级<br/>HPL / SPEC CPU / fio / iperf<br/>验证单机硬件]  L2[2. 机柜 / Pod 级<br/>NCCL-tests / SHARP / RDMA<br/>验证互联与路由]  L3[3. 应用级<br/>NeMo / Megatron / vLLM / 真实业务<br/>验证端到端]  L1 --> L2 --> L3

NVIDIA SA 内部就是用这三层做集群验收（详见 05-AI 基准测试 ）。每一层都不能跳——单机过了不代表集群过；集群通了不代表大模型训练 MFU 就达标。

一些避坑

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

1. 看绝对值不看 config：
   "我看 SPEC CPU 2017 排名厂商 A 比 B 高 5%"
   实际 A 用 96 GB DDR5-5600 + AVX-512、B 用 256 GB DDR5-4800 关 SMT
   → 没法比

2. 看单点不看曲线：
   "厂家说 IOPS 1000K"
   实际 P99 延迟 50ms，业务无法接受
   → 看 P99/P999 比看峰值有意义

3. 跑短时间不跑长时间：
   GPU 头 5 min 全 turbo，30 min 后 thermal throttle
   → 至少跑 30-60 min 看持续值

4. 不公开复现脚本：
   厂家 demo 一套，客户复现完全不是这数
   → 索要完整 reproduce 脚本和参数

5. 偷换 benchmark 版本：
   比 SPEC CPU2006（已退役）和 SPEC CPU2017 数字
   → 完全不可比

第九章会展开什么

小结

• 基准测试是把”datasheet 数字”翻译成”业务性能”的桥
• 两大体系 TPC（事务）+ SPEC（计算/能效）；HPC 看 TOP500 / HPL；AI 看 MLPerf
• 报告必看 SUT 配置 + 软件栈 + 调优参数，不能只看绝对值
• 集群验收三阶段：节点级 → 机柜级 → 应用级
• 避坑：看曲线、看 P99、看持续值、要可复现

下一篇展开 CPU & 数据库基准——SPEC CPU 怎么读、tpmC 怎么算、HammerDB 怎么用。