Skip to main content

NCA-AIIO 3: Container, Cluster & Inference Serving

Cập nhật: 2026-07-09

Mục lục​

1. NVIDIA Container Toolkit​

NVIDIA Container Toolkit là tập hợp thư viện và tiện ích cho phép người dùng build và chạy container có tăng tốc GPU. Toolkit này bao gồm container runtime, toolkit CLI, CDI hooks, container runtime hook, container CLI, và container library — không cần nhớ hết từng thành phần, chỉ cần biết là có nhiều mảnh ghép cùng phối hợp khi sử dụng trong thực tế. Khi cài toolkit này, việc tận dụng GPU trên host system từ trong container trở nên rất dễ dàng.

Có 3 cách để chỉ định GPU khi chạy container, và đây là điểm quan trọng cần phân biệt vì có thể xuất hiện trong đề thi:

# Cách 1 (kiểu cũ): dùng cờ --gpus, chỉ định muốn dùng tất cả GPU
sudo docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smi

# Cách 2: chỉ định chính xác device (số hiệu GPU được gán)
sudo docker run --rm --runtime=nvidia --gpus '"device=0,1"' ubuntu nvidia-smi

# Cách 3 (khuyến nghị): bật Container Device Interface (CDI) và chỉ định qua --device
sudo docker run --rm --device nvidia.com/gpu=all ubuntu nvidia-smi

CDI (Container Device Interface) là một đặc tả (specification) được thiết kế để chuẩn hóa cách các thiết bị như GPU, FPGA và các bộ tăng tốc phần cứng khác được expose và sử dụng bởi container — đây là tính năng của Docker mà NVIDIA Container Toolkit tận dụng. Điều cần nhớ là cách chỉ định GPU bằng --gpus, và cách chỉ định --device cùng target cụ thể muốn dùng.

2. Cài đặt Container Toolkit trên WSL2 + Docker — các lỗi hay gặp​

Khi chạy NVIDIA Container Toolkit qua WSL2 (Windows Subsystem for Linux) kết hợp Docker, có 3 lớp cần phân biệt rõ để tránh nhầm lẫn:

  1. Driver GPU của Windows — chỉ cần cài đúng driver (Game Ready hoặc Studio) trên Windows host. Driver này sẽ tự động được "stub" (ánh xạ) vào trong WSL2. Không được cài driver GPU riêng bên trong WSL — làm vậy có nguy cơ ghi đè lên driver mà WSL2 đang dùng từ host.
  2. CUDA Toolkit — chỉ cần thiết nếu muốn biên dịch code CUDA (cần lệnh nvcc). Đây là công cụ dành cho việc phát triển, không phải điều kiện bắt buộc để chạy container GPU.
  3. NVIDIA Container Toolkit — cần thiết riêng để Docker bên trong WSL2 có thể truy cập GPU. Đây là công cụ dễ bị nhầm lẫn với CUDA Toolkit vì tên gọi khá giống nhau — cài nhầm CUDA Toolkit thay vì Container Toolkit là lỗi rất dễ mắc phải.

Sau khi cài đúng NVIDIA Container Toolkit bên trong WSL2, bước dễ bị bỏ sót nhất là phải đăng ký runtime cho Docker và khởi động lại Docker daemon:

sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Thiếu bước này sẽ liên tục gặp lỗi kiểu "unknown runtime nvidia" dù đã cài toolkit đầy đủ. Sau khi cấu hình xong, kiểm tra bằng:

docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smi

Nếu lệnh trên trả về thông tin GPU đúng như khi chạy nvidia-smi trực tiếp trong WSL2, nghĩa là container đã truy cập được GPU thành công.

3. Triton Inference Server​

Triton Inference Server là một inference server mã nguồn mở. Cách dễ hình dung nhất: nếu web server phục vụ trang web, thì inference server phục vụ quyền truy cập vào một model để thực hiện dự đoán (prediction/inference) và trả về kết quả.

