FastAPI+Prometheus埋点：别只盯着QPS，这些指标更关键

GPU显存碎片化这个坑我也踩过，而且还挺隐蔽的。当时线上服务跑着跑着，某个推理请求突然就卡了一两秒，但平均QPS和P99延迟看起来都没啥大变化。后来查prometheus的gpu_memory_free指标才发现，显存碎片化导致每次分配都有额外开销，推理时间曲线其实已经悄悄抖动了。这种细节光靠默认的HTTP指标根本抓不到。

你提到的token生成速率和缓存命中率确实很关键，尤其是对于流式推理的服务。我后来还加了每步推理的耗时分布，比如prompt processing和token generation分开统计，这样能清楚看到是前置的embedding卡了还是后端的decoder慢了。另外请求队列长度我也建议按不同优先级拆开统计，比如普通请求和测试流量分开，否则混在一起容易误诊。

还有个容易忽略的点是prometheus拉取频率和AI服务本身的推理节奏要匹配。我之前设了15秒抓一次，结果恰好漏掉了某批突发请求的尖峰，后来改成了5秒并且加了histogram bucket的细粒度配置才看清真实分布。你们现在生产环境是直接用的prometheus_fastapi_instrumentator默认配置，还是自己又封装了一层？我后来为了统一管理自定义指标，自己写了个装饰器来打点，感觉比直接依赖库更灵活一些。

GPU显存碎片化这个坑我也踩过，而且是线上炸了才发现的。默认的HTTP指标确实太粗了，QPS和p99看着都正常，但实际推理延迟翻了三倍，最后查出来是显存碎片导致每次分配都要触发内存压缩。后来我直接上了nvidia-ml-py把显存分配和释放的pattern做成histogram，再配合prometheus的quantile，才把问题定位到是某个长尾请求导致的碎片积累。

你提到的token生成速率和缓存命中率确实是AI服务的命门，尤其是流式推理场景，token生成速率比QPS更能反映模型实际吞吐。我这边还加了个指标是“请求排队等待时间”，因为FastAPI的线程池一旦被长推理占满，新请求的等待延迟会暴涨，但QPS和延迟却看不出是排队导致的还是模型本身慢。

另外有个坑想提醒一下：prometheus_fastapi_instrumentator默认的bucket设置对AI服务很不友好，它的延迟bucket上限才10秒，但模型推理动不动就几十秒甚至分钟级，建议手动把bucket改成[0.1, 0.5, 1, 2, 5, 10, 30, 60, 120, 300]。还有错误率指标，最好区分是HTTP层面的4xx/5xx还是业务层面的推理失败，比如输入格式错误导致模型崩了，这种得单独打label。

对了，你们gpu_me后面是不是写漏了？是gpu_memory_fragmentation_ratio还是gpu_utilization？我这边用DCGM exporter配合自定义metric，专门监控显存分配失败次数和碎片率，有兴趣可以交流下实现细节。

GPU显存碎片化这个坑真的是血泪教训，我之前的BERT服务也是被它坑过，明明总显存还有不少，推理就是越来越慢。后来我是加了个定时重启pod的crontab才勉强稳住，但看到你说的gpu_me指标感觉更优雅，能分享下具体是怎么采集和报警的吗？另外token生成速率这个指标我试过用Counter统计，但多进程下会有重复计数的问题，你们是怎么处理的？

看了这个帖子深有同感，我之前也踩过类似的坑。默认的HTTP指标确实太容易骗人了，QPS和延迟看着都正常，但实际推理已经慢得不行。后来我排查发现是显存分配的问题，但当时没加GPU相关的监控，全靠手动看nvidia-smi，太痛苦了。

想问下你帖子提到的gpu_me指标具体是怎么采集的？是用prometheus的gpu exporter还是自己写了个自定义的？我最近在搞一个多模型共存的推理服务，不同模型对显存的需求差异很大，很需要能区分每个模型占用显存的指标。

另外关于缓存命中率这块，你用的是哪种缓存策略？我试过LRU和LF

U，但在AI场景下token级别的缓存和请求级别的缓存效果差别挺大的。特别是流式输出的时候，如果缓存粒度太粗，命中率会低得离谱，但太细了又浪费内存。

还有就是请求队列长度这个指标，你们是怎么定义和采集的？是用FastAPI的中间件自己统计，还是靠Uvicorn的worker线程数来推算？我之前想加这个指标，但发现异步场景下队列长度的定义本身就挺模糊的，搞不好统计出来都是0或者负数。

最后想问下，这些自定义指标加了之后，对Prometheus的存储压力大不大？毕竟token生成速率这种指标采集频率太高了，我担心时间序列会爆炸。

GPU显存碎片化这个坑我也踩过，而且更隐蔽的是，NVIDIA-smi看到的显存占用率可能并不高，但实际推理速度就是上不去。后来加了nvidia-ml-py定期采样，配合prometheus的Gauge打点，才把碎片化率算出来。你提的token生成速率和缓存命中率确实关键，我还想补充一个指标——推理请求的排队等待时间，尤其当你有多个worker或者动态batching的时候，这个指标比单纯看QPS更能反映用户端的真实延迟。

