AI 原生应用全栈可观测实践：以 DeepSeek 对话机器人为例

随着 DeepSeek-V3 & R1 火爆全球，基于大语言模型和 AI 生态技术栈构建的应用与业务场景与日俱增。AI 原生应用架构从研发到生产落地，面临诸多新的挑战，包括模型选择、流程编排、评估分析等等。可观测技术可以帮助 LLM 应用开发及运维人员更好的优化模型性能、成本及效果。

在 InfoQ 举办的 QCon 全球软件开发大会（北京站）上，阿里云高级技术专家夏明做了专题演讲“AI 原生应用全栈可观测实践：以 DeepSeek 对话机器人为例”，他以 DeepSeek 对话机器人为例，深入介绍 AI 原生应用架构的可观测需求、挑战与方案实践。比如 DeepSeek 为何频繁出现服务器繁忙？如何评估 DeepSeek 与其他模型的性能、成本与效果差异？如何优化 DeepSeek 对话机器人的终端用户体验？等等。

将于 10 月 23 - 25 召开的 QCon 上海站设计了「AI 时代的可观测实践」专题，本专题将围绕 AI 与可观测技术的双向赋能，讨论 LLM 如何重构传统可观测数据采集、分析、可视化、异常检测、根因定位全链路；AIOps 从实验到生产、从口号到落地的行动路径；可观测对 AI 全生命周期的支撑：从模型训练、推理以及 LLM 应用的稳定性保证与优化等等，敬请关注。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

Al 原生应用架构演进及痛点

AI 领域的从业者对相关进展应该比较熟悉。例如，基础模型的快速发展，尤其是近两个月，Deepseek 和阿里千问大模型等在国际上取得了领先的竞争力。在应用方面，目前比较热门的有 Dify 等应用编排和应用平台、LangChain 编排框架以及 MCP 生态，它们都迅速融入了大模型生态。

从大模型的应用形态来看，主要有三种：一是相对简单的对话机器人，直接调用基础模型或加上 RAG 领域知识库，可快速提供对话服务，应用场景较多；二是领域化的编排，如 Copilot 智能助手；三是最近比较有代表性的多 Agent 协同，真正实现任务的规划、编排、生成、执行等一系列流程，更接近人类的预期。

在蓬勃发展的生态之下，也存在一些 AI 领域的核心痛点。首先是基础资源问题，例如 GPU 卡价格昂贵，如何更好地利用底层资源；其次是模型推理问题，模型推理需求可能是模型训练的百倍甚至千倍以上，推理速度慢，还存在安全、隐私、合规以及恶意攻击投毒等风险，需要进行防御和评估；第三是成本问题，尤其是 MCP Server 出现后，存在“token 黑洞”现象，其内部实现不可见，恶意访问会导致反复调用大模型，快速消耗 token 额度。

阿里云 Al 全栈可观测架构

针对这些问题，提出了一个 AI 原生应用架构的方案。首先是用户终端，包括移动端和 Web 端，经过网关后，核心是应用模型层，例如 Dify 编排平台，上面可能运行多个语言模型应用。这些模型应用会调用向量数据库、模型服务调用缓存以及本地私有化或外部提供的 MCP 工具等。 AI 网关，可根据问题复杂度自动切换或路由模型，平衡服务性能和成本。再后面是模型服务层，可调用托管模型或自研自建模型，目前很多企业都在构建自己的模型服务。针对这套架构，总结出三个核心观测诉求：一是 AI 全栈统一监控，关注各层之间的动态，如模型性能、token 成本消耗等；二是端到端模型调用全链路诊断，从终端用户发起问答对话到后端系统流转，找出瓶颈并调优，这给传统 Tracing 系统标准带来新挑战；三是对模型生成结果的评估，这是提升生成质量的关键，需要探索自动化评估方法。

AI 全栈统一监控分为几层：用户业务层关注用户体验，如终端性能卡顿，以及 SSE 流式问答响应等新挑战；模型应用层关注推理响应耗时，如首包响应时间和平均吞吐量等指标，以确定性能瓶颈；外部工具层涉及网关、缓存、对象存储等；模型服务层观测不同模型的效果和成本利用率；AI Infra 层可在 K8s 上托管模型或直接调用 GPU 资源。

