NCA-AIIO 3: Container, cluster và inference serving

Loạt NCA-AIIO (9 phần): 1. Tổng quan & GPU cơ bản · 2. CUDA & lập trình song song · 3. Container & inference serving · 4. H100, H200 & DGX · 5. Networking data center · 6. GPUDirect & NCCL · 7. Blackwell & NVL72 · 8. HGX, DGX & SuperPOD · 9. Vận hành, điện & sizing

Phần 3/9 trong loạt NCA-AIIO: đọc sau Phần 2. Chuyển từ một GPU đơn lẻ sang cách đóng gói và phục vụ model: container, Triton, Kubernetes và các bộ điều phối job.

Cập nhật: 2026-10-23

Mục lục

1. Vì sao container muốn dùng GPU lại cần thêm thứ gì đó?
2. NVIDIA Container Toolkit
3. Ba cách chỉ định GPU cho container
4. Cài trên WSL2 và Docker: ba lớp hay bị nhầm
5. NGC catalog, nơi lấy image
6. Triton Inference Server
7. Model repository và dynamic batching
8. NIM, đóng gói sẵn một model thành dịch vụ
9. DenseNet và ResNet
10. GPU trên Kubernetes: device plugin và GPU Operator
11. Chia sẻ một GPU cho nhiều pod
12. Slurm, bộ lập lịch của thế giới HPC
13. NVIDIA Base Command Manager
14. NVIDIA DCGM
Nguồn tham khảo

1. Vì sao container muốn dùng GPU lại cần thêm thứ gì đó?

Chạy thử một container bình thường rồi gọi nvidia-smi bên trong, kết quả là lệnh không tồn tại. Thêm cờ --gpus all vào Docker chưa cài gì thêm, Docker báo lỗi unknown flag hoặc unknown runtime.

Nguyên nhân nằm ở bản chất của container. Container chia sẻ nhân hệ điều hành với máy chủ nhưng được cách ly về không gian tên, và mặc định nó không nhìn thấy các thiết bị phần cứng của host. Với CPU thì không sao vì nhân tự lo. Với GPU thì cần ba thứ phải khớp nhau:

Driver GPU nằm ở host, không bao giờ cài trong container.
Các thư viện người dùng của driver phải xuất hiện bên trong container, và phải đúng phiên bản khớp với driver ở host.
File thiết bị như /dev/nvidia0 phải được ánh xạ vào container.

Làm thủ công ba việc này rất dễ sai, nhất là chuyện khớp phiên bản thư viện. NVIDIA Container Toolkit sinh ra để tự động hoá chúng.

Ba câu hỏi phần này trả lời:

Làm sao để một container nhìn thấy và dùng được GPU.
Phục vụ một model cho người khác gọi thì dùng công cụ gì.
Khi có cả một cụm, ai quyết định job nào chạy trên GPU nào.

💡 Hình dung như thế này: container giống một căn phòng trọ có khoá riêng trong một toà nhà. Người thuê dùng chung móng và khung nhà (nhân hệ điều hành) nhưng không tự động có quyền vào phòng máy phát điện ở tầng hầm. NVIDIA Container Toolkit đóng vai người quản lý toà nhà: cấp đúng chìa khoá, kéo sẵn đường dây từ máy phát lên đúng phòng, và bảo đảm ổ cắm trong phòng cùng chuẩn với dòng điện dưới hầm.

2. NVIDIA Container Toolkit

NVIDIA Container Toolkit là tập hợp thư viện và tiện ích cho phép build và chạy container có tăng tốc GPU. Bên trong nó gồm container runtime, toolkit CLI, CDI hooks, container runtime hook, container CLI và container library. Không cần thuộc từng thành phần, chỉ cần biết đây là nhiều mảnh phối hợp với nhau để lo phần ánh xạ driver và thiết bị.

Sau khi cài, việc dùng GPU của host từ trong container trở nên đơn giản như thêm một cờ vào lệnh docker run.

Phân biệt với hai thứ tên gần giống, đây là chỗ hay cài nhầm:

Thành phần	Dùng để làm gì	Khi nào cần
Driver GPU	Để hệ điều hành nói chuyện được với card	Luôn cần, cài trên host
CUDA Toolkit	Để biên dịch code CUDA, có `nvcc`	Chỉ khi phát triển, không cần để chạy container
NVIDIA Container Toolkit	Để container truy cập được GPU	Khi chạy workload GPU trong Docker hoặc containerd

