推理集群可观测性：64 卡监控体系与缓存证据链

推理集群可观测性：64 卡监控体系与缓存证据链

Deng YongJie's blog 2 2026-09-28

推理集群可观测性：64 卡监控体系与缓存证据链

大模型推理基础设施实战系列 · 第 6 篇

1. 背景与问题：推理集群的观测，难在"语义"而不是"接入"

接入 GPU 指标只是第一步。难的是回答这些问题：

  • 报告"SM active 均值 26%"——这是 GPM 的 SM_ACTIVE 还是 nvidia-smi dmon 的 sm 列？两者语义不同，不能直接比；
  • 看板显示"Store 命中 92%"——这是元数据查询命中、预取传输完成，还是最终 prefill 真的复用了？
  • 中心存储里某卡窗口只有 3 个点——是采集失败、无业务，还是采样稀疏？

2. 案例规模：四类部署，不是可直接相加的现行资产

先交代被观测对象的体量。以下是系列在不同时期涉及的四类规模。节点可能复用，缺少同一时点资产去重清单，不能相加声称当前共有 408 卡，也不能认为全部具备本篇相同的采样覆盖：

GPU 集群规模一览

  • 文本 PD 分离池：128 卡（16 台 ×8），承载第 2 篇的 8 种 P:D 组合压测矩阵，逐卡功耗/SM/DRAM 同窗采集；
  • 长上下文副本组：64 卡（8 台 ×8，双副本 TP8×PP4），512K 窗口，该次核验有 45 个监控目标——本篇的截图就来自这个池；
  • 双 H20 长上下文节点：16 卡（2 台 ×8），第 4 篇的历史 TP8×PP2、512K 限时部署，后续已换型；
  • 视频生成池：规划/配置范围为 200 卡（25 台 ×8）；第 7 篇验证单机单元与双实例样例，没有 25 路同窗产能验收。

观测体系要同时覆盖"一个请求横跨 32 卡"（TP8×PP4）和"一机一实例"（视频池）两种拓扑，这是后续所有设计的前提。

3. 采集架构：有界采集器 + 节点原件 + 中心存储

采集链路

每个 GPU 节点一个 vmagent（systemd 托管），抓取本机各类指标源：

指标源 采集内容
SGLang 引擎 请求、队列、缓存、KV 层级
DCGM GPU 常规指标
node-exporter CPU / 内存 / 磁盘 / 网络
自研 GPM 采样器 逐卡 1 秒 SM / DRAM / 功耗 / 显存等
Mooncake master（部分节点） Store 容量与来源
官方 Gateway（部分节点） 入口队列与后端

合计 45 目标、覆盖 8 节点 64 卡。

三个设计决定：

① 采集器自身有界。 CPU 50%、512 MiB、swap 0、tasks 64、发送队列 ≤1 GB、Restart=no——采集器绝不能成为影响被测系统的变量。二进制与依赖库 SHA 冻结，随每次发布核验。

② 自研 GPM 采样器补 DCGM 的缺口。 我们需要 1 秒级、逐卡、带有效码的原始样本：SM active/occupancy、Tensor、DRAM、busy、显存、功耗、温度、时钟与降频原因。

GPM 用固定版本 pynvml（SHA 冻结），/metrics 仅回环可读；/samples 提供最近 7,200 帧（约 2 小时）的内存环形原件，仅回环与授权源 IP 可读，不含任何 Key、提示词或会话内容。它以同一 systemd 单位内的监督进程运行，不新增常驻单位。

③ 正式压测绕开中心存储。 中心 VictoriaMetrics 的历史查询实测存在约 30 秒的重复/稀疏样本，还有延迟偏移机制；压测客户端改为按每组实际窗口，从 8 台节点的 GPM 环形原件即时取回，核对 UUID、有效码、周期、时钟和缺口后合并。看板截图不能代替采样——看板表格用 avg_over_time/max_over_time，受绘图步长影响，可能漏掉短时尖峰。

4. 看板设计：先看证据对照，再看逐卡，再看时间线

