为规模配置 LangSmith

WARNING

本页上的缩放指导与示例配置适用于 LangSmith 版本 v0.13.0 或更高。

一个自托管 LangSmith 实例能处理大量追踪和用户。自托管部署的默认配置能处理相当负载，你可以把你的部署配置成能实现更高规模。本页描述缩放考量，并提供一些示例帮你配置你的自托管实例。

总结

下表提供了一个概览，针对不同负载模式（读/写）比较不同的 LangSmith 配置：

	低 / 低	低 / 高	高 / 低	中 / 中	高 / 高

| 5 | 5 | 50 | 20 | 50 | |

| 10 | 1000 | 10 | 100 | 1000 | | 前端副本
(500m CPU, 每副本请求 1Gi) | 1 （默认） | 4 | 2 | 2 | 4 | | 平台后端副本
(1 CPU, 每副本请求 2Gi) | 3 （默认） | 20 | 3 （默认） | 3 （默认） | 20 | | 摄取队列副本
(1 CPU, 每副本请求 2Gi) | 3 （默认） | 24 | 3 （默认） | 6 | 24 | | 后端副本
(1 CPU, 每副本请求 2Gi) | 2 （默认） | 5 | 40 | 16 | 50 | | Redis 资源 | 8 Gi （默认） | 26 Gi 外部 | 8 Gi （默认） | 13Gi 外部 | 26 Gi 外部 | | ClickHouse 资源 | 4 CPU
16 Gi （默认） | 10 CPU
32Gi memory | 8 CPU
16 Gi per replica | 16 CPU
24Gi memory | 14 CPU
24 Gi per replica | | ClickHouse 部署 | 单实例 | 单实例 | 3 节点

| 单实例 | 3 节点

| |

| 2 CPU
8 GB memory
10 GB storage （外部） | 2 CPU
8 GB memory
10 GB storage （外部） | 2 CPU
8 GB memory
10 GB storage （外部） | 2 CPU
8 GB memory
10 GB storage （外部） | 2 CPU
8 GB memory
10 GB storage （外部） | | Blob 存储 | 禁用 | 启用 | 启用 | 启用 | 启用 |

NOTE

上面的每副本数字是资源请求，即 Kubernetes 调度器保留的量。限制在每个情形下都更高。有关 chart 随附的默认值，见默认资源请求与限制。

一个超过其内存限制的容器会被 OOM 杀死，一个超过其 CPU 限制的容器会被限流。不要在对结果做负载测试之前，把任一项调低到随附默认值以下。

下面我们更详细地阐述读和写路径，并提供一个 values.yaml 片段供你为你的自托管 LangSmith 实例起步。

默认资源请求与限制

Helm chart 为 LangSmith 应用服务随附这些请求和限制。上面的汇总表涵盖 Postgres、Redis 和 ClickHouse，以及每种负载模式要运行的副本数。

`values.yaml` 键	请求（CPU / 内存）	限制（CPU / 内存）	默认副本
`frontend`	500m / 1Gi	1000m / 2Gi	1
`backend`	1000m / 2Gi	2000m / 4Gi	2
`platformBackend`	1000m / 2Gi	2000m / 4Gi	3
`ingestQueue`	1000m / 2Gi	2000m / 4Gi	3
`queue`	1000m / 2Gi	2000m / 4Gi	1
`playground`	500m / 1Gi	1000m / 8Gi	1
`aceBackend`	1000m / 2000Mi	2000m / 4000Mi	1
`hostBackend`	200m / 1000Mi	1000m / 2Gi	1
`listener`	1000m / 2Gi	2000m / 4Gi	1
`operator`	1000m / 2Gi	2000m / 4Gi	1

每个键把它的资源嵌在 deployment 之下，因此 backend 的请求在 backend.deployment.resources.requests。playground 是唯一一个内存限制远高于其请求的服务，是 8Gi 对 1Gi，因此要按限制来确定它所调度到的节点大小。要确认你 chart 版本的默认值，运行 helm show values langchain/langsmith。

默认自动缩放范围

