2、碎片度量指标：碎片率定义、最大连续块、碎片化指数、监控工具介绍
聊完了碎片是怎么产生的，咱们得先解决一个根本问题——怎么量化它。
你想想看，如果连碎片化程度都说不清楚，那优化就变成了「盲人摸象」。我个人习惯是，先定义清楚指标，再谈治理。这一节，我就把几个核心的度量指标掰开揉碎讲给你听。
2.1 碎片率（Fragmentation Ratio）
碎片率是最直观的指标。说白了，就是「用不了的碎片大小总和」除以「总空闲大小」。
公式很简单：
碎片率 = 1 - (最大连续空闲块大小 / 总空闲大小)举个例子：
- 总空闲 100 MB
- 最大连续块只有 30 MB
- 碎片率 = 1 - (30 / 100) = 0.7（70%）
重要判断：碎片率 > 0.5 时，基本可以判定显存碎片已经比较严重了。这时候大块分配请求很容易失败。
我在项目中遇到过这样的情况：碎片率显示 0.6，但应用还能跑。为什么？因为分配的都是小内存。所以碎片率要结合分配模式一起看，不能孤立使用。
2.2 最大连续块（Max Contiguous Block）
这个指标更直接——显存里最大的一块连续空闲区域有多大。
我个人习惯把它当作「红线指标」。为什么？因为很多大模型推理场景，比如加载一个 4GB 的权重张量，如果最大连续块小于 4GB，那分配必然失败。
监控这个指标时，我建议关注两点：
- 绝对值：是否小于当前最大分配请求
- 变化趋势：是否在持续下降（说明碎片在恶化）
小技巧：我习惯在代码里加一个定时采样，每 5 秒记录一次最大连续块。如果连续 3 次采样都低于阈值，就触发告警。
2.3 碎片化指数（Fragmentation Index）
这个指标比碎片率更精细。它考虑了空闲块的分布情况。
公式长这样：
碎片化指数 = 1 - (Σ(空闲块大小²) / (总空闲大小²))嗯，这里要注意：
- 指数接近 0：空闲块分布均匀，碎片少
- 指数接近 1：空闲块又小又碎，碎片严重
我曾经在一个推理服务里发现，碎片率只有 0.3，但碎片化指数高达 0.85。一查才发现，空闲块全是 1MB 以下的小碎片。这就是碎片率「骗人」的典型案例。
避坑指南：我曾经只盯着碎片率看，结果线上出了 OOM 事故。后来才明白，碎片化指数才是「照妖镜」。建议两个指标一起看，互相印证。
2.4 监控工具介绍
指标定义清楚了，怎么拿到这些数据？我常用的工具有这几个：
| 工具 | 适用场景 | 能拿到的指标 |
|---|---|---|
| nvidia-smi | 快速查看 | 总显存、已用、空闲 |
| Nsight Systems | 深度分析 | 分配/释放事件、碎片率 |
| CUDA Memory Checker | 调试阶段 | 最大连续块、碎片化指数 |
| 自定义 Hook 工具 | 生产环境 | 所有指标 + 自定义告警 |
我个人最推荐的是自定义 Hook 工具。为什么？因为 nvidia-smi 只能看到「总空闲」，看不到「最大连续块」。而生产环境里，你恰恰需要这个数据。
下面是一个简单的采样脚本思路：
// 伪代码：定期采样显存状态
while (true) {
auto stats = cudaMemGetInfo();
auto maxBlock = getMaxContiguousBlock(); // 需要 Hook 分配器
auto fragIndex = computeFragIndex(freeBlocks);
log("碎片率: %.2f, 最大连续块: %d MB, 碎片化指数: %.2f",
fragRatio, maxBlock / MB, fragIndex);
if (maxBlock < threshold) {
alert("警告：最大连续块低于阈值！");
}
sleep(5);
}
我的经验：监控工具不要只部署在测试环境。我建议生产环境也跑一份，但采样频率调低（比如 30 秒一次），避免影响性能。
2.5 知识体系总览
为了让你更直观地理解这几个指标的关系，我画了一张图：
你看，这三个指标各有侧重：碎片率看整体、最大连续块看极限、碎片化指数看分布。我个人习惯是三个指标一起看，就像医生看病不能只看体温一样。
好了，这一节的内容就到这里。记住一句话：没有度量，就没有优化。先把这些指标部署好，你才能知道碎片到底有多严重，下一步该怎么治。
核心总结：
- 碎片率 > 0.5 时需警惕
- 最大连续块是红线指标，低于最大分配请求时必出问题
- 碎片化指数能发现碎片率「骗人」的情况
- 生产环境建议用自定义 Hook 工具做实时监控
想要更多资料，联系可可