从AI Agent到模型推理：端到端AI可观测实践

从AIAgent到模型推理：端到端AI可观测实践 AI原生应用开发实战营深圳站 望陶2025/04 1.AI原生应用架构演进及痛点2.阿里云AI全栈可观测解决方案3.大模型应用可观测技术实践4.Demo 蓬勃发展的AI应用生态 AI应用的痛点 模型推理问题 成本问题 数据质量问题 推理性能慢，服务器频繁超时，慢在哪里？模型输出的内容是否准确，是否合规？ Token消耗在哪些应用，哪些用户？ 如何进一步提升数据的质量和准确性？ 用的省 用的好 用起来 一个典型的AI原生应用架构及可观测诉求 模型生成结果评估 模型调用全链路诊断 AI全栈统一监控 构建统一日志分析平台，对模型调用日志进行二次评估分析，实现质量、安全、意图提取等语义检测。 基于Prometheus构建AI全栈监控大盘，包括模型性能分析、Token成本分析、GPU资源异动分析等。 基于OpenTelemetry Trace实现用户终端、网关、模型应用、模型服务、外部依赖工具等全链路追踪。 Tracing:模型调用全链路诊断 LLM Trace端到端全链路追踪 一个典型的LLMChatBot应用架构 LLM ChatBot包含前端UI、对话服务、模型应用、模型服务、AI网关、向量数据库、外部Tool等众多组件。 基于OpenTelemetry W3C协议实现LLM Trace端到端全链路追踪。详细记录每一次模型调用过程，包括Prompt、Input/Output、Token、TTFT（Time to first Token）等。 面向LLM应用的领域化Trace语义 以会话串联用户交互问答过程，以Trace承载应用全链路交互节点，定义领域化的操作语义、标准化存储以及可视化关键内容。部分贡献给OpenTelemetryGenAI工作组。 Metrics:LLM应用可观测需要关注哪些指标？ 基于Prometheus + Grafana实现AI全栈指标统一存储与可视化，构建LLM领域监控大盘，如模型性能分析、Token成本分析等。 Metrics:模型推理关键指标 推理性能目标是：最快的首个token响应时间、最高的吞吐量和最快的每个输出token时间 基于OpenTelemetry的高质量数据采集 以OpenTelemetryPython Agent为底座，增强大模型领域语义规范与数据采集，提供多种性能诊断数据，全方位自监控保障稳定高可用。 Python探针无侵入埋点的实现原理 Python语言提供一种装饰器模式，底层采用了一种monkey patch的机制，允许程序在运行时改变一个模块或者类的属性和方法，实现无侵入的可观测代码插桩逻辑。 阿里云Python探针与开源探针对比分析 面向流式场景的LLMSpan分段采集与合并 随着SSE协议在大模型推理场景的广泛应用，针对流式数据采用客户端分段采集+服务端合并还原，以平衡客户端侧性能与数据分析易用性。 1拆分长文本长耗时LLM Span每个分片作为一个Event单独上报 2模型调用结束，上报主Span记录分片数量、TTFT、Token等信息 3合并Events还原上下文当次调用的Events合并为单行数据 4模型调用内容二次评估分析下游评估任务/分析模块进行查询 Dify生产级部署最佳实践 1.Nginx调大NGINX_CLIENT_MAX_BODY_SIZE2.PGSQL数据库连接池大小：建议增加到300或以上3.Redis使用哨兵模式提升高可用性4.使用消息队列替换Redis5.使用第三方向量数据库6.使用外置可观测组件7.存储配置建议使用云存储（如OSS） Dify可观测最佳实践 vLLM/SGLang推理性能可观测实战 vLLM是一个高效的推理引擎，通过动态批处理、内存分块管理、KV缓存复用等方式大幅度提升了推理效率。 问题现象 某业务通过AI网关调用自建DeepSeek模型服务发现请求耗时很高 排查思路 1.通过RequestId查询到关联的TraceId，再通过端到端调用链分析发现模型推理阶段耗时非常高。2.通过调用链和指标关联，排查同一时刻相关指标是否异常1.首先观察TTFT指标，确认正常，排除prefill阶段问题2.检查TPOT指标，确认正常，排除decode阶段问题3.检查推理引擎中正在执行的请求和排队的请求数量，发现正在执行的请求数量激增，同时出现较多的排队请求4.最终确认是请求数量过多，超过当前处理能力后导致排队 建议 增大推理引擎中请求队列的大小配置 基于LLM实现模型生成结果自动化评估 系统评估（内置10+模板）降低门槛、自定义评估深度提升生成效果。一站式Embedding/向量索引、向量和关键字混合检索简化开发流程。 模型生成结果评估 评估，为了更好的生成 自动化评估（定量/定性） 为了更好的提升大模型生成效果，可以通过新的模型对原有模型Prompt/Response进行二次评估（质量、安全等）。 基于Trace或模型日志中记录的上下文内容，可以实现自动化定量/定性评估，比如合规性检查、用户意图提取等。 MCP为大模型生态带来了哪些变化和挑战？ 模型&MCP多轮交互导致“熵增”形成token黑洞LLM模型、宿主环境和各种MCP服务器之间的相互连接，会 通用连接器解决“N×M”集成问题 MCP（ModelContextProtocol）为人工智能模型和开发环境之间建立统一的上下文交互提供了标准化方法。 导致链路复杂性提升、性能瓶颈诊断困难、SLA难以保障以及安全等问题，可观测是降低“熵增”最有效的办法。 Demo Serverless+AI让应用开发更简单 CONTENT目录 Serverless+AI的无限可能01 Serverless+AI全新云应用开发平台02 Serverless+AI让应用开发更简单03 Serverless在解决什么问题？ 目标和策略 成本目标 •简单，易用，减少发布/扩容时间，提升发布/扩容的效率 •按需付费，降低用户成本，提供产品竞争力 •通过不断的优化资源供给能力：降低用户保有资源的成本，提高资源利用率，降低资源使用成本； •通过不断的加强和云产品及周边生态的集成，降低用户业务构建的门槛，减少业务发布和扩容运维时间，提升业务效率； •平台及体验能力升级：云服务集成，事件驱动，函数编排，应用模版，计费优化，观测能力集成 客户构建AI应用的“绊脚石” Serverless+AI全新云应用开发平台 Serverless + AI让应用开发更简单 FunctionAI平台重磅发布 FunctionAI架构 FunctionAI开发范式 Serverless+AI让应用开发更简单 高质量AI应用模版：加速AI应用落地 Serverless应用开发平台，提供丰富的AI应用模版，提供AI应用落地案例参考，支持一键快速拉起，解决AI应用开发者无从下手的困境 Serverless运行时：让业务成本更低，开发效率更高 •极致弹性：根据实际流量需要，自动弹出新的实例承载请求•按量付费：实际使用了多少计算资源，就付费多少（毫秒粒度）•镜像加速：层按需加载、多层缓存，GB级别镜像秒级启动 请求计费：0.009元/万次（阶梯计费）资源计费：•CPU计费：0.00009元/vCPU*秒（阶梯计费）•内存计费：0.000009元/GB*秒•显卡计费：0.00011元/GB*秒（阶梯计费）存储计费：0.0000009元/GB*秒（512MB以下免费） 多种策略保证平稳运行 预留实例/闲置预留 按量弹性 以默认8C、32GB内存、24GB显存A10卡的应用为例，每秒钟收费约0.003648元（以512像素的Stable Diffusion出图为例，约1.5分钱一张图） 流程服务：让业务流程管理更简单，可控 Serverless应用开发平台，提供易用的流程式开发工具，用户自定义服务能够自动注册成为可编排制品，帮助云和AI用户快速构建业务流程。 函数服务：让业务代码开发，运维更简单 开发更简单 •100+云产品事件集成，降低用云复杂度•全托管计算服务，内置日志采集监控告警•应用中心50+热门应用模板，开箱即用 运维更高效 •开发、调试、部署、运维全生命周期管理•计算资源CPU/GPU/内存/磁盘/网络按需组合•百毫秒冷启动，单客弹性效率可达2000实例/秒 架构更先进 •业务拆分到函数粒度，资源利用率可达100%•无需容量管理，研发提效10倍，运维0负担•2倍资源溢价，3倍利用率提升，技术降本30+% 模型服务：Serverless GPU让模型服务更普惠 模型托管服务提供GPU资源的按需和极速模式，在保留用户原有长持预留GPU的使用形态下，通过区分GPU实例的忙闲时刻，闲时定价大幅低于忙时定价，帮助客户大幅降低AI落地成本，同时保证模型冷启动推理耗时。 产品价值 模型来源 新兴的大模型推理场景 传统的在线推理场景 应用场景 AIGC浪潮下的新兴推理应用，LLM文生文、Stable Diffusion文生图、FunASR文生音频等 延时高度变化，负载高度不确定，偏C端的应用形态，日均资源利用率普遍较低；例如：传统的CV类模型（OCR）、NLP模型（机器翻译） FunctionAI客户故事 大型企业灵活可定制，加速业务AI创新 初创公司自媒体浪潮中的潮流引领 客户原声 客户原声 客户原声 客户原声 CAP +任务调度 CAP+Web全栈 CAP + Stable Diffusion +定制化 CAP+ComfyUI 谢谢Thank You 十几行代码实现OpenManus，SpringAI Alibaba Graph工作原理与使用示例 刘军 Spring AI Alibaba开源项目负责人2025/04/24 CONTENT目录 Spring AI Alibaba Graph深入介绍01 Spring AI Alibaba Graph示例演示02 Spring AI Alibaba Graph总结规划03 一个完整的Spring AI Alibaba示例 4 .声 明C h a t C l i e n t为 标 准S p r i n g B e a n 1 .添 加依 赖 2 .a p p l i c a t i o n . p r o p e r t i e s指 定A P I-K E Y 3 .应 用 入 口 Spring AI提供基础AI抽象与能力 •文本、语音、图片等模型、多模态均可支持•支持任意模型适配，按需切换OpenAI、Qwen、Deepseek•聊天记忆（多轮对话）•Prompt声明•Tool工具•格式化数据输出•RAG•模块化RAG检索•私域数据Embedding向量化与VectorStore存储•Tracing链路可观测 基于ChatClient的Single Agent架构 Single Agent架构的局限 1.如果一个agent包含有太多的可用tools，模型会在决策工具选择时无所适从，效果变差2.多轮执行下来，消息上下文会变得很大。消耗大量的token且影响模型当前专注度3.对于很多复杂的任务，不止需要很多个步骤，通常在某些环节还需要专业领域技能支持，比如科学计算、深入研究、写代码、绘画、任务规划等。4.单Agent在复杂任务场景下的可维护性会变差 面向复杂AI业务场景的解决方案 典型的workflow模式-Chain 典型的workflow模式-Routing 使用Spring AIChatClient开发workflow？ 更复杂workflow–低代码应用开发平台 典型的multi-agent模式 SpringAIAlibabaGraph示例 示例一：基于w