优化 LangSmith 的追踪支出

问题设置

在本教程中，我们将基于一个现有的组织进行介绍，该组织拥有三个工作区，分别对应每个部署阶段（开发、预发布和生产）：

了解您当前的使用情况

优化过程的每一步首先需要了解当前的使用情况。LangSmith 提供了两种方法：使用量图（Usage Graph）和发票（Invoices）。

使用图谱

使用量图表让我们可以查看最近消耗了多少基于用量的定价指标。它并不直接显示支出（我们将在稍后的草稿发票中看到）。

我们可以导航到 Settings -> Usage and Billing -> Usage Graph 下的使用图表。

从上图可以看出，LangSmith 收取费用的使用指标有两个：

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

第一个指标跟踪您发送到 LangSmith 的所有追踪。第二个指标跟踪所有具有我们扩展的 400 天数据保留功能的追踪。更多详细信息，请参阅我们的数据保留概念文档。请注意这些图表看起来完全相同，这将在教程的后续部分发挥作用。

LangSmith Traces 的使用量是按工作区（workspace）进行统计的，因为工作区通常代表开发环境（如我们的示例所示），或组织内的团队。作为 LangSmith 管理员，我们希望按每个单位细粒度地了解支出情况。在这种情况下，如果我们只想削减支出，可以首先关注产生大部分成本的环境，以实现最大的节省。

注意

LangSmith 的使用量图表和发票使用术语 tenant_id 来指代工作区 ID。两者可以互换使用。

在上面的图片中，绝大多数使用场景都位于 ID 为 c27dd32c-7c80-4e8c-acde-bfcb67a90ab2 的工作区。我们可以前往 Settings -> Workspaces，并将鼠标悬停在 Workspace ID 按钮上，以找到 ID 匹配的项。在此情况下，它是 Prod 工作区：

发票

我们了解追踪在使用情况中的表现形式，但现在需要将其转化为支出。为此，我们需要前往 Invoices 标签页。屏幕上出现的第一个发票是您当前月份的草稿发票，其中显示了您本月至今的累计支出。

在上面的 GIF 中，我们看到 LangSmith Traces 的费用是按\"tenant_id\"（即 Workspace ID）划分的，这意味着我们可以跟踪每个工作区的追踪支出。在六月初的几天里，约 2,000 美元的总支出的绝大多数都发生在我们的生产工作区中。此外，该工作区中的大部分支出用于扩展数据保留的追踪升级。

这些升级发生有两个原因：

您使用扩展数据保留追踪，这意味着默认情况下，您的追踪将被保留 400 天
您使用基础数据保留跟踪，并利用了一项可自动延长跟踪数据保留的功能（查看我们的自动升级概念文档）

鉴于每日总追踪数等于每日扩展保留追踪数，该组织很可能在所有地方都使用了扩展数据保留追踪。因此，我们首先优化其保留设置。

优化 1：管理数据保留

LangSmith 根据追踪的数据保留策略收取不同费用（请参阅我们的数据保留概念文档），其中短期追踪的费用比长期追踪低一个数量级。在本优化指南中，我们将展示如何在不牺牲历史可观测性的前提下，设置最优的数据保留策略，并说明这将如何影响我们的账单。

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

我们导航到 Usage configuration 标签页，并查看组织级别的保留设置。修改此设置会影响在我们组织中所有工作区中将来创建的新项目。

注意

为了向后兼容，旧的组织可能默认设置为扩展模式。2024年6月3日之后创建的组织则默认设置为基础模式。

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

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

我们导航到 Projects -> <your project name>，点击数据保留下拉菜单，并将其修改为“基础保留”。与组织级别设置一样，这仅会影响后续跟踪的数据保留（和定价）。

保留一定比例的追踪记录以延长数据保留时间

如果我们关心历史调试，可能不希望所有追踪记录在14天后就过期。因此，我们可以利用LangSmith内置的服务器端采样功能来实现更长时间的数据保留。

选择要采样的运行百分比取决于您的使用场景。我们将任意选择10%的运行，但将把找到平衡稀有事件收集与成本约束的正确值留给用户。

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

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

因此，为了确保追踪具有正确的采样率，我们利用运行规则的过滤功能。

我们添加一个过滤条件，仅匹配运行树中的\"根\"运行。由于每个追踪（trace）是独立的，因此我们的 10% 采样将升级 10% 的追踪，而非 10% 的运行；而某些运行可能对应多个追踪，从而导致实际升级的追踪比例超过 10%。如有需要，我们可以选择性地添加其他所需的过滤条件（例如附加在追踪上的特定标签/元数据），以实现更精准的数据保留扩展。为便于本教程讲解，我们将采用最简单的条件，并将更高级的过滤功能留作用户自行练习。

注意

如果您希望出于数据收集目的将部分跟踪记录保留超过 400 天，您可以创建另一个运行规则，将某些运行发送到您选择的集合。集合允许您存储跟踪的输入和输出（例如作为键值对集合），并且即使跟踪被删除后仍会永久保存。

7 天后查看结果

尽管每日追踪总量保持不变，但扩展数据保留的追踪量被大幅削减。

这翻译为发票，我们最近7天仅花费了约900美元，而前4天花费了2000美元。这意味着每日成本降低了近75%！

优化 2：限制使用

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

LangSmith 有两个使用限制：总追踪数和扩展保留追踪数。这些对应于我们在用量图表中持续跟踪的两个指标。我们可以结合使用它们，对支出进行细粒度控制。

要设置限制，我们需要返回到 Settings -> Usage and Billing -> Usage configuration。页面底部有一个表格，允许您为每个工作区设置使用限制。对于每个工作区，会显示两个限制以及成本估算：

让我们首先为生产环境的使用设置限制，因为大部分支出都来自这里。

设置合理的总追踪数限制

选择适当的\"总追踪数\"限制取决于您计划发送到 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 行的编辑图标，然后可以按以下方式输入此限制：

注意

当未设置扩展数据保留跟踪限制时，最大成本估算器假设所有跟踪均使用扩展数据保留。

将最大支出与扩展数据保留限制相结合

如果我们不是大型企业，面对每月约4万美元的费用可能会感到望而却步。

我们从优化方案1中看到，降低成本的 simplest 方法是通过管理数据保留。对于限制条件也是如此。如果我们只想保留约10%的跟踪记录超过14天，我们可以设置可保留的高保留跟踪记录的最大数量限制。该值应为.10 * 7,800,000 = 780,000。

正如我们所见，由于不再允许过多的昂贵数据保留升级，每月最高成本已从约 4 万美元降至约 7500 美元。这让我们确信，平台上的新用户不会意外导致成本激增。

注意

延长数据保留期限可能会导致在达到限制后，除追踪以外的其他功能停止工作。如果您计划使用此功能，请阅读更多关于其功能的说明此处。

设置开发/预发布限制并查看跨工作区的总花费限制

遵循我们开发和预发布环境的相同逻辑，我们为每个工作区将使用限制设置为生产环境限制的 10%。

虽然这适用于我们的使用模式，但设置良好的开发和预发布限制可能因您使用 LangSmith 的具体场景而异。例如，如果您在开发或预发布环境中将评估作为 CI/CD 的一部分运行，您可能希望放宽使用限制，以避免测试失败。

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

使用此估计器，我们可以确信在月底不会出现意外的信用卡账单。

总结

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

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

如果您有关于进一步优化支出的问题，请联系 support@langchain.dev。

优化 LangSmith 的追踪支出

问题设置

了解您当前的使用情况

使用图谱

发票