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

如果你负责的大模型服务出了这么一个问题：GPU利用率、QPS、P95延迟全部正常，但业务方突然反馈“模型最近变蠢了”，你会怎么排查？我遇到过好几回。传统监控只能回答“机器有没有事”，回答不了“模型是不是在好好干活”。PLFM_RADAR 就是我针对这个问题做的项目——围绕预训练语言基础模型（PLFM）推理服务，搭建一套类似雷达扫描的可观测与预警系统，持续盯着输出质量、语义状态、性能指标，发现问题直接告警。无论你是做 RAG 应用、Agent 服务，还是自己微调模型对外提供服务，这套思路都可以直接借鉴。

这篇文章会把项目从指标设计、异常检测、雷达图可视化到告警联动完整拆一遍，中间穿插不少踩坑记录。内容偏向工程落地，适合已经跑通了大模型基础服务的工程师，也适合准备给团队建设模型监控体系的朋友。项目本身没有用太重的架构，基本都是 Python 脚本加轻量存储组合出来的，复制成本不高。

1. 模型服务监控的盲区：为什么传统指标救不了PLFM

1.1 传统可观测性栈看到了什么，漏掉了什么

做传统后端监控很多年的人，对 CPU、内存、磁盘 IO、QPS、错误码这套东西是有肌肉记忆的。但大模型服务不太一样。我维护 PLFM（Pre-trained Language Foundation Model，预训练语言基础模型）推理服务的时候，最常被问的一句话是“线上没问题吧？”。如果只看基础设施指标，我通常只能回答“没问题”。直到有一次用户反馈模型回答质量断崖式下跌，我查了一遍 Grafana：CPU 平稳、显存平稳、QPS 平稳、平均延迟还下降了——指标一切正常。问题出在哪？出在模型本身“不停地在生成错误答案”，而生成错误答案的性能开销可能比正确答案还小。

这就是传统可观测性栈在大模型场景下的核心缺口：它记录的是“机器状态”，不是“模型行为”。一个推理服务即使进程活着、GPU 打满、请求全部 200，模型也可能在重复输出、偏离指令、忘记上下文、甚至生成一堆法律上不能用的幻觉内容。这些都不会直接反应在节点指标上，只会让业务方觉得“效果变差了”。原因在于传统监控的采集对象是操作系统和运行框架暴露的数值，而模型输出质量这种“语义状态”需要额外一层检测才能变成可观察、可告警的指标。

所以你要建的不是又一个 Prometheus exporter，而是一条覆盖“输入—推理—输出—下游反馈”全链路的行为采集和分析通道。这也是 PLFM_RADAR 最开始立项的原因。

1.2 PLFM服务的四类高频异常模式

在系统设计之前，先把线上实际遇到过的异常归纳了一下，基本可以收敛成四类。

第一类是上下文漂移。多轮对话场景里，系统指令被用户输入覆盖、历史记忆被截断、模型开始用错角色说话，这类问题在长会话里尤其常见。表现是单轮回答本身没什么语法错误，但整体感觉“不在状态”。

第二类是输出格式坍塌。要求模型返回 JSON，它偏偏在前面加一句解释；要求输出数组，它返回一个对象；或者字段名从name变成了Name。这类问题看似小，但对下游系统是毁灭性的，一个解析异常就能让整条链路失败。

第三类是内容风险与幻觉。模型一本正经地给出虚假信息、编造引用来源、或者生成明显不合规的内容。这是最麻烦的一类，因为传统指标彻底感知不到。

第四类是性能突变。不是指普通的负载上升，而是 TTFT（首 Token 延迟）突然恶化、吞吐掉底、请求排队时间暴涨，通常伴随着模型版本切换、显存碎片化或并发参数配置不合理。

我用下面这个表格梳理了“传统指标能否发现”的情况：

结论很清楚：要监控 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", errors="ignore")[:2000], "response": resp_body.decode("utf-8", errors="ignore")[: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 存储与展示层：开始别上ES，SQLite够用

很多朋友一听到要存请求日志，第一反应是上 Elasticsearch。我劝你冷静，特别是项目刚起步的时候。按日均 10 万请求算，每条日志 2KB，一天才 200MB，SQLite 完全扛得住，Parquet 文件也能扛。ES 的部署、调优、运维成本在这个量级下纯属浪费。

PLFM_RADAR 的存储方案很朴素：核心指标写入 SQLite 的一张宽表，原始请求和响应用 JSON 压缩后按月分文件存。查询历史趋势直接 SQL，分析异常样本直接读 Parquet。等真到了日请求千万级，再迁移 ClickHouse 也不迟，而且迁移成本很低，因为指标模型早就定好了。

展示层我选的是 Streamlit，因为迭代快、不需要前端团队介入。页面上放三个板块：实时雷达图、趋势折线、最近异常样本列表。每次刷新页面，能看到过去 5 分钟的服务健康画像和前十异常请求。这个组合撑住了我这边半年多的日常监控需求。

3. 动态异常检测的实现：基线、EWMA与误报抑制

3.1 固定阈值为什么在大模型场景下不适用

最早我偷懒，给 TTFT 设了一个固定告警阈值：超过 3000 毫秒就报警。结果两个星期内被打脸。同一个模型，处理一个十来个字的简单问答和一个上千字的长文档分析，TTFT 差了 5 倍都不止。如果阈值按简单请求设，长文档请求天天告警；按长文档设，简单请求真出问题时完全漏报。

固定阈值还有一个更隐蔽的问题：模型的负载是随时间变化的，早高峰和深夜的延迟基线完全不同。同一个阈值在深夜可能算正常，在早高峰可能就是故障。所以必须用动态基线，让阈值跟着历史数据走。

3.2 基于EWMA的动态基线

EWMA（Exponential Weighted Moving Average，指数加权移动平均）是我在这个项目里用得最多的动态基线算法。它的思想很简单：给近期观测更高的权重，给远期观测指数衰减的权重，这样基线能跟上缓慢漂移，又不会被单个尖峰带偏。

下面是 PLFM_RADAR 里的核心实现：

import numpy as np class EWMABaseline: def __init__(self, alpha=0.15, warmup=20, z_threshold=3.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 区分严重程度，具体判定规则如下：

加了这三层之后，告警量直接从日均几十条降到了每周几条，而且留下来的基本都是真问题。

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), endpoint=False).tolist() values = values + values[:1] angles += angles[:1] fig, ax = plt.subplots(figsize=(6, 6), subplot_kw=dict(polar=True)) ax.fill(angles, values, color="skyblue", alpha=0.4) ax.plot(angles, values, color="steelblue", linewidth=2) ax.set_xticks(angles[:-1]) ax.set_xticklabels(labels) ax.set_ylim(0, 1) plt.tight_layout() plt.savefig(save_path, dpi=150) 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, json=payload, timeout=5) 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 日志直观太多。我们已经连续三个月靠这个习惯提前发现了两轮模型质量退化，都是在业务方感知之前搞定的。这套路不复杂，贵在踏实把事情做透。