Dynamo trên Kubernetes: dựng runtime GPU đã kiểm chứng trước khi chạy model

NVIDIA AI Cluster Runtime (AICR) đóng gói driver GPU, DRA, scheduler, kiểm tra sức khỏe node và Prometheus thành recipe tương thích cho NVIDIA Dynamo, giúp tách chuẩn bị cluster khỏi triển khai model inference.

Một cụm Kubernetes có GPU chưa tự động trở thành cụm inference sẵn sàng vận hành. Model có thể chạy trong pod, nhưng driver, cơ chế phát hiện và cấp phát GPU, scheduler, tình trạng node, mạng và monitoring phải hoạt động đồng bộ.

NVIDIA giới thiệu NVIDIA AI Cluster Runtime (AICR) như một cách đóng gói các phụ thuộc này cho NVIDIA Dynamo trên Kubernetes. Thay vì chỉ cài framework serving, AICR cung cấp các recipe có phiên bản thành phần được ghim, ràng buộc tương thích và bước kiểm tra runtime.

Dynamo cần nhiều hơn một DynamoGraphDeployment

Dynamo là framework inference phân tán, điều phối việc phục vụ model qua nhiều GPU worker. Trên Kubernetes, workload được mô tả bằng DynamoGraphDeployment, một CRD với API nvidia.com/v1beta1. API v1beta1 thay thế phiên bản v1alpha1 trước đó.

Nhưng graph deployment chỉ là tầng ứng dụng. Runtime bên dưới còn phải đáp ứng các yêu cầu như:

Driver và phần mềm GPU phù hợp với node. GPU được phát hiện, gắn nhãn và cấp phát đúng. Scheduler đặt GPU worker theo topology và yêu cầu gang scheduling. Các thành phần của graph serving được khởi động, đặt lịch và scale theo nhóm phối hợp. Có tín hiệu sức khỏe node trước khi workload được đặt lên node suy giảm. Prometheus thu thập metric cluster, accelerator và Dynamo. Nếu dùng ingress theo Kubernetes, Gateway API và Endpoint Picker được cấu hình cho đường routing tương ứng.

AICR đưa các yêu cầu này vào recipe, gồm phiên bản thành phần, giá trị cấu hình, node selector, toleration, checksum và kỳ vọng kiểm tra.

Stack AICR đóng gói cho Dynamo

AICR phân phối chart dynamo-platform phiên bản 1.4.2. Chart này gồm Dynamo operator, image runtime Dynamo và các tài nguyên như CRD DynamoGraphDeployment.

Các thành phần hạ tầng trong recipe được NVIDIA mô tả như sau:

| Nhu cầu vận hành | Thành phần trong recipe | |---|---| | Driver và phần mềm GPU | NVIDIA GPU Operator | | Phát hiện GPU, gắn nhãn node | Node Feature Discovery | | Cấp phát GPU theo Dynamic Resource Allocation | DRA Driver for NVIDIA GPUs | | Topology và gang scheduling | KAI Scheduler | | Điều phối graph serving nhiều thành phần | Grove | | Tín hiệu sức khỏe node | NVSentinel và Nodewright, tùy recipe | | Metric cluster, accelerator và Dynamo | Prometheus stack | | Ingress theo Kubernetes | agentgateway và Gateway API resources |

Recipe cũng ghim phiên bản các thành phần và ghi nhận ràng buộc tương thích để việc triển khai có thể tái lập.

Dựng runtime trước, cài model sau

AICR tách phần chuẩn bị hạ tầng khỏi triển khai ứng dụng theo luồng năm bước:

Snapshot cluster để ghi nhận trạng thái và đặc điểm hạ tầng. Tạo Dynamo inference recipe cho môi trường và workload. Render deployment bundle từ recipe. Triển khai runtime bằng Helmfile hoặc GitOps. Validate runtime trước khi cài workload ứng dụng.

Điểm quan trọng ở đây là runtime được kiểm tra trước khi model workload đi vào cluster. Điều này giúp đội platform có một nền tảng nhất quán hơn để phục vụ model và thử nghiệm ứng dụng.

Hai đường routing dựa trên KV-cache

Dynamo hỗ trợ hai đường routing trên Kubernetes. Cả hai đều sử dụng trạng thái KV-cache để hướng request tới worker đã có phần tiền tố liên quan trong bộ nhớ GPU.

