PLFM_RADAR：大模型推理服务质量监控与异常告警实践

如果你负责的大模型服务出了这么一个问题GPU利用率、QPS、P95延迟全部正常但业务方突然反馈“模型最近变蠢了”你会怎么排查我遇到过好几回。传统监控只能回答“机器有没有事”回答不了“模型是不是在好好干活”。PLFM_RADAR 就是我针对这个问题做的项目——围绕预训练语言基础模型PLFM推理服务搭建一套类似雷达扫描的可观测与预警系统持续盯着输出质量、语义状态、性能指标发现问题直接告警。无论你是做 RAG 应用、Agent 服务还是自己微调模型对外提供服务这套思路都可以直接借鉴。这篇文章会把项目从指标设计、异常检测、雷达图可视化到告警联动完整拆一遍中间穿插不少踩坑记录。内容偏向工程落地适合已经跑通了大模型基础服务的工程师也适合准备给团队建设模型监控体系的朋友。项目本身没有用太重的架构基本都是 Python 脚本加轻量存储组合出来的复制成本不高。1. 模型服务监控的盲区为什么传统指标救不了PLFM1.1 传统可观测性栈看到了什么漏掉了什么做传统后端监控很多年的人对 CPU、内存、磁盘 IO、QPS、错误码这套东西是有肌肉记忆的。但大模型服务不太一样。我维护 PLFMPre-trained Language Foundation Model预训练语言基础模型推理服务的时候最常被问的一句话是“线上没问题吧”。如果只看基础设施指标我通常只能回答“没问题”。直到有一次用户反馈模型回答质量断崖式下跌我查了一遍 GrafanaCPU 平稳、显存平稳、QPS 平稳、平均延迟还下降了——指标一切正常。问题出在哪出在模型本身“不停地在生成错误答案”而生成错误答案的性能开销可能比正确答案还小。这就是传统可观测性栈在大模型场景下的核心缺口它记录的是“机器状态”不是“模型行为”。一个推理服务即使进程活着、GPU 打满、请求全部 200模型也可能在重复输出、偏离指令、忘记上下文、甚至生成一堆法律上不能用的幻觉内容。这些都不会直接反应在节点指标上只会让业务方觉得“效果变差了”。原因在于传统监控的采集对象是操作系统和运行框架暴露的数值而模型输出质量这种“语义状态”需要额外一层检测才能变成可观察、可告警的指标。所以你要建的不是又一个 Prometheus exporter而是一条覆盖“输入—推理—输出—下游反馈”全链路的行为采集和分析通道。这也是 PLFM_RADAR 最开始立项的原因。1.2 PLFM服务的四类高频异常模式在系统设计之前先把线上实际遇到过的异常归纳了一下基本可以收敛成四类。第一类是上下文漂移。多轮对话场景里系统指令被用户输入覆盖、历史记忆被截断、模型开始用错角色说话这类问题在长会话里尤其常见。表现是单轮回答本身没什么语法错误但整体感觉“不在状态”。第二类是输出格式坍塌。要求模型返回 JSON它偏偏在前面加一句解释要求输出数组它返回一个对象或者字段名从name变成了Name。这类问题看似小但对下游系统是毁灭性的一个解析异常就能让整条链路失败。第三类是内容风险与幻觉。模型一本正经地给出虚假信息、编造引用来源、或者生成明显不合规的内容。这是最麻烦的一类因为传统指标彻底感知不到。第四类是性能突变。不是指普通的负载上升而是 TTFT首 Token 延迟突然恶化、吞吐掉底、请求排队时间暴涨通常伴随着模型版本切换、显存碎片化或并发参数配置不合理。我用下面这个表格梳理了“传统指标能否发现”的情况异常类型典型现象节点指标能否发现需要的行为指标上下文漂移回答跑题、角色错乱、遗忘指令不能语义一致性、上下文覆盖度输出格式坍塌JSON 解析失败、字段缺失通常不能格式合法率、schema 匹配度幻觉与内容风险编造事实、引用不存在不能事实一致性、安全规则命中性能突变TTFT 暴涨、吞吐下降部分能TTFT、TPOT、队列积压结论很清楚要监控 PLFM 服务必须把“语义质量”和“输出合规性”也变成指标。1.3 RADAR不是玄学是四个动作的缩写给项目命名时我刻意把 RADAR 拆成了四个模块Reliability可靠性、Anomaly Detection异常检测、Alert告警、Review复盘。为什么要这样拆因为一个真正能用的监控系统光有检测是不够的。检测出来没有通知等于白做通知了没有复盘入口下次照样踩坑。这四个动作正好形成一个闭环。雷达的隐喻也有意义。飞机雷达持续扫描周围空域发现危险目标并提示飞行员。PLFM_RADAR 做的也是这件事持续扫描每一个请求和输出的行为特征发现偏离正常模式的“目标”然后提示值班人员。它不追求像可观测性平台那样把全量日志都存下来而是追求“及时发现问题并且能解释为什么有问题”。2. PLFM_RADAR系统骨架采集、量化、存储与展示2.1 采集层在请求路径上装“行为记录仪”整个系统的第一个关键点是采集哪些数据。我选择在服务入口和出口分别埋点拦截请求体和响应体同时记录耗时、Token 用量、状态码等元信息。实际项目里我用 FastAPI 中间件做了一版最简实现import time import json from fastapi import Request async def capture_request(request: Request, call_next): start time.perf_counter() body await request.body() response await call_next(request) duration_ms (time.perf_counter() - start) * 1000 resp_body b async for chunk in response.body_iterator: resp_body chunk record { ts: int(time.time()), app: request.headers.get(x-plfm-app, default), prompt: body.decode(utf-8, errorsignore)[:2000], response: resp_body.decode(utf-8, errorsignore)[:2000], duration_ms: round(duration_ms, 2), status_code: response.status_code, prompt_len: len(body), resp_len: len(resp_body), } write_record_to_queue(record) return response注意几个细节。write_record_to_queue一定要用异步队列或后台线程批量写不能在请求路径上同步刷盘否则监控系统反而拖垮业务延迟。加了中间件之后线上服务 P95 延迟增加了不到 2%这个损耗基本可以接受。对于已经接入 vLLM、TGI 或 OpenAI 兼容接口的团队还有一个更省事的办法直接复用推理框架自带的 metrics 端点再通过 LangChain 的回调系统把 prompt、response 和 token 用量捞出来。两类数据一个管资源一个管行为正好互补。采集层的关键原则是“不漏关键字段、不存全量原文、不阻塞主流程”。2.2 分析层从原始事件到五维健康指标采集到的原始日志不是指标必须经过一个量化过程。PLFM_RADAR 把每个请求映射到五个维度格式可靠性、语义一致性、性能健康度、内容安全性、成本效率。格式可靠性怎么算对输出做一层轻量校验如果是 JSON用解析器直接解析解析失败记 0 分成功且字段齐全记 1 分如果要求列表、纯文本也有对应的规则。这一项是最容易实现的但价值很高因为它能抓住大量“模型看似正常、实际不可用”的情况。语义一致性稍微复杂一点。我用了两种方法一是对输入和输出做向量化计算输入 prompt 的指令向量与输出语义向量的余弦相似度二是计算输出文本的困惑度perplexity异常时困惑度会明显升高。实测下来困惑度对“重复输出”和“乱码”非常敏感但对“有逻辑的错误回答”无能为力所以只能作为辅助信号。性能健康度不是直接拿一个延迟值而是把 TTFT、TPOT、总时长分别归一化到 0-1 区间再合成一个分数。安全性和成本就相对简单安全性可以用关键词规则或独立安全模型打分成本则直接按 Token 单价折算。最后每个维度合成一个五维向量比如一个请求的画像可能是{ format: 1.0, semantic: 0.87, performance: 0.92, safety: 1.0, cost: 0.76 }这个向量就是雷达图上的一个点。一次会话或者一个时间窗口内把多个请求汇总成均值就成了可追踪的趋势指标。2.3 存储与展示层开始别上ESSQLite够用很多朋友一听到要存请求日志第一反应是上 Elasticsearch。我劝你冷静特别是项目刚起步的时候。按日均 10 万请求算每条日志 2KB一天才 200MBSQLite 完全扛得住Parquet 文件也能扛。ES 的部署、调优、运维成本在这个量级下纯属浪费。PLFM_RADAR 的存储方案很朴素核心指标写入 SQLite 的一张宽表原始请求和响应用 JSON 压缩后按月分文件存。查询历史趋势直接 SQL分析异常样本直接读 Parquet。等真到了日请求千万级再迁移 ClickHouse 也不迟而且迁移成本很低因为指标模型早就定好了。展示层我选的是 Streamlit因为迭代快、不需要前端团队介入。页面上放三个板块实时雷达图、趋势折线、最近异常样本列表。每次刷新页面能看到过去 5 分钟的服务健康画像和前十异常请求。这个组合撑住了我这边半年多的日常监控需求。3. 动态异常检测的实现基线、EWMA与误报抑制3.1 固定阈值为什么在大模型场景下不适用最早我偷懒给 TTFT 设了一个固定告警阈值超过 3000 毫秒就报警。结果两个星期内被打脸。同一个模型处理一个十来个字的简单问答和一个上千字的长文档分析TTFT 差了 5 倍都不止。如果阈值按简单请求设长文档请求天天告警按长文档设简单请求真出问题时完全漏报。固定阈值还有一个更隐蔽的问题模型的负载是随时间变化的早高峰和深夜的延迟基线完全不同。同一个阈值在深夜可能算正常在早高峰可能就是故障。所以必须用动态基线让阈值跟着历史数据走。3.2 基于EWMA的动态基线EWMAExponential Weighted Moving Average指数加权移动平均是我在这个项目里用得最多的动态基线算法。它的思想很简单给近期观测更高的权重给远期观测指数衰减的权重这样基线能跟上缓慢漂移又不会被单个尖峰带偏。下面是 PLFM_RADAR 里的核心实现import numpy as np class EWMABaseline: def __init__(self, alpha0.15, warmup20, z_threshold3.0): self.alpha alpha self.warmup warmup self.z_threshold z_threshold self.mean None self.m2 0.0 self.n 0 def update(self, value): if self.mean is None: self.mean value self.m2 0.0 self.n 1 return False self.n 1 diff value - self.mean self.mean self.alpha * diff self.m2 (1 - self.alpha) * (self.m2 self.alpha * diff * diff) if self.n self.warmup: return False std np.sqrt(self.m2) z_score abs(diff) / (std 1e-9) return z_score self.z_threshold用的时候把 TTFT、格式得分、语义相似度这些指标分别喂给各自的 EWMA 实例。每次拿到新观测值先更新基线看当前值和基线的偏差是否超过 3 倍标准差。超过就标记为异常。alpha 我用 0.15这个值对分钟级监控比较合适太大则基线波动太剧烈太小则对真实漂移反应太慢。提示EWMA 对“缓慢漂移偶发尖峰”的组合效果最好。如果你的指标有明显周期性比如每天固定时段的流量洪峰建议先做周期化处理再套 EWMA否则早晚被周期波动淹没。3.3 误报抑制的工程技巧动态基线可以降低误报但不能消除误报。实际运营中最烦的是告警疲劳第一天收到 50 条告警每条都鸡毛蒜皮第二天你就不想看了真出问题时反而没人理。PLFM_RADAR 处理这个问题的思路是三层抑制。第一层是联动判定。单个指标异常不告警必须两个以上独立维度同时异常才拉高严重级别。比如 TTFT 飙高但格式得分、错误率都正常很可能只是网络波动或单次调度问题如果 TTFT 飙高同时格式得分暴跌说明模型服务大概率出了实质问题。这一条能过滤掉至少一半无意义告警。第二层是冷却窗口。同一个告警主体比如某个 app 的上下文漂移指标30 分钟内只发一次通知。后续继续异常只更新告警状态不重复轰炸。第三层是等级分级。用 WARN 和 CRITICAL 区分严重程度具体判定规则如下级别触发条件响应方式WARN单维度 z-score 连续 3 个窗口超限记录不通知次日复盘CRITICAL两个以上维度同时超限或健康总分跌破 0.6立即通知值班人紧急健康总分跌破 0.4或连续 5 分钟结构性异常调用紧急响应流程暂停灰度流量加了这三层之后告警量直接从日均几十条降到了每周几条而且留下来的基本都是真问题。4. 雷达图可视化与告警闭环把健康度画成人能看懂的形状4.1 雷达图不是装饰是“形状语言”雷达图的优势在于它把五个维度的状态压缩成一个多边形人眼可以瞬间感知“形状是否正常”。一个健康的 PLFM 服务画出来是饱满的五边形所有维度分数都在 0.8 以上如果某个角凹进去一眼就能看出哪个维度劣化。绘图代码很简单用 matplotlib 的 polar 坐标import matplotlib.pyplot as plt import numpy as np def draw_radar(labels, values, save_path): angles np.linspace(0, 2 * np.pi, len(labels), endpointFalse).tolist() values values values[:1] angles angles[:1] fig, ax plt.subplots(figsize(6, 6), subplot_kwdict(polarTrue)) ax.fill(angles, values, colorskyblue, alpha0.4) ax.plot(angles, values, colorsteelblue, linewidth2) ax.set_xticks(angles[:-1]) ax.set_xticklabels(labels) ax.set_ylim(0, 1) plt.tight_layout() plt.savefig(save_path, dpi150) plt.close()我把这个函数放在一个定时任务里每 5 分钟生成一次当前健康画像同时保留上一张做对比。雷达图不需要很复杂关键是能快速回答三个问题现在还健康吗哪个维度出了问题跟半小时前比是变好还是变差4.2 综合健康度评分怎么算才不打架五个维度各自是 0-1 的分数要合成一个总分最简单是加权平均。但权重不能拍脑袋需要结合业务场景。PLFM_RADAR 默认权重是这样health_score (0.30 * format_score 0.25 * semantic_score 0.20 * performance_score 0.15 * safety_score 0.10 * cost_score)格式可靠性权重最高因为实践里格式错误对线上稳定性的杀伤力最大语义一致性次之它直接反映模型“干没干正事”性能排在第三但这里用的是相对基线健康度不是绝对延迟。内容安全性权重不高是因为大部分请求本身不涉及高风险场景一旦涉及就需要独立的高优告警通道而不是混在总分里。这个权重不是固定的。客服机器人我会调高 safety 到 0.25压科研助手会把 semantic 提到 0.35。每个团队都应该花一到两周收集线上 badcase反推自己业务里哪些维度更值钱。4.3 告警通知从雷达图缩水到飞书/钉钉消息告警通知我接了飞书机器人核心逻辑是拿到异常指标后拼接一条带雷达面积变化和劣化维度的消息。飞书 Webhook 推送用 requests 简单搞定import requests def send_feishu(webhook: str, title: str, content: str): payload { msg_type: text, content: {text: f{title}\n{content}} } try: requests.post(webhook, jsonpayload, timeout5) except Exception as exc: # 通知失败不能阻塞主流程 log_error(exc)通知内容模板长这样【PLFM_RADAR CRITICAL】 应用customer-service 雷达面积0.82 - 0.51 劣化维度semantic(0.87-0.52), performance(0.91-0.63) 时间窗口14:30 - 14:35 建议动作查看最近 20 条低分样本重点排查 prompt 指令变化这种消息值班人能直接看懂。注意通知发送本身要捕获异常告警通道挂掉不重要重要的是不能反过来让告警服务拖垮主进程。4.4 离线趋势与复盘光有实时告警还不够我每周会拉一次离线趋势把雷达面积按天画成折线。雷达面积可以从多边形面积公式算也可以用五维分数均值近似。面积持续缩小的那个星期一定对应了线上某次变更或 prompt 改动。这个规律我已经验证了好几次。复盘面板我用 Streamlit 做了一个简单的表格日期、平均雷达面积、五个维度各自均值、前三差指标样本 ID。到时候直接点样本 ID 看原始输入输出判断是模型问题、提示词问题还是数据问题。这个“从指标到样本”的链路比任何漂亮的大盘都有用。5. 踩坑记录上下文漂移、幻觉检测与流式延迟的真实表现5.1 上下文漂移检测的相似度阈值是个大坑最开始时侯上下文漂移用“当前轮 prompt 向量与历史 prompt 向量做余弦相似度”低于一个阈值就认为漂移。听起来很合理实际用起来全是坑。有一次线上告警一堆“上下文漂移”我打开样本一看全是正常的业务问题。比如用户先问“发货时间”然后说“那价格呢”两轮问题主题变了相似度自然掉到 0.5 以下。这个不是模型漂移是用户话题切换。后来把检测拆成三层系统指令和用户输入分别做向量化再比较“系统指令相关度”和“用户意图延续度”。系统指令相关度下降才是真漂移用户意图变化只是对话正常演进。阈值也不能一刀切长短对话分开建基线和阈值。改完之后误报率降了 70%。5.2 幻觉检测的双刃剑幻觉检测我最初试着用 NLI自然语言推理模型做把输入上下文作为 premise模型回答作为 hypothesis如果推理结果是 contradiction就判为幻觉。效果在小样本上很好上线后问题不少。首先是长文本场景。一个回答包含七八个事实点NLI 对其中一两个点 contradict 就会整体判负但模型其他部分其实是对的全部归为幻觉太粗暴。其次 NLI 对否定句处理很差回答“没有证据表明 X”时模型经常把它和原文混淆。混合中英文的内容更离谱误判率直线上升。我的优化方案是先把长回答按句子切分逐句做 NLI 判断再汇总成“幻觉严重比例”。阈值也从固定 0.5 改为动态基线。现在这个指标更多是趋势参考而不是直接告警条件——因为在真正的事实性校验场景还是要接知识库或搜索引擎做证据验证NLI 顶多能当预警器。5.3 流式与非流式延迟指标不能混在一起这是我在告警配置上栽过的最惨一次。当时给“响应总时长”设了动态基线结果灰度期间告警风暴。排查半天发现灰度版本默认开启了流式输出流式请求的第一个 chunk 可能在 200ms 就返回了但总时长要等所有 token 生成完TPS 和总时长的统计口径跟非流式完全不同。把流式和非流式请求混在一个基线里等于拿苹果和橘子比大小。修正方式是拆成两套指标TTFT 用于衡量“首字节响应”TPOT每个 token 的平均输出时间和总耗时分别建基线。同时增加一个请求方式标签所有基线按标签隔离。调整后流式场景的延迟异常检测才真正可用。5.4 JSON格式坍塌的一个具体案例有一次下游反馈解析成功率骤降我查雷达图发现 format 分从 0.95 跌到 0.3但业务 QPS、错误码完全没变化。模型输出的 JSON 偶尔会多一行json前缀导致解析器直接报错。这里有一个反直觉的点模型输出的 token 数变多了推理延迟反而略微下降因为 JSON 前缀非常模板化生成起来没有计算负担。所以性能指标完全没报警只有格式检测能抓住。后来做了两层处理一层是解析前先做代码块剥离和首尾去噪另一层是在 prompt 里明确“不要输出任何解释或代码块标记”。比较讽刺的是提示词优化只能降概率兜底解析逻辑才是真正阻止问题扩大的手段。这也是我把格式可靠性权重设最高的原因。6. 还能往哪里扩展多模型对比、RAG质量与A/B实验6.1 多模型雷达图叠加选型与灰度的直观工具PLFM_RADAR 的雷达图画法天然支持多模型叠加。我在做模型选型时会把同一个 prompt 集合分别发给候选模型每个模型生成一组五维分数画在一张雷达图里对比。比如 A 模型性能和成本分高但语义一致性低B 模型语义拉满但格式容易崩。这种对比比单纯看离线评测指标直观得多因为离线评测只有平均分看不到维度间失衡。灰度切换期间也可以把线上新老模型的雷达图实时叠在一起一旦灰度模型的雷达面积明显小于老模型立刻暂停灰度用数据说话而不是等业务方投诉。6.2 把RAG检索质量纳入雷达视野如果应用是 RAG 架构建议在采集层额外记录检索结果数量、命中文档的向量相似度、重排分数。把“检索命中后模型回答的相关性”也作为语义一致性的一部分。通常场景是检索返回了一堆无关文档模型再强也回答不好。不监控检索质量就会把 RAG 链路的问题误判成模型问题。PLFM_RADAR 当前版本把检索相关度单独存了一个字段未来计划扩展成“RAG 质量雷达”在原来的五个维度上增加检索命中率和引用准确度两个维度变成七维雷达。这个方向对做知识库问答的团队尤其有价值。6.3 我对这类监控系统的一点个人体会做 PLFM_RADAR 这半年最大的体会是模型服务的监控难题本质上不是技术问题而是“你能不能定义什么是正常”。传统监控的标准定义是资源阈值大模型场景的标准定义必须包含语义和格式。定义得越清晰自动化才越有意义。如果只能带走一个经验我建议从格式可靠性这个维度开始做。它最容易量化、最容易被下游感知、也最能快速体现监控系统的价值。等你把格式、延迟、成本几项跑顺了再逐步加语义相关性和内容安全难度梯度非常平滑。最后分享一个实用小技巧每天定时把雷达图存成 PNG放到一个只保留 30 天的目录里。复盘时看图形变化比翻 JSON 日志直观太多。我们已经连续三个月靠这个习惯提前发现了两轮模型质量退化都是在业务方感知之前搞定的。这套路不复杂贵在踏实把事情做透。