4.1 生产级推理监控看板：概览层、服务层、实例层的递进下钻

4.1 生产级推理监控看板：概览层、服务层、实例层的递进下钻

我见过最夸张的反例：一个团队的 Grafana 看板有 47 个 dashboard，其中一个"总览"看板堆了 30 多个图卡，密密麻麻像炒股软件。值班时根本抓不住重点——故障发生时，要在 30 个图卡里找出哪个异常，眼睛都看花了。后来我们重构成三层递进结构，值班从"全局异常"到"哪个节点的什么指标爆了"，30 秒内能完成下钻，MTTR（平均恢复时间）直接降了一半。

这一节给一套能直接落地的推理监控看板组织法。核心思想是分层——不能把所有图卡堆在一个面板，要按"概览→服务→实例"三层递进，让值班工程师能快速从宏观异常下钻到微观根因。

看板为什么要三层递进

生产级监控看板必须分层，这是由"值班排障"这个核心场景决定的。故障发生时，值班工程师的思维过程是：先看到"系统有问题"（宏观），再定位"是哪个服务"（中观），最后查"是哪台机器的什么资源"（微观）。看板的层级结构必须匹配这个思维过程，否则就要在不同看板间反复跳转，浪费时间。

三层结构正好对应这个过程。概览层面向全队，回答"现在用户爽不爽、系统稳不稳"，只放最关键的黄金信号。服务层面向服务 owner，回答"哪个推理服务出了问题"，按服务维度组织。实例层面向 SRE 和运维，回答"哪台机器的什么资源爆了"，到单机粒度。层与层之间有清晰的下钻路径——概览看到某个服务异常，点击就能进入该服务的服务层看板；服务层定位到某个实例异常，再点击进入实例层。

概览层首屏：必须常驻的黄金图卡

概览层只放最关键的黄金信号，要求值班时一眼就能判断系统健康度。我建议首屏不超过 6 到 8 个图卡，多了反而抓不住重点。

首屏必须常驻的图卡有几个。TTFT 分布（P50/P95/P99）是体验第一指标，必须用 histogram 而非平均值——平均值会掩盖尾部问题，P99 才是体验真相。TPOT（每 token 延迟）反映流式顺滑度。请求错误率要按 5xx/429/503 分类统计，因为这三类性质不同（5xx 是真故障，429/503 是主动保护），混在一起会误判。吞吐（tokens/s + QPS）反映当前负载水位。最后，错误预算消耗速率是 SLO 健康度的单一信号——把复杂的多维 SLO 凝聚成一个红黄绿的状态，值班一眼就知道"今天 SLO 守得住不"。

首屏设计的反模式是"堆图卡"。我见过有团队把所有能想到的指标都放首屏，结果首屏像一锅大杂烩，值班时根本分不清主次。首屏的原则是"少而精"——宁可少放，让值班能 5 秒内扫完判断健康度，也不要多放导致信息过载。不常看的指标放到服务层或实例层，需要时再下钻。

服务层：按推理服务下钻

服务层按"推理服务"维度组织，每个服务一组图卡。比如一个平台可能有 vLLM-GLM5（旗舰模型服务）、vLLM-DeepSeek（另一个模型）、TGI-Small（小模型分流服务），每个服务都有自己的服务层看板。

服务层要看的内容包括：该服务的 TTFT/TPOT/错误率（与概览层同指标，但限定到该服务，便于对比哪个服务出了问题）；KV Cache 占用率（vLLM 的 gpu_cache_usage_perc 指标），这是显存压力的直接信号，接近 100% 说明快 OOM 或已触发抢占；批处理队列长度（num_requests_waiting），排队堆积是延迟飙升的前兆，这个指标突然上升通常意味着请求速度超过了处理速度；GPU 利用率，反映算力是否打满。

服务层的价值在于"对比和定位"。当概览层显示 TTFT 异常时，到服务层对比各个服务的 TTFT，立刻能看出是哪个服务拖了后腿。这种"先全局再细分"的定位思路，比在单个看板里翻找高效得多。

实例层：定位到具体节点

实例层到单机粒度，用于故障的最终定位。当服务层发现某个服务异常时，到实例层看是该服务的哪台机器出了问题。

实例层要看的内容包括：单 GPU 的显存和算力时间序列，看哪台机器的哪张卡在抖动（比如某张卡的利用率异常飙高或掉零，可能是硬件故障）；显存碎片和抢占次数，反映 PagedAttention 的内部健康度（碎片严重或频繁抢占会拖慢推理）；容器和进程资源（CPU、网络、磁盘 IO），排查 exporter 自己吃资源的情况——就像 3.1 节那个案例，exporter 吃掉 15% CPU，在实例层的 CPU 图卡上能看出来。

实例层还要能"一键跳转日志"。看到某台机器在某个时间点异常，要能直接跳转到那台机器在那个时间段的日志，继续排查。监控和日志的关联，是快速定位根因的关键——只有监控没有日志，你只能看到"出了问题"，看不到"为什么出问题"。

看板设计的三个反模式

首屏堆 30 个图卡是第一个反模式，信息过载，值班抓不住重点。只有平均值没有分位数是第二个，P99 才是体验真相，平均会掩盖尾部问题——比如平均 TTFT 800ms 看起来还行，但 P99 可能已经 5 秒了，10 个用户里有 1 个体验崩塌，平均完全反映不出来。没有下钻路径是第三个，概览看到异常却点不进服务层或实例层，只能干瞪眼，然后去 Grafana 里手动翻找，浪费宝贵的故障响应时间。

这三个反模式的共同点是"只考虑了展示，没考虑使用场景"。看板是给人用的工具，要围绕"值班排障"这个核心场景设计，而不是把所有数据都堆出来好看。

这一节的关键交付

看板分三层：概览（用户视角，黄金信号）、服务（owner视角，按服务对比）、实例（SRE视角，单机定位）。首屏只放 6 到 8 个黄金信号图卡，少而精。关键图卡包括 TTFT 分布、KV Cache 占用率、批处理队列、错误率分类。三层之间要有清晰的下钻路径，并能关联日志。

下一节 4.2 讲如何把"告警"从噪音变成 actionable——再好的看板，如果告警半夜响了没人知道该干什么，也等于零。