大模型推理可观测与监控

• 核心指标的定义与采集方式
• 告警阈值的设定
• 指标与成本/质量的联动

TTFT（首 token 延迟）与 TPOT（每输出 token 时间）由推理引擎（vLLM/TGI）在请求粒度埋点，经 Prometheus 聚合为直方图（P50/P95/P99）；吞吐（tokens/s）与请求速率由引擎 metrics 或网关统计；token 成本在网关侧按输入/输出 token 数计量并归属业务。告警：TTFT 超阈值（如 P99 > 3s）告警，TPOT 反映生成速度（如 P99 > 100ms/token），吞吐与 GPU 利用率设下限避免浪费，token 成本设配额与环比告警。

推理指标强调 token 维度，且 TTFT 与 TPOT 需分开监控，因为前者反映首帧体验、后者反映生成流畅度。告警要分层：性能类（延迟/吞吐）、资源类（GPU利用率/显存）、成本类（token 配额）。采集需标注模型版本与业务线标签，才能做质量与成本归因。

• 实时计量的数据来源
• 按业务分摊的维度
• 成本报表与告警

实时计量在网关或推理引擎侧记录每个请求的输入/输出 token 数，结合模型单价（元/百万 token）计算出单次请求成本，并打上业务线、模型版本、租户等标签。分摊按业务线/应用维度聚合，得到各业务 token 消耗与成本。成本数据可写入时序库实时展示，并支持按天/周出报表、对成本突增告警。

计量核心是"token 数 × 单价"的准确采集与优雅归属。token 数要区分输入（prefill）与输出（decode）因为两者算力成本不同；单价按模型与部署形态（自建/托管）设置。分摊需强制标签治理，否则无法归因。运维上用成本环比/预算告警发现超支业务。

• 线上质量指标的可衡量性
• 埋点方式（反馈、自测、抽样评审）
• 质量与运营指标关联

线上难以直接衡量绝对幻觉率，但可通过代理指标与埋点近似：一是用户反馈埋点（点赞/踩、纠错、采纳率），作为最直接的质量信号；二是上下文内一致性自测（如可验证任务中答案与检索内容一致）；三是抽样人工评审（对少量流量做标注打分）；四是统计指标（重复生成率、空白输出率、refusal 率突变）。埋点需记录 model_version、prompt、completion 与采纳行为，供离线分析。

幻觉率是弱监督问题，线上指标只能做"信号"而非"真值"。实际做法是"多信号 + 抽查评审"：用户反馈与抽样评审提供校准，统计指标提供粗粒度预警。用这些信号做质量基线与回归告警，而非高精度幻觉检测。运维上把质量信号与成本、延迟统一观测。

• trace 的 span 设计（网关/队列/引擎）
• 流式 token 的追踪方式
• 排障关联（元数据、日志、指标）

端到端 trace 用统一 trace_id 贯穿应用、网关、队列与推理引擎各 span。流式 token 追踪需在 span 中记录首个 token 的时间、token 数、生成耗时与各流式事件，并关联输入输出（采样）。所有 span 带上 model_version、tenant、prompt_tokens 等属性，便于按模型/租户/版本过滤。排障时从 trace 定位发生在哪一跳（网关排队、prefill、decode、网络），结合日志与指标确认根因。

推理 trace 的特殊点是"Token 流是时间序列"，需记录 TTFT、TPOT 分布与流式事件（如连接中断、超时）。采样策略很关键——流式 token 量巨大，通常按请求全量保留元数据、按比例保留完整输入输出。trace 与日志、指标（红绿黄三信号）联动才能高效排障。

• 质量回归的信号来源
• 灰度对比与基线
• 早期预警机制

早期预警依赖"新旧版本并行对比 + 质量信号监控"：灰度期同时跑新版与旧版（或多版本 A/B），对比相同输入的输出质量信号——用户反馈率、采纳率、评审打分、可验证任务正确率、统计异常（重复/空输出）。设置质量基线（如反馈率、通过率）与偏差阈值，一旦新版本质量信号显著恶化即触发告警并自动回滚。用离线评测集在发布前做门禁，用线上信号做灰度期护栏。