Cài CUDA Toolkit khi thật ra cần Container Toolkit là lỗi rất phổ biến, vì hai cái tên chỉ khác nhau một từ.

3. Ba cách chỉ định GPU cho container

Phân biệt được ba cách này là nội dung có thể vào đề.

# Cách 1, kiểu cũ: dùng cờ --gpus để lấy toàn bộ GPU
sudo docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smi

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

# Cách 3, khuyến nghị: dùng Container Device Interface qua cờ --device
sudo docker run --rm --device nvidia.com/gpu=all ubuntu nvidia-smi

CDI (Container Device Interface) là một đặc tả chuẩn hoá cách các thiết bị như GPU, FPGA và bộ tăng tốc khác được expose cho container. Đây là tính năng chung của hệ sinh thái container, không riêng của NVIDIA, và Container Toolkit tận dụng nó. Ưu điểm là cùng một cú pháp dùng được cho Docker, Podman và containerd, thay vì mỗi runtime một kiểu.

Hai thứ cần nhớ: cú pháp --gpus của cách cũ, và cú pháp --device nvidia.com/gpu=... của CDI.

4. Cài trên WSL2 và Docker: ba lớp hay bị nhầm

Khi chạy qua WSL2 (Windows Subsystem for Linux) kết hợp Docker, có ba lớp phải phân biệt rõ:

Driver GPU của Windows. Chỉ cần cài đúng driver (Game Ready hoặc Studio) trên Windows host. Driver này được ánh xạ tự động vào WSL2. Không cài driver GPU bên trong WSL, vì sẽ ghi đè lên phần mà WSL2 đang mượn từ host và làm hỏng kết nối.
CUDA Toolkit. Chỉ cần nếu muốn biên dịch code CUDA. Không bắt buộc để chạy container GPU.
NVIDIA Container Toolkit. Cần riêng, cài bên trong WSL2, để Docker trong đó truy cập được GPU.

Bước hay bị bỏ sót nhất nằm sau khi cài xong: phải đăng ký runtime cho Docker rồi khởi động lại daemon.

# Đăng ký runtime nvidia vào cấu hình Docker
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# Kiểm tra: container phải thấy GPU giống như chạy nvidia-smi trực tiếp
docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smi
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 560.35.03    Driver Version: 560.94    CUDA Version: 12.6         |
|-------------------------------+----------------------+----------------------+
| GPU  Name            Persist-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  NVIDIA RTX 4060     On   | 00000000:01:00.0  On |                  N/A |
|  0%   42C    P8     12W / 115W|    512MiB /  8188MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

Thiếu bước nvidia-ctk runtime configure thì gặp lỗi unknown runtime: nvidia lặp đi lặp lại dù toolkit đã cài đủ.

5. NGC catalog, nơi lấy image

NGC (NVIDIA GPU Cloud) là cổng phần mềm của NVIDIA, catalog nằm tại catalog.ngc.nvidia.com. Đây là kho chứa container, model đã huấn luyện sẵn, Helm chart và script, tất cả đã được tối ưu và kiểm thử cho GPU NVIDIA, cập nhật hằng tháng.

Giá trị thực tế: một image PyTorch từ NGC đã có sẵn CUDA, cuDNN, NCCL đúng phiên bản khớp nhau và đã được tinh chỉnh. Tự dựng image tương đương từ đầu tốn nhiều thời gian và dễ dính các lỗi khớp phiên bản khó chẩn đoán.

Registry của NGC là nvcr.io, và nhiều thành phần quen thuộc như Triton Inference Server được kéo về từ đây. Một số image yêu cầu đăng nhập bằng API key của NGC.

6. Triton Inference Server

Triton Inference Server là một inference server mã nguồn mở. Cách hình dung ngắn gọn: web server phục vụ trang web, còn inference server phục vụ quyền truy cập vào một model để nhận đầu vào, chạy dự đoán và trả kết quả.

Vì sao cần một thành phần riêng cho việc này thay vì tự viết một API bọc quanh model: một dịch vụ inference thật phải lo việc gom nhiều request lại thành batch cho GPU chạy hiệu quả, chạy nhiều model cùng lúc trên một GPU, nạp và gỡ model mà không dừng dịch vụ, quản lý phiên bản model, và xuất số liệu để giám sát. Viết lại từng thứ đó cho mỗi dự án là lãng phí.

