大語言模型 (LLMs) 已廣泛應用于聊天機器人、內容生成、摘要、分類、翻譯等領域。State-of-the-art LLMs 和基礎模型如? Llama , Gemma , GPT 和 Nemotron ，已經展示了類似人類的理解能力和生成能力。借助這些模型，AI 開發者無需從頭開始經歷昂貴且耗時的訓練過程。
可應用 檢索增強生成（RAG）、prompt running 和 fine-tuning 等技術來定制基礎模型，并在更短的時間內針對特定任務實現更高的準確性，定制化模型可在生產環境中快速部署，滿足各種用例的推理請求。
本文分步介紹了如何使用 NVIDIA TensorRT-LLM 優化 Large Language Models、如何使用 NVIDIA Triton Inference Server 部署優化模型，以及如何在 Kubernetes 環境中自動擴展 Large Language Models 部署。
NVIDIA TensorRT-LLM 是一款易于使用的 Python API，可用于定義和優化 LLM。NVIDIA Triton 推理服務器是一款開源推理服務軟件，支持多個框架和硬件平臺。TensorRT-LLM 提供多種優化，如 kernel fusion、quantization、in-flight batch 和 paged attention，因此可以在 NVIDIA GPUs 上高效執行使用優化模型的推理。
Triton 推理服務器支持多種深度學習和機器學習框架，包括 NVIDIA TensorRT 、TensorFlow、PyTorch 和 ONNX。它支持多種查詢類型，包括實時、批處理、ensemble 或流式傳輸。它可以在 NVIDIA GPU、x86 和 ARM CPU 上的云、數據中心、邊緣和嵌入式設備上運行。作為開發者，您可以先構建包含模型優化的 TensorRT 引擎，然后在生產環境中使用 Triton 部署優化的模型。
您可以使用 Kubernetes 將經過優化的大語言模型（LLMs）的部署從單個 GPU 擴展到多個 GPU，以低延遲、高準確度處理數千個實時推理請求，并在推理請求數量減少時縮減 GPU 數量。這對于在線購物和呼叫中心等企業特別有用，因為它們可以在高峰和非高峰時段靈活處理不同數量的推理請求，同時受益于總成本的降低，而不是購買數量最多的硬件資源來處理峰值工作負載。
Prometheus 將 Triton metrics 抓取并將其發送到 Horizontal Pod Autoscaler (HPA)，以便根據推理請求的數量決定是否增加或減少部署和 GPUs 的數量。要查看此優化和部署的代碼和步驟，請訪問 GitHub 上的 triton-inference-server/tutorials 。
硬件和軟件要求?
要優化和部署模型，您需要擁有支持 TensorRT-LLM 和 Triton 推理服務器的 NVIDIA GPU。建議使用新一代 NVIDIA GPU。你可以在 TensorRT-LLM 支持矩陣 的硬件部分找到受支持的 GPU 列表。你還可以使用適當的 GPU 資源（例如 AWS EKS 、 Azure AKS 、 GCP GKE 或 OCI OKE ）在公有云計算實例上部署模型。
Kubernetes 可用于自動擴展您的部署，以處理低延遲的大規模實時推理請求。要使 Kubernetes 能夠發現哪些節點具有 GPU，并將其提供給在這些節點上運行的容器，請安裝 Kubernetes node feature discovery service、 NVIDIA device plugin for Kubernetes、 GPU Feature Discovery service 和 NVIDIA DCGM Exporter 。你還需要安裝 Prometheus ，以收集用于自動擴展的指標。請參閱詳細安裝步驟。
使用 TensorRT-LLM 優化 LLM?
TensorRT-LLM 支持各種 state-of-the-art 模型 。您可以從 Hugging Face 下載模型檢查點 ，然后使用 TensorRT-LLM 構建包含模型優化的引擎。要下載 LLM，您需要 訪問令牌 。然后，您可以使用訪問令牌創建 Kubernetes Secret ，該令牌將在后續的 Kubernetes Deployment 步驟中用于下載模型。
$ kubectl create secret generic hf-model-pull '--from-literal=password=<HF_access_token>' |
如需詳細了解 TensorRT-LLM 的工作原理，請探索 示例 ，了解如何通過優化構建熱門模型的引擎以獲得更好的性能，例如添加 gpt_attention_plugin, paged_kv_cache, gemm_plugin, quantization。
要生成 TensorRT 引擎文件，您可以使用 NVIDIA GPU Cloud (NGC) 上提供的具有 TensorRT-LLM 的 Triton 推理服務器的 Docker 容器鏡像。要從 NGC 拉取容器鏡像，您需要在 NGC 上生成 API 密鑰 ，以便訪問 NGC 容器。然后，使用 API 密鑰登錄 NGC，拉取容器鏡像。
使用 TensorRT-LLM 提取 Triton 的 NGC 鏡像（例如，基礎鏡像 nvcr.io/nvidia/tritonserver:24.08-trtllm-python-py3）后，可參考 模型準備步驟 生成 TensorRT-LLM 引擎文件。您可以根據模型大小和 GPU 顯存大小配置 TP 張量并行（TP）和 pipeline 并行（PP）。請注意，生成引擎文件時，您需要最低數量的 GPU，TP*PP。
按照“Custom Container Image”步驟 和腳本創建自定義 Triton-TensorRT-LLM 鏡像。構建自定義鏡像后，您可以將其推送到集群可以訪問的存儲庫。要在部署期間從私有注冊表中拉取此自定義鏡像，您需要使用 API 密鑰創建 Kubernetes docker-registry 密鑰 ，并讓 Kubernetes 使用此密鑰從私有注冊表中拉取鏡像。
在部署期間，生成的 TensorRT 引擎和計劃文件存儲在主機節點中，并重新映射到同一節點上的所有 Kubernetes Pod。如果以后擴展更多的 Pod，則無需生成相同的文件。
使用 Kubernetes 自動擴展 LLM 部署?
使用 TensorRT-LLM 優化您的 LLM 后，您可以使用 Triton 部署模型，并使用 Kubernetes 自動擴展部署。部署用于 AI 推理的 LLM 需要三個主要步驟：
- 為 Triton 服務器創建 Kubernetes 部署
- 創建 Kubernetes Service 以將 Triton 服務器作為網絡服務公開
- 使用基于 Prometheus 提取的 Triton 指標的水平 Pod 自動擴展器 (HPA) 自動擴展開部署。
用于 LLM 部署的 Helm 圖表?
您可以使用 Helm 圖表進行部署，因為 Helm 圖表易于修改和在不同環境中部署。要查找 Helm 圖表，請參閱?使用 Triton 服務器和 TensorRT-LLM 自動擴展和負載平衡生成式 AI?。在?圖表目錄?中，Helm 預期文件如下：
chart.yaml 包含您要打包的圖表的所有信息；例如，版本號和名稱。
values.yaml 定義要注入模板目錄的所有值，包括支持的 GPUs、LLMs、Triton 的容器鏡像、image pull secrets 等。您可以創建特定于模型、自定義圖像和 GPU 類型的自定義值文件，以覆蓋 values.yaml。以下示例是 gpt2_values.yaml，用于在 NVIDIA A10G GPU 上部署 GPT-2 模型。
gpu:- NVIDIA-A10Gmodel: name: gpt2 tensorrtLlm: parallelism: tensor: 1triton: image: pullSecrets: -name: ngc-container-pull name: <your custom image> |
如果您有一個不適合單個 GPU 的更大模型，則可以根據模型和 GPU 大小配置 TP。例如，您可以為需要兩個 GPU 的模型設置 model.tensorrtLlm.parallelism.tensor 為 2，并且每個 Kubernetes Pod 在部署中有兩個 GPU。
創建 Kubernetes 部署
Kubernetes 部署 為 Kubernetes Pod 和 ReplicaSets 提供聲明性更新。 deployment.yaml 為 Triton 服務器創建了一組已復制的 Pod。你可以指定要使用的 Pod 數量，如 .spec.replicas 字段所示。
.spec.containers 字段告知每個 Kubernetes Pod 在 GPU 上運行一個 Triton 服務器容器。為 Triton 服務器分別指定了端口號 8000 和 8001，用于接收來自客戶端的 HPPP 和 GRPC 推理請求。端口 8002 用于收集 Triton 指標 。你可以更改 .resources.ephemeral-storage 字段，以適應模型的大小；例如，GPT-2 模型可容納 24 GB 的 NVIDIA A10G GPU 內存。
apiVersion: apps/v1kind: Deploymentmetadata: […]spec: selector: […] replicas: 1 template: metadata: labels: app: {{ $.Release.Name }} app.kubernetes.io/component: server……spec: […] containers: - name: triton [...] image: {{ $image_name }} imagePullPolicy: IfNotPresent [...] ports: - containerPort: 8000 name: http - containerPort: 8001 name: grpc - containerPort: 8002 name: metrics |
創建 Kubernetes 服務?
Kubernetes Service 是將在一組 Pod 上運行的應用程序公開為網絡服務的抽象方式。 service.yaml 將 Triton 服務器公開為網絡服務，因此服務器可以隨時接收來自客戶端的推理請求。
apiVersion: v1kind: Servicemetadata: name: {{ $.Release.Name }} labels: app: {{ $.Release.Name }} app.kubernetes.io/component: service……spec: ports: - name: http port: 8000 targetPort: http - name: grpc port: 8001 targetPort: grpc - name: metrics port: 8002 targetPort: metrics selector: app: {{ $.Release.Name }} type: ClusterIP |
自動擴展 LLM 部署?
要自動擴展應用程序，您需要通過檢查容器、Pod 和服務來監控應用程序的性能。您可以使用 PodMonitor 或 ServiceMonitor 監控 Kubernetes Pod 或服務，以實現 Prometheus 的目標發現。Kube-Prometheus 可以幫助部署 Prometheus 并將 Prometheus 鏈接到指標端點。您可以使用 PodMonitor 和 Kube-Prometheus 向 Prometheus 公開 NVIDIA Triton 指標。
下方的 pod-monitor.yaml 文件使用 PodMonitor 來監控 Pod，每個 Pod 都有一個 Triton 服務器：
apiVersion: monitoring.coreos.com/v1kind: PodMonitormetadata: name: {{ $.Release.Name }} labels: app: {{ $.Release.Name }} app.kubernetes.io/component: autoscaler release: prometheus……spec: selector: matchLabels: app: {{ $.Release.Name }} app.kubernetes.io/component: server podMetricsEndpoints: - port: metrics path: /metrics |
Prometheus 可以從端口號為 8002 的所有 Kubernetes Pod 中抓取 Triton 指標 。您可以為 HPA 選擇一個 Triton，或者根據需要使用收集的指標定義新的自定義指標。Prometheus 適配器可以與 Kubernetes 和 Prometheus 通信，充當兩者之間的翻譯器。在 Prometheus 適配器的幫助下，HPA 可以使用選定的指標根據推理請求的數量自動擴展 Kubernetes Pod 的副本數量。
在此應用中 ， 我們使用名為 queue-to-compute ratio 的自定義指標作為 HPA 的指標。queue-to-compute ratio 反映推理請求的響應時間。它定義為隊列時間除以 triton-metrics_prometheus-rule.yaml 中推理請求的計算時間。
apiVersion: monitoring.coreos.com/v1kind: PrometheusRulemetadata: name: triton-metrics labels: app.kubernetes.io/component: autoscaler release: prometheusspec: groups: - name: autoscaling interval: 6s rules: # Average percentage of time inference requests spend in queue (not including cache hits). - expr: rate(nv_inference_queue_duration_us[1m])/clamp_min(rate(nv_inference_compute_infer_duration_us[1m]),1) record: triton:queue_compute:ratio |
Prometheus 在 6 秒的時間間隔內抓取 Triton 指標，并使用 Triton 指標志計算自定義指標的值。然后，HPA 根據自定義指標的值上下擴展副本數量。
下方的 hpa.yaml 指定了要部署的最大和最小副本數量；例如，最多 4 個 Pod 和至少 1 個 Pod。使用 Pods 對 metrics-type 取所有 Pod 中隊列與計算之比的平均值。平均隊列與計算之比高于所需值 1,000（毫單位），意味著隊列時間更長，或者副本數量不足以快速響應推理請求。在這種情況下，HPA 應增加副本數量，以降低隊列與計算之比，直到自定義指標低于所需值；如果推理請求量減少，則反之亦然。可以根據您的要求將此目標值設置為任意數量。
{{- $metric_name := "triton:queue_compute:ratio" }}{{- $metric_value := "1000m" }}{{- $replicasMax := 4 }}{{- $replicasMin := 1 }}……apiVersion: autoscaling/v2kind: HorizontalPodAutoscalermetadata: name: {{ $.Release.Name }} labels: app: {{ $.Release.Name }} app.kubernetes.io/component: autoscaler release: prometheus……spec: maxReplicas: {{ $replicasMax }} minReplicas: {{ $replicasMin }} metrics: - type: Pods pods: metric: name: {{ $metric_name }} target: type: AverageValue averageValue: {{ $metric_value }} scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: {{ $.Release.Name }} |
配置好 Kubernetes Deployment、Service、PodMonitor 和 HPA 的 .yaml 文件后，您可以使用以下命令使用 Triton 服務器和 Kubernetes 部署模型：
$ helm install gpt2 --values ./chart/values.yaml --values ./chart/gpt2_values.yaml --set 'triton.image.name=<your custom image>' ./chart/.NAME: gpt2LAST DEPLOYED: Mon Aug 26 23:04:42 2024NAMESPACE: defaultSTATUS: deployedREVISION: 1TEST SUITE: NoneNOTES:triton_trt-llm_aslb-example (0.1.0) installation complete.Release Name: gpt2Namespace: defaultDeployment Name: gpt2Service Name: gpt2 |
驗證 所有 內容 是否 均按 預期 工作 。 您 應該能夠看到輸出信息，例如 Pod 的 NAME、READY 和 STATUS；Service 的 NAME、TYPE 和 PORTS；HPA 的 NAME、MINPODS、MAXPODS 和 REPLICAS 等。
$ kubectl get deployments,pods,hpa,services,podmonitors --selector='app=gpt2'NAME READY UP-TO-DATE AVAILABLE AGEdeployment.apps/gpt2 1/1 1 1 11mNAME READY STATUS RESTARTS AGEpod/gpt2-85cfd5b6d5-4v87s 1/1 Running 0 11mNAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGEhorizontalpodautoscaler.autoscaling/gpt2 Deployment/gpt2 0/1 1 4 1 11mNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEservice/gpt2 ClusterIP 10.100.56.211 <none> 8000/TCP,8001/TCP,8002/TCP 11mNAME AGEpodmonitor.monitoring.coreos.com/gpt2 11m |
例如，如果 Pod 的狀態未成功運行（狀態顯示為 Init:CrashLoopBackOff 或 ImagePullBackOff），您可以嘗試使用以下命令來調試該問題。失敗的潛在原因可能是模型或自定義鏡像未成功下載、Kubernetes secrets 無法正常工作、內存不足等。
$ kubectl describe pod <pod name>$ kubectl logs <pod name> -c init $ kubectl logs <pod name> -c init --previous |
負載均衡器?
您還需要一個負載均衡器，以便在所有正在運行的 Pod 中分配工作負載。負載均衡器主要有兩種類型：Layer 4 和 Layer 7。Layer 4 負載均衡在傳輸級別運行，并根據網絡信息來管理流量，而 Layer 7 負載均衡在應用程序級別運行，并使用協議根據每個消息的內容做出決策。
您可以使用第三方負載均衡器，例如 Traefik ingress 控制器和負載均衡器 ， 或 NGINX Plus ，都屬于第 7 層。有關如何部署 Traefik 和 NGINX Plus 的更多信息，請參閱。如果您使用的是云服務，您還可以使用云負載均衡器。例如， AWS 負載均衡器控制器 可以同時配置應用程序和 網絡負載均衡器 。安裝控制器后，如果服務具有 loadBalancer 類型，您可以要求云控制器配置網絡負載均衡器，如果您創建 Kubernetes ingress，您可以要求 應用程序負載均衡器 。
發送測試推理請求?
最后，您可以通過從客戶端發送推理請求來測試 Triton 服務器。我們提供了一個 示例客戶端 文件夾，您可以從中構建客戶端容器鏡像：
$ docker build -f ./containers/client.containerfile -t <name> ./containers/. |
接下來，將客戶端文件夾中的 .yaml 文件修改為您構建的客戶端容器鏡像的名稱。使用以下命令創建具有一個副本的客戶端部署：
$ kubectl apply -f ./clients/gpt2.yamldeployment.apps/client-gpt2 created |
讓客戶端通過更改客戶端的副本數量來增加或減少推理請求量，并檢查 Pod：
$ kubectl scale deployment/client-gpt2 --replicas=10deployment.apps/client-gpt2 scaled$ kubectl get podsNAME READY STATUS RESTARTS AGEclient-gpt2-cb4bf7b74-6g82l 1/1 Running 0 16sclient-gpt2-cb4bf7b74-6lt8x 1/1 Running 0 16sclient-gpt2-cb4bf7b74-6nnvn 1/1 Running 0 16sclient-gpt2-cb4bf7b74-b7s88 1/1 Running 0 16sclient-gpt2-cb4bf7b74-fl5c6 1/1 Running 0 36sclient-gpt2-cb4bf7b74-j88ld 1/1 Running 0 16sclient-gpt2-cb4bf7b74-jdmkm 1/1 Running 0 16sclient-gpt2-cb4bf7b74-lqptv 1/1 Running 0 16sclient-gpt2-cb4bf7b74-m66cx 1/1 Running 0 16sclient-gpt2-cb4bf7b74-nt7b7 1/1 Running 0 16sgpt2-85cfd5b6d5-65ftt 1/1 Running 0 7m57s |
您可以看到運行的客戶端有 10 個，這顯著增加了推理請求的數量。這將增加自定義指標的值，從而導致 HPA 增加使用 GPT-2 模型的 Triton 服務器的副本數量。
$ kubectl get podsNAME READY STATUS RESTARTS AGEclient-gpt2-cb4bf7b74-6g82l 1/1 Running 0 56sclient-gpt2-cb4bf7b74-6lt8x 1/1 Running 0 56sclient-gpt2-cb4bf7b74-6nnvn 1/1 Running 0 56sclient-gpt2-cb4bf7b74-b7s88 1/1 Running 0 56sclient-gpt2-cb4bf7b74-fl5c6 1/1 Running 0 76sclient-gpt2-cb4bf7b74-j88ld 1/1 Running 0 56sclient-gpt2-cb4bf7b74-jdmkm 1/1 Running 0 56sclient-gpt2-cb4bf7b74-lqptv 1/1 Running 0 56sclient-gpt2-cb4bf7b74-m66cx 1/1 Running 0 56sclient-gpt2-cb4bf7b74-nt7b7 1/1 Running 0 56sgpt2-85cfd5b6d5-65ftt 1/1 Running 0 8m37sgpt2-85cfd5b6d5-65wg4 1/1 Running 0 22sgpt2-85cfd5b6d5-kh9j4 1/1 Running 0 22sgpt2-85cfd5b6d5-pdg5m 1/1 Running 0 22s |
同樣，如果您減少推理請求的數量（例如，將客戶端數量減少到一個副本），HPA 會在幾分鐘后相應地將 Triton 服務器的數量減少到一個副本：
$ kubectl get podsNAME READY STATUS RESTARTS AGEclient-gpt2-cb4bf7b74-6g82l 1/1 Running 0 11mgpt2-85cfd5b6d5-65ftt 1/1 Running 0 19m |
您還可以使用 Grafana 查詢 NVIDIA Triton 指標和自定義指標，通過導航至其 metrics 端點 localhost:8080，按時間序列可視化結果。
圖 2 顯示了反映這一變化的 GPU 利用率和 Queue:Compute Ratio。開始時，一個 GPU 上只運行一個 Triton 服務器副本。因此，GPU 利用率（orange 線）和 Queue:Compute Ratio 有所增加，而推理請求因客戶端數量而顯著增加。
為了減少 自定義指標，HPA 將 Triton 服務器的數量增加到在四個 GPU 上運行的四個副本，如 GPU 利用率 中的四行所示，這有效降低了 Queue:Compute Ratio。最終，推理請求量減少到一個客戶端，因此 GPU 利用率相應降低。
開始使用?
本文提供了在 Kubernetes 環境中部署 Large Language Models 和自動擴展部署的分步說明。Large Language Models 可以使用 NVIDIA TensorRT-LLM 進行優化，然后使用 NVIDIA Triton 推理服務器進行部署。Prometheus 收集 Triton 指標并與 Kubernetes 通信。HPA 可以使用自定義指標自動擴展 Pod 數量，具體取決于客戶端的推理請求數量。
準備好開始使用了嗎？請訪問 GitHub 上的 triton-inference-server/tutorials 。學習更多關于使用 TensorRT-LLM 的 Triton。如果您想制作自己的自定義鏡像，可以從 NGC 中提取 Docker 容器。
?