Triton hỗ trợ inference trên cloud, data center, edge, và các thiết bị nhúng chạy GPU NVIDIA, hoạt động được trên cả CPU x86 và ARM. Có thể triển khai model bằng nhiều định dạng: TensorRT, PyTorch, ONNX, OpenVINO, Python, RAPIDS FIL, và nhiều hơn nữa. Triton Inference Server là một phần của NVIDIA AI Enterprise.

Khi thử nghiệm thực tế với ví dụ mẫu (dùng model DenseNet ở định dạng ONNX), quy trình gồm:

# Clone repo ví dụ, tải model
git clone <triton-server-repo>
cd server/docs/examples
./fetch_models.sh

# Chạy Triton server dưới dạng container, dùng model repository vừa tải
docker run --gpus=1 --rm --net=host \
  -v $(pwd)/model_repository:/models \
  nvcr.io/nvidia/tritonserver:<tag> tritonserver --model-repository=/models

# Gửi một inference request từ container client mẫu (NGC Triton SDK container)

Sau khi gửi ảnh để inference với model DenseNet, kết quả trả về đúng các nhãn phân loại (ví dụ nhận diện đúng ly cà phê, bình cà phê trong ảnh mẫu). Điều cần nhớ: Triton là một inference server, dùng để phục vụ LLM/model cho các request inference.

4. DenseNet vs ResNet​

DenseNet và ResNet đều là convolutional neural network, cùng xuất phát từ cuộc thi ImageNet — một cuộc thi phân loại ảnh (nhận diện chó, máy bay,...) diễn ra qua nhiều năm. Mục tiêu của cuộc thi ImageNet là giải quyết các vấn đề như vanishing gradient, suy giảm hiệu năng (degradation) khi tăng số lớp, và hội tụ chậm — nói cách khác, làm sao để mạng neural sâu hơn mà vẫn dễ huấn luyện hơn, đặc biệt với convolutional neural network.

Khác biệt cốt lõi: ResNet cộng dồn (adds) đặc trưng, trong khi DenseNet nối (concatenates) đặc trưng — cả hai đều nhằm giải quyết vấn đề vanishing gradient khi huấn luyện mạng sâu.

So sánh thực dụng:

Tiêu chíResNetDenseNet
Tốc độ huấn luyệnNhanh hơn, cần ít bộ nhớ hơnChậm hơn
Trường hợp phù hợpVision tổng quát, inference nhanhẢnh y tế (medical imaging), cần độ chính xác cao hơn
Yêu cầu tài nguyênPhù hợp khi GPU/dữ liệu huấn luyện hạn chế—

Nói cách khác, lựa chọn giữa hai kiến trúc này là một sự đánh đổi tùy theo yêu cầu cụ thể (GPU huấn luyện hạn chế, dữ liệu huấn luyện hạn chế, hay cần độ chính xác cao). Đề thi có đề cập tới khái niệm vanishing gradient, nhưng không cần hiểu sâu về mặt toán học — chỉ cần nắm khái niệm.

5. Slurm — trình quản lý job cho HPC​

Slurm (Slurm Workload Manager, trước đây gọi là Simple Linux Utility for Resource Management) là một job scheduler mã nguồn mở miễn phí cho các nhân hệ điều hành kiểu Linux/Unix, được nhiều siêu máy tính và cụm máy tính trên thế giới sử dụng. Có thể hình dung Slurm như một hàng đợi (queue) xử lý theo lô (batch queuing), truyền thống được dùng cho high performance computing (HPC).

Slurm được backed bởi một database, quản lý các node, và có khái niệm job, job step, partition. Để tạo một job, viết một file cấu hình Slurm chỉ định tài nguyên cần dùng (bộ nhớ, thời gian, cách xuất kết quả) và script thực thi, sau đó dùng lệnh để đưa job vào hàng đợi, xem trạng thái, hoặc huỷ job.

