AI模型可观测性最大的误区，是只看一个“总耗时”或者“成功率”。这样的指标虽然能告诉你系统有没有变慢，却不能告诉你慢在哪里，也不能告诉你是不是模型本身的问题。
AI模型可观测性的真正价值，是让团队能快速判断问题在网关、模型、检索还是工具链。 如果定位链路不清楚，排障就会变成反复猜。
先把可观测对象分清楚
模型服务里通常有四层需要看：入口层、推理层、检索层和工具层。入口层负责请求是否正常进入；推理层负责模型实际处理；检索层负责知识和上下文；工具层负责外部接口调用。
如果这四层没有拆开，很多慢请求最后只能归因成“模型慢”。实际上，真正的瓶颈可能在网关排队、检索超时或工具调用失败。
指标要分成四类
可观测性不能只靠一堆图表堆起来。更实用的做法，是把指标分成四类：
1. 体验指标：首 token 延迟、总响应时间、超时率
2. 资源指标：GPU 利用率、显存占用、排队长度
3. 质量指标：错误率、拒答率、格式失败率
4. 成本指标：Token 消耗、请求计费、资源利用效率
这四类指标一起看，才能既看性能，也看成本和质量。
链路追踪要能串起一次请求
AI 请求往往会经过网关、模型、RAG、工具和日志系统。没有链路追踪，团队就看不到一次请求到底在哪一环节变慢或失败。
好的链路追踪，至少能串起请求 ID、模型版本、路由策略、检索命中、工具调用和最终结果。这样出问题时，平台团队可以快速判断该找哪一层。
日志要能帮助复盘，而不是堆噪声
AI系统的日志特别容易变成“记录很多，能用很少”。真正有价值的日志，应该能回答：请求来自谁、命中了什么模型、走了哪条路由、是否触发降级、是否调用工具、失败在什么位置。
同时，日志不能把所有 Prompt 和输出原样无限保存。生产里要区分排障日志、计量日志和内容日志，避免把可观测性做成新的合规风险。
观测要支持问题分类
当模型变慢时，系统要能帮助团队快速分类。是入口拥塞、推理排队、检索超时、工具失败，还是某个模型版本本身有问题？如果分类靠人工翻日志，效率会非常低。
更好的做法，是把核心信号标准化，让告警、看板和日志都围绕同一套字段展开。这样排障时，不同团队看的是同一件事。
POC 可以看 4 个问题
验证 AI模型可观测性时，可以直接问：
- 是否能看到每层链路耗时
- 是否能按模型和路由分维度看指标
- 是否能追踪一次请求的完整路径
- 是否能用日志快速定位异常原因
如果只能看到一个总耗时，就说明可观测性还不够。
常见问题
为什么模型日志不能只留原始 Prompt？
因为原始 Prompt 不能替代结构化日志。原始内容虽然信息多，但不便检索和统计，还可能带来敏感数据风险。
可观测性和监控有什么区别？
监控更偏向看状态，观测更偏向解释原因。对于 AI 系统，光知道“坏了”不够，还要知道“为什么坏”。
模型可观测性最重要的指标是什么？
没有单一指标。至少要把延迟、错误、资源、质量和成本一起看。
下一步建议
如果你的模型系统已经在生产里跑，先别急着上更多复杂面板。先把链路、指标和日志统一起来，能更快定位问题，也更容易做长期运营。
原创声明：本文为 Alauda 原创技术内容，非商业转载须注明出处：https://www.alauda.cn/blog/1514/。
文中图示和文章内容未经许可不得用于商业转载、培训课件、营销材料或二次分发。