下表中的每个服务默认都禁用自动缩放。每个服务随附两个带相同副本范围的块：autoscaling.hpa，用于 Kubernetes HorizontalPodAutoscaler（HPA），以及 autoscaling.keda，用于 KEDA（Kubernetes 事件驱动自动缩放）。启用其中一个而非两者。

`values.yaml` 键	最小副本	最大副本
`frontend`	1	5
`backend`	2	6
`platformBackend`	3	10
`ingestQueue`	3	10
`queue`	1	10
`playground`	1	5
`aceBackend`	1	5
`hostBackend`	1	5
`listener`	1	10

HPA 的键是 minReplicas 和 maxReplicas；KEDA 的等价项是 minReplicaCount 和 maxReplicaCount。operator 没有自动缩放块，始终按其配置的副本数运行。对于队列服务，优先考虑 KEDA，它基于队列积压而非仅 CPU 和内存来缩放。更多信息参阅用 KEDA 为 LangSmith 队列自动缩放。

WARNING

启用自动缩放会覆盖你的副本数。当某个服务的任一块被启用时， chart 就不再在该 deployment 上设置 replicas，自动缩放器拥有它，因此你配置的 deployment.replicas 值不再生效。

随附的最大值是通用的起点，不是与汇总表中负载模式相匹配的值。高读、高写需要 50 个 backend 副本、24 个 ingestQueue 和 20 个 platformBackend，而随附最大值是 6、10 和 10。一个为该负载定规格、然后切到自动缩放的部署，会运行在你所配置容量的一小部分。

把 maxReplicas 设在你负载模式的副本数或以上，把 minReplicas 设为你想保持的稳态数量。示例配置为每个服务都给了一个固定副本数和一个带注释的自动缩放范围。

追踪摄取（写路径）

常见给写路径带来负载的用法：

通过 Python 或 JavaScript LangSmith SDK 摄取追踪
通过 @traceable wrapper 摄取追踪
通过 /runs/multipart 端点提交追踪

在追踪摄取中扮演重要角色的服务：

Platform backend 服务：接收摄取追踪的初始请求，并把追踪放入一个 Redis 队列
Redis 缓存：用于排队需要被持久化的追踪
Ingest queue 服务：为查询而持久化追踪
ClickHouse：用于追踪的持久存储

当缩放写路径（追踪摄取）时，监控上面列出的四个服务/资源很有帮助。这里有一些典型改动能帮助提升追踪摄取的性能：

如果 ClickHouse 接近资源限制，给它更多资源（CPU 和内存）。
如果摄取请求响应耗时很长，增加 platform-backend pod 的数量。
如果追踪从 Redis 处理得不够快，增加 ingest queue 服务 pod 副本。
如果你注意到当前 Redis 实例接近资源限制，使用更大的 Redis 缓存。这也可能是摄取请求耗时很长的原因。

追踪查询（读路径）

常见给读路径带来负载的用法：

在前端查看追踪项目或单条追踪的用户
用于查询追踪信息的脚本
访问 /runs/query 或 /runs/<run-id> api 端点

在查询追踪中扮演重要角色的服务：

Backend 服务：接收请求，并向 ClickHouse 提交一个查询以响应请求
ClickHouse：追踪的持久存储。请求追踪信息时查询的主数据库。

当缩放读路径（追踪查询）时，监控上面列出的两个服务/资源很有帮助。这里有一些典型改动能帮助提升追踪查询的性能：

增加 backend 服务 pod 的数量。如果 backend 服务 pod 接近 1 核心 CPU 使用，这最有效。
给 ClickHouse 更多资源（CPU 或内存）。ClickHouse 可能非常耗资源，但它应当能带来更好的性能。
迁移到一个复制 ClickHouse 集群。增加 ClickHouse 副本有助于读性能，但我们建议保持在 5 副本以下（从 3 开始）。

有关这如何翻译为 helm chart values 的更精确指导，参阅下面节中的示例。如果你不确定为什么你的 LangSmith 实例无法处理某个负载模式，联系 LangChain 团队。

用 KEDA 为 LangSmith 队列自动缩放