推荐阅读顺序：

  1. 缓存证据对照（3 张节点表）：窗口终点各层占用 → 同窗最终复用与物理读写 → 缺失原因。选 All 时三张表应各有 8 行；不能跨 PP 相加为整机群命中量（同一请求在 4 个 PP 阶段各计一次）；
  2. 逐卡窗口统计（2 张表）：每卡的功耗/显存/SM/DRAM/busy 时间均值与峰值，64 卡分页，可排序——用于找热点卡与离群卡；
  3. 请求等待与吞吐：token/s、TPM、TTFT/E2E、官方 Gateway 队列（smg_admission_inflight/queue_depth，按 entry/backend 区分，同一请求经过多个层级，不能相加）；
  4. KV cache 与 NVMe 缓存盘：每卡 KV 池、每 PP 逻辑槽、Store 节点组容量、缓存盘读写带宽/IOPS/耗时/队列。

两个反"误导"设计：比例类面板固定 0–100% 纵轴，避免空闲期自动缩放把噪声放大成"剧烈波动"；No Data 按原因区分——无业务、无 I/O、样本不足、未初始化、采集失败是五种不同状态，不补零、不互相冒充。

下面是逐卡窗口统计面板的实景（64 卡分页显示，每张卡的功耗/显存/SM/DRAM/busy 均值与峰值同卡同行；主机名与 UUID 已马赛克脱敏，下同）：

逐卡功耗与显存统计面板（脱敏截图）

以下四图由已有矩阵 CSV 与 PD 扫描表重绘，使用真实并发坐标；它们不是看板截图，也不是同一部署窗口：

矩阵与并发扫描图（依据来源表重绘）

  • 左上：GLM 系全组合矩阵，12P4D/128 卡取得 708 万总 TPM 的最高观察点；
  • 右上：DS 系 96 卡扫描，三种配比的 TPM-并发曲线——5:1 从 C16 到 C32 总 TPM 仅增约 0.41%，延迟上升；未测更大并发；
  • 左下：8P4D 从 C32 到 C64，旧窗口总 TPM 不变、TTFT p99 约翻倍；
  • 右下：与左上相同 80K 行的板卡平均功耗合计；各列卡数、C、N 不同，不是同资源能效对照。

再看长上下文副本组本池的真实流量窗口（同一看板的历史截图，已脱敏）。请求等待与吞吐组：峰值 28,124 token/s、总 TPM 峰值约 169 万（已含每分钟单位），TTFT p95、生成间隔、官方 Gateway 活动/排队、各 PP 运行/等待请求同窗对照：

请求等待与吞吐面板实景（脱敏截图）

逐卡时间线组：显存占用贴近上限，GPU busy 尖峰 60–80%，SM occupancy、tensor active、温度、SM 时钟逐卡分色——找热点卡就看这一屏：

逐卡 GPU 时间线面板实景（脱敏截图）

5. 缓存证据链：每一层只说它能证明的话

第 1、3 篇反复用到"命中"，这套看板把"命中"拆成五层证据，每层的能力边界直接写在面板上：

缓存证据分层

配套的方向语义（全部来自真实踩坑）：

  • hicache_backup_bytes_total 是 GPU→Host 的字节；Host→Store 看 backuped_tokens_total，Store→Host 看 prefetched_tokens_total——预取成功不等于最终复用（之后可能被丢弃）；
  • hicache_dropped_tokens_total 是 GPU 缓存未备份到 Host 即被丢弃，不是"Host 驱逐"——方向搞反会错误归罪 Host 层容量；
  • segment 按实际 IP 映射回节点；master 导出端的 node 标签是"导出端"，不是数据所在节点；
  • RAM/SSD 来源占比 = RAM 或 SSD 返回次数 ÷ 两者之和，不含 miss，不是请求命中率；当前对象副本数允许同 key 重复，不能相加为唯一对象数。

有一类需求我们明确拒绝"创造条件也要上"：想看"Store 内存逐节点独立命中"。master 的命中计数没有存储节点标签，引擎最终复用只区分 GPU/Host/Store——拆不出来就标 N/A，不按容量比例伪造拆分。同理，官方客户端源码里有 SSD 埋点（SsdMetric），但当前部署组合未开启其 HTTP 导出——标"客户端未导出"，不为补图增加空采集目标，更不改模型进程。

Store 容量与来源面板实景（上排：节点组总量 256 GiB 的分配/容量、各节点 Store RAM、各 rank segment；下排：GPU→Host 备份、Host→Store 传输、RAM/SSD 元数据来源返回次数）：

