用量与计费

理解 LangSmith 追踪数据保留层级、定价、速率限制和用量限制。

数据保留

本节讲述数据保留如何工作以及在 LangSmith 中如何定价。

为何保留很重要

• 隐私：许多数据隐私法规，例如欧洲的 GDPR 或加州的 CCPA，要求组织在个人数据不再出于收集目的而必要时删除它。设置保留期有助于遵守此类法规。
• 成本：LangSmith 对低数据保留的追踪收费更少。更多信息，学习如何强制执行支出限制。

TIP

在你开始发送追踪之前规划好你的保留层级。更改只适用于新追踪——现有追踪保持其原始层级。见更改项目级默认保留。

工作原理

LangSmith 基于数据保留有两个追踪层级，具有以下特征：

	Base	Extended
价格	见定价页	见定价页
保留期	14 天	180 天

WARNING

从 2026 年 9 月 14 日起，SaaS 客户的最大长期追踪保留期改为 180 天。企业客户仍可按工作区自定义延长保留期直至这个新上限。更改只适用于新追踪——现有追踪不受影响。见自定义延长保留策略。

保留结束后的数据删除

在指定保留期之后，追踪在追踪项目 UI 中或通过 API 不再可访问。与该追踪关联的所有用户数据（例如输入和输出）会在其后不久从我们内部系统中删除。与每条追踪关联的某些元数据可能为分析和计费目的被无限期保留。

数据保留自动升级

WARNING

自动升级可能影响你的账单。请仔细阅读本节，以充分理解你估算的 LangSmith 追踪成本。

多数追踪用基础保留。某些动作，例如在线评估器和自动化规则，可能以更高成本把追踪延长到更长的保留期。你控制哪些动作延长保留。

当你在 base 层追踪上使用某些功能时，它们的数据保留可能被自动升级到 extended 层。这会同时增加保留期和追踪成本。

按动作的保留行为：

• 通过 API 或 SDK 的反馈：通过一个显式传 extend_trace_retention=true（TypeScript 中为 extendTraceRetention: true）的 API 或 SDK 调用，把反馈添加到该追踪（或该线程中任一线程）上的任何运行。更多信息见附加用户反馈。LangSmith UI 发送反馈和备注时不延长保留。
• 在线评估器：一个在线评估器给追踪打分且其保留设置已启用。追踪级和线程级评估器都可以选择退出这一升级。
• 自动化规则：一条启用了保留延长的自动化规则匹配某追踪内的任何运行。匹配单个运行会升级整条追踪，而不仅是那个运行。一条 item type 为 Threads 的规则，会升级匹配线程中的每条追踪，而不仅是最近那条。
• 手动标注队列添加（不升级）：手动把运行或线程添加到一个标注队列默认不升级保留。

此更改只适用于新动作。已被先前动作升级过的追踪保持其延长保留。

NOTE

当你在一个追踪项目上创建或编辑一个在线评估器时，你可以选择不去升级该评估器打分的追踪，让它们保持基础保留。此选项只有在项目的默认保留是基础层时可用。分步说明见管理评估器追踪保留。

NOTE

保留延长对新在线评估器和自动化规则默认启用。你可以在配置每个评估器或规则时选择退出。

为何自动升级追踪？

对于追踪的自动升级模型，我们有两个理由：

1. 我们认为匹配这些条件中任一的追踪从根本上比其他追踪更有趣，因此让用户能把它们保留更久是好事。
2. 我们在理念上希望对可能不会被有意义交互的追踪按低一个数量级向客户收费。我们认为自动升级使我们的定价模型与 LangSmith 带来的价值对齐，只有带有意义交互的追踪才按更高费率收费。

如果你对我们的定价模型有疑问或顾虑，请随时通过 support.langchain.com 联系支持，告诉我们你的想法！

数据保留如何影响下游功能？

以下功能以不同方式与保留交互：

