Thiết lập Model Registry và tích hợp HuggingFace Hub
Tạo một Model Registry nội bộ dựa trên MinIO để lưu trữ các phiên bản model đã được tối ưu hóa, đồng thời cấu hình để vLLM có thể truy cập trực tiếp vào HuggingFace Hub khi cần.
Bước này giúp trung tâm hóa việc quản lý artifact, giảm băng thông mạng khi tải model từ nguồn bên ngoài và cho phép rollback nhanh chóng về các snapshot đã lưu.
Kết quả mong đợi: MinIO chạy trong cluster, bucket "models" được tạo, và các model được upload thành công vào registry.
Deploy MinIO Operator và instance để tạo registry nội bộ.
kubectl apply -f https://operator.min.io/releases/latest/minio-operator.yaml
kubectl apply -f -
Chờ pod MinIO lên trạng thái Running, sau đó tạo bucket "models" và upload model đã tối ưu (ví dụ: Llama-3-8B-TRT).
minio alias set model-registry http://minio.model-registry.svc.cluster.local:9000 minioadmin minioadmin
minio mb model-registry/models --region us-east-1
minio cp ./optimized-models/llama3-8b-trt-v1 model-registry/models/llama3-8b-trt-v1 --recursive
Verify: List bucket và kiểm tra kích thước file đã được upload.
minio ls model-registry/models/llama3-8b-trt-v1 --recursive
Cấu hình vLLM/TensorRT-LLM để load nhiều model trên cluster
Thiết lập Multi-Model Serving với Model Loading Strategy
Cấu hình Kubernetes để chạy các Pod vLLM khác nhau, mỗi Pod phục vụ một model hoặc một nhóm model tương thích (cùng kiến trúc) trên các GPU khác nhau.
Điều này cho phép tận dụng tài nguyên GPU không đồng nhất và phục vụ nhiều use-case (chat, coding, translation) đồng thời trên cùng một cluster.
Kết quả mong đợi: Các Pod vLLM chạy độc lập, mỗi Pod chỉ load một model cụ thể, tránh xung đột bộ nhớ GPU.
Tạo Kubernetes Deployment cho model Llama-3-8B (vLLM) và một Deployment khác cho Mistral-7B (TensorRT-LLM).
cat > /etc/k8s/llama3-deployment.yaml
Deploy model thứ hai (Mistral-7B) sử dụng image TensorRT-LLM custom đã build ở phần trước, mount vào GPU khác.
cat > /etc/k8s/mistral-trt-deployment.yaml
Verify: Kiểm tra trạng thái Pod và xem logs để đảm bảo mỗi Pod đang load đúng model.
kubectl get pods -l app=vllm
kubectl get pods -l app=trt-llm
kubectl logs -f $(kubectl get pods -l app=vllm -o jsonpath='{.items[0].metadata.name}') | grep "loaded"
Quản lý phiên bản model và Rollback qua Kubernetes ConfigMap
Triển khai Dynamic Model Loading
Sử dụng ConfigMap để định tuyến đường dẫn model và version tag. Kết hợp với script entrypoint của container để thực hiện việc tải model mới mà không cần restart toàn bộ Pod (nếu hỗ trợ hot-swap) hoặc restart Pod một cách có kiểm soát (rolling update) dựa trên ConfigMap.
Đây là cơ chế chuẩn để quản lý phiên bản: thay vì hardcode đường dẫn trong Dockerfile, ta dùng biến môi trường hoặc ConfigMap để chỉ định version cần load.
Kết quả mong đợi: Thay đổi ConfigMap kích hoạt việc tải model phiên bản mới (v1.1) thay vì v1.0, hoặc rollback về v1.0 chỉ trong vài phút.
Tạo ConfigMap chứa thông tin phiên bản model hiện tại đang được sử dụng cho Llama-3.
cat > /etc/k8s/llama3-configmap.yaml
Update Deployment vLLM để mount ConfigMap vào biến môi trường và sử dụng script wrapper để tải model từ registry dựa trên biến này.
cat > /etc/k8s/llama3-deployment-v2.yaml
Viết script entrypoint.sh để xử lý logic tải model từ registry vào thư mục local dựa trên biến môi trường.
cat > /opt/entrypoint.sh
Thực hiện update ConfigMap để nâng cấp lên v1.1 (giả định đã upload trước đó) và rollback.
kubectl patch cm llama3-model-config --type merge -p '{"data": {"MODEL_VERSION": "v1.1", "MODEL_REPO": "model-registry/models/llama3-8b-trt-v1.1"}}'
# Rollback về v1.0
kubectl patch cm llama3-model-config --type merge -p '{"data": {"MODEL_VERSION": "v1.0", "MODEL_REPO": "model-registry/models/llama3-8b-trt-v1"}}'
Verify: Kiểm tra xem Pod có tự động reload không (tùy vào cơ chế hot-swap) hoặc kiểm tra logs sau khi rolling update.
kubectl rollout status deployment/vllm-llama3-8b
kubectl logs -f $(kubectl get pods -l app=vllm -o jsonpath='{.items[0].metadata.name}') | grep "Loading model"
Cấu hình Route Rules để định tuyến request về đúng phiên bản model
Sử dụng Ingress và Canary Deployment
Cấu hình Ingress Controller (như Nginx hoặc Traefik) để phân phối traffic dựa trên header, query parameter hoặc tỷ lệ phần trăm (canary) đến các Pod chạy các phiên bản model khác nhau.
Cho phép bạn chạy A/B testing giữa v1.0 và v1.1, hoặc định tuyến request yêu cầu "high-quality" về model lớn hơn, request "fast" về model nhỏ hơn.
Kết quả mong đợi: Request gửi đến endpoint `/v1/chat/completions` với header `X-Model-Version: v1.1` sẽ được chuyển đến Pod chạy v1.1, các request khác đi về v1.0.
Tạo Service riêng cho từng phiên bản model nếu cần tách biệt, hoặc dùng một Service chung với label selector động.
cat > /etc/k8s/llama3-services.yaml
Cấu hình Ingress để định tuyến traffic dựa trên header hoặc path. Ở đây dùng header `X-Model-Version`.
cat > /etc/k8s/llama3-ingress.yaml
Cấu hình Ingress Nginx chi tiết để route theo header `X-Model-Version`.
cat > /etc/k8s/llama3-ingress-advanced.yaml
Cấu hình ConfigMap của Nginx Ingress để map header vào upstream.
cat > /etc/k8s/nginx-configmap.yaml
Verify: Gửi request với header khác nhau và kiểm tra logs của backend xem request về Pod nào.
curl -H "Host: ai-cluster.local" -H "X-Model-Version: v1.1" http:///v1/chat/completions -d '{"model": "llama3", "messages": [{"role": "user", "content": "Hello"}]}'
curl -H "Host: ai-cluster.local" -H "X-Model-Version: v1.0" http:///v1/chat/completions -d '{"model": "llama3", "messages": [{"role": "user", "content": "Hello"}]}'
Điều hướng series:
Mục lục: Series: Series: Xây dựng nền tảng AI inference hiệu năng cao với vLLM, TensorRT-LLM và Kubernetes trên Proxmox
« Phần 7: Giám sát, Logging và Alerting cho hệ thống AI inference
Phần 9: Bảo mật: TLS, Authentication và Network Policies cho AI Gateway »