自托管 LLM 可观测性:我们实测了什么
2026-06-13 · self-hosting, benchmark, observability
我们的发现
插桩开销是个伪问题:我们测的每个 SDK 给一次典型 LLM 调用增加的开销都低于 0.05%(尽管彼此相差约 7 倍)。真正的差别在于运维重量。Arize Phoenix 以单个容器起来(1.35 GB 镜像、约 400 MB 空闲内存,OTLP 摄取端到端验证通过);Langfuse 是一个完整平台,启动顺利,但作为 6 服务栈运行,空闲内存约 2.1 GB。按需求匹配占用。(测试环境 @ 2026-06,WSL2 + Docker)
大多数"最佳自托管可观测性"清单从没真正跑过这些工具。我们跑了。自托管时有两个问题最关键:SDK 把我的应用拖慢多少,以及后端运维起来要花我多少。下面是我们的实测。
1. 插桩开销(客户端)
我们对每个 SDK 用内存导出器(无网络)计时 50,000 个 span,并与未插桩的基线对比。单 span 开销,以及它占一次典型 500 ms LLM 调用的比例:
| SDK | 每 span 开销 | 占 500ms 调用比例 |
|---|---|---|
| OpenTelemetry(原始) | ~34 µs | 0.007% |
| Traceloop / OpenLLMetry | ~37 µs | 0.007% |
| Langfuse SDK | ~243 µs | 0.049% |
结论:对 LLM 工作负载别再纠结插桩开销 —— 模型调用本身要主导 2000 倍以上。那约 7 倍的差距(更丰富的观测模型每 span 成本更高)只在 span 量极大的非 LLM 热路径上才有意义。
2. 运维重量(自托管占用)
我们用每个后端的官方 Docker 配置启动它,并测量其占用:跑多少个容器、磁盘镜像大小、健康后的空闲内存、到就绪端点的时间,以及是否开箱即支持 OpenTelemetry(OTLP)摄取。(测试环境 @ 2026-06,WSL2 + Docker,实测)
| 工具 | 容器数 | 镜像大小 | 空闲内存 | 就绪时间 | OTLP 摄取 |
|---|---|---|---|---|---|
| Arize Phoenix | 1 | 1.35 GB | ~400 MB | 19 秒 | 是(端到端验证) |
| Langfuse | 6 | 1.16 GB | ~2.1 GB (仅 web 容器约 1.1 GB) | ~10 秒 (镜像已缓存) | 不适用(自家 SDK,非 OTLP 原生) |
| SigNoz | 多服务 | — | — | 未测 | 本环境未测* |
Arize Phoenix 处在轻量这一端:一个即插即用容器、约 400 MB 空闲内存、20 秒内就绪,并且立即接受标准 OTLP 追踪。如果你想五分钟内跑起自托管追踪,就该找这种形态。
Langfuse 这次启动顺利 —— 在镜像已缓存的情况下整个栈约 10 秒起来。但它是一个完整平台,而非单容器即插即用:一个 6 服务栈(web、worker、Postgres、ClickHouse、缓存、对象存储),空闲内存约 2.1 GB,仅 web 容器就约 1.1 GB。它也是通过自家 SDK 而非原生 OTLP 摄取。有一个值得提前知道的主机端口坑:它自带的 MinIO 对象存储默认用 :9090,在很多开发机上会与 Prometheus 冲突 —— 启动前先改掉。它在提示词管理、评测和留存方面强得多;只是要为运维重量做好预算。
SigNoz 我们在自己的环境里没能干净地测出来:它首次启动的 init 容器在我们的测试网络上下载一个 GitHub release 资产时被卡住,导致整个栈始终未达健康状态。我们如实把它标为本环境未测 —— 这是我们这边的环境/网络问题,不是 SigNoz 的缺陷 —— 而不是发布一个我们并未真正观测到的数字。
* SigNoz:init 容器在我们的测试网络上下载 GitHub release 资产时被卡住(环境问题,非 SigNoz 缺陷)。
怎么读这些数据
按任务匹配占用。需要能快速起来的轻量、OpenTelemetry 原生追踪?单容器工具胜出。需要给团队用的提示词管理、评测、数据集和长留存?完整平台值它的运维重量。别为单容器的需求付多服务的运维成本,反之亦然。
把话说明白的几点保留意见:开销测试测的是客户端 span 成本、内存导出,不是端到端后端延迟;自托管数字来自单一测试环境(WSL2、Docker,测试 @ 2026-06),是占用快照而非压测。Langfuse 的时间受益于已缓存镜像;冷拉取会更久。SigNoz 标为本环境未测而非估算。我们正在把这张矩阵扩展到更多工具,并会给每一行都标注"已测试"和日期。详见我们的方法论。
Frequently asked questions
LLM 可观测性插桩会拖慢我的应用吗?
可忽略。在我们的测试里,每个 SDK 给一次典型 500ms LLM 调用增加的开销都低于 0.05%;模型调用要主导数千倍。对 LLM 工作负载,插桩开销不应成为选型依据。
哪个自托管 LLM 可观测性工具运行起来最轻?
在我们的测试里 Arize Phoenix 处在轻量这一端:单个容器、约 1.35GB 镜像、约 400MB 空闲内存,并立即接受 OTLP 追踪。像 Langfuse 这样的完整平台强大得多,但是多服务栈,运维投入更大。
Langfuse 自托管难吗?
在我们 2026-06 的测试里它启动顺利(镜像已缓存约 10 秒),但它是完整平台而非单容器即插即用:一个 6 服务栈(web、worker、Postgres、ClickHouse、缓存、对象存储),空闲内存约 2.1GB,仅 web 容器约 1.1GB。它用自家 SDK 而非原生 OTLP,且自带 MinIO 默认占用主机端口 :9090(在很多开发机上会与 Prometheus 冲突)。在提示词管理、评测和留存方面相当强 —— 只是要为运维重量做好预算。