1. 背景
随着 LLM / AI Agent / RAG 系统进入生产环境，**可观测性（Observability）**成为核心基础设施问题：
● 需要记录 Prompt / Response / Latencies / Errors
● 需要支持 Trace（链路级分析）
● 需要评估（Evaluation / Scoring）
● 需要支持高吞吐（日志级别数据量）
传统日志系统（ELK / Prometheus）无法直接覆盖：
● 语义级 tracing
● Prompt 版本管理
● AI 评估链路
因此需要专门的 LLM Observability 平台。
2. 行业解决方案对比
2.1 方案背景概览
Langfuse
● 类型：开源 / 自建部署
● 现状：GitHub 开源，可自建 Kubernetes / Docker Compose
● 是否免费：核心版本免费
● 设计目标：企业级 LLM Observability，覆盖 Prompt / Response / Trace / Evaluation
● 使用场景：
○ 高吞吐 LLM 系统（百万级/日 trace）
○ 私有化部署，高安全 / 合规要求
● 特点：异步 ingestion、OLAP 存储、对象存储解耦、可水平扩展
LangSmith
● 类型：SaaS / 官方
● 现状：OpenAI 官方提供，集成 OpenAI 产品
● 是否免费：免费试用额度有限
● 设计目标：快速可用的 LLM observability 和实验追踪
● 使用场景：PoC、小团队调试
● 限制：数据不可控，扩展性受限
Helicone
● 类型：SaaS + 部分开源
● 现状：提供 API 级指标采集
● 是否免费：免费额度有限，高 QPS 需付费
● 设计目标：快速收集 API 使用指标
● 使用场景：轻量监控、PoC 项目
● 限制：功能轻量，无法深度 trace / Evaluation，大规模生产受限
2.2 对比表格
2.3工程总结
Langfuse
● 企业生产级首选
● 可自建、可扩展、高吞吐
● 支持完整 trace / evaluation / Prompt 管理
LangSmith
● SaaS 快速 PoC / SDK 调试
● 不适合企业生产
Helicone
● API 指标采集轻量方案
● 适合 PoC 或快速试验
● 功能受限，历史数据管理不便
自研方案
● 仅适合长期研发投入团队
● 成本高、维护复杂
结论：👉结合背景 + 对比表 + Radar 图，Langfuse 是企业 LLM Observability 的最优解。
3. 为什么选择 Langfuse
3.1 核心优势
① 专为 LLM 设计
● Trace / Span / Observation 模型
● Prompt 管理
● Evaluation 内建
② 架构天然支持高吞吐
● 异步 ingestion
● OLAP 分析（ClickHouse）
● 对象存储解耦
③ 可完全自托管
● 数据安全
● 支持私有化部署
● 可接入公司基础设施
④ 可水平扩展
● ingestion 层无状态
● worker 可扩展
● ClickHouse 支持集群
4. 总体架构
Langfuse 不是“主从架构”，而是：👉 事件驱动 + 异步解耦架构
数据流：
Client SDK
↓
Ingestion API（Web）
↓
对象存储（S3/COS） ←（原始数据）
↓
Redis Queue
↓
Worker（异步消费）
↓
ClickHouse（分析数据）
↓
PostgreSQL（元数据）
5. 核心依赖组件（必须）
5.1 必选组件
5.2 对象存储支持
支持所有 S3 API：
● AWS S3
● MinIO
● 腾讯云 COS（✔支持）
● Cloudflare R2
👉 你只需要配置：
S3_ENDPOINT
S3_ACCESS_KEY
S3_SECRET_KEY
S3_BUCKET
6. 部署方式（推荐）
6.1 开发：Docker Compose
6.2 生产：Kubernetes（推荐）
部署组件：
- langfuse-web (Deployment)
- langfuse-worker (Deployment)
- redis (StatefulSet)
- postgres (StatefulSet)
- clickhouse (StatefulSet / Cluster)
- object storage（外部）
6.3 对外访问方式（关键）
在 K8S 中：
👉 不会直接暴露 Pod IP
而是：
Client
↓
LoadBalancer / Ingress（统一入口）
↓
Service（ClusterIP）
↓
Pods（多个副本）
👉 外部只需要一个地址：我们使用ETCD/LB7. 高并发是如何解决的（重点）
❗关键结论：
👉 Langfuse 不内置“自动集群负载均衡”
👉 吞吐能力 = 架构设计 + 基础设施能力
7.1 ingestion 层（接收请求）
● 无状态
● 可水平扩展
👉 扩容方式：
replicas: N
👉 由：
● Kubernetes Service
● 或 Nginx / LB
做负载均衡
7.2 解耦核心：异步队列
API → Redis Queue → Worker
👉 好处：
● API 不阻塞
● 支持突发流量
● 削峰填谷
7.3 Worker 扩展
worker replicas ↑ → 吞吐 ↑
7.4 ClickHouse（关键瓶颈）
优化方式：
● 写读分离：
○ CLICKHOUSE_URL
○ CLICKHOUSE_READONLY_URL
● 使用集群（分片 + 副本）
7.5 S3 并发优化
关键参数：
LANGFUSE_S3_CONCURRENT_WRITES
8. 数据淘汰策略
8.1 ClickHouse（推荐 TTL）
ALTER TABLE traces
MODIFY TTL timestamp + INTERVAL 7 DAY DELETE;
👉 自动淘汰，无需人工
8.2 PostgreSQL
无 TTL：👉 用 cron：
DELETE FROM traces WHERE created_at < now() - interval '7 days';
8.3 对象存储（COS / S3）
使用：
👉 Lifecycle Policy
例如：
● 7天后删除
● 或转低频存储
腾讯云 COS ✔支持
9. 最终推荐方案
架构选型：
● K8S 部署
● COS 作为对象存储
● ClickHouse 集群
● Redis 队列
● PostgreSQL
数据策略：
● ClickHouse TTL（主方案）
● COS 生命周期
● PG 定期清理
参考资料
GitHub - langfuse/langfuse: 🪢 Open source LLM engineering platform: LLM Observability, metrics, evals, prompt management, playground, datasets. Integrates with OpenTelemetry, Langchain, OpenAI SDK, LiteLLM, and more. 🍊YC W23 · GitHubLangfuse - 中文概述 - Langfuse