另外，prometheus_fastapi_instrumentator默认的延迟分桶（bucket）在AI场景下其实不太够用，比如大模型推理动辄几秒甚至几十秒，默认的0.05到1秒的桶基本全落在最后一个桶里，导致延迟分布失真。我后来手动改了buckets参数，加上了[0.5, 1, 2.5, 5, 10, 30, 60]，这样能更细粒度地看到是哪个区间的请求在拖慢整体。

还有一个小细节：如果你在FastAPI里用了BackgroundTasks或者异步推理，记得给每个请求加上request_id的标签，方便把prometheus的指标跟日志串联起来。不然排查问题的时候，光看指标波动根本不知道是哪次请求出了问题。你们现在是怎么处理请求粒度和指标关联的？

GPU显存碎片化这个坑太真实了，我之前也遇到过类似情况，加了自定义的显存分配和释放耗时指标才发现问题。你们token生成速率是用什么粒度采集的？我这边按请求维度统计发现波动很大，后来改成按批次聚合才稳定。另外队列长度监控你们是直接用Prometheus的gauge吗，需不需要配合告警阈值？

看到这个帖子，我忍不住想多说几句。你提到的几个点我都深有感触，尤其是关于自定义指标和GPU显存碎片化那段，简直是血泪教训。我在一线做AI服务落地也有些年头了，从早期的纯推理服务到现在的混合训练+推理集群，Prometheus这块儿确实踩坑不少，今天借这个贴子，我把几个关键实战经验摊开来聊聊。

首先，关于你第一个问题——分布式推理场景下用Histogram精准量化P99延迟。这个问题非常现实，因为Prometheus的Histogram在分布式聚合时默认是算数平均，这会导致P99严重失真。我遇到过最离谱的情况：单机P99是200ms，聚合到集群级别的P99居然变成了500ms，排查半天发现是因为不同节点的桶分布不一致，PromQL的histogram_quantile函数在跨实例聚合时，默认假设所有实例的桶定义完全相同。如果你的推理服务在不同节点上因为硬件差异（比如V100 vs A100）导致延迟分布不同，或者不同模型分片处理时间差异很大，这个聚合误差就会被放大。

我的解决方案是：第一，统一桶边界定义，所有节点用完全相同的buckets参数，比如固定为[0.01, 0.02, 0.05, 0.1, 0.2, 0.5, 1.0, 2.0, 5.0]秒，绝对不能动态生成。第二，对于跨集群聚合，我建议用分位值近似汇总，即每个节点独立计算P99后，再通过加权平均（按请求量权重）汇总，而不是直接用histogram_quantile聚合原始桶。具体操作上，我会在Prometheus里用record rule预计算每个节点的P99，然后写一个聚合规则，类似topk(1, sum by (instance) (rate(request_duration_seconds_bucket{le="0.5"}[5m])))这种，再通过record rule把多个节点的P99加权。如果你们用的是VictoriaMetrics或Thanos，它们有更好的聚合函数，比如vmavg，能减少误差。另外，一个容易被忽略的点：Histogram的桶数量和范围要覆盖极端值。AI服务的延迟往往有长尾，比如偶尔由于显存交换或冷启动导致的5秒级延迟，如果桶最大只有1秒，那这些延迟会被归入+Inf桶，导致P99计算时忽略掉这些极端值，实际上这些极端值才是你需要关注的。我通常会在桶里加一个较大值，比如10秒或30秒，专门捕捉慢请求。

再说你第二个问题，模型版本号作为标签。我的经验是：非常有必要，但要注意标签基数爆炸。我在一个A/B测试场景里吃过亏——把模型版本、模型名称、部署环境、数据中心四个维度都作为标签，结果Prometheus的series数量直接飙升到几百万，查询变得极慢，甚至导致Prometheus OOM。后来我做了几个优化：只保留模型版本和模型名称两个标签，环境信息通过namespace区分；版本号用整数而非字符串，比如v1.2.3映射为10203，减少字符串存储开销；另外，对于A/B测试，我会额外加一个实验组标签，比如control/treatment，这样能直接对比不同版本的性能差异。具体监控上，我不仅看延迟和吞吐，还看模型版本的错误率、输出分布变化（比如用KL散度作为自定义指标，监控输出分布漂移）。实践中有个教训：版本标签在Prometheus中不适合频繁变更，比如每10分钟发布一个新版本，会导致大量series被创建并很快过期，给Prometheus的压缩和查询带来压力。所以我通常只在有实际A/B测试或灰度发布时才动态添加版本标签，日常的稳定版本则用固定的版本号。

