详解大模型应用可观测全链路 - 53AI-AI生产力的卓越领导者（大模型知识库|大模型训练|智能体开发）

一、背景

近日，随着阿里通义千问推出的 QwQ 系列深度思考模型爆火全球，以其令人赞叹的推理能力强、性价比突出等特点，一经发布就引发广泛关注，从资本市场与工业界走进大众视野中。

越来越多普罗大众开始了解与尝试 LLM 应用。但伴随着用户需求的激增，无论是基于官方模型服务还是自建部署大模型，在应用层调用大语言模型服务时，都可能面临响应超时或者不稳定等问题，从而影响用户的实际使用体验。相较于过往的云原生应用，LLM 应用可观测发生了翻天覆地的变化，不仅仅是资源类型、核心指标、数据特征的变化，故障模型、调试方式也发生了巨大改变。面对这一系列的稳定性挑战，本文给出了更符合业务特征的可观测解决方案。

二、大模型可观测的挑战

随着模型规模的扩大和推理请求量激增，推理服务会逐渐暴露出一系列性能瓶颈问题；基于大语言模型构建的 LLM 应用，从研发到生产落地，也面临若干环节的挑战，例如模型选择，提示词调优，流程编排、开发调试以及部署上线等；

我们总结从模型层到应用层的挑战包含如下：

性能与成本：许多企业在部署大模型时发现，GPU 利用率往往难以达到理想水平，导致资源浪费和成本上升；
使用与开发体验：引入推理架构虽然提升了扩展性，但也增加了系统的复杂性，使得故障排查和性能调优变得更加困难。复杂的 LLM 应用往往链路较长，流程编排复杂、依赖组件多且杂，往往端侧出现问题时定位链路问题根因效率低；
效果评估：大模型输出不可预测以及幻觉，可能会导致效果不符合预期；
安全合规：内容输入输出可能会涉及内容安全合规等风险。

我们熟悉的分布式、微服务应用可观测解决方案经过多年发展，已相对成熟。通过对性能、资源等核心指标的监控，及时发现系统性能瓶颈及容量问题，而 LLM 应用则是从性能、成本、效果三大方面来对可观测性提出了差异化的观测需求；AI 推理服务的监控需求则不仅涉及硬件资源和性能指标，还包括模型行为和分布式架构的复杂性；为了解决这些问题，我们需要一套统一可观测方案，能够覆盖从硬件到软件、从单机到集群，从模型到应用的全链路能力。

三、典型 LLM 应用组件与可观测数据类型

一个基于 LLM 的 ChatBot 应用架构参考如下：包含若干组件，包含前端 UI 组件、认证模块、会话管理、对话服务以及后台管理等一系列微服务，通过静态或者动态的流程编排来满足业务灵活性。在整体架构中涉及大语言模型相关的技术以及组件还包括：

AI 网关：基于 AI 网关对接不同 LLM 服务来应对不同场景的请求，满足大小模型混合使用的情况，另外在出现故障时能够自动切换模型服务来保障服务的连续性；
内容安全：客户的输入存在不确定性，往往需要引入 Moderation 和 Guardrails 技术来进行内容审查以及提示词防御，避免合规问题；
工具调用：面对复杂的业务场景，调用外部工具或者服务来完成具体操作，如借助调用互联网搜索来“准实时”获取最新信息，利用客户授权的工具来帮助客户完成实际行为动作；
RAG 技术：基于向量数据库来优化对话上下文或者长期记忆，来解决模型应答的幻觉问题，提升回答的实时性以及准确性；
缓存技术：通过对接缓存服务能够直接命中缓存，一方面可以直接命中缓存可以提升回答效率，另一方面可以降低对 LLM 的重复调用进而降低成本。

和典型应用一样，我们能够通过 Trace、Metric、Log 建立一套立体的可观的体系，在下文中，我们依次会通过 Trace、Metric、Log 演示性能分析、内容评估、安全合规与敏感信息保护等场景的解决方案。

四、LLM 应用必备的可观测能力：采集治理、领域视图、根因定位