Triton chạy được trên cloud, trong data center, ở edge và trên thiết bị nhúng, hỗ trợ CPU x86 lẫn ARM. Nó nhận model ở nhiều định dạng: TensorRT, PyTorch, ONNX, OpenVINO, Python, RAPIDS FIL và nhiều loại khác, mỗi loại qua một backend tương ứng. Triton là một phần của NVIDIA AI Enterprise.

Ba cổng mặc định cần nhớ:

Cổng	Dùng cho
8000	HTTP/REST
8001	gRPC
8002	Số liệu theo định dạng Prometheus

Chạy thử với ví dụ mẫu dùng model DenseNet ở định dạng ONNX:

# Lấy repo ví dụ và tải model mẫu về
git clone https://github.com/triton-inference-server/server.git
cd server/docs/examples
./fetch_models.sh

# Chạy Triton dưới dạng container, trỏ vào model repository vừa tải
docker run --gpus=1 --rm --net=host \
  -v ${PWD}/model_repository:/models \
  nvcr.io/nvidia/tritonserver:26.09-py3 \
  tritonserver --model-repository=/models \
  --model-control-mode explicit --load-model densenet_onnx
I1023 09:14:22.104 1 server.cc:626]
+------------------+---------+--------+
| Model            | Version | Status |
+------------------+---------+--------+
| densenet_onnx    | 1       | READY  |
+------------------+---------+--------+
I1023 09:14:22.218 1 grpc_server.cc:4587] Started GRPCInferenceService at 0.0.0.0:8001
I1023 09:14:22.219 1 http_server.cc:3303] Started HTTPService at 0.0.0.0:8000
I1023 09:14:22.261 1 http_server.cc:178] Started Metrics Service at 0.0.0.0:8002

Gửi ảnh vào model DenseNet rồi nhận về đúng nhãn phân loại là cách xác nhận cả chuỗi đã chạy. Thẻ 26.09-py3 ứng với bản Triton 2.73.0; thẻ thay đổi hằng tháng nên luôn kiểm tra lại trên NGC trước khi dùng.

Cờ --model-control-mode explicit kết hợp --load-model nói với Triton chỉ nạp đúng model được chỉ định thay vì nạp mọi thứ trong thư mục, hữu ích khi model repository chứa nhiều model mà chỉ muốn thử một cái.

7. Model repository và dynamic batching

Model repository là một thư mục có cấu trúc quy định sẵn, nơi Triton tìm model để phục vụ:

model_repository/
├── densenet_onnx/
│   ├── config.pbtxt
│   ├── densenet_labels.txt
│   └── 1/
│       └── model.onnx
└── resnet50_trt/
    ├── config.pbtxt
    ├── 1/
    │   └── model.plan
    └── 2/
        └── model.plan

Thư mục con đánh số chính là phiên bản model. Triton nạp được nhiều phiên bản cùng lúc, nhờ đó chuyển dần lưu lượng từ bản cũ sang bản mới mà không dừng dịch vụ.

File config.pbtxt khai báo tên model, backend, hình dạng đầu vào và đầu ra, cùng các tuỳ chọn tối ưu. Hai tuỳ chọn đáng biết:

Dynamic batching cho phép Triton giữ các request đến gần nhau trong một khoảng thời gian rất ngắn rồi gộp chúng thành một batch gửi xuống GPU. GPU xử lý một batch 32 ảnh tốn ít thời gian hơn nhiều so với chạy 32 lần một ảnh đơn lẻ, nên thông lượng tăng mạnh mà độ trễ chỉ tăng chút ít. Người gọi không cần biết, họ vẫn gửi từng request riêng lẻ.

Concurrent model execution cho phép nhiều bản sao của cùng một model, hoặc nhiều model khác nhau, chạy song song trên cùng một GPU. Hữu ích khi một model đơn lẻ không dùng hết tài nguyên GPU.

💡 Hình dung như thế này: dynamic batching giống chuyến xe buýt chờ thêm vài giây ở bến để đón nốt khách đang chạy tới, thay vì mỗi khách đi một chuyến riêng. Mỗi người tới sớm phải chờ thêm một chút, nhưng số người được chở trong một giờ tăng lên nhiều lần vì xe không còn chạy rỗng.

