Ngày 29/10, SkyPilot công bố một phân tích kỹ thuật cho rằng tủ rack NVIDIA GB200 NVL72 phá vỡ những giả định mà hầu hết bộ điều phối (scheduler) GPU đang dựa vào. Bài học đáng giá lại khá ngược đời: với loại rack này, cố ý để trống một phần mỗi rack có thể cho nhiều năng lực tính toán dùng được hơn là cố lấp kín mọi chỗ.
Rack giờ mới là "máy chủ"
Nhiều năm qua, đơn vị cơ bản của một cụm GPU là máy chủ 8 GPU nối với nhau bằng NVLink, đường kết nối tốc độ cao riêng của NVIDIA. Mọi thứ vượt ra ngoài chiếc máy đó phải đi qua mạng InfiniBand hoặc RoCE, và các scheduler như Slurm hay Kubernetes kết hợp Kueue coi các node gần như hoán đổi được cho nhau.
NVL72 dời ranh giới đó. Nó gom 72 GPU Blackwell cùng CPU Grace vào một rack, chia thành 18 khay tính toán, mỗi khay 4 GPU, tất cả nối qua một mạng chuyển mạch NVLink duy nhất với tổng băng thông khoảng 130 TB/s. Trong rack, mỗi GPU trao đổi với các GPU khác ở khoảng 1,8 TB/s. Ra khỏi rack, lưu lượng rơi xuống các đường mạng scale-out chỉ tính bằng hàng trăm gigabit mỗi giây.
SkyPilot gọi hiện tượng này là "vực topo" (topology cliff). Tensor parallelism và expert parallelism, các kỹ thuật chia một mô hình lớn cho nhiều GPU cùng tính, nằm trên đường găng của từng bước huấn luyện. Khi một job vốn dành cho một miền NVLink bị rải ra nhiều rack, đường truyền chậm sẽ quyết định tốc độ. Báo cáo đo được mức sụt thông lượng tới 43% trong trường hợp này.
Vị trí đặt job hiện ra trên hoá đơn
Báo cáo cũng dẫn kết quả từ nhóm GR00T của NVIDIA khi huấn luyện GR00T N1.7 trên 512 GPU GB300 trải trên 128 node. Điều phối nhận biết cấu trúc liên kết (topology-aware scheduling) giúp tăng thông lượng 14,4%, rút thời gian mỗi vòng lặp từ 1,59 xuống 1,39 giây. SkyPilot ngoại suy rằng mức cải thiện như vậy trên cụm 10.000 GPU tương đương khoảng 400.000 USD chi phí tính toán mỗi ngày.
Con số tiền nên xem là ước tính, không phải định luật. Nhưng cơ chế thì đơn giản: một scheduler chỉ thấy "còn 64 GPU trống" mà không biết chúng nằm ở rack nào có thể âm thầm biến một job nhanh thành job chậm.
Một node hỏng có thể "giam" 68 GPU
Vấn đề thứ hai khó thấy hơn. Nếu các job lớn yêu cầu trọn một rack, đủ 18 node, thì chỉ cần một node hỏng là 17 node còn lại (68 GPU) trở nên vô dụng với loại job đó. Phần cứng vẫn khoẻ, nhưng không còn đúng "hình dạng" cần thiết.
Ở quy mô lớn, hỏng hóc không hiếm. Theo các giả định độ tin cậy trong báo cáo, một rack 18 node gặp gián đoạn node khoảng 27 ngày một lần. Trên 128 rack, tức 2.304 node, cứ khoảng 5 giờ lại có một rack mất một node. Chính sách cấp phát nguyên rack vì thế liên tục làm rơi rớt năng lực thành những mảnh vụn.
Chừa 2 node mỗi rack, thêm 27% năng lực
Lời giải của SkyPilot là thôi định cỡ job theo nguyên rack. Scheduler chia mỗi rack thành một lát cố định 16 node (64 GPU) và giữ 2 node còn lại (8 GPU) làm dự phòng nóng ngay trong rack. Khi một node hỏng, node dự phòng trong cùng miền NVLink thay thế, nên job giữ nguyên cấu trúc liên kết, không ai phải dừng cả rack hay dời tải sang nơi khác.
Với ví dụ 2.304 node, báo cáo cho biết cách này đạt khoảng 2.037 node dùng được, so với khoảng 1.602 node nếu cấp phát kín 18 node, tức nhiều hơn chừng 27% trên cùng phần cứng. Bỏ không 11% mỗi rack lại thắng, vì nó xoá đi khoản lãng phí lớn hơn nhiều do phân mảnh.
Hai cơ chế hỗ trợ:
- Ràng buộc topo cứng. Các giai đoạn ngốn băng thông như tensor parallelism hay context parallelism bắt buộc nằm trong một miền NVLink; scheduler từ chối mọi cách xếp vượt ranh giới đó.
- Tự động chống phân mảnh. Khi một job lớn bị chặn vì không còn rack nào trống trọn vẹn, hệ thống lưu checkpoint rồi tạm dừng (preempt) các job nhỏ, dễ khởi động lại, chẳng hạn các lượt fine-tune ngắn, và chuyển chúng đi để giải phóng một rack nguyên.
Đánh đổi là có thật. Preemption khiến người chạy job nhỏ mất một phần công việc, lát 64 GPU có thể không hợp với mô hình thiết kế quanh song song 72 chiều, và mức lợi phụ thuộc tỷ lệ hỏng hóc vốn khác nhau giữa các cụm. SkyPilot cũng có lợi ích rõ ràng khi bán phần mềm điều phối. Dù vậy, phép tính đủ minh bạch để bạn tự kiểm tra với cụm của mình.
Doanh nghiệp và kỹ sư Việt nên rút ra gì
Phần lớn công ty Việt Nam sẽ không vận hành 128 rack NVL72. Nhưng ngày càng nhiều đội thuê năng lực GPU từ các nhà cung cấp cloud trong và ngoài nước, và nguyên tắc này vẫn đúng ở quy mô nhỏ hơn.
- Hỏi GPU của bạn nằm ở đâu. Khi thuê 32 hay 64 GPU trên phần cứng đời Blackwell, hãy hỏi chúng có nằm trong cùng một miền NVLink không. "Cùng region" hay "cùng cụm" không phải là cùng một cam kết.
- Ghi topo vào benchmark. Con số thông lượng hay token mỗi giây mà không kèm thông tin GPU cùng rack hay khác rack có thể khiến bạn hiểu sai việc mô hình hay tối ưu nào thực sự tốt lên.
- Định cỡ job theo hình dạng chịu được hỏng hóc. Thiết kế song song quanh 64 GPU thay vì đúng 72 chừa chỗ cho dự phòng và giúp xếp lịch dễ hơn.
- Dành ngân sách cho tầng điều phối, không chỉ cho chip. GPU nhanh hơn không bảo đảm huấn luyện nhanh hơn nếu scheduler vẫn coi các node là hàng hoá đồng nhất.
Điểm lớn hơn: khi phần cứng ngày càng dày đặc, ranh giới trừu tượng dịch chuyển từ máy chủ lên rack, và phần mềm phải theo kịp. Đội nào vẫn đếm GPU như những đơn vị hoán đổi được sẽ trả tiền cho phần cứng mà mình không dùng hết.
Đang tải bình luận…