NOTE

在 LangSmith v0.13.0 及更高版本中可用。

我们强烈建议在你的集群上安装 KEDA。KEDA 使 queue 和 ingest-queue 服务能根据其队列积压大小，以及 CPU 和内存自动缩放。这会带来更高效的资源利用和更好的流量峰值处理。

安装 KEDA

bash

helm repo add kedacore https://kedacore.github.io/charts
helm install keda kedacore/keda --namespace keda --create-namespace

配置 KEDA 自动缩放

KEDA 安装后，你可以在 values.yaml 中为 queue 和 ingest-queue 服务启用基于 KEDA 的自动缩放：

yaml

queue:
  autoscaling:
    keda:
      enabled: true

ingestQueue:
  autoscaling:
    keda:
      enabled: true

启用 KEDA 后，队列服务会在其积压增长时自动缩放上去，在其积压被处理完时缩放下来。这对于处理可变的追踪摄取负载而不过度预配资源尤为有用。

NOTE

你也可以为其他服务（backend、platformBackend 等）启用 KEDA，但它们仍只会随 CPU 和内存缩放。

用于规模的 LangSmith 示例配置

下面我们基于预期的读和写负载提供一些 LangSmith 示例配置。

对于读负载（追踪查询）：

低大致意味着同时约 5 个用户查看追踪（约每秒 10 个请求）
中大致意味着同时约 20 个用户查看追踪（约每秒 40 个请求）
高大致意味着同时约 50 个用户查看追踪（约每秒 100 个请求）

对于写负载（追踪摄取）：

低意味着最多每秒提交 10 条追踪
中意味着最多每秒提交 100 条追踪
高意味着最多每秒提交 1000 条追踪

NOTE

确切的最优配置取决于你的用法和追踪载荷。将下面的示例与上面的信息以及你的具体用法结合使用，按你看到的合适方式更新你的 LangSmith 配置。如有任何疑问，请联系 LangChain 团队。

低读、低写

默认的 LangSmith 配置能处理这种负载。这里无需自定义资源配置。

低读、高写

你有非常高规模的追踪摄取，但在任一时点前端上查询追踪的用户只有个位数。

为此，我们推荐如下配置：

yaml

config:
  blobStorage:
    # Please also set the other keys to connect to your blob storage. See configuration section.
    enabled: true
  settings:
    redisRunsExpirySeconds: "3600"
# ttl:
#   enabled: true
#   ttl_period_seconds:
#     longlived: "7776000"  # 90 days (default is 400 days)
#     shortlived: "604800"  # 7 days (default is 14 days)

frontend:
  deployment:
    replicas: 4 # OR enable autoscaling below
# autoscaling:
#   hpa:
#     enabled: true
#     minReplicas: 2
#     maxReplicas: 4

platformBackend:
  deployment:
    replicas: 20 # OR enable autoscaling below
# autoscaling:
#   hpa:
#     enabled: true
#     minReplicas: 8
#     maxReplicas: 20

ingestQueue:
  deployment:
    replicas: 24 # OR enable KEDA autoscaling below
# autoscaling:
#   keda:
#     enabled: true
#     minReplicaCount: 8
#     maxReplicaCount: 24

backend:
  deployment:
    replicas: 5 # OR enable autoscaling below
# autoscaling:
#   hpa:
#     enabled: true
#     minReplicas: 3
#     maxReplicas: 5

## Ensure your Redis cache is at least 26 GB for high write scale
redis:
  external:
    enabled: true
    existingSecretName: langsmith-redis-secret # Set the connection url for your external Redis instance (26+ GB)

clickhouse:
  statefulSet:
    persistence:
      # This may depend on your configured TTL (see config section).
      # We recommend 600Gi for every shortlived TTL day if operating at this scale constantly.
      size: 4200Gi # This assumes 7 days TTL and operating a this scale constantly.
    resources:
      requests:
        cpu: "10"
        memory: "32Gi"
      limits:
        cpu: "16"
        memory: "48Gi"

