服务器基础知识全解

基准测试与认证的实战收口 —— 第九章小结

2026-05-23T11:45:00.000Z

第九章前面 6 篇分别讲了 benchmark 概览、CPU/数据库基准、HPC、存储/网络、AI、认证。本篇收口，也是全书的最后一篇。

选 benchmark 的”四层决策”

graph TD  Q1[第 1 层: 业务类型?]  Q1 --> Q2[第 2 层: 验收阶段?]  Q2 --> Q3[第 3 层: 报告读者?]  Q3 --> Q4[第 4 层: 时长 / 预算?]  Q4 --> A[最终 benchmark 组合]

第 1 层：业务类型

通用计算 / Web / 应用：    SPEC CPU2017 + SPECjbb 2015
数据库（OLTP）：          HammerDB TPROC-C / sysbench oltp
数据库（OLAP）：          TPC-DS / HammerDB TPROC-H
HPC（FP64）：           HPL + HPCG
AI 训练：               HPL-MxP + NCCL-tests + MLPerf Training + NeMo burn-in
AI 推理：               cublasMatmulBench + vLLM/TRT-LLM bench + MLPerf Inference
存储（块）：              fio
存储（NAS）：            SPECstorage SFS 2020
存储（分布式 / HPC）：    IO500 / IOR / mdtest
网络（TCP）：            iperf3
网络（RDMA）：           perftest 套件（ib_write_bw 等）

第 2 层：验收阶段

研发选型 / POC：       SPEC CPU2017 + 业务模拟
集群验收（节点）：      DCGM diag + nvbandwidth + cublasMatmulBench + HPL
集群验收（机柜）：      NCCL-tests + ClusterKit + SHARP
集群验收（应用）：      NeMo / Megatron 24-72h burn-in
生产监控：            DCGM Exporter + Prometheus + Grafana 持续基线
故障排查：            对比基线、单点回归测试

第 3 层：报告读者

高管 / 财务：        TCO 数字（$/TPM, $/TFLOPS, GFLOPS/W）
采购 / 招标：        tpmC（合同硬指标）+ SPEC 系列
DBA / SRE：         HammerDB / fio 实际曲线 + P99
GPU 集群运维：       NCCL busbw + DCGM 报告
AI 工程师：         MFU + tokens/sec + loss 曲线

不同读者要不同数字。给老板看 TCO，给运维看 P99，给 AI 工程师看 MFU——一份”All in one”报告反而每方都不满意。

第 4 层：时长 / 预算

1 小时：       fio + iperf + nccl-tests 单 size + dcgmi diag -r 2
1 天：         + HPL + HPL-MxP + nccl-tests 全 size + 单机 NeMo 短跑
1 周：         + 多机 burn-in 24-72h + IO500 + MLPerf 复现
1 个月：       完整 SuperPOD 验收 + 客户场景 POC + MLPerf 提交准备

时间越多越能 dump 隐藏问题——但客户通常给不了那么多。压缩到 1-3 天的”快验”是最常见。

各章 benchmark 速查表

按服务器章节回顾：

章	主题	推荐 benchmark
01	服务器通用	整机功耗 / 散热（IPMI / DCGM 监控）、UL 安规
02	CPU	SPEC CPU2017 / SPECpower / SPECjbb
03	内存	mlc / stream / mbw（带宽）+ Intel MLC（延迟）
04	存储	fio / SPECsfs / IO500
05	GPU/AI	nvbandwidth / cublasMatmulBench / NCCL-tests / MLPerf / NeMo
06	网络	iperf3 / perftest / RFC2544
07	OS	UnixBench / sysbench / phoronix-test-suite
08	可信计算	tpm2-tools / OpenSSL benchmark / IMA 完整性
09	整合验收	三阶段（节点 → 机柜 → 应用）

服务器选型的”benchmark 矩阵”

把 9 章融合成一张实战矩阵——按业务横向、按 benchmark 纵向：

业务	CPU	内存	存储	GPU	网络	整体
数据库 OLTP	SPEC int + HammerDB	mlc	fio + 文件系统	—	iperf	$/tpmC
数据仓库	SPEC fp + TPC-DS	stream	fio seq	—	iperf	$/QphH
Web / Java	SPECjbb	—	fio rand	—	iperf	latency P99
HPC	SPEC fp	stream	IOR	HPL/HPCG	ib_write_bw	TFLOPS/W
AI 训练	—	mlc	IOR/GDS	NCCL/HPL-MxP	ib_write_bw	MFU + tokens/s
AI 推理	—	—	NVMe fio	cublasMatmul	iperf	TTFT/TPOT P99
虚拟化云	SPEC int + jbb	—	fio + SPECsfs	MIG/vGPU	iperf	$/VM

认证选型

按市场 + 客户类型回顾：

市场 / 客户	必拿	推荐
中国互联网	CCC	ISO 9001
中国国央政企	CCC + 信创目录	等保 2.0 + 密评
欧盟	CE + Lot 9 能效	ENERGY STAR
美国数据中心	FCC + UL/NRTL	ENERGY STAR
AI 客户 NVIDIA 生态	—	NVIDIA-Certified Systems
银行 / 金融	CCC	ISO 27001 + 等保三级

SA / 实施工程师”成长路径”

0-1 年（初级）：
  考 NCA-AIIO（NVIDIA 入门）
  熟练 fio / iperf / sysbench
  会读 nvidia-smi / DCGM 报告
  能独立完成节点级验收
  
1-3 年（中级）：
  考 NCP-AII
  能调 HPL / HPL-MxP，跑出 70%+ 效率
  熟练 NCCL-tests，能定位 busbw 瓶颈
  能跑通 NeMo / Megatron 烧机
  能读懂 MLPerf 结果
  
3 年+（高级）：
  能做集群级故障 root-cause
  能写 reproduce 脚本给客户
  能为客户做 TCO 分析
  能根据业务负载推荐 benchmark 组合 + 整体方案

整本书的回顾

第一章 → 第九章串起来：

graph TB  C1[01-服务器通用
主板 / 总线 / 散热]  C2[02-CPU
指令集 / 微架构 / 国产]  C3[03-内存
DDR/HBM/CXL]  C4[04-存储
HDD/SSD/NVMe]  C5[05-GPU/AI
NVIDIA/AMD/国产]  C6[06-网络
NIC/SmartNIC/DPU]  C7[07-OS
Linux/Windows/国产]  C8[08-可信计算
TPM/TEE/机密]  C9[09-基准 + 认证
SPEC/MLPerf/CCC]  C1 --> C2 --> C3 --> C4 --> C5 --> C6 --> C7 --> C8 --> C9

每一章都是一台服务器的”一层”——从主板到芯片，从硬件到软件，最后用 benchmark + 认证检验。把这 9 章串起来，能看懂任何一份服务器规格书 + 验收报告 + 招标文件——这就是本书的目标。

给读者的几句

1. 不要"背 benchmark 数字"
   → 数字会过时，方法论不会
   → 学怎么读 / 怎么跑 / 怎么排障，而不是 H100 FP8 是 3958 TFLOPS

2. 不要"只看销售 PPT"
   → 销售给的是"理想配置 + 理想 workload"
   → 自己跑一遍才有真相

3. 不要"跳过认证"
   → 认证不是装饰，是法定责任 + 客户信任
   → 没有 CCC 的服务器进不了国采，没 NCP 的 SA 拿不到 NVIDIA partner 项目

4. 不要"孤岛验收"
   → 节点过了不代表机柜过；机柜过了不代表应用 MFU 达标
   → 三阶段必须全跑

5. 不要"一次验收过了就放着"
   → 集群跑半年后要做"健康度回测"
   → 用同一套基线对比，找到漂移

结语

写到这里九章都齐了。服务器是最复杂的工程产品之一——从晶体管到机房，从 NVLink 到 BGP，从 BIOS 到 PyTorch，跨越十几个学科。

但拆开看，每一层有自己的逻辑：

硬件层有摩尔定律 + 散热墙
互联层有 PCIe / NVLink / IB 各代演进
软件层有 OS / 驱动 / 框架 / 编排
信任层有 TPM / TEE / 远程证明
评估层有 SPEC / MLPerf / TPC

这些”层”不是孤立的——一个 H100 集群训练慢，可能是 BIOS 的 prefetch 没开，也可能是 NVLink 拓扑配错，也可能是 NCCL 走了 IB 而不是 NVLink。架构师的能力就是看穿层之间的链路——这本书希望提供这种”穿层”的能力。

服务器世界还会变。HBM4 / PCIe 7.0 / CXL 3.x / 1.6T 网络 / 800V HVDC / 万亿参数大模型——下一个 5 年又是新故事。

但主干不会变：电源 → 主板 → CPU → 内存 → 存储 → 加速器 → 网络 → OS → 应用 → 度量。

把这条主干理清，新东西出来时你能在 5 分钟内放进合适的位置。这是这本书最想传递的。

写完了。下次见。

服务器认证体系 —— CCC、CE、FCC、能效之星、NVIDIA-Certified

2026-05-17T15:00:00.000Z

服务器不是想卖就能卖——进哪个市场要拿哪些认证，是合规第一关。本文系统讲。

什么是”认证”

认证是指由认证机构证明产品、服务、管理体系符合相关技术规范、相关技术规范的强制性要求或者标准的合格评定活动。
认证通常分为产品、管理体系和服务认证。

1
2
3

产品认证：       CCC（强制）/ CE（强制）/ FCC / ENERGY STAR
管理体系认证：    ISO9001（质量）/ ISO14001（环境）/ ISO27001（信息安全）
服务认证：       体育场所、银行业等

服务器场景下主要打交道的是产品认证和部分管理体系认证。

认证要求覆盖哪些方面

安全（Safety）            人身安全 / 不起火 / 不漏电
电磁兼容（EMC）           不相互干扰 / 不影响其他设备
健康环保（HE）            RoHS / WEEE / 包装回收
频谱协调（RF）            无线频段合规
接口性能（Telecom）       入网证（含 SRRC 型号核准等）
认证评估程序              测试机构资质 / 评定流程
市场监管                  上市后抽检
标识标志（Labeling）      标签 / 防伪 / 可追溯

中国市场：CCC

CCC（China Compulsory Certification）是国家市场监督管理总局负责的强制认证。

适用范围（不完全列举）：
  电脑及配件、显示器、UPS、电池
  含无线模块的设备需 SRRC 型号核准 + CCC

不适用：
  专业服务器（部分目录调整后免 CCC，但仍需自我声明 + 第三方 EMC/Safety 报告）
  数据中心专用网络设备（按品类）

服务器机型上 CCC 主要查：

1
2
3

GB 4943.1：信息技术设备安全
GB 9254：  信息技术设备 EMI（辐射干扰）
GB 17625.1: 谐波电流限值

CCC 标志由”圆形 CCC”图案 + 编号组成，必须贴在产品上。没有 CCC 不能在国内合法销售（针对目录内品类）。

欧盟市场：CE

CE（Conformité Européenne）是欧盟”自我声明”型认证：

原则：
  厂家自己声明符合若干指令（Directive）
  不强制第三方测试，但出问题厂家担责
  
关键指令：
  低电压指令 LVD：     EN 62368-1（替代 EN 60950-1）
  EMC 指令：          EN 55032 / EN 55035
  RoHS 指令：         有害物质限值
  WEEE 指令：         电子产品回收
  Eco-design 能效指令：服务器与存储能耗规则（EU 2019/424）

服务器进欧盟必须有 EU 2019/424（”Lot 9”能效规则）——欧盟 2019 年生效，规定服务器闲置功耗、PSU 效率、信息披露等要求。新代次服务器要符合（或申请豁免）。

美国市场：FCC + UL/NRTL

FCC Part 15B：      EMC（无意辐射）
FCC Part 15C：      含无线模块时
UL/NRTL：          安全（NRTL = Nationally Recognized Testing Laboratory，UL 是其中一家）
                 服务器装机柜 → 数据中心要求 NRTL 证书

美国市场 FCC 是法规要求；UL 不是强制，但绝大多数美国数据中心入场要求 UL/NRTL 安全证书——实际等价于强制。

能效认证：ENERGY STAR

ENERGY STAR for Servers 由 EPA 主导，自愿性能效认证：

要求：
  有 PMI（Power Management Interface）能耗实时上报
  待机功耗低于阈值
  PSU 效率达 80 PLUS Platinum 以上
  服务器空闲 / 满载下功耗符合曲线
  
好处：
  公共采购加分（部分国家政府采购优先）
  在欧美数据中心竞争中有市场优势

国内对应的”中国能效标识”也是类似机制——服务器属于 GB 28381 标准。

安全 + 质量管理认证

ISO 9001：     质量管理体系（厂家级）
ISO 14001：    环境管理体系
ISO 27001：    信息安全管理体系（数据中心运营方常做）
ISO 22301：    业务连续性
TL 9000：      电信行业质量

这些是厂家或运营方层面的认证，不是产品上贴的，但客户招标时常要求供应商提供。

NVIDIA-Certified Systems —— GPU 服务器的”上车证”

NVIDIA-Certified Systems 不是法规要求，但卖 NVIDIA AI 方案的 OEM 必须拿。

覆盖：
  Mainstream NVIDIA-Certified（主流推理 / 训练）
  Enterprise NVIDIA-Certified（企业 AI）
  HGX H100/H200/B200/B300 reference 设计
  GB200 / GB300 NVL72 整机柜认证
  
测试套件：
  GPU + CPU 兼容性
  PCIe / NVLink 拓扑
  网络 & 存储性能基线
  整机散热 & 功耗
  NGC 容器 + AI Enterprise 软件兼容

戴尔 / HPE / 联想 / 浪潮 / 超微等 OEM 各自的”AI 服务器”就是基于 HGX 基板 + 自家整机集成 + 通过 NVIDIA-Certified。

NVIDIA AI Enterprise 平台认证

NVIDIA AI Enterprise 是企业级 AI 软件平台订阅，认证从”硬件 + 虚拟化层 + 平台”:

硬件：           NVIDIA-Certified System
Hypervisor：     VMware vSphere / Red Hat OpenShift / Nutanix
K8s：           OpenShift / Tanzu / Anthos / EKS / GKE / AKS
Bare-metal：    Ubuntu / RHEL / Rocky
软件栈：         NGC 容器 + NIM 微服务 + Triton + NeMo

国内出口管制后，国产化 OS（统信 UOS、麒麟等）的 NVIDIA AI Enterprise 适配还在补 —— 待补充。

NCP-AII —— SA 实施工程师必备

NVIDIA 自家的人员认证，不是产品认证：

NCA-AIIO：     基础级（销售、解决方案工程师入门）
NCP-AII：      专业级（SA、实施工程师）
NCP-AI Operations：   运维方向
NCA / NCP - Generative AI：内容方向

NCP-AII 考点权重（速查）

比重	模块
31%	Cluster bring-up
5%	Physical layer
19%	Control plane
33%	Cluster test
12%	Troubleshooting

考查内容（节选官方学习指南）：

System and Server Bring-up（31%）

- 部署与验证序列
- AI factory 网络拓扑
- BMC / OOB / TPM 初始配置
- 固件升级（含 HGX）与故障检测
- 电力与散热参数验证
- GPU 服务器安装（SMI）
- 安装硬件验证
- 线缆类型与光模块识别
- 物理 GPU 安装
- 第三方存储初始参数配置

Physical Layer Management（5%）

1 2	`- BlueField 网络平台配置管理 - MIG（AI 和 HPC）配置`

Control Plane Installation（19%）

- Base Command Manager（BCM）安装、HA 配置
- OS 安装
- Cluster 安装（category、interfaces、Slurm/Enroot/Pyxis）
- NVIDIA GPU & DOCA 驱动管理
- NVIDIA container toolkit
- GPU + Docker 演示
- NGC CLI 安装

Cluster Test and Verification（33%）

- 单节点压力测试
- HPL 执行
- 单节点 NCCL（含 NVLink Switch 验证）
- 线缆信号质量验证
- 线缆连接确认
- 交换机 FW/SW 确认
- BlueField-3 FW/SW 确认
- 光模块 FW 确认
- ClusterKit 多面节点评估
- NCCL 验证 E/W fabric 带宽
- NCCL burn-in
- HPL burn-in
- NeMo burn-in
- 存储测试

Troubleshoot and Optimize（12%）

- 硬件故障识别（GPU / 风扇 / 网卡）
- 故障卡 / GPU / PSU 识别替换
- NVSM 应用：https://docs.nvidia.com/nvidia-system-management-nvsm/
- AMD / Intel 服务器性能优化
- 存储优化

NCP-AII 是 NVIDIA SA / partner SA 的”必备资格”——考完才能独立交付 GB200/H100 SuperPOD 集群验收。

国产 GPU 与”信创认证”

国产 AI 服务器除常规 CCC 外还涉及：

信创目录：       工信部 / 国资委发布的"信息技术应用创新"产品目录
等保 2.0：       网络安全等级保护
密评：          密码应用安全性评估
GB/T 28181：    安防领域（部分场景）
GJB / 军品认证： 军工渠道

这些不是统一一张证，而是分行业 / 分省份 / 分客户群组织的——比如某省国采明确”必须在 XX 省信创目录”。

数据中心整体认证

数据中心运营方拿的”机房认证”：

Uptime Institute：    Tier I-IV（常用 Tier III/IV）
TIA-942：            机房 Rated 1-4
EN 50600：           欧洲数据中心标准
GB 50174：           中国数据中心设计规范（A/B/C 类）
LEED：              绿色建筑
PUE：               能源使用效率（不是认证，是指标）
WUE：               水使用效率
CUE：               碳使用效率

这些不是”服务器”的认证，而是”机房 / 整个数据中心”的认证。但服务器选型时要考虑能否在某个 Tier 等级的机房落地（功率密度、抗震、冗余等）。

一张速查

认证	谁发	强制性	测什么
CCC	中国国家认监委	强制（目录内）	安全 + EMC（中国）
CE	EU 自声明 + 第三方	强制（欧盟）	安全 + EMC + 能效 + RoHS
FCC	美国 FCC	强制（美）	EMC（美国）
UL/NRTL	UL 等 NRTL	实质强制（美数据中心入场）	安全
ENERGY STAR	EPA	自愿	能效
ISO 9001	TÜV / SGS / BV 等	自愿	厂家质量管理
NVIDIA-Certified	NVIDIA	自愿（NVIDIA 生态）	GPU 兼容 + 性能基线
NCA/NCP	NVIDIA	人员资格	SA / 销售 / 实施
信创目录	工信部	部分场景强制	自主可控
等保 2.0	公安部	强制（联网系统）	网络安全分级

实战经验

1. 卖到中国 → CCC 必拿（看品类目录）
2. 卖到欧盟 → CE 必拿，2019/424 能效硬指标
3. 卖到美国 → FCC + UL/NRTL（实质强制）
4. 国内大客户 → ISO 9001 / 14001 / 27001 是招标常见
5. NVIDIA AI 方案 → NVIDIA-Certified 是品牌背书
6. 政府国央 → 信创目录 / 等保 2.0
7. SA 入职 → 半年内拿 NCA-AIIO，1-2 年内拿 NCP-AII

待补充：H20 / B20 在中国市场的 CCC + 信创认证状态。

小结

认证体系覆盖产品（CCC/CE/FCC）、体系（ISO）、人员（NCP）三类
卖到不同市场拿不同证：中国 CCC、欧盟 CE+能效指令、美国 FCC+UL
ENERGY STAR 是自愿但带来公共采购加分
NVIDIA-Certified 是 GPU 服务器进 NVIDIA 生态的必经
NCP-AII 是 SA 实施工程师 1-2 年内必拿的人员资格

下一篇是第九章小结，按业务场景串起所有 benchmark 与认证。

AI 基准 —— MLPerf、cuBLAS、nvbandwidth、NCCL-tests、NeMo 烧机

2026-05-10T08:25:00.000Z

GPU 集群和传统 HPC 集群的验收哲学不同：HPC 看 HPL 一个数字，AI 集群看的是算力 + 显存 + 互联 + 集合通信 + 真实训练 token/s 一连串数字。本文按 NVIDIA SA 实战视角串完。

AI 集群验收三阶段

graph TB  S1[1. 节点级
HPL, HPL-MxP
nvbandwidth
cublasMatmulBench
DCGM diag]  S2[2. 机柜/Pod 级
nccl-tests
SHARP 验证]  S3[3. 应用级
NeMo / Megatron 真训练
token/sec]  S1 --> S2 --> S3

每一阶段都不能跳——单卡过了不代表机柜过；机柜过了不代表大模型训练 MFU 达标。

第 1 阶段（节点级）

nvbandwidth —— H2D / D2H / D2D 带宽

nvbandwidth 是 NVIDIA 官方的 GPU 带宽测试工具。

# 编译（需要 boost）
cmake .
make -j $(nproc)

# 列出所有 case
./nvbandwidth -h

两种执行单元：CE vs SM

Copy Engine (CE)：

CE 是 GPU 内部的 DMA（Direct Memory Access）引擎，独立于 SM
当 CPU/GPU 发起 CE 拷贝时，向 DMA 控制器发一组描述符
（源地址、目的地址、数据大小），DMA 接管 PCIe / NVLink 总线和显存控制器，直接搬比特流
仅搬数据，不能做计算或格式转换；数量、吞吐硬件 fix

cudaMemcpy / cudaMemcpyAsync 通常底层就用 CE
CE 测出来的数值是 NVLink 理论的 ~80% 即合格

Streaming Multiprocessor (SM)：

SM 是流式多处理器（含 CUDA Core、寄存器、shared memory、Load/Store）
SM 拷贝是把搬运当成 CUDA Kernel 跑
GPU 启动成千上万线程，每线程负责一小块数据
线程通过 PTX 的 LD/ST 指令搬数据
极依赖内存合并（Memory Coalescing）：一个 Warp 32 线程同时访连续地址
显存控制器会合并成 128 字节宽事务，打满 HBM 带宽

SM 在做带宽测试时显然干不了别的（计算）
SM 效率会更低，~75-80% 算合理
典型地，CE 比 SM 效率高（CE 是专用 DMA 硬件）

使用模式

# 列出所有测试
./nvbandwidth -t list

# 跑 host-to-device、device-to-host、device-to-device 全套
./nvbandwidth -t 0,1,2,3

# 只跑特定测试
./nvbandwidth -t host_to_device_memcpy_ce
./nvbandwidth -t device_to_device_memcpy_write_sm

期望数值

H100 SXM5 单卡：
  H2D PCIe Gen5 x16：  ~52 GB/s（理论 64）
  D2H PCIe Gen5 x16：  ~52 GB/s
  D2D NVLink 4 双向：  ~720 GB/s（理论 900）

B200 SXM5 单卡：
  D2D NVLink 5 双向：  ~1500 GB/s（理论 1800）

低于上述 80% 一般是 PCIe lane / NVLink 链路问题。

GEMM 算力测试

测算力 = 测 GEMM（General Matrix Multiply）—— 几乎所有 AI workload 的基础原语。

关键调优要点

锁频：测试前必须 nvidia-smi -lgc  锁 GPU 频率
      否则 GPU Boost 会抖动，无法横向对比

Warmup：所有工具计时前必须预热（空跑几圈）
        否则第一次包含 PTX JIT 编译或库加载时间，数据不准

矩阵尺寸：要测出峰值算力，M, N, K 必须足够大（4096+）
         且最好是 8 或 16 倍数（Tensor Core 对齐）

工具家族

cublasMatmulBench（NVIDIA 内部 / NDA 工具，集成在 benchmark guide）：

# INT8
cublasMatmulBench -P=bisb_imma -m=8192 -n=3456 -k=16384 -T=1000 -ta=1 -B=0
# FP16
cublasMatmulBench -P=hsh -m=12288 -n=9216 -k=32768 -T=1000 -tb=1 -B=0
# TF32
cublasMatmulBench -P=sss_fast_tf32 -m=8192 -n=3456 -k=16384 -T=1000 -ta=1 -B=0
# FP32
cublasMatmulBench -P=ddd -m=3456 -n=2048 -k=16384 -T=1000 -tb=1 -B=0
# FP64
cublasMatmulBench -P=sss -m=3456 -n=2048 -k=16384 -T=1000 -tb=1 -B=0

GEMM CublasLt —— 公开 Python 版：

1	`https://github.com/Azure/AI-benchmarking-guide/blob/main/Benchmarks/NVIDIA/GEMMCublasLt.py`

batchBLAS —— CUDA Samples 自带：

1	`cuda_samples / 4_CUDA_Libraries / batchCUBLAS`

MAMF Finder（开源）：

1 2	`https://github.com/stas00/ml-engineering/blob/master/compute/accelerator/benchmarks/mamf-finder.py 帮你找出最高 achievable GEMM 算力（"Maximum Achievable Matmul FLOPS"）`

期望算力（dense throughput）

H100 SXM5：
  FP8：     3958 TFLOPS dense
  FP16/BF16： 1979 TFLOPS dense
  TF32：    989 TFLOPS dense
  FP64：    67 TFLOPS dense

B200 SXM5：
  FP4：     18000 TFLOPS dense
  FP8：     9000 TFLOPS dense
  FP16/BF16： 2250 TFLOPS dense
  FP64：    40 TFLOPS dense

跑出来 ≥ 90% 理论值算合格。低于 80% 排查锁频 / NUMA / cuBLAS 版本。

DCGM diag —— 节点健康自检

NVIDIA DCGM 是 GPU 监控 + 诊断工具：

dcgmi diag -r 1   # 快速 (~30s)
dcgmi diag -r 2   # 中等 (~5min)
dcgmi diag -r 3   # 完整（含压力测试，~30min）
dcgmi diag -r 4   # 长时（含 thermal stress, ~1h+）

-r 3 通常够节点初验。-r 4 用于客户怀疑 thermal throttle 时跑长时间压测。

第 2 阶段（机柜 / Pod 级）

NCCL-tests —— 集合通信带宽

NCCL-tests 是事实标准。前一篇已展开测试列表（all_reduce_perf 等）和 algbw / busbw 区别。

NVL72 / 多机不同规模 busbw 基线

单机 8 卡 H100 NVLink 4：     AllReduce busbw ~370-400 GB/s
单机 8 卡 B200 NVLink 5：     AllReduce busbw ~700-900 GB/s
NVL72 72 卡 NVLink 5：       AllReduce busbw ~700-900 GB/s
跨节点 H100 + IB NDR 单端口：  ~50 GB/s 量级
跨节点 H100 + IB NDR 双端口：  ~100 GB/s
SuperPOD H100 256-GPU NVLink Network：达到 100+ GB/s
SHARP 启用后大规模 AllReduce：~2× 提升

待补充：完整 NVL72 / NVL576 / DGX SuperPOD 不同 message size 的 busbw 表。

排障思路

1. NCCL_DEBUG=INFO 看选了哪个 algorithm + protocol
2. 拓扑：nvidia-smi topo -m 看 NVLink / PCIe / SYS 矩阵
3. 网络：nccl-tests 加 -x NCCL_IB_HCA=mlx5_0,mlx5_1 显式指定
4. SHARP：NCCL_COLLNET_ENABLE=1
5. P2P：NCCL_P2P_LEVEL 控制是否走 P2P / 强制走 NIC

ClusterKit —— SuperPOD 验收快速 sanity check

NVIDIA HPC-X 自带的集群验证工具集：

clusterkit 主入口
单对 / 全对 latency-bandwidth
GPU↔GPU、CPU↔GPU 多组合
报告生成与 baseline 比对

ClusterKit 是 SuperPOD 验收里”几分钟出全图”的工具，比手工拼 nccl-tests 高效。

完整使用示例多在 Partner / NVIDIA 内部 RA，等待补充。

MLPerf

MLCommons MLPerf 是行业内 NVIDIA / Google / Intel / AMD 加速器对比的标准入口。

主要类别：

MLPerf Training      — pretraining / fine-tuning
MLPerf Inference     — Datacenter / Edge
MLPerf HPC           — 科学计算
MLPerf Storage       — 存储吞吐
MLPerf Power         — 能效
MLPerf Client/Mobile/Tiny — 端侧

NVIDIA 通常以 DGX / HGX / GB200 系统提交：

1 2	`详细工程报告： NVIDIA blog 与 GitHub repo nvidia/MLPerf* 复现工件： NeMo / Megatron / TensorRT-LLM 等`

NVIDIA MLPerf blog 索引：https://developer.nvidia.com/blog/tag/mlperf/
NVIDIA submission repos：https://github.com/mlcommons

待补充：跟踪最新一轮 MLPerf Training/Inference 中 NVIDIA 的 SoTA 数字。

怎么读 MLPerf 结果

Closed Division：    严格规则，能直接横比
Open Division：      开放优化，看创新方向
"提交规模"：         看 GPU 数（8 / 64 / 1024 / 11000+）
"模型 / 任务"：       Llama-2 70B, GPT-3 175B, BERT, ResNet-50, RNN-T, Stable Diffusion ...
"指标"：             Training time-to-train（分钟）/ Inference QPS、samples/sec

NVIDIA 几乎每轮都是榜首——这是 NVIDIA 卖 GPU 的”市场背书”。但 SoTA 数字基于”DGX SuperPOD 万卡级 + 整套 SW stack”——客户实际能不能复现要看自己软硬件配置。

第 3 阶段（应用级）

NeMo / Megatron Burn-in 烧机

集群级烧机测试通常用 NeMo / Megatron 跑真实 training step 数小时～数十小时，监控：

Tokens/sec 稳定性
GPU / HBM 温度
链路 down / NCCL timeout
训练 loss 曲线是否平滑

关键监控

1
2
3

DCGM Exporter → Prometheus → Grafana
NetQ / UFM 链路 telemetry
SLURM / Run:ai 任务日志

典型烧机配置