登录 Y Combinator 公司网站查询 LLM Observability 关键词发现，存在 10 家以上的产品解决方案来满足 LLM 可观测需求场景，例如 Langfuse、TraceLoop、Arize AI、Datadog 以及 Helicone 等，分别从 LLMOps、Debug、Evaluation 等角度来构建产品形态满足不同的角色需求，产品能力各有侧重。Arize 公司提出 LLM 可观测五大支柱(Evaluation、Trace&Spans、Prompt Engineering、Search&Retrieval、Fine-tuning)，从这五大支柱出发，一方面需要覆盖模型层基础设施的模型训练以及推理等水位指标，另外一方面需要满足 LLM 应用层的若干可观测述求，基于丰富的指标、调用链、日志、事件等数据集合可观测大盘以及告警能力，提供强大的可观测分析解决能力。

整体思路上，成熟的可观测性平台需要支持从端侧不同接入形态的数据采集上报，构建领域化分析视图以及场景化分析能力，覆盖端到端全链路分析，及时发现线上问题，辅助 LLMOps 进行根因定位。阿里云可观测解决方案从以下几个方面来尝试帮助使用 DeepSeek 或QWQ 的 LLM 应用开发者来满足领域化的可观测述求。

面向 LLM 应用领域化指标洞察

通过分析 LLM 应用的交互特点以及处理链路，分析应用范式以及工作流程，往往一个用户会发起多轮对话。一次会话过程涉及到多次 Query，一次 Query 请求会涉及到若干操作，梳理并定义出关键的操作类型(LLM Span Kind)，用以标识 LLM 应用链路的核心操作语义，参考最新的OTel GenAI语义规范[1]，实现自动化的埋点采集上述核心行为，借助调用链分析可以更加聚焦 LLM 领域关键执行动作，分析内部执行细节，包括输入输出以及 Token 消耗明细等内容。

LLM 应用除了微服务已有的核心指标外，需要额外关注模型层的推理性能、Token 消耗、效果评估指标等特殊指标，能够从 LLM 领域视角去更好的洞察应用的业务表现。在业务表现下降或者出现内容风险时，能够及时感知第一时间进行人工介入。

模型推理过程中会关注推理速率以及性能体验，可能会关注如下指标：

Time to First Token (TTFT): 生成第一个令牌所需的时间，用于评估系统响应速度；
Time Between Tokens (TBT) ：生成相邻令牌之间的时间间隔，评估生成流畅度；
Time Per Output Token (TPOT): 生成每个输出令牌的平均时间，用于评估生成效率，计算公式为：;

评估场景，往往需要借助自动化或者人工评估手段从准确性、有毒性，幻觉等角度来评估整体性能、安全性以及可靠性等。

高质量的可观测数据采集能力

要实现上述面向 LLM 领域的调用链和指标的采集和上报，需要具备端侧埋点自动采集以及对接服务端上报数据的能力。由于 LLM 应用的主流开发语言为 Python，阿里云提供基于 OpenTelemetry Python Agent 底座的自研 Python Agent。除了覆盖常见的 Web 框架、数据库以及消息队列等埋点外，针对LLM应用进行量身打造，支持 LLamaIndex/LangChain/通义千问/OpenAI/Dify/PromptFlow 等国内外框架和模型。在原理上利用框架的 Callback 机制以及 wrapper 原理，能够实现无侵入埋点，极大地简化了集成接入流程。

我们看到 DeepSeek 官网提供的请求示例如下：


# Please install OpenAI SDK first: `pip3 install openai`
from openai import OpenAI
client = OpenAI(api_key="<DeepSeek API Key>", base_url="https://api.deepseek.com")
response = client.chat.completions.create(model="deepseek-chat",messages=[{"role": "system", "content": "You are a helpful assistant"},{"role": "user", "content": "Hello"},],stream=False)
print(response.choices[0].message.content)

从官方示例上看，DeepSeek 兼容 OpenAI 的 SDK 调用请求，阿里云 Python Agent 支持 Open AI SDK 自动化埋点，所以默认兼容 DeepSeek 场景自动化埋点采集能力，实现低成本采集各种请求类指标。另外，针对基于 vLLM 加速框架的模型服务进行自动化埋点采集，可以从模型服务端视角获取更多的性能评估指标，从而可以弥补部分场景客户端视角采集不全的短板。

面向用户的 LLM 应用体验监控

目前，国内外的 LLM 应用已经渗透到多个领域，并且在不同行业中展现出强大的潜力，而 LLM 应用相比传统 Web、移动端应用，在用户体验监控方面存在以下差异：

