可观测性平台：GPU推理专用监控大盘

可视化演示

三步展示GPU推理专用监控大盘：利用率/显存/温度/功耗GPU特有指标、采集→存储→展示→告警监控流程、以及实时监控与历史分析的时间维度对比。

大盘设计概览：餐厅的中控台

想象你给餐厅装中控台：一排屏幕显示订单量，一排摄像头盯着后厨，另一排显示冰箱库存。有了这些，你就能随时回答“现在生意怎样”“哪里会不会出问题”。GPU推理监控大盘就是AI服务的中控台。它把大量零散的运行数据拼成一眼能看懂的图表，让你像餐厅老板一样在几分钟内掌握全局。

在可观测性领域，这些数据被归纳为三大支柱：指标（Metric） 是定时采样的数值，比如GPU利用率、每秒请求数；日志（Log） 是记录事件细节的文本，比如某次请求超时的报错；链路追踪（Trace） 则是还原一个请求经过网关、预处理、推理引擎的完整路径。监控大盘把这三类信息汇总在一起，形成“总览—下钻—定位”的闭环。

设计大盘时，最忌讳把几百个图表堆在一起。好的大盘有三条原则：先确定一个北极星指标作为最高层的“红灯”；再按“集群—实例—请求”做分层下钻；最后用视觉颜色区分繁忙、高负载、过载三个状态。衡量整体好坏最常用的北极星指标就是服务健康度，也就是满足服务质量目标的请求占比。

回到餐厅比喻：健康度是那块最显眼的“综合满意度大屏”。如果它跌到90%以下，你不需要看细枝末节，第一反应就应该是“今天服务出了问题”，然后沿着大盘层层下钻，找到是哪张桌子、哪道菜、哪个环节掉了链子。

核心GPU指标：厨师的脉搏

如果餐厅老板想知道后厨有没有“虚度光阴”，会看厨师是否在频繁颠勺、操作台是否堆满备料、灶台火力足不足。GPU推理监控同样要看四个核心指标：SM利用率、显存占用、功耗和温度、GPU时钟频率。

SM（Streaming Multiprocessor）利用率是GPU计算核心的繁忙程度。SM相当于厨师，利用率就是他们真正在颠勺的时间比例。推理任务的特点是“每生成一个词都要串行算一次”，所以SM利用率往往只有30%—60%，远低于训练场景。看到利用率不高时别急着加负载，先看看是什么在拖后腿——可能是访存瓶颈，也可能是批次太小。显存占用则像冰箱和工作台的空间，推理时权重、KV缓存、激活值都会占地方，超了就会OOM（内存耗尽）甚至进程被杀。功耗与温度决定GPU会不会“降频保命”：温度逼近85°C甚至更高时，芯片自动降频，性能随之崩盘，就像厨师热到中暑只能放慢速度。GPU时钟频率则像厨师的速度档位，低频说明在摸鱼或散热不足，高频满载说明火力全开。

监控时要注意：SM利用率和显存占用要放在一起看。好比厨师在满负荷炒菜，但操作台已经不够用了——这时真正该优化的不是加人，而是整理空间（KV缓存管理）或者让更多菜合并下锅（批处理）。两块指标一横一纵，才能拼出后厨的真实画像。

推理性能指标：上菜速度的真实体验

客人去餐厅最在意的不是厨师多辛苦，而是“第一道菜什么时候上”“整顿饭能不能在合理时间吃完”。GPU推理服务也一样，用户的真实体验由几个延迟指标定义：TTFT（首Token时延） 是从发起请求到模型吐出第一个字的时间，相当于第一道凉菜上桌的等待；TPOT 是每生成一个输出Token所花的时间，相当于每道菜的上菜节奏；端到端延迟 则是整个请求完成的总时长。它们共同回答一个问题：用户体验到底快不快？

只看平均值是远远不够的。假设餐厅平均上菜10分钟，但高峰时段有一部分客人等了40分钟——平均分会被大多数快单掩盖，而等40分钟的人早已愤怒离店。因此监控大盘必须看分位延迟：P50代表中位数体验，P99代表最差的那1%体验。对在线推理服务来说，P99才是真正的“用户耐心红线”。

监控时建议把TTFT、TPOT和P99画在同一个时间轴上。好比餐厅同时看“第一道菜时间”“上菜节奏”和“最慢客人体验”三条曲线。当P99突然飙升而P50平稳时，问题往往出在排队或资源争抢，而不是模型本身——这种“尾部恶化”是定位瓶颈的重要线索。

批处理与并发：一次做好几道菜

餐厅出餐口的柜台一次只能放几道菜，但如果同时要出几十份订单，聪明的后厨会用一个“大托盘”把多道菜一起端出去。GPU推理中的批处理（Batching） 就是这种思想：与其一个请求一个请求地算，不如把多个请求合并成一批，让GPU同时处理，摊薄固定开销，大幅提升吞吐量。

早期推理框架多使用静态批处理：等凑满一批再统一执行，但流量稀疏时GPU经常空转。现代推理引擎（如vLLM）升级为动态批处理和连续批处理：请求到达后立刻进入当前批次，序列生成完毕就腾出位置，让排队的请求“插队”进来。这就像服务员随时把新订单塞进同一盘托盘，而不是非要等托盘装满再送。监控大盘上要重点跟踪当前批大小和队列长度：批大小太小说明GPU“吃不饱”，队列太长说明后端已经“消化不过来”。

批处理监控的巧妙之处在于“既要又要”：批次越大，GPU吞吐越高，但单个请求可能多等几轮才能排上。大盘上同时展示批大小和P99延迟，就能找到那个“吞吐又高、尾延迟又可接受”的甜蜜点，让后厨既不闲着也不让任何客人等到发火。