模型：           Llama-2 70B / GPT-3 175B / Llama-3 8B（轻量）
数据集：         合成数据或 C4 子集
精度：           BF16 + FP8 (TE)
batch / seq：    跟 NVIDIA reference recipe
并行：           TP=8 + PP=8 + DP=N（按集群规模）
时长：           24h（短）/ 72h（中）/ 7 天（长）

标准烧机时长 / 阈值多来自 RA，等待补充。

通过标准

Tokens/sec：     稳定（< 5% 抖动）
loss 曲线：      平滑下降，无 NaN / Inf
GPU 温度：       < 85°C 持续
HBM 温度：       < 95°C 持续
NCCL timeout：  0 次
节点重启：       0 次

任何一项失败 → 排查节点 / 链路 / 散热，整改后重测。

vLLM / TensorRT-LLM 推理验收

# vLLM 自带 benchmark
python -m vllm.entrypoints.openai.api_server --model meta-llama/Llama-3-70B
python benchmark_serving.py --num-prompts 1000 --request-rate 10

# TensorRT-LLM perf
trtllm-bench --model_path /path/to/llama3 --max_batch_size 32 throughput

观察：
  P50 / P99 TTFT（Time To First Token）
  P50 / P99 TPOT（Time Per Output Token）
  Throughput（tokens/sec）
  GPU 利用率（nvidia-smi dmon）
  HBM 占用

不同模型 / 量化 / 序列长度组合下数字差很多——验收前先和客户对齐”业务侧 SLA”，再选基线。

一张验收表

阶段	工具	通过标准
节点	DCGM diag -r 3	All PASS
节点	nvbandwidth	NVLink ≥ 80% 理论
节点	cublasMatmulBench	FP8/FP16 ≥ 90% peak
节点	HPL	效率 70-80%
节点	HPL-MxP	Tensor Core 跑出
机柜	nccl-tests all_reduce	busbw 符合基线
机柜	nccl-tests alltoall	MoE 路径 OK
机柜	SHARP 启用	大消息 ~2× 提升
应用	NeMo / Megatron 24h+	tokens/sec 稳 / loss 平
应用	vLLM / TRT-LLM	TTFT/TPOT 满足 SLA

为什么不能跳阶段

跳节点 → 集群：
  单卡有 thermal throttle，集群表现像"扩展性差"
  排查时 N×N 排错，浪费几天
  
跳机柜 → 应用：
  AllReduce busbw 不达标，但训练能跑（只是 MFU 低）
  → 客户拿到集群训练 MFU 30%，怀疑硬件
  → 实际是网络 ~30% 折损
  → 排查极困难
  
所以三阶段必须按顺序跑过

一些坑

1. 锁频忘了：
   GPU Boost 让单次 GEMM 跑出 110% 理论
   → 多次跑分波动 10%+
   
2. NUMA 没绑：
   nvidia-smi topo -m 显示 GPU 0 应该在 numa node 0
   实际 mpirun 把进程跑到 numa node 1
   → 跨 socket 链路加 30-50% 延迟
   
3. PCIe 降速：
   nvidia-smi 查"GPU Link Width"应该是 16x，"Link Generation"应该是 5
   实际 5 → 3，链路问题，需要重新插或换板
   
4. 容器版本不对：
   NVIDIA hpc-benchmarks 容器有不同版本（24.06 / 24.09 / 24.12）
   大模型测试要 PyTorch + CUDA + cuDNN + NCCL 全套版本对齐
   → 不对齐有时候慢一倍
   
5. 客户拿走 baseline 自己跑出来不一致：
   客户没跑 nvidia-smi -lgc 锁频
   客户用了不同 BIOS / Power Profile
   客户驱动版本不一致
   → 一定要把 reproduce 文档写细

小结

AI 集群验收三阶段：节点 → 机柜 → 应用，缺一不可
节点级：nvbandwidth + cublasMatmulBench + DCGM diag + HPL
机柜级：nccl-tests（busbw）+ ClusterKit + SHARP 验证
应用级：NeMo/Megatron 24h+ burn-in + vLLM/TRT-LLM 推理 SLA
MLPerf 是行业标尺，看 SoTA 但客户复现要慎重
锁频、NUMA、PCIe、版本是四大坑

下一篇讲服务器认证体系——CCC、CE、FCC、能效之星、NVIDIA-Certified。

存储与网络基准 —— fio、iperf、ib_write_bw、SPECsfs

2026-05-03T12:10:00.000Z

存储和网络两条线的 benchmark 在集群验收里同样占大头——HPL 测 GPU、fio 测盘、iperf/perftest 测网。本文讲实操。

存储 benchmark 的几个层级

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

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

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

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

关键参数

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

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

看哪几个数字

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

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

一些经验值

介质	顺序读	4K 随机读 IOPS	P99 延迟
7200 转 HDD	200 MB/s	100-200	10-30 ms
SATA SSD	550 MB/s	50K-100K	< 1 ms
NVMe Gen4 SSD	7 GB/s	1M	< 100 μs
NVMe Gen5 SSD	14 GB/s	2M	< 100 μs
Optane PMem（已停产）	6 GB/s	0.5M	< 10 μs

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

跑 fio 的几个坑

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 选型主基准。

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 存储事实尺。

工作负载：
  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

观察：
  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 吞吐

# 服务端
iperf3 -s

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

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

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

# qperf 服务端
qperf

# 客户端
qperf  -t 30 tcp_bw tcp_lat

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

ib_write_bw / ib_read_bw / ib_send_lat —— InfiniBand RDMA

perftest 套件：

# 服务端
ib_write_bw -d mlx5_0 -F

# 客户端
ib_write_bw -d mlx5_0 -F  --report_gbits

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

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 视图里：

测试	含义
`all_reduce_perf`	AllReduce 带宽（最关键）
`all_gather_perf`	AllGather
`reduce_scatter_perf`	ReduceScatter
`broadcast_perf`	Broadcast
`reduce_perf`	Reduce
`alltoall_perf`	AllToAll（MoE 关键）
`sendrecv_perf`	Point-to-point

关键指标：

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

# 单机 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

常用环境变量：

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

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

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. 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 流量。

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

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

一张速查

层级	工具	主指标
块/SSD	fio	IOPS, BW, P99 lat
文件系统	fio	同上（+ overhead）
NAS	SPECstorage SFS 2020	ops/sec, ORT
分布式	IO500 / IOR / mdtest	bw + meta
GPUDirect Storage	gdsio	GiB/s, CPU = 0
TCP/UDP 网络	iperf3	Gbit/s, retrans
RDMA	ib_write_bw / perftest	Gbit/s, lat
集合通信	nccl-tests	algbw / busbw

一些验收脚本骨架

# 节点级（单机）
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 烧机。

HPC 基准 —— HPL、HPCG 与 TOP500

2026-04-26T07:35:00.000Z

HPC 基准是 GPU 集群验收里第一个跑的——既是验机也是衡量峰值。本文专题讲 HPL、HPCG、HPL-MxP，以及 TOP500 / Green500 / HPCG 三张榜单。

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）

原则：填满所有 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（进程网格）

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

跑分目标

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

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

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

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

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

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

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

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

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

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

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

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

HPCG —— “真实性能”基准

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

为什么 HPCG”低得多”？

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 性质决定。

历史事件

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

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

HPL-MxP —— 混合精度 HPL

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

为什么需要 HPL-MxP？

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 混合负载的体现。

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. 节点 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 三张榜怎么选

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

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

一些命令与文档

# 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 ...

查 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	FP64 峰值 LU 分解	集群初验、TOP500 提交	数小时
HPL-MxP	Tensor Core 混合精度	AI 集群验收	数小时
HPCG	真实科学计算	真实 workload 摸底	1-2 小时
nvbandwidth	H2D/D2H/D2D 带宽	单卡基线	几分钟
NCCL-tests	集合通信带宽	集群互联验收	1-2 小时

小结

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 实战。

CPU 与数据库基准 —— SPEC CPU、TPC-C、SPECjbb

2026-04-19T14:15:00.000Z

第九章第二篇专题讲 CPU 和数据库基准——这是服务器采购合同里最常出现的两组数字。

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

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

四个子套件

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

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

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

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

怎么读 SPECrate

某 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）时关键列：

列	含义	看什么
Hardware	CPU、内存、存储、BIOS	配置基线
Software	OS、编译器、libc、glibc	软件栈
Tunable	NUMA、Turbo、HT、Power Profile	调优
Result	base / peak	实际数字
Energy	部分报告有功耗	能效

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

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

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 测的是”性能 / 瓦”——服务器能效之标尺。

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 系列里最经典：模拟电商订单系统。

仓库（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 官网真实发布。

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

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

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

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

graph LR  HDB[HammerDB
开源, GUI/CLI]  SB[sysbench
开源, 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 官网。

实操要点

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

典型对比：
  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 自我对标。

选型场景

单机数据库（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”

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

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

成熟做法：

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

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

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

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 绑核做对照测试

一些命令

# 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    # 全脚本驱动

一张速查

场景	主基准	次要基准
CPU 通用计算	SPEC CPU2017 (rate base)	SPEC CPU2017 (speed base)
CPU 能效	SPECpower	—
单核响应	SPECspeed_int_base	sysbench cpu
Java 中间件	SPECjbb 2015	—
OLTP（MySQL/PG）	sysbench oltp / HammerDB TPROC-C	TPC-C 官网（参考）
OLTP（Oracle/Db2）	HammerDB TPROC-C	TPC-C 官网（参考）
决策支持	TPC-H	HammerDB TPROC-H
大数据数仓	TPC-DS	—

小结

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

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

基准测试体系概览 —— TPC、SPEC、TOP500 与 MLPerf

2026-04-12T13:50:00.000Z

前八章把硬件讲完了——但实际选型时，”H100 算力 1979 TFLOPS”这种 datasheet 数字不能直接拿来对比 Llama 3 训练性能。基准测试（benchmark）是把硬件性能落到同一把尺上的工具。第九章讲基准。

为什么需要基准测试

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

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
事务处理性能委员会
1988 成立]  ROOT --> SPEC[SPEC
标准性能评估机构
1988 成立]  TPC --> TPCC[TPC-C
OLTP 经典]  TPC --> TPCH[TPC-H
决策支持/分析]  TPC --> TPCDS[TPC-DS
大数据分析]  TPC --> TPCx[TPCx-AI / TPCx-HS
AI 与 Hadoop]  SPEC --> SPECCPU[SPEC CPU
处理器整数/浮点]  SPEC --> SPECjbb[SPEC jbb
Java 中间件]  SPEC --> SPECpower[SPECpower
能效]  SPEC --> SPECstorage[SPEC SFS
NAS 文件存储]  SPEC --> SPECMLPerf[SPECaccel /
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 全景”：

领域	经典基准	现代主流	测什么
CPU 整数 / 浮点	SPEC CPU2006	SPEC CPU2017	单核 / 多核计算
CPU 能效	—	SPECpower_ssj2008	性能 / 瓦
数据库 OLTP	TPC-C（tpmC）	HammerDB / sysbench	每分钟事务数
数据库分析	TPC-H	TPC-DS	复杂查询响应时间
Java 中间件	SPECjbb2005	SPECjbb2015	Java 服务端吞吐
Web 服务器	SPECweb2005	（已退役）	HTTP QPS
HPC 峰值	HPL / Linpack	HPL（仍是 TOP500 标尺）	FP64 峰值
HPC 真实	—	HPCG	内存 / 网络综合
存储块设备	iozone	fio	IOPS / 带宽 / 延迟
NAS 文件	SPECsfs	SPECstorage SFS 2020	文件操作并发
网络带宽	iperf	iperf3 / qperf	TCP / UDP 吞吐
RDMA 网络	—	ib_write_bw / perftest	InfiniBand / RoCE
集合通信	—	NCCL-tests	AllReduce / AllGather busbw
AI 训练 / 推理	—	MLPerf	端到端训练 / 推理
AI GEMM	—	cuBLASMatmulBench / nvbandwidth	算力 / 带宽底层

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

基准结果”怎么读”

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

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

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

一份典型 benchmark 报告应有什么

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×：

编译器选项：     -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 年后受出口管制影响数量下降

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
训练]  ML --> I[Inference
推理]  ML --> H[HPC
科学计算]  ML --> S[Storage
存储吞吐]  ML --> P[Power
能效]  ML --> C[Client / Mobile / Tiny
端侧]

每轮提交分 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

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

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

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

一些避坑

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 数字
   → 完全不可比

第九章会展开什么

篇	内容
02	CPU & 数据库 benchmark：SPEC CPU2017、TPC-C、SPECjbb
03	HPC benchmark：HPL、HPCG、TOP500 实战
04	存储与网络 benchmark：fio、iperf、ib_write_bw、SPECsfs
05	AI benchmark：MLPerf、cuBLAS、nvbandwidth、NCCL-tests、NeMo burn-in
06	服务器认证：CCC、CE、FCC、ISO9001、NVIDIA-Certified、能效之星
07	选型与第九章小结

小结

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

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

可信计算选型与第八章小结

2026-04-05T15:20:00.000Z

第八章前面 5 篇分别讲了 TPM/TCM、Secure Boot/IMA、TEE（SGX/TDX/SEV/TrustZone）、机密计算、国产可信。本篇收口。

选型的”四层决策”

graph TD  Q1[第 1 层: 威胁模型?]  Q1 --> Q2[第 2 层: 数据保护粒度?]  Q2 --> Q3[第 3 层: 国密 / 信创要求?]  Q3 --> Q4[第 4 层: 性能 / 成本预算?]  Q4 --> A[最终方案]

第 1 层：威胁模型

威胁 1：物理偷盘 / 服务器被搬走
  → LUKS 全盘加密 + TPM 密封 PCR 7

威胁 2：BIOS / Bootloader 被篡改
  → Secure Boot + Measured Boot

威胁 3：root 用户恶意 / 内部攻击
  → IMA Appraisal + 文件签名

威胁 4：CSP 不可信 / 多租户隔离
  → Confidential VM（TDX / SEV-SNP）

威胁 5：跨数据所有者协作
  → MPC + Confidential Computing

威胁 6：供应链 / 后门
  → TPCM 主动可信 + 全栈国产

威胁 7：内存 dump / 侧信道
  → TEE 内存加密 + 时间常数代码

第 2 层：数据保护粒度

粒度	推荐方案	适用场景
全盘	LUKS + TPM	防偷盘
文件	IMA + Appraisal	应用文件防篡改
进程	Intel SGX	KMS / 密钥保护
VM	TDX / SEV-SNP / CSV	整 VM 加密
容器	CoCo（基于 VM TEE）	K8s 机密容器
GPU	NVIDIA Confidential Mode + TDX	大模型机密推理

第 3 层：国密 / 信创

graph TD  Q1{业务等保等级?}  Q1 -- "等保 1-2 级" --> S1[国际方案 OK
TPM 2.0 + LUKS]  Q1 -- "等保 3 级" --> S2[国密 + TCM
麒麟 / 欧拉]  Q1 -- "等保 4 级 / 关基" --> S3[全栈国产
TPCM + 海光 CSV / 鲲鹏 iTrustee]  Q1 -- "军工 / 国防" --> S4[龙芯 / 申威 + 自研可信]

第 4 层：性能 / 成本

最便宜：     纯软件方案（IMA / dm-crypt）
中端：       TPM + Secure Boot + LUKS（每机几十元 TPM 芯片）
中高：       Confidential VM（云价格 +10-20%）
高：         CoCo（资源开销 + 启动慢）
最高：       Confidential GPU（H100 量级 + 软件）

几个典型场景的清单

场景 1：互联网公司一般业务

推荐：     不用 TPM / TEE，靠普通安全
理由：     ROI 不划算，运维成本高
保护手段：     
  - dm-crypt 普通磁盘加密
  - SELinux / AppArmor
  - 入侵检测 / 审计

场景 2：金融核心系统

推荐：     全栈可信启动
配置：     
  - TPM 2.0 / TCM 芯片
  - Secure Boot 启用
  - Measured Boot 记录
  - LUKS + TPM 密封 PCR 7
  - IMA Appraisal
  - 远程证明上报
  - 国密 SSL（GmSSL）
预算：     额外 5-10% 硬件 + 运维

场景 3：政府 / 央企信创系统

推荐：     国产全栈 + TPCM
配置：     
  - 海光 / 鲲鹏 + TPCM 模块
  - 麒麟 V10 / openEuler / UOS
  - TCM 芯片（与 TPCM 配合）
  - 国密 Secure Boot（SM2 签名）
  - IMA + EVM 国密版
  - 海光 CSV / 鲲鹏 iTrustee（敏感业务）
认证：     等保 3+ / 信创目录

场景 4：多方计算 / 联邦学习

推荐：     Confidential VM + Confidential GPU
配置：     
  - 云上 TDX VM 或 SEV-SNP VM
  - NVIDIA H100 Confidential Mode
  - 远程证明 + KBS 密钥分发
  - Veraison / Intel Trust Authority
应用：     银行联合反欺诈、医疗 AI、广告 Data Clean Room

场景 5：军方 / 国防

推荐：     龙芯 / 申威 + 自研可信芯片
配置：     
  - 全自主指令集
  - 自研 BIOS / OS / 可信 module
  - 物理隔离网络
  - 国密 + 自定义算法
等保：     4 级以上

几个常见的”老坑”

坑 1：以为 TPM = 安全

TPM 只能"度量"，不能"防御"：     
  - 启动时 BIOS 改了，PCR 也改，但系统照样启动
  - TPM 不阻止攻击，只记录状态
  
完整方案：     TPM 度量 + Secure Boot 阻止 + IMA 运行时验证 + 远程证明

坑 2：Secure Boot 关闭后还以为安全

有人嫌 Secure Boot 麻烦关掉：     
  - PCR 7 变化（reboot 后 LUKS 解不开）
  - 但 BIOS 度量仍记录
  - 攻击面立即扩大

坑 3：把 Confidential VM 当魔法

启用 TDX / SEV-SNP 不等于"完全安全"：     
  - 业务代码漏洞照样存在
  - 侧信道攻击仍可能
  - 远程证明不实现 = 走过场
  
正确：     TEE + 应用层安全 + 持续审计

坑 4：远程证明不验签

拿到 attestation report 但不验签：     
  - 攻击者可伪造
  - TCB level 不查 = 旧漏洞 CPU 仍信任
  - 不防重放
  
完整验证：     签名链 + nonce + TCB level + 撤销列表

坑 5：vTPM 状态丢失

KVM vTPM 默认非持久化：     
  - VM 重启 → PCR 全空
  - LUKS 密封解不开
  - 业务 down
  
解决：     swtpm + libvirt 持久化模式

坑 6：万级集群基线管理

每机 PCR 因 BIOS / kernel 略差异：     
  - 远程证明要逐机维护基线
  - 升级时全集群 PCR 重算
  - 运维成本高
  
缓解：     用 PCR 7 + Secure Boot 抽象，不直接比 PCR 0/4

坑 7：性能预估错位

1
2
3

TEE 加密内存 5-10% 性能损失看起来小：     
  - 但有些业务（数据库 / 高频交易）20% 都受不了
  - 实测后再决定生产用

一些性能直觉数字

TPM 操作：     
  生成 RSA 2048 密钥：     500-1000 ms
  RSA 签名：              50-100 ms
  PCR Extend：            1-5 ms
  Quote：                  50-150 ms

启动开销：     
  Secure Boot：            +50-200 ms
  Measured Boot：          +500 ms
  IMA：                   +1-5 秒
  TPM 解 LUKS：           +200-500 ms

TEE 性能：     
  SGX 内存敏感应用：       50-70%（大数据集）
  SGX CPU 敏感应用：       95%
  TDX / SEV-SNP：         95%（< 5% 损失）
  Confidential GPU：     90-95%

启动 + 远程证明：     
  Confidential VM：        +3-5 秒
  CoCo Pod：              +5-10 秒

第八章整体小结

回看第八章覆盖：

TPM / TCM 基础 — 硬件根 + PCR + 度量启动链
Secure Boot / Measured Boot / IMA — 启动链验签 + 度量 + 运行时验证
TEE — SGX / TDX / SEV / TrustZone / CCA
机密计算 — Confidential VM / Container 产品形态
国产可信计算 — TCM / TPCM / 海光 CSV / 鲲鹏 iTrustee
可信计算选型与小结（本篇）

几条贯穿全章的主线：

graph LR  HW[硬件根
TPM/TCM/CPU TEE]  BOOT[启动链
Secure + Measured]  RUN[运行时
IMA / TEE]  REMOTE[远程证明]  APP[业务可信]  HW --> BOOT --> RUN --> REMOTE --> APP

核心认知：

可信计算 = “硬件证明系统状态”
TPM 度量 + Secure Boot 验签 + IMA 运行时 = 完整启动链
TEE 进一步保护”运行时数据”
远程证明把”信任”延伸到远端
国产路线分两条：TPM 2.0 + 国密 / TCM-TPCM 主动可信
互联网启用率低，政企 / 金融 / 关基启用率高

可信计算未来 2-3 年趋势

1. TDX / SEV-SNP 在公有云全面铺开
2. Confidential GPU（NVIDIA H100/B200）走向规模化
3. CoCo（K8s 机密容器）从研究走向生产
4. ARM CCA 商用 + 鲲鹏 + 飞腾跟进
5. RATS（IETF 远程证明）成为跨厂家标准
6. 量子安全密码学开始嵌入 TPM（PQC）
7. 国产 TPCM 在关基 / 政企持续渗透
8. 海光 CSV3 / GPU TEE 大规模落地
9. 联邦学习 + 机密计算结合（数据合作）
10. 监管推动（PIPL / GDPR / DORA）使机密计算成为合规手段

给读者的实战建议

如果你在公司负责可信计算 / 安全规划：

1. 先评估威胁模型——不要"为了用而用"
2. 一般业务先做基本面：     磁盘加密 + SELinux + 审计
3. 关键业务再叠加：     TPM + Secure Boot + IMA
4. 对外提供服务：     考虑 Confidential VM 给客户证明
5. 跨方合作：     选 TDX / SEV-SNP 路线
6. 国产化要求按等保等级分层
7. 远程证明要规划基线管理（最大坑）
8. 性能 / 成本先做 PoC 实测
9. 留 fallback（recovery key / 等密码）
10. 团队培训：     可信计算运维比常规更复杂

待补充：你公司或项目的可信计算选型经验。

第八章结束

下一章进入第九章基准测试与认证。会重点讲：

SPEC CPU / Linpack / SPECpower
TPC-C / TPC-H / TPC-DS（数据库基准）
MLPerf（AI 基准）
STREAM / fio / iperf 等工具
国产认证（CCC / 中标 / 信创目录 / 等保 / 国密）
全书收口

Chapter 8 done.

国产可信计算 —— TCM、TPCM、海光 CSV、鲲鹏

2026-03-29T08:30:00.000Z

中国可信计算 1990 年代起步，2000 年后形成”沈昌祥院士”主导的”可信计算 2.0”路线——和国际 TCG 路线有差异。本文盘点国产可信硬件、软件、标准全景。

中国可信计算的”两条线”

graph TB  CN[国产可信计算]  CN --> L1[国际兼容路线
TPM 2.0 + 国密扩展]  CN --> L2[国密自主路线
TCM + TPCM 主动可信]    L1 --> H1[多数 OEM 主板带 TPM]  L1 --> H2[海光 CSV / 鲲鹏 iTrustee]    L2 --> H3[TCM 芯片 主板加]  L2 --> H4[TPCM 主控可信芯片]  L2 --> H5[等保 2.0 / 关基要求]

TCM：可信密码模块

国密版 TPM：

TCM（Trusted Cryptography Module）：     
  - 国家密码管理局主导
  - GB/T 29827-2013（"信息安全技术 可信计算规范 TCM"）
  - 算法：     SM2 / SM3 / SM4
  - 接口：     LPC / SPI

与 TPM 1.2 类比：     
  - TPM SHA-1 → TCM SM3
  - TPM RSA → TCM SM2
  - TPM AES → TCM SM4

商用：     兆芯 / 海光 / 龙芯主板都可选 TCM 芯片
厂家：    国民技术、华大半导体、海泰方圆、瑞达等

TPCM：可信平台控制模块

中国”主动可信”路线的核心创新：

TPCM（Trusted Platform Control Module）：     
  - "可信计算 3.0"概念
  - 沈昌祥院士主推
  - 不同于 TPM / TCM 的"被动度量"
  - TPCM 主动控制系统启动
  
区别于 TPM：     
  TPM：     CPU 调它，被动响应
  TPCM：    自身有控制权，可主动启动 / 阻断

物理形态：     
  - 主板上独立模块
  - 上电时优先启动
  - 控制 BIOS 是否被允许执行
  - 持续监督系统运行

TPCM 工作流程

graph TB  POW[上电] --> TPCM[TPCM 优先启动]  TPCM --> CHECK[校验 BIOS 完整性]  CHECK -- 通过 --> RUN[允许 BIOS 执行]  CHECK -- 不通过 --> BLK[阻止系统启动 / 告警]  RUN --> MON[运行时持续监督
主动度量]  MON -- 发现异常 --> ACTION[报警 / 隔离 / 重启]

关键差异：     
  - TPM 等"度量后请求"的方式：     CPU 主动询问 TPM 是否 OK
  - TPCM 等"主动控制"：     TPCM 自己决定 CPU 能不能跑
  
理论上 TPCM 比 TPM 更安全——硬件级"看门狗"。

实际部署：     
  - 政府 / 国央企 / 关基系统
  - 等保 2.0 / 3.0 三级及以上
  - 部分电网 / 银行 / 军方
  
争议：     
  - 与国际 TCG 标准不同
  - 国际生态较弱
  - 但在国内信创市场是确定的需求

海光 CSV（China Secure Virtualization）

8.3 已介绍——海光 EPYC 衍生 CPU 的 SEV 国密版：

graph LR  S1[CSV1
2020
仅内存加密] --> S2[CSV2
2021
+ 寄存器加密]  S2 --> S3[CSV3
2023
+ 完整性 + 防回滚]

CSV 系列：     
  CSV1：    SM4 加密 DRAM，对应 SEV
  CSV2：    + 寄存器加密，对应 SEV-ES
  CSV3：    + 完整性 + 嵌套页表保护，对应 SEV-SNP

用 SM4 不是 AES：     
  - DRAM 内存加密用 SM4-128
  - 满足国密要求
  - 性能与 AES 相当（硬件实现）

应用：     
  - 海光 + 麒麟 / 欧拉 / UOS：信创机密计算
  - 与海光 DCU 配合做 GPU TEE
  - 阿里 / 腾讯云国产化区域使用

待补充：海光 CSV 实际部署规模和案例。

鲲鹏 iTrustee

华为 / 海思系：

鲲鹏 iTrustee：     
  - ARM TrustZone 上的 Secure World OS
  - 华为自研
  - 与昇腾 / 鲲鹏 / 麒麟深度集成
  
secGear SDK：     
  - 华为开源 confidential computing 编程框架
  - 抽象 Intel SGX / TrustZone / 鲲鹏 / 海光
  - 跨 TEE 应用编程
  
应用：     
  - 华为云机密计算服务
  - 政企 / 金融 / 运营商
  - 鲲鹏 + 麒麟 V10 标配

飞腾 PSPA

飞腾 PSPA（Phytium Security Processing Architecture）：     
  - 飞腾自家"可信路线"
  - 基于 ARM TrustZone
  - 与麒麟 / UOS 配套
  - PSPA 协处理器集成在 SoC 内

待补充：飞腾 PSPA 详细规格和成熟度。

龙芯安全方案

龙芯（LoongArch 架构）：     
  - 自研可信计算扩展
  - 与中科方德 / 麒麟适配
  - GUKI 安全 OS（中科方德）
  - 国产可信芯片

特点：     从指令集到 OS 全栈自主
应用：     军方 / 关基核心系统

待补充：龙芯可信计算具体实现细节。

申威 / 兆芯

申威（SW64）：     
  - 国防 / 关基
  - 全自主指令集
  - 自带可信扩展

兆芯（x86）：     
  - 通过 VIA x86 授权
  - 部分通用 + 国密扩展

国产可信计算的标准体系

GB/T 29827-2013：     可信计算规范——TCM
GB/T 29828-2013：     可信连接架构（TCA）
GB/T 29829-2013：     TCM 服务模块（TSM）
GB/T 36639-2018：     可信计算规范——服务器可信支撑平台
GB/T 41388-2022：     机密计算技术框架
GB/T 39786-2021：     信息系统密码应用基本要求

等保 2.0 / 3.0：     
  - 三级以上要求"可信验证"
  - 启动时验证 BIOS / Bootloader
  - 运行时验证关键应用
  - 可信验证记录留存

关键信息基础设施保护条例（2021）：     
  - "关基"必须有可信验证
  - 涵盖电力 / 金融 / 交通 / 政务等

信创可信计算栈

graph TB  L1[硬件层]  L1 --> H1[CPU：海光 / 鲲鹏 / 飞腾 / 龙芯]  L1 --> H2[TCM / TPCM 芯片]  L1 --> H3[GPU：海光 DCU / 昇腾]    L2[固件层]  L2 --> F1[国产 BIOS / UEFI]  L2 --> F2[Secure Boot 国密签名]    L3[OS 层]  L3 --> O1[麒麟 V10 / openEuler / UOS / 龙蜥]  L3 --> O2[IMA + 国密验证]    L4[应用层]  L4 --> A1[国密 OpenSSL（GmSSL）]  L4 --> A2[国产数据库 / 中间件]    L5[监管面]  L5 --> M1[CCRC 认证]  L5 --> M2[国密局认证]  L5 --> M3[等保测评]

国密算法在可信计算

SM2：     椭圆曲线公钥（256-bit），对应 ECDSA
SM3：     哈希（256-bit），对应 SHA-256
SM4：     对称加密（128-bit），对应 AES-128
SM9：     标识密码（基于双线性对），无国际等价

可信启动用法：     
  - SM3 哈希 PCR Extend
  - SM2 签名 attestation
  - SM4 加密 LUKS / DRAM