💡 Hình dung như thế này: Slurm giống hệ thống đặt bàn của một nhà hàng đông khách. Mỗi job là một nhóm khách muốn đặt bàn — phải khai báo trước cần bàn cỡ nào (tài nguyên), ăn trong bao lâu (thời gian). Lễ tân (Slurm scheduler) xếp các nhóm khách vào đúng bàn trống, cho vào hàng chờ nếu nhà hàng đang kín chỗ, và có thể huỷ chỗ nếu khách không tới.

Lý do cần biết Slurm cho kỳ thi: từ khóa "Slurm" có thể xuất hiện trong đề — không cần biết cách vận hành chi tiết, chỉ cần phân biệt được Slurm là công cụ lập lịch job (job scheduling), mã nguồn mở, dùng cho Linux.

6. NVIDIA Base Command Manager​

NVIDIA Base Command Manager là phần mềm quản lý cluster cho AI và HPC, hoạt động ở edge, trong data center, và trong môi trường multi-cloud/hybrid-cloud. Phần mềm có giao diện heads-up display, giúp đơn giản hóa việc cấp phát cluster (provisioning), quản lý luồng công việc, và giám sát hạ tầng. Base Command Manager hỗ trợ quy mô từ 2 đến hàng nghìn node, hỗ trợ kiến trúc Blackwell, Rubin và các hệ thống khác.

Điểm quan trọng nhất cần nhớ: Base Command Manager cho phép orchestration với cả Kubernetes và Slurm — đây là lý do Slurm được đưa vào khóa học, vì nó có thể được quản lý thông qua Base Command Manager. Phần mềm này thường đi kèm giao diện người dùng, dùng được với hệ thống NVIDIA DGX, phù hợp cho việc rapid prototyping và huấn luyện multi-GPU. Có thể quản lý Jupyter Lab qua Base Command Manager, tận dụng lịch trình, xác thực cho GPU quota, và tự động dọn dẹp hạ tầng, đồng thời duy trì khả năng truy cập CUDA 12.6 và NeMo framework cho việc thử nghiệm.

Điều cần nhớ cho kỳ thi: đây là phần mềm quản lý cluster, có khả năng orchestration với Kubernetes và Slurm.

7. NVIDIA GPU Operator​

NVIDIA GPU Operator sử dụng operator framework trong Kubernetes để tự động hóa việc quản lý toàn bộ các thành phần phần mềm NVIDIA cần thiết để cấp phát (provision) GPU. Nó cung cấp (provision) các thành phần như driver NVIDIA, device plugin cho GPU trong Kubernetes, tự động gắn nhãn (node labeling), và giám sát dựa trên DCGM.

Cách cài đặt điển hình là dùng Helm:

helm install --wait --generate-name \
  -n gpu-operator --create-namespace \
  nvidia/gpu-operator

Điều cần nhớ cho kỳ thi: GPU Operator giúp việc bắt đầu sử dụng GPU NVIDIA trên Kubernetes trở nên rất dễ dàng, và được cài đặt qua Helm.

8. NVIDIA DCGM — Data Center GPU Manager​

NVIDIA DCGM (Data Center GPU Manager) là một daemon cho phép người dùng giám sát các GPU của data center chạy NVIDIA. Từ viết tắt này có thể xuất hiện trực tiếp trong đề thi, nên cần nhớ chính xác nó là viết tắt của gì.

DCGM bao gồm giám sát sức khỏe chủ động (active health monitoring), chẩn đoán toàn diện (comprehensive diagnostics), cảnh báo hệ thống, và các chính sách quản trị (governance policies). DCGM tích hợp vào hệ sinh thái Kubernetes thông qua nhiều native API binding (C, Python, Go).

Điều cần nhớ đơn giản: DCGM là một daemon chạy để giám sát GPU của data center.

Nguồn tham khảo​

Nguồn gốc: NVIDIA-Certified Associate AI Infrastructure and Operations (NCA AIIO) Free Study Course — kênh freeCodeCamp.org