在 LLM 应用规模化部署的背景下，Langfuse 作为开源 LLM 工程平台，面临着海量追踪数据存储与查询的成本挑战。2024 年底，Langfuse 团队完成了从 PostgreSQL 到 ClickHouse 的架构迁移，这一转变不仅提升了查询性能，更重要的是为成本优化提供了全新的技术基础。本文将深入探讨 ClickHouse 与 Langfuse 集成的成本优化架构，聚焦向量嵌入存储压缩、事件数据冷热分层、资源配额动态调整三大核心工程问题。
一、向量嵌入存储的压缩策略
1.1 向量存储的成本挑战
每个 LLM 追踪包含的向量嵌入（通常为 1536 维浮点数数组）约占用 6KB 存储空间。对于日处理百万级追踪的系统，仅向量存储每月就产生数 TB 的数据增长。传统行式数据库如 PostgreSQL 在处理此类数据时面临双重挑战：存储效率低下和查询性能瓶颈。
1.2 ClickHouse 列式存储的压缩优势
ClickHouse 采用列式存储架构，为向量压缩提供了理想的技术基础：
压缩实现原理：
- 列式布局：所有追踪的向量数据连续存储，形成高密度数据块
- 字典编码：对低基数向量（如相似语义的嵌入）进行字典映射
- 浮点量化：将 32 位浮点数转换为 16 位或 8 位定点数
- ZSTD 压缩：在编码基础上应用高效压缩算法
工程参数配置：
CREATE TABLE langfuse_traces (
trace_id UUID,
model String CODEC(ZSTD(3)),
prompt String CODEC(ZSTD(5)),
completion String CODEC(ZSTD(5)),
embeddings Array(Float32) CODEC(Delta, ZSTD(5)),
cost Float32 CODEC(Delta, ZSTD(3)),
timestamp DateTime64(3) CODEC(DoubleDelta, ZSTD(3)),
project_id String CODEC(ZSTD(3))
) ENGINE = MergeTree()
ORDER BY (project_id, toDate(timestamp), trace_id)
PARTITION BY toYYYYMM(timestamp)
TTL timestamp + INTERVAL 90 DAY;
1.3 压缩效果实测数据
根据 Langfuse 生产环境数据，不同数据类型的压缩比表现：
- 模型名称字段：50:1（低基数，高度重复）
- 时间戳字段：15:1（Delta 编码 + DoubleDelta 编码）
- 向量嵌入字段：3:1（高熵数据，压缩难度大）
- 整体加权平均：10:1
这意味着 100GB 原始追踪数据在 ClickHouse 中仅占用 10GB 存储空间，月度存储成本从 $1000 降至 $100（基于 AWS EBS gp3 定价）。
二、事件数据的冷热分层架构
2.1 三层存储策略设计
基于数据访问频率和性能要求，设计三级存储架构：
Hot 层（0-7 天）：
- 存储介质：NVMe SSD
- 访问特征：实时仪表盘、调试查询
- 性能要求：亚秒级响应
- 成本：~$100/TB/ 月
Warm 层（8-90 天）：
- 存储介质：S3 作为 ClickHouse 磁盘
- 访问特征：周度报告、模型对比
- 性能要求：1-5 秒响应可接受
- 成本：~$23/TB/ 月
Cold 层（90 + 天）：
- 存储介质：S3 Glacier Deep Archive
- 访问特征：合规审计、历史分析
- 性能要求：批量作业，小时级延迟可接受
- 成本：~$1/TB/ 月
2.2 ClickHouse TTL 与存储策略集成
通过 ClickHouse 的 TTL 功能实现自动数据迁移：
-- 创建支持分层存储的表
CREATE TABLE langfuse_traces_tiered (
-- 字段定义同上
) ENGINE = MergeTree()
ORDER BY (project_id, toDate(timestamp), trace_id)
PARTITION BY toYYYYMM(timestamp)
TTL
timestamp + INTERVAL 7 DAY TO DISK 'hot_ssd',
timestamp + INTERVAL 90 DAY TO VOLUME 'warm_s3',
timestamp + INTERVAL 365 DAY DELETE;
2.3 S3 生命周期策略配置
{
"Rules": [
{
"ID": "HotToWarm",
"Status": "Enabled",
"Filter": {"Prefix": "clickhouse/hot/"},
"Transitions": [
{
"Days": 7,
"StorageClass": "STANDARD_IA"
}
]
},
{
"ID": "WarmToCold",
"Status": "Enabled",
"Filter": {"Prefix": "clickhouse/warm/"},
"Transitions": [
{
"Days": 90,
"StorageClass": "GLACIER"
}
]
}
]
}
2.4 成本效益分析
假设客户日生成 100GB 追踪数据（压缩后 10GB）：
- 全热存储方案：3.65TB × $100 = $365 / 月
- 分层存储方案：
- Hot 层（700GB）：$70 / 月
- Warm 层（830GB）：$19 / 月
- Cold 层（2.75TB）：$2.75 / 月
- 总计：$91.75 / 月
- 年度节省：($365 - $91.75) × 12 = $3,279
三、智能采样与数据保留策略
3.1 95/5 规则与采样算法
基于 LLM 追踪的特性，95% 的追踪为正常成功调用，5% 包含异常或高价值信息。设计自适应采样策略：
def should_keep_full_trace(trace):
# 保留所有异常和重要追踪
if (trace.status != "success" or
trace.cost > 0.10 or # 高成本
trace.latency > 10.0 or # 高延迟
trace.evaluation_score < 0.6 or # 低质量
trace.user_feedback == "negative"):
return True
# 正常追踪：10%随机采样
if hash(trace.id) % 10 == 0:
return True
# 其他：仅保留指标数据
return False
def extract_metrics_only(trace):
"""提取并存储精简指标数据"""
return {
"model": trace.model,
"input_tokens": trace.input_tokens,
"output_tokens": trace.output_tokens,
"cost": trace.cost,
"latency": trace.latency,
"status": trace.status,
"timestamp": trace.timestamp
}
3.2 存储空间优化效果
日处理 100 万追踪的场景：
- 无采样：100 万 × 25KB = 25GB / 日
- 智能采样后：
- 5% 异常追踪（5 万）：1.25GB
- 10% 正常采样（9.5 万）：2.37GB
- 85% 仅指标（85 万）：1.71GB
- 总计：5.33GB / 日
- 存储减少：78.7%
3.3 渐进式数据降级策略
针对合规性要求（如 7 年数据保留），实施渐进式数据降级：
| 时间范围 | 数据完整性 | 存储格式 | 预估成本 |
|---|---|---|---|
| 0-1 年 | 完整追踪 | 所有字段 | $100/TB/ 月 |
| 1-3 年 | 压缩追踪 | 移除向量，保留文本 | $23/TB/ 月 |
| 3-7 年 | 元数据 | 仅模型、成本、时间戳 | $12.5/TB/ 月 |
| 7 年以上 | 聚合摘要 | 月度汇总 | $1/TB/ 月 |
四、资源配额动态调整机制
4.1 基于负载模式的资源调度
ClickHouse 集群资源需要根据查询模式动态调整：
监控指标体系：
- 查询并发数（QPS）
- 平均查询延迟（P95，P99）
- 内存使用率（峰值 / 均值）
- 磁盘 I/O 吞吐量
- 压缩率变化趋势
动态调整策略：
resource_adjustment_rules:
- condition: "qps > 100 AND p95_latency > 2000ms"
action: "scale_up_compute_nodes"
parameters: {nodes: +2, instance_type: "c6g.4xlarge"}
- condition: "avg_memory_usage < 40% FOR 24h"
action: "scale_down_memory"
parameters: {memory_per_node: -25%}
- condition: "compression_ratio < 8:1"
action: "recompress_table"
parameters: {codec: "ZSTD(7)", background: true}
4.2 查询优化与索引策略
通过优化查询模式减少资源消耗：
分区策略：
-- 按日期分区，支持时间范围快速过滤
PARTITION BY toYYYYMM(timestamp)
-- 按项目分区，支持多租户隔离
PARTITION BY project_id
排序键设计：
-- 优化常见查询模式
ORDER BY (project_id, toDate(timestamp), model, status)
跳过索引配置：
-- 为高频过滤字段创建跳过索引
INDEX idx_model model TYPE bloom_filter GRANULARITY 4
INDEX idx_status status TYPE set(10) GRANULARITY 1
INDEX idx_cost cost TYPE minmax GRANULARITY 4
4.3 成本监控与告警体系
建立多维度的成本监控：
-- 每日成本分析查询
SELECT
toDate(timestamp) as date,
project_id,
model,
sum(cost) as total_cost,
count() as trace_count,
avg(cost) as avg_cost_per_trace,
sum(cost) / sum(input_tokens + output_tokens) as cost_per_token
FROM langfuse_traces
WHERE timestamp >= today() - 30
GROUP BY date, project_id, model
ORDER BY total_cost DESC
LIMIT 100;
告警规则配置：
- 存储成本日增幅 > 10%
- 单项目成本占比 > 总成本 30%
- 查询成本（CU 消耗）异常波动
- 压缩率下降 > 20%
五、工程实施清单与最佳实践
5.1 部署架构检查清单
- ClickHouse 版本 ≥ 23.3（支持高级压缩编解码器）
- 存储后端配置：SSD（Hot）、S3（Warm）、Glacier（Cold）
- 网络拓扑：ClickHouse 节点与 S3 同区域部署
- 备份策略：每日快照 + 跨区域复制
- 监控集成：Prometheus + Grafana 仪表盘
5.2 表结构优化清单
- 为每个字段选择合适的 CODEC
- 设置合理的分区键（通常按时间）
- 设计高效的 ORDER BY 键
- 配置 TTL 自动清理规则
- 创建必要的跳过索引
5.3 成本控制参数参考
| 参数类别 | 推荐值 | 说明 |
|---|---|---|
| 热数据保留 | 7 天 | 平衡性能与成本 |
| 暖数据保留 | 90 天 | 覆盖季度分析需求 |
| 采样率 | 10% | 保持统计显著性 |
| ZSTD 压缩级别 | 3-5 | 平衡压缩率与 CPU 消耗 |
| 合并操作间隔 | 4 小时 | 避免频繁合并影响性能 |
5.4 性能基准测试指标
- 数据写入吞吐量：≥ 50K traces / 秒
- 点查询延迟：< 100ms（P95）
- 聚合查询延迟：< 2 秒（P95，7 天数据）
- 压缩率：≥ 8:1（整体）
- 存储成本：< $0.10/GB/ 月（分层后）
六、案例研究：从 $15K / 月到 $2.4K / 月的优化实践
某 B2B SaaS 公司使用 Langfuse 监控其 AI 客服系统，日处理 50 万 LLM 调用。初始采用 Langfuse Cloud 服务，月度成本达 $15,000。通过实施本文所述优化策略：
优化阶段与效果：
- 智能采样（第 1 月）：成本从 $8,000 降至 $2,500
- 自托管迁移（第 2 月）：基础设施成本 $1,800 / 月
- 存储分层（第 3 月）：存储成本从 $5,000 降至 $400
- 查询优化（第 4 月）：计算成本从 $2,000 降至 $200
最终效果：月度总成本 $2,400，年节省 $151,200，同时获得无限数据保留和亚秒级查询性能。
结论
ClickHouse 与 Langfuse 的集成为 LLM 可观测性提供了经济高效的解决方案。通过列式存储压缩、智能数据分层、自适应采样和动态资源管理四大技术支柱，企业可以在保持完整可观测能力的同时，将存储成本降低 75-90%。关键成功因素包括：
- 数据感知的架构设计：理解 LLM 追踪的数据特征，针对性优化
- 自动化运维：通过 TTL、生命周期策略减少人工干预
- 持续监控优化：建立成本与性能的反馈循环
- 灵活部署选项：根据规模选择云服务或自托管
随着 LLM 应用的进一步普及，成本优化的可观测性架构将成为企业 AI 战略的核心竞争力。ClickHouse 与 Langfuse 的组合为此提供了经过生产验证的技术路径。
资料来源
- Langfuse 官方博客 - Infrastructure Evolution (2024-12)
- ClickHouse 技术文档 - Compression in ClickHouse
- Medium 技术文章 - Cost Optimization in LLM Observability (2025-11)
- AWS 官方文档 - S3 Storage Classes and Lifecycle Policies
- Langfuse 生产环境监控数据（匿名化）