Với workload agent, phần tiền tố có thể gồm system prompt, định nghĩa tool, lịch sử hội thoại và kết quả tool. Nếu request đến một worker chưa giữ các KV block tương ứng, hệ thống cần xử lý lại một phần hoặc toàn bộ prompt thay vì tái sử dụng cache.

Path 1: Dynamo Frontend router

Đây là đường mặc định. Dynamo Frontend được đặt phía sau một Kubernetes Service.

Khi chạy với DYNROUTERMODE=kv, Frontend token hóa request, đánh giá worker theo mức trùng tiền tố và tải hiện tại, sau đó chọn worker để chuyển tiếp request qua request plane. Theo đường mặc định của AICR, request plane dùng TCP.

text DYNROUTERMODE=kv

NVIDIA cho biết topology này phù hợp với endpoint chuyên biệt cho một model, hoặc khi edge proxy hiện có chỉ cần chuyển tiếp lưu lượng tới Dynamo Frontend Service. Đây cũng là topology nhỏ nhất để triển khai và kiểm tra một Dynamo graph, không cần thêm các thành phần gateway và EPP của đường thứ hai.

Path 2: Gateway API, GAIE và EPP

Đường thứ hai tích hợp cache-aware routing ở lớp ingress Kubernetes thông qua Gateway API Inference Extension (GAIE) và Endpoint Picker Plugin (EPP).

AICR có thể cài và kiểm tra topology này cùng agentgateway và các Gateway API resource. Cách triển khai phù hợp với trường hợp muốn tích hợp Dynamo vào ingress dùng chung được quản lý bằng Gateway API.

Đổi lại, topology này bổ sung các thành phần gateway và EPP so với đường Dynamo Frontend trực tiếp.

Luồng sự kiện KV-cache trong Dynamo 1.4.2

Trong Dynamo 1.4.2, request plane và event plane của KV-cache tách biệt:

Request sử dụng TCP theo đường Kubernetes mặc định của AICR. Sự kiện KV-cache sử dụng ZMQ. Mỗi vLLM worker engine phát raw KV-cache event qua một ZMQ publisher cục bộ. Runtime Dynamo đăng ký nguồn event này, chuẩn hóa event và phát lại lên event plane của Dynamo. Dynamo Frontend router hoặc GAIE/EPP dùng trạng thái KV-cache do Dynamo quản lý để đưa ra quyết định routing.

Ví dụ cấu hình vLLM được NVIDIA nêu để bật prefix caching và phát sự kiện KV-cache:

text --enable-prefix-caching --kv-transfer-config \ {"enablekvcacheevents": true, "publisher": "zmq", "endpoint": "tcp://:5557"}

Từ Dynamo 1.4, frontend, worker, các thành phần GAIE/EPP tùy chọn và dịch vụ Dynamo khác khám phá lẫn nhau qua tài nguyên Kubernetes. Vì vậy, đường mặc định của AICR không còn dùng NATS; chart dynamo-platform cũng không cài NATS theo mặc định. NATS vẫn có thể được bật tùy chọn cho các deployment cần nó.

Tách prefill và decode để điều chỉnh độc lập

Dynamo cũng hỗ trợ disaggregated serving: tách xử lý prompt (prefill) khỏi sinh token (decode).

Khi cache miss xảy ra, một phần hoặc toàn bộ prompt cần được prefill pool xử lý lại. Decode worker sau đó tiếp quản việc sinh token. Hai giai đoạn này có đặc tính khác nhau về GPU, bộ nhớ, độ trễ và batching, vì vậy có thể được scale và điều chỉnh độc lập theo từng kiểu tải.

Tỷ lệ cache miss phụ thuộc vào workload. Các phiên agent kéo dài có đặc điểm khác với request chat một lượt, nên việc cấu hình prefill và decode cần gắn với request mix thực tế.

Giá trị chính: runtime có thể tái lập và kiểm tra

AICR không chỉ gom Dynamo vào một chart. Cách tiếp cận này đóng gói driver GPU, discovery, DRA, scheduling, tín hiệu sức khỏe node, monitoring và ingress tùy chọn thành một runtime có phiên bản, ràng buộc tương thích và bước xác minh.

Với đội hạ tầng phải vận hành inference trong mạng nội bộ, việc tách runtime đã được kiểm tra khỏi graph và model workload giúp giảm phần thời gian dành cho việc dò lỗi giữa các lớp hạ tầng, để tập trung hơn vào hành vi model, hiệu năng serving và tích hợp ứng dụng.