一、AI 领域的发展趋势

AI 领域的变化主要体现在以下三个方面：

第一是模型方面。目前业界各种生态不断迭代发展，无论是 DeepSeek 还是阿里云的通义千问，各类基础大模型都在持续升级；

第二是框架层面。目前市面上针对不同语言、不同层次的 AI 应用开发，涌现出了大量框架。例如在高代码领域，有 Java 的 Spring AI 和阿里巴巴生态；Python 方面也有 LangChain、Llama Index 等主流框架。而在低代码方向，也有很多开源平台可供选择，比如 Dify 和 Code Interpreter，这些工具可以帮助开发者快速构建 AI 应用。

第三则是应用场景。包括聊天机器人、编码助手、语音交互在内的多种 AI Agent 应用场景正在快速发展，呈现出日新月异的趋势。

二、AI 应用面临的挑战

但与此同时，AI 在使用上也遇到了三个方面的挑战：

第一个问题是“怎么用好”，即在搭建一个 AI 应用之后，如何确保其输出结果的一致性和准确性。例如，同一个问题多次提问，返回的结果却不一样；或者更换模型后，整体效果明显下降；甚至有时候模型在推理请求过程中出现卡顿或长时间无响应的情况。这些都是许多开发者在实际部署过程中遇到的问题。

第二个问题是“怎么节省资源”。模型调用是消耗 Token 的，需要清楚地知道每一次请求消耗了多少 Token，哪些请求或者应用在消耗的托管资源，才能进行整体成本核算与运营规划。

第三个问题是“怎么合规”。虽然构建了 AI 应用，使用了各种模型能力，但仍然需要关注回答的质量是否符合预期，是否存在不合理或不符合规范的内容。这也是通过可观测性手段去解决的核心问题。

三、AI 应用的典型架构分析

在解决这些问题之前，先来看一看常见的 AI 应用的典型架构。通常情况下，一个完整的 AI 应用可以分为三个层级：

首先是用户层，即通过 iOS 或 Android 设备访问的前端界面。一般在生产环境中，会通过 API 网关来完成流量防护和 API 管理。

其次是应用层，即由 Python 或 Java 编写的程序组成的 Agent 平台。这部分程序会调用多个模型，并且可能会根据业务需求在多个模型之间切换。引入 AI 网关可以用于统一管理流量、Token 控制、敏感信息过滤以及模型切换等功能，避免开发者在多模型间频繁切换带来的复杂度。

最后是模型服务层，即真正提供推理能力的底层模型服务。这一层可能部署了多个模型实例，并且运行在不同的计算平台上。

四、实现端到端可观测性的关键问题

为了实现端到端的可观测性，需要解决以下几个问题：

首先是如何对一次调用的全链路进行追踪，定位问题所在环节。例如一个请求出现问题时，到底是网关出问题了，还是应用层或模型层出现了异常？

其次是需要构建一个涵盖所有层级的可观测数据平台，将链路追踪、指标监控、日志采集等整合在一起。这样可以进行关联分析，判断问题具体出在哪个层级。

最后要采集模型内部的日志，记录输入输出内容，并通过这些数据评估 AI 应用的效果和质量。

五、各层级的观测重点

从监控的角度来看，在不同层级提供了不同的观测手段和关注点。例如在用户层，通常会分析是否存在卡顿、用户体验是否流畅；在应用层，关注异常情况和推理延迟；在网关层，关注 Redis、向量数据库等依赖组件的可用性；在模型服务层，关注推理效率；而在基础设施层，则关注资源利用率、缓存命中率等情况。

六、阿里云的全栈可观测解决方案

阿里云提供一套完整可观测解决方案，能够实现从上至下的立体化全栈可观测能力，涵盖底层的 GPU、人工智能平台 PAI、或者是通过容器服务部署的模型，到上层的模型层、AI 平台 PaaS 层、训练推理等，以及再往上的应用开发，包括百炼以及自研的 AI Agent 应用。

七、Tracing：打通全链路调用的关键

AI 可观测实践首先是 Tracing，也就是如何打通上文的全链路调用。Tracing采用了标准的 OpenTelemetry 规范，从用户的终端设备出发，经过 API 网关、AI 网关，再到应用层和模型层，将整个链路串联起来。

八、Tracing 的技术实现细节

Tracing在应用层，支持 Python 和 Java 两种语言环境，通过探针方式无侵入地采集 AI 应用的执行路径。而在模型层，也将探针部署到了模型推理服务中，采集推理过程中的各项指标。

在整个 Trace 的实现过程中，以 OpenTelemetry 为基础，定义了一套面向 LM（Language Model）应用的语义规范。这套规范明确了需要采集哪些指标、以什么格式存储、如何上报等问题。

OpenTelemetry 是公开的开放规范，因此可观测团队也积极与上游社区合作，推动统一的数据格式标准化，方便各厂商和服务端存储和处理。

九、关键性能指标的监控

在指标监控方面，也梳理了一些核心指标。例如推理阶段常用的 TTFT（Time to First Token）和 TPOT（Time Per Output Token），分别表示首 Token 返回时间和每个输出 Token 的平均间隔时间。这两个指标共同决定了单次推理的整体延时表现。

