Với các cluster GPU thế hệ Grace Blackwell (GB200/GB300 NVL72), câu hỏi "job chạy ở đâu" quan trọng gần ngang câu hỏi "có bao nhiêu GPU". SkyPilot vừa đăng một bài blog giải thích vì sao scheduler cần hiểu topology của rack NVL72, kèm một số liệu gây chú ý: chia rack thành slice 16 node thay vì dùng trọn 18 node có thể cho thêm 27% capacity thực sự dùng được. Bài lên top Hacker News, nhưng phần bình luận cũng khá gắt. Bài này tóm lại phần kiến thức hữu ích và các phản biện, để bạn có cái nhìn cân bằng.

Vì sao communication là nút thắt

Khi train model lớn, ta phải trả lời hai câu hỏi: chia model thế nào để vừa bộ nhớ GPU, và chạy bao nhiêu bản sao song song để tối đa throughput. Câu đầu được giải bằng tổ hợp các kiểu parallelism:

  • Tensor Parallelism (TP): chia ma trận trọng số trong mỗi layer cho nhiều GPU. Theo cách của Megatron-LM, mỗi block (attention hoặc MLP) gồm hai GEMM, GEMM đầu chia theo cột, GEMM sau chia theo hàng, nên chỉ cần một all-reduce mỗi block. Dù vậy, forward pass vẫn có hai all-reduce mỗi transformer layer, nằm trên critical path và khó overlap với tính toán.
  • Expert Parallelism (EP): với model MoE, đặt các expert lên các GPU khác nhau. Mỗi MoE layer cần hai bước all-to-all (dispatch token đến expert và combine kết quả về).
  • Pipeline Parallelism (PP): chia model theo layer.

Câu thứ hai quyết định mức Data Parallelism (DP).

TP và EP là hai kiểu tốn băng thông nhất, nên phải đặt trên NVLink. Bài gốc dẫn số liệu Hugging Face đo được throughput giảm 43% khi chuyển TP từ NVLink sang InfiniBand. Với MoE 64-way EP trên server 8 GPU truyền thống, traffic all-to-all buộc phải đi qua InfiniBand, nơi băng thông mỗi GPU thấp hơn khoảng 18 lần.

Inference cũng không khác. Chia model qua nhiều GPU giải phóng bộ nhớ cho KV cache, cho phép nhiều request đồng thời hơn hoặc context dài hơn. Bài gốc trích benchmark của vLLM: chạy Llama-3.1-70B tensor-parallel trên hai H100 tăng số block KV cache lên 13.9 lần và throughput 3.9 lần so với một GPU. Lý do là với một GPU, gần như toàn bộ bộ nhớ đã bị trọng số chiếm, phần còn lại cho KV cache rất ít, nên thêm GPU thứ hai làm phần dư tăng vọt.

NVL72: rack là server mới

NVL72 nối toàn bộ 72 GPU trong một rack bằng một NVLink fabric thống nhất. Mỗi GPU có 18 port NVLink, mỗi port 100 GB/s hai chiều, tổng 1.8 TB/s mỗi GPU. Mỗi port nối tới một trong 18 chip NVSwitch, nên fabric là non-blocking: bất kỳ GPU nào cũng nói chuyện với GPU khác trong rack ở cùng băng thông và độ trễ.

Hệ quả cho scheduling: một job multi-node nằm gọn trong một rack được hưởng NVLink, nhưng nếu bị rải qua hai rack thì phần giao tiếp liên rack lại quay về InfiniBand (400 Gb/s mỗi chiều). Scheduler không biết topology sẽ âm thầm làm job chậm đi.

Phần đáng giá nhất: bài toán slice và độ tin cậy

Ý tưởng hay nhất của bài là phân tích độ tin cậy. GPU hỏng thường xuyên. Bài gốc dẫn số liệu Meta: mean time between interruptions (MTBI) khoảng 490 ngày cho mỗi node 4 GPU. Một rack NVL72 có 18 node như vậy, nên MTBI của rack xấp xỉ:

MTBI_rack ≈ MTBI_node / số_node = 490 / 18 ≈ 27 ngày

Trên cluster 128 rack, cứ khoảng 5 giờ lại có một rack có node hỏng. Nếu job chiếm trọn 18 node, mỗi lần hỏng là cả rack không chạy được job full-rack cho đến khi sửa xong.