质量回归预警的关键是"有质量的照妖镜"：既能与旧版对比，又能独立量化。灰度期是预警窗口，将线上信号与基线对比，比全量后才发现更早。运维上要建立"质量信号→告警→自动回滚"的闭环，避免新版本长期带病运行。

• 引擎内部指标暴露
• KV cache 与显存指标
• 调优与告警

vLLM/TGI 等引擎会暴露 Prometheus 指标：running/queued 请求数（continuous batching 队列深度）、KV cache 使用率（paged KV cache blocks used/total）、GPU 显存利用率与峰值、每个请求的 prefill/decode 耗时。通过 Prometheus 拉取并可视化。监控关注：队列积压（queued 长期高）→ 扩容或调并发；KV cache 利用率接近上限 → 长上下文压力大，可能 OOM；显存水位 → 预警碎片与 OOM。

引擎内部状态是"黑盒变白盒"的关键：队列深度反映调度压力，KV cache 利用率反映长上下文与并发压力，显存水位反映资源边界。这些指标帮助定位"是排队慢还是算力慢""是显存不足还是并发过高"。告警阈值需结合模型容量与并发预算设定。

• 三层指标的定义
• 层间关联与因果链
• 问题定位方法

三层指标构成因果链：资源级（GPU 利用率、显存）决定引擎级（吞吐、排队数）决定请求级（TTFT/TPOT、端到端延迟）。定位问题时自上而下：先看请求级延迟恶化，再查引擎级排队与吞吐是否饱和，最后看资源级 GPU 利用率/显存是否打满或碎片，从而判断瓶颈在"算力不足、排队过长"还是"显存/GPU 故障"。层间指标需关联（如 GPU 利用率高但吞吐低 → 可能 batch 填充差；GPU 利用率低但排队高 → 调度/队列问题）。

分层关联的价值是把"症状"归因到"根因"：请求级是用户体验，引擎级是调度，资源级是供给。单看某一层会误判。运维上建立"三层联动看板"，用同一时间轴对照指标变化，快速定位瓶颈层。

• 常见推理异常类型
• 规则检测与采样检测
• 检测到异常后的处理

常见异常包括重复生成（同一 token 反复循环）、截断（达到 max_tokens 被强行截断）、空输出、乱码等。检测方式：规则检测——对输出做启发式判断（如 n-gram 重复率超过阈值、连续重复子串、输出长度达到截断上限、含非法字符），在采样流量上实时跑；采样检测——对全量输出按比例采样，用正则/分类器/评测模型识别异常。异常率作为质量指标上报，超阈值告警并触发降级/回滚。

异常检测是"质量的第一道护栏"。规则检测轻量低成本，适合在线实时；采样检测更准但非实时。两者结合：在线规则做低延迟过滤，离线采样做深度分析。异常率与模型版本关联，可反向定位是新版本引入的回归。

• 队列积压与超时的监控
• 限流与降级策略
• 背压与削峰

实时发现通过监控队列深度（queued requests）、排队等待时间（waiting time）与请求超时率。当队列积压或等待时间超过阈值时，触发限流：拒绝新请求（返回 429）、降级（缩短输出、降低优先级）、或扩容。配合背压机制（gateway 感知下游队列状态，减缓放量）与削峰（队列异步缓冲）避免雪崩。限流要区分租户，优先保障高优先级请求。

队列积压是"吞吐不足"的先行信号，比延迟更早暴露。策略是"发现→限流→（扩容）"：先限流保护已有请求不被饿死，再决定是否扩容。用排队时间作为核心指标，而非单纯队列长度（长度要结合处理速率）。限流需分级，避免影响核心业务。

• 提示词注入的攻击特征
• 防护与监控手段
• 异常检测与溯源