在一个典型的 LLM 聊天机器人的应用架构中，从用户请求到流转，还包括防御词检查、领域知识库外联等环节。传统链路观测视角难以满足算法从业者和模型平台开发者的诉求，因为他们更关注模型调用、embedding、retrieval 等 LLM 层面的内容。针对不同角色和场景，需要定义新的指标，与社区共建，尝试定义新的 GNI 领域语义化能力。

模型生成结果的评估对现有研发运维体系是重大挑战。传统质量保证方法如黑白盒测试在语义结果上难以界定对错。针对新的语义响应，可采用评估模板，对用户输入输出进行评估，包括质量效果、安全性风险、用户意图提取、情绪等，这些都是新挑战，团队也在进行相关探索，如语义特征提取、评估自动化等。在阿里云视角下，从 AI 应用到大模型、AI PaaS、容器和智算基础设施，提出了一个整体解决方案。

大模型应用可观测技术剖析

在大模型应用的可观测性方面，我们需要关注一些与传统不同的指标。除了传统的黄金三指标（RED 指标），大模型中还会出现一些新的指标，例如 TTFT（首次首包传输时间）、TPOT（平均吞吐量）和 Token per Second（每秒 token 数）等。这些指标从三个维度来观测模型的效率，每个指标都代表了模型在不同生成阶段可能存在的问题，比如在 prefill 阶段或 decode 阶段。此外，还需要关注 token 成本以及评估生成内容的毒性、幻觉等问题，这就需要我们定义新的指标来描述这些问题。

对于 LLM 应用的领域化 Trace 语义，大模型生态中的会话（session）概念变得更加重要，因为多轮对话的场景较为常见。例如，用户登录 APP 后可能会先问一个问题，然后不断追问，这就构成了一个会话，而每轮对话背后又会发生多次请求，即多条 Trace。系统中不同 Trace 的流转被我们定义为 LLM span chunk 类型。例如，需要考虑如何编排整个流程，包括 embedding、向量检索以及调用模型服务等环节。针对这些不同类型的 Trace，它们都有自己特有的字段语义。总的来说，我们不能简单地用传统微服务 CPU 架构的视角去套用到大模型 GPU 架构上，而应该以更开放的心态重新理解这一套新架构。

在具体实现方面，开源的迭代速度相对较慢，而阿里云通过自研探针进行高质量数据采集。阿里云的探针底座基于业界主流开源生态，并非另起炉灶。团队还计划将相关工作回馈社区，进行开源。以 Python 探针为例，它可以通过无侵入的方式进行埋点，无论是在 Dify 平台、自建模型服务的 vLLM 框架还是 SGLang 框架下，都能采集到对应的性能指标数据和链路信息，包括 Llama index 操作逻辑、prompt 信息以及外部调用信息等。

阿里云自研探针与开源的 OTel Python 探针存在一定差异。例如，自研探针支持更多埋点框架，如最新的一些 vLLM、SGLang 以及正在做的 MCP 等，这些在开源领域是略微领先的。此外，阿里云探针会定义更丰富的埋点，因为开源探针为了兼容不同生态，可能会受到一定限制。例如，OpenAI 有自己的 tracing 标准，与现有的 OTel 标准差别很大。阿里云希望尽可能兼容各种主流实现，虽然在标准实现上会有些差异，但在埋点上会丰富数据采集，最终归一为一套生产可用的实现。同时，阿里云探针还会针对多进程协程等细节进行优化，以提高稳定性和性能。在大模型数据处理链路方面，阿里云既支持自研探针，也兼容主流开源的数据集成方案。无论客户端类型如何，都可以实现统一上报采集和数据加工处理，最终提供一个稳定、高性能的服务。

在大模型领域，流式场景的 LLM Span 分段采集与合并是一个比较特殊的新问题。虽然流式场景本身并不新，比如 Websocket 也有流式传输，但在大模型领域，这个问题变得尤为重要，需要重新审视。针对流式场景，开源的 OTel 社区也在讨论相关问题。如果不将流式数据分段采集和上报，而是等到完整后再上报，会对探针客户端造成很大压力。因为一些极端的大模型调用上下文可能有几兆甚至几十兆，持续时间可能达数小时甚至超过一天，这与传统意义上的请求有很大差异。为了解决这个问题，可以将流式场景分 chunk 进行分段上报，但简单地分段存储会导致后续数据分析困难，比如算法人员难以找到分散的 chunk 信息进行模型上下文评估，尤其是进行批量回归时。因此，最终方案是与社区提案相近的分段数据上报后在服务端重新合并为一条记录。这其中涉及很多细节，如何时上报、如何缓存、高性能实现以及是否有限制（如截断）等，但整体思路是为了平衡客户端性能、实时性以及数据分析评估的易用性，采用分段采集和服务端合并，最终持久化为一条记录的方案。

