先说结论:什么人适合自建
如果你符合下面任意两条,自建 Langfuse 大概率划算:
- 合规约束:医疗、金融、政务、欧洲 GDPR、中国网信办数据不出境——用户 prompt 和 LLM 回复属于敏感内容,不能流到第三方 SaaS
- 月 trace 量 ≥ 500 万:SaaS 按条数或团队席位计费,量上来后每月几千到几万刀,自建一台 ClickHouse 就扛了
- 已经在跑 OTel / Prometheus / Grafana:想把 LLM 可观测接进现有基础设施,不想再开一个独立账号体系
- 评估需要深度定制:你的业务 metric 不是 "answer relevancy" 就能概括,要能自己写 evaluator 代码、接内部 RAG、调内部裁判模型
- 需要本地/内网可用:有离线调研、私有云交付、断网演示等场景
反过来说,如果你只是"做个 demo"、"团队 3 人"、"一天几千次调用",用 LangSmith Plus 或 Braintrust 的免费档,比自建省心得多。
本教程的立场
我们不会黑任何一家 SaaS——LangSmith、Braintrust、Helicone、Phoenix 都很好用。选 Langfuse 的核心原因只有一个:源码在你这边,数据在你这边,定制能力最强。如果这两点对你不重要,请理性选择 SaaS。
我们不会黑任何一家 SaaS——LangSmith、Braintrust、Helicone、Phoenix 都很好用。选 Langfuse 的核心原因只有一个:源码在你这边,数据在你这边,定制能力最强。如果这两点对你不重要,请理性选择 SaaS。
LLM 可观测到底要看什么
传统 APM(Datadog / New Relic)看的是请求链路、CPU、延迟。LLM 应用的核心观测面不止这些:
Trace / Span
一次用户对话可能触发 N 次 LLM 调用 + M 次工具调用 + 若干次向量检索。把它们挂在同一棵 trace 树上,才能定位"到底慢在哪、错在哪"。
Prompt / Completion 原文
出 bug 90% 是 prompt 出了问题或输入含脏数据。必须能看到每次调用的完整 prompt 与模型返回(含 tool_calls)。
Token / Cost
按模型、按 endpoint、按用户、按 tenant 聚合的 token 与成本,一周就能发现某个 prompt 膨胀了 3 倍。
Score / Evaluation
每一次调用除了"成功/失败",还要有业务质量分:answer relevancy、faithfulness、toxicity……可以由 LLM-as-Judge、规则、人工三种方式产生。
Session / User
trace 是一次调用,session 是一通对话,user 是长期画像。只有拼成这三层,才能回答"这个用户为什么不满意"。
Prompt 版本
Prompt 在生产会频繁迭代,版本号 + 环境 label(prod/staging)是基础能力。没它就做不了 A/B 和回滚。
Dataset
评估的"金标准集"。从生产 trace 圈出,CI 跑回归,模型/prompt 每次升级都跑一次,挡住 regressive 变更。
SaaS 对比自建:一张表看懂
| 维度 | LangSmith (SaaS) | Braintrust (SaaS) | Helicone (SaaS) | Langfuse (自建) | Phoenix (自建 / SaaS) |
|---|---|---|---|---|---|
| 数据主权 | 在 LangChain 服务器 | 在 Braintrust 服务器 | 在 Helicone 服务器 | 自己 | 自建时自己 |
| 开源协议 | 闭源 | 闭源 | 部分开源 | MIT + EE | Elastic v2 |
| Prompt 管理 | ✔ | ✔ | 弱 | ✔✔ 版本+label | 弱 |
| Dataset + CI | ✔ | ✔✔ 强项 | ✖ | ✔ | ✔ |
| LLM-as-Judge | ✔ | ✔ | ✖ | ✔ 内置+自定义 | ✔ |
| OTel 兼容 | 部分 | 部分 | ✔ | ✔ 原生 OTLP | ✔✔ |
| 价格(100M events/月) | ≈ $5000+ | ≈ $3000+ | ≈ $1500+ | 自建成本(~$500 硬件) | 自建成本 |
| 零到可用 | 10 分钟 | 10 分钟 | 10 分钟 | 10 分钟(docker)/ 1 天(K8s) | 10 分钟 / 1 天 |
简单来说:
- LangSmith 生态最广,跟 LangChain/LangGraph 零配置,缺点是闭源、贵、数据在 US
- Braintrust 评估 + dataset 做得最精致,eval playground 丝滑
- Helicone 轻量 gateway 思路,接入最快,但功能深度一般
- Langfuse 本章主角——功能完整(trace/prompt/dataset/eval 都齐)、MIT 核心、有商业版 EE 兜底企业需求
- Phoenix(Arize)OTel 原生,偏"评估与漂移检测",模型监控味道更浓
自建的隐形成本
别只看服务器那几百刀——自建真正的成本在人力:
一次性成本
- Helm chart / docker compose 熟悉 ≈ 0.5 人日
- ClickHouse / Postgres / Redis / S3 五件套部署 ≈ 1 人日
- SDK 接入业务代码 ≈ 1-3 人日
- 认证(OIDC / SSO)对接 ≈ 0.5 人日
长期成本
- 版本升级(~每月 1 次)
- ClickHouse 扩容与慢查询调优
- 对象存储成本监控
- 备份、灾难恢复演练
- SSO/权限变更响应
如果团队里没一个人对 ClickHouse 或 K8s 有基础,坦白说——先用 SaaS,业务跑稳了再自建。
一个真实的决策路径
- MVP 阶段:用 Langfuse Cloud(SaaS 版)免费档或 LangSmith Plus,别自建,把业务跑通
- 产品化:流量起来,观察月度 trace 量。< 500 万条继续 SaaS;> 500 万且有合规要求,评估自建
- 规模化:1000 万 + / 月或数据主权硬要求,自建 Langfuse,从 docker compose 起步,平稳后迁 K8s
- 平台化:多业务线共用时,引入 Langfuse 的 organization + project 做 tenant 隔离,对接公司 SSO
一个小细节
Langfuse 的 SDK 是通用的——先用 Langfuse Cloud,哪天想自建,只改
Langfuse 的 SDK 是通用的——先用 Langfuse Cloud,哪天想自建,只改
LANGFUSE_HOST 环境变量就切到自建实例,业务代码零改动。这也是我推荐它作为起点的原因:不锁定。
本教程的路线
下一章开始,我们按"先懂架构 → 本地跑通 → SDK 接入 → 深入四大功能 → 上生产 → 压成本"的顺序走:
- 第 2 章:Langfuse 的七个组件与数据流
- 第 3 章:docker compose 起 demo,UI 过一遍
- 第 4 章:Python / TS / OTel 三种 SDK 接入
- 第 5 章:Prompt 版本化与灰度
- 第 6 章:Dataset 与 CI 回归
- 第 7 章:Evaluation(LLM-as-Judge + 自定义)
- 第 8 章:K8s + Helm 生产部署
- 第 9 章:ClickHouse 调优与成本治理
- 第 10 章:端到端接一个真实客服 Agent
本章小结
- LLM 可观测 ≠ APM,至少要看 trace/prompt/token/score/session/version/dataset 七个面
- SaaS(LangSmith/Braintrust/Helicone)快,自建(Langfuse/Phoenix)自由,选哪个看数据主权、量级、定制深度
- 自建真正的成本是人力,不是硬件——没 ClickHouse / K8s 基础就先别自建
- Langfuse 的独特优势:MIT 核心 + EE 商业兜底 + SDK 跟 Cloud 完全兼容(不锁定)
- 本教程十章走完,你会有一套能扛 1000 万 trace/日 的自建平台