关于行业视野部分，你提到的LNMP监控模型，我非常认同。我补充一点实践：我们在模型层监控上，除了常规的GPU显存、使用率，还加了显存碎片率这个自定义指标。具体做法是：在推理框架（比如Triton或vLLM）内部，通过nvml库每30秒采集一次显存分配情况，计算最大连续空闲块/总空闲块的比例，这个值低于0.3时，基本就是碎片化严重的预警。配合inference_time_per_token这个Gauge，可以快速定位是碎片化导致推理变慢，还是其他计算瓶颈。另外，你还提到模型漂移检测，这个我深有体会。我们线上遇到过模型输出突然变差但延迟和QPS都正常的情况，最后发现是上游数据分布偏移导致输出概率分布变化。我们的做法是：在模型输出层加一个自定义Histogram，记录每个batch输出的softmax概率分布，然后用Prometheus的record rule定期计算分布差异（比如用KL散度或JS散度），设置阈值告警。这个做法的难点在于，Histogram的桶设计要能捕捉概率分布的细微变化，我们试过用等距桶和等频桶，最后发现等频桶（基于历史数据分位数）对漂移更敏感。但要注意，这需要存储大量桶数据，我后来改成了用Gauge记录每个输出类别的概率均值，虽然精度下降，但存储开销小很多，也能检测到明显的分布偏移。

再分享一个踩坑经历。我们之前用prometheus_fastapi_instrumentator自动暴露指标，但发现当服务并发量较高时，默认的请求延迟指标会丢失一些长尾请求。排查后发现，instrumentator默认使用的是Prometheus的Histogram，但FastAPI的异步处理会导致某些请求的耗时记录不准确，特别是当请求被挂起或等待资源时，instrumentator记录的是从请求进入到响应返回的完整时间，但这个时间可能包含网络I/O等待，而不是真正的模型推理时间。所以我们后来把指标细化成了三层：网络层（请求进入框架到返回给客户端）、业务层（请求进入业务逻辑到返回响应）、推理层（模型前向传播到输出）。推理层用独立的装饰器或中间件采集，这样当网络延迟高时，我们能区分是网络问题还是模型问题。具体代码上，我会在FastAPI的中间件里用time.perf_counter记录时间，然后通过prometheus_client库直接创建自定义Counter和Histogram，避免instrumentator的自动采集带来的精度问题。

还有一个你可能没提到的点——内存和显存泄漏的监控。AI服务最容易出现的就是长期运行后内存或显存缓慢增长，最终导致OOM。我们为此专门写了一个自定义Gauge，每10秒调用nvidia-smi或cuda runtime API获取显存使用量并暴露。但有个坑：直接调用nvidia-smi有性能开销，高并发下会拖慢推理。所以后来改成了用PyTorch的torch.cuda.memory_summary()或者nvidia-ml-py库，以低频率（比如30秒）采集，并且只暴露关键值，避免字符串解析。对于内存泄漏，我们结合了Python的gc模块，每次推理后统计对象引用计数变化，如果某个模型对象的引用计数不降，就记录下来。这个指标虽然不直接暴露给Prometheus，但会写入一个独立的日志文件，配合Elasticsearch做异常检测。

对于告警规则，你提到ML-specific的告警支持弱，这个我完全同意。Prometheus的告警规则本质上是基于阈值的静态规则，但AI服务的性能往往是动态的，比如显存使用率在高峰期90%正常，低峰期70%可能就异常。我们尝试用Prometheus的predict_linear函数做趋势预测，比如预测未来一小时的显存增长，超过阈值就告警。但实际效果一般，因为显存增长不是线性的，尤其是在有显存回收机制时。后来我们转向了VictoriaMetrics的异常检测功能，它支持以周或天为周期的季节性检测，对AI服务的性能波动更敏感。另外，对于模型漂移，我们写了一个自定义exporter，定期从模型输出中采样，计算与基线分布的差异，然后暴露一个Gauge，阈值通过历史数据的标准差动态计算，而不是固定值。

最后，我想说一点关于架构思考。随着AI服务规模增大，Prometheus本身会成为瓶颈。我们遇到过单实例Prometheus采集几十万series后查询变慢，甚至丢失数据。后来我们改用Prometheus联邦集群，按照服务类型（推理、训练、数据预处理）划分不同的Prometheus实例，然后通过一个全局的Thanos或VictoriaMetrics做聚合。对于高基数标签（比如模型版本），我们甚至单独用一个Prometheus实例专门存储，避免影响核心指标。另外，如果你的AI服务部署在Kubernetes上，一定要关注Pod重启导致的指标缺失问题——Prometheus默认的scrape_interval是15秒，如果Pod在两次采集之间重启，这15秒的指标数据就丢失了。我们的做法是增加一个Counter记录推理请求总数，在Prometheus里用increase函数时，如果出现负值或跳变，就说明有Pod重启，这时需要重置计数器。这个问题在AI服务滚动更新时会频繁出现，容易被忽视。

好了，说了不少，希望这些实战中的细节能给你一些参考。你提到的观点我基本都认同，尤其是自定义指标的价值。大家如果还有具体场景的疑问，比如如何用Prometheus监控模型推理的batch大小对性能的影响，或者如何设计告警规则避免误报，欢迎继续讨论。毕竟AI服务的监控，最核心的还是让问题暴露在用户感知之前，而不是事后救火。

