Büyük dil modelleri (LLM’ler), chatbot’lar, içerik üretimi, özetleme, sınıflandırma ve çeviri gibi birçok alanda yaygın olarak kullanılmaktadır. Son teknoloji LLM’ler ve temel modeller, Llama, Gemma, GPT ve Nemotron gibi modeller, insan benzeri anlama ve üretim yetenekleri sergilemiştir. Bu modeller sayesinde, AI geliştiricileri, eğitim sürecine baştan başlamaya gerek kalmadan uzun ve masraflı bir süreci atlayabilmektedir.
Geri alma artırılmış üretim (RAG), istemci çalıştırma ve ince ayar yapma gibi teknikler, temel modelleri özel görevler için özelleştirmede ve daha kısa sürede daha yüksek doğruluk elde etmede uygulanabilmektedir. Özelleştirilmiş modeller, hızlı bir şekilde üretimde yer alabilir ve çeşitli kullanım senaryoları için anlık talepleri karşılayabilir.
TensorRT-LLM ile LLM’leri Optimize Etmek
Bu gönderi, NVIDIA TensorRT-LLM kullanarak LLM’leri nasıl optimize edeceğiniz, optimize edilmiş modelleri NVIDIA Triton Inference Server ile nasıl dağıtacağınız ve Kubernetes ortamında LLM dağıtımını nasıl otomatik ölçeklendireceğiniz hakkında adım adım talimatlar sunmaktadır.
NVIDIA TensorRT-LLM, LLM’leri tanımlayan ve optimize eden kolay kullanımlı bir Python API’sidir. NVIDIA Triton Inference Server ise birden fazla framework ve donanım platformunu destekleyen açık kaynak kodlu bir çıkış sunma yazılımıdır. TensorRT-LLM, kernel birleştirme, kuantizasyon, geçici toplama ve sayfalı dikkat gibi çeşitli optimizasyonlar sunarak, optimize edilmiş modellerle çıkışların verimli bir şekilde yapılabilmesini sağlamaktadır.
Kubernetes ile Otomatik Ölçeklendirme
Triton Inference Server, NVIDIA TensorRT, TensorFlow, PyTorch ve ONNX dahil çeşitli derin öğrenme ve makine öğrenimi frameworklerini desteklemektedir. Gerçek zamanlı, toplu, ensemble veya akış gibi birden fazla sorgu tipini destekler. Geliştirici olarak, önce model optimizasyonlarını içeren TensorRT motorları oluşturabilir, ardından optimize edilmiş modelleri üretim ortamında Triton ile dağıtabilirsiniz.
Optimize edilmiş LLM’lerin dağıtımını tek bir GPU’dan birden fazla GPU’ya ölçeklendirebilir, böylece düşük gecikme süresi ve yüksek doğruluk ile binlerce anlık talep ile başa çıkabilirsiniz. Talep hacminin düştüğü durumlarda GPU sayısını azaltmak oldukça yararlıdır. Bu durum, özellikle çevrimiçi alışveriş ve çağrı merkezleri gibi işletmeler için önemli olup, farklı talep hacimlerinin olduğu saatlerde esneklik sağlarken, en yüksek yükleri karşılamak için gerekli donanım kaynaklarını satın almaktan daha düşük bir toplam maliyet avantajı sunar.
Triton metrikleri, Prometheus tarafından toplanır ve Yatay Pod Otomatik Ölçekleyici (HPA) ile gönderilerek, otomatik ölçeklendirme için gereken kararları almaktadır. Bu optimizasyon ve dağıtım için kod ve adımları görmek için triton-inference-server / tutorials sayfasına göz atabilirsiniz.
Donanım ve Yazılım Gereksinimleri
Modellerinizi optimize etmek ve dağıtmak için NVIDIA GPU’lara sahip olmanız gerekmektedir. En yeni NVIDIA GPU nesillerini kullanmanız önerilir. TensorRT-LLM için destek matrisinde desteklenen GPU’ların listesini bulabilirsiniz. Gerekli GPU kaynaklarına sahip kamu bulut hesaplama örneklerinde de modellerinizi dağıtabilirsiniz.
Kubernetes, düşük gecikme süreleri ile büyük ölçekli gerçek zamanlı talepleri karşılamak için dağıtımınızı otomatik olarak ölçeklemek için kullanılabilir. Kubernetes’in hangi düğümlerin GPU’lara sahip olduğunu keşfetmesini ve bu GPU’ları çalışan konteynerler üzerinde erişilebilir hale getirmesini sağlamak için Kubernetes düğüm özellik keşif servisini, NVIDIA cihaz eklentisini, GPU Özellik Keşif servisini ve NVIDIA DCGM Exporter’ı yüklemelisiniz. Ayrıca otomatik ölçeklendirme için metrikler toplamak üzere Prometheus kurulumunu da gerçekleştirmelisiniz. Detaylı kurulum adımlarını burada bulabilirsiniz.
LLM’leri TensorRT-LLM ile Optimize Etmek
TensorRT-LLM, son teknoloji modellerin bir çeşitliliğini desteklemektedir. Model kontrol noktalarını Hugging Face’den indirebilir ve ardından TensorRT-LLM kullanarak model optimizasyonlarını içeren motorlar oluşturabilirsiniz. Modelleri indirmek için bir erişim token’ına ihtiyacınız vardır. Ardından, daha sonraki Kubernetes Dağıtım adımında modelleri indirmek için kullanılacak bir Kubernetes sırrı oluşturabilirsiniz.
Bunu yapmak için aşağıdaki komutu çalıştırabilirsiniz:
$ kubectl create secret generic hf-model-pull '--from-literal=password='
TensorRT-LLM’in nasıl çalıştığı hakkında daha fazla bilgi edinmek için, optimizasyonlar ile popüler modellerin motorlarını oluşturma örneklerini keşfedebilirsiniz. Örneğin, gpt_attention_plugin, paged_kv_cache, gemm_plugin ve quantization ekleyebilirsiniz.
TensorRT motor dosyalarını oluşturmak için, NVIDIA GPU Cloud (NGC) üzerindeki Triton Inference Server’ın TensorRT-LLM ile sağlanan Docker konteyner görüntüsünü kullanabilirsiniz. NGC’den konteyner görüntüsünü çekmek için API anahtarı oluşturmalısınız. Ardından, API anahtarınızı kullanarak NGC’ye giriş yaparak konteyner görüntüsünü çekebilirsiniz.
NGC üzerinde TensorRT-LLM ile Triton’ın temel görüntüsünü çekmenizin ardından, Model Hazırlama Adımları ile referans alarak TensorRT-LLM motor dosyalarını oluşturabilirsiniz. Model boyutunuza ve GPU belleği boyutunuza göre TP tensör paralelizmi (TP) ve hat planlamasını (PP) ayarlayabilirsiniz. Motor dosyalarını oluşturmak için en azına ihtiyacınız olduğunu unutmayın; TP*PP kadar GPU gereklidir.
Özelleştirilmiş bir Triton-TensorRT-LLM görüntüsü oluşturmak için Özelleştirilmiş Konteyner Görüntüsü adımlarını ve betiklerini izleyebilirsiniz. Özel görüntüyü oluşturduktan sonra, kümenizin erişebileceği bir depoya itebilirsiniz. Dağıtım sırasında özel depodan bu özelleştirilmiş görüntüyü çekmek için, Kubernetes docker-registry sırrı oluşturmanız ve Kubernetes’in özel depodan görüntüyü çekmesi için bu sırrı kullanmasını sağlamanız gerekir.
Dağıtım sırasında, oluşturulan TensorRT motoru ve plan dosyaları ana düğümde depolanır ve aynı düğüm üzerindeki tüm Kubernetes Pod’larına yeniden eşlenir. Bu, daha sonra daha fazla Pod ölçeklendirilirse, aynı dosyaların yeniden oluşturulmasına gerek kalmayacağı anlamına gelir.
LLM Dağıtımını Kubernetes ile Otomatik Ölçeklendirme
TensorRT-LLM ile LLM’lerinizi optimize ettikten sonra, Triton kullanarak modellerinizi dağıtabilir ve Kubernetes ile dağıtımı otomatik olarak ölçeklendirebilirsiniz. LLM’lerin AI çıkışı için dağıtım yapmak üzere üç ana adım gereklidir:
- Kubernetes için Triton sunucuları için bir Dağıtım oluşturun
- Triton sunucularını bir ağ servisi olarak açığa çıkaracak bir Kubernetes Servisi oluşturun
- Otomatik ölçeklendirme yapmak için Horizontal Pod Autoscaler (HPA) kullanarak Triton metrikleriyle dağıtımı ölçeklendirin
LLM Dağıtımı için Helm Şeması
Dağıtım için bir Helm şeması kullanabilirsiniz, çünkü bu, farklı ortamlara kolayca uyarlamak ve dağıtmak için kullanışlıdır. Helm şemasını bulmak için Triton Sunucusu ve TensorRT-LLM ile Otomatik Ölçeklendirme ve Yük Dengeleme sayfasına göz atabilirsiniz. Şema dizininde, Helm’in beklediği dosyalar şunlardır:
chart.yaml, paketlediğiniz şemanın tüm bilgilerini, versiyon numarasını ve adını içerir.
values.yaml, şemanızın uygulamaları için tüm değerleri tanımlar, bunlar arasında desteklenen GPU’lar, LLM’ler, Triton’un konteyner görüntüsü, görüntü çekme sırları vb. bulunur. Modeliniz, özel görüntünüz ve GPU türünüz için kendinize özel bir değer dosyası oluşturabilirsiniz. Aşağıda, bir gpt2_values.yaml örneği, NVIDIA A10G GPU’da bir GPT-2 modelini dağıtmak üzerine hazırlanmıştır.
gpu:
- NVIDIA-A10G
model:
name: gpt2
tensorrtLlm:
parallelism:
tensor: 1
triton:
image:
pullSecrets:
-name: ngc-container-pull
name:
Bir GPU’ya sığmayacak kadar büyük bir modeliniz varsa, model ve GPU boyutuna bağlı olarak TP’yi yapılandırabilirsiniz. Örneğin, bir model için model.tensorrtLlm.parallelism.tensor‘ı 2 olarak ayarlayabilir ve her Kubernetes Pod’un iki GPU içerdiği bir Dağıtım yaratabilirsiniz.
Kubernetes Dağıtımı Oluşturma
Bir Kubernetes Dağıtımı, Kubernetes Pod’ları için bildirimsel güncellemeler sağlar. deployment.yaml, Triton sunucularının çoğaltılmış Pod’lar oluşturmasını sağlar. Kaç Pod ile başlayacağınızı .spec.replicas alanında belirtebilirsiniz.
Pod’da her Triton sunucu konteynerinin bulunacağını belirten .spec.containers alanı mevcuttur. Triton sunucularının HPPP ve GRPC üzerinden istemcilerden gelen talep yanıtlarını almak için 8000 ve 8001 port numaraları belirtilmiştir. 8002 portu ise Triton metriklerini toplamak için kullanılır. Model boyutunuza uyacak şekilde .resources.ephemeral-storage alanını değiştirebilirsiniz; örneğin, bir GPT-2 modeli NVIDIA A10G GPU’sunun 24 GB belleğine sığabilir.
apiVersion: apps/v1
kind: Deployment
metadata:
[…]
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 Servisi Oluşturma
Bir Kubernetes Servisi, bir dizi Pod üzerinde çalışan bir uygulamayı açık bir ağ servisi olarak yaymak için karmaşık bir yol sunar. service.yaml, Triton sunucularını ağ servisi olarak açığa çıkararak istemcilerden gelen talep yanıtlarını almaya hazır hale getirir.
apiVersion: v1
kind: Service
metadata:
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 Dağıtımını Otomatik Ölçeklendirme
Uygulamanızı otomatik olarak ölçeklendirmek için, uygulamanızın performansını gözlemlemeniz gerekmektedir. Pod’lar, Servisler ve kapsayıcıların performansına dair izleme yapmalısınız. Ya bir PodMonitor ya da bir ServiceMonitor kullanarak Kubernetes Podlarını veya Servisi hedef keşfi yapmak için izleyebilirsiniz. Kube-Prometheus, Prometheus’u dağıtır ve Prometheus’u metrik uç noktalarına bağlar. Triton metriklerini, bir PodMonitor ve Kube-Prometheus kullanarak Prometheus’a açabilirsiniz.
Aşağıdaki pod-monitor.yaml dosyası, her bir Triton sunucusu için PodMonitor kullanarak izleme sağlar:
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
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, tüm Kubernetes Pod’larından 8002 porta Triton metriklerini toplar. HPA için Triton seçebilir veya kendi özel metriklerinizi tanımlayabilirsiniz. Prometheus adaptörü, Kubernetes ile Prometheus arasında bir iletişim kurarak iki taraf arasında tercümanlık yapar. Prometheus adaptör sayesinde, HPA, belirli bir metrik kullanarak Kubernetes Pod’larının sayısını otomatik olarak ölçeklendirebilir.
Bu uygulamada, HPA için kullanılan özel bir metrik, kuvvet: hesaplama oranı olarak tanımlanır. Bu oran, bir inanç talebinin yanıt süresini gösterir. triton-metrics_prometheus-rule.yaml dosyasında tanımlı olan bu metrik, kuyruk zamanının hesaplama süresine oranıdır.
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: triton-metrics
labels:
app.kubernetes.io/component: autoscaler
release: prometheus
spec:
groups:
- name: autoscaling
interval: 6s
rules:
# Kuyrukta geçirilen süre yüzdesinin ortalaması (ön bellek vuruşları hariç).
- 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, Triton metriklerini 6 saniyelik aralıklarla toplar ve belirtilen metrikleri kullanarak HPA’nın ölçeklendirme kararları almasına yardımcı olur.
HPA yapılandırması hpa.yaml dosyası ile yapılır; örneğin, bir dağıtım için maksimum ve minimum Pod sayısını belirtebilirsiniz ve bu da 4 Pod’a kadar çıkabilirken, en az 1 Pod’da kalır. metrics-type için Pods kullanarak, tüm Pod’lar üzerindeki kuvvet: hesaplama oranı ortalamasını alabilirsiniz. Bu oran hedef değerinden yüksekse, yanıt süresi uzun anlamına gelir ve bu durumda HPA, Pod sayısını artırarak bu oranı düşürmeye çalışır.
{{- $metric_name := "triton:queue_compute:ratio" }}
{{- $metric_value := "1000m" }}
{{- $replicasMax := 4 }}
{{- $replicasMin := 1 }}
……
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
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 Dağıtımı, Servisi, PodMonitor ve HPA için yapılandırdığınız .yaml dosyalarını kullandıktan sonra, modelinizi Triton sunucusu ve Kubernetes ile dağıtmak için aşağıdaki komutu çalıştırmalısınız:
$ helm install gpt2 --values ./chart/values.yaml --values ./chart/gpt2_values.yaml --set 'triton.image.name=' ./chart/.
Her şeyin bekliğiniz gibi çalıştığını kontrol edin. Pod, Servis ve HPA için NAME, READY, STATUS gibi bilgilerin çıktısını alabilmelisiniz. Örneğin:
$ kubectl get deployments,pods,hpa,services,podmonitors --selector='app=gpt2'
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/gpt2 1/1 1 1 11m
NAME READY STATUS RESTARTS AGE
pod/gpt2-85cfd5b6d5-4v87s 1/1 Running 0 11m
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
horizontalpodautoscaler.autoscaling/gpt2 Deployment/gpt2 0/1 1 4 1 11m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/gpt2 ClusterIP 10.100.56.211 8000/TCP,8001/TCP,8002/TCP 11m
NAME AGE
podmonitor.monitoring.coreos.com/gpt2 11m
Eğer Pod’un durumu başarılı bir şekilde çalışmıyorsa, örneğin Init:CrashLoopBackOff veya ImagePullBackOff gibi bir durumla karşılaşırsanız, sorunları giderme amaçlı aşağıdaki komutları deneyebilirsiniz. Olası nedenler; modelin veya özel bir görüntünün başarılı bir şekilde indirilmemesi, Kubernetes sıralarının düzgün çalışmaması veya bellek yetersizliği gibi sebepler olabilir.
$ kubectl describe pod
$ kubectl logs -c init
$ kubectl logs -c init --previous
Yük Dengeleyici Kullanımı
Ayrıca, çalışan tüm Pod’lar arasında yük dengelemesini sağlamak için bir yük dengeleyiciye ihtiyacınız vardır. İki ana yük dengeleyici türü bulunmaktadır: Katman 4 ve Katman 7. Katman 4 yük dengeleyici, ağ bilgisini temel alarak trafiği yönetirken, Katman 7 yük dengeleyici, uygulama düzeyinde işlem yaparak her mesajın içeriğine göre karar alır.
Bir üçüncü taraf yük dengeleyici kullanabilirsiniz; örneğin, Traefik ingress denetleyicisi ve yük dengeleyici ya da NGINX Plus gibi katman 7 yük dengeleyicilerini kullanabilirsiniz. Bulut servisleri kullanıyorsanız, bir bulut yük dengeleyicisi de kullanabilirsiniz. Örneğin, AWS yük dengeleyici denetleyicisi, hem uygulama hem de ağ yük dengeleyicileri tesis edebilir.
Test İnferans Talepleri Gönderme
Son olarak, Triton sunucularını test etmek için istemcilerden inferans talepleri gönderebilirsiniz. Örnek bir istemci dizini, istemci konteyner görüntüsünü oluşturmak için kullanılmaktadır:
$ docker build -f ./containers/client.containerfile -t ./containers/.
Daha sonra istemci dizinindeki <model>.yaml dosyasını, oluşturduğunuz istemci konteyner görüntüsünün adıyla değiştirmelisiniz. Aşağıdaki komutları kullanarak tek bir örnek ile istemci Dağıtımını oluşturabilirsiniz:
$ kubectl apply -f ./clients/gpt2.yaml
deployment.apps/client-gpt2 created
İstemcinin, talep hacmini artırarak veya azaltarak birden fazla kopyayı oluşturmasına izin verin ve Pod’ları kontrol edin:
$ kubectl scale deployment/client-gpt2 --replicas=10
deployment.apps/client-gpt2 scaled
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
client-gpt2-cb4bf7b74-6g82l 1/1 Running 0 16s
client-gpt2-cb4bf7b74-6lt8x 1/1 Running 0 16s
client-gpt2-cb4bf7b74-6nnvn 1/1 Running 0 16s
client-gpt2-cb4bf7b74-b7s88 1/1 Running 0 16s
client-gpt2-cb4bf7b74-fl5c6 1/1 Running 0 36s
client-gpt2-cb4bf7b74-j88ld 1/1 Running 0 16s
client-gpt2-cb4bf7b74-jdmkm 1/1 Running 0 16s
client-gpt2-cb4bf7b74-lqptv 1/1 Running 0 16s
client-gpt2-cb4bf7b74-m66cx 1/1 Running 0 16s
client-gpt2-cb4bf7b74-nt7b7 1/1 Running 0 16s
gpt2-85cfd5b6d5-65ftt 1/1 Running 0 7m57s
On istemcinin çalıştığını görebilirsiniz; bu, zaten bir dizi inferans talebini artırabilir. Bu, özel metriğin değerini artıracak ve dolayısıyla HPA’nın, GPT-2 modelleriyle Triton sunucularının çoğaltılmasını artırarak yanıt süresini düşürmesini sağlayacaktır.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
client-gpt2-cb4bf7b74-6g82l 1/1 Running 0 56s
client-gpt2-cb4bf7b74-6lt8x 1/1 Running 0 56s
client-gpt2-cb4bf7b74-6nnvn 1/1 Running 0 56s
client-gpt2-cb4bf7b74-b7s88 1/1 Running 0 56s
client-gpt2-cb4bf7b74-fl5c6 1/1 Running 0 76s
client-gpt2-cb4bf7b74-j88ld 1/1 Running 0 56s
client-gpt2-cb4bf7b74-jdmkm 1/1 Running 0 56s
client-gpt2-cb4bf7b74-lqptv 1/1 Running 0 56s
client-gpt2-cb4bf7b74-m66cx 1/1 Running 0 56s
client-gpt2-cb4bf7b74-nt7b7 1/1 Running 0 56s
gpt2-85cfd5b6d5-65ftt 1/1 Running 0 8m37s
Son olarak, eğer inferans talepleri sayısını azaltırsanız, yalnızca bir istemci kopyasına düşürürseniz, HPA da birkaç dakika içinde Triton sunucularının kopyasını bir olarak azaltacaktır:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
client-gpt2-cb4bf7b74-6g82l 1/1 Running 0 11m
gpt2-85cfd5b6d5-65ftt 1/1 Running 0 19m
Ayrıca, Grafana kullanarak NVIDIA Triton metrelerini ve özel metriklerinizi sorgulayarak, zaman serisini görselleştirebilirsiniz; metrik uç noktasına gidebilirsiniz: localhost:8080.
Şekil 2, GPU Kullanımı ve Kuyruk:Hesaplama Oranının bu değişimi yansıttığı bir örnek sunmaktadır. Başlangıçta yalnızca bir Triton sunucusu çalışıyordu; bu sebeple GPU kullanımı (turuncu hat) ve Kuyruk:Hesaplama Oranı artış gösterdi. Talep sayısı arttığında HPA, Triton sunucularının kopyasını dördü, bu da sistemin yanıt süresini düşürmesine yardımcı oldu. Nihayetinde talep hacmi bir istemciye düştüğünde, GPU kullanımı da buna bağlı olarak azalmaktadır.
Başlarken
Bu gönderi, LLM’lerinizi dağıtmak ve Kubernetes ortamında otomatik ölçeklendirmek için adım adım talimatlar sunacaktır. LLM’ler, NVIDIA TensorRT-LLM kullanılarak optimize edilebilir ve ardından NVIDIA Triton Inference Server kullanılarak dağıtılabilir. Prometheus, Triton metriklerini toplayarak Kubernetes ile iletişim kurar. HPA, özel bir metrik kullanarak Pod sayısını otomatik olarak ölçeklendirerek, istemcilerden gelen talep miktarına bağlı olarak yanıt verir.
Başlamak için hazır mısınız? triton-inference-server / tutorials sayfasını ziyaret edin. Triton ile TensorRT-LLM hakkında daha fazla bilgi edinin. Kendi özelleştirilmiş görüntünüzü oluşturmak için NGC‘den Docker konteynerlerini çekebilirsiniz.