• 实验：运行默认在延长保留下创建。
• 自动化规则和评估器：当其保留设置启用时，把匹配的追踪升级到延长保留。线程级的规则和评估器会升级匹配线程中的每条追踪。
• UI 反馈、备注和标注队列：保持追踪的保留层级不变。

其他功能独立于追踪的保留层级运作：

• 监控：即使在一个基础层追踪的数据保留期结束之后，监控标签仍会继续工作。它由存在超过 30 天的追踪元数据驱动，意味着你的监控图表即使在 base 层追踪上也会继续保持准确。
• 数据集：数据集有无限期的数据保留。换句话说，如果你把一条追踪的输入和输出添加到数据集，它们永不被删除。我们建议，如果你用 LangSmith 做数据收集，就善用数据集功能。

计费模型

可计费指标

在你的 LangSmith 发票上，你会看到我们收费的两个指标：

• LangSmith Traces (Base Charge)
• LangSmith Traces (Extended Data Retention Upgrades)。

第一个指标包含所有追踪，不论层级。第二个指标只统计延长保留追踪的数量。

为何衡量所有追踪 + 升级，而非基础和延长追踪？

考虑我们的定价时一个自然会问的问题是，为什么不直接在发票上显示 base 层和 extended 层追踪的数量？

虽然我们理解那样更直白，但它无法恰当地体现追踪升级。考虑一条在 6 月 30 日记录、在 7 月 3 日升级到 extended 层的 base 层追踪。base 层追踪发生在 6 月账期，但升级发生在 7 月账期。因此，我们需要能够独立衡量这两个事件，以正确地向客户计费。

如果你的追踪被记录为延长保留追踪，那么 base 和 extended 指标都会以同样的时间戳被记录。

速率限制

LangSmith 有速率限制，旨在为所有用户确保服务稳定性。

为确保访问和稳定，LangSmith 会在以下情形下以 HTTP 状态码 429 响应，指示速率或用量限制已被超出：

在我们的应用负载均衡器上，1 分钟时间段内的临时吞吐限制

这个 429 是在 1 分钟窗口内、按服务密钥或 PAT 超出固定的 API 调用数所致。窗口的起点会略有变动——不保证从时钟分钟的头开始——并可能依据应用部署事件而改变。

在收到最大事件数之后，我们会用 429 响应，直到距评估窗口开始满 60 秒，然后该过程重复。

这个 429 由我们的应用负载均衡器抛出，是为所有 LangSmith 用户就位的机制，独立于方案层级，以确保所有用户的服务连续性。

方法	端点	限制	窗口
DELETE	/sessions*	30	1 分钟
POST OR PATCH	/runs*	5000	1 分钟
GET	/runs/:id	30	1 分钟
POST	/feedbacks*	5000	1 分钟
*	*	2000	1 分钟

NOTE

LangSmith SDK 会采取措施，把单个会话 ID 的多达 100 个运行批处理进单个 API 调用，以降低在这些与运行相关的端点上触及这些限制的可能性。

方案级的每小时追踪事件限制

这个 429 是达到你每小时摄取最大事件数的结果，在一个从每个 UTC 时钟小时头开始的固定窗口中评估，并在每个新小时的整点重置。

在这个语境中，一个事件是一次运行的创建或更新。如果一个运行在同一小时窗口内被创建随后又被更新，那算作 2 个事件计入此限制。

这由我们的应用抛出，并按方案层级而异，处于我们 Startup/Plus 和 Enterprise 方案层级的组织，比面向个人使用的 Free 和 Developer 方案层级有更高的每小时限制。

方案	限制	窗口
Developer（未留付款方式）	50,000 事件	1 小时
Developer（已留付款方式）	250,000 事件	1 小时
Startup/Plus	500,000 事件	1 小时
Enterprise	自定义	自定义

方案级的每小时追踪数据摄取限制

这个 429 是达到你追踪输入、输出和元数据跨取的最大数据量的结果，在一个从每个 UTC 时钟小时头开始的固定窗口中评估，并在每个新小时的整点重置。