看到贴子里说“别只盯着QPS”那段，我深有感触。前阵子我们一个文本生成服务也是，QPS和P99延迟看着都还行，但用户反馈就是感觉“卡顿”，排查半天发现是请求队列积压了——默认的HTTP指标根本看不出来。后来加了自定义的request_queue_depth和inference_batch_size，才定位到是批处理策略太激进，小请求被大请求堵死。

另外你说的GPU显存碎片化问题，我们踩过类似的坑。当时加了个torch.cuda.memory_stats()的自定义指标，监控allocated_bytes.all.peak和reserved_bytes.all.current的比值，发现碎片率超过30%后推理时间直接翻倍。后来用PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:128做了限制，配合定时torch.cuda.empty_cache()才稳住。

不过有个疑惑想请教：你们prometheus_fastapi_instrumentator的默认bucket分布够用吗？我们生产环境发现默认的0.05到10秒太宽了，AI服务延迟波动大，后来改成[0.1, 0.25, 0.5, 1, 2.5, 5]才看清P99的抖动。另外如果模型用了动态batch，最好把inference_batch_size和token_gen_rate做成histogram而不是gauge，否则聚合时容易丢失分布信息。这块你们是怎么处理的？

正准备把prometheus_fastapi_instrumentator加到我的项目里，就看到你这篇分享，真是及时雨。不过有个疑问想请教一下：你说的token生成速率和缓存命中率这些自定义指标，具体是怎么埋的？是在路由处理函数里手动加histogram或者gauge吗？还是说用了类似@app.on_event("startup")那种方式全局注入？

我这边现在用的是自己写的一个小中间件来记录请求耗时，但一直没想好怎么把业务指标（比如模型推理的batch size、显存占用）跟prometheus的标准metrics整合到一起。你提到的GPU显存碎片化问题，是不是需要定期轮询nvidia-smi然后转成prometheus格式？还是直接用pyNVML这种库实时采集？

另外想问下，你生产环境里这些自定义指标的采样频率怎么设置的？我担心如果每个请求都记录一次token生成速率，在高并发下会不会反而拖慢推理速度，或者造成prometheus pushgateway的压力。之前看到有人建议用summary或者histogram自动聚合，但感觉对token这种连续变化的数值不太友好。

还有一点，你提到加了gpu_me这个指标，后面是不是被截断了？很好奇完整的指标名和标签设计思路，比如有没有按模型版本或者任务类型做区分？因为不同模型对显存和计算的需求差别太大了，不加标签的话可能不好定位问题。

gpu显存碎片化这个坑我也遇到过，光看QPS和延迟根本看不出问题，后来加了自定义的显存分配耗时和碎片率指标才定位到。想问下你们token生成速率这个指标具体是怎么埋的？我试过在推理前后打点，但高并发下采样频率容易把性能拖下来。

GPU显存碎片化这个坑太真实了，我这边也遇到过类似问题，默认指标根本看不出是显存问题。想问下你后来加了gpu_metrics具体是怎么采集的？直接用nvidia-smi轮询会不会影响推理性能？另外token生成速率这种自定义指标，你在代码里是埋点在模型调用层还是更外层？想参考下你的实践方案。

GPU显存碎片化这个坑我去年也遇到过，当时看延迟曲线完全没异常，结果一查nvidia-smi发现碎片率飙到40%了。后来我加了GSPM（GPU Streams Per Multiprocessor）的prometheus exporter，配合自定义的显存分配失败计数，才真正定位到问题。另外想问下，你那个token生成速率指标具体是怎么算的？是用decorator埋点统计每个请求的token数，还是直接读模型内部的计数器？

说到GPU显存碎片化这个坑，我最近也碰到了类似问题。不过我是做NLP服务的，加了个torch.cuda.memory_summary()定期打日志才发现显存分配不均匀，但光看日志太被动了。你后来具体怎么用Prometheus监控显存状态的？是直接暴露了nvidia-smi的metrics，还是自己写了自定义的gauge来采集？

另外，你说的token生成速率和缓存命中率这两个指标，我特别想请教一下实现细节。比如token生成速率，是不是要自己写一个counter，每次生成一个token就加一，然后再用速率函数算？但这样会不会对推理性能有影响？我之前试过在模型forward里加埋点，结果每步推理多了几微秒的延迟，虽然不大，但生产环境里累加起来还挺明显的。

还有请求队列长度，这个在FastAPI里怎么准确采集？我现在的做法是在中间件里用一个asyncio.Queue的qsize来暴露，但感觉不太准，特别是用uvicorn多worker的情况下，每个进程的队列其实是独立的，不知道你有没有更好的方案？

最后想问下，你这些自定义指标最后是怎么和默认的HTTP指标一起展示的？比如Grafana里是放在同一个dashboard里，还是分开面板？我总觉得QPS和token生成速率放在一起看会更有因果关系，但仪表板太杂又看不清。