TPM 2.0 标准支持自定义 hash 算法：     
  → TPM 厂家可以做"国密版 TPM"（也叫 TCM 升级版）
  → 同一颗芯片支持 SHA-256 + SM3 双 PCR bank

国产 OS 中的可信适配

openEuler

openEuler 22.03 LTS：     
  - secGear（机密计算 SDK）
  - shimx64.efi 国密签名
  - GRUB / kernel 适配 SM2/SM3
  - IMA + EVM 国密版本
  - 与海光 CSV / 鲲鹏 iTrustee 集成
  
工具链：     
  - tpm2-tss + 国密扩展
  - keylime 国密版

麒麟 V10

银河麒麟 V10 SP3：     
  - 默认启用国密 Secure Boot
  - TCM / TPCM 标配
  - 等保 3 级合规
  - 国密 OpenSSL（GmSSL）
  - 国密 SSH

与 PKI 集成：     
  - SM2 数字证书
  - 与中国电子签名服务对接

统信 UOS

UOS Server V20 / V21：     
  - 部分支持 TCM
  - 与海光 / 鲲鹏 / 飞腾全适配
  - 等保 / 国密合规

应用场景

党政信息系统

要求：     
  - 等保 3 级及以上
  - TCM / TPCM 启用
  - 全栈国产 + 国密
  
典型部署：     
  - 海光 + 麒麟 V10 + TPCM
  - openEuler + 鲲鹏 + iTrustee
  - 飞腾 + UOS + TCM

央国企生产系统

银行核心系统：     
  - 国密 SSL（OpenSSL → GmSSL）
  - 数据库国密（GaussDB / OceanBase 国密版）
  - HSM 用国密
  - 部分用 TEE（海光 CSV / 鲲鹏）
  
电力调度系统：     
  - TPCM 主动可信
  - 电网信创目录
  - 边界网关国密

军方 / 关基

要求：     
  - 等保 4 级
  - 自主可控（指令集 + 全栈）
  - 龙芯 / 申威优先
  - 自研可信芯片
  
典型部署：     
  - 龙芯 + 中科方德 + 自研可信
  - 申威 + 凝思 / 麒麟信安

国产可信计算的挑战

1. 国际生态弱：     
   - TCM / TPCM 与 TCG 不完全兼容
   - 跨厂家工具少
   - 学术研究少
   
2. 应用兼容：     
   - 国密 OpenSSL 替代国际版
   - 国产中间件 / 数据库适配
   - 应用层移植成本

3. 性能：     
   - SM2 / SM4 性能稍逊 RSA / AES（差距小）
   - SM3 与 SHA-256 相当
   - 国密硬件加速覆盖度不如 AES-NI

4. 工具链：     
   - 调试 / profiling 工具少
   - 与开源社区互动有限
   - 标准更新慢

5. 主动可信路线分歧：     
   - TPCM 仅国内推
   - 国际厂家不实现
   - 跨国企业落地难

国产可信计算的优势

1. 监管确定性：     
   - 信创目录 / 等保 2.0 / 关基保护条例
   - 一定数量的政企采购"必带"
   
2. 全栈自主：     
   - 从指令集到 TEE 全栈自研
   - 不被外部"卡脖子"

3. 与国密深度结合：     
   - SM2 / SM3 / SM4 / SM9 硬件加速
   - 国密合规直接达成

4. 主动可信创新：     
   - TPCM 是国内创新点
   - 未来可能反向输出

工具与命令

# 看 TCM 支持
ls /dev/tcm*
cat /sys/class/tcm/tcm0/version

# 国密 OpenSSL（GmSSL）
gmssl version
gmssl sm3 -in file.txt
gmssl sm2sign -in file.txt -inkey sm2.pem

# 海光 CSV 检测
dmesg | grep -i csv
ls /dev/csv-guest

# 鲲鹏 iTrustee（OP-TEE 衍生）
optee-supplicant status

# secGear（华为机密计算 SDK）
secgear-cli list-tee

一些查询

# 看 CPU 是否支持国密扩展
grep -E "sm3|sm4|sm9" /proc/cpuinfo

# 看 TPM 是否双 bank（SHA-256 + SM3）
tpm2_pcrread sha256:0,1,2
tpm2_pcrread sm3_256:0,1,2

# 安装国密支持
# openEuler：     
dnf install GmSSL openssl-gmssl
# 麒麟 V10：     
yum install GmSSL kysec

业界进展

2022-2024：     
  - 信创采购爆发期
  - TCM / TPCM 上量
  - 海光 CSV 商用化
  - 鲲鹏 iTrustee 进入华为云

2024-2026：     
  - 万节点级国产可信集群
  - 与机密计算 / 多方计算结合
  - GPU TEE（海光 DCU + CSV）

2026+：     
  - 全栈机密计算（海光 / 鲲鹏 + 国密）
  - 国密 + 国际标准互认
  - 信创 + 关基的可信网络（TNC）

待补充：实际项目国产可信计算选型经验。

与国际方案对比

国际	国产对应	现状
TPM 2.0	TCM 2.0（GB/T 29827-2024 进化中）	TCM 已成熟
Intel TDX	海光 CSV3	海光 CSV 已商用
AMD SEV-SNP	海光 CSV3	兼容 SEV
Intel SGX	鲲鹏 iTrustee（不同模型）	进程级 vs VM 级
ARM TrustZone	鲲鹏 iTrustee / 飞腾 PSPA	同根 ARM
ARM CCA	鲲鹏 + 国密版 CCA（探索）	未量产
TPM Quote	国密 attestation	标准化进行中

一些”国产可信”的真实落地

国家电网调度系统：     
  - 全栈国产 + TPCM 主动可信
  - 等保 4 级
  - 千节点级

中国银联：     
  - 海光 + 麒麟 + 国密
  - 部分核心系统

某省级政务云：     
  - 鲲鹏 + 麒麟 + iTrustee
  - 与机密计算结合

军工 / 国防系统：     
  - 龙芯 / 申威 + 自研可信
  - 全脱网部署

待补充：你公司或项目的国产可信选型实际情况。

一些数字直觉

TPCM 启动：     
  +1-3 秒（主动验证 BIOS）
  
海光 CSV 启动：     
  类似 SEV，+2-3 秒

国密 vs 国际：     
  SM2 签名 vs ECDSA：    几乎相同
  SM3 哈希 vs SHA-256：    几乎相同
  SM4 加密 vs AES-128：    硬件加速后接近

实际部署成本：     
  TCM 芯片：    单颗几十元 RMB
  TPCM 模块：    数百元 RMB
  海光 CSV：    随海光 CPU 免费
  鲲鹏 iTrustee：    随 SoC 免费

小结

国产可信计算分两条路线：TPM 2.0 + 国密 / TCM-TPCM 主动可信
TCM 是国密版 TPM，TPCM 是”主动可信”创新
海光 CSV 是国密版 SEV，鲲鹏 iTrustee 基于 ARM TrustZone
国密算法 SM2/3/4/9 全栈替换 RSA/SHA/AES
信创 / 等保 / 关基是主要驱动力
全栈自主优势 + 国际生态弱势是当前现状
应用：党政、央国企、银行、电力、军方

下一篇是第八章收口——可信计算选型与第八章小结。

机密计算 —— Confidential VM 与 Confidential Container

2026-03-22T12:40:00.000Z

第 8.3 讲了 TEE 技术（SGX / TDX / SEV / TrustZone）。本篇讲它们的”产品形态”——云上的 Confidential VM、Confidential Container，以及实际业务应用。

Confidential Computing 的定义

Confidential Computing Consortium 定义：     
  "Protection of data in use by performing 
   computation in a hardware-based, 
   attested Trusted Execution Environment."

核心三要素：     
  1. 硬件 TEE
  2. 远程证明（attested）
  3. 运行时数据保护（data in use）

数据三种状态

graph TB  D[数据]  D --> R1[At Rest 静态
磁盘加密 LUKS / S3]  D --> R2[In Transit 传输
TLS / IPsec]  D --> R3[In Use 使用
过去无解 → 现在 TEE]

数据”使用中”加密——这是机密计算填补的空白。

Confidential VM（CVM）

主流云的 CVM 产品

云	产品	底层
Microsoft Azure	DCe / DCa / ECe / ECa 系列	Intel TDX / AMD SEV-SNP
Google Cloud	Confidential VM C2D / N2D	AMD SEV / SEV-SNP / TDX
AWS	Nitro Enclaves（限制版本）	Nitro 自家 + SEV
阿里云	ECS 安全增强型	TDX / SEV / 海光 CSV
腾讯云	TKE 机密计算	SEV / 海光 CSV
华为云	鲲鹏 + iTrustee	TrustZone

启动 Confidential VM 的流程

graph LR  U[用户提交 VM 模板] --> H[CSP Hypervisor]  H --> CR[创建加密 VM
注入 vTPM / TDX module]  CR --> BOOT[VM 启动 + Measured Boot]  BOOT --> AT[VM 调 Quote API
得到 Attestation Report]  AT --> US[用户拿到 Report]  US --> VER[用户验证签名 + PCR]  VER --> KEY[确认可信 → 注入业务密钥]  KEY --> APP[业务运行]

关键点：

1. 用户不信任 CSP / Hypervisor
2. CSP 看不到 VM 内存
3. 用户先验证 attestation，再决定是否注入数据 / 密钥
4. 整个流程"硬件 + 协议"保证

简单 Demo：Azure Confidential VM

# Azure CLI 创建 Confidential VM
az vm create \
  --resource-group myRG \
  --name myCVM \
  --image Ubuntu2204 \
  --size Standard_DC4ads_v5 \  # SEV-SNP
  --security-type ConfidentialVM \
  --enable-vtpm true \
  --enable-secure-boot true

# 在 VM 内取 attestation
sudo apt install snp-guest-tools
snp-guest-report report.bin

# 验证
snp-guest verify report.bin

Confidential Container（CoCo）

容器粒度的机密计算：

graph TB  K8S[K8s API]  K8S --> CC[Confidential Container]  CC --> KATA[Kata Container 运行时]  KATA --> TDX_VM[TDX / SEV-SNP VM]  TDX_VM --> POD[Pod 容器]

CoCo 项目（CNCF）

Confidential Containers（CoCo）：     
  - K8s 上跑机密容器的开源项目
  - 基于 Kata Containers 改造
  - 支持 SGX / TDX / SEV-SNP / CCA
  - 红帽 / Intel / IBM / Microsoft 共同推动
  
工作流：     
  1. K8s 调度 Pod
  2. CoCo 运行时启动加密 VM
  3. VM 内 kata-agent 启动容器
  4. 远程证明触发
  5. 业务镜像解密 + 运行

CoCo 与普通容器对比

普通容器：     
  - 共享内核
  - Host root 能 dump 进程内存
  - 不可信

CoCo（基于 TDX/SEV-SNP）：     
  - 每 Pod 一个加密 VM
  - 内核独立
  - Host 看不到 VM 内存
  - 远程证明
  - 启动比普通容器慢 2-5 秒
  - 资源占用比普通容器多一些

镜像保护

普通容器镜像：     公开（registry 直接拉）
CoCo 加密镜像：     
  - 用密钥加密 layer
  - 远程证明通过后才下发解密 key
  - 镜像层只在 enclave 内解密
  
工具：     
  Skopeo + ocicrypt：    加密 OCI 镜像
  KBS（Key Broker Service）：    远程证明 + key 分发

Nitro Enclaves（AWS）

AWS 走的是不一样的路线：

Nitro Enclaves：     
  - 不基于 SGX / TDX / SEV
  - 基于 AWS Nitro 自研 Hypervisor
  - 隔离 vCPU + RAM 给 enclave
  - 无网络、无持久化（只 vsock）
  - 通过 Nitro 远程证明 API

应用：     
  - 金融业（合规要求高）
  - 区块链私钥
  - DRM 内容保护

特点：     不需要特殊 CPU，只要 EC2

待补充：Nitro Enclaves 与 SEV-SNP 实测对比。

NVIDIA Confidential Computing（GPU TEE）

H100 引入的 GPU 机密计算：

graph LR  CVM[Confidential VM
TDX/SEV-SNP] -.- |加密 PCIe| GPU[H100/B200
Confidential Mode]  GPU --> ENC[GPU 显存加密]

H100 Confidential Mode：     
  - GPU 内存加密
  - PCIe 总线密文
  - 与 TDX VM 配合
  - vGPU 内 attest GPU 状态
  - 性能损失 ~5-10%

应用：     
  - 多方训练（数据所有者不信 CSP）
  - 模型权重保护
  - 监管 / 合规 AI

支持栈：     
  CUDA 12.x+
  NVIDIA Driver R535+
  与 Microsoft Azure / GCP 联动

业务应用

1. 多方计算（MPC）/ 联邦学习

graph TB  P1[参与方 A 数据]  P2[参与方 B 数据]  P3[参与方 C 数据]    P1 --> CVM[Confidential VM
多方都不信任的 CSP]  P2 --> CVM  P3 --> CVM    CVM --> RESULT[联合训练结果]

传统 MPC：     全密文计算（HE / 秘密分享），慢
TEE 替代：     明文进 enclave，性能近原生
应用：     
  - 银行间联合反欺诈
  - 医院联合医疗 AI
  - 跨集团 / 跨国数据合作

2. 数据安全屋（Data Clean Room）

广告主 + 媒体方：     
  - 双方都有用户数据
  - 想合并分析但不公开各自数据
  - 把数据进 Confidential VM
  - 在里面联合查询 / 建模
  - 输出仅汇总结果
  
代表产品：     
  AWS Clean Rooms
  Snowflake Data Clean Room
  Google Ads Data Hub
  阿里云 / 腾讯云的 Privacy-Preserving Computing

3. 区块链 / Web3 私钥

传统区块链节点：     私钥在内存 → 攻击面大
TEE 节点：     
  - 私钥永远不出 enclave
  - 签交易在 enclave 内
  - 即使 root 也偷不到

代表：     
  - Hyperledger Avalon
  - Microsoft Confidential Consortium Framework (CCF)
  - 各家区块链的"硬件钱包"

4. 监管合规

GDPR / HIPAA / 金融数据保护法：     
  - "数据所有者不信任云"是常见诉求
  - Confidential VM 提供"我可以用云但不让 CSP 看见"
  - 部分行业法规已认可 Confidential Computing 为合规手段
  
中国：     
  - 个人信息保护法（PIPL）
  - 关键信息基础设施保护
  - 信创 + 等保对机密计算有要求

5. 大模型推理保护

场景：     
  - 客户上传数据用 LLM 推理
  - 不希望 CSP / 服务商看到 prompt 和结果
  - 也不希望模型被偷
  
解决：     
  - Confidential VM + Confidential GPU
  - prompt / model / output 全程加密
  - 远程证明保证

代表：     
  Microsoft Azure Confidential AI
  NVIDIA Confidential AI
  阿里云、华为云类似产品

CoCo 与 Service Mesh

graph TB  CL[客户端]  CL -->|TLS| GW[网关]  GW -->|mTLS| SVC1[CoCo Pod 1]  GW -->|mTLS| SVC2[CoCo Pod 2]    SVC1 -.- AT[Attestation Service]  SVC2 -.- AT

机密计算 + Service Mesh：     
  - 每个微服务跑在 CoCo
  - 服务间 mTLS + attestation 双重验证
  - 端到端加密 + 端到端可信
  
挑战：     
  - 启动慢（每 Pod 一 VM）
  - 资源开销
  - 调试困难

远程证明的”两层”

graph TB  L1[第一层：硬件 attestation]  L1 --> Q1[Intel TDX Quote / AMD SEV-SNP Report]  Q1 --> CPU[CPU 厂家签名]  CPU --> ROOT[Intel / AMD 根证书]    L2[第二层：业务 attestation]  L2 --> Q2[包含业务公钥 / hash]  Q2 --> APP[应用层验证]

第一层硬件证明 + 第二层业务证明 = 端到端可信。

标准化进展

IETF RATS（Remote ATtestation procedureS）：     
  - 跨厂家 attestation 协议
  - EAT（Entity Attestation Token）
  - CWT / JWT 风格

CCC（Confidential Computing Consortium）：     
  - Open Enclave SDK
  - Veracruz
  - Confidential Containers
  - 跨平台 SDK

Linux Kernel：     
  - kvm/coco：    内核 CoCo 子系统
  - tdx-guest / sev-guest 驱动

国内标准：     
  - GB/T 41388（机密计算技术框架）
  - 工信部、信通院推
  - 国家可信云体系

部署的几个老坑

坑 1：性能预期错位

Confidential VM：     
  - 内存加密：    带宽降 5-10%
  - 启动慢：     +几秒
  - 适合稳态业务，不适合频繁启停
  
CoCo（每 Pod 一 VM）：     
  - 启动 2-5 秒
  - 资源占用比普通 Pod 多
  - 大规模 Job 调度成本高

坑 2：迁移复杂

普通 VM → Confidential VM：     
  - 部分老镜像不兼容（缺驱动）
  - kernel 要支持 TDX guest / SEV guest
  - GRUB / initrd 要支持 attestation 流程
  
建议：     用 CSP 提供的官方镜像起步

坑 3：远程证明实现门槛高

要正确实现：     
  - Attestation 库（rats / ratls）
  - 签名链验证
  - 撤销列表查询
  - TCB 版本管理
  - Nonce 防重放
  
开源工具：     
  Veraison（Linux Foundation）
  Microsoft Maa
  Intel Trust Authority
  阿里 vSGX / 龙蜥 attestation

坑 4：密钥分发服务（KBS）

"远程证明通过 → 给密钥"——这个 KBS 怎么部署？     
  - 自建：     高可用 + 安全（KBS 本身要 TEE）
  - 用 CSP 服务：    依赖 CSP

正确实现：     
  - KBS 自己跑在 Confidential VM
  - 密钥分级（root key 在 HSM，业务 key 派生）
  - 严格审计

坑 5：调试困难

Confidential VM 内：     
  - 无法 console attach
  - 无法 strace / gdb（attestation 不通过会拒）
  - dmesg 看不到内核启动
  
调试模式：     
  - SEV-SNP / TDX 都有 "debug" 选项
  - 但 attestation TCB level 不一样
  - 不能用于生产

监控与可观测

传统 VM：     
  Hypervisor 看 / IPMI / cAdvisor

Confidential VM：     
  - Hypervisor 看不到内部
  - 必须从内部上报 metrics
  - 但要保护 metrics 不被监控泄露

实践：     
  - Prometheus 客户端跑在 CVM 内
  - 加密上报到外部存储
  - 业务侧分析

CSP 信任假设

graph TB  T1[传统 VM]  T1 --> N1[Trust 链：你 → CSP → 物理机]    T2[Confidential VM]  T2 --> N2[Trust 链：你 → CPU 厂家 → 物理机硬件]  T2 -.- |不 trust| CSP[CSP 软件 / Hypervisor / Host OS]

Confidential Computing 不能：     
  - 防御 CPU 厂家后门
  - 防御 Quote 服务被劫持
  - 防御侧信道（理论上）
  - 抵抗物理 / 实验室级攻击
  
能做的：     
  - 防御 CSP 内部威胁（恶意管理员）
  - 防御 Hypervisor 入侵
  - 防御 Host OS 入侵
  - 满足合规要求

监管 / 合规中的位置

中国：     
  - 关基设施保护：     等保 3+ 鼓励 TEE
  - 个保法：    敏感数据处理推荐
  - 信创目录：    部分项目要求

欧洲：     
  - GDPR：    Confidential Computing 是隐私技术
  - eIDAS 2.0：    欧盟数字身份
  
美国：     
  - HIPAA / SOC2：    医疗 / 金融
  - FedRAMP：    政府云
  - DoD IL5/IL6：    国防场景

价格

Microsoft Azure Confidential VM：     
  - 标准 VM 价格 + 10-20% 溢价
  
Google Confidential VM：     
  - 标准 VM 价格 + 5-15%
  
阿里云 / 腾讯云：     
  - 类似溢价

CoCo 容器：     
  - 同价但资源占用多

待补充：实际项目机密计算的成本预算。

一些查询命令

# Confidential VM 内部：     
# AMD SEV-SNP
sudo dmesg | grep -i sev
ls /dev/sev-guest
snp-guest-report report.bin

# Intel TDX
sudo dmesg | grep -i tdx
ls /dev/tdx_guest

# CoCo 项目
kubectl get nodes -L node.kubernetes.io/instance-type
kubectl get runtimeclass

# Pod yaml 用 CoCo：     
spec:
  runtimeClassName: kata-qemu-tdx
  containers:
  - image: 

# 远程证明
veraison-verify report.bin

几个权威资源

Confidential Computing Consortium：     
  https://confidentialcomputing.io/

Linux Kernel CoCo 文档：     
  Documentation/virt/coco/

Project documentation：     
  - Intel TDX：    intel.com/sgx
  - AMD SEV：     developer.amd.com/sev/
  - ARM CCA：     developer.arm.com/cca

学术论文：     
  IEEE S&P / USENIX Security 上每年都有 TEE 攻击 / 防御论文

一些数字直觉

Confidential VM 启动：     
  Azure DCa：    +3-5 秒（attestation）
  GCP C2D：     +2-3 秒
  
CoCo Pod 启动：     
  +5-10 秒（VM + attestation + 解密镜像）
  
性能：     
  纯 CPU 业务：    < 5% 损失
  内存密集：     5-10% 损失
  IO 密集：     可能更高（vsock）
  GPU 业务（H100 confidential）：    +5-10%

实际可用规模（2026）：     
  Confidential VM：    数十万节点（Azure / GCP / 阿里）
  CoCo：              小规模（几千 Pod）
  Confidential GPU：    刚起步

小结

机密计算 = TEE 的产品形态
Confidential VM 是主流方向（TDX / SEV-SNP）
Confidential Container 是 K8s 上的探索（CoCo）
远程证明 + KBS 是核心信任链
多方计算 / 联邦学习 / 数据安全屋是主要业务场景
NVIDIA H100 Confidential Mode 是 GPU TEE 起点
性能开销 < 10%，启动慢几秒
满足 GDPR / HIPAA / 信创等合规需求

下一篇讲国产可信计算——海光 CSV、鲲鹏 iTrustee、TPCM、TCM 等国密路线。

TEE —— SGX、TDX、SEV、TrustZone

2026-03-15T06:55:00.000Z

TPM 解决的是”启动可信”，但启动后内存仍然透明——OS、Hypervisor、root 用户都能 dump 内存。TEE（Trusted Execution Environment） 在 CPU 内开辟”加密飞地”，让运行时数据也”硬件加密”。本文展开各家 TEE。

TEE 的核心思想

graph TB  subgraph WITHOUT["传统模式"]    OS[OS / Hypervisor / root
都能看 / 改 进程内存]  end    subgraph WITH["TEE 模式"]    TEE[加密飞地内存]    TEE -.- |"只有 enclave 内代码能访问"| OUT[OS / 攻击者看不到]  end

TEE 的目标：

1. 内存加密：     enclave 内存硬件级加密，OS 看不到明文
2. 完整性保护：    enclave 代码 / 数据被改 → CPU 拒绝执行
3. 远程证明：     远端可验证 "我在某个 TEE 里跑了某段代码"
4. 隔离：     不同租户 / 进程的 enclave 互相隔离

TEE 的几种主流路线

graph TB  TEE[TEE 路线]  TEE --> P1[进程级
一个进程内的飞地]  TEE --> P2[VM 级
整个 VM 加密]  TEE --> P3[安全世界级
独立"安全 OS"]    P1 --> SGX[Intel SGX]    P2 --> TDX[Intel TDX]  P2 --> SEV[AMD SEV / SEV-SNP]  P2 --> CCA[ARM CCA]  P2 --> CSV[海光 CSV]    P3 --> TZ[ARM TrustZone]  P3 --> SE[Apple Secure Enclave]

Intel SGX（Software Guard Extensions）

最早商用的进程级 TEE，2015 年 Skylake 引入：

graph TB  PROC[用户进程]  PROC --> EN[Enclave 飞地]  EN --> EPC[EPC 加密内存]    OS[OS 内核]  OS -.- |看不到 Enclave 内存| EN

SGX 工作机制

1. 应用启动：     普通进程
2. 创建 Enclave：    
   - ECREATE 指令分配加密内存（EPC）
   - 加载 Enclave 代码 + 数据
   - EINIT 锁定，从此 OS 看不到内存

3. 进入 Enclave：    
   - EENTER 指令切入 enclave
   - 在 enclave 内执行受保护代码
   
4. 退出：     EEXIT 回到普通模式

EPC 内存：     
  - CPU 访问时 MEE（Memory Encryption Engine）解密
  - DRAM 中存的是密文
  - DMA / 总线嗅探拿不到明文

SGX 的限制

EPC 大小：     
  - SGX1：128 MB（Skylake/Coffee Lake，物理上限）
  - SGX2：512 MB - 1 GB（Ice Lake Server）
  - SGX 3rd gen：    几十到几百 GB（Sapphire Rapids，2023+）

性能开销：     
  - 加密 / 完整性校验：    内存访问慢 30-50%
  - 进入 / 退出 Enclave：    几千 CPU cycles
  - 不适合大数据集计算
  
攻击：     
  - Foreshadow（2018）：    侧信道泄露
  - LVI / Plundervolt：    其他 CVE
  - 这些已修复但生态信心受损

SGX 的应用

密钥管理 KMS：     
  - 在 enclave 内做加密 / 签名
  - 即使 root 也偷不到密钥
  
区块链 / Confidential Computing：     
  - Microsoft Azure Confidential Containers（早期）
  - Hyperledger Avalon
  - Intel ISV 生态

数据库加密：     
  - SQL Server Always Encrypted
  - Microsoft Azure SQL Confidential
  
SDK：     
  - Intel SGX SDK
  - Open Enclave SDK（Microsoft）
  - Gramine（项目）：    把整个 Linux 应用塞进 SGX

2022+ Intel 缩减消费级 SGX：     
  - 11th gen 桌面 CPU 起取消 SGX
  - 服务器仍然支持
  - 重心转向 TDX

Intel TDX（Trust Domain Extensions）

TDX 是 SGX 的”VM 级”继任者，2023 年 Sapphire Rapids 商用：

graph TB  HV[Hypervisor / Host OS
不可信]    HV --> TD1[TD 1
Trust Domain VM]  HV --> TD2[TD 2]  HV --> TD3[TD 3]    TD1 -.- HV

TDX 工作机制

1. TDX Module：     CPU 内的固件，管理 TD
2. Trust Domain：     一台加密 VM
   - VM 内存全部加密（MK-TME）
   - VM 寄存器在切换时加密保存
   - Hypervisor 不能读 VM 内存
   
3. 远程证明：     
   - TDX Quote 包含 TD 启动哈希
   - 远端验证 TD 是真 TDX 且内容正确

整个 VM 是 TEE：     
  - 应用不需要重写
  - Linux / Windows / 数据库 等都能跑
  - 性能开销 < 5%（内存加密硬件级）

TDX 的优势 vs SGX

SGX：     
  - 应用要拆 enclave 部分
  - EPC 大小受限
  - 编程复杂

TDX：     
  - 整 VM 加密
  - 应用无需修改
  - 大内存友好
  - 可跑大模型推理 / 训练
  - 客户场景普适

TDX 在云上

Azure DCe / DCa（2024+）：    Confidential VM 用 TDX
GCP Confidential VM：         TDX 选项
阿里云 ACK Confidential：      TDX 适配中

应用：     
  - 多方计算 / 联邦学习
  - 数据安全房 (Data Clean Room)
  - 监管合规（GDPR / HIPAA）

待补充：TDX 实际生产部署规模 2025-2026 数据。

AMD SEV / SEV-ES / SEV-SNP

AMD 的”VM 级 TEE”路线，比 TDX 早：

graph LR  S1[SEV
2017
仅内存加密] --> S2[SEV-ES
2019
+ 寄存器加密]  S2 --> S3[SEV-SNP
2021
+ 完整性 + 防回滚]

SEV（2017）

- AMD EPYC 第 1 代 Naples 起
- AES-128 加密 DRAM
- 每 VM 一个 VEK（VM Encryption Key）
- Hypervisor 看到密文
- 但寄存器 / 中断未加密

SEV-ES（Encrypted State，2019）

1
2
3

- VM 进出时 CPU 寄存器也加密保存
- 防止 Hypervisor 通过 vmexit 偷状态
- AMD EPYC 第 2 代 Rome 起

SEV-SNP（Secure Nested Paging，2021）

- 加完整性保护：     防止 Hypervisor 改 VM 内存
- RMP（Reverse Map Table）：    每页归属验证
- 防回滚攻击
- 远程证明完整支持
- AMD EPYC 第 3 代 Milan 起

最完整的 AMD VM-level TEE 方案

SEV-SNP 在云上

Microsoft Azure DCasv5（基于 SEV-SNP）：     已大规模部署
GCP Confidential VM（C2D / N2D）：           SEV
AWS：                                         自家 Nitro 等价能力
阿里云 / 腾讯云：                             SEV-SNP 选项

SEV 比 TDX 早 6 年商用——AMD 在 Confidential VM 市场领先。

ARM TrustZone

ARM 的”安全世界”路线，2003 年起：

graph TB  ARM[ARM CPU]  ARM --> NW[Normal World
普通 OS]  ARM --> SW[Secure World
独立安全 OS]    NW --> NS_OS[Linux / Android]  SW --> S_OS[OP-TEE / Trusty / 国产 TEE]

TrustZone 工作模式

CPU 双世界：     
  - Normal World（NS）：    Linux / Android
  - Secure World（S）：     一个完全独立的安全 OS

切换：     SMC 指令进入 Secure Monitor

Secure World 内：     
  - 独立内核（OP-TEE / TrustyTEE / 国产 TEE）
  - 独立 RAM 区域
  - 独立外设访问