通常，输入、输出和元数据在运行创建和更新事件上都会发送。如果一个运行在 2.0MB 创建并在同一小时窗口内更新到 3.0MB，那算作 5.0MB 存储计入此限制。

这由我们的应用抛出，并按方案层级而异，处于我们 Startup/Plus 和 Enterprise 方案层级的组织，比面向个人使用的 Free 和 Developer 方案层级有更高的每小时限制。

方案	限制	窗口
Developer（未留付款方式）	500MB	1 小时
Developer（已留付款方式）	2.5GB	1 小时
Startup/Plus	5.0GB	1 小时
Enterprise	自定义	自定义

方案级的每月唯一追踪限制

这个 429 是达到你每月摄取最大追踪数的结果，在一个从每个 UTC 日历月头开始的固定窗口中评估，并在每个新月的头重置。

这由我们的应用抛出，仅在没有付款方式的 Developer 方案层级上适用。

方案	限制	窗口
Developer（未留付款方式）	5,000 条追踪	1 个月

自配置的每月用量限制

这个 429 是达到由你组织管理员所配置的用量限制的结果，在一个从每个 UTC 日历月头开始的固定窗口中评估，并在每个新月的头重置。

这由我们的应用抛出，按组织依其配置的设置而异。

每条追踪的最大运行数

每条追踪最多限制为 25,000 个运行。一旦追踪达到这个限制，LangSmith 会拒绝对该追踪发送的任何额外运行。

运行查询端点

POST /runs/query 端点有基于查询参数的、按租户的额外速率限制。详情见用 SDK 查询追踪。

工作区邀请批处理端点

工作区邀请批处理请求按工作区做速率限制，以减少批量邀请滥用。

在你的应用中处理 429 响应

由于某些 429 响应是暂时的、可能在一次后续调用时成功，如果你在应用中直接调用 LangSmith API，我们建议实现带指数退避和抖动的重试逻辑。

为便利起见，用 LangSmith SDK 构建的 LangChain 应用内置了这一能力。

NOTE

重要的是要注意，如果你在长时间段内饱和端点，重试可能无效，因为你的应用最终会累积足够大的积压而耗尽所有重试。

如果是这种情况，我们想更具体地讨论你的需求。请通过 LangSmith 支持联系支持，附上你应用的吞吐需求详情和示例代码，我们可以与你协作，更好地理解最佳做法是修复 bug、更改你的应用代码，还是换一个 LangSmith 方案。

用量限制

LangSmith 让你在追踪上配置用量限制。注意这些是用量限制，而非支出限制，意味着它们让你限制某个事件的发生数量，而非你要花费的总额。

LangSmith 让你设两个不同的每月限制，对应我们前述数据保留指南中讨论的可计费指标：

• 所有追踪限制
• 延长数据保留追踪限制

它们分别让你限制追踪总数和延长数据保留追踪的数量。

用量限制的特性

用量限制是近似的，意味着我们不保证限制的精确性。在罕见情况下，在用量限制开始生效之前，可能有短暂的一小段时间在限制阈值之上额外处理了一些追踪。

延长数据保留追踪限制的副作用

延长数据保留追踪限制有副作用。如果限制已经达到，LangSmith 会阻止那些将再创建一个延长保留追踪的动作。例如，你将不能再：

1. 运行延长追踪保留的自动化规则
2. 运行延长追踪保留的评估器

不改变追踪保留的动作不计入延长保留追踪限制。当达到限制时，你仍能在 LangSmith UI 中提交反馈、把运行或线程添加到标注队列，以及运行禁用了保留延长的自动化规则或评估器。

更新用量限制

用量限制可在 Usage and Billing 下的 Settings 页更新。限制值会被缓存，所以新限制生效前可能需要一两分钟。

相关内容

• 关于如何强制执行支出限制的教程

---