在国内，Dify 平台使用较为广泛，团队也在实践中使用 Dify 原生的可观测能力。但在使用过程中发现，Dify 原生的可观测性以及探针存在一些问题，比如如何实现全多维度分析视角。Dify 本身是一个大应用，上面会运行多个业务 LLM 应用，需要评估每个业务 LLM 的成本消耗和性能，这更符合生产级部门间的协同需求。而 Dify 只是 AI 全栈调用链路中的一环，它如何与外部依赖、模型服务层以及 AI 网关等上游层协同进行全量观测，是 Dify 框架本身无法完整回答的。通过整体方案可以解决这一问题。

在 VLLM/SGLang 推理性能可观测实战方面，比如在阿里云的 PAI EAS 上部署模型服务，或加速推理性能时，会遇到一些问题。例如，当发现 Deepseek 模型服务请求超时时，可以通过 Request ID 检索到相关联的 Trace ID，通过端到端分析定位问题是否出在模型推理服务本身，还是在前置端侧或应用层。如果定位到模型推理问题，再观察相关指标，如首包延迟正常可排除 prefill 阶段问题，TPOT 指标正常可排除 Decode 问题，最终发现是请求队列问题，通过调整队列大小解决了问题。这就是推理层面的一个实践案例。

基于 LLM 实现模型生成结果的自动化评估时，实践过评估的同学可能会面临一些问题。例如，现有方案中，用户输入的 embedding 过程和向量检索过程可能需要调用两次服务或两个组件来完成。即使通过评估语义检索查出了一些结果，但这些结果可能无法完全满足生产级的查询需求，还需要结合传统的关键词进行混合检索。针对这些问题，阿里云格文斯团队的实践是提供内置的评估服务。由于 trace 数据天然记录了整个模型调用的上下文过程，包括单次 LLM 请求的 prompt 和 response，以及全链路每个阶段的完整上下文，因此可以基于这些数据快速提供开箱即用的内置评估模板。用户可以选择针对某一类用户或场景的模型调用进行质量检测、安全检测或意图提取等操作。然而，内置模板的上限相对较低，例如算法补全优化从百分之十几提升到 40% 后，若想继续提升就需要不断调优，丰富各环节的关键特征并进行微调，这就需要支持自定义扩展能力。从工程实践效率角度出发，还需要解决如何将 embedding 与 retrieval 过程结合，以及如何将语义检索与关键词、顺序扫描的混合检索结合等问题，团队提供了一些更好的工程化能力来简化开发流程。

MCP 目前非常受欢迎，它主要解决了协议标准化的问题。之前 function call 虽然也能解决类似问题，但没有标准化，针对不同实现需要提供多种实现方式。如果未来 OpenAI 等遵循统一标准，那么只需要定义一套 MCP Server 即可。例如，阿里云会开放相应的 MCP Server 和公共工具，帮助用户简化构建智能运维、智能体的流程。用户可以直接集成阿里云的智能诊断能力，而无需面对多种不同协议。MCP 解决了 n 乘 m 的集成问题，但也引入了新问题。由于增加了 Client 和 Server 之间的交互，调用链路变得更加复杂。例如，Minus 有上千个 tool，在这种复杂场景下，调用链路的优化和定位变得非常困难。因此，针对 MCP Server 背后的观测以及 client 端的观测能力变得尤为重要，可观测性是解决这些问题的有效手段，团队在这方面也做了很多工作，并将陆续发布相关成果。

Al In 可观测实战