应用：     
  - 移动支付（Apple Pay / Samsung Pay）
  - 指纹 / 人脸数据
  - DRM 视频
  - 部分服务器场景

服务器场景

ARM 服务器（Ampere / Graviton / 鲲鹏 / 飞腾）：     
  - TrustZone 仍存在
  - 但服务器 TEE 主要看 CCA
  
TrustZone 在服务器侧用得少——主要是嵌入式 / 移动场景。

ARM CCA（Confidential Compute Architecture）

ARM 在服务器市场对位 TDX / SEV-SNP 的方案：

ARM CCA（v9 引入，2021）：     
  - Realm 模式（VM 级 TEE）
  - RMM（Realm Management Monitor）
  - 类似 TDX 思路
  - Realm VM 内存加密 + 完整性
  
状态（2026）：     
  - ARM v9 服务器 CPU 商用
  - 软件生态成熟中
  - 主流云厂家适配中

待补充：ARM CCA 实际商用部署案例。

海光 CSV（China Secure Virtualization）

海光 DCU 时讲过——这里重点讲 CSV：

海光 CSV：     
  - AMD SEV 国产授权 + 加密算法替换
  - SM4 加密 DRAM（不是 AES）
  - 与 SEV API 兼容
  - 海光 C86 / 7000 系列起支持

CSV1 / CSV2 / CSV3：     与 SEV / SEV-ES / SEV-SNP 对应

应用：     
  - 信创云
  - 国产机密计算
  - 政企客户

待补充：海光 CSV 实际部署规模。

鲲鹏 ITrustee

华为鲲鹏 / 麒麟 / 海思的 TEE：     
  - 基于 ARM TrustZone
  - 自研 Secure World OS（iTrustee）
  - 与昇腾 / 昇思深度集成
  
华为云 TEE：     
  - 鲲鹏 + iTrustee
  - 支持机密计算 SDK（secGear）

TEE 编程模型

Open Enclave SDK（跨平台）

1
2
3

// 编译为 enclave
oe_create_enclave("my_enclave.signed");
oe_call_enclave(enclave, "func", args);

支持 SGX / TrustZone / OP-TEE。

Gramine LibOS（容器化）

Gramine（前身 Graphene）：     
  - 把整个 Linux 应用塞进 SGX enclave
  - 不需要改代码
  - 性能损失但可用性好

graphene-direct：     非 SGX 也能跑（用于开发）

Confidential Computing Consortium（CCC）

Linux Foundation 旗下：     
  - Open Enclave SDK
  - Veracruz
  - Confidential Containers
  - SPDM 标准
  - 跨厂家 TEE 抽象层

远程证明（Attestation）的演进

graph TB  TPM[TPM 远程证明
启动状态]  TPM --> SGX_AT[SGX 远程证明
Enclave 状态]  SGX_AT --> TDX_AT[TDX/SEV-SNP 远程证明
VM 状态]  TDX_AT --> CCA_AT[ARM CCA 远程证明
Realm 状态]

SGX 远程证明：     
  - Intel Attestation Service（IAS）
  - 后来改 DCAP（Data Center Attestation Primitives）
  
TDX 远程证明：     
  - Intel Trust Authority
  - 跨云通用

SEV-SNP 远程证明：     
  - AMD KDS（Key Distribution Service）
  - SNP_REPORT 命令

工业标准趋同：     
  - IETF RATS（Remote ATtestation procedureS）
  - 跨厂家可互验

TEE 的性能数字

SGX：     
  Enclave 内 CPU 性能：     ~95%（小数据）
  大数据 / 跨 enclave IO：    50-70%
  Enclave 切换：             几千 cycles（~ μs 级）

TDX / SEV-SNP：     
  整 VM 性能损失：    < 5%（内存加密硬件级）
  启动 + 远程证明：    +几秒
  
TrustZone：     
  Secure World 切换：    几百 cycles
  适合短计算（密钥操作 / 验证）

CCA Realm：     
  类似 TDX，性能开销 < 5%（待实测验证）

TEE 的几个安全”老坑”

坑 1：侧信道攻击

SGX 历史：     Foreshadow / LVI / SGAxe / Plundervolt
TDX：          一些早期理论攻击
SEV：         Cipherleaks / Crossline

教训：     
  - TEE 不是"绝对安全"
  - 仍有侧信道 / 故障注入风险
  - 应用层仍需防护

坑 2：远程证明实现复杂

正确实现 attestation：     
  - 验证签名链（厂家根 → CPU 证书 → Quote）
  - 验证 PCR / MR 哈希匹配预期
  - 验证 nonce 防重放
  - 验证 TCB level 不旧
  - 验证撤销列表

错误实现：     
  - 跳过签名验证
  - 不验 nonce
  - 不查 TCB
  → 攻击者可重放或冒充

坑 3：性能预期错位

SGX 大内存应用：     性能崩
TDX 内存加密：       带宽降 5-10%
SEV-SNP：           类似

设计：     先 PoC 实测，再上生产

坑 4：CPU 错失支持

不是所有 CPU 都支持：     
  - SGX：Skylake+ 服务器
  - TDX：Sapphire Rapids+
  - SEV：EPYC 全系
  - SEV-SNP：Milan+
  - CCA：ARM v9
  - 桌面 / 老服务器：不支持

→ 采购前确认 CPU 支持

坑 5：CSP 与租户信任假设

TDX / SEV-SNP 实际信任假设：     
  - 租户 trust：CPU 厂家（Intel / AMD）
  - 不 trust：    Hypervisor / Host OS / CSP

但：     
  - CPU 厂家有后门? 
  - CPU 厂家 KMS 被入侵?
  - Quote 服务被劫持?
  
→ 现实中是"减少信任面"，不是"零信任"

TEE 与 GPU

GPU TEE 是新前沿：

NVIDIA Confidential Computing（H100+）：     
  - GPU 内存加密
  - PCIe 总线密文
  - 需配 TDX / SEV-SNP CPU
  - VM 与 GPU 端到端加密
  - 2024+ 量产

应用：     
  - 多方训练（数据所有者不信任 CSP）
  - 模型权重保护（推理服务防偷模）
  - 监管合规 AI 训练

待补充：NVIDIA H100 / B200 Confidential Computing 实际部署案例。

一些查询命令

# 看 SGX 支持
cpuid -1 | grep -i sgx
ls /dev/sgx_enclave

# 看 TDX 支持（CPU）
cat /proc/cpuinfo | grep -i tdx
dmesg | grep -i tdx

# 看 SEV 支持（AMD）
dmesg | grep -i sev
ls /dev/sev

# 看 TEE（ARM TrustZone）
ls /dev/tee*
ls /dev/teepriv*
optee-toolchain status

# CPU 加密能力
grep -E "aes|sha_ni|gfni|vaes" /proc/cpuinfo

# 启动参数验证
cat /proc/cmdline | grep -E "kvm_intel.tdx|kvm_amd.sev"

几个 TEE 选型场景

场景	选什么	理由
密钥保护 / KMS	SGX 或 HSM	小内存，强隔离
Confidential VM 大模型	TDX 或 SEV-SNP	整 VM 加密，无修改
数据库 Always Encrypted	SGX（部分操作）	进程级精细控制
移动应用支付	TrustZone	嵌入式 + 已成熟
多方计算 / 联邦学习	TDX / SEV-SNP + Confidential GPU	端到端加密
国产化机密计算	海光 CSV / 鲲鹏 iTrustee	信创要求

一些数字直觉

TEE 启动时间：     
  TDX VM：     比普通 VM 多 3-5 秒（attestation）
  SEV VM：     +2-4 秒
  SGX Enclave：    100-500 ms

价格溢价：     
  Confidential VM vs 普通 VM：    +10-20%
  Confidential GPU：              价格暂未公开，预计溢价显著

部署规模（2026）：     
  TDX / SEV-SNP：    主流公有云已量产
  海光 CSV：         国内信创规模化
  ARM CCA：         初始
  GPU TEE：         小规模

信任模型对比

graph TB  M1[传统模式]  M1 --> T1[trust：硬件 + 固件 + Hypervisor + OS + 应用]    M2[Confidential Computing]  M2 --> T2[trust：CPU 厂家硬件 + 固件 + 应用代码]  M2 --> NT2[不 trust：CSP / Hypervisor / Host OS]

TEE 把信任面从”整个云栈”缩到”CPU 硬件 + 固件”——这是机密计算的根本价值。

小结

TEE 让运行时数据”硬件加密”，连 OS / 攻击者也看不到
进程级 TEE： Intel SGX，灵活但 EPC 受限
VM 级 TEE： Intel TDX、AMD SEV-SNP、ARM CCA、海光 CSV，主流方向
安全世界： ARM TrustZone，移动 / 嵌入式
远程证明是 TEE 价值的关键
TDX / SEV-SNP 性能开销 < 5%
GPU TEE（NVIDIA Confidential Computing）是新前沿
国产路线：海光 CSV、鲲鹏 iTrustee

下一篇讲机密计算（Confidential Computing）—— TEE 在云上的实际产品形态。

Secure Boot、Measured Boot 与 IMA

2026-03-08T14:45:00.000Z

第 8.1 讲了 TPM 和 PCR——本篇讲怎么把它用起来。Secure Boot（验签防篡改）+ Measured Boot（度量记录）+ IMA（运行时完整性）= Linux 完整可信启动链。

三个机制对比

graph TB  M1[Secure Boot]  M1 --> R1[启动时验签
签名错就拒绝执行]    M2[Measured Boot]  M2 --> R2[启动时记录
哈希进 TPM PCR]    M3[IMA]  M3 --> R3[运行时验证
读文件时检查]

机制	时机	动作	失败后果
Secure Boot	启动	验签	拒绝启动
Measured Boot	启动	度量记录	不阻止启动，但 PCR 不同
IMA	运行	验签 / 度量	拒绝执行 / 报警

UEFI Secure Boot

graph LR  PK[Platform Key
主板厂家]  KEK[Key Exchange Key
OS 厂家]  DB[DB
允许的签名 / 哈希]  DBX[DBX
禁用的签名 / 哈希]    PK --> KEK --> DB  KEK --> DBX

UEFI Secure Boot 的密钥层次：

PK（Platform Key）：     主板厂家，根
KEK（Key Exchange Key）：     OS 厂家用，可签 DB / DBX
DB（Allowed DB）：     允许执行的签名 / 哈希列表
DBX（Forbidden DB）：     禁用的签名（吊销列表）

启动时验签流程：     
  1. UEFI 加载 Bootloader
  2. 检查 Bootloader 签名是否在 DB 中
  3. 是 → 加载执行
  4. 否 → 拒绝，停止启动

Microsoft 主导的 DB

默认 DB 包含：     
  Microsoft Windows Production CA
  Microsoft UEFI CA（用于第三方 OS）
  
Linux Bootloader（shim）签名：     
  shim 由 Microsoft UEFI CA 签
  shim 内嵌 Linux 厂家公钥
  shim 加载 GRUB → GRUB 验签 kernel → kernel 验 module

shim 是 Linux 在 Secure Boot 下的”信任桥梁”——所有发行版（RHEL / Ubuntu / SUSE）都用它。

自管 Secure Boot

# 装 shim 后看 Secure Boot 状态
mokutil --sb-state

# 看 MOK 列表（用户级密钥）
mokutil --list-enrolled

# 加自定义证书到 MOK
mokutil --import my_cert.crt
# 重启时设密码确认

# 完全清空 / 替换 PK / KEK / DB（高级用法）
sbkeysync --pk          # 设 PK
sbkeysync --keystore /etc/secureboot/keys

shim → GRUB → kernel 的验签

shim 启动后：     
  1. 检查 grubx64.efi 签名（用 shim 内嵌的发行版公钥）
  2. 通过 → 加载 GRUB
  
GRUB 启动后：     
  1. 检查 vmlinuz 签名
  2. 通过 → 加载 kernel
  
kernel 启动后：     
  1. 检查 .ko 模块签名（kernel 模块也要验签）
  2. 通过 → 允许加载
  
任何一步不通过 → 拒绝执行 → 启动失败

Secure Boot 的几个重要实践

# 启用 / 禁用 Secure Boot：BIOS 中
# 看当前状态
bootctl status

# 看 EFI 变量
mokutil --sb-state
efivar -l

# 自己签 kernel 模块
sbsign --key MOK.priv --cert MOK.crt --output module.ko.signed module.ko

Measured Boot

Secure Boot 是”二选一”——通过或不通过。Measured Boot 是”完整记录”——把每一步都哈希进 TPM。

graph TB  CRTM[CRTM] -->|度量并 Extend| PCR0[PCR 0]  BIOS[BIOS] -->|度量 Bootloader| PCR4[PCR 4]  GRUB[GRUB] -->|度量 kernel/initrd| PCR8[PCR 8]  GRUB -->|度量 cmdline| PCR9[PCR 9]  KER[Kernel] -->|度量初始化| PCR10[PCR 10]  IMA[IMA] -->|度量文件| PCR10b[PCR 10]

启动度量事件日志

UEFI 实现把每次”度量”事件记到日志，开机后 OS 可以看：

# 看 measured boot 事件日志
sudo tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements

# 输出例：
# Event:     EV_S_CRTM_VERSION
# PCR:       0
# Digest:    sha256: ...
# Data:      "BIOS Vendor v3.5"
# 
# Event:     EV_EFI_VARIABLE_DRIVER_CONFIG
# PCR:       7
# Digest:    sha256: ...
# Data:      Secure Boot State=1

事件日志 + 当前 PCR 值 = “可重放”——验证方可以独立验证启动链。

用 PCR 7 还是 PCR 0-4？

PCR 0-4：     度量具体的 BIOS / Bootloader / kernel 哈希
  → 任何 BIOS / kernel 升级都改值
  → 灵活性差
  
PCR 7：     仅度量 Secure Boot 状态（PK / KEK / DB / DBX 等）
  → 升级 kernel 时 PCR 7 不变
  → 推荐用 PCR 7 + Secure Boot 组合

LUKS + Measured Boot 实战

# 把 LUKS 密钥密封到 PCR 7（推荐）
systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/sda3

# 重启后自动解密：     
#   - Secure Boot 状态没变 → PCR 7 不变 → 解封成功
#   - Secure Boot 被禁 → PCR 7 变了 → 解封失败 → 提示输 fallback 密码

# 配合 dracut / mkinitcpio：     
#   /etc/crypttab：
#   root  UUID=...  none  tpm2-device=auto

# 紧急情况：备用恢复 key
cryptsetup luksAddKey /dev/sda3 recovery_key.txt

IMA：Linux 文件完整性

IMA（Integrity Measurement Architecture）是 Linux 内核的运行时完整性子系统：

graph TB  EXEC[执行 / mmap / open]  EXEC --> IMA[IMA Hook]  IMA --> CHECK{检查策略}  CHECK --> M[度量：写入 measurement list + Extend PCR 10]  CHECK --> A[Appraisal：验证签名 / 哈希]  CHECK --> AUDIT[审计：仅记录]    A --> R{验证通过?}  R -- 是 --> RUN[允许执行]  R -- 否 --> DENY[拒绝]

IMA 的三种模式：

1. 度量（Measurement）：     
   - 把文件哈希写入 /sys/kernel/security/ima/ascii_runtime_measurements
   - 同时 Extend PCR 10
   - 不阻止执行
   - 用于审计和远程证明
   
2. 评估（Appraisal）：     
   - 验证文件的扩展属性签名
   - 不通过 → 拒绝执行
   - 严格但需要预先签名

3. 审计（Audit）：     
   - 仅写日志

IMA 启用

# 启动参数（GRUB）
GRUB_CMDLINE_LINUX="ima_policy=tcb ima_template=ima-ng ima_hash=sha256"

# 重启后看 measurements
cat /sys/kernel/security/ima/ascii_runtime_measurements | head

# 例：
# 10 4d29...  ima-ng  sha256:abc...  /usr/bin/ls
# 10 8def...  ima-ng  sha256:def...  /usr/lib/libc.so.6

# 看当前 PCR 10
tpm2_pcrread sha256:10

IMA 度量后每个文件首次访问时都会哈希入 PCR 10——这就让”系统启动以来所有访问的文件”都被记录。

IMA 策略

# /etc/ima/ima-policy 例：
dont_measure fsmagic=0x9fa0           # 不度量 procfs
dont_measure fsmagic=0x62656572        # 不度量 sysfs
measure func=BPRM_CHECK                 # 度量 execve
measure func=FILE_MMAP mask=MAY_EXEC   # 度量可执行 mmap
measure func=MODULE_CHECK               # 度量内核模块
appraise func=POLICY_CHECK              # 验签策略文件

EVM：扩展属性签名

EVM（Extended Verification Module）：     
  - 验证文件的扩展属性 xattr（IMA 哈希、SELinux 标签等）
  - 防止单独篡改 xattr

启用：     
  GRUB_CMDLINE_LINUX="... evm=fix"  # 第一次自动签
  之后 evm=enforce

完整可信启动链的搭建

graph TB  S1[BIOS Secure Boot]  S1 --> S2[Bootloader 验签 kernel]  S2 --> S3[Kernel 验签 module]  S3 --> S4[IMA 度量 + Appraisal]  S4 --> S5[远程证明可达]    S6[Measured Boot 同步进行]  S6 -.- S1 & S2 & S3 & S4

实际部署：

1. BIOS：     启用 Secure Boot + Measured Boot
2. Bootloader：     shim + GRUB 签名
3. Kernel：     发行版签的 kernel + 自签 module
4. initrd：     生成时签
5. IMA：     启动 ima_policy=appraise_tcb
6. EVM：     启用 evm
7. LUKS：     密封到 PCR 7
8. 应用：     按需 IMA 度量

实战案例：金融业可信服务器

某银行核心交易系统：     
  - 物理 TPM 2.0 + Secure Boot
  - kernel + initrd 内部签
  - LUKS 全盘加密 + TPM 密封 PCR 7
  - IMA Appraisal 模式
  - 远程证明每天定时到中心化平台
  - 启动状态异常 → 自动告警 + 隔离

效果：     
  - 任何 BIOS / Bootloader / Kernel 篡改 → 启动失败
  - 任何关键二进制篡改 → 拒绝执行
  - 物理拆机偷盘 → 数据无法解密（PCR 不对）

远程证明实战

# 服务端：建立 attestation 服务（开源 keylime）
# 客户端：装 keylime agent
apt install keylime-agent

# Agent 注册到 verifier：     
keylime_register --addr  --uuid 

# Verifier 周期发起 Quote 检查
# Agent 调 TPM_Quote 返回
# Verifier 比对 PCR 是否匹配预期

# 不匹配 → 隔离机器

主流远程证明方案：

keylime（NCC 出品，CNCF 项目）：     
  - 开源
  - Bootstrap + Periodic attest
  - 集成 IMA 度量列表

Microsoft Attestation Service：     
  - Windows Defender Device Health
  - Azure Attestation Service
  
Intel Trust Authority：     
  - Intel 官方
  - 服务化远程证明

国产：     
  - 公安部一所 / 中电科 等可信认证体系
  - 工信部"可信云"标准
  - 各家 OEM 自家方案

几个老坑

坑 1：Secure Boot + 第三方驱动

NVIDIA / Mellanox 等内核模块：     
  - shim 信任的是发行版公钥
  - 第三方模块需要单独签
  - 用 mokutil 加用户证书

正确流程：     
  1. 生成 MOK 密钥对
  2. mokutil --import 加证书
  3. 装第三方驱动时用 dkms 自动签

坑 2：Kernel 升级 PCR 0/4 改变

LUKS 密封 PCR 0/4 → kernel 升级 → PCR 不一样 → 启动后无法解密

防御：     
  - 升级前 systemd-cryptenroll 重新封装
  - 或一直只用 PCR 7（推荐）
  - 留一把 fallback 密码

坑 3：IMA 性能开销

IMA 默认全度量：     
  - 每次 execve / mmap 都要哈希
  - 4 KB 文件哈希 ~10 μs
  - 大量小文件应用受影响 5-15%

调优：     
  - 用 dont_measure 排除不必要路径
  - 用 ima-buf 替代 ima-ng（buffer 模式）
  - SHA-1 比 SHA-256 快但安全性弱

坑 4：BIOS 升级清密钥

BIOS 升级有时候清空 PK / KEK / DB
   → Secure Boot 关闭
   → mokutil 之前导入的全没

防御：     
  - 升级前导出 PK / KEK / DB 备份
  - 升级后用 sbkeysync 恢复

坑 5：vTPM 状态

KVM vTPM 默认 swtpm 持久化：     
  /var/lib/swtpm/
  
迁移 VM：     vTPM 状态要同步迁移
否则：     新宿主机的 vTPM 是新的 → PCR 全空 → LUKS 解不开

坑 6：IMA Appraisal 启用前没签好

appraisal=enforce 时：     未签的文件不能执行
   → 突然启用 → 大量应用启动失败

正确：     
  1. 先 ima_appraise=fix 一次（自动签）
  2. 验证一切正常
  3. 再 ima_appraise=enforce

坑 7：远程证明引用值管理

万级集群每机 PCR 值不同（kernel / 配置略差异）：     
  - 集中维护"已知好"哈希列表
  - 每次升级都要更新基线
  - 大集群运维成本高

→ 这是为什么互联网厂启用率低

TPM 与 BIOS 的协议

TCG PC Client Profile：     
  - 度量哪些事件（PCR mapping）
  - 事件日志格式
  - 厂家必须遵循

每家 BIOS 实现略有差别：     
  - 同款服务器换 BIOS 厂 PCR 不一样
  - 跨厂家集群 PCR 基线管理头疼

一些查询命令

# Secure Boot 状态
mokutil --sb-state

# 已注册 MOK
mokutil --list-enrolled

# UEFI 变量
efivar -l
efibootmgr -v

# Measured Boot 事件
tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements
tpm2_pcrread sha256:0,1,2,3,4,5,6,7,8,9,10

# IMA 度量列表
cat /sys/kernel/security/ima/ascii_runtime_measurements | wc -l

# 看 IMA 策略
cat /sys/kernel/security/ima/policy

# 内核 lockdown 模式（与 Secure Boot 关联）
cat /sys/kernel/security/lockdown

一些数字直觉

启动时间影响：     
  Secure Boot：     +50-200 ms
  Measured Boot：    +500-1000 ms
  IMA 度量：        +1-5 秒（按文件数）
  TPM 解 LUKS：     +200-500 ms
  
运行时性能：     
  IMA Measurement：    5% 性能损失
  IMA Appraisal：      10-15% 性能损失
  EVM 启用：           额外 5-10%
  
存储：     
  Measurement 列表：    小集群每天几十 MB
  Event log：          每机几 MB

不同发行版默认情况

RHEL 9：     
  - Secure Boot 默认启用
  - shim 已签
  - IMA 配置可选
  - TPM 工具齐全

Ubuntu 24.04：     
  - Secure Boot 默认启用
  - LUKS + TPM 通过 systemd-cryptenroll
  - IMA 不默认

openEuler 22.03 LTS：     
  - 信创目录默认启用 Secure Boot + Measured Boot
  - IMA 政企版默认启用
  - 与 TCM 集成

麒麟 V10：     
  - 等保 3+ 默认 Secure Boot + IMA
  - 国密签名（SM2/SM3）
  - 与 TCM / TPCM 适配

小结

Secure Boot = 启动验签，不通过就拒绝
Measured Boot = 启动度量记录到 TPM PCR
IMA = 运行时文件完整性验证
三者配合形成完整可信启动链
远程证明把启动状态送到验证方
LUKS + TPM PCR 7 是最常用的全盘加密方案
互联网厂启用率低，政企 / 金融 / 关基启用率高

下一篇讲 TEE——SGX、TDX、SEV、TrustZone 等”可信执行环境”。

TPM / TCM 基础与可信启动链

2026-03-01T13:30:00.000Z

第八章讲可信计算。可信不是”加密”也不是”防火墙”——是”用硬件证明系统在某个状态”。本文从 TPM 这颗小芯片讲起。

为什么需要可信计算

传统安全：     防火墙 / 杀毒 / 加密 / 权限
缺陷：     
  - 软件防御软件，攻击者一旦进系统就能改一切
  - 没有"硬件级根"
  - 系统启动时无法验证 BIOS / Bootloader / Kernel 是否被篡改
  - 加密密钥放在内存里 → 内存 dump 就泄露

可信计算的核心思想：     
  1. 硬件根：     一颗独立芯片，物理隔离，不可被软件篡改
  2. 度量启动链：    每一层启动时哈希下一层，记录到芯片
  3. 远程证明：    把启动状态送到远端，远端判断是否可信
  4. 密封：     用启动状态作为"密钥派生因子"，状态错就解不开

TPM：可信平台模块

TPM（Trusted Platform Module）是一颗独立小芯片：

graph TB  CPU[CPU]  CHIPSET[Chipset / PCH]  TPM[TPM Chip
独立芯片]  MB[主板]    CPU --- CHIPSET  CHIPSET --- TPM  TPM --- MB

TPM 的物理形态：

独立芯片（dTPM）：     主板焊一颗
固件 TPM（fTPM）：     CPU 内 TEE 模拟（Intel PTT、AMD fTPM）
虚拟 TPM（vTPM）：     VM 用的软件模拟
集成 TPM：             有些 SoC 内集成

TPM 的内部架构

TPM 内部：     
  - 处理器（小 CPU）
  - 非易失存储（NVRAM）
  - 易失存储（PCR、密钥句柄）
  - 加密引擎（RSA / ECC / SHA / AES）
  - 随机数发生器（RNG）
  - 唯一身份（EK）

接口：     
  TPM 1.2：    LPC（Low Pin Count）
  TPM 2.0：    SPI / I²C / LPC
  fTPM：       内部接口

TPM 1.2 vs 2.0

TPM 1.2（2003）：     
  - 仅 SHA-1
  - 单 hash 算法
  - 难升级
  - 已淘汰

TPM 2.0（2014）：     
  - SHA-256 / SHA-384 / SHA-512
  - SM3（中国国密）支持
  - 算法可扩展
  - PCR 数量可配置
  - 已是当前标准

Windows 11 强制要求 TPM 2.0——这是 2024 年 TPM 2.0 普及的主要推动力。

TCM：国密版 TPM

中国”可信计算 2.0”路线推出的：

TCM（Trusted Cryptography Module）：     
  - 中国主导
  - 算法用国密：     SM2 / SM3 / SM4 / SM9
  - GM/T 0011-2012 等国标
  - 与 TPM 1.2 类似的接口
  - 兼容 TCG 部分协议

TPCM（Trusted Platform Control Module）：     
  - "主动可信"
  - TCM + 主控制器，可主动度量 / 干预系统
  - 不只是被动度量
  - 国内独有，类似"安全协处理器"

实现：     
  - 主板 TCM 芯片
  - 沈昌祥院士主推

应用：     
  - 党政信创
  - 等保 2.0 三级 / 四级
  - 关基设施

PCR：平台配置寄存器

PCR（Platform Configuration Register）是 TPM 的核心：

graph TB  PCR[PCR 寄存器组
每个 32 字节]  PCR --> PCR0[PCR 0：BIOS]  PCR --> PCR1[PCR 1：BIOS 配置]  PCR --> PCR2[PCR 2：Option ROM]  PCR --> PCR3[PCR 3：Option ROM 配置]  PCR --> PCR4[PCR 4：MBR / Bootloader]  PCR --> PCR5[PCR 5：Bootloader 配置]  PCR --> PCR6[PCR 6：状态变更]  PCR --> PCR7[PCR 7：Secure Boot 状态]  PCR --> PCR8[PCR 8-15：OS 用]  PCR --> PCR16[PCR 16-23：debug / 应用]

PCR 的核心特性：

1. 不能直接写：     只能 Extend
2. Extend 操作：    PCR_new = SHA256( PCR_old || measurement )
3. 不可逆：     一旦写入，无法撤回
4. 重置：     只在系统重启时清零

→ 任何篡改都会改变最终的 PCR 值
→ 启动链状态被"哈希链"忠实记录

PCR 的 24 个寄存器各有约定（TCG 规范）：

PCR 0-7：     固件（BIOS / Boot 等）
PCR 8-15：    OS 层度量
PCR 16-22：   debug / 自定义
PCR 23：     应用 / 临时

度量启动链

graph LR  CRTM[CRTM
核心可信根
BIOS 内只读] --> B[BIOS]  B --> B2[BIOS 度量 Bootloader]  B2 --> BOOT[Bootloader
GRUB]  BOOT --> BOOT2[Bootloader 度量 Kernel]  BOOT2 --> KER[Kernel + initrd]  KER --> APP[OS / 应用]    CRTM -.-> TPM[TPM PCR]  B2 -.-> TPM  BOOT2 -.-> TPM  KER -.-> TPM

整个启动过程：

1. 上电 → CRTM（Core Root of Trust for Measurement）开始执行
   CRTM 是 BIOS 中的一段不可变代码 / 不可变 mask ROM
   它度量自己 + 度量 BIOS 的剩余部分 → Extend PCR 0
   
2. BIOS 度量 Option ROM（PCI 卡 firmware）→ Extend PCR 2/3
   
3. BIOS 度量 Bootloader（GRUB）→ Extend PCR 4/5
   把控制权交给 Bootloader

4. Bootloader 度量 Kernel + initrd → Extend PCR 8/9
   把控制权交给 Kernel
   
5. Kernel IMA 度量重要文件 → Extend PCR 10
   挂载文件系统，启动应用

最终：     PCR 0-10 反映了整个启动链的"哈希状态"

任意环节被篡改： PCR 就会和”已知好的状态”不一样。

TPM 的密钥层次

graph TB  EK[EK
Endorsement Key
制造时烧死，唯一身份]  SRK[SRK
Storage Root Key
用户拥有，加密其他密钥]  AIK[AIK
Attestation Identity Key
身份证明用]  CHK[Child Keys
用户密钥]    EK -.- AIK  SRK --> CHK

