LLM应用监控实战：用Langfuse搭建AI对话可视化仪表盘

做 LLM 应用最头疼的事情不是模型效果不好而是出了问题你根本不知道问题出在哪儿。模型半天没响应是提示词写得不对还是模型服务挂了Token 用量突然暴涨是用户真的在刷量还是代码里忘了加缓存这类问题在传统后端开发里靠日志和 APM 就能解决但搬到 LLM 应用这边情况复杂得多——你不仅要监控系统本身还得追踪每一次模型调用的输入输出、Token 消耗、延迟分布甚至整个提示词链路的调用关系。这个需求不是锦上添花是刚需。这篇文章要分享的就是我最近从零搭建的一套 AI 对话监控仪表盘。技术栈是 Langfuse Langchain DeepSeek FastAPI WebSocket核心目标很直白把每一次 AI 对话的前因后果、成本耗时、链路追踪全部可视化并且通过 WebSocket 实时推送到前端仪表盘上。通俗点说就是给 LLM 应用装一个飞行黑匣子加实时仪表盘。无论你是刚接触 RAG / Agent 开发的新手还是已经被线上 LLM 应用折腾到怀疑人生的老手这篇文章里的架构思路、完整源码和踩坑记录我觉得都值得你花几分钟看完。1. 这个项目为什么这么设计1.1 没有监控的 LLM 应用等于裸奔很多人刚接触大模型应用开发时会陷入一个错觉模型返回正常就万事大吉。但一旦应用上线问题就接踵而至。举个我实际遇到的场景用户连续追问几条敏感问题后模型开始输出一段格式异常的内容前端直接把整段 JSON 渲染崩了。事后排查时我只能看到一条模糊的 HTTP 500 记录既不知道用户到底问了什么也不知道模型返回了什么更不知道是不是某个中间环节把上下文搞坏了。没有链路追踪所有排查都只能靠猜。传统后端监控只能覆盖到系统有没有报错这一层而 LLM 应用多了一个模型推理链路的黑盒。这个链路里有用户输入经过了多少层处理的痕迹、有 Prompt 模板渲染结果、有模型实际收到的上下文大小、有最终响应的 Token 拆分细节还有调用成本和延迟的分布。这些信息传统 APM 工具根本采集不到。所以我们需要一套专门面向 LLM 应用的可观测性体系至少覆盖三个维度一是链路追踪看清一次请求到底经历了哪些环节二是成本与用量实时掌握 Token 消耗和费用三是质量回溯能快速复现某次糟糕回答是怎么产生的。这套需求Langfuse 正好都对得上。它是目前开源社区里做得比较成熟的 LLM 可观测性平台支持自托管不会像某些商业方案那样涉及数据出域问题。核心概念和传统 APM 的 trace / span 对齐上手成本低。1.2 这套技术栈到底解决了什么问题先回答一个很多人会问的问题为什么不用 LangSmithLangSmith 确实好用但它是闭源商业产品免费额度有限用量一大就得付费。而且很多企业内部对数据安全有要求模型调用记录不能全量发到第三方平台。Langfuse 能自托管数据全在自己手里从这一点上就已经赢了大半。再解释一下为什么是这五个组件拼在一起。Langfuse 负责监控和可视化Langchain 负责编排模型调用逻辑DeepSeek 作为模型底座FastAPI 提供异步后端接口WebSocket 解决实时推送。它们之间不是互相替代的关系而是各管一段、拼成完整闭环。Langfuse 和 Langchain 之间有一个天然的切入点——Langchain 的 CallbackHandler这是官方提供的事件回调机制每一次模型调用结束Langchain 会自动把 Token 用量、延迟、Prompt 等元数据通过回调抛出来Langfuse 的 SDK 正好接住这一层。整个接入过程不需要在业务代码里到处埋点配置好回调就能自动采集工程成本非常低。选择 FastAPI 和 WebSocket 的理由也很简单。FastAPI 原生支持异步和 WebSocket和 Langchain 的异步接口搭配协调。LLM 响应动辄几秒到几十秒如果用 HTTP 轮询前端每隔一秒打一次接口又慢又浪费资源WebSocket 建立一条长连接服务端有变