阿里云可观测团队在 AI 应用方面的实战主要分为两个部分。第一部分是提供智能助手，例如 Copilot 智能助手，它适用于垂直领域，如分析复杂的大模型 trace。传统领域也存在类似问题，很多客户不会用 trace，这是一个行业难题。为了解决复杂度问题，团队提供了 Copilot 智能助手，用户点击“魔法棒”后，它能判断 trace 是否有问题，是错误问题还是性能问题，如果是性能问题，会指出是哪个组件导致的，背后原因是什么，以及如何优化。这种方式更易理解，有助于推动行业的广泛应用。类似地，在性能优化场景中，如 CPU 热点、内存 OOM 等问题，除了复杂的火焰图分析外，还需要结合死锁数据、资源管理配置、Pod 规格等信息。针对这些问题，团队也通过 Copilot 的方式解决，现阶段倾向于用 workflow 方式提高确定性，规避模型幻觉问题。

第二部分是 Problem Insights 智能洞察，它解决的场景更复杂。当企业服务出现可用性风险（故障）时，团队希望通过自动发现故障、给出传播链事件流推理过程、根因分析，甚至结合企业运维的 MCP 工具实现故障自愈，构建智能运维体系。这个场景的复杂性使得编排难以应对，团队倾向于通过 Agent 的方式尝试回答，内部会涉及多种工具。

目前，Copilot 已上线三类功能。第一类针对日志服务，偏 SQL，可帮助用户进行自然语言转 SQL 或 SQL 分析，优化 SQL 语句。第二类是 trace 分析，当 trace 出现慢、错或异常时，它能指出入口服务报错的原因，如下游接口调用数据库 SQL 语法问题，并给出 SQL 优化建议。这背后涉及分析 trace 结构、识别特定领域问题、关联多模态的 profiling 日志和 metrics 等信息，目前通过 workflow 方式编排。第三类是 profiling，实现了常态化持续性能剖析，可随时回溯对比发布前后的差分火焰图，定位性能问题代码。下一步，团队计划关联发布变更的 Pod 镜像版本，甚至探索 Git 提交的 commit 信息及责任人。

Problem Insights 智能洞察主要面向故障应急场景，目标是实现真正的智能洞察。它可以智能检测系统核心问题，也可关联告警事件触发洞察。例如，当检测到应用接口性能退化时，它会展示推理过程，先进行根因定界，判断是服务自身问题、下游问题还是基础环境问题；然后进一步分析是资源问题还是代码问题，以及对上游业务的影响。对于 SRE 或运维人员来说，了解故障传播链、相关事件流、影响面，结合多模态数据给出根因和解决方案，可以极大地简化运维操作，提升企业可用性，降低 MTTR 时间。

未来规划与展望

在未来规划和展望方面，首先，可观测的核心问题依然是采集更多高质量的数据，包括对新协议的覆盖。这是首要任务，否则将面临“无米之炊”的挑战。其次，无论是 MCP 的生态还是整个端到端的生态，未来企业构建统一可观测平台时，仅仅做到数据存储是远远不够的。例如，日志存储在日志系统，指标存储在监控系统，这种分散的数据存储方式无法满足需求。团队正在尝试解决如何真正理解这些数据，打破数据孤岛，构建数据之间的实体关系连接。以 Tracing 为例，它可以解决端到端请求流量的精准连接，只要遵循同一协议并透传 Tracing ID 即可。但一旦涉及非调用环节，比如某个模型应用部署在 K8s Pod 上，而该 Pod 两分钟前发生了容器镜像版本更新，且该镜像对应某人提交的 Git commit，如何解决这种更大范围、更广义的数字世界连接问题，是团队关注的重点。团队希望通过构建实体拓扑来解决这一问题，这不仅包括大模型的实体拓扑（会优先构建），还包括如何构建整个数字世界的完整实体拓扑，这是团队未来需要回答的核心问题。第三，随着大模型的广泛应用，语义类问题将日益突出，如质量、安全、意图等。团队将持续优化模型评估流程，降低使用门槛，同时支持用户进行自定义扩展。最后，团队将持续迭代自身的可观测智能体，借助 AI 发展浪潮，通过 AGI 提升行业和社会的生产力。

演讲嘉宾介绍

夏明，阿里云高级技术专家。在链路追踪、应用可观测领域从业近十年。先后负责阿里集团 EagleEye、阿里云 ARMS 相关产品设计与研发。GitHub 稳定性专栏 StabilityGuide 发起者。