Giải pháp: chỉ cấp 16 node mỗi slice, giữ 2 node dự phòng trong mỗi rack. Khi một node hỏng, đổi sang node dự phòng cùng rack, job vẫn giữ được NVLink. Dựa trên mô hình của NVIDIA cho cluster 128 rack (2.304 node) và tỷ lệ node không khả dụng khoảng 2% mà SkyPilot đo được trên production:

  • Slice 16 node cho khoảng 2.037 node dùng được, so với 1.602 node khi dùng slice 18 node, tức hơn 27%.
  • Slice 16 node còn hơn slice 9 node khoảng 4%, dù hai slice 9 lấp kín rack: với slice 9, mỗi lần hỏng mất nửa rack, còn slice 16 hấp thụ được hai lỗi đầu tiên.
  • So với slice 8 node, slice 16 cho mỗi job gấp đôi GPU trong cùng NVLink domain mà mất chưa tới 1% capacity, chừng nào tỷ lệ node hỏng dưới khoảng 3.3%.

64 GPU cũng là lũy thừa của 2, khớp với cách thường chia nhóm parallelism.

Đây là kiểu tư duy đáng mang sang các bài toán khác: đôi khi cố tình để dư lại cho hệ thống tổng thể dùng được nhiều hơn, giống như giữ headroom trong capacity planning hay spare trong RAID.

Scheduler làm gì cụ thể

Bài mô tả ba cơ chế:

  1. Topology-aware placement: đặt toàn bộ worker của một slice vào cùng rack; job nhiều rack được chia thành các slice, mỗi slice một rack.
  2. In-place recovery: khi phát hiện GPU lỗi, hot swap node lỗi bằng node dự phòng cùng rack trong khi các node khác tiếp tục chạy; hết dự phòng thì chuyển slice sang rack khác.
  3. Auto defragmentation: job kết thúc lệch thời điểm để lại node trống rải rác. Cluster có đủ GPU nhưng không có rack nào trống đủ chỗ cho job lớn. Scheduler chọn tập job ít gây xáo trộn nhất để preempt, chỉ với job có checkpoint và resume an toàn, không động vào môi trường dev tương tác.

Số liệu thực nghiệm được dẫn là từ đội GR00T của NVIDIA: pre-train trên 512 GPU GB300 (128 node), đặt rack-aware vào đúng 8 rack giúp mỗi iteration giảm từ 1.59 s xuống 1.39 s, tăng throughput 14.4%.

Trên Kubernetes, ý tưởng có thể diễn đạt bằng label topology và gang scheduling. Ví dụ với Kueue (dự án của SIG Scheduling/Batch):

metadata:
  annotations:
    kueue.x-k8s.io/podset-required-topology: "example.com/nvlink-domain"
spec:
  parallelism: 16
  completions: 16

Tên label chỉ mang tính minh hoạ, bạn cần gán label NVLink domain cho node theo hạ tầng thực tế.

Phản biện từ Hacker News

Bình luận trên HN khá nghi ngờ:

  • Nhiều người cho rằng gang scheduling và rack-aware scheduling chẳng có gì mới, đã có từ thời các scheduler HPC như HTCondor và Slurm, và ai vận hành NVL72 đều biết. Tiêu đề "cần một scheduler mới" bị xem là giật tít.
  • Một người làm scheduler tương tự ở công ty nhận xét bài dành nhiều chỗ giải thích vì sao cần, nhưng không nói gì về phần khó thật sự: thuật toán, cách scale, thời gian một chu kỳ scheduling. Họ coi đây là bài marketing.
  • Có người nhắc Kueue đã hỗ trợ topology-aware scheduling, nên bài nên đề cập prior art.

Những phản biện này hợp lý: bài là blog của vendor, các con số 27% và 14% phụ thuộc vào giả định cụ thể (tỷ lệ hỏng 2%, mô hình của NVIDIA, baseline là scheduler "ngây thơ"). Nhưng với phần lớn dev chưa từng chạm vào cluster cỡ này, bài vẫn là một bản tóm tắt dễ hiểu về vì sao topology quan trọng.

Mang về được gì

  • Khi thuê GPU multi-node trên cloud, hãy hỏi rõ các node có nằm trong cùng NVLink domain hay không. Cùng số GPU nhưng khác placement có thể chênh hiệu năng đáng kể.
  • Giữ TP và EP trong NVLink domain, để DP và PP đi qua mạng chậm hơn.
  • Tính độ tin cậy theo đơn vị "blast radius": khi đơn vị lớn lên (node thành rack), xác suất hỏng của đơn vị tăng theo, và cần chiến lược dự phòng tương ứng.
  • Thiết kế job để checkpoint và resume dễ dàng, vì đó là điều kiện để scheduler có thể preempt, defrag và recover tự động.

Bài viết được AI của DevViet viết lại bằng tiếng Việt từ một bài viết/thảo luận tiếng Anh trên Hacker News, có thể chưa chính xác tuyệt đối. Nguồn: Grace Blackwell needs a new scheduler: 27% more usable GPUs from the same racks