此外，还需关注模型调用次数、硬件使用率、Token 消耗量等指标。特别是 Token 的输入和输出要分开统计，因为大多数模型对输入和输出的计费是不同的，这对成本控制非常重要。

在模型推理阶段，TTFT 和 TPOT 是两个非常重要的指标。它们涉及模型推理的两个核心阶段：

第一个阶段是 Prefill 阶段，也就是模型将输入提示词转换为 Token 的过程。在这个阶段，输入 Prompt 会被分词并生成相应的 Embedding，同时填充 KV Cache。这个阶段的结束标志是第一个 Token 被生成，因此将这个阶段的耗时称为 TTFT，它是衡量推理性能的关键指标之一。

十、Prefill 与 Decode 阶段详解

第二个阶段是 Decode 阶段，即模型依次生成后续 Token 的过程。每一个新的 Token 都是基于此前生成的所有 Token 来预测的，因此这是一个逐步解码的过程。TPOT 就是用来衡量这个阶段中每个 Token 输出的平均间隔时间。

除了这两个指标，吞吐量也是关注的重点之一。它反映了单位时间内模型能够处理的请求数量。这三个指标之间存在一定的权衡关系，无法同时做到最优。例如在线推理场景下，更关注 TTFT 和 TPOT；而在离线批量处理场景中，则更关注吞吐量。

因此，在数据采集时，优先上报这些关键指标，并将其可视化呈现出来。

十一、数据采集与探针优化实践

在实际实现中，基于 OpenTelemetry 的 Python Agent 构建了一套无侵入式的监控方案。对于常用框架如 Llama Index、Dify，都进行了适配支持，并做了稳定性和性能优化，确保探针能够在不显著影响应用性能的前提下完成数据采集。

比如在 Python 中，利用 Monkey Patch 的机制动态修改函数行为，在函数执行前后插入想要的逻辑。这种方式无需修改用户代码即可实现数据采集，非常适合生产环境使用。此外，也解决了在 Gunicorn 多进程、Gevent 协程等常见部署环境下探针稳定性的问题，避免因探针导致进程崩溃或无法采集数据的情况。在高并发场景下，由于模型返回的数据量较大，一次性缓存全部数据再上报会对内存造成压力。因此还对数据上报流程进行了优化，采用分批上传并在服务端还原的方式，提升系统整体性能。

十二、Dify 监控中的常见问题与建议

在 Dify 的监控实践中，也有一些值得关注的问题。例如在其默认配置下，Nginx 的请求体大小限制可能导致大文件上传失败。建议适当增大 Nginx 的 body size 上限。

另外，在 PostgreSQL 数据库连接方面，Dify 的默认连接池较小，容易在高并发场景下出现连接打满、业务卡顿的问题。建议适当增加连接池容量。

Redis 在 Dify 中被广泛用于任务队列和状态同步，但在某些场景下，任务查询频率过高会导致 Redis 成为性能瓶颈。建议使用专业消息队列替代轮询 Redis 的方式，提升系统扩展性。

此外，Dify 自身集成的向量数据库和存储模块在高可用性和稳定性方面存在一定风险，建议迁移到更专业的向量数据库服务上。

十三、Dify 的可观测性增强

从可观测性的角度看，Dify 提供的基本日志和页面追踪功能较为局限，无法与外部微服务进行链路贯通。而通过接入 OpenTelemetry，可以实现跨服务的全链路追踪，全面掌握 Dify 内部的执行路径和性能表现。

对于 VLLM 和 SGLang 等流行的推理加速框架，也在底层探针中集成了支持。通过采集内部执行路径，可以精准定位模型推理过程中的性能瓶颈。

例如某个业务在调用 Dify 推理接口时出现延迟上升，可以通过全链路追踪快速定位哪一环节出现了问题。结合黄金指标（TTFT、TPOT）和模型服务排队情况分析，最终确认是由于推理引擎队列积压导致延迟升高。这类问题通过可观测性手段可以高效诊断。

十四、模型质量评估与 Token 黑洞监控

在模型质量评估方面，通过采集输入输出日志，结合外部裁判模型进行分析。例如可以检查回复中是否存在敏感词、幻觉内容，也可以对语义分类、情感倾向进行标注。

此外，还支持对模型调用过程中的 Token 黑洞问题进行监控。在 MCP（Multi-Call Protocol）模式下，模型可能会进行多次内部调用，导致 Token 消耗远超预期。阿里云可观测团队正在推进对此类场景的可观测性建设，即将上线相关功能。

十五、阿里云监控平台的统一观测能力

阿里云云监控平台支持对 Dify 应用、模型服务、资源使用情况进行统一观测。例如可以看到 Dify 工作流的具体执行路径、每个节点的耗时情况、模型调用次数、Token 消耗分布等。在模型层，还可以查看推理请求的 QPS、错误率、KV Cache 使用率等关键指标。进一步下钻到 PAI 平台，还能查看 GPU、CPU 等硬件资源的使用情况。此外，还支持基于绘画维度的 Token 消耗分析，帮助用户识别高频调用的模型和用户。同时，还引入了评估任务机制，可创建评估任务对模型输出进行自动评分，并进行聚类分析和语义标签标注。