commonEnv:
  - name: "CLICKHOUSE_ASYNC_INSERT_WAIT_PCT_FLOAT"
    value: "0"

高读、低写

你有相对较低规模的追踪摄取，但有许多前端用户查询追踪，和/或有频繁访问 /runs/query 或 /runs/<run-id> 端点的脚本。

对此，我们强烈建议设置一个复制 ClickHouse 集群，以在低延迟下实现高读规模。 有关如何设置一个复制 ClickHouse 集群的更多指导，参阅我们的外部 ClickHouse 文档。对于这种负载模式，我们建议使用一个 3 节点复制设置，其中集群里每个副本的资源请求为 8+ 核心、16+ GB 内存，资源限制为 12 核心、32 GB 内存。

为此，我们推荐如下配置：

yaml

config:
  blobStorage:
    # Please also set the other keys to connect to your blob storage. See configuration section.
    enabled: true

frontend:
  deployment:
    replicas: 2

ingestQueue:
  deployment:
    replicas: 3 # OR enable KEDA autoscaling below
# autoscaling:
#   keda:
#     enabled: true
#     minReplicaCount: 2
#     maxReplicaCount: 3

backend:
  deployment:
    replicas: 40 # OR enable autoscaling below
# autoscaling:
#   hpa:
#     enabled: true
#     minReplicas: 16
#     maxReplicas: 40

# We strongly recommend setting up a replicated clickhouse cluster for this load.
# Update these values as needed to connect to your replicated clickhouse cluster.
clickhouse:
  external:
    # If using a 3 node replicated setup, each replica in the cluster should have resource requests of 8+ cores and 16+ GB memory, and resource limit of 12 cores and 32 GB memory.
    enabled: true
    host: langsmith-ch-clickhouse-replicated.default.svc.cluster.local
    port: "8123"
    nativePort: "9000"
    user: "default"
    password: "password"
    database: "default"
    cluster: "replicated"

中读、中写

这是一个良好的全方位配置，应能处理 LangSmith 大多数使用模式。在内部测试中，这个配置让我们能缩放到每秒 100 条追踪摄取和每秒 40 个读请求。

为此，我们推荐如下配置：

yaml

config:
  blobStorage:
    # Please also set the other keys to connect to your blob storage. See configuration section.
    enabled: true
  settings:
    redisRunsExpirySeconds: "3600"

frontend:
  deployment:
    replicas: 2

ingestQueue:
  deployment:
    replicas: 6 # OR enable KEDA autoscaling below
# autoscaling:
#   keda:
#     enabled: true
#     minReplicaCount: 3
#     maxReplicaCount: 6

backend:
  deployment:
    replicas: 16 # OR enable autoscaling below
# autoscaling:
#   hpa:
#     enabled: true
#     minReplicas: 8
#     maxReplicas: 16

redis:
  statefulSet:
    resources:
      requests:
        memory: 13Gi
      limits:
        memory: 13Gi

  # -- For external redis instead use something like below --
  # external:
  #   enabled: true
  #   connectionUrl: "<URL>" OR existingSecretName: "<SECRET-NAME>"

clickhouse:
  statefulSet:
    persistence:
      # This may depend on your configured TTL.
      # We recommend 60Gi for every shortlived TTL day if operating at this scale constantly.
      size: 420Gi # This assumes 7 days TTL and operating a this scale constantly.
    resources:
      requests:
        cpu: "16"
        memory: "24Gi"
      limits:
        cpu: "28"
        memory: "40Gi"

commonEnv:
  - name: "CLICKHOUSE_ASYNC_INSERT_WAIT_PCT_FLOAT"
    value: "0"

WARNING

如果你在使用上述配置后仍注意到读得慢，我们建议迁移到一个复制 Clickhouse 集群设置

高读、高写

你有非常高的追踪摄取速率（接近每秒 1000 条提交），也有许多用户在前端查询追踪（超过 50 用户），和/或持续向 /runs/query 或 /runs/<run-id> 端点发请求的脚本。