那么，LLM 应用如何衡量用户体验呢？目前 LLM 应用大多采用流式响应方式（即：逐字输出结果），相比传统应用，除了上文提到的 Time to First Token (TTFT)、Time Between Tokens (TBT) 、Time Per Output Token (TPOT) 等指标外，在用户体验方面还需要关注以下性能指标：

1、内容质量方面：

首次回答准确率 (First Response Accuracy)：用户问题在首次回答中被正确解决的比例，通常结合人工标注或辅助模型判断；
幻觉率 (Hallucination Rate)：模型生成内容中虚构事实或逻辑矛盾的比例，需要通过知识图谱校验、RAG（检索增强生成）答案一致性对比；

2、交互效率方面：

用户中断率 (Abandonment Rate)：指用户在生成完成前主动终止交互的比例，可能由于生成内容质量较差，或响应速度较慢导致；
多轮对话平均轮次 (Average Turns per Session)：用户需要多次交互才能完成目标任务的对话轮数，可能反映意图理解偏差，或内容生成质量不符合预期；
意图修正频率 (Intent Correction Frequency)：用户通过“重述问题”或“否定回答”修正模型理解的次数；

除此之外，在不同应用场景下，还需要关注对应的业务指标，比如：智能客服场景，需要关注人工透传率；内容生成场景，还需要关注内容原创度、以及排版等，以上这些指标，通常很难在服务端进行埋点，因此，需要结合用户体验监控来进行覆盖；

3、LLM 应用会话与传统应用会话的关联：

LLM 应用和传统 Web、移动端应用一样，都有会话的概念，从用户体验监控的视角，可以做如下对比：

相同点：

均需记录用户行为序列
依赖唯一标识符（Session ID）追踪链路
关注异常终止（如崩溃、网络中断）

从上面的对比来看，LLM 应用的会话其实和传统应用的会话没有本质的区别，两者之间可以进行关联，这样可以方便和用户其他交互操作进行关联分析，相信随着 LLM 应用不断发展，越来越多传统应用接入 LLM 能力，这一点将会得到验证。

LLM 专属领域可视化分析视图

开箱即用的指标分析大盘可以覆盖基础的业务黄金三指标外以及场景化分析，针对复杂应用架构的 LLM 应用也可以满足性能瓶颈分析需求。相比于微服务应用观测视图，新的 LLM 应用视图，更加强调领域化大盘设计，突出 LLM 相关指标，支持 LLM 调用趋势、Token 使用趋势、模型维度分析、RAG 以及 Tool 调用分析等，从性能以及成本多种角度提供对应用运行状态的全面了解；阿里云可观测提供的应用分析大盘效果如下：

推理性能分析：关注大模型调用请求数、耗时、错误等性能指标，从而可以对比不同的模型差异，例如首包耗时等领域指标；

Token 消耗分析：可以跟踪分析输入/输出 Token 趋势，了解哪些会话以及用户 Token 消耗偏高，能够帮助用户分析 Token 成本以及增长趋势。

调用链大模型分析视图：基于 LLM 领域语义格式化展示 TraceView 更直观，能够辅助开发者快速了解执行过程以及输入输出细节，缩短定位问题的时间。

会话分析视图：可以有效了解用户对话时序以及对话问答效果，帮忙开发者优化流程设计以及提示词调优，从可观测到业务运营实现更好的业务洞察。

云产品一站式端到端全链路打通

越来越多的企业使用到云产品，而云产品对于开发者而言存在黑盒，例如从客户端时间看到的耗时长，比较难分析是客户端慢还是服务端慢了；云产品自身提供端到端的链路埋点以及打通，就可以有效帮助开发定位耗时错慢根因；目前可观测链路 OpenTelemetry 版与阿里云近 10 款云产品（RUM、ALB、MSE 网关、ASM 等）深度合作，完成了云产品内部链路插桩与数据上报。对于企业用户来说，只需在相应的云产品控制台一键启用链路追踪开关，就可以直接看到相应的调用链，大幅简化了链路采集成本。针对 LLM 应用的云产品集成，阿里云可观测和百炼、PAI、MSE 网关等密切合作，在 Prometheus 接入中心可以完成 PAI、百炼、灵骏、容器Ray框架的接入，在云产品侧可以一键开启实现开箱即用的链路打通。