提示词注入攻击（prompt injection）通过在输入中嵌入恶意指令诱导模型执行非预期行为。监控手段：输入过滤——检测 prompt 中的注入模式（如"忽略此前指令"、系统提示覆盖、危险指令）；输出侧检测——识别模型被诱导产出的异常输出（如泄露内部 prompt、越权行为）；限流与隔离——对异常来源 IP/用户限流、告警。建立注入样本库，用规则/分类器/LLM 安全检测模型识别，并记录攻击流量用于溯源。

提示词注入是 LLM 特有的安全风险，需输入+输出双侧监控。输入侧防注入，输出侧防越权。监控要结合告警与实时阻断，并留存样本迭代检测模型。运维上把安全拦截率作为 LLM 监控指标之一，与质量、成本并列。

• 对比监控的目标
• 输出差异的度量方法
• 差异告警与决策

灰度期将同一（或等价）输入同时发给新旧版本，对比输出差异。度量方法：语义相似度（embedding 余弦/SBERT）、事实一致性（对可验证任务比对正确率）、风格/长度差异、用户反馈差异。设置差异阈值——若新版本与旧版在质量指标上显著变差（如正确率下降、相似度骤降、反馈变差），触发告警并回滚。同时监控延迟、成本差异，综合决定是否全量。

对比监控的核心是"用相同输入做受控对照"，隔离模型版本这一个变量。度量需结合语义与任务正确性，不能只看文本相似度。灰度期输出差异监控是"新版本质量门禁"的线上阶段，与离线评测互补。

• ECC 错误与数据损坏
• NVIDIA 链路与温度降频
• 监测工具与告警

ECC 错误反映显存位翻转，可能造成推理结果错误（数据损坏），需通过 nvidia-smi/DCGM 监控 ECC 错误计数并区分可纠正/不可纠正；NVLink 状态异常会导致多卡通信错误与吞吐下降；温度过高触发降频（thermal throttling），降低算力与性能。监测用 DCGM exporter + nvidia-smi 采集 ECC 计数、NVLink 速率、温度与功耗，超阈值告警；不可纠正 ECC 错误增多时应隔离并更换 GPU。

GPU 硬件隐性故障会"悄悄影响质量"——ECC 错误导致输出错误但进程不崩。监测让隐性故障显性化。重点是 ECC 错误（纠正错误多预示退化）、温度降频（性能隐性下降）、NVLink（多卡一致性）。结合自动隔离与重启，防止坏卡长期带病。

• 各类告警的指标与阈值
• 告警分级与抑制
• 告警的连贯性

告警规则：延迟超时——TTFT/TPOT/端到端延迟 P99 超阈值（如 TTFT>3s、超时率>1%）告警；显存 OOM——OOM 事件计数/显存利用率>90% 告警；配额耗尽——各租户 token 配额使用率>90% 或达到限流告警；错误率突增——错误率对比基线上升（如环比 >50%）告警。告警分级（P1-P4）与抑制（同源合并、维护窗口忽略）避免告警疲劳，并设置自动处理（如 OOM 自动重启）。

好的告警要"可执行、不疲劳"。关键在阈值基于基线（环比/同比）而非固定值，减少误报；分级决定响应时效；抑制与聚合减少噪音。同时告警要自带 Playbook（处理方法），才能快速处置。

• 成本指标与单位
• GPU 利用率与成本的关系
• 账单核对与归因

每 token 成本 = 总成本 / 总 token 数，把成本与 GPU 利用率、实际 token 输出关联。GPU 利用率低提示资源浪费（成本高但产出少），tokens/sec/GPU 反映单位算力产出效率。账单层面核对云厂商账单与内部计量的一致（利用标签/分摊），把 GPU 成本按业务线归因。做"成本×利用率×token 产出"的关联分析，识别低效租户与资源。

关联分析的核心是发现"预算内的高效使用"与"高成本低产出"。GPU 利用率高但 token 产出低说明 batch 优化不足；利用率低说明资源闲置。账单核对确保计量无误。按业务线归因支撑成本治理与预算告警。

