Một rack máy chủ GPU không chỉ là một tủ chứa đầy bộ tăng tốc. Đây là ranh giới triển khai nơi cấu trúc liên kết GPU, hạ tầng mạng, lưu trữ, quản lý, nguồn điện, làm mát và lập lịch либо phối hợp hoạt động — hoặc tạo ra các điểm nghẽn tốn kém.
Đối với các nhà phát triển AI và kỹ sư hạ tầng ML, câu hỏi hữu ích không phải là “Có bao nhiêu GPU vừa trong một rack?” Mà là: rack này có thể cung cấp khả năng giao tiếp, đường dẫn dữ liệu và khả năng phục hồi mà khối lượng công việc cần không? Hướng dẫn này biến câu hỏi đó thành danh sách kiểm tra kiến trúc và kế hoạch nghiệm thu trên đám mây.
Rack máy chủ GPU là gì?
Rack máy chủ GPU là một rack vật lý hoặc một phân bổ ở quy mô rack do nhà cung cấp quản lý, chứa một hoặc nhiều máy chủ GPU cùng các thành phần mạng, nguồn điện, làm mát và quản lý cần thiết để vận hành chúng. Trong một triển khai đám mây, bạn có thể không kiểm soát bản thân tủ rack, nhưng vẫn nên hỏi những phần nào của cấu trúc liên kết được đảm bảo: số GPU trên mỗi máy chủ, kết nối liên kết nội bộ máy chủ, hạ tầng giữa các máy chủ, đường dẫn lưu trữ, miền bảo trì và chính sách bố trí.
Một máy chủ GPU đơn lẻ là một nút. Một rack máy chủ GPU là hệ thống xoay quanh một số nút. Một cụm GPU có thể trải trên một hoặc nhiều rack. Những khác biệt đó rất quan trọng vì một dịch vụ suy luận có thể bị giới hạn bởi bộ nhớ GPU và đường dẫn PCIe/NVLink của một máy chủ duy nhất, trong khi huấn luyện phân tán hoặc suy luận quy mô lớn có thể bị giới hạn bởi các đường dẫn mạng và lưu trữ giữa các máy chủ.
Kiến trúc tham chiếu BasePOD của NVIDIA minh họa sự khác biệt này: kiến trúc tách riêng mạng tính toán InfiniBand, hạ tầng Ethernet cho quản lý và lưu trữ, cùng mạng quản lý ngoài băng tần. Thiết kế của bạn không nhất thiết phải sao chép kiến trúc tham chiếu đó, nhưng cần làm rõ các đường dẫn tương đương trước khi cam kết năng lực. Kiến trúc tham chiếu NVIDIA DGX BasePOD
Kiến trúc rack máy chủ GPU: sáu yếu tố cần lập sơ đồ
Bắt đầu bằng sơ đồ rack thể hiện vị trí vật lý và các đường dẫn logic. Nếu nhà cung cấp không thể công bố mọi thành phần, hãy ghi lại những gì được đảm bảo và kiểm tra phần còn lại trong thời gian nghiệm thu.
| Lớp | Nội dung cần ghi nhận | Lý do làm thay đổi kết quả |
|---|---|---|
| Nút tính toán | Mẫu GPU, số GPU trên mỗi máy chủ, CPU/RAM, NVMe cục bộ, miền thay thế | Xác định dung lượng bộ nhớ, năng lực tiền xử lý phía máy chủ và phạm vi ảnh hưởng khi một nút gặp sự cố. |
| Cấu trúc liên kết nội bộ nút | Bố cục PCIe, khả năng có NVLink/NVSwitch, mức độ liên kết GPU-với-NIC | Quyết định liệu các GPU trên một máy chủ có thể trao đổi dữ liệu hiệu quả hay không. |
| Hạ tầng liên nút | Loại mạng, số lượng và tốc độ NIC, tầng chuyển mạch, chính sách đăng ký quá mức, bố trí cùng rack | Quyết định hành vi giao tiếp tập thể khi tác vụ rời khỏi một máy chủ. |
| Đường dẫn lưu trữ | Bộ nhớ đệm cục bộ, hệ thống tệp dùng chung hoặc kho đối tượng, đích checkpoint, đường dẫn mạng | Giúp việc nạp dữ liệu và tạo checkpoint không chiếm thời gian của hoạt động tính toán. |
| Quản lý và điều khiển | Truy cập BMC/ngoài băng tần, kiểm kê, bộ lập lịch, chỉ số đo lường, kiểm soát thay đổi | Giúp rack có thể vận hành khi máy chủ hoặc trình điều khiển gặp sự cố. |
| Giới hạn hạ tầng cơ sở | Phân bổ nguồn điện cho rack, dự phòng PDU, thiết kế luồng khí hoặc làm mát bằng chất lỏng, khả năng tiếp cận để bảo trì | Giới hạn mật độ có thể duy trì và việc bảo trì — không chỉ những gì có thể lắp vừa về mặt cơ khí. |
1. Xem cấu trúc liên kết là một đầu vào của khối lượng công việc
Số lượng GPU là mô tả năng lực chưa đầy đủ. Đối với một máy chủ, hãy kiểm tra cách GPU kết nối với nhau và với NIC. Giữa các máy chủ, hãy xác định liệu một tác vụ sẽ ở trong một máy chủ, một rack hay trải qua nhiều rack. Ghi lại quy tắc bố trí dự kiến trong đặc tả khối lượng công việc thay vì giả định rằng “tám GPU” mô tả cùng một loại máy ở mọi nơi.
NCCL sử dụng các đường dẫn ngang hàng trực tiếp khi CUDA báo cáo rằng các GPU liên quan có thể truy cập bộ nhớ của nhau. NVIDIA tài liệu hóa nvidia-smi topo -p2p như một cách để kiểm tra trạng thái ngang hàng; hãy dùng nó làm đầu vào xác thực, không phải thay thế cho benchmark khối lượng công việc. Hướng dẫn khắc phục sự cố GPU NCCL
2. Tách riêng lưu lượng tính toán, dữ liệu và quản lý
Một rack máy chủ GPU cần nhiều hơn một mạng huấn luyện nhanh. Lưu lượng quản lý, tải artifact, telemetry, lưu trữ dùng chung và truy cập người dùng có thể gây nhiễu lưu lượng công việc khi chúng dùng chung một đường dẫn thiếu năng lực. Hãy sử dụng các đường dẫn logic hoặc vật lý riêng biệt khi kiến trúc của bạn yêu cầu, sau đó xác định đường dẫn nào mang từng loại lưu lượng sau:
- giao tiếp tập thể và lưu lượng GPU-direct;
- tải image, trọng số mô hình, tập dữ liệu và checkpoint;
- lưu lượng Kubernetes, SSH, BMC, ghi nhật ký và giám sát;
- lưu lượng đi ra tới API, kho lưu trữ đối tượng hoặc các dịch vụ hạ nguồn.
Điều này đặc biệt quan trọng đối với năng lực đám mây: hãy hỏi liệu các con số băng thông mô tả băng thông giữa các máy chủ, đường lên của rack, thông lượng lưu trữ hay tổng băng thông nỗ lực tối đa. Chúng không thể hoán đổi cho nhau.
3. Thiết kế nguồn điện và làm mát như các ràng buộc năng lực
Đừng định cỡ rack máy chủ GPU chỉ dựa trên đơn vị rack. Một cấu hình vừa vặn về mặt cơ khí có thể bị giới hạn bởi nguồn điện hạ tầng, dự phòng PDU, hướng luồng khí, yêu cầu làm mát bằng chất lỏng, bán kính uốn cáp hoặc khoảng hở phục vụ bảo trì. NVIDIA lưu ý rằng bố cục rack thay đổi theo công suất tối đa tại chỗ và hạ tầng làm mát; hãy sử dụng tài liệu hiện hành của nhà cung cấp máy chủ và nhà cung cấp colocation để biết mức phân bổ thực tế. Câu hỏi thường gặp về NVIDIA DGX SuperPOD
Trước khi triển khai, hãy yêu cầu câu trả lời bằng văn bản cho các câu hỏi sau:
- Mức công suất rack duy trì là bao nhiêu và bao gồm giả định dự phòng nào?
- Thiết kế làm mát là không khí, chất lỏng trực tiếp đến chip, trao đổi nhiệt qua cửa sau, hay kết hợp?
- Thành phần nào kích hoạt điều tiết hiệu năng hoặc sự kiện bảo trì trước: máy chủ, PDU, thiết bị chuyển mạch mạng hay vòng hạ tầng?
- Kỹ thuật viên có thể bảo trì một nút, cáp hoặc thành phần cửa sau mà không làm gián đoạn năng lực của các thành phần liền kề không?
Nếu triển khai chỉ trên đám mây, hãy chuyển các câu hỏi tương tự sang thuật ngữ của nhà cung cấp: vị trí máy chủ chuyên dụng, miền bảo trì, chính sách thay thế máy chủ và liệu phân bổ có thể thay đổi cấu trúc liên kết sau khi cấp phát hay không.
4. Chỉ cung cấp nhận biết rack cho bộ lập lịch khi điều đó hữu ích
Nhãn rack có giá trị khi khối lượng công việc quan tâm đến tính cục bộ hoặc các miền lỗi. Một tác vụ huấn luyện phân tán có thể ưu tiên bố trí trong một rack trước khi mở rộng sang các rack khác. Một dịch vụ suy luận có tính sẵn sàng cao có thể chủ động phân tán các bản sao trên nhiều rack hoặc máy chủ. Hãy bắt đầu với một tập nhãn nhỏ, có thể kiểm tra, chẳng hạn như topology.rack, topology.host-class, topology.fabric và topology.failure-domain, sau đó xác minh rằng vị trí do bộ lập lịch chọn tuân theo chúng.
Với Kubernetes, hãy xác thực toàn bộ ngăn xếp phần mềm GPU theo hệ điều hành, Kubernetes, trình điều khiển, môi trường chạy và tùy chọn triển khai được hỗ trợ — không chỉ phiên bản cụm. Ma trận hỗ trợ GPU Operator của NVIDIA phân biệt giữa bare metal, VM GPU-passthrough và triển khai vGPU, đồng thời công bố chi tiết khả năng tương thích cho các môi trường được hỗ trợ. Hỗ trợ nền tảng NVIDIA GPU Operator
Cách chọn rack máy chủ GPU cho khối lượng công việc của bạn
Sử dụng bản mô tả khối lượng công việc để quyết định liệu bạn cần một máy chủ đơn mật độ cao, một rack hay một cụm nhiều rack.
| Mẫu khối lượng công việc | Thường ưu tiên | Hỏi nhà cung cấp hoặc nhóm nền tảng |
|---|---|---|
| Tinh chỉnh hoặc suy luận trên một nút | Bộ nhớ GPU, cấu trúc liên kết nội bộ nút, lưu trữ cục bộ, thay thế máy chủ đáng tin cậy | Những GPU và kết nối liên thông nào được gắn với một máy chủ? Có thể cấp phát đồng thời tất cả GPU cần thiết không? |
| Huấn luyện phân tán | Bố trí cùng rack, fabric mạng, affinity NIC, thông lượng checkpoint | Những gì được đảm bảo cho kết nối mạng giữa các máy chủ? Việc bố trí giữa các rack được hiển thị hoặc tránh như thế nào? |
| Suy luận đa nút | Độ trễ đuôi, giao tiếp giữa các phân mảnh mô hình, an toàn khi triển khai, khả năng quan sát | Có thể phân tán các bản sao theo miền lỗi trong khi các rank song song mô hình vẫn nhận biết cấu trúc liên kết không? |
| Khối lượng công việc theo lô hoặc kết xuất | Hành vi hàng đợi, bộ nhớ đệm cục bộ, xử lý gián đoạn, chuẩn bị image/dữ liệu | Cam kết về vị trí là gì và các tác vụ bị gián đoạn được khôi phục như thế nào? |
| Nền tảng nội bộ dùng chung | Cô lập, hạn ngạch, chính sách bộ lập lịch, khả năng hiển thị năng lực, kiểm soát thay đổi | Các phân vùng GPU, ranh giới tenant, trình điều khiển và nâng cấp được quản trị như thế nào? |
Đối với một triển khai mới, hãy so sánh quyết định về rack với một phương án đơn giản hơn. Nếu công việc không yêu cầu kiểm soát cấu trúc liên kết, tính cục bộ của dữ liệu hoặc một ngăn xếp phục vụ tùy chỉnh, API mô hình được quản lý có thể có gánh nặng vận hành thấp hơn. Hãy sử dụng phần so sánh GPU cloud và model API này như một phần của quyết định, thay vì coi rack máy chủ GPU là câu trả lời mặc định.
Cách đánh giá hiệu năng rack máy chủ GPU
Đừng chấp nhận một rack máy chủ GPU chỉ dựa trên một con số hiệu năng cực đại của bộ tăng tốc. Hãy xây dựng một bài kiểm thử nghiệm thu ngắn để tách biệt các đường hiệu năng chính.
Bước 1: Thu thập đường cơ sở về kiểm kê và cấu trúc liên kết
Đối với mỗi máy chủ được cấp phát, hãy thu thập danh tính GPU, phiên bản trình điều khiển và CUDA, cấu trúc liên kết GPU-với-GPU, affinity GPU-với-NIC, bố cục NUMA CPU, lưu trữ cục bộ và giao diện mạng. Lưu bản ghi này cùng với bản sửa đổi triển khai. Nó cung cấp cho bạn một điểm so sánh khi hiệu năng thay đổi sau khi thay image, firmware, trình điều khiển hoặc máy chủ.
nvidia-smi -L
nvidia-smi topo -m
nvidia-smi topo -p2p p
nvidia-smi topo -p2p n
Không thay đổi các thiết lập kernel, BIOS, IOMMU hoặc kiểm soát truy cập PCIe theo một danh sách kiểm tra chung chung. NVIDIA ghi nhận hành vi ngang hàng nhạy cảm với cấu hình trên các hệ thống bare metal Linux; hãy sử dụng các thiết lập được hỗ trợ cho máy chủ và nền tảng đám mây mà bạn thực sự vận hành. Khắc phục sự cố cấu trúc liên kết và ngang hàng NCCL
Bước 2: Kiểm thử tại các ranh giới quan trọng
Chạy các bài kiểm thử đại diện ở ba phạm vi:
- Một nút để xác thực khả năng hiển thị GPU và đường NVLink/NVSwitch hoặc PCIe cục bộ.
- Cùng rack để xác thực vị trí giữa các máy chủ và fabric cục bộ.
- Khác rack để hiểu đường truyền mà bộ lập lịch của bạn sẽ sử dụng khi năng lực mở rộng hoặc chuyển đổi dự phòng.
Hướng dẫn kiểm thử NCCL của NVIDIA nêu rõ việc chạy trên một nút, một rack và nhiều rack để xác thực khả năng hiển thị GPU, kết nối liên thông trong nút, fabric giữa các nút và vị trí. Hãy ghi lại độ trễ và băng thông cùng với lệnh kiểm thử, digest image container, danh sách nút và nhãn vị trí để có thể tái tạo kết quả. Hướng dẫn xác thực NCCL
Bước 3: Đo lường đường chạy của ứng dụng thực tế
Sau đó, chạy khối lượng công việc mà bạn dự định phục vụ. Đối với huấn luyện, hãy báo cáo thời gian mỗi bước, thời gian chờ dữ liệu, thời gian giao tiếp tập thể, thời gian checkpoint và hành vi khôi phục. Đối với suy luận, hãy báo cáo thời gian đến token đầu tiên, thông lượng đầu ra, độ trễ đuôi, độ trễ hàng đợi, hành vi bộ nhớ đệm, cùng tỷ lệ lỗi hoặc khởi động lại. Giữ nguyên cùng mô hình, cấu hình batch/đồng thời, độ dài ngữ cảnh và trạng thái bộ nhớ đệm khi so sánh các phương án bố trí.
Đây là cách bạn phân biệt vấn đề GPU với vấn đề dữ liệu, mạng, bộ lập lịch hoặc cấu hình.
Bước 4: Kiểm thử một sự cố được lên kế hoạch
Một rack máy chủ GPU vận hành được cần có đường khôi phục. Trước khi có lưu lượng sản xuất, hãy xác minh điều gì xảy ra khi một worker được rút khỏi phục vụ, một nút không khả dụng, một tác vụ bị preempt hoặc một checkpoint cần được tiếp tục ở nơi khác. Xác nhận rằng dữ liệu bền vững được tách biệt khỏi tài nguyên tính toán có thể thay thế, đồng thời thông tin xác thực, image và khả năng quan sát vẫn hoạt động trên đường thay thế.
Triển khai rack máy chủ GPU trên đám mây: trình tự thực tế
Triển khai đám mây thay đổi ranh giới kiểm soát, không phải công việc kỹ thuật. Bạn vẫn cần làm rõ các giả định về phần cứng và vị trí bố trí.
- Viết hợp đồng khối lượng công việc. Nêu rõ kích thước mô hình, số lượng GPU, yêu cầu bộ nhớ, SLO về độ trễ hoặc thông lượng, độ nhạy mạng, nguồn dữ liệu, vị trí checkpoint, mục tiêu tính sẵn sàng và giới hạn ngân sách.
- Chọn ranh giới topology. Quyết định liệu tác vụ phải nằm trong một máy chủ, một rack hay một fabric nhiều rack xác định. Hãy coi đây là yêu cầu trong đề nghị gửi nhà cung cấp, không phải là một ưu tiên không chính thức.
- Yêu cầu bảng phân bổ. Yêu cầu lớp máy chủ, số lượng GPU, kết nối liên thông GPU, NIC, network fabric, các tùy chọn lưu trữ, bảo đảm vị trí, chính sách bảo trì và mọi siêu dữ liệu topology được cung cấp cho bộ lập lịch của bạn.
- Chốt hợp đồng phần mềm. Ghi lại hệ điều hành, kernel, trình điều khiển NVIDIA, CUDA, container runtime, phiên bản Kubernetes, phiên bản GPU Operator, framework image và application image digest. Xác thực tổ hợp này với ma trận được hỗ trợ trước khi triển khai.
- Tạo một cửa sổ nghiệm thu hẹp. Chạy các kiểm thử về kiểm kê, topology, giao tiếp cùng nút/cùng rack/khác rack, lưu trữ, ứng dụng và khôi phục trước khi chuyển lưu lượng duy trì liên tục.
- Trang bị đo lường cho từng lớp. Cảnh báo riêng biệt về tình trạng GPU, lỗi fabric, thời gian chờ lưu trữ, thời gian chờ bộ lập lịch, các sự kiện nhiệt hoặc điều tiết hiệu năng và SLO của ứng dụng. Một chỉ số sử dụng duy nhất không thể giải thích một sự cố ở quy mô rack.
- Duy trì các lựa chọn thoát và khôi phục. Duy trì các định nghĩa image, cấu hình hạ tầng, vị trí dữ liệu bền vững, checkpoint và kế hoạch quay lui độc lập với một phân bổ cụ thể.
Đối với các phần ở cấp máy chủ trong trình tự này, hãy xem hướng dẫn triển khai máy chủ GPU. Để có góc nhìn về control plane và fabric đa nút, hãy xem hướng dẫn kiến trúc cụm GPU.
Danh sách kiểm tra nghiệm thu rack máy chủ GPU
Sử dụng danh sách kiểm tra này trước khi bạn nghiệm thu một rack máy chủ GPU mới, phân bổ đám mây chuyên dụng hoặc bản triển khai colocation.
- [ ] Hợp đồng khối lượng công việc nêu rõ ranh giới topology: một máy chủ, cùng rack hoặc nhiều rack.
- [ ] Bảng phân bổ xác định số lượng GPU trên mỗi máy chủ, kết nối liên thông tăng tốc, NIC, network fabric và đường lưu trữ.
- [ ] Nguồn điện, làm mát, dự phòng PDU, yêu cầu về luồng không khí hoặc làm mát bằng chất lỏng và khoảng trống bảo trì đều có người phụ trách.
- [ ] Các phiên bản GPU, trình điều khiển, CUDA, kernel, container runtime và điều phối được ghi lại.
- [ ] Bộ lập lịch hiển thị và tuân thủ các nhãn vị trí hoặc miền lỗi tại nơi khối lượng công việc cần chúng.
- [ ] Đầu ra kiểm kê và topology của
nvidia-smiđược lưu trữ cho mọi lớp máy chủ. - [ ] Các kiểm thử giao tiếp bao gồm các phương án bố trí một nút, cùng rack và khác rack mà bộ lập lịch sản xuất có thể tạo ra.
- [ ] Kiểm thử ứng dụng sử dụng nguồn dữ liệu và cấu hình khối lượng công việc mang tính đại diện.
- [ ] Các đường checkpoint, rút máy chủ khỏi phục vụ, thay thế và quay lui được thực hành.
- [ ] Báo cáo chi phí tách riêng thời gian GPU hữu ích khỏi chi phí nhàn rỗi, thử lại, dữ liệu và hỗ trợ mà không tính cùng một khoảng thời gian hai lần. Để biết mô hình chi phí rộng hơn, hãy bắt đầu với hướng dẫn thuê GPU này.
Câu hỏi thường gặp
Rack máy chủ GPU có giống cụm GPU không?
Không. Rack máy chủ GPU mô tả một ranh giới triển khai vật lý hoặc được nhà cung cấp quản lý ở quy mô rack. Cụm GPU là một nhóm nút logic có thể trải trên một phần của rack, toàn bộ một rack hoặc nhiều rack. Sự khác biệt này quan trọng khi mạng, lưu trữ, miền lỗi và lập lịch vượt qua các ranh giới vật lý.
Có bao nhiêu máy chủ GPU trong một rack máy chủ GPU?
Không có một con số phổ quát hữu ích. Độ sâu máy chủ và đơn vị rack chỉ là ràng buộc đầu tiên. Câu trả lời thực tế phụ thuộc vào mức tiêu thụ điện của máy chủ, thiết kế làm mát, công suất và khả năng dự phòng PDU, định tuyến cáp, khả năng tiếp cận để bảo trì và mật độ được cơ sở phê duyệt. Hãy xác thực câu trả lời dựa trên thiết kế chính xác của máy chủ, rack và trung tâm dữ liệu mà bạn sẽ sử dụng.
Mọi rack máy chủ GPU có cần InfiniBand không?
Không. Fabric phù hợp phụ thuộc vào khối lượng công việc và topology. Khối lượng công việc trên một máy chủ có thể hoàn toàn không cần fabric hiệu năng cao liên nút. Khối lượng công việc phân tán nên được kiểm thử trên đường mạng mà chúng thực sự sẽ sử dụng, bao gồm bố trí cùng rack và khác rack. Tránh chọn fabric chỉ dựa trên một thông số kỹ thuật tiếp thị.
Tôi nên kiểm thử gì trước khi nghiệm thu năng lực rack GPU trên đám mây?
Kiểm thử phần dung lượng được cấp cho bạn: kiểm kê phần cứng, cấu trúc liên kết, mức độ liên kết GPU-với-NIC, hành vi của bộ nhớ lưu trữ cục bộ và dùng chung, giao tiếp trong một nút, giao tiếp trong cùng rack, giao tiếp giữa các rack nếu điều đó có thể thực hiện trong môi trường sản xuất, hành vi ứng dụng đại diện và khả năng khôi phục sau một sự cố đã được lên kế hoạch.
Khi nào tôi nên tránh vận hành một rack máy chủ GPU?
Tránh vận hành ở quy mô rack khi khối lượng công việc của bạn không cần mức độ kiểm soát mà chúng cung cấp. Nếu một API mô hình được quản lý có thể đáp ứng các yêu cầu về mô hình, độ trễ, tính sẵn sàng, quyền riêng tư và chi phí, nó có thể loại bỏ công việc liên quan đến phần cứng, fabric, trình điều khiển, bộ lập lịch và quản lý dung lượng. Hãy chủ động thực hiện so sánh đó trước khi cam kết sử dụng một rack máy chủ GPU.
Xây dựng rack xoay quanh khối lượng công việc
Một rack máy chủ GPU thành công khi thiết kế vật lý và phần dung lượng đám mây được cấp phát phù hợp với các luồng giao tiếp, dữ liệu và khôi phục của khối lượng công việc. Hãy làm rõ cấu trúc liên kết, tách riêng các lớp lưu lượng có thể gây nhiễu lẫn nhau, xác thực hiệu năng ở phạm vi một nút, cùng rack và giữa các rack, đồng thời chỉ chấp nhận dung lượng sau khi đã kiểm thử ứng dụng thực tế và một đường dẫn sự cố.
Nếu không cần kiểm soát ở cấp rack, hãy so sánh phương án API mô hình trước khi gánh vác trách nhiệm vận hành. Nếu cần, hãy sử dụng hướng dẫn này cùng với hướng dẫn máy chủ GPU, hướng dẫn kiến trúc cụm GPU và danh sách kiểm tra chi phí đám mây GPU để biến dung lượng thành một hoạt động triển khai có thể xác minh.
