大模型观测选型，更要看评测资产迁移

Langfuse、Phoenix 和 LangSmith 都能通过 OTLP 接收 OpenTelemetry spans。按原文的判断，只要应用输出的是标准 spans，追踪数据发到哪里，主要是配置选择。真正让迁移变麻烦的，是积累在平台里的评分、数据集和提示词。

这篇短文的价值，是把选型问题从「谁的追踪界面更好」拉回到许可证、运维、计费和评估流程。不过，它给出的几项结论都有适用前提，尤其是成本比较，不能直接照搬。

能换追踪后端，不等于能迁移整套工作流

span 可以理解为一次操作的追踪记录，例如一次模型调用。多个 spans 串起来，构成一条 trace，帮助开发者还原请求经过了哪些步骤。

原文用下面的命令说明：对于输出标准 spans 的示例应用，可以通过环境变量指定接收端。

OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:6006 python trace_demo.py

要注意的是 OTEL_EXPORTER_OTLP_ENDPOINT：它控制追踪数据发往哪里，并不负责搬走平台里的其他资产。

作者把真正的迁移成本归到三类东西：scores、datasets 和 prompts，也就是评分、数据集和提示词。你可以更换接收 spans 的地址，但没有哪个 exporter 设置会顺带把这些资产迁过去。

追踪协议统一了数据入口，却没有统一平台里的工作资产。

因此，选型时只验证「能不能接入 OpenTelemetry」还不够。还要看评估样本放在哪里、评分结果怎样保存，以及提示词如何管理。这些东西用得越深，迁移时要处理的问题就越多。

许可证、部署和账单，要分开算

原文列出了三个容易被追踪功能掩盖的差异。

首先是许可证。Langfuse 除 ee/ 目录外采用 MIT；Phoenix 的服务器采用 Elastic License 2.0，作者据此提醒不要把它作为替客户托管服务的当然选项；LangSmith 则是闭源产品，自托管只向 Enterprise 提供。对只在团队内部使用的项目，以及要把能力交付给客户的项目，这些差异会影响选择。短文没有展开完整许可条件，不能只凭这一句概括确定具体业务能否使用。

其次是运维。作者给出的对比是：自托管 Langfuse 需要六个容器，Phoenix 则可以用一个进程配合 SQLite 运行。这个差别直接影响起步成本，但原文没有提供同等负载下的性能、可靠性或维护数据，不能把「进程少」直接推导成「生产环境更合适」。

最后是计费单位。Langfuse Cloud 按 traces、observations 和 scores 计费。作者称，每条 trace 有 4 个 spans 时便宜，到 40 个 spans 时则比 LangSmith 更贵。

关键在于，一次请求可能产生多条内部记录。只按请求量估预算，容易漏掉调用链变长后的费用变化。不过，提供的短文没有列出具体套餐、单价和计算过程，也没有完整展示所提到的三种流量形态。这是一条需要代入实际用量验证的成本判断。

我的判断

我赞同作者把选型重点放在评估闭环上。追踪解决的是「这次调用发生了什么」，评估解决的是「改了提示词或模型之后，效果有没有变好」。当样本、评分和日常迭代都围绕某个平台展开，换平台就会牵动整个工作流程。

但「追踪不是决策重点」说得偏满。这个判断有一个明确前提：应用输出标准 spans。短文没有验证三家对同一份数据的展示和处理是否完全一致，也没讨论已经深度接入平台专用 SDK 的情况。

与把评估资产全部放进平台相比，团队也可以在自己的仓库里保留样本和提示词，再让平台承担追踪与结果展示。这样通常需要自行维护更多流程，是否划算要看团队需求。原文没有给两种做法的对照数据，不能替其中任何一种背书。

选型时更该问的是：离开这个平台，需要重建哪些东西？

能拿来做什么

• 为前端 AI 功能或 Node 服务接入追踪时，先确认能否输出标准 OpenTelemetry spans，并实际验证更换 OTLP 接收端后的数据展示。
• 做一次迁移盘点，分别记录 scores、datasets 和 prompts 存在哪里、怎样导出，以及迁移后需要重建哪些评估步骤。
• 估算费用时，同时统计 trace 数量、每条 trace 的内部记录数量和评分量；可以用原文的 4 spans、40 spans 两种形态检查预算对调用链长度有多敏感。
• 决定自托管前，把许可证适用范围和部署维护成本一起纳入评审，再判断六个容器或单进程 SQLite 是否适合自己的使用方式。