密钥	用途
EK（Endorsement Key）	出厂烧入，证明这是真 TPM
SRK（Storage Root Key）	用户绑定的根密钥
AIK（Attestation Identity Key）	远程证明时用，避免泄露 EK
Child Keys	用户业务密钥

EK 由 TPM 厂家签发——内置一张”出厂证书”。这是远程证明能信任 TPM 的根。

远程证明（Remote Attestation）

graph LR  CL[客户端机器]  CL --> Q[Quote 操作
TPM 签名 PCR 状态]  Q --> SR[发到验证方]  SR --> SRV[验证服务器]  SRV --> CMP[比对预期 PCR]  CMP --> RES[可信 / 不可信]

远程证明流程：

1. 验证方发起挑战（Nonce）
2. 客户端调用 TPM_Quote(PCRs, Nonce)
3. TPM 用 AIK 签名 PCR 哈希 + Nonce → Quote
4. 客户端把 Quote + AIK 证书发给验证方
5. 验证方：     
   a. 验证 AIK 证书链（来自 EK 厂家）
   b. 验证 Quote 签名
   c. 比对 PCR 值是否匹配预期"好的状态"
   d. 通过 → 这台机器在可信状态

应用场景：

- 网络准入：     设备进网前要 attest
- 云租户：     租户验证云上 VM 是真 TEE
- 软件更新：     更新前验证当前状态
- 数据访问控制：     PCR 错就解密失败

密封（Sealing）

TPM 可以把数据”密封”到某个 PCR 状态：

密封 = 用 PCR 当前值作为派生因子加密数据：     
  TPM_Seal(data, PCR_target_values)
  
解封：     
  TPM_Unseal(sealed_blob)
  → 仅当 PCR 当前值 == 密封时的值，才能解出
  
应用：     
  - 全盘加密密钥密封到启动状态
  - 业务密钥密封到应用代码
  - 任何篡改 → 解封失败 → 数据无法访问

LUKS 全盘加密 + TPM 密封是 Linux 上最常用的安全启动方案。

DRTM 与 SRTM

度量根的两种类型：

SRTM（Static Root of Trust for Measurement）：     
  - 系统启动时建立
  - 从 CRTM 一路度量
  - 大部分场景

DRTM（Dynamic Root of Trust for Measurement）：     
  - 系统运行时动态建立"信任岛"
  - Intel TXT / AMD SKINIT
  - 不需要从开机度量
  - 用于安全敏感任务的"临时可信环境"

DRTM 应用：

1
2
3

- 启动 hypervisor 时建立 measure
- 银行 / 政务 / 军方关键操作前 DRTM
- 现在 TEE 已经吸收大部分 DRTM 场景

TPM 的实战命令

# 看 TPM 是否存在
ls /dev/tpm*
# /dev/tpm0
# /dev/tpmrm0

# TPM 版本
cat /sys/class/tpm/tpm0/tpm_version_major
cat /sys/class/tpm/tpm0/device/description

# 看 PCR 值
tpm2_pcrread sha256:0,1,2,3,4,5,6,7

# 输出例：
# sha256:
#   0: 0x...64-hex
#   1: 0x...
#   ...

# 取个随机数
tpm2_getrandom 32 | xxd

# 创建主密钥
tpm2_createprimary -c primary.ctx

# 创建子密钥
tpm2_create -C primary.ctx -u key.pub -r key.priv

# 加密 / 解密
tpm2_rsaencrypt -c key.ctx -o cipher.bin plain.txt
tpm2_rsadecrypt -c key.ctx -o plain.bin cipher.bin

# 密封
echo "secret" | tpm2_create -C primary.ctx -u sealed.pub -r sealed.priv -i -

# Quote（远程证明）
tpm2_quote -c key.ctx -l sha256:0,1,2,3 -q "challenge_nonce"

TPM 在系统中的角色

graph TB  TPM[TPM 2.0]  TPM --> SB[Secure Boot 验证]  TPM --> BOOT[Measured Boot 度量]  TPM --> LUKS[LUKS 密封]  TPM --> SSH[SSH 密钥保护]  TPM --> CERT[X.509 证书 / mTLS]  TPM --> WIN[Windows BitLocker / Hello]  TPM --> RA[远程证明]

TPM 不直接做”业务”——它是给上层各种安全子系统提供根。

LUKS + TPM

传统 LUKS：     用户输密码解密
TPM 密封 LUKS：    密码绑定 PCR
                启动状态正确 → 自动解密
                启动被篡改 → 解密失败

systemd-cryptenroll：     2021+ Linux 标准工具
  systemd-cryptenroll --tpm2-device=auto /dev/sda3
  
GRUB 加 measured boot：     
  → BIOS / GRUB / kernel / initrd 哈希都进 PCR
  → 任何篡改 → 解不开

Windows BitLocker

Windows 用 TPM：     
  - BitLocker 全盘加密自动解（密钥密封到 PCR）
  - Hello 生物识别（密钥保护）
  - Defender Credential Guard
  - Win 11 强制 TPM 2.0

服务器 TPM 的现状

2026 年现状：     
  - 几乎所有数据中心服务器都带 TPM 2.0
  - 政府 / 金融 / 关基采购"必带"
  - 互联网厂商：     多数采购带 TPM，但实际启用率低（< 20%）
  - 信创目录：     强制 TPM 2.0 或 TCM
  
为什么互联网启用率低：     
  1. 配置复杂
  2. 大规模运维难（每机 PCR 不同）
  3. 业务团队不熟
  4. 收益不明显

TPM 的几个老坑

坑 1：fTPM bug 导致系统卡顿

2022 年 AMD fTPM 在某些主板上偶发卡死
   → 鼠标 / 键盘卡顿几百毫秒
   → 桌面用户大量抱怨
   → AMD 后续 BIOS 修复

教训：     fTPM 性能不如 dTPM 稳定

坑 2：BIOS 升级清除 PCR

BIOS 升级 → CRTM 改变 → PCR 0 改变
   → LUKS 密封基于 PCR 0 → 解不开
   → 全盘加密的服务器锁死

防御：     
  - 升级前重新封装密钥
  - 用 TPM Recovery Key 备用
  - PCR 选择只用 7（Secure Boot 状态）而非 0

坑 3：vTPM 状态不持久

KVM vTPM 默认存在内存：     
  - VM 重启状态丢失
  - 必须用 SWTPM 持久化
  
正确：     swtpm + libvirt 标准模式

坑 4：TPM 命令排队

TPM 是慢芯片：     单核单队列
  → 多并发可能卡 100+ ms
  → 高并发应用不要频繁调 TPM

应用：     一次启动取出密钥后缓存到 kernel keyring

坑 5：TPM 与 Secure Boot 混淆

TPM ≠ Secure Boot：     
  Secure Boot = UEFI 验签
  TPM = 度量记录

可以独立：     
  - 只 Secure Boot，无 TPM：能验签，但没有"启动状态记录"
  - 只 TPM，无 Secure Boot：度量记录但允许任何启动
  - 两个都开：完整方案

TCG 标准

TCG（Trusted Computing Group）：     
  TPM 标准制定者
  AMD / IBM / Intel / HP / Microsoft 等创立
  
  规范：     
    TPM 2.0 Library Spec
    TCG PC Client Profile
    Storage Spec（SED）
    DICE（Device Identifier Composition Engine）
    SPDM（Security Protocol and Data Model）
    
中国对应：     
  TCG 中国分会
  GB/T 29827-2013 系列国标

一些查询命令

# TPM 设备
ls /dev/tpm*
cat /sys/class/tpm/tpm0/tpm_version_major

# TPM 设备字符
dmesg | grep -i tpm

# 启用 / 禁用（GRUB）
tpm_tis.driver_args=...

# tpm2-tools 安装
apt install tpm2-tools         # Ubuntu
dnf install tpm2-tools         # RHEL

# 看 measured boot 事件日志
sudo tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements

# 安装 swtpm（vTPM）
apt install swtpm swtpm-tools

# vTPM 给 KVM
qemu-system-x86_64 ... \
  -chardev socket,id=chrtpm,path=/tmp/swtpm-sock \
  -tpmdev emulator,id=tpm0,chardev=chrtpm \
  -device tpm-tis,tpmdev=tpm0

一些数字直觉

TPM 2.0 性能：     
  生成 RSA 2048 密钥：     500-1000 ms
  RSA 签名：              50-100 ms
  PCR Extend：            1-5 ms
  Quote：                 50-150 ms
  RNG 32 字节：           5-10 ms

启动时间影响：     
  完整 measured boot：     +1-3 秒
  TPM unseal LUKS：        +200-500 ms
  
价格：     
  dTPM 芯片单颗：          $1-3 美元
  服务器主板支持：          通常含
  fTPM 启用：               免费

第八章 Roadmap

接下来会展开：

Secure Boot / Measured Boot / IMA（怎么用 TPM）
TEE：SGX / TDX / SEV / TrustZone
机密计算 Confidential VM/Container
国产可信计算（海光 CSV / 鲲鹏 / TPCM）
选型与小结

小结

TPM 是可信计算的硬件根，提供度量、密封、远程证明能力
TPM 1.2 仅 SHA-1，已淘汰；TPM 2.0 多算法可扩展
TCM 是中国国密版本，TPCM 是”主动可信”扩展
PCR 是核心数据结构——用 Extend 操作记录哈希链
度量启动链从 CRTM 到应用层，PCR 0-10 各有约定
Quote 是远程证明，Seal 是状态绑定
LUKS + TPM、Win BitLocker 是常见的应用
数据中心服务器普遍配 TPM 2.0，但启用率有限

下一篇讲 Secure Boot / Measured Boot / IMA——怎么把 TPM 用起来。

OS 选型实战与第七章小结

2026-02-22T03:15:00.000Z

第七章前面 6 篇分别讲了 Linux 发行版、虚拟化、容器/K8s、内核内部、AI OS 适配、国产 OS。本篇收口。

OS 选型的”四层决策”

graph TD  Q1[第 1 层: 业务类型?]  Q1 --> Q2[第 2 层: 虚拟化方案?]  Q2 --> Q3[第 3 层: 容器栈?]  Q3 --> Q4[第 4 层: 国产化要求?]  Q4 --> A[最终选型]

第 1 层：业务类型

传统单机应用：     RHEL / Ubuntu LTS / 麒麟 / 欧拉
云原生 / K8s：     Ubuntu / Rocky / 龙蜥 / Bottlerocket / Talos
数据库专用：       RHEL（Oracle 认证）/ Ubuntu / 龙蜥
AI 训练：         Ubuntu 22.04 + 内核 5.15+
HPC：             RHEL / Rocky / openEuler
边缘 / 嵌入式：     Yocto / Buildroot / Alpine
桌面 / VDI：       Windows / Ubuntu / 麒麟桌面 / UOS

第 2 层：虚拟化方案

场景	推荐
公有云 IaaS	KVM + 自研管理面（参考 AWS Nitro / 阿里神龙）
私有云	OpenStack + KVM 或国产替代（华为 / 深信服 / H3C）
VMware 替换	Proxmox VE / OpenStack / 国产虚拟化
桌面虚拟化	VMware Horizon / Citrix / 国产 VDI
AI 训练 VM	KVM + GPU 直通 + SR-IOV
容器优先	直接 K8s + containerd（无 VM 层）

第 3 层：容器栈

graph TD  Q1{规模和需求?}  Q1 -- "<10 节点" --> S1[Docker Compose / 单机 K8s]  Q1 -- "10-100 节点" --> S2[K8s + Rancher / KubeSphere]  Q1 -- "100+ 节点" --> S3[K8s + 自建 / 云厂家 K8s]  Q1 -- "AI 训练集群" --> S4[K8s + Volcano / KAI]  Q1 -- "Serverless" --> S5[Knative / Lambda / Fargate]

第 4 层：国产化要求

1
2
3

强国产化（党政 / 央企）：     麒麟 V10 / openEuler / UOS
中等国产化（国央企互联网）：    龙蜥 / openEuler / 阿里 Alinux
弱国产化（互联网商业）：       Ubuntu LTS / Rocky / RHEL

几个典型场景的清单

场景 1：传统企业 IT

OS：           RHEL 9（订阅）或 Rocky Linux 9（免费）
虚拟化：        VMware vSphere（已有）或 Proxmox VE（替代）
容器：         少量（基本用 VM）
管理：         vCenter / Ansible
预算：         订阅 + 服务约 ¥几百万 / 年

场景 2：互联网中型

宿主机 OS：     Ubuntu 22.04 LTS / 龙蜥 8
虚拟化：        KVM + libvirt + OpenStack（或自研）
容器：         containerd + K8s 1.30+
CNI：          Cilium 或 Calico
存储：         Ceph + 本地 NVMe
监控：         Prometheus + Grafana + Loki
预算：         开源为主，运维团队 + 商业支持

场景 3：AI 训练集群

OS：           Ubuntu 22.04 LTS（NVIDIA 官方支持最好）
内核：         6.x（GPU 驱动 + IB 模块）
容器：         containerd + K8s + nvidia-device-plugin
调度：         Volcano / KAI Scheduler / Run.ai
存储：         WekaFS / Lustre + 本地 NVMe
训练框架：      PyTorch + DeepSpeed / Megatron / FSDP
监控：         Prometheus + DCGM Exporter

场景 4：信创私有云

OS：           麒麟 V10 SP3 + openEuler 22.03 LTS
虚拟化：        华为 FusionCompute / 深信服 aSV / 新华三 UIS
容器：         iSulad + K8s（华为 CCE 衍生）
存储：         华为 OceanStor / 浪潮分布式
安全：         凝思安全 OS + 国密
管理：         国产 IaaS / PaaS 平台

场景 5：边缘 / IoT

OS：           Alpine Linux（容器）/ Yocto（嵌入式）/ Talos
容器：         containerd + KubeEdge / K3s
更新：         OTA 不可变镜像
监控：         轻量化（Prometheus 缩减）

几个常见的”OS 坑”

坑 1：选 EOL 的 OS

新部署上 CentOS 7（EOL 2024-06）：     1 年后无补丁
新部署上 RHEL 7：     2024-06 EOL
新部署上 Ubuntu 18.04：     已 EOL

正确：     选最新 LTS（RHEL 9 / Ubuntu 24.04 / Rocky 9）

坑 2：内核过旧不支持新硬件

H100 GPU 需要 NVIDIA driver 535+：     
  RHEL 7 内核 3.10 → 装不上
  Ubuntu 18.04 内核 4.x → 部分功能不可
  
NVMe 5.0 SSD：     
  需要 5.x+ 内核
  
ConnectX-7 400G：     
  MOFED 25.x+，需要新内核

坑 3：systemd 不熟

开发用 supervisord 启服务，生产环境过时：     
  - 用 systemd unit
  - 资源限制 / 重启策略 / 日志都是 systemd
  
journalctl 不会用：     运维效率低

坑 4：忽视 NUMA

8 GPU 服务器跨 NUMA 不绑定：     
  - DataLoader 性能损失 30%
  - Database 性能损失 20%
  - 网卡跨 socket 损失 30-50%

调优：     Topology Manager / numactl / taskset 三件套

坑 5：cgroup v1 / v2 混用

RHEL 8 / Ubuntu 22.04 默认 v2：     
  - K8s 1.25+ 需要 v2
  - 老的 Docker 可能不兼容
  
迁移：     
  - GRUB 加 systemd.unified_cgroup_hierarchy=1
  - Docker / containerd 升级

坑 6：默认 ulimit 太低

默认 nofile 1024：     高并发立刻崩
默认 nproc：           容器多 worker 不够
默认 memlock：         RDMA / NCCL 报错

修复：     /etc/security/limits.conf 调大

坑 7：把所有应用塞到一台 OS

单台物理机 → 一个 OS → 跑很多应用：     
  - 资源争用
  - 升级困难
  - 故障爆炸半径大
  
正确：     
  - 物理机 → 一个 Hypervisor / 容器 host
  - 应用跑容器或 VM 里

一些性能直觉数字

启动时间：     
  RHEL 9 + systemd：     30 秒
  Ubuntu 22.04：         20 秒
  K8s Pod 启动（含调度）： 1-3 秒
  Firecracker μVM：       125 ms
  OCI 容器：             100-500 ms

资源占用：     
  RHEL 9 最小安装：       1.5 GB
  Alpine：               5-10 MB
  K8s 控制面（小集群）：    1-2 vCPU / 4 GB
  K8s 控制面（万节点）：    16+ vCPU / 64 GB

性能损失：     
  KVM 虚拟化：           <2-5%
  KVM + virtio：         <5%（IO）
  容器：                 <1%
  KVM + SR-IOV：         <5%
  Kata Container：        ~5%
  gVisor：               20-30%（用户态内核）

OS 升级的实战建议

1. 升级前评估：     
   - 应用依赖（glibc / Python / Java 等）
   - 第三方驱动（NVIDIA / Mellanox）
   - 老的内核模块（kABI 兼容）
   
2. 测试环境先验证：     
   - 同 OS 同硬件克隆
   - 完整业务功能测试
   - 性能回归测试
   
3. 滚动升级：     
   - 不要全量升级
   - 一个机柜先升，观察 1 周
   - 然后下一批
   
4. 回滚预案：     
   - 保留旧镜像
   - 备份配置
   - 文档化升级步骤

第七章整体小结

回看第七章覆盖：

Linux 服务器 OS 演进 — RHEL / Debian / SUSE 三大家族 + systemd
虚拟化 — KVM / Xen / Hyper-V + SR-IOV / vGPU
容器与 K8s — namespace + cgroup，K8s 调度模型
内核内部 — 调度器 / 网络栈 / 文件系统 / 内存管理
AI 时代 OS 适配 — GPU 调度 / NUMA / 大模型训练
国产服务器 OS — 欧拉 / 麒麟 / 龙蜥 / 统信
OS 选型与小结（本篇）

几条贯穿全章的主线：

graph LR  HW[硬件]  HV[Hypervisor / 容器引擎]  HOST[Host OS]  ORCH[K8s / 调度器]  APP[应用]    HW --> HOST  HOST --> HV --> ORCH --> APP

核心认知：

Linux 是服务器市场绝对主流
systemd / cgroup v2 / eBPF / io_uring 是近 10 年最重要的内核新特性
KVM + containerd + K8s 是事实标准 stack
AI 时代 OS 要管 GPU / NUMA 拓扑 / 大 IO
国产 OS（欧拉 + 麒麟 + 龙蜥）已能完整覆盖政企 + 互联网

OS 未来 2-3 年趋势

1. RHEL 10 引入（2025-2026）—— ARM64 第一公民
2. Linux 内核 6.x LTS 取代 5.15 LTS
3. EEVDF 完全取代 CFS
4. cgroup v2 全面普及
5. eBPF + Cilium 取代 iptables
6. io_uring 在数据库 / 存储成为默认
7. Confidential VM（机密计算）从研究走向生产
8. 不可变 OS（Talos / Bottlerocket / NixOS）增长
9. 国产 OS（openEuler / 龙蜥）海外影响力提升
10. AI 集群专用 OS 镜像逐步标准化

不可变 OS 的兴起

值得单独提一句：

传统 OS：     可读写根文件系统，apt/dnf 装包
不可变 OS：     根文件系统只读，整体镜像更新

代表：     
  Container Optimized OS（GCP）
  Bottlerocket（AWS）
  Talos（K8s 专用）
  Flatcar Linux（前 CoreOS）
  NixOS（声明式）
  openEuler 镜像版（探索中）

优势：     
  - 故障状态可预测
  - 升级 = 替换镜像
  - 适合 K8s / 大规模车队管理

给读者的实战建议

如果你在公司负责 OS 标准化：

1. 选好 LTS 版本，不要追新（RHEL 9 / Ubuntu 24.04）
2. 标准化基础镜像（包 + 配置 + 监控 agent）
3. 内核参数 / limits 用 Ansible / Salt 推送
4. 定期 CVE 扫描和补丁
5. 容器化业务，VM 只跑基础设施
6. K8s 集群 < 5000 节点，超就上联邦
7. 国产化按业务等级分层
8. AI 集群单独标准化（与传统业务隔离）
9. 监控 + 日志 + tracing 三件套不能省
10. 备份和灾难恢复演练 1 次 / 季度

待补充：你公司或项目内的 OS 选型决策。

第七章结束

下一章进入第八章可信计算。会重点讲：

TPM / TCM 基础
Secure Boot / Measured Boot / IMA
TEE（Intel SGX / TDX、AMD SEV / SEV-SNP、ARM TrustZone / CCA、海光 CSV）
机密计算（Confidential VM / Confidential Container）
国产可信计算（TCM / TPCM / 海光 CSV / 鲲鹏）
DICE / SPDM / Attestation

Chapter 7 done.

国产服务器 OS —— 欧拉、麒麟、龙蜥、统信

2026-02-15T15:25:00.000Z

CentOS 8 提前 EOL（2021）+ 信创需求 = 国产服务器 OS 的爆发期。本文盘点主流国产 Linux 发行版及其差异。

一张全景

graph TB  CN[国产服务器 OS]  CN --> EU[openEuler 系
华为主导]  CN --> KY[麒麟系
麒麟软件]  CN --> AN[龙蜥系
阿里 + OpenAnolis]  CN --> UO[统信系
统信软件 UOS]  CN --> DP[深度系
Deepin]  CN --> OT[其他]    EU --> EU1[openEuler
开源社区版]  EU --> EU2[EulerOS
华为商业版]    KY --> KY1[银河麒麟
桌面 + 服务器]  KY --> KY2[中标麒麟
原中标软件]  KY --> KY3[开放麒麟 openKylin
2023 开源社区]    AN --> AN1[Anolis OS
开源社区版]  AN --> AN2[Alinux
阿里云内部]  AN --> AN3[腾讯 OS / 龙蜥衍生]    UO --> UO1[UOS V20 / V21
商业]  UO --> UO2[Deepin → 统信 Deepin]    DP --> DP1[Deepin OS
桌面起家]    OT --> OT1[红旗 Linux
历史]  OT --> OT2[中科方德]  OT --> OT3[凝思安全 OS]

openEuler（欧拉）

华为 2019 年开源的 Linux 发行版：

背景：     
  - 起源于华为 EulerOS（华为内部 / 服务器）
  - 2019 年 12 月开源
  - 2021 年捐给开放原子开源基金会

特点：     
  - 内核基于 Linux 5.10（22.03 LTS）/ 6.6（24.03 LTS）
  - 多架构：x86_64 / ARM64 / RISC-V / LoongArch / Power
  - 鲲鹏 / 昇腾深度优化
  - 全栈虚拟化（StratoVirt）
  - 容器（iSulad）
  - openGauss 数据库适配

商业版：     
  EulerOS（华为）
  麒麟 V10（兼容欧拉）
  统信 UOS 部分版本
  绿盟 / 麒麟信安 / 中科方德等

22.03 LTS：     2022 年发布，长期支持
24.03 LTS：     2024 年发布

openEuler 的版本节奏

22.03 LTS：     2022-03，5.10 内核，长期支持到 2026
22.03 SP1/2/3：  21-22 年继续 SP 更新
24.03 LTS：     2024-03，6.6 内核，长期支持到 2028+
26.03 LTS：     预计 2026-03

每 2 年一个 LTS，与 Ubuntu LTS 节奏类似

openEuler 的差异化

鲲鹏 / 昇腾原生：     
  - 内核优化（NUMA、调度）
  - 工具链：     毕昇编译器（BiSheng Compiler，基于 LLVM）
  - 与 ARM64 服务器 + 昇腾 GPU 紧密集成

iSulad：     
  - 华为开源的轻量级容器引擎
  - 启动比 Docker 快
  - 与 Kata 集成

A-Tune：     
  - 智能调优系统
  - 自动分析负载，推荐参数
  
secGear / occlum：     
  - 机密计算 SDK
  - SGX / TrustZone / 海光 CSV 适配

麒麟（Kylin）系

银河麒麟（Kylin V10）

出品方：     麒麟软件（中国电科子公司，原天津麒麟 + 中标软件合并）
定位：       商业发行版，等保 / 政企信创主流
版本：       V10 SP1 / SP2 / SP3 / SP4 (2024)

特点：     
  - 基于 CentOS / Ubuntu 双线
  - 华为鲲鹏 / 飞腾 / 海光 / 兆芯 / 龙芯 / 申威 全适配
  - 国密算法支持（SM2/3/4/9）
  - 等保 2.0 三级
  - 与 GooseFS / GBase / 华为云 / 阿里云适配

商业模式：     卖订阅 + 服务
客户：       政府 / 国央企 / 银行 / 军方

中标麒麟

1
2
3

原中标软件出品，2019 年与天津麒麟合并：     
  - 中标麒麟 V7 仍在很多政府部门使用
  - 已合并到银河麒麟统一品牌

openKylin（开放麒麟）

2023 年 6 月发布的社区开源版：     
  - 麒麟软件主导
  - 完全开源
  - 桌面为主
  - 服务器版逐步建设

龙蜥（OpenAnolis）

阿里云 2020 年发起的开源社区：

背景：     
  - CentOS 8 风波后阿里推出 Anolis OS
  - 邀请龙蜥社区成员
  - 主要由阿里云 / 龙芯 / 统信 / 浪潮 / 中兴等参与

版本：     
  - Anolis OS 7：     CentOS 7 兼容
  - Anolis OS 8：     RHEL 8 兼容
  - Anolis OS 23（2023）：     6.6 内核
  - 24+ ：     最新

特点：     
  - RHEL 兼容（迁移容易）
  - 龙蜥 Cloud Kernel 优化
  - 阿里云原生：     容器、K8s、OS 协同
  - 多 ISA：     x86_64 / ARM64 / 龙芯 LoongArch

阿里 Alinux

Alinux：     
  - 阿里云内部用版本
  - 基于 Anolis OS
  - 自家服务器 / ECS 默认

腾讯 OS（TencentOS Server）

腾讯系：     
  - 基于龙蜥 / RHEL
  - 腾讯云内部
  - 部分对外发布

统信 UOS

统信软件 2019 年成立（中国电子集团子公司）：

UOS：     
  - 桌面 + 服务器双产品线
  - 桌面：     UOS Desktop（基于 Deepin）
  - 服务器：    UOS Server V20 / V21
  - 多架构：     x86_64 / ARM64 / 龙芯 / 海光 / 飞腾 / 申威
  - 等保 / 国密支持

定位：     政企信创桌面 + 服务器
背景：     国资背景，央企渠道
对手：     麒麟（也是央企背景）

Deepin（深度）

深度社区：     2008 起，桌面 Linux
2019 年起被统信收购：     
  - Deepin 仍开源
  - 同时统信 UOS 商业版基于 Deepin
  - DDE（Deepin Desktop Environment）国际口碑好

服务器版：     主要桌面，服务器市场不强

其他国产 OS

凝思安全 OS（ENISC）：     
  - 等保安全方向
  - 政府客户

中科方德：     
  - 中科院系
  - 龙芯适配优势

红旗 Linux：     
  - 历史品牌（2000 年代）
  - 多次易主
  - 现仍在卖
  
其他小众：     微步、欧拉派生等

国产 OS 的”两条路线”

graph TB  RHEL[RHEL 兼容路线
RPM]  RHEL --> R1[openEuler]  RHEL --> R2[麒麟 V10]  RHEL --> R3[龙蜥 OS]  RHEL --> R4[统信 UOS Server]    DEB[Debian 兼容路线
DEB]  DEB --> D1[Deepin]  DEB --> D2[麒麟桌面]  DEB --> D3[UOS Desktop]

服务器主流是 RHEL 路线——因为政企客户原本用 CentOS，迁移路径短。

国产 OS 的”必备特性”

graph TB  CN[国产 OS 必备]  CN --> ARCH[多架构支持]  CN --> SEC[国密算法]  CN --> COMP[兼容认证]  CN --> EQ[等保合规]  CN --> SUP[商业服务]    ARCH --> A1[x86_64
海光 / 兆芯]  ARCH --> A2[ARM64
鲲鹏 / 飞腾]  ARCH --> A3[LoongArch
龙芯]  ARCH --> A4[SW64
申威]  ARCH --> A5[RISC-V
未来]    SEC --> S1[SM2 椭圆曲线]  SEC --> S2[SM3 哈希]  SEC --> S3[SM4 对称]  SEC --> S4[SM9 标识密码]

国产 OS 都要支持：

1. 至少 5-6 种 CPU 架构
2. 国密算法（SM2/3/4/9）
3. 等保 / GB 18030 / 中文显示
4. 信创目录 / CNAS 认证
5. 商业服务 / 7×24 支持

国产 OS 的兼容性

应用兼容：     
  - 大多数 Linux 应用直接跑（同 RHEL/Debian 上游）
  - 国产数据库（GaussDB / OceanBase / TDSQL）原生
  - 国产中间件 / 中间层

驱动兼容：     
  - x86_64 NVIDIA：     可装驱动，但官方支持差
  - 鲲鹏 + 昇腾：     openEuler 最完整
  - 海光 DCU：     需要 ROCm 适配
  - 摩尔线程 / 寒武纪：     按厂家适配

包管理：     
  - DNF / YUM（RHEL 系）
  - APT（Debian 系）
  - 国产仓库（mirrors.huaweicloud.com / aliyun.com 等）

装机命令对比

# openEuler / 麒麟 V10 / 龙蜥（RPM）
dnf install nginx
dnf update
dnf list installed

# UOS / Deepin（DEB 桌面）
apt install nginx

# 看版本
cat /etc/os-release        # 通用
cat /etc/openEuler-release
cat /etc/kylin-release
cat /etc/anolis-release

国产 OS 选型实战

graph TD  Q1{业务场景}  Q1 -- "全栈华为生态" --> S1[openEuler / EulerOS]  Q1 -- "央国企政企" --> S2[银河麒麟 V10]  Q1 -- "云原生 / 互联网" --> S3[龙蜥 / 阿里 Alinux]  Q1 -- "桌面 + 服务器一体" --> S4[统信 UOS]  Q1 -- "等保 / 安全" --> S5[凝思 / 麒麟信安]

