很多 AI 项目，本地 Demo 测试效果出色，上线生产环境之后故障频发，但是研发很难定位问题根源。缺少面向大模型场景的可观测体系，是非常普遍的工程短板。传统后端服务监控，重点关注 CPU、内存、QPS，这套指标无法完整覆盖 LLM 业务的运行状态，需要补充专门针对大模型调用的观测维度。
我们可以将指标划分为四大类：时延指标、错误指标、消耗指标、业务质量指标。
时延指标：整体请求总耗时、首 Token 返回时间 TTFT、内容生成总耗时。其中 TTFT 是流式业务用户体验最关键指标，代表用户第一次看到 AI 输出内容的等待时间。TTFT 缓慢抬升，往往代表上游模型推理集群压力上涨，即便没有直接报错，用户体验已经变差。
错误指标：整体请求错误率，同时拆分细分错误类型：鉴权错误、参数非法、429 限流、请求超时、服务商内部错误。指标需要按照不同模型服务商做维度拆分，这样可以快速定位是全部模型出现问题，还是某一家服务商的服务质量下滑。
消耗指标：输入 Token、输出 Token、业务 QPS。按项目、用户、模型类型做维度拆分，既可以做成本统计，也可以快速发现异常暴涨的调用流量。
业务质量指标：网关只能观测调用链路，无法判断大模型输出内容是否准确，幻觉、回答偏离需求这类问题网关无法识别。需要业务层自行统计用户反馈、输出截断占比、拒绝回答占比，以此评估模型在真实业务场景下的输出质量。
告警设计需要避开简单阈值告警的误区。少量 429 限流属于大模型业务的正常现象，瞬时小占比的限流不需要触发告警；只有短时间内错误占比持续飙升，才需要推送告警通知。相比于瞬间突增的故障，指标缓慢持续恶化更加隐蔽，建议配置趋势告警，监测时延逐步抬升、错误率缓慢上涨这类现象。
日志方面，完整记录请求 ID、模型标识、耗时、错误原因，方便问题排查。但是要注意合规约束，不要完整存储用户原始 Prompt 和敏感业务数据，做好数据脱敏，规避数据合规风险。
完整的可观测体系，目的就是变被动接用户反馈，为主动感知系统状态。当监测到某一家模型服务商服务质量下滑，可以配合网关的路由、熔断策略，自动切换备选模型，最大程度保障线上业务稳定。可观测不是简单打印日志，是大模型生产落地不可或缺的基础设施。