另外，我们知道一个复杂的应用系统涉及到组件非常复杂，调用链链路也会非常长。当我们需要对 LLM 应用问题进行排查时，通常需要覆盖用户端到服务端完整链路进行分析，同时需要结合用户体验监控的数据，追踪用户侧的输入和操作，复现整个问题过程。前后端打通的完整调用链效果如下：

通过上述的链路打通能力，用户在类似百炼这样的应用构建平台专注构建智能体应用，在百炼侧开启应用可观测基于请求调用链等进行调试优化。通过登录阿里云可观测控制台，查看该智能体的 LLM 应用更多的分析视图，覆盖 UI 端侧->网关->后端->组件依赖->模型的完整业务链路，实现端到端全链路透视能力。

五、突破 LLM 应用观测局限：Dify 应用自动化埋点与端到端链路追踪实战

阿里云 Python Agent 提供对常见大模型框架（Llamaindex、Dify、LangChain、OpenAI、通义千问、Prompt Flow等）的可观测性提供自动化埋点接入能力。详细信息请查看开始监控Python应用[2]。接下来以 Dify 应用接入可观测举例：

Dify.AI 是一款简单易用且开源的 LLMOps 平台，帮助开发者更简单、更快速地创建 AI 应用。它的核心理念是通过可声明式的 YAML 文件定义 AI 应用的各个方面，包括 Prompt、上下文和插件等。Dify 提供了可视化的 Prompt 编排、运营、数据集管理等功能。这些功能使得开发者能够在数天内完成 AI 应用的开发，或将 LLM 快速集成到现有应用中，并进行持续运营和改进。

在和客户的交流中发现有很多开发者基于 Dify 开发 LLM 应用或者二次开发构建内部AI平台，但缺乏有效的监控分析工具，同时也存在和其它内部系统链路打通的观测需求。当前的 Dify 默认集成的 Langfuse 以及 Langsmith 都偏向于 LLM 领域，缺乏端到端的完整分析能力；阿里云 Python Agent 针对上述场景，针对 Dify 内部执行链路进行精细埋点并采集丰富的数据，基于 OTel 标准默认和上下游进行串联打通，帮助开发者更好的进行定位流程执行、工具调用、异常分析等。我们尝试基于如下 Demo 来构建 LLM 应用并接入阿里云可观测。

步骤一：基于 Dify 构建工作流，并在业务流程中调用 DeepSeek 大语言模型来获取结果。

步骤二：安装阿里云 Python Agent：

安装 ack-onepilot，请确保 ack-onepilot 版本在 3.2.4 或以上。
修改 Dockerfile

从 PyPI 仓库下载探针安装器。

pip3 install aliyun-bootstrap

使用 aliyun-bootstrap 安装探针。

aliyun-bootstrap -a install

通过 ARMS Python 探针启动应用。

aliyun-instrument python app.py

构建镜像。

授予 ARMS 资源的访问权限
修改工作负载 YAML

labels:aliyun.com/app-language: python # Python应用必填，标明此应用是Python应用。  armsPilotAutoEnable: 'on'  armsPilotCreateAppName: "<your-deployment-name>"    #应用在ARMS中的展示名称

步骤三：在 Dify 应用入口发起流量，登录应用实时监控服务 ARMS 工作台，查看调用链详情效果如下，包含模型调用参数、Token 消耗、调用耗时以及输入输出等内容：

六、未来展望以及挑战

越来越多的微服务应用集成 LLM 能力来优化业务流程或者提效，往往出问题的环节不局限于 LLM 调用，需要从用户端到网关以及依赖服务等链路进行全链路问题排查以及根因定位。业界主流的 LLM Observability 平台聚焦于模型侧运维，提供了提示词以及模板管理、Dataset、Evaluation、Playground 实验对比等专业功能，比较适合研发调试以及 LLMOps 运维人员，相对缺乏微服务领域端到端的全链路视角，而阿里云可观测平台则侧重于提供全链路的打通以及全栈可观测能力。

阿里云可观测未来还会考虑支持实现调用链和 Evaluation 评分关联，基于 Trace 进行进行自动化语义特征分析等功能，帮助开发者解读理解数据内涵，为客户提供更多的语义化分析评估能力，实现可观测和大模型的联动打通。大模型服务作为LLM应用的核心依赖，模型侧的诊断分析场景，例如支持 GPU Continous Profiling，vLLM 的推理框架的埋点观测能力也在持续跟进中。阿里云可观测会持续跟踪业界进展，提供全面且开箱即用的可观测解决方案