8. NIM, đóng gói sẵn một model thành dịch vụ

NIM (NVIDIA Inference Microservices) đi thêm một bước so với Triton: thay vì cung cấp một server rồi để người dùng tự chuẩn bị model, mỗi NIM là một container đã chứa sẵn một model cụ thể cùng toàn bộ phần tối ưu cho nó.

Bên trong một container NIM có CUDA, TensorRT, TensorRT-LLM và Triton Inference Server, tất cả đã được cấu hình cho đúng model đó. Người dùng kéo image từ nvcr.io, chạy lên, và có ngay một endpoint.

Điểm khiến NIM dễ dùng là API tương thích OpenAI: các endpoint quen thuộc như /v1/chat/completions, /v1/completions và /v1/models. Code đang gọi OpenAI thường chỉ cần đổi base URL là chạy được với NIM.

	Triton	NIM
Nội dung	Server, người dùng tự chuẩn bị model	Server kèm sẵn một model đã tối ưu
Cấu hình	Tự viết `config.pbtxt`	Có sẵn
API	API riêng của Triton	Tương thích OpenAI
Phù hợp	Model tự huấn luyện, nhiều loại model	Model phổ biến, muốn chạy nhanh

NIM thuộc NVIDIA AI Enterprise, và dùng trong môi trường production cần giấy phép tương ứng.

9. DenseNet và ResNet

Hai model này xuất hiện trong các ví dụ của Triton và cũng hay vào đề, nên cần phân biệt được.

Cả hai đều là convolutional neural network, huấn luyện và đánh giá trên tập ảnh ImageNet, trong đó ResNet thắng cuộc thi ILSVRC năm 2015 còn DenseNet là công trình nghiên cứu công bố sau đó, tại hội nghị CVPR 2017. Bài toán chung mà chúng giải quyết là vanishing gradient: khi mạng neural càng sâu, tín hiệu điều chỉnh lan ngược về các lớp đầu càng yếu dần cho tới khi gần như bằng không, khiến các lớp đó không học được gì.

Khác biệt cốt lõi nằm ở cách nối tắt giữa các lớp:

ResNet cộng đặc trưng của lớp trước vào đầu ra lớp sau.
DenseNet nối (concatenate) đặc trưng của mọi lớp trước vào đầu vào lớp sau.

Tiêu chí	ResNet	DenseNet
Phép nối tắt	Cộng	Nối chuỗi
Tốc độ huấn luyện	Nhanh hơn	Chậm hơn
Bộ nhớ activation lúc training	Ít hơn	Nhiều hơn
Phù hợp	Vision tổng quát, inference nhanh, GPU hoặc dữ liệu hạn chế	Ảnh y tế và các bài toán cần độ chính xác cao hơn

Đề thi có nhắc tới vanishing gradient nhưng không đòi hỏi hiểu sâu phần toán, chỉ cần nắm khái niệm và biết hai kiến trúc này sinh ra để xử lý nó.

10. GPU trên Kubernetes: device plugin và GPU Operator

Kubernetes không biết GPU là gì. Nó quản lý CPU và bộ nhớ như tài nguyên có sẵn, còn mọi phần cứng khác phải được khai báo qua cơ chế device plugin.

Để một cụm Kubernetes chạy được workload GPU, cần đủ một chuỗi thành phần trên mỗi node: driver, container toolkit, device plugin, thành phần gắn nhãn node theo loại GPU, và thành phần giám sát. Cài và nâng cấp từng thứ trên hàng chục node là công việc tẻ nhạt và dễ lệch phiên bản.

NVIDIA GPU Operator dùng mô hình operator của Kubernetes để tự động hoá toàn bộ chuỗi đó. Nó cài driver, device plugin, công cụ gắn nhãn node, container toolkit và phần giám sát dựa trên DCGM, rồi giữ chúng ở đúng trạng thái mong muốn.

Cài bằng Helm:

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

# Sau khi cài xong, node được gắn nhãn tự động theo loại GPU phát hiện được
kubectl get nodes -o json | jq '.items[].metadata.labels | with_entries(select(.key | startswith("nvidia.com")))'
{
  "nvidia.com/gpu.count": "8",
  "nvidia.com/gpu.product": "NVIDIA-H100-80GB-HBM3",
  "nvidia.com/gpu.memory": "81559",
  "nvidia.com/mig.capable": "true"
}