• 大盘指标设计
• tokens/sec/GPU 定义
• 大盘的运维价值

大盘展示 GPU 利用率、显存、tokens/sec/GPU、吞吐、TTFT/TPOT 与按模型/租户的 token 产出。tokens/sec/GPU = 总输出 token 数 / (GPU 数 × 时间)，反映单位算力生产效率。看大盘要区分"GPU 利用率高但 tokens/sec/GPU 低"（batch 填充差、短输出多）与"利用率低"（资源闲置），据此优化并发与批处理或缩容。大盘支撑容量规划与成本优化。

tokens/sec/GPU 是比 GPU 利用率更贴近"有效产出"的指标，避免"GPU 忙但产出少"的假繁荣。大盘作用是让效率可视化，支撑 batch 优化、并发调优与缩容决策。需按模型/租户维度下钻，定位低效单元。

• 日志字段与结构
• 输入输出采样策略
• 检索与索引设计

请求日志记录结构化字段：trace_id、tenant、model_version、engine_version、prompt_tokens、completion_tokens、TTFT、TPOT、总耗时、输入输出（采样）、错误码、缓存命中。输入输出量大且敏感，采用全量记录元数据 + 按比例/按规则采样完整内容（如 1% 全量、异常请求全量）。检索用 ES/日志平台按 trace_id、tenant、model_version 索引，支持按时间与状态过滤，用于排障与质量分析。

日志设计的关键是"元数据全量、内容采样"与"结构化+索引"。采样策略兼顾成本与排障能力（异常必采）。结合版本字段可做质量回归溯源。日志与 trace、指标三信号联动。

• 离线评测与线上指标的关系
• 关联方法与预测
• 自动回归发现机制

离线评测集（MMLU、业务 case 集）在发布前打分，线上质量指标（反馈率、采纳率、评审分数）用于持续观测。两者关联：离线评测能预测部分线上行为（如推理能力），线上指标反映真实用户影响。质量回归自动发现——定期把线上流量回流到评测集（或抽取线上样本标注），对比历史基线；当线上质量指标（如反馈率、评审通过率）下降超过阈值，或样例集评分下降，自动告警并触发回滚/重训。

离线评测是"门禁"，线上指标是"护栏"，两者配合：离线能提前拦截明显劣化，线上能发现离线未覆盖的分布漂移。自动发现的关键是"基线 + 偏差阈值 + 闭环（告警→回滚）"。将线上样本回流到评测集，使评测集保持与真实分布一致。

• span 分层设计
• 模型版本属性
• 采样策略

span 分层：网关 span（路由、鉴权、限流、token 计量）、队列 span（排队时间）、引擎 span（prefill/decode 耗时）、应用 span（端到端）。所有 span 携带 model_version、tenant、prompt/completion token 数、错误码等属性。采样策略：元数据（trace_id、耗时、token 数）全量，完整输入输出按比例采样（如 1%）且异常请求强制全采，避免成本爆炸同时保留排障能力。

span 设计要覆盖"排队/推理/生成"各阶段，才能定位瓶颈。模型版本属性是质量与成本归因的关键维度。采样策略平衡"可观测性"与"成本"——LLM 输入输出数据量大，全量不可行。异常优先采集保证排障。

• 流式输出的特殊指标
• 采集与告警
• 体验影响分析

流式输出指标：首帧时间（TTFT，从请求到首 token 到达）、token 间延迟（inter-token latency）及其抖动（衡量生成流畅度）、输出中断率（流中途断开/超时比例）、端到端完成时间。观测：在网关/客户端埋点记录每个 token 到达时间戳，计算 inter-token 间隔分布与 P90/P99 抖动；中断率按连接异常数统计。告警：TTFT 超阈值、token 抖动过大、中断率突增。

流式体验是 LLM 应用的关键——用户感知的是"首帧快不快、生成顺不顺、有没有断"。token 间延迟抖动反映引擎调度与网络抖动，需与 TPOT 区分。中断率反映稳定性。运维上把流式体验指标纳入 SLO 监控。