Langfuse 是一个开源的 LLM(大语言模型)可观测平台,用于追踪、评测和监控生产环境中的大模型应用。它解决的核心问题是:LLM 应用是一个黑盒——一次对话跨多个模型调用、上下文不可见、token(模型计费与处理的基本文本单元)成本波动大,传统日志和 APM(应用性能监控)工具无法回答「这个回答为什么差」「这次请求花了多少钱」「prompt 改一版到底有没有变好」这类问题。Langfuse 以 Trace 树(一次完整请求的调用链记录)为核心,记录每次模型调用的模型名、参数、输入输出、token 用量、延迟与成本,并提供数据集评测、提示词版本管理、用量分析与告警能力。它采用 MIT 协议,可 Docker 自托管,也提供托管云服务;Python/JS SDK 支持一行接入,并原生兼容 OpenAI、LangChain、LlamaIndex、LiteLLM 等主流框架。本篇按「速览 → 安装 → 上手 → 核心能力 → 生产部署 → 选型对比 → 应用场景」的顺序,带你在 5 分钟内完成从部署到埋点的全流程。
掌握 Langfuse,你就掌握了 LLM 应用从开发调试、线上监控到提示词迭代的完整可观测闭环,这是 LLM 应用工程师与 AI 平台团队的必备技能。
目录
速览卡是工具类内容的固定首屏模块:30 秒判断「这工具是什么、能不能商用、适不适合我」。
为什么需要 Langfuse:LLM 应用是黑盒,上线后无法排查与优化
传统监控体系对 LLM 应用基本失效。常规日志只能记录一条最终的 completion(模型补全结果),检索到的上下文、多轮对话状态、prompt 模板、token 消耗这些关键信息全部丢失;APM 工具只能看到普通的 HTTP 请求,无法理解「一次用户请求内部调用了哪几个模型、各自花了多少钱、哪个环节拖慢了响应」。更麻烦的是,LLM 输出具有随机性,同样的问题换个参数就换一个答案,出了问题只能靠用户反馈倒推,复现和定位成本极高。
Langfuse 用两条思路解决这个问题。一是全链路追踪:一次请求从业务函数到模型调用,记录成一颗 Trace 树,每个节点携带模型名、参数、输入输出、token 数与成本,支持全文检索和属性筛选,输入一个 trace_id 就能复现任意一次线上请求的完整上下文。二是把观测与迭代打通:同一份数据既能做故障排查,也能用来跑数据集评估、提示词版本对比、成本聚合分析,让「观测」直接服务于「改进」,而不只是事后翻日志。
与同类工具相比,Langfuse 的气质差异在于「开源中立 + 平台化」:它不像 LangSmith 深绑 LangChain 生态,也不像 Helicone 偏网关接入,而是以 SDK 植入为主、框架无关,并把追踪、评测、提示词管理放在同一套开源代码里,自托管可完全掌控数据。
安装与环境配置:3 步就绪
步骤一:自托管服务端。 官方提供 Docker 镜像与 docker-compose 配置,一条命令即可启动完整服务(UI + API + 数据库)。
浏览器打开 http://localhost:3000,首次访问注册账号即完成部署。默认配置开放注册,生产环境务必按下文关闭。
步骤二:安装 Python SDK 并配置密钥。 在 UI 的「项目设置 → API Keys」中创建一对密钥(public key 与 secret key 配对使用),写入环境变量:
步骤三:验证连通。 运行健康检查脚本,确认数据能写入并在 UI 查询到:
UI 的 Traces 列表出现 healthcheck 记录即接入成功。
git clone https://github.com/langfuse/langfuse.gitcd langfusedocker compose up -d
pip install langfuseexport LANGFUSE_PUBLIC_KEY=pk-lf-xxxxexport LANGFUSE_SECRET_KEY=sk-lf-xxxxexport LANGFUSE_HOST=http://localhost:3000
python -c "from langfuse import Langfuse; c=Langfuse(); t=c.trace(name='healthcheck'); t.update(output='ok'); c.flush(); print('sent')"快速上手:5 分钟给真实应用埋点
最小可用流程:不修改业务逻辑,用装饰器包裹需要观测的函数,再使用 Langfuse 包装的 OpenAI 客户端发起模型调用,调用链会自动上报为 Trace 树。
操作步骤:
1. 安装 SDK 并配置三个环境变量(见上节)。
2. 在代码中导入 langfuse.decorators.observe 装饰器,为业务函数加上 @observe()。
3. 将 openai 客户端替换为 langfuse.openai.openai——API 用法与原版 SDK 完全一致,只多一层自动埋点。
4. 正常调用函数,数秒后打开 UI 的 Traces 页面,点击最新一条记录查看完整 Trace 树。
运行结果:UI 中生成一条名为 answer 的 Trace,其下挂一个 Generation 节点,展示模型名、完整输入输出、token 数与成本估算。如果 answer 内部还有检索或工具调用,继续用 @observe() 装饰子函数,它们会成为 Trace 树的子节点。
进阶技巧:在函数参数中传入业务 ID(如订单号)作为 trace_id,可将业务数据与观测数据关联;用 @observe(as_type="generation") 直接把节点标记为模型调用,便于按类型筛选。
from langfuse.decorators import observefrom langfuse.openai import openai @observe()def answer(question: str): client = openai.OpenAI() resp = client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": question}], ) return resp.choices[0].message.content print(answer("用一句话解释什么是 RAG"))
核心能力详解:4 大支柱
支柱一:追踪与可观测(Trace 树)。 Langfuse 用 6 类观测对象描述一次请求:Trace(完整请求)、Span(耗时子操作,如检索、工具调用)、Generation(模型调用,自动记录 prompt、completion、用量)、Event(零散事件)、Score(评分)、Session(会话)。数据支持全文检索与任意属性筛选,可复现任意一次线上请求的完整上下文;检索质量、模型参数、耗时分布都以结构化字段存储,支持按模型、标签、用户维度切片分析。
支柱二:评测与数据集。 数据集(Dataset)可批量管理「输入-期望输出」样本,支撑回归测试;Score 支持人工打分、代码打分与 LLM-as-judge(用大模型当裁判自动评分)三种方式;评测可以对历史 Trace 重放——把当时的输入重新跑一遍并给出质量分数,从而量化「prompt 改一版是否真的变好了」,而不是凭感觉上线。
支柱三:提示词管理(Prompt Management)。 提示词在平台内版本化管理,支持灰度发布与回滚;应用代码通过 langfuse.get_prompt(name, version) 拉取指定版本并即时生效,提示词迭代无需发版。dev / staging / prod 环境可用不同版本实现隔离,回滚只需在 UI 中操作。
支柱四:用量与成本分析。 按模型、用户、会话、日期聚合 token 消耗与预估成本;成本单价模型内置 OpenAI 等主流厂商,也可自定义。可快速定位「哪个用户、哪个功能在烧钱」,配合阈值告警(token 用量、成本、错误率)防止费用失控。
生产部署与监控:从上线到运维
部署方式一:Docker Compose 生产化。 生产环境建议使用独立 Postgres 15+ 实例(或云数据库),并配置 Redis——v3 起 Redis 是必需组件,作为后台任务队列。首次启动前通过 LANGFUSE_INIT_USER_EMAIL、LANGFUSE_INIT_USER_PASSWORD 等环境变量初始化管理员,并开启 AUTH_DISABLE_SIGNUP 关闭开放注册。多副本场景下 web 与 worker 使用同一 Redis 队列,镜像分开部署。
部署方式二:Kubernetes / 托管云。 官方提供 Helm Chart,支持多副本、HPA(水平自动扩缩)与持久化存储;若启用会话回放(记录网页交互与 LLM 调用),需配置 S3 兼容对象存储(如 MinIO)存放媒体文件。数据合规要求高的团队可完全自托管;无运维人力的团队可直接使用 Langfuse Cloud(SaaS),核心功能与自托管一致。
可观测性: 平台的自我监控分为三层:一是业务告警,基于 token 用量、成本、错误率设置阈值,通过 Webhook / Slack / 邮件推送;二是数据量控制,SDK 初始化时配置 sampling_rate(采样率,按比例随机丢弃上报数据)以控制存储成本,配合数据保留期策略清理过期 trace;三是基础设施运维,定期备份 Postgres 数据库,关注 worker 队列积压与连接数,高峰期横向扩容 web 与 worker 副本。
<p class="para-label">避坑清单:</p>
<ul class="dash-list"><li>v3 起自托管必须配置 Redis,只装 Postgres 会启动失败——升级前先读官方 v3 部署变更说明。</li><li>Python SDK 默认异步批量上报,进程退出前要调用 client.flush(),否则最后一批数据会丢。</li><li>生产环境默认开放注册必须关闭并初始化管理员账号,否则任何访问者都能看到你的观测数据。</li><li>自托管不受消息量收费限制,但 trace 量过大会压垮默认 Postgres——按需开采样、设保留期清理历史数据。</li></ul>
| 维度 | Langfuse | LangSmith | Arize Phoenix | Helicone |
|---|---|---|---|---|
| 定位 | 开源 LLM 可观测平台(追踪+评测+提示词管理) | LangChain 生态的商业追踪与评测 SaaS | 开源 AI 可观测与实验平台(Arize 出品) | 开源 LLM 网关式监控与成本管理 |
| 编排范式 | SDK 装饰器/回调,以 Trace 树为观测模型 | 原生 SDK + 深绑 LangChain 回调 | OpenInference 协议 + Notebook 优先 | 代理/网关拦截,改 Base URL 即接入 |
| 类型约束 | Trace/Span/Generation/Event/Score/Session 六类对象 | Trace/运行/评估/数据集/提示词 | Trace/嵌入向量/在线实验 | 请求日志/成本/缓存/限流 |
| 学习曲线 | 低(一个装饰器 + 异步批量上报) | 中(依赖 LangChain 概念体系) | 中(实验场景顺手,生产接入需自建) | 低(无需改代码) |
| 生态集成 | OpenAI/LangChain/LlamaIndex/LiteLLM/Haystack 等 30+ | LangChain 全家桶优先,其余次之 | OpenInference 标准 + 主流框架回调 | 所有 OpenAI 兼容接口 |
| 生产部署 | 自托管(Docker/Helm)+ 托管 Cloud | 仅 SaaS 托管 | 自托管单机/Python 包 + Arize 云 | 云版为主,自托管需自建代理 |
| License | MIT(企业版功能另收费) | 专有商业 | Apache 2.0 | MIT |
| 适合谁 | 要自托管、预算敏感、要完整闭环的团队 | 已重度使用 LangChain 的商业团队 | 研究/实验、偏好 Notebook 的数据团队 | 网关接入、纯成本与用量监控优先 |
选型建议:需要完全掌控数据、预算有限,且希望一套开源方案同时覆盖追踪、评测与提示词管理,Langfuse 是最平衡的选择;已重度绑定 LangChain 且接受 SaaS 收费,LangSmith 集成体验最好;做研究与实验、喜欢 Notebook 工作流,推荐 Phoenix;只关心成本与用量、想不改代码接入,Helicone 见效最快。
版本迭代
Langfuse 从 2023 年专注 LLM 可观测起步,2024 年初的 2.0 完成架构重写,确立「追踪 + 评分 + 数据集」核心框架;2025 年 3 月的 3.0 带来全新 UI、会话回放,并引入 Redis 队列与对象存储,从「观测工具」走向「平台化」。其迭代节奏约为每两周一个小版本。
| 版本 | 时间 | 变化 | 提升 |
|---|---|---|---|
| v1.x | 2023 年中 | LLM 调用追踪、Token 用量统计、Docker 自托管 | 验证了「LLM 专用可观测」的产品方向,奠定 Trace/Generation 数据模型 |
| v2.0.0 | 2024-01 | 全面重写:新 UI、Python/JS SDK 重构 | 新增评分(Scores)与数据集(Datasets),遥测体积与部署成本大幅下降 |
| v3.0.0 | 2025-03 | 全新 UI、会话回放(Session Replay) | 引入 Redis 队列与 S3 对象存储,追踪查看与加载性能显著提升 |
| v3.1.0 | 2025-04 | 3.0 后首个功能性跟进版本 | 修复自托管已知问题,补强 3.0 周边能力 |
作为开发工具而非模型,Langfuse 没有 MMLU 类基准分数,版本间差异体现在功能与部署方式上。整体趋势是「平台化」:从纯追踪工具扩展为集评测、提示词管理、告警于一体的 LLM 工程平台;自托管依赖从「单 Postgres」变为「Postgres + Redis(+可选 S3)」,选型时需评估基础设施成本。(截至训练数据,可能已有更新版本)
AI 应用场景
场景一:线上故障定位——从翻日志到按 Trace 溯源
阶段:RAG 管道构建 / 线上监控与溯源
解决的问题:RAG 应用答非所问时,传统日志只有一条最终 completion,检索到的上下文片段、截断详情都不可见。Langfuse 把检索、组装、生成记录为同一 Trace 树的多个节点,输入 trace_id 即可复现完整请求链,快速判断问题出在检索(召回不准)还是生成(幻觉)。
具体案例:某 RAG 客服机器人接入 Langfuse 后,线上问题定位从「翻半小时日志」降到「搜索 trace_id 数十秒完成」;通过对比失败 trace 发现约 30% 的坏案例源于检索 top-k 设置过大引入噪声,调整后首答准确率明显提升。
场景二:提示词迭代评测——用数据集回放替代「凭感觉上线」
阶段:提示词工程 / 评测与回归
解决的问题:改一个 prompt 无法判断是否真的变好。Langfuse 用数据集保存一批「输入-期望输出」样本,对旧版与新版 prompt 分别重放并自动打分(支持 LLM-as-judge),用分数决定是否发布。
具体案例:某团队用 200 条标注样本对两个提示词版本离线评测,新版在意图识别准确率上高出 8 个百分点后才被发布;此后每次提示词改动都先过评测再上线,线上回归率明显下降。
场景三:成本与用量治理——知道钱烧在哪里,才能管住成本
阶段:成本监控与配额管理
解决的问题:多团队共用模型 API 时,成本暴涨却不知道是哪个功能或用户在消耗。Langfuse 按模型、用户、会话、标签聚合 token 与成本估算,并支持阈值告警。
具体案例:某平台团队为三个业务线配置成本告警后,定位到一个「失败重试死循环」缺陷,修复后无效 token 消耗下降约 40%,月度模型成本减少约四分之一。
常见误区
误区「Langfuse 就是给大模型调用记日志的,和 ELK 差不多,我直接用 print 也能排查问题。」
正解追踪只是 Langfuse 四分之一的职能。它同时提供数据集(批量管理评测样本)、评分(人工/代码/LLM-as-judge)、提示词版本管理、用量成本分析与告警,形成「观测—评测—迭代」闭环。日志工具只能回答「发生了什么」,Langfuse 还能回答「效果好不好、该不该上线」。尤其评测与提示词管理,是日志工具完全没有的能力。
为何常见:多数教程只展示 trace 列表与模型调用详情,上手第一眼看到的就是追踪页面,容易让人把它简化理解为「LLM 版日志系统」。
误区「要装 Postgres、Redis、S3、对象存储一堆组件,太重了,不如直接用云服务。」
正解v3 之前最小部署确实只需一个容器加 Postgres;v3 起额外需要 Redis(后台任务队列),但仍是轻量组件,单实例即可。S3/MinIO 只在启用会话回放(录制网页交互)时才需要。小团队用单机 docker compose 即可跑通全部核心功能,无需 Kafka、ELK 之类的重型组件。
为何常见:v3 部署文档列出的组件比 2.x 多,且部分教程把「可选组件」和「必需组件」一起罗列,误导读者以为全部都要装。
误区「每次调用都要发网络请求上报,我的 API 延迟肯定会被拖高。」
正解Langfuse Python SDK 采用异步批量上报:数据先写入内存队列,后台线程定时批量发送,上报失败只记日志、不影响业务返回值。若仍担心,可在 SDK 初始化时配置采样率(如 0.1 表示只上报 10% 请求)。异步队列是观测 SDK 的常见设计,对业务接口的延迟影响可忽略。
为何常见:看到 SDK 内部有 HTTP 上报就联想到同步请求,忽略了异步队列的设计,也高估了网络开销的量级。
误区「开源版顶多试用,生产环境必须买 Langfuse Cloud 的企业版。」
正解自托管(MIT 协议)提供完整核心能力:多项目、多成员、追踪、评分、数据集、提示词管理、告警全部可用且不按量收费;企业版额外提供 SSO、审计日志、子域名、私有模型网关等合规与治理能力。预算敏感的团队完全可以用自托管支撑生产。
为何常见:把「托管版的免费额度限制」与「开源版的能力边界」混为一谈;部分商业对比文章也会刻意淡化自托管能力。
面试题
Q1. Langfuse 中最顶层的观测对象是?
- A.Generation(模型调用)
- B.Trace(一次完整请求)← 正确答案
- C.Span(子操作)
- D.Score(评分)
答案:B。Trace 代表一次完整请求,是整个调用链的根节点;Span 与 Generation 都是挂在 Trace 下的子节点,Score 则是对 Trace 或其子节点的评价结果。选节点层级关系时先找根节点即可。
Q2. Python SDK 中用哪个装饰器自动记录函数调用?
- A.@track
- B.@observe← 正确答案
- C.@trace
- D.@monitor
答案:B。langfuse.decorators.observe 是官方提供的装饰器,包裹函数后自动创建 Trace/Span 节点;@track、@trace、@monitor 均不是 Langfuse 的 API,容易与其它监控框架混淆。
Q3. 自托管 Langfuse v3 除 PostgreSQL 外,还必需哪个组件?
- A.Redis← 正确答案
- B.Kafka
- C.Elasticsearch
- D.S3/MinIO
答案:A。v3 起后台任务队列基于 Redis(BullMQ),因此 Redis 成为必需组件;Kafka 与 Elasticsearch 不在官方依赖中;S3/MinIO 仅在启用会话回放媒体存储时才需要,属于选配。
Q4. Python SDK 异步上报场景下,进程退出前应调用哪个方法避免丢数据?
- A.langfuse.flush()← 正确答案
- B.langfuse.send()
- C.langfuse.commit()
- D.langfuse.close()
答案:A。flush() 会阻塞并确保内存队列中的数据全部上报完成,适合在脚本结束或 worker 关闭前调用;send/commit 不是官方方法,close 在部分版本中语义不保证清空队列,不要依赖。
Q5. Langfuse 核心仓库的开源协议是?
- A.Apache 2.0
- B.MIT← 正确答案
- C.GPL-3.0
- D.专有商业
答案:B。Langfuse 核心仓库采用 MIT 协议,允许自由使用、修改与商用,这是它成为自托管首选的重要前提;Apache 2.0 是 Phoenix 的协议,LangSmith 则是专有商业产品。
Q6. 以下哪些是 Langfuse 的核心能力?
- A.Trace 追踪与检索← 正确答案
- B.数据集与离线评测← 正确答案
- C.提示词版本管理← 正确答案
- D.LLM 网关与限流
答案:ABC。追踪、数据评测、提示词管理是 Langfuse 三大核心支柱;网关代理与限流是 Helicone 的定位,Langfuse 采用 SDK 埋点而非请求代理,不提供网关能力。
Q7. 关于 Trace 树结构,以下描述正确的是?
- A.Trace 是根,Span/Generation 是其子节点且可多层嵌套← 正确答案
- B.Generation 是根节点,Trace 挂在它之下
- C.Trace 与 Span 平级,不可互相嵌套
- D.每条 Trace 只允许一个 Generation
答案:A。Trace 是树的根,Span、Generation、Event 都是它的后代节点,且 Span 内部可以继续嵌套 Span,形成任意深度的调用树;Generation 是叶子层级的模型调用,不存在「Generation 包含 Trace」的逆向关系。
Q8. 下列哪些是 Langfuse 官方支持的接入方式?
- A.OpenAI 客户端包装器← 正确答案
- B.LangChain 回调函数← 正确答案
- C.LlamaIndex 回调← 正确答案
- D.Nginx 反向代理
答案:ABC。官方提供 langfuse.openai 包装客户端、LangChain 回调处理器(CallbackHandler)、LlamaIndex 回调等 30+ 集成;Nginx 反向代理是普通 Web 层组件,不是 Langfuse 的对接方式。
Q9. 如何避免开发环境与生产环境的数据互相污染?
- A.每个环境一个项目,用不同的 PUBLIC_KEY 隔离← 正确答案
- B.LANGFUSE_HOST 指向同一实例即可
- C.用 @observe(enabled=False) 关闭上报
- D.把 SECRET_KEY 删除即可隔离环境
答案:A。项目(Project)是 Langfuse 的数据隔离边界,每个环境创建独立项目并使用对应的 LANGFUSE_PUBLIC_KEY / SECRET_KEY,数据会写入不同项目;host 相同只会增加跨环境混读风险,删除密钥则会导致全部上报失败。
Q10. 关于 Langfuse 生产部署,下列说法正确的有?
- A.SDK 的 sampling_rate 参数可控制数据量← 正确答案
- B.生产环境应初始化管理员并关闭注册← 正确答案
- C.观测数据只能保存在 Langfuse 云上
- D.官方支持 Kubernetes/Helm 部署← 正确答案
答案:ABD。sampling_rate 是官方文档明确的采样方案,可在高流量下控制存储成本;生产环境应通过 LANGFUSE_INIT_* 初始化管理员并开启 AUTH_DISABLE_SIGNUP;官方提供 Helm Chart 支持 K8s 部署。数据存储位置由部署方式决定,自托管数据完全在本地,不存在「只能上云」的限制。
参考来源
- webpageLangfuse 官网产品介绍、定价与登录入口
- webpageGitHub 仓库源码、Issue 与 Release 记录