场景	推荐	原因
鲲鹏服务器 + 昇腾	openEuler	原生集成
党政机关、央国企	麒麟 V10	政府认可度最高
阿里云 / 腾讯云 ECS	龙蜥 / Alinux	云原生优化
飞腾 + 麒麟桌面统一	麒麟 / UOS	全套国产
信创 + 数据库国产	麒麟 / 欧拉	与 GaussDB 兼容
中小企业 + 节省成本	Rocky Linux 9（非国产） / 龙蜥	免费稳定

国产 OS 的”老坑”

坑 1：版本标注不一致

"麒麟 V10" 实际可能是不同 SP / 不同上游：     
  Kylin V10 SP1：     基于 CentOS 7
  Kylin V10 SP2：     基于 CentOS 8 衍生
  Kylin V10 SP3：     基于 RHEL 9 衍生

→ 选包要明确 SP 版本

坑 2：硬件兼容性

NVIDIA GPU 驱动：     
  - openEuler / 麒麟较新版本基本 OK
  - 老版本可能要自己编译
  - 新型号（B200）官方滞后
  
国产 GPU 驱动：     
  - 国产 OS 适配相对完整（昇腾 → openEuler）
  - 但跨家组合（海光 + 麒麟）需要厂家联合验证

坑 3：第三方软件支持

商业软件（Oracle / SAP / Splunk 等）：     
  - 部分认证 RHEL / SLES 后才能跑
  - 国产 OS 上"能跑但官方不支持"是常态
  - 重要业务要求厂家明确支持

坑 4：内核与上游差异

国产 OS 自带补丁 / patch：     
  - 修复 CVE 时序与上游不一致
  - 某些性能补丁是定制的
  - 升级时要小心 ABI 兼容

坑 5：包仓库稳定性

某些国产 OS 仓库不稳定：     
  - 镜像同步延迟
  - 包签名问题
  - 需要本地缓存仓库（apt-mirror / dnf-reposync）

国产 OS 的市场份额（估算）

2026 年估算（信创市场）：     
  银河麒麟：     30-40%
  openEuler 系（EulerOS / 麒麟欧拉版）：     30-40%
  龙蜥 / 阿里 Alinux：     10-15%
  统信 UOS：     10-15%
  其他：     5%
  
互联网市场：     
  仍以 CentOS 衍生（Rocky / Anolis）+ Ubuntu 为主
  阿里 / 腾讯：     主用龙蜥 / Alinux
  字节 / 百度 / 美团：     混合，部分自研

云市场：     
  阿里云 / 腾讯云：     龙蜥 / TencentOS 默认
  华为云：     openEuler / EulerOS 默认
  AWS / Azure 中国：     主要 Linux 发行版

待补充：2025-2026 国产 OS 实际市场份额数据。

与开源社区的关系

openEuler：     
  - 完全开源，公开 git
  - 上游补丁回馈 kernel.org
  - 已是 Linux Foundation 重要贡献者

龙蜥：     
  - 完全开源，公开 git
  - 阿里云 / 腾讯主要 PR 提交者
  - "Cloud Kernel"是 Linux 内核明显贡献

麒麟：     
  - 部分开源（openKylin 社区）
  - 商业 V10 不公开 git
  - 内核修改与上游差异多

统信：     
  - Deepin 完全开源
  - UOS Server 部分开源

整体：     openEuler 和龙蜥的开源透明度最高

信创采购清单的 OS 选型

党政信创目录：     
  - 银河麒麟 V10
  - 统信 UOS
  - openKylin

央企采购：     
  - 麒麟 / 欧拉双轨
  - 部分企业用龙蜥

国企：     
  - 多家共存
  - 麒麟 + 欧拉占多数

军方 / 关基：     
  - 银河麒麟 + 凝思 / 麒麟信安
  - 等保 4 级要求

待补充：你公司或项目内的国产 OS 实际选型。

一些查询命令

# 看版本
cat /etc/os-release

# 麒麟特有
cat /etc/.kylin-release
cat /etc/kylin-build

# 欧拉特有  
cat /etc/openEuler-release
cat /etc/issue

# 龙蜥
cat /etc/anolis-release

# 统信
cat /etc/uos-release

# 内核 / 架构
uname -mr

# CPU
cat /proc/cpuinfo | grep "model name" | head -1
# 鲲鹏：HUAWEI Kunpeng 920
# 飞腾：FT-2000+/64
# 海光：Hygon C86 7185
# 龙芯：Loongson-3A5000
# 兆芯：ZHAOXIN KX-U6580
# 申威：sw_64

国产 OS 的几个特色工具

A-Tune（openEuler）：     
  - 智能调优
  - atune-adm define / set / list

iSulad（openEuler）：     
  - 轻量容器
  - 类似 containerd

KMI（Kylin Management Interface）：     
  - 麒麟管理工具
  - 类似 cockpit
  
龙蜥 SysAK：     
  - 系统运维工具集
  - 类似 BCC 工具的国产版

LoongArch 工具链：     
  - GCC / glibc 已上游
  - LLVM 在适配

国产 OS 的发展趋势

2024-2026 趋势：     
  1. openEuler 与麒麟 V10 路线持续融合（同源）
  2. 信创市场 OS 国产化率 > 50%
  3. AI 适配成为新战场（昇腾 / 海光 DCU）
  4. RISC-V 支持成为差异化点
  5. 云原生 OS（轻量 + 不可变）开始出现
  6. 桌面国产化（UOS / 麒麟桌面）持续渗透

2027+ 看点：     
  1. RHEL 10 引入 ARM64 第一公民 → 影响国产 OS
  2. 龙芯 LoongArch 持续完善
  3. AI 加速器原生 OS 集成
  4. 与 Anduril / 国密 / 关基生态融合

小结

国产服务器 OS 主流四家：openEuler、麒麟 V10、龙蜥、统信
都基于 RHEL / CentOS 上游，但各自有内核优化
openEuler 和龙蜥开源透明度最高
麒麟在政府 / 央企认可度最高
信创市场国产 OS 已超 50%，互联网仍以 CentOS 衍生 + Ubuntu 为主
国产 GPU（昇腾、海光、寒武纪）与国产 OS 深度集成

下一篇是第七章收口——OS 选型与第七章小结。

AI 时代的 OS 适配 —— GPU 调度、NUMA 与大模型训练

2026-02-08T08:45:00.000Z

服务器 OS 过去 20 年都是为 CPU + 网卡 + 磁盘设计的。AI 时代加进来了 GPU、NPU、HBM、NVLink 这些新东西——OS 需要适配。本文从 GPU 调度讲到大模型训练 OS 优化。

AI 时代 OS 的新挑战

graph TB  TRAD[传统服务器 OS]  TRAD --> T1[CPU 调度]  TRAD --> T2[内存管理]  TRAD --> T3[文件 / 网络 IO]    AI[AI 时代追加]  AI --> A1[GPU / NPU 调度]  AI --> A2[HBM 内存管理]  AI --> A3[GPUDirect / NVLink]  AI --> A4[NUMA + GPU 拓扑]  AI --> A5[大量 IO（数据集 / checkpoint）]  AI --> A6[超大进程地址空间]

GPU 设备文件

NVIDIA GPU 在 Linux 下表现为字符设备：

ls -la /dev/nvidia*
# /dev/nvidia0
# /dev/nvidia1
# /dev/nvidiactl
# /dev/nvidia-uvm
# /dev/nvidia-uvm-tools
# /dev/nvidia-modeset

# 设备权限和容器：
ls /dev/dri/
# /dev/dri/card0          # DRM 设备
# /dev/dri/renderD128     # 渲染节点

容器里要把这些设备 mount 进去——nvidia-container-toolkit 自动做这件事：

# Docker 用
docker run --gpus all nvidia/cuda:12.4-base nvidia-smi
docker run --gpus '"device=0,1"' ...

# K8s 用 nvidia-device-plugin
kubectl describe node 
# Allocatable: nvidia.com/gpu: 8

# Pod 申请
resources:
  limits:
    nvidia.com/gpu: 1

GPU 资源在 K8s 里的模型

graph TB  PLUGIN[nvidia-device-plugin
DaemonSet]  PLUGIN --> EXPOSE[暴露 nvidia.com/gpu 资源]  EXPOSE --> SCHED[K8s Scheduler
按 GPU 数量调度]  SCHED --> POD[Pod 申请 GPU]  POD --> RUNTIME[nvidia-container-runtime
映射设备]

这个模型有几个根本问题：

1. 整数粒度：     一个 Pod 只能要 1/2/4/8 个 GPU
   → 小模型推理浪费 GPU 资源

2. 单 GPU 不可分享：     
   → 一个 Pod 占整张卡
   
3. 没有拓扑感知：     
   → 8 GPU Pod 可能跨 NUMA
   → NCCL 性能受影响

GPU 资源细分：MIG / vGPU / Time-Slicing

第 7.2 已经讲过——这里讲 K8s 层适配：

graph TB  GPU[GPU 资源细分]  GPU --> MIG[NVIDIA MIG
硬件级]  GPU --> VGPU[NVIDIA vGPU
软件许可]  GPU --> TS[Time-Slicing
K8s 软件]  GPU --> MPS[CUDA MPS
进程级]

MIG（A100/H100）

# 启用 MIG
nvidia-smi -i 0 -mig 1
nvidia-smi mig -cgi 9,9,9   # 创建 3 个 1g.10gb

# K8s 看到
nvidia.com/mig-1g.10gb
nvidia.com/mig-2g.20gb
nvidia.com/mig-3g.40gb

MIG 后每个实例独立显存、SM、L2 缓存——真正的硬件隔离。

Time-Slicing

nvidia-device-plugin 配置：
  sharing:
    timeSlicing:
      replicas: 4           # 每张 GPU 切成 4 份

K8s 看到：     8 GPU 节点 → 32 个 nvidia.com/gpu

适合：     推理 / 开发
不适合：    训练（互相抢，性能不可预测）

CUDA MPS（Multi-Process Service）

MPS：     多个 CUDA 进程共享一张 GPU
启用：     nvidia-cuda-mps-control -d
应用：     HPC 多进程任务

K8s 集成：     部分插件支持

NVIDIA GPU Operator

K8s 上 GPU 全栈管理：

nvidia-gpu-operator 包含：     
  - Driver Container（容器化驱动）
  - Device Plugin
  - DCGM Exporter（监控）
  - GPU Feature Discovery（标签）
  - MIG Manager
  - Network Operator（GPUDirect）

一键部署整个 GPU stack——但有性能开销和 license 复杂度。

NUMA-aware 调度：GPU 拓扑

8 GPU 服务器 GPU ↔ CPU 的拓扑：

graph TB  CPU0[CPU Socket 0
NUMA 0] --- PCIe0[PCIe Switch 0]  CPU1[CPU Socket 1
NUMA 1] --- PCIe1[PCIe Switch 1]    PCIe0 --- G0[GPU 0] & G1[GPU 1] & G2[GPU 2] & G3[GPU 3]  PCIe1 --- G4[GPU 4] & G5[GPU 5] & G6[GPU 6] & G7[GPU 7]    G0 ---|NVLink| G4  G1 ---|NVLink| G5  ...

# 看 GPU NUMA 关联
nvidia-smi topo -m

# 输出矩阵：
# X = self
# NV1-18 = NVLink 链路数
# PXB = PCIe Switch
# PIX = PCIe Adjacent
# SYS = 跨 NUMA / 跨 CPU
# NODE = 同 NUMA

调度的智慧：

1
2
3

- DataLoader 进程绑到 GPU 同侧 NUMA 的 CPU 上
- 内存分配也要 NUMA-bind
- 否则 PCIe 跨 socket 性能崩 30-50%

CPU pinning for AI

# PyTorch DataLoader
import os
import torch

# DataLoader workers 绑核
os.sched_setaffinity(0, {0, 1, 2, 3, 4, 5, 6, 7})

# 也可以用 numactl
# numactl --cpunodebind=0 --membind=0 python train.py

# 容器层面 NUMA 绑定
docker run --cpuset-cpus=0-15 --cpuset-mems=0 ...

# K8s 通过 Topology Manager
kubelet --topology-manager-policy=single-numa-node

K8s 1.18+ 支持 Topology Manager——同时考虑 CPU + GPU + 网卡的 NUMA 亲和。

GPUDirect 在 OS 层

GPUDirect RDMA 让网卡直接读写 GPU 显存——OS 要做的事：

1. peer_mem 模块加载：     
   modprobe nvidia_peermem
   
2. GPU BAR 暴露给 PCIe peer-to-peer：     
   # nvidia-smi -q | grep -i bar
   
3. PCIe ACS 关闭：     
   # 否则 ACS 阻断 P2P
   setpci -s  ECAP_ACS+0x6.w=0:1f0

4. IOMMU 设置：     
   intel_iommu=on iommu=pt    # passthrough 模式

GPUDirect Storage（GDS）

GPU 直接读 NVMe：

GDS：     
  - cuFile API
  - 绕过 CPU 内存
  - 大数据集训练加速
  - PyTorch / NVIDIA DALI 支持

要求：     
  - NVIDIA MOFED 驱动
  - GPU + NVMe 在同一 PCIe Switch（理想）
  - 内核 5.x+

OS 对 HBM 的态度

GPU 显存（HBM）是不归 Linux 内核管的：

Linux 看到：     主机 DRAM
GPU 显存：       由 NVIDIA driver / CUDA Runtime 管
  - cudaMalloc
  - 不在 vmstat / free 里显示
  - nvidia-smi 看
  
Unified Memory（CUDA UM）：     
  - 假装 CPU/GPU 共用内存
  - 实际是 driver 在背后搬数据
  - 大模型训练用得少（性能不可控）

CXL 时代会改变这个——未来 GPU 显存可能”挂到 CPU 主存空间”：

CXL Type 3 远端内存设备：     
  - 暴露成普通 NUMA 节点
  - Linux 直接 mmap

CXL 上挂 HBM：     
  - 实验性，B200 后可能
  - 会改变 OS 对显存的认知

大文件 / 大内存：调优

大模型训练对 OS 的特殊压力：

模型权重文件：     
  Llama 70B FP16 = 140 GB
  GPT-3 175B = 350 GB
  → 单文件超过 100 GB 是常态
  
   ext4 / XFS 都没问题，但读写要：
  - 大块 IO（≥ 1 MB）
  - O_DIRECT 跳过 page cache
  - 多线程并行

进程地址空间：     
  PyTorch 训练进程：     1-2 TB 虚拟内存
  Linux 默认 64 TB 上限够用
  
mmap 支持：     
  CUDA Runtime 用 mmap 管 page-locked memory
  vm.max_map_count 要调大：
  sysctl vm.max_map_count=1048576

训练专用的 K8s 调度

普通 K8s scheduler 缺陷：     
  - 不懂 gang scheduling（几十个 Pod 要"全部启动 OR 不启动"）
  - 不懂拓扑（同 Pod 的 GPU 应该 NVLink 互联）
  - 不懂训练队列优先级

AI 专用调度器：     
  Volcano（华为 + 社区）：     gang scheduling
  Yunikorn：                  Apache 的多租户
  KAI Scheduler（NVIDIA Run.ai）：    GPU 池化
  Kueue（K8s 官方）：          Job Queueing

Gang Scheduling

传统 K8s：     一次调一个 Pod
Gang：         一组 Pod 必须同时调度

应用：     
  - 分布式训练（128 个 worker 必须一起启）
  - MPI 作业
  - RAY / Dask 集群

不 gang scheduling 时：     
  - 部分 Pod 已启动，等其他
  - 占资源不释放
  - 集群死锁

训练相关的内核参数

# 共享内存（PyTorch DataLoader 用）
sysctl kernel.shmmax=1099511627776   # 1 TB
echo "16G" > /sys/fs/cgroup//shm.size

# 文件描述符
ulimit -n 1048576
echo "* soft nofile 1048576" >> /etc/security/limits.conf
echo "* hard nofile 1048576" >> /etc/security/limits.conf

# 进程数
ulimit -u unlimited
echo "* soft nproc unlimited" >> /etc/security/limits.conf

# 内存锁定（GPUDirect 需要）
ulimit -l unlimited
echo "* soft memlock unlimited" >> /etc/security/limits.conf
echo "* hard memlock unlimited" >> /etc/security/limits.conf

# 大页
vm.nr_hugepages = 8192

# 网络（NCCL / IB）
net.core.rmem_max = 268435456
net.core.wmem_max = 268435456
net.core.netdev_max_backlog = 30000

NPU 调度：昇腾 / 寒武纪等

国产 NPU 的 OS 适配：

华为昇腾（Ascend）：     
  - /dev/davinci0 ~ N
  - npu-smi 工具
  - K8s ascend-device-plugin
  - resources.limits: huawei.com/Ascend910

寒武纪（Cambricon）：     
  - /dev/cambricon_dev*
  - cnmon 工具
  - K8s cambricon-device-plugin
  - resources.limits: cambricon.com/mlu

摩尔线程：     
  - /dev/mtgpu*
  - mthreads-gmi
  - K8s mthreads-device-plugin

各家 device-plugin 仿照 NVIDIA 风格，但生态成熟度差异大。

checkpoint / 断点续训

大模型训练常见操作——对 OS IO 子系统的考验：

checkpoint 写入：     
  - 70B FP16 模型：     ~140 GB
  - 训练优化器状态：     280-400 GB
  - 激活值 / 元数据：     几十 GB
  - 总：     500 GB - 1 TB / checkpoint
  - 频率：     每 1-2 小时一次

要求：     
  - 高速文件系统：     Lustre / WekaFS / GPFS
  - 网络足够（万卡级用 InfiniBand 写）
  - 所有 GPU 同时写 → 集合 IO

故障恢复：     
  - 节点挂了 → 训练框架自动从最近 checkpoint 恢复
  - PyTorch FSDP / DeepSpeed 都有此能力
  - SLA：     一次故障 < 30 分钟恢复

监控：DCGM / Prometheus

DCGM（Data Center GPU Manager）：     
  - NVIDIA 官方 GPU 监控
  - dcgm-exporter 暴露 Prometheus 格式
  - 关键指标：     
    GPU 利用率、显存、温度、功耗、ECC 错误
    
Prometheus + Grafana：     
  - dcgm-exporter
  - node-exporter
  - kube-state-metrics
  - 一图看全集群

DCGM 监控万卡集群：     
  - 每秒几万 metric
  - 异常自动告警
  - 故障节点自动隔离

容器与 GPU 的几个老坑

坑 1：容器里看不到 nvidia-smi

# 没装 nvidia-container-toolkit
apt install nvidia-container-toolkit
# 或 RHEL：
dnf install nvidia-container-toolkit

# 重启 Docker
systemctl restart docker

坑 2：CUDA 版本不匹配

Host driver 版本必须 ≥ Container 内 CUDA 版本
查看：     nvidia-smi（看左上角 CUDA Version）

Host driver 535 → 兼容 CUDA 12.x
Host driver 470 → 仅兼容 CUDA 11.x

坑 3：MIG 实例不可见

MIG 启用后，容器要明确请求 MIG 实例：
  resources.limits:
    nvidia.com/mig-1g.10gb: 1
    
不能再用 nvidia.com/gpu: 1（除非禁 MIG）

坑 4：训练 Pod OOM

显存 OOM：     batch size / sequence length 太大
主机内存 OOM：     DataLoader workers 太多
SHM 不够：     /dev/shm 默认 64 MB，DataLoader 经常需要更大

K8s 调大 SHM：     
  spec:
    containers:
    - volumeMounts:
      - mountPath: /dev/shm
        name: dshm
    volumes:
    - name: dshm
      emptyDir:
        medium: Memory
        sizeLimit: 16Gi

坑 5：跨 NUMA 性能损失

8 GPU Pod 没有 numa-aware 调度：     
  - 跨 socket PCIe 通信
  - DataLoader CPU 在另一个 NUMA
  - 实测性能损失 20-40%

解决：     
  - 启用 K8s Topology Manager
  - 训练框架显式 numactl

坑 6：NCCL 启动失败

症状：     "NCCL WARN Failed to open socket"
常见原因：     
  - SHM 太小
  - ulimit -l（memlock）太小
  - IB 设备不可见
  - PCIe ACS 没关
  - Container 没 IPC=host

坑 7：GPU 假性死机

GPU "stuck" 但 nvidia-smi 还能查：     
  - dmesg | grep "Xid"  → 看 NVIDIA Xid 错误
  - Xid 13/31/63/79：通常硬件 / 散热问题
  - 重启 GPU：nvidia-smi --gpu-reset -i 
  - 持续：     更换 GPU

大模型训练时 OS 实战清单

# /etc/sysctl.d/99-ai-training.conf
fs.file-max = 2097152
fs.aio-max-nr = 1048576
kernel.shmmax = 1099511627776
kernel.shmall = 268435456
vm.max_map_count = 1048576
vm.swappiness = 10
vm.dirty_ratio = 5
vm.dirty_background_ratio = 2
net.core.rmem_max = 268435456
net.core.wmem_max = 268435456
net.core.netdev_max_backlog = 30000

# /etc/security/limits.conf
* soft nofile 1048576
* hard nofile 1048576
* soft nproc unlimited
* hard nproc unlimited
* soft memlock unlimited
* hard memlock unlimited

# 启动参数（GRUB）
intel_iommu=on iommu=pt
default_hugepagesz=2M hugepagesz=2M hugepages=8192
nohz_full=8-31 isolcpus=8-31         # 隔离训练用 CPU
nosoftlockup
mitigations=off                       # 关 spectre 等（性能优先）

OS 在 AI 集群的角色变化

graph TB  OLD[传统 OS]  OLD --> O1[管理 CPU/MEM/IO]    NEW[AI 集群 OS]  NEW --> N1[GPU 调度 + 拓扑]  NEW --> N2[NUMA + GPU 联合调度]  NEW --> N3[大文件 IO + checkpoint]  NEW --> N4[InfiniBand + RDMA]  NEW --> N5[BPF observability]  NEW --> N6[Container + K8s 集成]

一些数字直觉

nvidia-driver 升级：     
  - 大版本（535→555）：     需重启
  - 同版本小修：     有时 modprobe 即可

GPU "ready" 时间：     
  - 节点重启：     5-10 分钟（初始化）
  - 容器调度后启动：     5-30 秒

GPU 利用率监控：     
  - dcgm 1 秒采样
  - K8s prometheus 15 秒间隔
  - 8 GPU 节点：     生成 ~50 个 metric / 秒

万卡集群 OS 配置一致性：     
  - Ansible / Salt：     5-30 分钟
  - 配置漂移检测：     必备

国产 OS 的 AI 适配

openEuler：     
  - 与昇腾深度集成
  - npu-smi、ascend-device-plugin 已包
  - "openEuler AI 版"

龙蜥（Anolis OS）：     
  - 与寒武纪 / 摩尔线程适配
  - SIG-AI 工作组

麒麟（Kylin）：     
  - 商用支持华为昇腾
  - 政企信创主流

待补充：国产 OS 在大模型训练集群的实际部署。

小结

AI 时代 OS 要管的多了： GPU/NPU 调度、NUMA + GPU 拓扑、大 IO
nvidia-device-plugin + GPU Operator 是 K8s 标配
MIG / vGPU / Time-Slicing 是 GPU 资源细分手段
Volcano / KAI Scheduler 是训练专用调度器
GPUDirect / GDS 让网卡 / 存储直接访问 GPU 显存
大模型训练对 OS 内核参数（SHM / memlock / file-max）有特殊要求
国产 OS 已与昇腾 / 寒武纪深度适配

下一篇讲国产服务器 OS——欧拉、麒麟、龙蜥、统信、深度等。

内核内部 —— 调度器、网络栈、文件系统

2026-02-01T12:35:00.000Z

服务器运维的”硬核”调优都落在内核子系统上——CPU 调度、网络协议栈、文件系统。本文按三大子系统展开。

一张全景

graph TB  K[Linux Kernel]  K --> SCH[进程调度
CFS / EEVDF / sched_ext]  K --> NET[网络栈
TCP/IP / XDP / eBPF]  K --> FS[文件系统
ext4 / XFS / Btrfs / ZFS]  K --> MM[内存管理
NUMA / Page / Huge Page]  K --> IO[IO 子系统
blk-mq / io_uring]  K --> SEC[安全
SELinux / Seccomp / capabilities]

进程调度

CFS（Completely Fair Scheduler）

Linux 默认调度器（2.6.23+，2007）：

设计：     基于"虚拟运行时间"的红黑树
目标：     公平分配 CPU 时间
关键数据结构：     红黑树 / 任务的 vruntime

调度决策：
  - 选 vruntime 最小的任务运行
  - 周期性 tick 更新 vruntime
  - 抢占点检查

CFS 的几个调优参数：

# /proc/sys/kernel/
sched_min_granularity_ns        # 最小调度粒度，默认 750000 ns
sched_wakeup_granularity_ns     # 唤醒抢占粒度，默认 1000000 ns
sched_migration_cost_ns         # 迁移成本，默认 500000 ns
sched_latency_ns                # 调度周期，默认 6000000 ns

# 调优
sysctl -w kernel.sched_migration_cost_ns=5000000   # 不轻易迁核

EEVDF（2023+）

Linux 6.6 默认替代 CFS：

EEVDF（Earliest Eligible Virtual Deadline First）：
  - 借鉴 1995 年学术论文
  - 比 CFS 在低延迟场景表现更好
  - 适配现代多核多 NUMA 工作负载
  - 6.6 LTS 默认

CFS vs EEVDF 是 Linux 调度器 16 年来最大变化。

sched_ext（可插拔调度器）

sched_ext（6.12+）：
  - 用 BPF 实现自定义调度器
  - 不需要重新编译内核
  - 实验性，Meta 主推

应用：     
  - 数据库专用调度器
  - 游戏低延迟调度器
  - AI 训练调度器

实时调度

SCHED_NORMAL（默认）：     CFS
SCHED_FIFO：              先进先出实时
SCHED_RR：                轮转实时
SCHED_DEADLINE：          截止时间调度
SCHED_IDLE：              低优先级
SCHED_BATCH：             批处理任务

# 设置实时优先级
chrt -f 99 ./mysql            # FIFO 99
chrt -p                  # 查看
chrt -p -f 50            # 改

# nice 调度
nice -n 10 ./batch_job
renice -n 5 -p

调度域和 NUMA

第二章已经讲过 NUMA——内核通过 scheduling domain 知道拓扑：

# 看调度域
cat /proc/sys/kernel/sched_domain/cpu0/domain*/name

# NUMA 信息
numactl -H
numactl --cpunodebind=0 --membind=0 ./app

CPU 亲和力工具：

1 2	`taskset -c 0-7 ./app # 绑核 0-7 taskset -p -c 0-7 # 改进程绑定`

网络协议栈

graph TB  APP[应用]  APP --> SOCKET[socket layer]  SOCKET --> TCP[TCP / UDP / SCTP]  TCP --> IP[IPv4 / IPv6]  IP --> NETF[netfilter / nftables]  NETF --> QDISC[Qdisc / Traffic Control]  QDISC --> NIC[NIC driver]  NIC --> HW[硬件网卡]    XDP[XDP] -.- NIC

TCP 拥塞控制

Linux 支持的拥塞控制算法：
  reno：     最早，已过时
  cubic：     Linux 默认（2007 起）
  bbr：      Google 出品（2016），延迟感知
  bbr2：     改进版
  bbr3：     最新
  dctcp：     数据中心专用
  westwood：     改进 reno

# 看可用算法
sysctl net.ipv4.tcp_available_congestion_control

# 当前用
sysctl net.ipv4.tcp_congestion_control

# 改成 BBR
modprobe tcp_bbr
sysctl -w net.ipv4.tcp_congestion_control=bbr
sysctl -w net.core.default_qdisc=fq

BBR 在长肥管道（LFN）上表现更好——视频流 / 跨地域传输的标配。

TCP 调优参数

# 缓冲区大小（10G+ 网卡建议调大）
sysctl -w net.core.rmem_max=134217728
sysctl -w net.core.wmem_max=134217728
sysctl -w net.ipv4.tcp_rmem="4096 87380 134217728"
sysctl -w net.ipv4.tcp_wmem="4096 65536 134217728"

# 连接队列
sysctl -w net.core.somaxconn=65535
sysctl -w net.ipv4.tcp_max_syn_backlog=65535

# TIME_WAIT 复用
sysctl -w net.ipv4.tcp_tw_reuse=1

# Fast Open
sysctl -w net.ipv4.tcp_fastopen=3

# 持久化
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.d/99-tuning.conf
sysctl --system

XDP：高速包处理

XDP（eXpress Data Path）让 BPF 程序在网卡驱动层就处理包——包没进网络栈就被处理：

graph LR  NIC[网卡] --> XDP[XDP BPF]  XDP --> D1{决策}  D1 -- DROP --> X[丢弃]  D1 -- TX --> NIC  D1 -- REDIRECT --> NIC2[其他网卡]  D1 -- PASS --> NS[正常网络栈]

性能：

1
2
3

XDP_DROP（DDoS 防护）：     20+ Mpps / 核
XDP_TX（负载均衡）：        10-15 Mpps / 核
传统 iptables：             几百 Kpps / 核

应用：

- DDoS 防护（Cloudflare、Facebook）
- 负载均衡（Katran）
- 抓包（xdpdump）
- 加速容器网络（Cilium）

netfilter / nftables

iptables（传统）：
  - 规则线性匹配，N 条规则 O(N) 性能
  - 内核已不主推

nftables（现代）：
  - 哈希表匹配，性能 O(1)
  - 命令更简洁
  - RHEL 8+ / Ubuntu 20.04+ 默认
  - iptables 命令可作为 nftables 兼容层

iptables → nftables 迁移：
  iptables-translate "iptables -A INPUT ..."

IPVS

