NCA-AIIO 9: Vận hành cụm AI, điện, làm mát, sizing và giám sát
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 9/9 trong loạt NCA-AIIO: đọc sau Phần 8. Phần khép lại loạt bài, phủ domain AI Operations của đề thi.
Cập nhật: 2026-10-23
Mục lục
- 1. Phần hay bị bỏ qua lại chiếm 22% đề thi
- 2. Từ TDP tới ngân sách điện của một rack
- 3. PUE và hiệu quả của cả cơ sở
- 4. Ba cách làm mát và ngưỡng chuyển đổi
- 5. Vòng làm mát chất lỏng hoạt động ra sao?
- 6. Sizing: bao nhiêu GPU cho một model?
- 7. Training và inference đòi hỏi khác nhau thế nào?
- 8. On-prem hay cloud?
- 9. Giám sát bằng DCGM
- 10. XID error và health check
- 11. Điều phối job: Slurm và Kubernetes
- 12. Danh sách kiểm tra trước khi chốt thiết kế
- Nguồn tham khảo
1. Phần hay bị bỏ qua lại chiếm 22% đề thi
Blueprint chính thức của NCA-AIIO dành 22% cho domain AI Operations và 40% cho domain AI Infrastructure (bảng trọng số đầy đủ của cả ba domain nằm ở phần tổng quan của loạt bài), nên phần điện, làm mát, facility, giám sát và điều phối cộng lại là tỉ trọng lớn nhất của đề. Người ôn thi thường dồn thời gian vào thông số GPU và bỏ trống đúng khoảng này.
Ba câu hỏi phần này trả lời:
- Từ một con số TDP, tính ra được bao nhiêu rack và bao nhiêu kW cần chuẩn bị.
- Một model cỡ nhất định cần bao nhiêu GPU, và vì sao training với inference ra hai đáp số khác hẳn nhau.
- Khi cụm đã chạy, theo dõi những chỉ số nào để biết nó khoẻ hay ốm.
2. Từ TDP tới ngân sách điện của một rack
TDP (Thermal Design Power) là lượng nhiệt tối đa một linh kiện sinh ra, tính bằng watt, và cũng là lượng nhiệt hệ làm mát phải tản đi. Với GPU data center, con số này cũng xấp xỉ mức điện tiêu thụ ở tải cao.
Bảng TDP qua các đời để nhìn thấy xu hướng:
| GPU | TDP |
|---|---|
| H100 NVL | 350 tới 400 W |
| H100 SXM | tới 700 W |
| H200 SXM | tới 700 W |
| H200 NVL | tới 600 W |
| B200 | tới 1.000 W |
| B300 | khoảng 1.400 W |
Trong mười năm, TDP mỗi GPU tăng khoảng năm lần, và đó là lý do cách thiết kế data center phải thay đổi theo.
Quy trình tính ngân sách điện. Lấy ví dụ 64 GPU H100 SXM, mỗi rack chịu được 15 kW:
Bước 1, điện cho riêng GPU:
64 × 700 W = 44.800 W = 44,8 kW
Bước 2, cộng phần còn lại của hệ thống (CPU, RAM, NIC, quạt, hao phí nguồn).
Thực tế GPU chiếm khoảng 70% tổng điện của một node GPU:
44,8 kW ÷ 0,7 = 64 kW
Bước 3, chia cho trần mỗi rack:
64 kW ÷ 15 kW = 4,27 → cần 5 rack
Nếu chỉ tính riêng GPU như cách làm nhanh trong đề thi:
44,8 ÷ 15 = 2,99 → tối thiểu 3 rack
Hai đáp số khác nhau vì trả lời hai câu hỏi khác nhau. Đề thi thường hỏi mức tối thiểu về lý thuyết và chỉ tính phần GPU, nên đáp án là 3. Một thiết kế triển khai thật phải tính điện của cả node, tức lấy phần GPU chia cho 0,7, nên ra 5. Khi gặp câu hỏi dạng này, đọc kỹ xem đề hỏi "tối thiểu cần bao nhiêu rack" hay "nên bố trí bao nhiêu rack".
Tính ngược từ trần điện. Ngoài đời bài toán hay đi theo chiều ngược lại: phòng máy chỉ có 100 kW, vậy lắp được bao nhiêu GPU H100?
100 kW × 0,7 (phần dành cho GPU) = 70 kW
70.000 W ÷ 700 W = 100 GPU
Làm tròn xuống theo bội số của 8 GPU mỗi node: 96 GPU, tức 12 node
💡 Hình dung như thế này: ngân sách điện của một phòng máy giống trọng tải của một chiếc thang máy. Con số dán trên tường không phải để tham khảo mà là trần cứng, và khi tính xem chở được bao nhiêu người thì phải trừ luôn cân nặng của chính cabin, chứ không chỉ cộng cân nặng hành khách. Rất nhiều dự án vỡ kế hoạch vì tính đủ phần GPU mà quên phần còn lại của chiếc máy.
3. PUE và hiệu quả của cả cơ sở
PUE (Power Usage Effectiveness) đo tỉ lệ giữa tổng điện mà cả cơ sở tiêu thụ và phần điện thực sự tới thiết bị tính toán:
PUE = Tổng điện năng toàn cơ sở ÷ Điện năng của thiết bị IT
PUE bằng 1,0 nghĩa là mọi watt đi vào đều phục vụ tính toán, mức lý tưởng không đạt được trong thực tế. Data center hiện đại đạt khoảng 1,2 hoặc thấp hơn. Trung bình ngành nằm trong khoảng 1,58 tới 1,8.
Phần dư chủ yếu đi vào làm mát, cộng thêm tổn hao ở UPS và hệ thống phân phối điện.
Ứng dụng khi lập kế hoạch: một cụm GPU cần 500 kW cho thiết bị IT, đặt trong cơ sở có PUE 1,5, sẽ kéo từ lưới 750 kW. Nếu chuyển sang cơ sở có PUE 1,15 thì con số là 575 kW, chênh lệch 175 kW công suất liên tục, tức khoảng 1,53 triệu kWh mỗi năm, kéo dài suốt vòng đời hệ thống. Đây là lý do làm mát bằng chất lỏng hấp dẫn về mặt chi phí vận hành chứ không chỉ về mặt kỹ thuật: nó cắt phần lớn điện dành cho quạt và máy lạnh.
4. Ba cách làm mát và ngưỡng chuyển đổi
| Cách | Ngưỡng mật độ phù hợp | Cơ chế |
|---|---|---|
| Làm mát bằng khí | Tới khoảng 20 tới 30 kW mỗi rack | Quạt thổi khí lạnh qua tản nhiệt, nóng lên rồi thoát ra hành lang nóng |
| Direct-to-chip liquid cooling | Khoảng 30 tới 150 kW mỗi rack | Chất lỏng chạy qua cold plate áp sát mặt chip, lấy nhiệt ngay tại nguồn |
| Immersion cooling | Mật độ rất cao | Nhúng cả bo mạch vào chất lỏng không dẫn điện |
Ngưỡng chuyển đổi quan trọng nằm ở khoảng 30 kW mỗi rack. Dưới mức đó, làm mát bằng khí vẫn kinh tế. Trên mức đó, lượng khí cần thổi qua trở nên quá lớn: quạt ăn điện nhiều hơn, tiếng ồn vượt ngưỡng cho phép, và chênh lệch nhiệt độ giữa đầu vào với đầu ra không còn đủ để mang nhiệt đi.
Với GPU TDP từ 700 W trở lên lắp dày trong rack, direct liquid cooling gần như là lựa chọn duy nhất. Khi đề thi hỏi phương án làm mát cho GPU TDP cao, đáp án là direct liquid cooling hoặc closed-loop liquid cooling.
Ba nhận định sai hay được cài vào đáp án nhiễu:
- Liquid cooling hạ nhiệt độ nhưng không giảm điện mà GPU tiêu thụ. Chip vẫn ăn đúng ngần ấy watt.
- Bộ nguồn hiệu suất cao giảm hao phí chuyển đổi, cũng không làm GPU bớt tiêu thụ.
- Liquid cooling tự nó không tăng năng lực tính toán mỗi rack; nó gỡ nút thắt nhiệt, nhờ đó mới nhồi được nhiều GPU hơn vào cùng thể tích.
5. Vòng làm mát chất lỏng hoạt động ra sao?
Hệ thống direct-to-chip gồm hai vòng tách biệt, nối với nhau qua một bộ trao đổi nhiệt.
Vòng sơ cấp là nước của toà nhà, chạy từ chiller hoặc tháp giải nhiệt tới phòng máy. Nước này không bao giờ vào thẳng trong rack.
Vòng thứ cấp là chất lỏng chạy trong rack, đi qua các cold plate áp trên GPU và CPU. Chất lỏng ở vòng này được kiểm soát chặt về thành phần và độ sạch, vì các vi kênh trong cold plate rất nhỏ và dễ tắc.
CDU (Coolant Distribution Unit) là thiết bị nối hai vòng. Nó chứa bộ trao đổi nhiệt, bơm, cảm biến và van điều tiết, giữ nhiệt độ cùng lưu lượng của vòng thứ cấp ở mức đặt trước. CDU có thể lắp trong rack hoặc đặt ở đầu dãy phục vụ nhiều rack.
Đường đi của nhiệt: chip sinh nhiệt, truyền qua cold plate vào chất lỏng, chất lỏng nóng chảy về CDU, nhả nhiệt sang vòng nước toà nhà qua bộ trao đổi, rồi quay lại rack. Nước toà nhà mang nhiệt ra chiller hoặc tháp giải nhiệt để thải ra môi trường.
Con số thực tế cho một rack rack-scale thế hệ Blackwell: tải khoảng 120 tới 140 kW, CDU lắp trong rack thường chọn ở 200 tới 250 kW để có biên an toàn. Nước phía toà nhà phải đạt chuẩn chất lượng theo hướng dẫn của ASHRAE.
Hai ràng buộc hạ tầng hay bị phát hiện muộn: nguồn vào thường là 480 V, và một tủ rack-scale nặng khoảng 1,36 tấn nên sàn phải chịu được tải điểm đó.
6. Sizing: bao nhiêu GPU cho một model?
Bài toán nền tảng nhất của việc lập kế hoạch, và là dạng câu hỏi hay gặp.
Bước 1, tính bộ nhớ cho trọng số. Nhân số tham số với số byte mỗi tham số:
| Độ chính xác | Byte mỗi tham số |
|---|---|
| FP32 | 4 |
| FP16 hoặc BF16 | 2 |
| FP8 | 1 |
| FP4 | 0,5 |
Bước 2, nhân hệ số theo loại công việc.
| Công việc | Hệ số so với kích thước trọng số | Vì sao |
|---|---|---|
| Inference | 1 lần, cộng thêm chỗ cho KV cache | Chỉ cần chứa trọng số và trạng thái của các request đang chạy |
| Fine-tuning kiểu LoRA | Khoảng 1,5 lần | Chỉ cập nhật một phần nhỏ tham số |
| Training đầy đủ | 2 tới 4 lần | Phải giữ thêm gradient và trạng thái optimizer |
| Training đầy đủ ở FP16 với optimizer nặng | Có thể tới 12 tới 16 lần | Trạng thái optimizer kiểu Adam chiếm gấp nhiều lần trọng số |
Bước 3, chia cho dung lượng một GPU rồi làm tròn lên bội số của 8.
Ví dụ hoàn chỉnh: inference model 70 tỉ tham số ở FP16 trên H100 SXM.
Trọng số: 70 × 10⁹ × 2 byte = 140 GB
Dự phòng KV cache và hoạt động, cộng khoảng 20%: 168 GB
Chia cho 80 GB mỗi H100 SXM: 168 ÷ 80 = 2,1 → cần 3 GPU
Cùng model đó trên H200 141 GB thì hai GPU là đủ thoải mái, và một GPU vừa khít phần trọng số nhưng không còn chỗ cho KV cache.
Ví dụ thứ hai: training đầy đủ cùng model đó ở FP16.
Trọng số: 140 GB
Hệ số training 4 lần: 560 GB
Chia cho 80 GB: 7 GPU, làm tròn lên một node 8 GPU
Một node 8 GPU H100 có 640 GB tổng, vừa đủ trên lý thuyết. Nhưng nếu dùng optimizer Adam với trạng thái đầy đủ, hệ số có thể lên 12 tới 16 lần, tức 1.680 tới 2.240 GB, và khi đó cần ba tới bốn node. Lỗi out of memory hay gặp sinh ra từ đúng bối cảnh này: phép tính thô cho thấy dư bộ nhớ, thực tế lại tràn.
Quy tắc 2 tới 4 lần chỉ là ước lượng. Con số thật phụ thuộc vào độ chính xác, loại optimizer và các kỹ thuật tiết kiệm bộ nhớ đang dùng.
7. Training và inference đòi hỏi khác nhau thế nào?
Hai loại công việc này tạo ra hai bài toán hạ tầng khác hẳn nhau, và phân biệt được chúng là nội dung nằm thẳng trong blueprint đề thi.
| Training | Inference | |
|---|---|---|
| Bộ nhớ | 2 tới 4 lần kích thước model, có khi hơn | Khoảng 1 lần, cộng KV cache |
| Mạng giữa các node | Rất quan trọng, all-reduce sau mỗi bước | Ít quan trọng hơn, mỗi request độc lập |
| Nút thắt thường gặp | Băng thông mạng và dung lượng bộ nhớ | Băng thông bộ nhớ của chính GPU |
| Hình dạng tải | Ổn định, chạy liên tục nhiều ngày | Dao động theo lượng người dùng |
| Độ chính xác | FP16, BF16, FP8 | FP8, FP4, INT8 |
| Nhạy với lỗi | Rất nhạy, một node hỏng là cả job dừng | Ít nhạy, mất một node thì giảm công suất |
| Lưu trữ | Cần thông lượng lớn để nạp dữ liệu và ghi checkpoint | Chủ yếu đọc trọng số lúc khởi động |
Hệ quả trong thiết kế: cụm training cần fabric InfiniBand hoặc Spectrum-X đắt tiền với tỉ lệ 1 NIC cho 1 GPU, vì mọi GPU phải đồng bộ với nhau liên tục. Cụm inference có thể dùng mạng đơn giản hơn nhiều, nhưng lại cần GPU có bộ nhớ lớn và băng thông bộ nhớ cao. Đó là lý do H200 hấp dẫn cho inference dù sức tính không hơn H100, còn B300 hấp dẫn vì tăng cả bộ nhớ lẫn sức tính FP4.
8. On-prem hay cloud?
| Tiêu chí | On-prem | Cloud |
|---|---|---|
| Chi phí ban đầu | Rất lớn, mua đứt | Gần như không |
| Chi phí dài hạn | Thấp hơn nếu dùng đều | Cao hơn nếu chạy liên tục |
| Thời gian có hàng | Vài tháng, phụ thuộc nguồn cung | Ngay lập tức, nếu còn capacity |
| Co giãn | Cố định theo số máy đã mua | Thuê thêm hoặc trả lại theo nhu cầu |
| Chủ quyền dữ liệu | Dữ liệu không rời khỏi cơ sở | Phụ thuộc vùng và chính sách nhà cung cấp |
| Vận hành | Tự lo điện, làm mát, nhân sự | Nhà cung cấp lo |
Ngưỡng quyết định thường nằm ở tỉ lệ sử dụng. Một cụm chạy trên 60 tới 70% thời gian thường rẻ hơn khi mua đứt trong vòng hai tới ba năm. Tải thất thường, hoặc giai đoạn thử nghiệm chưa rõ nhu cầu, thì thuê cloud hợp lý hơn.
Mô hình lai khá phổ biến: giữ on-prem phần tải nền chạy liên tục, thuê cloud cho các đợt cao điểm và cho các thử nghiệm ngắn.
9. Giám sát bằng DCGM
DCGM (Data Center GPU Manager) là daemon giám sát GPU của NVIDIA. Từ viết tắt này có thể xuất hiện thẳng trong đề, nên cần nhớ đúng tên đầy đủ.
DCGM cung cấp giám sát sức khoẻ chủ động, chẩn đoán, cảnh báo và chính sách quản trị. Nó tích hợp vào hệ sinh thái Kubernetes qua các binding C, Python và Go, và thường chạy kèm DCGM Exporter để đẩy số liệu sang Prometheus rồi hiển thị trên Grafana.
Các nhóm chỉ số cần theo dõi:
| Nhóm | Chỉ số | Ý nghĩa |
|---|---|---|
| Sử dụng | GPU utilization | Tỉ lệ thời gian GPU có việc. Thấp kéo dài nghĩa là pipeline nạp dữ liệu đang nghẽn |
| Sử dụng sâu | Tỉ lệ chu kỳ SM có ít nhất một warp, tỉ lệ chu kỳ tensor pipe hoạt động | Phân biệt "GPU bận" với "GPU làm việc có ích" |
| Bộ nhớ | Dung lượng đã dùng, memory copy utilization | Dự báo nguy cơ hết bộ nhớ |
| Nhiệt | Nhiệt độ, thời gian bị giới hạn vì nhiệt | Tích luỹ theo microgiây, tăng nhanh nghĩa là làm mát không đủ |
| Điện | Công suất tiêu thụ, thời gian bị giới hạn vì điện | Phục vụ cả kiểm tra thiết kế lẫn tối ưu chi phí |
| Lỗi | XID error, ECC, retired page, row remap, PCIe replay | Dấu hiệu phần cứng đang hỏng dần |
Chỉ số đáng chú ý nhất với người mới vận hành là cặp GPU utilization và tỉ lệ chu kỳ tensor pipe hoạt động. Một GPU có thể báo utilization 100% trong khi tensor core gần như rảnh, nghĩa là công việc đang vướng ở chỗ khác chứ không phải ở sức tính. Chỉ nhìn một con số utilization dễ dẫn tới kết luận sai rằng cụm đã chạy hết công suất.
10. XID error và health check
XID error là mã lỗi do driver NVIDIA phát ra khi GPU gặp sự cố. Mỗi mã ứng với một loại vấn đề: lỗi bộ nhớ, lỗi phần cứng, ứng dụng truy cập sai vùng nhớ, hoặc GPU không phản hồi.
DCGM ánh xạ các mã XID sang mã tình trạng sức khoẻ, và phân loại theo mức nghiêm trọng. Một nhóm XID được xếp vào loại lỗi phần cứng nghiêm trọng, gặp là phải đưa node ra khỏi hàng đợi. Cách ánh xạ phụ thuộc kiến trúc: DCGM chỉ cảnh báo hỏng InfoROM cho XID 93 trên GPU Volta, còn các kiến trúc khác thì bỏ qua mã này.
DCGM có ba mức kiểm tra:
- Background check chạy nền liên tục, không ảnh hưởng hiệu năng ứng dụng, phát hiện GPU không phản hồi, firmware hỏng, hoặc nhiệt vượt ngưỡng.
- Prologue và epilogue check chạy trước và sau mỗi job, bắt lỗi trước khi job bắt đầu và xác nhận tình trạng sau khi job kết thúc.
- Diagnostics plugin là bài kiểm tra sâu và chiếm dụng GPU, theo dõi toàn bộ XID, vi phạm nhiệt độ và lỗi bộ nhớ không sửa được trong lúc chạy.
Phân biệt quan trọng khi đọc cảnh báo: throttling vì nhiệt là chỉ báo tải chứ chưa chắc là lỗi. GPU tự hạ xung khi nóng là cơ chế bảo vệ hoạt động đúng. Lỗi thật về điện và làm mát đến dưới dạng vi phạm hardware slowdown riêng biệt. Đặt cảnh báo nhầm chỗ sẽ sinh ra hàng loạt báo động giả, và đội vận hành nhanh chóng học cách phớt lờ chúng.
Các phân loại lỗi do DCGM trả về (ngưỡng hiệu năng, lỗi phần mềm XID, lỗi nhiệt phần cứng) là nền để dựng quy trình tự động: thấy loại nào thì rút node ra sửa, thấy loại nào thì chỉ ghi nhận.
Lưu ý về phiên bản: từ DCGM 4.6, phần giám sát lỗi chung dùng nhiệt độ hoạt động tối đa do chính GPU báo thay vì tham số temperature_max, nên không đặt được ngưỡng thấp hơn theo ý muốn của từng cơ sở qua tham số đó.
11. Điều phối job: Slurm và Kubernetes
Hai hệ điều phối cùng tồn tại trong thế giới cụm GPU, phục vụ hai kiểu công việc khác nhau.
Slurm xuất thân từ high performance computing. Mô hình của nó là hàng đợi xử lý theo lô: người dùng khai báo cần bao nhiêu node, bao nhiêu GPU, chạy trong bao lâu, rồi nộp job vào hàng chờ tới lượt. Slurm hợp với training dài ngày cần một khối tài nguyên cố định trong nhiều giờ hoặc nhiều ngày.
Kubernetes xuất thân từ thế giới dịch vụ. Mô hình của nó là duy trì trạng thái mong muốn: khai báo cần bao nhiêu bản sao của một dịch vụ, hệ thống tự giữ đúng số đó, tự khởi động lại cái chết. Kubernetes hợp với inference, nơi tải lên xuống theo người dùng và cần co giãn tự động.
💡 Hình dung như thế này: Kubernetes giống việc quản lý số nhân viên phục vụ đứng ca trong một nhà hàng. Ca nào cũng quy định phải có đủ năm người trên sàn: ai nghỉ giữa ca thì quản lý gọi người thay, khách đông lên thì gọi thêm người, vãn khách thì cho về bớt, và con số năm người là mục tiêu phải giữ chứ không phải một hàng chờ xếp trước.
Hai hệ này không loại trừ nhau, và phần container cùng inference serving của loạt bài nói rõ phần mềm quản lý cụm nào gánh được cả hai trên cùng một hạ tầng.
Về chia sẻ GPU giữa nhiều công việc, có bốn cơ chế, xếp theo mức cách ly giảm dần: MIG chia ở mức phần cứng nên mỗi instance có SM và bộ nhớ riêng, MPS cho nhiều tiến trình dùng chung một ngữ cảnh GPU mà không cách ly bộ nhớ, time-slicing cho các tiến trình luân phiên dùng GPU theo thời gian, và vGPU cấp GPU ảo cho máy ảo với mức cách ly theo máy ảo nhưng bên dưới vẫn chia theo thời gian. Cách khai từng cơ chế trên Kubernetes, các giá trị của migStrategy và cách kết hợp MIG với time-slicing nằm ở phần container và inference serving của loạt bài.
Chọn theo yêu cầu vận hành: cần đảm bảo chất lượng dịch vụ giữa các nhóm người dùng thì dùng MIG; chỉ cần vét nốt phần GPU còn rảnh cho các job nhỏ không quan trọng thì time-slicing là đủ.
12. Danh sách kiểm tra trước khi chốt thiết kế
Gom lại thành một danh sách dùng được khi lập kế hoạch thật, và cũng là bản tóm tắt các nội dung dễ ra đề.
Điện
- Tổng công suất thiết bị IT, đã cộng cả phần không phải GPU.
- Trần công suất mỗi rack mà cơ sở cho phép.
- Số rack cần, tính trên điện của cả node chứ không riêng phần GPU.
- Điện áp đầu vào, thường 480 V cho hệ rack-scale.
- PUE của cơ sở, để tính ra công suất phải kéo từ lưới.
Làm mát
- Mật độ mỗi rack nằm ở ngưỡng nào, quyết định dùng khí hay chất lỏng.
- Công suất CDU, chọn dư so với tải rack.
- Chất lượng nước phía toà nhà theo hướng dẫn ASHRAE.
- Nhiệt độ nước vào và lưu lượng thiết kế.
Sàn và không gian
- Tải điểm của sàn, một tủ rack-scale khoảng 1,36 tấn.
- Lối vận chuyển tủ từ cửa vào tới vị trí lắp.
Tính toán và bộ nhớ
- Kích thước model và độ chính xác dự kiến.
- Hệ số bộ nhớ theo loại công việc.
- Số GPU cần, làm tròn lên bội số của 8.
- Dung lượng bộ nhớ mỗi GPU đủ cho model hay buộc phải chia nhỏ.
Mạng
- Tỉ lệ NIC trên GPU, chuẩn là 1 trên 1 cho cụm training.
- InfiniBand hay Ethernet, và loại cáp cùng transceiver tương ứng.
- Các mặt phẳng mạng đã tách đủ: compute, storage, in-band, out-of-band.
Vận hành
- Node control plane, khuyến nghị 8 node cấu hình sẵn sàng cao.
- DCGM và đường đẩy số liệu ra Prometheus cùng Grafana.
- Quy trình xử lý khi gặp XID lỗi nghiêm trọng.
- Hệ điều phối: Slurm, Kubernetes, hay cả hai.
Nguồn tham khảo
Đã fact-check (truy cập 2026-10-23):
- Trọng số ba domain của đề thi (38%, 40%, 22%), 50 câu, 60 phút, lệ phí 125 USD, hiệu lực 2 năm: AI Infrastructure and Operations (AIIO) Certification
- TDP của H100 SXM và NVL, H200 SXM và NVL: NVIDIA H100, NVIDIA H200
- B200 cấu hình được tới 1 kW mỗi GPU: Components, NVIDIA HGX AI Factory
- B300 (Blackwell Ultra) đạt NVFP4 dense 15 PFLOPS so với 10 PFLOPS của B200, nên hơn thế hệ trước cả về bộ nhớ lẫn sức tính FP4: Inside NVIDIA Blackwell Ultra
- Công suất rack NVL72 khoảng 120 tới 140 kW, CDU 200 tới 250 kW, nguồn 480 V, tủ nặng khoảng 1,36 tấn, nước toà nhà theo hướng dẫn ASHRAE: tổng hợp từ tài liệu của Supermicro, HPE và Gigabyte cho hệ GB300 NVL72. Các con số lệch nhau vì mỗi bên đo mức duy trì, mức danh định hoặc mức đỉnh khác nhau, và NVIDIA không công bố một con số thống nhất.
- Các chỉ số DCGM Exporter (GPU utilization, memory copy utilization, XID, bộ đếm thời gian bị giới hạn vì nhiệt tính theo microgiây, tỉ lệ chu kỳ SM có warp, tỉ lệ chu kỳ tensor pipe hoạt động, ECC, retired page, row remap, PCIe replay): DCGM Exporter Metrics, DCGM Field Identifiers
- Ba mức kiểm tra của DCGM và phạm vi theo dõi của diagnostics plugin: DCGM Feature Overview, DCGM Diagnostics
- Ánh xạ XID sang mã sức khoẻ phụ thuộc kiến trúc (XID 93 chỉ cảnh báo trên Volta), phân loại lỗi để tự động hoá xử lý, thay đổi về
temperature_maxtừ DCGM 4.6: Diagnostic Plugin, NVIDIA DCGM - Các ngưỡng mật độ chuyển từ làm mát khí sang chất lỏng và các con số PUE là mức tham chiếu phổ biến trong ngành, không phải chỉ tiêu do NVIDIA công bố. Con số 1,53 triệu kWh mỗi năm là phép tính trực tiếp từ 175 kW × 24 giờ × 365 ngày.