Hai thứ đáng nhớ cho kỳ thi: GPU Operator tự động hoá việc cấp phát mọi thành phần phần mềm NVIDIA cần cho GPU trên Kubernetes, và nó được cài qua Helm.

11. Chia sẻ một GPU cho nhiều pod

Một GPU H100 cấp trọn cho một pod chạy model nhỏ là lãng phí. Có bốn cơ chế chia sẻ, khác nhau ở mức độ cách ly.

Cơ chế	Cách chia	Cách ly bộ nhớ	Cách ly lỗi
MIG	Phần cứng, mỗi instance có SM và bộ nhớ riêng	Có	Có
MPS	Nhiều tiến trình dùng chung ngữ cảnh GPU	Không	Không
Time-slicing	Luân phiên theo thời gian	Không	Không
vGPU	Ảo hoá cho máy ảo	Theo máy ảo	Theo máy ảo

Time-slicing được cấu hình bằng cách khai số replica cho mỗi GPU. Khai 4 replica thì Kubernetes thấy node có 4 GPU thay vì 1, và xếp được 4 pod lên đó. Các pod luân phiên dùng GPU. Tài liệu NVIDIA nói rõ cơ chế này không cách ly bộ nhớ và không cách ly lỗi giữa các replica, đó là cái giá phải trả so với MIG. Bù lại, nó chạy được trên cả các GPU đời cũ không hỗ trợ MIG. Mặc định GPU Operator không áp cấu hình time-slicing lên node nào, phải bật tường minh và có thể áp theo từng node bằng nhãn.

MIG strategy trong cấu hình GPU Operator nhận ba giá trị:

Giá trị	Ý nghĩa
`none`	Mặc định, không dùng MIG
`single`	Mọi GPU trên node dùng chung một profile MIG
`mixed`	Các GPU trên node mang profile khác nhau

Đặt mixed khi MIG không được bật trên toàn bộ GPU của một node. Chế độ mixed sinh ra các tên tài nguyên riêng theo từng profile, ví dụ nvidia.com/mig-1g.10gb, nên pod xin đúng loại lát mình cần.

Hai cơ chế này kết hợp được: bật MIG ở chế độ mixed rồi áp time-slicing lên từng instance MIG, cho phép nhiều pod dùng chung một lát MIG.

Hướng chọn thực tế: cần đảm bảo chất lượng dịch vụ giữa các nhóm người dùng khác nhau thì dùng MIG; chỉ cần tận dụng GPU rảnh cho các job nhỏ không quan trọng thì time-slicing đơn giản hơn và không đòi phần cứng cao cấp.

12. Slurm, bộ lập lịch của thế giới HPC

Slurm (Slurm Workload Manager, tên cũ là Simple Linux Utility for Resource Management) là bộ lập lịch job mã nguồn mở cho Linux, được phần lớn siêu máy tính trên thế giới sử dụng. Mô hình của nó là hàng đợi xử lý theo lô, truyền thống của high performance computing.

Slurm có một cơ sở dữ liệu phía sau, quản lý danh sách node, và làm việc với các khái niệm job, job step, partition. Người dùng viết một script khai báo tài nguyên cần dùng rồi nộp vào hàng đợi:

# Nội dung file train.sbatch
#!/bin/bash
#SBATCH --job-name=llama-finetune
#SBATCH --nodes=4
#SBATCH --gpus-per-node=8
#SBATCH --time=12:00:00
#SBATCH --partition=gpu
srun python train.py

# Nộp job vào hàng đợi
sbatch train.sbatch
Submitted batch job 184726

# Xem trạng thái hàng đợi
squeue -u $USER
   JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
  184726       gpu llama-fi       rd  R       0:42      4 dgx[01-04]

# Huỷ job
scancel 184726

Lý do Slurm xuất hiện trong chương trình của một chứng chỉ về AI: nó được NVIDIA Base Command Manager quản lý, và nhiều cụm GPU lớn vẫn chạy trên nó. Không cần thuộc cú pháp, chỉ cần phân biệt được Slurm là bộ lập lịch job mã nguồn mở cho Linux, theo mô hình hàng đợi xử lý theo lô.