IPVS（IP Virtual Server）：
  - 内核 L4 负载均衡
  - 比 iptables 快很多
  - K8s kube-proxy 支持 IPVS 模式
  - LVS（Linux Virtual Server）项目核心

文件系统

graph TB  FS[Linux 文件系统]  FS --> LOCAL[本地]  FS --> NETWORK[网络]  FS --> SPECIAL[特殊]    LOCAL --> EXT[ext2/3/4]  LOCAL --> XFS[XFS]  LOCAL --> BTRFS[Btrfs]  LOCAL --> ZFS[ZFS]  LOCAL --> F2FS[F2FS]    NETWORK --> NFS[NFS]  NETWORK --> CIFS[CIFS/SMB]  NETWORK --> CEPHFS[CephFS]  NETWORK --> GLUSTER[GlusterFS]    SPECIAL --> PROC[/proc]  SPECIAL --> SYS[/sys]  SPECIAL --> TMPFS[tmpfs]  SPECIAL --> OVERLAY[OverlayFS
容器用]

ext4

ext4：     
  - Linux 默认（多数发行版）
  - 经久耐用
  - 单文件最大 16 TB
  - 单卷最大 1 EB
  - 不支持原生压缩 / 快照

仍是企业 Linux 服务器最常用的根文件系统。

XFS

XFS：     
  - SGI 1993 年 IRIX 移植到 Linux
  - 大文件性能好
  - 默认延迟分配
  - 单卷最大 8 EB
  - RHEL 7+ 默认根文件系统
  - 不支持 shrink（缩容）

适用：     大文件场景，数据库，存储节点

Btrfs

Btrfs：     
  - "B-tree FS"
  - 写时复制（COW）
  - 原生快照、子卷、压缩、RAID
  - 单卷最大 16 EB
  - SUSE 默认（openSUSE / SLES）

历史问题：     
  - 早期 RAID 5/6 不稳
  - 大量碎片场景性能差
  - Red Hat 已不再支持

适用：     SUSE 系，桌面，开发机

ZFS

ZFS：     
  - Sun 1995 起开发，开源
  - 写时复制 + 校验和 + 压缩 + 去重
  - 软件 RAID（RAIDZ）
  - 单池可达 256 ZiB
  - License 问题不能合入 Linux 内核
  - Ubuntu 通过 DKMS 模块支持
  - 数据完整性最强

适用：     存储节点、备份、文件服务器

NFS

NFS（Network File System）：     
  - Sun 1984 起，跨平台
  - NFSv3：无状态，老但稳
  - NFSv4：有状态，加密
  - NFSv4.1 / pNFS：     并行 NFS
  - NFSv4.2：     新特性

调优：     
  - mount -o rsize=1048576,wsize=1048576,vers=4.2
  - 异步 / 同步选择
  - 端口 2049

CephFS / GlusterFS

CephFS：     
  - Ceph 存储集群提供 POSIX 文件系统
  - 元数据服务器（MDS）
  - 客户端 ceph-fuse 或内核 cephfs

GlusterFS：     
  - Red Hat 主推，已下马
  - 不需要专门元数据服务器

第四章已介绍。

OverlayFS

容器镜像分层的核心：

OverlayFS：     
  - lowerdir：镜像层（只读）
  - upperdir：容器写入层
  - merged：合并视图

Docker / containerd 默认 storage driver

tmpfs

tmpfs：     
  - 内存中的文件系统
  - 关机消失
  - /tmp / /run / /dev/shm 默认
  - 大小可指定（默认半内存）

内存管理

graph TB  MM[Memory Management]  MM --> PG[Page Allocator
buddy system]  MM --> SLAB[SLAB / SLUB
对象缓存]  MM --> VMA[VMA / mmap]  MM --> SWAP[Swap]  MM --> OOM[OOM Killer]  MM --> NUMA[NUMA Allocator]  MM --> THP[Transparent Huge Pages]

Huge Pages

减少 TLB miss，对大内存应用很重要：

# 看大页配置
cat /proc/meminfo | grep -i huge

# 静态大页 2 MB
echo 8192 > /proc/sys/vm/nr_hugepages
mkdir /mnt/hugepages
mount -t hugetlbfs none /mnt/hugepages

# 1 GB 大页（启动参数）
GRUB_CMDLINE_LINUX="default_hugepagesz=1G hugepagesz=1G hugepages=64"

# Transparent Huge Pages（动态）
cat /sys/kernel/mm/transparent_hugepage/enabled
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled

# THP 三选项：
# always：     自动用大页（数据库可能慢）
# madvise：     应用主动 madvise 才用（推荐）
# never：     禁用

数据库（Oracle / PostgreSQL / MongoDB）建议关 THP 改静态大页。

Swap

# 看 swap
swapon -s
free -h

# swappiness（0-100，越高越爱用 swap）
cat /proc/sys/vm/swappiness            # 默认 60
sysctl -w vm.swappiness=10             # 服务器一般调小

# swap 文件
fallocate -l 16G /swapfile
mkswap /swapfile
swapon /swapfile
echo "/swapfile none swap sw 0 0" >> /etc/fstab

数据库 / 大内存机器通常 swap = 0 或很小——别让 swap 拖累性能。

OOM Killer

内存耗尽时杀进程：
  - OOM Score 计算（/proc//oom_score）
  - 优先杀大的、可恢复的
  - 重要进程 echo -1000 > /proc//oom_score_adj 不被杀

调整：     
  - vm.overcommit_memory = 0/1/2
  - vm.overcommit_ratio = 50（百分比）

IO 子系统

graph TB  APP[应用 read/write]  APP --> VFS[VFS 抽象层]  VFS --> FS[具体文件系统]  FS --> BIO[block IO 层]  BIO --> SCHED[IO 调度器]  SCHED --> DRV[块设备驱动]  DRV --> HW[硬件 SSD/HDD]

IO 调度器（blk-mq）

现代 Linux blk-mq 多队列：
  none：     无调度，对 NVMe 默认
  mq-deadline：     deadline 改进
  bfq：     公平调度
  kyber：     低延迟

NVMe 用 none：     
  cat /sys/block/nvme0n1/queue/scheduler
  
  原因：硬件已经多队列，软件调度反而拖累

1
2
3

# 改 IO 调度器
echo none > /sys/block/nvme0n1/queue/scheduler
echo mq-deadline > /sys/block/sda/queue/scheduler

io_uring

7.1 已介绍——异步 IO 革命。配套 API：

io_uring_queue_init();
io_uring_get_sqe();
io_uring_prep_read();
io_uring_submit();
io_uring_wait_cqe();

应用：

1
2
3

PostgreSQL 17+：     io_uring 后端
ScyllaDB：           原生 io_uring
Tokio（Rust 异步）：     io_uring 支持

安全子系统

SELinux / AppArmor

SELinux（Red Hat）：     
  - 标签 / 类型强制
  - 默认严格
  - RHEL / Fedora 默认 enforcing

AppArmor（Ubuntu）：     
  - 路径基础
  - 比 SELinux 简单
  - Ubuntu / Debian 默认

# SELinux
getenforce
setenforce 0       # 临时关
semanage / restorecon

# AppArmor
aa-status
aa-enforce / aa-complain

Seccomp

Seccomp：     系统调用白名单
  - 进程限制只能调几个 syscall
  - 容器逃逸防护
  - Docker 默认 seccomp profile

应用：     
  - 容器（Docker / K8s）
  - 沙箱（Chromium、Firefox）
  - 不可信代码执行

capabilities

传统 root：     全权或全无权
capabilities：     细粒度
  CAP_NET_ADMIN：     管网络
  CAP_SYS_ADMIN：     管系统（万能）
  CAP_NET_BIND_SERVICE：     绑端口 < 1024
  ...
  
容器默认 drop ALL，再 add 必需的几个。

内核参数总览

# 看所有 sysctl
sysctl -a