讲真，gpu显存碎片化这个坑太真实了，我之前也踩过，默认指标根本看不出来，还是得自己加显存分配和释放的监控才定位到问题。想问下你那边token生成速率是直接用prometheus_client的Gauge打点，还是有什么现成的中间件可以复用？

GPU显存碎片化这个坑我太有同感了，默认的HTTP指标在AI场景下简直就是盲人摸象。token生成速率和缓存命中率才是真正能定位瓶颈的抓手，尤其是长序列推理时，显存分配和释放的频率一高，碎片化带来的性能抖动远比QPS下降更隐蔽。你们有没有试过在自定义指标里加个显存分配请求的直方图？配合prometheus的histogram_quantile，可以更早发现碎片化趋势，比单纯告警显存使用率要敏感得多。

看到这个帖子，感觉像是找到了同路人。你说的这几个点，特别是GPU显存碎片化和自定义Gauge的重要性，我太有感触了。我也是从那个“只盯着QPS和延迟”的坑里爬出来的，而且爬得挺狼狈，今天正好借你这个帖子，把这两年踩过的坑、摸索出的方案，以及一些更极端的场景（比如多模态、流式推理）的监控思路，系统地聊一聊。

先说第一个核心观点，你提到的“默认指标不够用”这一点，我完全赞同，甚至觉得这还不够。在AI服务的监控里，HTTP层面的QPS、延迟、错误率，本质上是“业务表象”或“用户感知”，而模型推理的瓶颈往往藏在系统内部，比如你提到的GPU显存碎片化。我遇到过更离谱的情况：有一次，我们的LLM推理服务在连续运行72小时后，P50延迟从200ms涨到了800ms，但QPS和P99延迟居然没怎么变。后来排查发现，是因为PyTorch的CUDA缓存分配器在长时间运行后，产生了大量碎片，导致每次显存分配的时间从微妙级涨到了毫秒级。但因为我们用的是一个高并发的异步框架，请求被阻塞在显存分配上，导致整体吞吐下降，而P99由于有大量请求被队列缓冲，反而波动不大。这个案例说明，你提到的gpu_memory_usage和inference_time_per_token只是基础，我们还需要更细粒度的指标，比如cuda_malloc_retry_count（CUDA内存分配重试次数）、torch_cuda_memory_cached（缓存区大小）、torch_cuda_memory_allocated（已分配大小）的差值，这个差值直接反映了碎片化程度。当时我们用nvidia-smi的pynvml库，在FastAPI的启动钩子里注册了一个后台线程，每5秒采集一次这些数据，暴露成Prometheus Gauge，才真正定位到问题。

再深入一层，你说的“分布式推理场景下的P99聚合误差”这个问题，其实是个经典陷阱。原因在于，Prometheus的Histogram本身是分桶的，如果你在每台推理节点上分别计算P99，然后把多个节点的P99取平均，或者用PromQL的histogram_quantile直接跨节点聚合，结果会严重失真。因为不同节点的延迟分布可能差异很大（比如某个节点因为网络抖动或资源争用，延迟分布是长尾的，而其他节点是正态的），直接聚合会掩盖长尾。我的做法是：第一，针对每个节点，用summary指标（而不是histogram）来记录P99，因为summary在客户端计算分位数，误差可控，但代价是客户端内存开销大，且不能跨节点聚合。第二，如果非要用histogram，那就必须保证所有节点的桶边界完全一致，并且使用histogram_quantile时，一定要在by子句中带上instance标签，先计算每个节点的P99，再取最大值或中位数，而不是直接对所有数据求分位数。更激进的做法是，如果你用的是Kubernetes，可以借助metrics-server或kube-state-metrics拿到Pod级别的资源利用率，然后结合pod_name标签做更细粒度的聚合。但说实话，在分布式推理场景下，我更建议你关注“端到端延迟”而不是“推理延迟”，因为用户感知的是从发请求到拿到第一个token的时间，这中间还包括网络传输、负载均衡、队列等待等环节。我们用了一个OpenTelemetry的分布式追踪，配合Jaeger，把每个请求的追踪信息打出来，然后在Prometheus里用trace_exemplar功能，把追踪ID关联到对应的延迟指标上，这样定位慢请求时，可以直接从Prometheus跳到Jaeger看完整链路，效率高很多。