对此，我们非常强烈地建议设置一个复制 ClickHouse 集群，以防止在高写规模下降级的读性能。 有关如何设置一个复制 ClickHouse 集群的更多指导，参阅我们的外部 ClickHouse 文档。对于这种负载模式，我们建议使用一个 3 节点复制设置，其中集群里每个副本的资源请求为 14+ 核心、24+ GB 内存，资源限制为 20 核心、48 GB 内存。我们还建议每个 ClickHouse 节点/实例按你所启用的每天 TTL（如下方配置）具备 600 Gi 的卷存储。

总体上，我们推荐这样一个配置：

yaml

config:
  blobStorage:
    # Please also set the other keys to connect to your blob storage. See configuration section.
    enabled: true
  settings:
    redisRunsExpirySeconds: "3600"
# ttl:
#   enabled: true
#   ttl_period_seconds:
#     longlived: "7776000"  # 90 days (default is 400 days)
#     shortlived: "604800"  # 7 days (default is 14 days)

frontend:
  deployment:
    replicas: 4 # OR enable autoscaling below
# autoscaling:
#   hpa:
#     enabled: true
#     minReplicas: 2
#     maxReplicas: 4

platformBackend:
  deployment:
    replicas: 20 # OR enable autoscaling below
# autoscaling:
#   hpa:
#     enabled: true
#     minReplicas: 8
#     maxReplicas: 20

ingestQueue:
  deployment:
    replicas: 24 # OR enable KEDA autoscaling below
# autoscaling:
#   keda:
#     enabled: true
#     minReplicaCount: 8
#     maxReplicaCount: 24

backend:
  deployment:
    replicas: 50 # OR enable autoscaling below
# autoscaling:
#   hpa:
#     enabled: true
#     minReplicas: 20
#     maxReplicas: 50

## Ensure your Redis cache is at least 26 GB for high write scale
redis:
  external:
    enabled: true
    existingSecretName: langsmith-redis-secret # Set the connection url for your external Redis instance (26+ GB)

# We strongly recommend setting up a replicated clickhouse cluster for this load.
# Update these values as needed to connect to your replicated clickhouse cluster.
clickhouse:
  external:
    # If using a 3 node replicated setup, each replica in the cluster should have resource requests of 14+ cores and 24+ GB memory, and resource limit of 20 cores and 48 GB memory.
    enabled: true
    host: langsmith-ch-clickhouse-replicated.default.svc.cluster.local
    port: "8123"
    nativePort: "9000"
    user: "default"
    password: "password"
    database: "default"
    cluster: "replicated"

commonEnv:
  - name: "CLICKHOUSE_ASYNC_INSERT_WAIT_PCT_FLOAT"
    value: "0"

NOTE

确保 Kubernetes 集群配置了足够资源以缩放到推荐大小。部署后，Kubernetes 集群中所有 pod 都应处于 Running 状态。卡在 Pending 的 pod 可能表明你接近节点池上限或需要更大的节点。

另外，确保部署在集群上的任何 ingress 控制器能处理期望的负载以避免瓶颈。

数据集

创建数据集

运行评估

评估技术

定义评估目标

打分方法

实验配置

多模态评估

分析实验结果

微调

教程

常见数据类型

评估器类型

UI

SDK

框架与集成

改进评估器

反馈

追踪设置

集成

手动埋点

配置与故障排除

项目与环境设置

高级追踪技术

数据与隐私

故障排除指南

查看与管理追踪

批量导出追踪数据

轨迹视图

数据类型参考

监控与告警

在线评估器

自动化

开发你的应用

设置依赖

持久化

能力

助手

运行

并发消息处理

如何构建

鉴权与访问控制

自定义鉴权教程

服务器定制

静态加密

替换内置后端

扩展 HTTP 服务器

请求头与日志

部署指南

参考

配置

参考

提示词

创建与管理提示词

连接模型

上下文中枢

教程

全栈 Web 应用

Agent Server API

控制平面 API

计费与用量

参考

按云服务商起步

用 Terraform 部署

AWS

GCP

Azure

安装实例

配置实例

连接外部服务

平台鉴权与访问控制

管理实例

自托管可观测性

混合部署

脚本

参考

组织