优化 LangSmith 上的跟踪支出

问题设置

在本教程中，我们采用一个现有组织，该组织具有三个工作区，每个部署阶段一个（开发、暂存和生产）：

了解您当前的使用情况

任何优化过程的第一步都是了解当前使用情况。LangSmith 提供了两种方法来做到这一点：Usage Graph 和 Invoices。

使用情况图

通过使用情况图表，我们可以检查最近消耗了多少基于使用情况的定价指标。它不会直接显示 spend （我们稍后会在发票草稿上看到）。

我们可以导航到 Usage Graph （使用情况图）Settings -> Usage and Billing -> Usage Graph.

我们在上图中看到，LangSmith 对两个使用量度收费：

LangSmith 跟踪（基本费用）
LangSmith 跟踪（延长数据保留升级）。

第一个指标跟踪您发送到 LangSmith 的所有跟踪。第二个跟踪也具有延长 400 天数据保留期的所有跟踪。有关更多详细信息，请参阅我们的数据保留概念文档。请注意，这些图表看起来 identical，这将在本教程的后面部分发挥作用。

LangSmith Traces 使用情况是按工作区测量的，因为工作区通常代表开发环境（如我们的示例所示），或组织内的团队。作为 LangSmith 管理员，我们希望详细了解每个单元的支出。在在这种情况下，我们只想削减支出，我们可以首先关注负责大部分成本的环境，以获得最大的节省。

注意

LangSmith 的 Usage Graph 和 Invoice 使用术语tenant_id以引用工作区 ID。它们是可互换的。

在上图中，绝大多数使用都在 ID 为c27dd32c-7c80-4e8c-acde-bfcb67a90ab2.我们可以转到Settings -> Workspaces，然后将鼠标悬停在Workspace ID按钮查找具有匹配 ID 的 ID。在在本例中，它是 Prod 工作区：

发票

我们了解跟踪方面的使用情况，但现在需要将其转化为支出。为此，我们前往Invoices标签。屏幕上显示的第一张发票是您当月的草稿 invoice，显示您本月到目前为止的流动支出。

在上面的 GIF 中，我们看到 LangSmith Traces 的费用按“tenant_id”（即 Workspace ID）细分，这意味着我们可以跟踪跟踪支出在我们的每个工作区。在 6 月的前几天，~2,000 美元的总支出的绝大部分都用于我们的生产工作。此外，该工作区的大部分支出都用于延长数据保留跟踪升级。

这些升级有两个原因：

您使用延长数据保留跟踪，这意味着默认情况下，您的跟踪将保留 400 天
您使用基本数据保留跟踪，并使用自动延长跟踪数据保留的功能（请参阅我们的自动升级概念文档)

鉴于每天的总跟踪数等于每天的延长保留跟踪数，则很可能是如果该组织在任何地方都使用扩展数据保留跟踪。因此，我们首先优化保留设置。

优化方案 1：管理数据保留

LangSmith 根据跟踪的数据保留情况收取不同的费用（请参阅我们的数据保留概念文档），其中，短期跟踪比持续时间较长的跟踪成本低一个数量级。在这个优化中，我们将展示如何在不牺牲历史可观测性的情况下获得数据保留的最佳设置，以及显示它对我们的账单的影响。

更改新项目的组织级别保留默认值

我们导航到Usage configuration选项卡，然后查看我们的组织级别保留设置。修改此设置会影响所有新项目，这些项目在我们组织的所有工作区中创建。

注意

为了向后兼容，较旧的组织可能默认为 Extended。在 6 月 3 日之后创建的组织已将此默认为 Base。

更改项目级别保留默认值

我们现有的项目尚未更改其数据保留设置，因此我们可以在各个项目页面上更改这些设置。

我们导航到Projects -> <your project name>，单击 Data retention （数据保留）下拉列表，然后将其修改为 Base retention（基本保留）。如使用 Organization Level （组织级别）设置时，这只会影响以后跟踪的保留期（和定价）。

保留大约一定比例的跟踪以延长数据保留期

如果我们关心历史调试，我们可能不希望所有跟踪在 14 天后过期。因此，我们可以利用 LangSmith 的内置功能，可以进行服务器端采样以延长数据保留期。

选择要采样的运行的正确百分比取决于您的使用案例。我们将在这里任意选择 10% 的跑位，但会让用户找到平衡收集罕见事件和成本约束的正确值。

LangSmith 会自动升级与我们的自动化产品中的运行规则匹配的任何跟踪的数据保留期（请参阅我们的运行规则文档）。在 Projects （项目）页面上，单击Rules -> Add Rule，并按如下方式配置规则：