# 常用调优文件
/etc/sysctl.conf
/etc/sysctl.d/*.conf

# 临时改
sysctl -w net.core.somaxconn=65535

# 持久化
echo "net.core.somaxconn=65535" >> /etc/sysctl.d/99-tuning.conf
sysctl --system

服务器一般调优起点

# /etc/sysctl.d/99-server.conf

# 网络
net.core.somaxconn = 65535
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30

# 内存
vm.swappiness = 10
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5

# 文件
fs.file-max = 2097152
fs.nr_open = 1048576

# 进程
kernel.pid_max = 4194304

内核 BPF 工具

# bpftrace 一行命令
bpftrace -e 'tracepoint:syscalls:sys_enter_open { printf("%s\n", str(args->filename)); }'

# 常见 BCC 工具
opensnoop      # 看打开文件
execsnoop      # 看进程执行
biolatency     # 看 IO 延迟分布
tcpconnect     # 看 TCP 连接
runqlat        # 看运行队列延迟

BPF 工具是排障神器——比 strace 快几十倍。

一些查询命令

# CPU
mpstat -P ALL 1
top / htop / btop
pidstat 1
perf top
perf stat / perf record

# 内存
free -h
vmstat 1
cat /proc/meminfo
slabtop

# 网络
ss -s                        # socket 总览
ss -tnp                      # TCP 连接
iftop / nethogs              # 流量
ethtool -S eth0              # 网卡统计
tcpdump -i eth0 -w cap.pcap

# 磁盘
iostat -x 1
iotop
dstat                        # 综合
fio                          # 性能测试

# 内核日志
dmesg
journalctl -k                # kernel logs
journalctl --since "1 hour ago"

内核调优的方法论

graph TD  M[Measure 测量]  M --> A[Analyze 分析瓶颈]  A --> H[Hypothesize 假设]  H --> C[Change 改一项]  C --> V[Verify 验证]  V --> M

Brendan Gregg 的"USE 方法"：     
  Utilization：     利用率
  Saturation：     饱和度（队列、等待）
  Errors：     错误数

每次只改一项 → 测量对比 → 不要改"一堆"。

内核版本与新特性查询

uname -r                              # 内核版本

# 新特性查询（编译开关）
zcat /proc/config.gz | grep 
# 或
cat /boot/config-$(uname -r) | grep 

# 模块管理
lsmod | grep 
modprobe 
modinfo

一些数字直觉

syscall 开销：     
  read/write：    几十 ns
  socket：        几百 ns
  fork：          几十 μs
  exec：          几百 μs

内存访问：     
  L1 cache：       1 ns
  L2 cache：       5 ns
  L3 cache：       30 ns
  本地 DRAM：     100 ns
  远端 NUMA：     200 ns
  HBM：           ~50 ns

文件系统：     
  ext4 顺序读：    >5 GB/s（NVMe）
  XFS 大文件：     >10 GB/s
  本地 NVMe 4K 随机读：     500K-1M IOPS
  
网络：     
  本地 ping：      几十 μs
  同机房 ping：    < 1 ms
  跨城 ping：      ~10-50 ms
  跨国 ping：      ~100-200 ms

小结

Linux 内核三大子系统：调度（CFS/EEVDF）、网络（TCP/IP/XDP）、文件系统（ext4/XFS/Btrfs/ZFS）
io_uring + eBPF 是近年内核最重要新特性
TCP BBR 是长肥管道的拥塞控制选择
nftables 已替代 iptables
THP 在数据库要谨慎用
BPF / bpftrace 是排障神器
调优要”测量-假设-改一项-验证”循环

下一篇讲 AI 时代 OS 适配——vGPU、NPU 调度、大模型训练 OS 优化。

容器与 Kubernetes —— 比 VM 更轻的抽象

2026-01-25T07:50:00.000Z

容器是 Linux 内核两个能力（namespace + cgroup）”打包”出来的产品——本质上是进程隔离而非虚拟化。本文从内核机制讲到 K8s 调度。

容器的两个内核基础

graph TB  KERNEL[Linux Kernel]  KERNEL --> NS[Namespace
资源视图隔离]  KERNEL --> CG[Cgroup
资源消耗限制]    NS --> N1[mnt：文件系统]  NS --> N2[pid：进程树]  NS --> N3[net：网络栈]  NS --> N4[uts：主机名]  NS --> N5[ipc：进程通信]  NS --> N6[user：用户/UID]  NS --> N7[cgroup：cgroup 视图]  NS --> N8[time：时间]    CG --> CG1[CPU]  CG --> CG2[内存]  CG --> CG3[IO]  CG --> CG4[PID 数]  CG --> CG5[device 访问]

容器 = 一组进程绑定到一组 namespace + cgroup。

namespace：视图隔离

# 查看进程的 namespace
ls -l /proc/$$/ns/
# net -> net:[4026531956]
# pid -> pid:[4026531836]
# ...

# 进入容器的 namespace
nsenter -t  -n ip addr      # 进入网络 ns 看 IP
nsenter -t  -m              # 进入挂载 ns

# 创建新 namespace 跑 shell
unshare --net --pid --fork bash

每个 namespace 独立一份资源视图——容器内的 PID 1 是宿主机的 PID 12345。

cgroup：资源限制

# cgroup v1（旧）
ls /sys/fs/cgroup/

# cgroup v2（新，RHEL 9 / Ubuntu 22.04+ 默认）
mount | grep cgroup2

# 看进程的 cgroup
cat /proc//cgroup

# 限制 CPU
echo "100000 100000" > /sys/fs/cgroup//cpu.max  # 1 核

# 限制内存
echo "1G" > /sys/fs/cgroup//memory.max

cgroup v1 vs v2

cgroup v1（2007）：
  - 每个 controller 独立树
  - CPU / memory / blkio 各管各的
  - 复杂，难统一

cgroup v2（2016+，2022 默认）：
  - 统一树
  - controller 在节点上启用
  - 内核优化更多
  - K8s 1.25+ 默认 cgroup v2

OCI 标准：容器的”协议”

容器市场曾经只有 Docker——后来 OCI（Open Container Initiative）标准化：

graph TB  IMG[OCI Image Spec
镜像格式标准]  RUN[OCI Runtime Spec
运行时标准]  DIST[OCI Distribution Spec
镜像仓库标准]    IMG --> R1[Docker / containerd 镜像]  IMG --> R2[Buildah 构建]    RUN --> R3[runc
默认运行时]  RUN --> R4[crun
C 实现]  RUN --> R5[kata-runtime
VM 后端]  RUN --> R6[gVisor runsc
用户态内核]

任何符合 OCI 的工具链都可以互操作——这就是容器生态成功的关键。

容器运行时的演进

graph LR  D[Docker
2013] --> D2[Docker + libcontainer]  D2 --> CD[containerd
2017]  CD --> CDV2[containerd 2.x
K8s 默认]  D --> RUN[runc
2015 拆出]  CRIO[CRI-O
K8s 专用]

Docker

Docker（2013）：     
  - 第一个让"容器易用"的工具
  - 镜像分层 / Dockerfile / 仓库
  - 早期是 daemon 单体

Docker 现状：
  - 桌面开发仍主流（Docker Desktop）
  - 服务器运行时已被 containerd 替代
  - K8s 1.24+ 不再原生支持 Docker

containerd

containerd：
  - Docker 拆出的运行时层
  - K8s 默认运行时
  - 简洁、稳定、性能好
  - Apache 2.0 开源

工具：     
  ctr - containerd CLI
  nerdctl - 类似 docker CLI
  
配置文件：     /etc/containerd/config.toml

CRI-O

CRI-O：     
  - Red Hat 主推
  - K8s CRI（Container Runtime Interface）专用
  - 最小化运行时
  - OpenShift 默认

runc / crun

runc：     
  - Go 实现的 OCI 运行时
  - Docker / containerd 默认
  
crun：     
  - C 实现，启动快 50%
  - Red Hat 主推
  - Podman / CRI-O 推荐

Docker / containerd 实战

# 老版 Docker
docker run -d -p 80:80 nginx
docker ps
docker logs 
docker exec -it  bash
docker images
docker pull nginx:alpine

# containerd（ctr）
ctr image pull docker.io/library/nginx:latest
ctr run -d docker.io/library/nginx:latest nginx-container

# nerdctl（更友好）
nerdctl run -d -p 80:80 nginx
nerdctl ps
nerdctl logs 

# Podman（无 daemon Docker 替代）
podman run -d -p 80:80 nginx
podman ps

镜像分层

FROM ubuntu:22.04         # Layer 1
RUN apt update            # Layer 2
RUN apt install nginx -y  # Layer 3
COPY config /etc/nginx/   # Layer 4
CMD ["nginx", "-g", "daemon off;"]

每个 Layer 是只读 tarball——多容器共享相同 Layer，节省磁盘。

1
2
3

# 看镜像分层
docker image history nginx:latest
docker inspect nginx:latest | jq .[0].RootFS

镜像格式：

OCI Image Format：
  config.json
  layer1.tar.gz
  layer2.tar.gz
  ...
  manifest.json

仓库：     
  Docker Hub（默认）
  GitHub Container Registry（ghcr.io）
  Quay.io
  自建：     Harbor / Nexus / Artifactory

容器网络

graph TB  NETMODES[容器网络模式]  NETMODES --> M1[bridge
默认
NAT]  NETMODES --> M2[host
共享主机]  NETMODES --> M3[none
无网络]  NETMODES --> M4[overlay
跨主机]  NETMODES --> M5[macvlan
每容器独立 MAC]  NETMODES --> M6[CNI
K8s 用]

CNI（Container Network Interface）

K8s 网络抽象，K8s 通过 CNI 调用网络插件：

CNI plugin 主流：
  Flannel：     简单，VXLAN
  Calico：      BGP，性能好
  Cilium：      eBPF，最现代
  Weave：       端到端加密
  Multus：      多网卡 CNI 适配器

调用方式：
  K8s 创建 Pod → kubelet 调 CNI plugin
  → plugin 创建 veth pair / 配置 IP / 路由

Cilium：eBPF-based CNI

Cilium 是 2024-2026 年趋势：
  - 数据面用 eBPF（不用 iptables）
  - L3-L7 策略
  - 服务网格能力（Cilium Mesh）
  - 完全替代 kube-proxy
  - 性能：vs iptables / IPVS 快几倍

Kubernetes 架构

graph TB  subgraph CP["控制面"]    APIS[API Server]    SCH[Scheduler]    CTRL[Controller Manager]    ETCD[etcd
状态存储]    CCM[Cloud Controller]  end    subgraph WK["Worker Node × N"]    KUBELET[kubelet]    KP[kube-proxy / Cilium]    CRI[containerd]    CNI[CNI plugin]        KUBELET --> CRI    KUBELET --> CNI  end    APIS --> KUBELET  CTRL --> APIS  SCH --> APIS  ETCD --- APIS

K8s 核心概念：

Pod：       一组容器（共享 net + storage namespace）
Deployment：声明式管理 Pod 副本
Service：   负载均衡 + 服务发现
ConfigMap / Secret：配置和密钥
Namespace（K8s 概念，与内核不同）：     租户/项目隔离
PersistentVolume：     持久化存储
Ingress：     L7 路由
DaemonSet：     每节点一份
StatefulSet：     带状态副本
Job / CronJob：     一次性 / 定时任务

CRD：     扩展资源类型
Operator：     用 CRD + Controller 实现自动化运维

K8s 调度器

graph TB  POD[新 Pod 创建]  POD --> SCH[Scheduler]  SCH --> F1[Filter
过滤不能放的节点]  F1 --> F2[节点亲和 / 反亲和]  F1 --> F3[资源够不够]  F1 --> F4[Taint / Toleration]  F1 --> SC[Score
剩余节点评分]  SC --> S1[资源平衡]  SC --> S2[镜像本地化]  SC --> S3[拓扑分布]  SC --> SEL[选最优节点]  SEL --> KUB[kubelet 启动 Pod]

调度过程：

1. 用户提交 Pod yaml → APIs Server
2. APIs 写 etcd
3. Scheduler 读到未绑定的 Pod
4. Filter 阶段：排除不合适的节点
5. Score 阶段：剩下节点打分
6. 选最高分节点，写绑定到 etcd
7. 该节点 kubelet 收到 → 启动容器

调度策略：

节点亲和（NodeAffinity）：     "只在 GPU 节点跑"
Pod 亲和（PodAffinity）：       "和 X Pod 同节点"
反亲和（AntiAffinity）：        "和 X Pod 不同节点"
Taint / Toleration：           "节点专用，只接受能容忍的 Pod"
Topology Spread：              "Pod 均匀分布在多个 zone"

kubelet 与 Node Agent

每节点上跑 kubelet：

kubelet 职责：
  - 接 APIs Server 的 Pod 创建/删除
  - 通过 CRI 调 containerd 启动容器
  - 通过 CNI 配置网络
  - 通过 CSI 挂载存储
  - 心跳上报节点状态
  - 健康检查（Liveness / Readiness）
  - 资源监控（CPU/MEM）上报

systemd 单元：     kubelet.service
日志：     journalctl -u kubelet

CSI：存储插件

CSI（Container Storage Interface）：
  - 把存储和 K8s 解耦
  - 各厂家实现自己 CSI driver
  - K8s 不需要硬编码各种存储

主流 CSI：
  AWS EBS / Azure Disk / GCP PD
  Ceph CSI（RBD / CephFS）
  NFS CSI
  local-path / Longhorn
  存储厂家：Pure / NetApp / 戴尔 / 华为 OceanStor

K8s 网络模型

K8s 网络的 4 个要求：

1. Pod 与 Pod 之间：不需要 NAT，直连
2. Pod 与 Node 之间：双向直连
3. Node 上有"集群 IP" → Pod IP 的路由
4. Service 提供稳定 VIP

实现方案：
  - Cilium：eBPF
  - Calico：BGP
  - Flannel：VXLAN / Host-GW
  - 各家云厂家自家网络

Service 与 kube-proxy

ClusterIP（默认）：     集群内部 VIP
NodePort：              每节点开同一端口，对外
LoadBalancer：          云提供 LB（AWS ELB 等）
ExternalName：          DNS 别名

kube-proxy 实现：
  iptables 模式：       规则数随 Service 数线性增（性能差）
  IPVS 模式：           哈希表，性能好
  eBPF（Cilium）：      最高性能，规则数 O(1)

可观测：metrics、logs、tracing

Metrics：
  - Prometheus + Grafana（标准组合）
  - kube-state-metrics
  - cAdvisor（容器指标）
  - node-exporter（节点指标）

Logs：
  - Fluent Bit / Fluentd（采集）
  - Elasticsearch / Loki（存储）
  - Kibana / Grafana（查询）

Tracing：
  - OpenTelemetry（标准）
  - Jaeger / Tempo（后端）

K8s 在 AI 集群里的角色

传统 K8s：     微服务编排
AI K8s：     
  - GPU 资源管理（nvidia-device-plugin）
  - 多 GPU Pod 调度
  - 大模型训练 Pod 间通信（NCCL）
  - PyTorchJob / MPIJob CRD（Kubeflow）
  - Volcano / KAI Scheduler（gang scheduling）

AI 集群专用 K8s 发行版：
  Run.ai（NVIDIA 收购）：    GPU 池化
  Kubeflow：               ML 平台
  Determined AI：           训练管理
  KubeRay：                Ray on K8s

容器镜像安全

扫描镜像漏洞：
  Trivy：     最常用
  Clair：     CoreOS 出品
  Snyk：      商业
  Anchore：    商业

签名 / 验签：
  cosign：    Sigstore 出品
  Notary v2：    Docker 老的
  
SBOM（Software Bill of Materials）：     软件物料清单
  syft：     生成
  grype：    检测

容器的几个老坑

坑 1：忘记设资源限制

# 没设 limits → Pod 把节点吃光
resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 1000m
    memory: 1Gi

不设限制就是定时炸弹——某个 Pod 内存泄漏把整节点 OOM。

坑 2：用 latest tag

image: nginx:latest
  → 各节点拉的可能不同版本
  → 重启 Pod 后行为变了
  → 难追溯
  
正确：     image: nginx:1.26.2
更好：     image: nginx@sha256:xxx

坑 3：root 用户运行

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

容器逃逸的第一道屏障——非 root + 只读文件系统。

坑 4：默认 ServiceAccount 权限过大

默认 namespace 的 default ServiceAccount
   → 自动挂载 token
   → 容器内可以 kubectl 操作集群

正确：     
  - 用专用 ServiceAccount
  - 用 RBAC 限制
  - automountServiceAccountToken: false

坑 5：镜像太大

基础镜像选择：
  ubuntu:24.04：     ~80 MB
  debian:slim：     ~30 MB
  alpine：          ~5 MB
  distroless：     ~20 MB（Google 出品，无 shell）
  scratch：         0 MB（静态二进制）

镜像越小：
  - 拉取快
  - 攻击面小
  - 节省存储

坑 6：忽视健康检查

livenessProbe:
  httpGet: { path: /healthz, port: 8080 }
  initialDelaySeconds: 30
  periodSeconds: 10
readinessProbe:
  httpGet: { path: /ready, port: 8080 }

无健康检查 = 死了的容器还在收流量。

坑 7：节点资源碎片

节点 64 核，已用 40 核分散在多个 Pod
新建 Pod 要 32 核 → 找不到节点（虽然总剩余 24 核分散）
   → 调度失败

解决：     
  - bin-packing 调度策略
  - HPA / VPA 弹性扩缩
  - 节点资源池规划

K8s 多集群和联邦

单集群上限：~5000 节点（API Server 性能瓶颈）

多集群方案：
  Karmada（华为开源）：     联邦标准
  Cluster API：           K8s 风格管 K8s
  Rancher / OpenShift：     多集群管理面
  Submariner：             跨集群网络
  
应用：     
  - 跨地域容灾
  - 法规合规（数据不能跨境）
  - 资源池突破单集群上限

云原生 vs 传统

云原生（Cloud Native）特征：
  - 容器化打包
  - 微服务架构
  - 声明式 API
  - 不可变基础设施
  - DevOps 流程
  - 12-Factor App

CNCF（Cloud Native Computing Foundation）：
  - K8s 主家
  - 200+ 项目
  - 全球云原生标准

一些查询命令

# 容器层面
docker ps / nerdctl ps / crictl ps
docker inspect 
docker logs -f 
docker exec -it  sh

# K8s 层面
kubectl get nodes
kubectl get pods -A
kubectl describe pod 
kubectl logs  -c  -f
kubectl exec -it  -- sh
kubectl top pods
kubectl top nodes

# debug
kubectl debug node/ -it --image=busybox
kubectl get events --sort-by='.lastTimestamp'

# 配置
kubectl config get-contexts
kubectl config use-context

一些数字直觉

容器启动：     
  小镜像：    100-500 ms
  大镜像（首次拉）：    秒到分钟级
  
Pod 启动（含调度）：     
  普通业务：    1-3 秒
  GPU Pod：    5-10 秒（需要 device plugin）

K8s 集群规模：     
  推荐：    < 5000 节点
  超大：    联邦 / 多集群

K8s 控制面消耗：     
  小集群：    1-2 vCPU + 4 GB
  万节点：    8-16 vCPU + 32-64 GB（etcd 重）

国产云原生

阿里云 ACK：     深度定制 K8s
腾讯 TKE：       K8s + 自家增强
华为 CCE：       K8s + 容器服务
青云 KubeSphere：     国产 K8s 管理面（开源）
Rancher：       原 SUSE，被广泛用
KubeEdge：     边缘计算 K8s（华为开源）

国产容器引擎：
  iSulad（华为开源）：     轻量容器引擎
  PouchContainer（阿里开源）：    已停
  
国产容器仓库：     
  Harbor（VMware / CNCF）：     最广泛
  Quay：     Red Hat

待补充：国产 K8s 发行版的实际部署比例。

小结

容器 = namespace（视图隔离） + cgroup（资源限制）
OCI 标准化让生态健康
containerd 已替代 Docker 成为 K8s 默认运行时
Cilium / eBPF 是 K8s 网络的下一代
K8s 是云原生事实标准，调度器和 CRD 模型是核心
AI 集群有专用 K8s 发行版（Kubeflow / Volcano / Run.ai）
国产 K8s 发行版（阿里 ACK / 腾讯 TKE / 华为 CCE）已成熟

下一篇讲内核内部——调度器、网络栈、文件系统。

虚拟化 —— KVM、Xen、Hyper-V 与 SR-IOV

2026-01-18T14:25:00.000Z

虚拟化把一台物理机变成多台虚拟机，是云计算的根本基础。本文讲清虚拟化的演进、KVM / Xen / Hyper-V 三大方案、以及 SR-IOV / vGPU 等”硬件辅助”技术。

虚拟化的两种类型

graph TB  T1[Type 1 Hypervisor
裸金属]  T1 --> T1A[VMware ESXi]  T1 --> T1B[Microsoft Hyper-V]  T1 --> T1C[Xen]  T1 --> T1D[KVM 也算
跑在 Linux 内核里]    T2[Type 2 Hypervisor
宿主机型]  T2 --> T2A[VMware Workstation]  T2 --> T2B[VirtualBox]  T2 --> T2C[QEMU 用户态]  T2 --> T2D[Parallels]

数据中心只用 Type 1——直接跑在硬件上，性能最优。Type 2 是开发 / 桌面用。

CPU 虚拟化的硬件支持

CPU 虚拟化经历两个阶段：

2005 之前：纯软件虚拟化（VMware 早期、Xen para-virt）
  - 二进制翻译 / 修改客户机 OS
  - 性能损失 30-50%
  
2005+：硬件辅助虚拟化
  - Intel VT-x（2005）
  - AMD-V（2006）
  - 性能损失 < 5%
  - 客户机 OS 可不修改

后续硬件持续增强：

EPT / NPT：     第二级页表（地址翻译加速）
VPID：          TLB 标签（避免 vmexit 刷 TLB）
APICv：         中断虚拟化加速
VT-d / IOMMU：  IO 设备虚拟化（设备直通）
SR-IOV：        网卡 / GPU 单设备多虚机

ARM 也有等价：

1 2	`ARM VHE（Virtualization Host Extensions）： v8.1 ARM SMMU（System MMU）： IOMMU 等价`

KVM：Linux 内核里的虚拟化

KVM（Kernel-based Virtual Machine）是 Linux 2.6.20（2007）合入的内核虚拟化模块：

graph TB  HW[硬件 CPU + VT-x/EPT]  KVM[KVM 内核模块]  HW --> KVM    QEMU[QEMU 用户态]  KVM --- QEMU    GUEST1[VM 1 GuestOS]  GUEST2[VM 2 GuestOS]    QEMU --> GUEST1  QEMU --> GUEST2

KVM 架构特点：

- KVM 模块负责 CPU/内存虚拟化
- QEMU 负责设备模拟（磁盘 / 网卡 / 显卡）
- 每个 VM 是一个 QEMU 进程
- VM 内 vCPU 是一个 Linux 线程
- Linux 调度器调度 vCPU

KVM + QEMU 的实战

# 装包（Ubuntu / RHEL）
apt install qemu-kvm libvirt-daemon-system virt-manager
dnf install qemu-kvm libvirt virt-manager

# 启动 libvirtd
systemctl enable --now libvirtd

# virsh 命令
virsh list                       # 看运行中 VM
virsh list --all                # 看所有 VM
virsh start                 # 启动
virsh shutdown              # 优雅关机
virsh destroy               # 强制关闭
virsh dominfo               # VM 信息

# virt-install 创建 VM
virt-install --name=vm1 \
  --vcpus=4 --memory=8192 \
  --disk size=50 \
  --cdrom=ubuntu.iso \
  --os-variant=ubuntu24.04 \
  --network bridge=br0 \
  --graphics vnc

# 直接 QEMU 命令行（不通过 libvirt）
qemu-system-x86_64 -enable-kvm \
  -smp 4 -m 8G \
  -hda disk.qcow2 \
  -netdev user,id=net0 -device virtio-net,netdev=net0

KVM 的性能优化

# CPU pinning（绑核）
virsh vcpupin vm1 0 4-7        # vCPU 0 绑到物理 4-7

# NUMA 配置
virsh edit vm1
# 
#   ...
# 

# 大页内存
echo 8192 > /proc/sys/vm/nr_hugepages    # 16 GB 大页

# 关闭 KSM（多 VM 共享内存对延迟敏感场景关）
echo 0 > /sys/kernel/mm/ksm/run

virtio：半虚拟化设备

KVM 默认用 virtio——一组半虚拟化设备规范：

virtio-net：     网卡
virtio-blk：     块设备
virtio-scsi：    SCSI 控制器
virtio-balloon： 内存膨胀（VM 间动态分配）
virtio-fs：      文件系统共享
virtio-gpu：     GPU
virtio-rng：     随机数生成器

virtio 性能比模拟硬件（e1000、IDE）快 10-100 倍。

Xen

Xen 是 2003 年剑桥大学的研究项目，2007 年 Citrix 商业化：

graph TB  HW[硬件]  XEN[Xen Hypervisor
裸金属]  HW --> XEN    DOM0[Dom0
特权 Linux
控制 + 设备驱动]  DOMU1[DomU 1
客户 OS]  DOMU2[DomU 2]    XEN --- DOM0  XEN --- DOMU1  XEN --- DOMU2

Xen 的核心概念：

Dom0：     特权域，跑 Linux，提供设备驱动给其他 VM
DomU：     非特权域，普通 VM
PV：       Para-virtualization（半虚拟化），客户 OS 修改过
HVM：      Hardware Virtual Machine（全虚拟化）
PVH：      混合，HVM + PV 优点

Xen 的兴衰

2007-2015：Xen 是云鼻祖
  - AWS EC2 早期全 Xen
  - Citrix XenServer 企业市场
  - 阿里云 / 腾讯云早期也用 Xen
  
2015+：KVM 全面崛起
  - AWS Nitro 弃 Xen 转 KVM 衍生
  - 开源社区聚焦 KVM
  - Xen 主要剩 Citrix 商业产品

2023+：基本边缘化
  - 仍有少数嵌入式 / 安全场景
  - Xen 项目改名 Xen Hypervisor，Linux Foundation 下

Xen 已不是数据中心主流——除非有历史包袱，新建系统不上 Xen。

VMware ESXi

VMware 是 1998 年成立的虚拟化老厂，ESXi 是其裸金属 Hypervisor：

ESXi：     裸金属 Hypervisor
vSphere：  ESXi + vCenter（管理面）
NSX：      网络虚拟化
vSAN：     存储虚拟化

商业模式：高端商业，单 socket 订阅 license

2023：Broadcom 收购 VMware（$610 亿）
   - 大幅涨价 + 转订阅制
   - 中小客户大量逃离
   - 国产 / 开源替代加速

VMware 当前问题：

1. Broadcom 收购后涨价 200-300%
2. 永久 license 取消，全转订阅
3. 中小企业开始迁出（Proxmox / OpenStack / 国产）
4. 国产虚拟化（深信服、新华三 H3C UIS、华为 FusionCompute）替代加速

待补充：VMware 客户流失数据 / 国产替代迁移规模。

Microsoft Hyper-V

Microsoft 自家 Hypervisor：

Windows Server Hyper-V：     企业级
Azure Hypervisor：           云上变体
Hyper-V Server：             免费独立版（已停）

特点：     
  - Windows / Linux VM 都支持
  - 与 Windows Server 集成
  - Azure 云的基础

市场：    主要是 Microsoft 客户和 Azure 云

OpenStack：开源云的”操作系统”

OpenStack 不是 Hypervisor 而是云管理平台：

graph TB  CLI[CLI / Web UI]  CLI --> NOVA[Nova
计算 / VM 管理]  CLI --> NEUTRON[Neutron
网络]  CLI --> CINDER[Cinder
块存储]  CLI --> SWIFT[Swift
对象存储]  CLI --> KEYSTONE[Keystone
身份]  CLI --> GLANCE[Glance
镜像]  CLI --> HEAT[Heat
编排]    NOVA --> KVM[KVM / Xen / Hyper-V]  NEUTRON --> OVS[Open vSwitch / OVN]

OpenStack 在中国被广泛使用：

华为 FusionCloud / 华为云：    OpenStack 衍生
H3C UIS：                    OpenStack 衍生
深信服超融合：                  OpenStack 衍生
ZStack：                     国产 OpenStack 替代

公有云 / 私有云的"标准"开源平台

SR-IOV：硬件虚拟化的”作弊”

SR-IOV（Single Root I/O Virtualization）让一个 PCIe 设备自己变成”多个虚拟设备”：

graph TB  PHY[物理网卡
PF Physical Function]  PHY --> V1[VF 1
Virtual Function]  PHY --> V2[VF 2]  PHY --> V3[VF 3]  PHY --> VN[VF N
最多 256]    V1 -.- VM1[VM 1]  V2 -.- VM2[VM 2]  V3 -.- VM3[VM 3]

每个 VF 在 VM 看来就是独立网卡——绕过 Hypervisor 的软件交换机，直接 DMA。

性能对比：

1 2	`virtio-net：几 GB/s SR-IOV VF 直通： ~95% 物理性能`

应用：

- 云裸金属：    每个 VM 一个 VF
- 5G 网元：    极致延迟
- HPC：        类似裸金属
- AI 训练 VM： GPU 也要 SR-IOV

VFIO 与设备直通

VFIO（Virtual Function I/O）是 Linux 把 PCIe 设备暴露给用户态的框架：

应用：     
  - GPU 直通：把整张 H100 给一个 VM
  - 网卡直通：SR-IOV VF 直通
  - 加密卡 / FPGA 直通

要求：
  - IOMMU 启用（intel_iommu=on / amd_iommu=on）
  - vfio-pci 驱动绑定
  - PCIe ACS 支持（避免 DMA 攻击）

# 启用 IOMMU（GRUB 启动参数）
intel_iommu=on iommu=pt

# 看 IOMMU group
ls /sys/kernel/iommu_groups/

# 绑定 vfio-pci
echo 10de 2330 > /sys/bus/pci/drivers/vfio-pci/new_id

# QEMU 命令行直通
qemu-system-x86_64 -device vfio-pci,host=01:00.0

vGPU：GPU 虚拟化

NVIDIA vGPU 让一颗 GPU 多 VM 共享：

graph TB  GPU[NVIDIA GPU
例如 A100]  GPU --> M1[MIG 实例 1]  GPU --> M2[MIG 实例 2]  GPU --> M3[MIG 实例 3]  GPU --> M7[MIG 实例 7]    M1 -.- V1[VM 1]  M2 -.- V2[VM 2]

NVIDIA vGPU 两种模式：

Time-slicing（vGPU 软件）：
  - 多 VM 时间片轮转用 GPU
  - 软件许可（需要 NVIDIA Grid 订阅）
  - 适合显卡虚拟化（VDI）

MIG（Multi-Instance GPU，A100/H100）：
  - 硬件分割
  - 每个 MIG 实例独立 SM、L2、显存
  - QoS 严格隔离
  - 适合 AI 推理 / 多租户

A100 / H100 MIG 配置：

A100 80GB 可分：
  7× 1g.10gb（最小）
  3× 2g.20gb
  2× 3g.40gb
  1× 7g.80gb（不分）

H100 80GB 类似 A100

# 启用 MIG
nvidia-smi -i 0 -mig 1

# 看 MIG 实例
nvidia-smi mig -lgi
nvidia-smi mig -lci

# 创建 MIG
nvidia-smi mig -cgi 9,9,9,9,9,9,9   # 7 个 1g.10gb
nvidia-smi mig -cci

# 删除
nvidia-smi mig -dci
nvidia-smi mig -dgi

容器 vs 虚拟机

graph TB  subgraph VM["虚拟机栈"]    direction TB    V1[App]    V2[Guest OS]    V3[Hypervisor]    V4[Host OS]    V5[硬件]    V1 --> V2 --> V3 --> V4 --> V5  end    subgraph CN["容器栈"]    direction TB    C1[App]    C2[容器运行时]    C3[Host OS]    C4[硬件]    C1 --> C2 --> C3 --> C4  end

维度	VM	容器
隔离	强（硬件级）	弱（namespace + cgroup）
启动	30s-1min	秒级
内存占用	GB 级 / VM	MB 级 / 容器
性能	<5% loss	<1% loss
安全	内核漏洞不易跨	内核共享，漏洞共担
用途	多租户 / 强隔离	微服务 / DevOps

容器后续单独一篇展开。

微虚拟化 / Firecracker / Kata Containers

容器的安全性弱——业界发明了”轻量虚拟化”：

Firecracker（AWS）：
  - 微 VM，启动 125 ms，内存 5 MB
  - AWS Lambda / Fargate 用
  - Rust 实现，攻击面小

Kata Containers：
  - "VM 包容器"
  - 看起来是容器，实际是 VM
  - 安全 + 兼容容器生态
  - QEMU / Cloud Hypervisor 后端

Cloud Hypervisor（Intel/AMD/Microsoft）：
  - Rust 实现的轻量 Hypervisor
  - 替代 QEMU 在某些场景

这些”微虚拟化”是 serverless / 多租户 K8s 的关键。

嵌套虚拟化

VM 里跑 VM：

启用嵌套：
  modprobe kvm_intel nested=1
  或 GRUB: kvm-intel.nested=1

应用：
  - 云上跑 K8s 节点 + VM 测试
  - CI 跑虚拟化测试
  - 套娃训练环境

性能：     损失 5-10% / 层

Live Migration（在线迁移）

VM 迁移到另一台物理机不停机：

原理：
  1. 标记内存脏页
  2. 在线复制内存到目标
  3. 反复迭代脏页
  4. 暂停 source，复制最后脏页 + 寄存器
  5. 启动 destination
  
  停机时间：     50-500 ms（看内存大小和带宽）

要求：
  - 网络共享存储或镜像迁移
  - 网络带宽足够（10G+）
  - CPU 能力相近（或开 host-passthrough 关）

1 2	`# KVM Live Migration virsh migrate --live vm1 qemu+ssh://target-host/system`

VM Live Migration 在云上是常态——升级宿主机时，把 VM 平滑迁走，租户感知微小。

虚拟化的几个老坑

坑 1：忘记开 VT-x / VT-d

# 看 CPU 是否支持
egrep "vmx|svm" /proc/cpuinfo

# 看 KVM 是否启用
ls /dev/kvm                    # 应该存在
lsmod | grep kvm

# IOMMU 状态
dmesg | grep -E "DMAR|IOMMU"

很多服务器 BIOS 默认不开 VT-d——必须 BIOS 启用。

坑 2：CPU “host” vs “host-model”

1
2
3

host-passthrough：  完全暴露物理 CPU 特性，性能最好但 Live Migration 受限
host-model：        暴露相近 CPU 模型，可迁移
custom：            指定通用模型（"qemu64"），性能损失但兼容性最好

云厂家一般用 host-model 折中。

坑 3：内存 ballooning 调过头

balloon 让 Hypervisor 在 VM 间动态调内存
但调过头：VM 突然 OOM
建议：
  - 业务 VM 关闭 balloon
  - 给定固定内存

坑 4：KSM 误用

KSM（Kernel Same-page Merging）：
  - 多 VM 共享相同内存页
  - 节省内存
  - 但增加 CPU 开销 + 侧信道风险

延迟敏感场景关：    echo 0 > /sys/kernel/mm/ksm/run

坑 5：Live Migration 失败

常见原因：
  1. CPU 模型不匹配 → host-model 不一致
  2. 网络配置不一致 → bridge 名不同
  3. 共享存储不可达 → 镜像不在 NFS / Ceph 上
  4. 安全策略阻断 → SELinux / AppArmor

虚拟化的国产化

华为 FusionCompute：    KVM 衍生 + 自家管理
深信服 aSV：           KVM 衍生
新华三 H3C CAS / UIS：   KVM 衍生 + OpenStack
浪潮 InCloud：          KVM 衍生
ZStack：               国产 OpenStack 替代
青云 QingCloud：       自研

VMware 替代浪潮：       Broadcom 收购后加速

待补充：国产虚拟化产品 2025-2026 在政企的实际部署比例。

虚拟化与云

graph TB  PUB[公有云
AWS/Azure/GCP/阿里/腾讯]  PUB --> NITRO[AWS Nitro
KVM 衍生 + DPU 卸载]  PUB --> AZURE_HV[Azure Hypervisor
Hyper-V 衍生]  PUB --> ALI[阿里神龙
KVM + DPU]    PRIV[私有云]  PRIV --> VMW[VMware vSphere
已被 Broadcom]  PRIV --> OS[OpenStack 系]  PRIV --> CN_OS[国产虚拟化]

公有云 Hypervisor 都是 “KVM 深度定制 + DPU 卸载” 的路线。

一些数字直觉

KVM VM 启动：              30s - 1min
Firecracker μVM 启动：     125 ms
Kata Container 启动：     ~1 sec

KVM CPU 性能损失：         <2%
KVM IO 性能损失（virtio）：5-15%
SR-IOV 网卡：             ~95% 性能
GPU 直通：                100% 性能
NVIDIA MIG：              资源严格隔离

VMware vSphere license：  $5K-15K / socket（Broadcom 后）
KVM + libvirt：           免费
华为 FusionCompute：      ¥几万 / 节点

小结

虚拟化分 Type 1（裸金属）和 Type 2（宿主机），数据中心只用 Type 1
KVM 是 Linux 内核虚拟化，QEMU 提供设备模拟
Xen 已边缘化，VMware 被 Broadcom 收购后涨价加速国产化
SR-IOV 让一个网卡变多 VF，VFIO 让设备直通到 VM
NVIDIA MIG 是 A100/H100 硬件级 GPU 虚拟化
Firecracker / Kata 是”轻量虚拟化”，serverless 主流
Live Migration 是云的核心能力

下一篇讲容器与 K8s——比 VM 更轻、规模更大的”OS 层抽象”。

Linux 服务器 OS 演进 —— 从 RHEL 到现代发行版

2026-01-11T13:10:00.000Z

第七章讲操作系统。Linux 是服务器市场绝对主流——但”哪个发行版”、”用什么内核”、”哪种包管理器”这些选择会决定运维成本。本文按家族梳理。

一张全景

graph TB  K[Linux Kernel
内核 / kernel.org]  K --> RH[RHEL 系
RPM]  K --> DB[Debian 系
DEB]  K --> SU[SUSE 系
RPM]  K --> SP[特殊
NixOS / Gentoo / Arch]    RH --> RHEL[RHEL]  RH --> CENTOS[CentOS
已转 Stream]  RH --> ROCKY[Rocky Linux]  RH --> ALMA[AlmaLinux]  RH --> FEDORA[Fedora]  RH --> ORACLE[Oracle Linux]    DB --> DEBIAN[Debian]  DB --> UBUNTU[Ubuntu Server]  DB --> KALI[Kali]    SU --> SLES[SLES]  SU --> OPENSUSE[openSUSE Leap/Tumbleweed]    RH -.- CN[国产基于 RPM]  DB -.- CN  CN --> EULER[openEuler]  CN --> KYLIN[麒麟]  CN --> ANOLIS[龙蜥 OpenAnolis]  CN --> UOS[统信 UOS]

三大主流家族

Red Hat 系（RPM）

RHEL（Red Hat Enterprise Linux）：     付费，企业级
CentOS：                               原 RHEL 重编译，2021 年转 Stream（即"上游版"）
Rocky Linux：                          CentOS 关闭后社区接力，RHEL 兼容
AlmaLinux：                            另一支社区 RHEL 兼容
Oracle Linux：                          Oracle 维护的 RHEL 兼容
Fedora                               Red Hat 上游，新特性试验

CentOS Stream 风波（2020） 是 Linux 服务器界的大事件：

2020 年 12 月：Red Hat 宣布 CentOS 8 提前 EOL
              CentOS 8 → CentOS Stream（变为 RHEL 上游）
影响：        几亿 CentOS 用户必须迁移
受益：        Rocky Linux、AlmaLinux 一夜走红
              国产 OS 路线（欧拉、龙蜥）加速

Debian 系（DEB）

1
2
3

Debian：       社区维护，稳定保守
Ubuntu：       Canonical 商业发行，每 2 年 LTS（4-6 月发版）
              22.04 LTS / 24.04 LTS / 26.04 LTS（即将）

Ubuntu LTS 是云市场最广泛——AWS / GCP / Azure 上 Ubuntu 占比都很高。

SUSE 系（RPM）

1
2
3

SLES（SUSE Linux Enterprise Server）：付费企业级
openSUSE Leap：                       社区版
openSUSE Tumbleweed：                 滚动更新

SUSE 在欧洲企业、SAP 系统上份额高。中国市场较少。

RHEL 的版本节奏

RHEL 6（2010-2020）：    服务器经典
RHEL 7（2014-2024）：    引入 systemd，是变化最大的一代
RHEL 8（2019-2029）：    UBI 容器、模块化 AppStream
RHEL 9（2022-2032）：    OpenSSL 3、cgroup v2 默认
RHEL 10（2025-2035）：   预计、ARM 架构第一公民

每代主要支持 10 年（5 年 full + 5 年 extended）

RHEL 8/9 是当前服务器市场的主流——大多数企业上 RHEL 8 或 RHEL 9。

Ubuntu Server 的版本节奏

Ubuntu 18.04 LTS（2018-2028）：旧但还在用
Ubuntu 20.04 LTS（2020-2030）：当前主力之一
Ubuntu 22.04 LTS（2022-2032）：当前主力
Ubuntu 24.04 LTS（2024-2034）：最新 LTS
Ubuntu 26.04 LTS（2026-2036）：将在 2026 年 4 月发布

非 LTS 半年一发，9 月支持

LTS 是数据中心标配——10 年支持是企业刚需。

systemd：Linux 服务器的”分水岭”

2014 年 RHEL 7 / Debian 8 / Ubuntu 14.04 都默认换成 systemd——这是 Linux 历史上最有争议的变化：

graph TB  OLD[传统 SysVinit + Upstart]  OLD --> S1[/etc/init.d/ + 串行启动]    NEW[systemd]  NEW --> N1[unit 文件 + 并行启动]  NEW --> N2[整合：网络/日志/挂载/cron]  NEW --> N3[依赖关系图]  NEW --> N4[journald 二进制日志]

systemd 集中管理：

原来分散的功能被 systemd 接管：
  init → systemd
  cron → systemd-timer
  syslog → journald
  network → networkd（可选）
  resolv.conf → resolved
  mount → mount unit
  inetd → socket activation
  
争议：
  - "Unix 哲学"违反（一个工具只做一件事）
  - 复杂度大
  - 大型软件吸引大型 bug

systemd 的实战命令

# 服务管理
systemctl start/stop/restart nginx
systemctl enable/disable nginx
systemctl status nginx

# 看日志
journalctl -u nginx
journalctl -f          # 跟踪模式
journalctl --since "1 hour ago"
journalctl -p err      # 仅错误

# 单元配置
systemctl cat nginx.service
systemctl edit nginx.service      # 临时覆盖
systemctl daemon-reload

# 启动分析
systemd-analyze
systemd-analyze blame             # 看启动慢的服务
systemd-analyze critical-chain    # 关键启动链

# 资源限制
systemctl set-property nginx MemoryLimit=2G
systemctl set-property nginx CPUQuota=200%

systemd 的资源限制其实就是 cgroup——它在自动管理 cgroup。

包管理器对比

graph TB  RPM[RPM 系]  RPM --> YUM[yum
RHEL 7]  RPM --> DNF[dnf
RHEL 8+]  RPM --> ZYPPER[zypper
SUSE]    DEB[DEB 系]  DEB --> APT[apt
Debian/Ubuntu]    OTHER[其他]  OTHER --> PACMAN[pacman
Arch]  OTHER --> NIX[nix
NixOS]  OTHER --> SNAP[snap / flatpak
跨发行版]

包管理器	命令例	配置文件
dnf / yum	`dnf install nginx`	`/etc/yum.repos.d/`
apt	`apt install nginx`	`/etc/apt/sources.list`
zypper	`zypper install nginx`	`/etc/zypp/repos.d/`
pacman	`pacman -S nginx`	`/etc/pacman.conf`

内核版本与发行版

LTS 内核版本（kernel.org）：
  4.19（2018）：   仍在维护
  5.4（2019）：    EOL 2025
  5.10（2020）：   EOL 2026
  5.15（2021）：   EOL 2026
  6.1（2022）：    EOL 2026
  6.6（2023）：    EOL 2026
  6.12（2024）：   EOL 2027

每个发行版选一个 LTS 内核长期维护：
  RHEL 9：       基于 5.14
  Ubuntu 22.04：5.15
  Ubuntu 24.04：6.8
  Debian 12：    6.1
  SLES 15 SP6：  6.4

数据中心服务器多年不会换内核——选好 LTS 后稳定运行 5-10 年。

内核新特性的”上游 → 发行版”路径

2017：BPF 抓包 / XDP 高速包处理（5.x）
2018：cgroup v2（4.20，2019 默认 RHEL 8）
2019：io_uring 异步 IO（5.1）
2020：BPF CO-RE，eBPF 程序通用
2021：folios（VM 子系统重构）
2022：BPF for tracing 大量工具（bpftrace）
2023：folio 完成 + multi-gen LRU
2024：sched_ext（可插拔调度器）
2025：NUMA / memory tiering 改进 / CXL

这些特性按发行版”渐进引入”——RHEL 9 才开始默认 cgroup v2，是 2019 上游引入后 3 年。

io_uring：异步 IO 革命

io_uring（5.1+，2019）是 Linux 几年最重要的 IO 子系统升级：

传统 IO：     read() / write() / epoll
   每次系统调用过 kernel 切换上下文
   高并发吃 CPU

io_uring：   提交队列 + 完成队列
   多个请求批量提交，批量完成
   内核轮询模式可零系统调用
   性能 5-10× 传统
   
应用：
  - PostgreSQL（17+）
  - MySQL
  - Redis（部分）
  - QEMU
  - rusoto / Tokio

io_uring 是数据库 / 存储 / 高并发服务的”未来 IO”。

eBPF：内核可编程

eBPF（extended BPF）是 2014+ Linux 内核最深刻的扩展：

graph TB  USER[用户程序
C / Rust / Go]  USER --> BPF[BPF Verifier
安全检查]  BPF --> JIT[JIT 编译]  JIT --> KERNEL[内核中执行
挂钩点]  KERNEL --> H1[网络包处理]  KERNEL --> H2[系统调用追踪]  KERNEL --> H3[安全策略]  KERNEL --> H4[性能分析]

应用：

Cilium：       BPF-based K8s CNI
bpftrace：    动态 tracing 工具
Falco：        BPF 安全审计
Pixie：        BPF 可观测平台
Katran：       BPF 负载均衡（Facebook）
Calico：       BPF 数据面

BPF 让数据中心运维 / 排障 / 安全能力大幅提升——比传统 ftrace / strace 快 10-100 倍。

服务器 OS 的几个”老坑”

坑 1：选错 EL 版本

RHEL 7：     2024 年 6 月 EOL
RHEL 8：     2029 年 EOL
RHEL 9：     2032 年 EOL

新部署上 RHEL 7 就是 1 年内 EOL ——非常糟
新部署应该 RHEL 9 / Ubuntu 24.04 起步

坑 2：CentOS 8 仍在跑

CentOS 8 已 EOL（2021 年）
但很多企业仍在用——补丁 / 安全洞危险
迁移路径：
  CentOS 8 → Rocky Linux 8 / AlmaLinux 8（最容易）
  CentOS 8 → RHEL 8（付费）
  CentOS 8 → openEuler / 龙蜥（国产）

坑 3：systemd 资源限制忘记设

默认 systemd 单元没有资源限制
进程内存泄漏 → 把整机吃光 → OOM 全杀

补救：
  systemctl set-property myapp MemoryLimit=4G
  写入 .service 文件中持久化

坑 4：journald 日志爆盘

journald 默认无限保留 → 磁盘满
配置 /etc/systemd/journald.conf:
  SystemMaxUse=2G
  RuntimeMaxUse=1G
  MaxRetentionSec=1month

坑 5：NetworkManager 与 networkd 冲突

1
2
3

RHEL 默认 NetworkManager
Ubuntu Server 默认 networkd
两个都开：互相覆盖配置 → 网络抖动

坑 6：firewalld vs nftables

RHEL 8+ 默认 firewalld（nftables 后端）
直接 iptables 命令在 RHEL 8+ 上是模拟层
建议：    
  - 用 firewalld 命令（系统层）
  - 或直接 nftables（更现代）
  - 不要混用

坑 7：内核升级踩坑

RHEL minor 升级（9.2 → 9.3）：通常 OK
RHEL major 升级（9 → 10）：     重新装更安全
内核单独升级（不是发行版）：
  - 5.14 → 6.x：驱动可能缺
  - GPU / 存储驱动必须验证
  - 第三方模块（kABI）不一定兼容

服务器 OS 的几个”硬核”特性

Live Patching（在线打补丁）

kpatch（RHEL）/ livepatch（Ubuntu）：
  - 内核安全补丁不重启即生效
  - 主要打 CVE 漏洞
  - 临时方案，下次重启永久打

kdump（内核崩溃转储）

内核崩溃时把内存 dump 到文件：
  - 第二个 kernel 接管
  - dump 到 /var/crash/
  - 用 crash 工具分析

配置：     /etc/kdump.conf
启用：     systemctl enable --now kdump

tuned（性能调优）

tuned-adm list           # 看可用 profile
tuned-adm profile latency-performance     # 低延迟
tuned-adm profile throughput-performance  # 高吞吐
tuned-adm profile virtual-host            # 虚拟化宿主

每个 profile 自动调 CPU 调度、内核参数、IRQ。

服务器 OS 选型实战

graph TD  Q1{业务场景?}  Q1 -- "传统企业 + 商业支持" --> S1[RHEL 9 + 订阅]  Q1 -- "云原生 / K8s" --> S2[Ubuntu 22.04/24.04 LTS]  Q1 -- "自管 + 免费" --> S3[Rocky Linux 9 / AlmaLinux 9]  Q1 -- "SAP / 欧洲企业" --> S4[SLES 15]  Q1 -- "国产化要求" --> S5[openEuler / 麒麟 / 龙蜥]  Q1 -- "AI 训练集群" --> S6[Ubuntu 22.04 + 内核 5.15+]

一些查询命令

# 看发行版
cat /etc/os-release
hostnamectl

# 看内核
uname -r
uname -a

# 看包管理器
dnf list installed
apt list --installed

# 看 systemd 单元
systemctl list-units --type=service
systemctl list-timers

# 内核参数
sysctl -a | grep 
cat /proc/cmdline                  # 启动参数

# 看启动时间
systemd-analyze
systemd-analyze blame | head -10

一些数字直觉

RHEL 9 全新安装：    ~1.5 GB 磁盘 / 系统启动 < 30 秒
Ubuntu 22.04 LTS：   ~1.2 GB
最小 Alpine Linux：  ~5 MB（容器用）

RHEL 订阅：         $349/年 起（标准）
SLES 订阅：         $1499/年 起（标准）
openEuler：         免费 + 商业服务（华为）
龙蜥：              免费 + 商业服务（阿里、统信等）

第七章 Roadmap

接下来会展开：

虚拟化（KVM / Xen / Hyper-V）
容器化（Docker / containerd / K8s）
内核内部（调度 / 网络栈 / FS）
AI 时代 OS 适配（vGPU / NPU 调度）
国产服务器 OS（欧拉 / 麒麟 / 龙蜥 / 统信）

小结

Linux 是服务器市场绝对主流，三大家族 RHEL / Debian / SUSE
CentOS 8 风波改变格局，Rocky / AlmaLinux 接力
systemd 是 2014 后服务器 OS 的”分水岭”
io_uring + eBPF 是近年内核最重要的两个新特性
RHEL 订阅 vs 免费衍生 vs 国产 OS 是当前选型核心问题

下一篇讲虚拟化——KVM、Xen、Hyper-V，以及 SR-IOV / vGPU。