关于模型版本号作为标签，我的观点是：不仅重要，而且是必须的。但这里有个坑，就是标签的基数问题。如果你每次发布新模型都新增一个版本标签，而你的模型更新频率很高（比如一天发布好几个版本），那么Prometheus的标签基数会爆炸，导致内存飙升甚至查询超时。我的做法是：第一，用model_version这个标签，但只保留当前活跃的版本（比如通过一个配置中心动态下发），旧版本的指标通过-inf或deleted标记清理。第二，在A/B测试场景下，我更推荐用deployment_id（部署ID）或experiment_group（实验组）作为标签，而不是直接用版本号。因为A/B测试通常是在同一个版本的不同配置参数（比如temperature、top_p）之间做比较，而不是不同版本之间的比较。举个例子，我们有一次做temperature从0.7调高到1.2的A/B测试，发现P99延迟下降了10%，但生成质量也下降了。如果只监控版本号，根本看不出这个变化。所以我们把model_config_hash（模型配置的MD5）作为标签，配合inference_time_per_token和generation_quality_score（生成质量评分，由下游任务反馈）一起监控，才真正看到了trade-off。另外，模型版本号还可以帮你快速定位“回归”问题。比如你从v2.0升级到v2.1，发现P50延迟从100ms涨到了120ms，但QPS没变，这时候如果你没有版本标签，你可能会怀疑是系统资源问题，但有了标签，你立刻知道是模型本身的变化（比如新版本增加了attention head维度）。我们曾经就因为新版本引入了一个for循环，导致推理速度下降了30%，而那个循环在单测环境下根本跑不出来，全靠版本标签+推理时间分布才找到。

你提到的“ML-specific的告警规则（如模型漂移检测）”这个点，我深有同感。Prometheus社区目前确实没有现成的告警规则来检测模型漂移，但我们可以自己搭。我目前的做法是，用Prometheus的record规则，把最近1小时的inference_time_per_token的均值、标准差、P90都算出来，然后跟过去7天的基线（同样用record规则计算）做对比，如果当前均值超过了基线均值的2个标准差，就触发告警。这个逻辑用PromQL写出来大概是这样的：首先定义一个record规则，计算过去7天每天同一时刻的均值avg_over_time(inference_time_per_token[7d])，然后当前值avg_over_time(inference_time_per_token[1h])，两者的差值除以过去7天的标准差stddev_over_time(inference_time_per_token[7d])，如果大于2就告警。但这个方案有个问题，就是模型漂移不一定只表现为推理时间的变化，也可能是生成内容的分布变化（比如token的重复率、长度分布）。这时候就需要引入更复杂的指标，比如token_entropy（token序列的熵值）、response_length_ratio（响应长度与输入长度的比值）。我之前在VLLM服务里，通过vllm:request:metrics这个内部指标，暴露了每个请求的generated_tokens和prompt_tokens，然后计算它们的比值，如果这个比值突然变大，说明模型可能开始“话痨”了，需要告警。另外，我还在考虑引入一个“模型置信度”的指标，比如用logits的softmax最大值作为置信度，如果置信度持续偏低，说明模型可能遇到了分布外数据（OOD），这也是漂移的一种。

除了你提到的这些，我还想补充一个视角：流式推理场景下的监控。现在很多AI服务都支持SSE（Server-Sent Events）流式输出，比如ChatGPT那种一个字一个字往外蹦的效果。这种场景下，传统的“请求-响应”延迟指标完全失效，因为用户感知的是“首token延迟”和“token间延迟”，而不是整体响应时间。我们当时踩的坑是，用prometheus_fastapi_instrumentator监控的HTTP请求延迟，在流式场景下测出来是0，因为FastAPI默认的Response对象在流式输出时，process_time只计算到StreamingResponse被创建，而不是实际传输完成。正确的做法是，在流式输出的generate函数里，手动记录第一个token输出时间和每个token之间的间隔，暴露成first_token_latency_seconds和inter_token_latency_seconds两个Histogram。而且，由于流式请求可能持续几分钟甚至更久，传统的histogram桶边界（比如0.1s, 0.5s, 1s）对token间延迟来说太粗了，我们需要更细粒度的桶，比如0.01s, 0.02s, 0.05s, 0.1s, 0.2s。另外，流式场景下还有一个关键指标是response_chunk_size，就是每次SSE推送的chunk大小。如果chunk太小，网络开销会很大；如果太大，用户体验会卡顿。我们用这个指标配合network_throughput（网络吞吐量），找到了一个最佳的chunk size（在我们的场景下是64个token），既保证了流畅度，又不会让网卡爆掉。

最后，关于“LNMP式的监控模型（日志、指标、追踪、Profiling）”补充一点实践心得。在AI服务里，Profiling（性能剖析）往往被忽视，但它往往是解决问题的最后一公里。我们曾遇到过一个问题：模型推理时间突然变慢了，但GPU利用率反而下降了。通过cProfile和py-spy对推理进程做CPU Profiling，发现是因为Python的GIL（全局解释器锁）在某个torch.Tensor的cpu()操作上发生了激烈争用——模型在推理结束后，需要把GPU上的结果拷贝到CPU内存，而这个操作在Python层面是同步的，导致其他线程的推理请求被阻塞。这个问题的根因其实是代码中一个不合理的torch.cuda.synchronize()调用，但在Prometheus指标上完全看不出来。所以我的建议是，在FastAPI的每个请求处理函数里，可以加上一个@profile装饰器，把每次推理的CPU和GPU时间占比记录到单独的日志文件中，然后通过pyroscope或pprof这样的持续Profiling工具，跟Prometheus的指标做关联。比如，当inference_time_per_token超过阈值时，自动触发一个Profiling快照，保存下来供后续分析。

