NVIDIA AICR đơn giản hóa việc triển khai Dynamo trên Kubernetes
NVIDIA AI Cluster Runtime đóng gói các công thức hạ tầng đã được kiểm chứng cho Dynamo, giúp tinh gọn quá trình thiết lập driver GPU, lịch trình và mạng cho các khối lượng công việc suy luận.
Được dịch tự động từ bản gốc tiếng Anh.
NVIDIA đã ra mắt NVIDIA AI Cluster Runtime (AICR) nhằm tinh gọn quy trình triển khai framework suy luận phân tán Dynamo của hãng trên nền tảng Kubernetes. Được phát hành như một phần của DSX AI Factory Platform, công cụ này đóng gói các công thức hạ tầng đã được kiểm chứng, xử lý những phụ thuộc phức tạp như driver GPU, phân bổ tài nguyên và giám sát. Mục tiêu là cung cấp cho các nhóm nền tảng một nền tảng cơ sở nhất quán, có thể lặp lại để phục vụ các mô hình ngôn ngữ lớn.
Điều gì đã xảy ra
Việc triển khai các mô hình suy luận AI trên Kubernetes không chỉ đơn thuần là chạy các container. Các kỹ sư phải đảm bảo rằng driver GPU, tín hiệu tình trạng nút, phân bổ tài nguyên động và định tuyến mạng đều hoạt động đúng cách cùng nhau. Theo cách truyền thống, việc giải quyết các phụ thuộc này tốn nhiều thời gian và gây ra sự biến đổi giữa các môi trường. NVIDIA giải quyết vấn đề này bằng cách tích hợp Dynamo 1.4.2 và hạ tầng hỗ trợ vào AICR, cung cấp các cấu hình đã được xác thực trước cho các môi trường phần cứng và đám mây cụ thể.
Runtime này nắm bắt các yêu cầu quan trọng như ngữ nghĩa lập lịch gang (gang scheduling), tích hợp số liệu Prometheus và cơ chế khám phá GPU. Bằng cách cố định phiên bản các thành phần và xác định các ràng buộc tương thích, AICR đảm bảo rằng trạng thái cụm cơ bản khớp với kỳ vọng của khối lượng công việc suy luận. Cách tiếp cận này tách biệt độ phức tạp của việc thiết lập runtime khỏi quy trình triển khai ứng dụng, cho phép các nhà phát triển tập trung vào hành vi của mô hình thay vì gỡ lỗi hạ tầng.
AICR hỗ trợ hai đường dẫn định tuyến chính cho Dynamo: bộ định tuyến Dynamo Frontend gốc và Gateway API Inference Extension (GAIE) với Endpoint Picker Plugin (EPP). Lựa chọn phụ thuộc vào việc nhóm quản lý các endpoint dành riêng cho mô hình hay ingress Kubernetes dùng chung. Cả hai đường dẫn đều tận dụng khả năng nhận biết KV-cache để tối ưu hóa việc tạo token, nhưng chúng khác nhau về cách chuyển tiếp và quản lý lưu lượng truy cập trong topo cụm.
Cách thức hoạt động
Dynamo 1.4.2 tách biệt mặt phẳng yêu cầu (request plane) khỏi mặt phẳng sự kiện KV-cache. Nó sử dụng TCP cho các yêu cầu tiêu chuẩn và ZeroMQ (ZMQ) cho các sự kiện KV-cache. Mỗi worker vLLM xuất bản các sự kiện cache thô cục bộ, sau đó runtime Dynamo chuẩn hóa và xuất bản lại. Điều này cho phép cả hai đường dẫn định tuyến đưa ra các quyết định dựa trên cache, hướng các yêu cầu đến những worker đã giữ sẵn các tiền tố prompt liên quan trong bộ nhớ. Cơ chế này giảm bớt nhu cầu xử lý lại các token, cải thiện độ trễ và thông lượng cho các quy trình làm việc dạng agent.
Quy trình triển khai AICR tuân theo năm bước riêng biệt. Thứ nhất, các kỹ sư chụp ảnh trạng thái cụm hiện tại, ghi lại nhãn và taint của các nút. Thứ hai, AICR tạo ra một công thức suy luận Dynamo dựa trên phần cứng và bản phân phối Kubernetes được phát hiện. Thứ ba, nó kết xuất một gói triển khai với các phiên bản được cố định. Thứ tư, runtime được triển khai bằng Helmfile hoặc các công cụ GitOps. Cuối cùng, hệ thống xác thực runtime đã cài đặt trước khi bất kỳ khối lượng công việc ứng dụng nào được lên lịch, đảm bảo hạ tầng sẵn sàng cho lưu lượng sản xuất.
Chi tiết chính
- AICR đóng gói Dynamo 1.4.2 với chart
dynamo-platform, thay thế API v1alpha1 trước đó bằng v1beta1. - Đường dẫn định tuyến mặc định sử dụng bộ định tuyến Dynamo Frontend, trong khi đường dẫn GAIE/EPP tích hợp với ingress Kubernetes dùng chung thông qua các tài nguyên Gateway API.
- NATS không còn được cài đặt theo mặc định trong chart dynamo-platform, mặc dù nó vẫn khả dụng dưới dạng thành phần tùy chọn cho các triển khai cụ thể.
- Các thành phần hạ tầng được hỗ trợ bao gồm NVIDIA GPU Operator, KAI Scheduler, Grove cho điều phối và NVSentinel để kiểm tra tình trạng nút.
- Dynamo 1.5 sẽ giới thiệu EPP Rust gốc để thay thế cầu nối Go/CGO hiện tại, giảm bớt chi phí xử lý mỗi yêu cầu trong đường dẫn GAIE.
- Các công thức xác thực cố định các phiên bản cụ thể, chẳng hạn như NVIDIA GPU Operator v26.7.1 và Kube Prometheus Stack 84.4.0 cho các thiết lập Amazon EKS.
Tại sao điều này quan trọng
Đối với các kỹ sư hạ tầng, lợi ích chính là tính tái lập. Việc cấu hình thủ công các operator GPU, scheduler và stack giám sát thường dẫn đến sự trôi dạt cấu hình và các xung đột tương thích tinh vi. Các công thức đã được kiểm chứng của AICR loại bỏ sự phỏng đoán này bằng cách cung cấp một cấu hình "known-good" (đã biết là tốt) cho các phần cứng cụ thể như NVIDIA GB200 NVL72. Điều này giảm bớt gánh nặng vận hành và đẩy nhanh thời gian từ lúc khởi tạo cụm đến lúc phục vụ mô hình.
Các nhà phát triển hưởng lợi từ đặc điểm hiệu suất nhất quán. Bằng cách đảm bảo các sự kiện KV-cache được định tuyến đúng cách và lập lịch gang được thực thi nghiêm ngặt, runtime giảm thiểu các đỉnh độ trễ do miss cache hoặc tranh chấp tài nguyên. Sự tin cậy này rất quan trọng để xây dựng các ứng dụng AI phản hồi nhanh, đặc biệt là những ứng dụng liên quan đến các phiên làm việc dạng agent kéo dài, nơi việc duy trì ngữ cảnh là yếu tố sống còn.
Những gì bạn có thể làm
- Cài đặt NVIDIA AI Cluster Runtime để tạo ra các công thức đã được kiểm chứng cho môi trường Kubernetes cụ thể của bạn.
- Đánh giá xem trường hợp sử dụng của bạn đòi hỏi sự đơn giản của bộ định tuyến Dynamo Frontend hay khả năng ingress dùng chung của GAIE/EPP.
- Cập nhật các triển khai Dynamo hiện có để sử dụng phiên bản API v1beta1 nhằm phù hợp với các tiêu chuẩn operator mới nhất.
- Cấu hình các worker vLLM để bật caching tiền tố và các sự kiện KV-cache dựa trên ZMQ cho hiệu suất định tuyến tối ưu.
- Sử dụng tính năng chụp ảnh trạng thái (snapshot) của AICR để kiểm toán trạng thái cụm hiện tại của bạn trước khi tạo các công thức suy luận mới.
- Theo dõi quá trình chuyển đổi sang Dynamo 1.5 để tận dụng EPP Rust gốc sắp tới, giúp giảm chi phí xử lý gateway.