💡 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 nhóm khách khai trước cần bàn cỡ nào và dự định ngồi bao lâu, lễ tân xếp họ vào bàn trống phù hợp hoặc cho vào danh sách chờ nếu kín chỗ, và huỷ chỗ nếu khách không tới đúng giờ.

13. NVIDIA Base Command Manager

NVIDIA Base Command Manager là phần mềm quản lý cụm cho AI và HPC, chạy ở edge, trong data center và trong môi trường lai nhiều cloud. Nó lo việc cấp phát node, cài hệ điều hành, theo dõi tình trạng và điều phối luồng công việc, kèm giao diện giám sát trực quan.

Phần mềm hỗ trợ quy mô từ 2 node tới hàng nghìn node, và hỗ trợ các kiến trúc mới gồm Blackwell và Rubin.

Base Command Manager điều phối được cả Kubernetes lẫn Slurm, và đó là lý do Slurm được đưa vào chương trình học. Trong thực tế nhiều cụm chạy song song hai phân vùng: Slurm cho training dài ngày, Kubernetes cho inference co giãn theo tải.

Phần mềm cũng quản lý được Jupyter Lab, áp hạn mức GPU theo người dùng kèm xác thực, và tự dọn dẹp tài nguyên sau khi job kết thúc.

14. NVIDIA DCGM

NVIDIA DCGM (Data Center GPU Manager) là một daemon chạy để giám sát GPU của data center, và từ viết tắt này có thể xuất hiện thẳng trong đề thi nên cần nhớ đúng tên đầy đủ. GPU Operator cài sẵn DCGM cùng DCGM Exporter, còn danh sách chỉ số cần theo dõi và cách xử lý lỗi XID được trình bày ở phần vận hành của loạt bài.

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.

Đã fact-check (truy cập 2026-10-23):

Thẻ container Triton hiện tại 26.09-py3 ứng với bản 2.73.0, lệnh chạy kèm --model-control-mode explicit --load-model densenet_onnx, quy trình fetch_models.sh: triton-inference-server/server
Yêu cầu NVIDIA Container Toolkit và biến thể chạy không GPU: Triton Inference Server Quickstart
Ba cổng mặc định 8000 HTTP, 8001 gRPC, 8002 metrics: tài liệu Triton, mục Running the Server.
Time-slicing khai theo số replica, không cách ly bộ nhớ và không cách ly lỗi, dùng được cho GPU đời cũ không hỗ trợ MIG, mặc định không áp lên node nào, kết hợp được với MIG: Time-Slicing GPUs in Kubernetes
Ba giá trị của migStrategy (none, single, mixed) và tên tài nguyên sinh ra ở chế độ mixed: GPU Operator with MIG
Cài GPU Operator bằng Helm và danh sách thành phần nó quản lý: Installing the NVIDIA GPU Operator
NIM gồm container kèm model, bên trong có CUDA, TensorRT, TensorRT-LLM và Triton, API tương thích OpenAI với các endpoint /v1/chat/completions và /v1/models, kéo từ nvcr.io bằng NGC API key, thuộc NVIDIA AI Enterprise: Deploy NVIDIA NIM, LLM Inference Benchmarking Guide
ResNet thắng ILSVRC năm 2015, DenseNet là công trình nghiên cứu công bố tại CVPR 2017: Deep Residual Learning for Image Recognition, Densely Connected Convolutional Networks
Base Command Manager điều phối được cả Kubernetes lẫn Slurm: NVIDIA Base Command Manager
Output mẫu của nvidia-smi và kubectl get nodes trong bài là minh hoạ định dạng, số liệu thay đổi theo từng máy.

Mục lục​

1. Vì sao container muốn dùng GPU lại cần thêm thứ gì đó?​

2. NVIDIA Container Toolkit​

3. Ba cách chỉ định GPU cho container​

4. Cài trên WSL2 và Docker: ba lớp hay bị nhầm​

5. NGC catalog, nơi lấy image​

6. Triton Inference Server​

7. Model repository và dynamic batching​

8. NIM, đóng gói sẵn một model thành dịch vụ​

9. DenseNet và ResNet​

10. GPU trên Kubernetes: device plugin và GPU Operator​

11. Chia sẻ một GPU cho nhiều pod​

12. Slurm, bộ lập lịch của thế giới HPC​

13. NVIDIA Base Command Manager​

14. NVIDIA DCGM​

Nguồn tham khảo​