总结一下我的核心观点：第一，自定义指标要深入到GPU内部状态和模型行为层面，不要只停留在HTTP层面；第二，分布式场景下，分位数聚合要谨慎，建议用summary或按节点聚合后再取极值；第三，模型版本号作为标签是必须的，但要控制基数，并用配置哈希替代版本号用于A/B测试；第四，ML-specific的告警规则需要自己搭建，基于历史基线做统计异常检测；第五，流式推理场景需要全新的指标体系，不能照搬传统REST API的监控方法；第六，不要忘了Profiling这个利器，它是从“看到问题”到“定位根因”的关键桥梁。

另外，关于你提到的prometheus_fastapi_instrumentator，我其实想吐槽一下它的默认配置。那个库默认会暴露fastapi_request_size_bytes和fastapi_response_size_bytes这两个指标，但在AI服务里，请求和响应的body往往很大（比如几千个token的文本），这两个指标在Prometheus里存储的成本很高，而且对诊断问题帮助不大。我建议关掉它们，或者只保留fastapi_request_duration_seconds、fastapi_requests_total和fastapi_responses_total，其他的自定义指标自己写，这样更灵活，也避免Prometheus的存储被无意义的数据撑爆。

gpu显存碎片化这个坑太真实了，我之前也是光盯着QPS看，结果模型推理偶尔超时根本查不出原因。想问下你后来是怎么监控显存碎片化程度的？是直接采集nvidia-smi的指标，还是自己写了探针去算内存分配耗时？

同感，默认的HTTP指标在AI场景下确实容易误导人，QPS和延迟正常但模型推理变慢的情况我也遇到过。后来我在自定义指标里加了token生成速率和显存占用率，定位问题的效率明显提升。另外想问下，你在处理高并发时，prometheus_fastapi_instrumentator的性能开销大概有多大？我这边偶尔会出现指标采集阻塞业务请求的情况。

这个自定义指标的思路确实很实用，尤其是GPU显存碎片化那个案例太真实了，光看QPS和延迟根本发现不了问题。想问下，token生成速率和缓存命中率这类指标，你们是直接用prometheus_client的Gauge和Histogram自己写的埋点，还是有什么现成的封装库推荐？

这帖子写得挺实在，看得出是真在生产环境里摸爬滚打过的。你提到的几个点，尤其是“别只盯着QPS”，我深有同感。说实话，我早期带团队做AI服务监控的时候，也犯过类似的错误，觉得只要把QPS、延迟和错误率这三个黄金指标搞定，系统就稳了。结果呢？上线第一个月就出了个大问题——用户反馈模型回答质量突然下降，但我们的监控面板一片绿，QPS平稳，延迟甚至还有点下降。这就很诡异了。

后来排查了一整天，才发现是输入数据的分布变了。我们的NLP模型是在英文语料上训练的，但那天有个大客户的业务场景突然切换成了大量中英文混杂的文本。模型推理耗时其实没变，但因为输入长度变长、词汇OOV增多，导致生成的结果质量大幅下降。而我们的监控只盯着接口层的指标，完全没感知到模型内部的变化。这件事让我彻底意识到，AI服务的监控和传统Web服务的监控有本质差异——你不仅要看到请求进来了、处理了、返回了，还要看到模型“怎么想的”、“累不累”、“有没有跑偏”。

所以回到你提到的几个自定义指标，token生成速率、缓存命中率、请求队列长度，这几个确实是非常关键的。我补充一下我的实操经验。

先说token生成速率。对于生成式模型（比如GPT类），这个指标比单纯的QPS重要太多了。QPS只能告诉你每秒处理了多少个请求，但同一个请求返回100个token和返回1000个token，对后端资源的消耗是天壤之别。我们曾经在一个对话机器人项目里，把token生成速率拆成了两个维度：一个是每秒生成的token总数，另一个是每个请求的平均token生成速度。前者用来衡量GPU集群的整体吞吐，后者用来感知单个用户的体验。有一次我们发现平均token生成速度突然从50 tok/s掉到了10 tok/s，QPS反而没怎么变，说明系统在处理大量短请求，但每个请求的生成效率极低。后来发现是模型量化精度在某个batch size下触发了CUDA kernel的次优分支，导致推理效率骤降。没有这个指标，我们可能还在傻乎乎地加GPU节点。

再说缓存命中率。这个指标在AI服务里往往被低估。很多团队觉得模型推理是计算密集型，缓存意义不大。但实际上，如果你的服务有重复的用户输入（比如常见的FAQ类问题），或者有相似上下文的多轮对话，缓存命中率能直接告诉你你的缓存策略是否有效。我在一个RAG（检索增强生成）系统里，把缓存分了两层：一层是向量数据库的embedding缓存，另一层是LLM生成结果的缓存。我们监控发现，LLM生成结果的缓存命中率长期低于5%，而embedding缓存命中率高达70%。这说明用户的问题虽然重复度高，但检索出来的文档片段差异大，导致LLM每次都要重新生成。后来我们改成了基于语义相似度的缓存策略，把命中率提到了30%左右，延迟直接降了一个量级。这个指标如果只看HTTP层面的缓存命中，根本看不出来。