资源优化：让厨房井井有条

餐厅生意再好，操作台只有那么大。食材不能整箱堆在台面上，而是要分门别类放进小抽屉，随用随取。GPU推理的显存管理也是类似的难题：模型运行时要为每个请求的注意力机制保存一份KV缓存（Key-Value Cache），它会随生成长度线性膨胀，成为显存中最占空间的“食材”。

传统推理框架为每个请求预留一整块连续显存，但不同请求生成长度差异很大，很容易留下大量碎片。现代推理引擎采用分页管理（PagedAttention）：把KV缓存切成大小固定的“页”，像厨房放调料的小抽屉一样按需分配，用到哪页申请哪页，极大降低碎片率。但碎片依然存在，所以大盘上要设置显存碎片率与缓存命中率指标：碎片率升高意味着很多“零散空隙”无法利用，缓存命中率则反映前缀复用是否生效。如果显存长期紧张，还可以用量化把模型权重从FP16压到INT8，或者配置自动伸缩让副本数量跟着流量涨落。

把厨房管理延伸到自动伸缩：当碎片率和显存水位双高时，系统会主动整理缓存或触发扩容；当深夜低峰时再缩容省电。数据说话，比人工拍脑袋准得多——这就像餐厅根据实时订餐量自动决定开几个窗口，而不是每天固定开全部灶台。

告警与SLO：守住出餐承诺

很多餐厅承诺“30分钟未上齐，此单免单”，这就是出餐服务质量目标。AI服务也有类似的承诺：比如“95%的请求要在200毫秒内返回”，这被称为SLO（服务等级目标）。SLO不是给用户看的虚话，而是运维决策的标尺。所有请求里允许未达标的比例，被称为错误预算。假如SLO是95%，那么错误预算就是5%——好比每天允许5%的客人催单。

错误预算用一点少一点，用得太快就要叫停风险。燃烧率（Burn Rate） 衡量的就是错误预算消耗的速度：燃烧率为1表示“恰好按预算速度消耗”，大于1说明正在透支未来预算，必须告警。燃烧率不能只看一个窗口，要在1小时、6小时、3天等多个时间尺度同时观察——1小时窗口能快速发现突发故障，6小时和3天窗口能排除偶发抖动，防止误报警。这种机制叫多窗口多维告警。

告警触发后，接下来要做的是“联动排查”：从燃烧率异常这张总览图，一路下钻到具体是哪个模型版本、哪个GPU节点、哪条网络链路出问题。就像顾客频繁催单时，你得倒查是后厨出错、传菜太慢还是收银台堵住了。监控大盘把SLO、指标、日志和追踪打通，就能让每一次告警都快速变成一次准确定位。

AI 应用场景

Python 演示

"""GPU 推理服务监控指标模拟器：统计SM利用率、P99延迟与SLO燃烧率。"""import randomfrom collections import deque  class GPUInferMonitor:    def __init__(self, slo_ratio=0.95, window=500, total_sm=132):        self.slo_ratio = slo_ratio        self.window = window        self.total_sm = total_sm        self.busy_ticks = 0        self.total_ticks = 0        self.requests = deque(maxlen=window)        self.frag_count = 0   # 显存碎片整理次数     def record(self, latency_ms, ok, busy_sm):        self.requests.append((latency_ms, ok))        self.busy_ticks += busy_sm        self.total_ticks += self.total_sm     def sm_utilization(self):        if self.total_ticks == 0:            return 0.0        return self.busy_ticks / self.total_ticks * 100     def p99(self):        vals = sorted(lat for lat, _ in self.requests)        if not vals:            return 0.0        idx = int(0.99 * len(vals)) - 1        return vals[max(0, idx)]     def success_rate(self):        if not self.requests:            return 1.0        ok = sum(1 for _, good in self.requests if good)        return ok / len(self.requests)     def burn_rate(self):        error_budget = 1 - self.slo_ratio        if error_budget <= 0:            return 0.0        error_rate = 1 - self.success_rate()        return error_rate / error_budget  if __name__ == "__main__":    random.seed(7)    mon = GPUInferMonitor(slo_ratio=0.95)     for i in range(300):        busy_sm = random.randint(30, 125)        lat = random.expovariate(0.05)        if lat > 180:            lat = 180 + random.random() * 120   # 模拟排队导致的尾延迟        ok = lat < 200        mon.record(lat, ok, busy_sm)     print("SM 利用率: {:.1f}%".format(mon.sm_utilization()))    print("P99 延迟: {:.1f} ms".format(mon.p99()))    print("成功率: {:.2f}".format(mon.success_rate()))    print("燃烧率: {:.2f} (>1 表示需要告警)".format(mon.burn_rate()))

1. self.requests = deque(maxlen=window)用双向队列保留最近500条请求，超出自动丢弃，就像大盘只展示一个滚动窗口。
2. self.busy_ticks += busy_sm每次记录都把当前忙的SM数累加，作为利用率公式的分子。
3. ok = lat < 200判断本次请求是否满足SLO（延迟小于200ms）。
4. mon.record(lat, ok, busy_sm)每次推理完成时写入一条监控记录。
5. return self.busy_ticks / self.total_ticks * 100SM利用率 = 实际忙周期 / 理论总周期。
6. idx = int(0.99 * len(vals)) - 1用99%分位数索引直接取出P99延迟。
7. error_rate / error_budget实际错误率除以允许错误率，得到燃烧率。

常见误区

面试题