Store 层级与来源面板（脱敏截图）

缓存 NVMe 面板实景（真实流量窗口）：繁忙度尖峰约 1.25%、平均队列与当前 I/O、容量 / 已用 / 可用（每盘标称 3.84 TB、文件系统容量约 3.44 TiB；图中坐标上界不是容量或已用量）逐节点分色；下排为逐节点 CPU、主机 RAM 与模型盘余量。

同组另有预取未满足原因计数（anchor_lost、aux_window_trim、below_threshold、cache_admission_shortfall 四类分开计——延后不等于最终 miss）：

NVMe 缓存盘与逐节点健康面板（脱敏截图）

6. 一个容量数字的解剖：Store 为什么显示 256 GiB

看板上 global_segment_size=274,877,906,944（256 GiB）经常被问。正确读法：这是每副本的 Store RAM 总配额——适配器先除以 TP×PP=32，得每 rank 8 GiB → 每节点（8 ranks）64 GiB → 每副本（4 节点）256 GiB → 两副本 512 GiB。它不是每节点 256 GiB，更不是 master 进程占用 256 GiB。

同类算式还有：Host 缓存 32 GiB/rank → 256 GiB/节点 → 1 TiB/副本；NVMe 桶限额 240 GB/rank（物理 250 GB）→ 1.92 TB/节点。限额、逻辑分配、文件系统实际用量是三个数，面板分开展示。

7. 看板即代码：发布流程

看板 JSON 由生成器产出，发布走完整闭环：导出线上最新版 → 生成器重建 → 核对原有面板/变量查询不变 → 验证新查询 → 发布并回读校验 SHA → 记录版本号与清理清单。

8. 效果与总结

能力 现状 边界
采集覆盖 45 目标 / 64 卡 / 1 秒 GPM 逐卡采样 采集器有界运行；不修改被测系统驱动/时钟/功耗
看板 历史截图 137 面板 / 19 组；10-20 记录为 142 / 19 看板用于定位；正式数字只出自节点原件
缓存证据 五层证据 + 方向语义 + N/A 纪律 拆不出的维度标 N/A，不伪造拆分

四条经验：

  1. 先统一指标语义，再谈监控覆盖——SM active、GPU busy、MFU、DRAM%、GB/s 是五种量，混用比缺测更危险；
  2. 采集器必须有界且自身可观测——它是实验装置的一部分，不能成为变量；
  3. 中心存储做长期趋势，节点原件做正式测量——两者的局限分别写明，截图不作数；
  4. N/A 是一等公民——"没有数据"和"数据为 0"是两种事实，看板必须能区分五种 No Data 原因。

下一篇离开文本模型，看扩散视频模型的服务化：视频生成服务化：ComfyUI 多 GPU 编排与长任务生命周期。

系列目录

  1. KV Cache 与前缀缓存：从原理到 99.9% 命中率的生产实践
  2. PD 分离实战：Prefill/Decode 拆池、配比拐点与容量规划
  3. GPU→内存→SSD 三级 KV 缓存：Mooncake 分层实战与跨引擎复用陷阱
  4. Kimi-K3 原始 MXFP4 权重512K 长上下文生产部署：双机 16 卡 TP8×PP2 与 CUDA Graph 调优
  5. 大模型压测方法论：如何让性能数据可信
  6. 推理集群可观测性：64 卡监控体系与缓存证据链（本篇）
  7. MiniMax-H3视频生成服务化：ComfyUI 多 GPU 编排与长任务生命周期
  8. 掉卡排查实录：RTX 5070 反复 Xid 79，如何排查建立证据链
  9. GPU对调定位法：8 卡 RTX 6000D 掉卡，如何用对调缩小故障范围
  10. CUDA 802 不是 NCCL 网络故障：H20 NVSwitch 物理链路排查实录
  11. DeepSeek-V4.1-Flash 双机 16 卡 H20 部署压测：TP8×DP2 与跨机 EP 的边界

数据声明：本文数量按对应日期的记录保留，地址标识做脱敏。45 目标和 1 秒 GPM 覆盖仅针对本篇 64 卡案例；其他部署使用的采集器与周期须分别核对。

AI vLLM SGlang