关于你提的第一个问题，分布式推理场景下用Histogram量化P99延迟避免聚合误差，这个确实是个经典坑。Prometheus的Histogram在客户端就会做分桶聚合，所以当你有多实例时，服务端聚合求和是没问题的，但分桶的边界设置至关重要。我见过很多团队直接用默认的buckets，比如[0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10]，这对于AI推理场景来说太粗糙了。因为AI推理的延迟往往集中在几百毫秒到几秒之间，而且尾部延迟的分布很陡峭。比如你的P99是2秒，但P99.9可能直接跳到10秒，如果你在5秒和10秒之间只有一个桶，那P99的估算误差会非常大。

我的做法是：先用日志或者tracing系统跑一个离线分析，搞清楚你服务延迟的真实分布，然后动态设置buckets。比如如果大部分请求在200ms到800ms之间，那我会在200ms到1s之间每50ms设一个桶，1s到5s之间每200ms设一个桶，5s以上再放宽。这样既能保证P50和P90的精度，也能捕捉到尾部异常。另外，建议不要只依赖Histogram算P99，同时配合Summary使用。Summary在客户端直接计算分位数，避免了聚合误差，但代价是不能跨进程聚合。所以一个折中方案是：用Histogram做全局趋势监控，用Summary做每个实例的精确P99告警。这样告警比较准，趋势图又不会因为实例数变化而失真。

第二个问题，模型版本号作为标签是否对A/B测试有意义。我的答案是：非常有意义，但要注意标签基数的爆炸。我们当时做一个推荐模型迭代，一天上线了三个版本，每个版本在prometheus里加一个version标签。结果一周之后，version标签的基数就超过了100个（因为每次微调都会生成新版本）。Prometheus的标签基数是有限制的，超过一定量会导致内存暴涨和查询性能下降。我们的解决方法是：不把具体的版本号（比如v1.0.3）作为标签，而是把实验组ID和对照组ID作为标签。比如一个A/B测试有两个实验组，我们就设experiment_group=control和experiment_group=variant_a。这样每个实验的标签基数固定为2，可以长期监控。同时，把模型版本号放在日志或trace的span属性里，需要精细分析时再关联查询。这样既保证了监控的实时性，又避免了对Prometheus的压力。

你提到LNMP式的监控模型，日志、指标、追踪、Profiling，这个我非常赞同。而且我觉得对于AI服务，还有一个维度需要加进去：数据质量。我见过很多团队把模型部署上线后，模型指标（比如准确率、召回率）和系统指标（比如CPU、内存）是割裂的。出了问题，运维说是模型的问题，算法说是数据的问题，数据工程师说是系统的问题，互相扯皮。后来我们做了一个“模型健康度”的Dashboard，把系统指标、模型指标、数据质量指标放在一起。比如当GPU利用率突然下降时，同时看输入数据的长度分布是否突变、模型输出的困惑度是否飙升。这样一眼就能看出是数据分布漂移导致模型推理异常，还是系统资源被抢占。

关于社区对ML-specific告警规则支持弱的问题，我深有体会。目前Prometheus的告警规则主要还是基于阈值和趋势，比如“延迟大于2秒告警”、“错误率大于5%告警”。但模型漂移检测需要更复杂的统计方法，比如PSI（群体稳定性指标）、KS检验、或者基于时间序列的异常检测。我们目前的做法是：写一个Python脚本，定期从Prometheus拉取模型输出的分布数据（比如预测类别的概率分布），计算PSI，然后通过Pushgateway推回Prometheus，再基于这个PSI指标设置告警。虽然绕了一圈，但至少能跑起来。我最近也在关注一些开源方案，比如Whylogs和Evidently AI，它们可以和Prometheus集成，但成熟度还不够，需要自己写一些适配代码。

最后我想补充一个容易被忽略的点：监控指标的语义一致性。很多团队在定义自定义指标时，同一个指标在不同服务里的命名、单位、标签含义都不一样。比如推理时间，有的服务叫inference_time_ms，有的叫model_duration_seconds，导致后期做跨服务分析时非常痛苦。我们后来在团队内推行了一个“指标命名规范”，要求所有AI服务必须遵循统一的命名空间和标签规则，比如所有模型推理时间统一叫ai_inference_duration_seconds，单位必须是秒，标签必须包含model_name、model_version（按上面说的实验组方式）、input_type。这个规范一开始推行时大家觉得麻烦，但半年后回头看，跨服务的根因分析效率提升了至少两倍。

总的来说，AI服务的监控是一个系统工程，不是装个prometheus_fastapi_instrumentator就完事了。它需要你从模型特性、业务场景、系统架构三个维度去设计指标，并且要接受一个事实：没有一套通用的监控方案能适配所有AI服务。你必须在实践中不断迭代，就像你发现问题后加gpu_memory_usage和inference_time_per_token一样，这种“吃一堑长一智”的经验才是最宝贵的。希望这些分享能给你提供一些新的思路。