Run rules 匹配 runs 而不是 trace。运行是 LLM 应用程序的 API 处理中的单个工作单元。痕迹是端到端的 API 调用（了解有关 LangSmith 中的跟踪概念的更多信息）。这意味着跟踪可以被视为构成 API 调用的运行树。当运行规则与跟踪中的任何运行匹配时，跟踪的完整运行树升级将保留 400 天。

因此，为了确保我们在跟踪上具有适当的采样率，我们利用了 run rules 的筛选功能。

我们添加一个筛选条件，以仅匹配运行树中的 “root” 运行。这在每条跟踪中是不同的，因此我们的 10% 采样将升级 10% 的跟踪，而不是 10% 的运行，这可能对应于超过 10% 的跟踪。如果需要，我们可以选择添加需要的任何其他筛选条件（例如，附加到我们的跟踪的特定标签/元数据）以实现更有针对性的数据保留外延。在本教程中，我们将坚持使用最简单的条件，并将更高级的过滤保留为锻炼给用户。

注意

如果要将跟踪子集保留 400 天以上以用于数据收集，则可以创建另一个运行规则，该规则将一些运行发送到您选择的数据集。数据集允许您存储跟踪输入和输出（例如，作为键值数据集）、并且将无限期地保留，即使在删除跟踪后也是如此。

7 天后看到结果

虽然每天的跟踪总数保持不变，但延长的数据保留跟踪被大大减少。

这意味着发票上，我们在过去 7 天内只花费了大约 900 美元，而前 4 天花费了 2000 美元。这相当于每天减少近 75% 的成本！

优化方案 2：限制使用

在上一节中，我们管理了数据保留设置以优化现有支出。在本节中，我们将使用使用限制来防止将来超支。

LangSmith 有两个使用限制：总跟踪数和延长保留跟踪数。这些对应于我们的两个指标一直在跟踪我们的使用情况图。我们可以结合使用这些来对支出进行精细控制。

要设置限制，我们导航回Settings -> Usage and Billing -> Usage configuration.在页面底部，允许您设置每个工作区的使用限制。对于每个工作区，将显示两个限制，以及使用成本估算：

让我们从设置生产使用限制开始，因为这是大部分支出的来源。

设置良好的总跟踪限制

选择正确的 “total traces” 限制取决于您将发送到 LangSmith 的预期跟踪负载。您应该在设定限制之前，请清楚地考虑您的假设。

例如：

当前负载：我们的一代 AI 应用程序每秒被调用 1.2-1.5 次，每个 API 请求都有一个与之关联的跟踪。这意味着我们每天记录大约 100,000-130,000 条跟踪
预期负载增长：我们预计在不久的将来，规模将翻一番。

根据这些假设，我们可以进行快速的粗略计算，以获得以下的良好限制：

limit = current_load_per_day * expected_growth * days/month
      = 130,000 * 2 * 30
      = 7,800,000 traces / month

我们单击表格右侧的 Prod 行的编辑图标，并可以按如下方式输入此限制：

注意

如果设置时没有延长数据保留跟踪限制，则最大成本估算器假定所有跟踪都使用延长数据保留。

通过延长数据保留限制来削减最大支出

如果我们不是一家大企业，我们可能会为每月 ~$40k 的账单感到不寒而栗。

我们从优化方案 1 中发现，降低成本的最简单方法是管理数据保留。限制也是如此。如果我们只希望将 ~10% 的跟踪保持在 14 天左右，我们可以设置最大值限制我们可以保留的高保留痕迹。那将是.10 * 7,800,000 = 780,000.

正如我们所看到的，最高成本从每月 ~40k 削减到每月 ~7.5k，因为我们不再允许那么多昂贵的数据保留升级。这让我们确信平台上的新用户不会意外导致成本飙升。

注意

延长的数据保留限制可能会导致除跟踪以外的功能在达到后停止工作。如果您打算使用此功能，请在此处阅读有关其功能的更多信息。

设置开发/暂存限制并查看跨工作区的总支出限制

按照对开发和暂存环境的相同逻辑，我们将限制设置为生产的 10% 每个工作区的使用限制。

虽然这适用于我们的使用模式，但设置良好的开发和暂存限制可能会有所不同，具体取决于您使用 LangSmith 的使用案例。例如，如果您在开发或暂存中将 evals 作为 CI/CD 的一部分运行，则可以希望更自由地设置使用限制以避免测试失败。

现在，我们的限制已设置完毕，我们可以看到 LangSmith 显示了所有工作区的最大支出估算值：

有了这个估算器，我们可以确信我们不会在月底收到意外的信用卡账单。

总结

在本教程中，我们学习了如何：

通过数据保留策略降低现有成本
使用限制防止未来超支

如果您对进一步优化支出有任何疑问，请联系 support@langchain.dev。