最佳实践
目录
最佳实践#
安全#
安全套接字层 (SSL) 及其后继者传输层安全 (TLS) 协议,用于建立和加密两个端点之间交换的数据,强烈建议与 HTTP/2 和 gRPC 一起使用。虽然此协议增加了安全性,但也增加了开销。可以通过尽可能建立 gRPC 流而不是创建一元调用来缓解这种情况。每次创建新的 gRPC 通道时,都需要开销来交换 SSL/TLS 密钥,以及建立 TCP 和 HTTP/2 连接。如果客户端定期与服务器发送或接收消息,则流可以减少此开销。
在服务器中启用安全连接#
Riva 服务器可以部署 SSL/TLS 证书,以验证 Riva 服务器的身份并加密客户端和服务器之间交换的所有数据。为了使用 SSL/TLS,您必须在快速入门脚本的 config.sh
配置文件中提供 SSL/TLS 证书和密钥的路径。
如果 ssl_server_cert
或 ssl_server_key
变量为空,则使用不安全的 gRPC 连接。
连接到安全服务器#
要连接到安全的 Riva 服务器,客户端必须提供服务器信任链中的证书。明确地说,这意味着客户端必须配置服务器上部署的证书或属于用于生成服务器证书的服务的任何证书,以便与 Riva 服务器建立连接。
随着 gRPC 从明文切换到安全,需要修改通信通道的创建方式。例如,在 Python 中
# required imports
import grpc
# establish connection to Riva server and initialize client
ssl_cert="my_ssl_cert.crt"
with open(ssl_cert, 'rb') as f:
certificates = f.read()
creds = grpc.ssl_channel_credentials(certificates)
channel = grpc.secure_channel("localhost:50051", creds)
自动缩放配置#
部署后,您可以根据观察到的利用率自动缩放分配的计算资源。在 Riva Helm Chart 的 values.yaml
中,可以增加 replicaCount
以启用 Horizontal Pod Autoscaler。这也需要正确配置的入口控制器来执行 HTTP/2 和 gRPC 负载均衡,包括名称解析。
监控 GPU 和 CPU 遥测#
在运行 GPU 密集型工作负载时,重要的是监控硬件遥测并将其纳入您的计算作业中,实际上这是启用 Horizontal Pod Autoscaling 所必需的。NVIDIA Data Center GPU Manager (DCGM) 是一套用于监控集群环境中 NVIDIA 数据中心 GPU 的工具。将 GPU 遥测集成到 Kubernetes 中 使用 GPU 温度和其他遥测技术来提高数据中心效率并最大限度地减少资源分配。同样重要的是 监控其他资源,包括 CPU 核心数利用率或与用例相关的任何自定义指标。
Riva 从快速入门脚本和 Helm 部署选项中公开 Triton Inference Server 的指标 API。Triton 提供指示 GPU 和请求统计信息的 Prometheus 指标。这些指标可在 http://<hostname>:<metrics_port>/metrics
中找到,其中 <metrics_port>
是映射到 Riva 容器内端口 8002 的端口号。例如,如果 Riva 在本地部署并且容器端口 8002 映射到端口 49183,则指标可在 http://127.0.0.1:49183/metrics 中找到。
有关更多信息,请参阅 Triton Inference Server Metrics。
负载均衡类型#
负载均衡是将固定数量的资源分配给任意数量的传入任务的过程。最值得注意的是对于可扩展的服务器-客户端应用程序,负载均衡器将网络流量分配到一组节点上。负载均衡有常见的类别,每种类别都有其自身的优点和缺点。
提供了一个使用 MetalLB 的 Layer 2 (数据链路层) 负载均衡的基本实现 (但默认情况下未启用)。在这种方法中,一个节点承担处理所有流量的责任,然后流量从该节点传播到 Pod。如果节点发生故障,则充当故障转移机制。但是,这严重限制了带宽。此外,云提供商通常不公开 Layer 2,在这种情况下,它不可用。
Level 4 (传输层) 负载均衡使用来自传输层的网络信息 (例如应用程序端口和协议) 来定向流量。L4 负载均衡在连接级别上运行;但是,gRPC 使用 HTTP/2,它在单个连接上多路复用多个调用,将该连接上的所有调用都集中到一个端点。
Level 7 (应用层) 负载均衡使用高级应用程序信息 (消息内容) 来定向流量。这通常允许更“智能”的负载均衡决策,因为该算法可以使用其他信息。此外,这不会遇到与 L4 负载均衡相同的问题,但会以增加 gRPC 调用的延迟为代价。
优化嵌入式平台的资源使用#
在 嵌入式 平台上,拥有内存占用尽可能小的模型至关重要。为了实现这一点,在嵌入式平台上部署模型时,请在 riva-build
命令中使用 max_batch_size
为 1。请参阅 ASR 管道配置 和 TTS 管道配置 部分,其中详细解释了使用 max_batch_size
为 1 的 riva-build
参数。
可以使用 Jetson 平台上内置的 tegrastats 实用程序来监控模型的资源使用情况。使用 sudo tegrastats --interval 100
命令启动该实用程序。以下是一些日志片段,可帮助您识别瞬时资源使用情况。
指标 |
日志片段 |
---|---|
CPU |
RAM 7912/15817MB (lfb 55x4MB) SWAP 8/7908MB (cached 0MB) CPU [0%@2265,0%@2265,83%@2265,46%@2265,83%@2265,0%@2265,9%@2265,16%@2265] EMC_FREQ 1%@2133 GR3D_FREQ 62%@1338 APE 150 MTS fg 0% bg 33% AO@41.5C GPU@42.5C Tdiode@43.25C PMIC@50C AUX@40.5C CPU@43.5C thermal@40.95C Tboard@42C GPU 2005/521 CPU 2005/675 SOC 1851/1000 CV 0/0 VDDRQ 462/173 SYS5V 1898/1564 |
GPU |
RAM 7912/15817MB (lfb 55x4MB) SWAP 8/7908MB (cached 0MB) CPU [0%@2265,0%@2265,83%@2265,46%@2265,83%@2265,0%@2265,9%@2265,16%@2265] EMC_FREQ 1%@2133 GR3D_FREQ 62%@1338 APE 150 MTS fg 0% bg 33% AO@41.5C GPU@42.5C Tdiode@43.25C PMIC@50C AUX@40.5C CPU@43.5C thermal@40.95C Tboard@42C GPU 2005/521 CPU 2005/675 SOC 1851/1000 CV 0/0 VDDRQ 462/173 SYS5V 1898/1564 |
RAM |
RAM 7912/15817MB (lfb 55x4MB) SWAP 8/7908MB (cached 0MB) CPU [0%@2265,0%@2265,83%@2265,46%@2265,83%@2265,0%@2265,9%@2265,16%@2265] EMC_FREQ 1%@2133 GR3D_FREQ 62%@1338 APE 150 MTS fg 0% bg 33% AO@41.5C GPU@42.5C Tdiode@43.25C PMIC@50C AUX@40.5C CPU@43.5C thermal@40.95C Tboard@42C GPU 2005/521 CPU 2005/675 SOC 1851/1000 CV 0/0 VDDRQ 462/173 SYS5V 1898/1564 |