GPU H200: Kiến trúc, Hiệu năng và Hướng dẫn Triển khai Đám mây
GPU NVIDIA H200 là bộ tăng tốc trung tâm dữ liệu thế hệ Hopper, với đặc điểm triển khai nổi bật là bộ nhớ: 141 GB HBM3e và băng thông bộ nhớ 4,8 TB/s trên mỗi GPU. Điều đó thay đổi cách bạn lập kế hoạch suy luận ngữ cảnh dài, lô lớn và các tác vụ HPC bị giới hạn bởi bộ nhớ—nhưng không khiến việc lập kế hoạch dung lượng hoặc xác thực trên đám mây trở nên không cần thiết.
Hướng dẫn này giải thích GPU H200 là gì, H200 SXM và H200 NVL khác nhau như thế nào, khi nào nó phù hợp với một khối lượng công việc và cách xác thực triển khai đám mây trước khi cam kết với một cụm lớn hơn. Hướng dẫn này chủ ý tránh các ảnh chụp nhanh về giá của nhà cung cấp vốn dễ thay đổi. Hãy dùng danh sách kiểm tra bên dưới với khu vực, loại máy, cấu trúc liên kết và hợp đồng chính xác mà bạn có thể sử dụng.
Câu trả lời ngắn gọn
Chọn GPU H200 khi khối lượng công việc của bạn bị giới hạn bởi dung lượng hoặc băng thông bộ nhớ GPU, và khi bạn có thể xác thực hệ thống xung quanh—không chỉ riêng bộ tăng tốc. Với máy chủ mô hình một GPU, điều đó có nghĩa là chứng minh trọng số mô hình, không gian làm việc thời gian chạy và bộ nhớ đệm KV vừa đủ kèm dư địa. Với huấn luyện hoặc phục vụ đa GPU, điều đó có nghĩa là chứng minh fabric GPU-to-GPU và, khi áp dụng, mạng giữa các nút.
GPU H200 không phải là bản nâng cấp phù hợp cho mọi trường hợp. Nếu yêu cầu ngắn, kích thước lô thấp hoặc khối lượng công việc bị giới hạn bởi CPU, lưu trữ hoặc mạng, bộ nhớ bổ sung của nó có thể không thay đổi kết quả quan trọng. Hãy bắt đầu bằng bản mô tả khối lượng công việc, sau đó kiểm thử một dấu vết đại diện.
Thông số kỹ thuật GPU H200: điều gì thay đổi kế hoạch triển khai của bạn
NVIDIA liệt kê H200 là GPU kiến trúc Hopper với 141 GB bộ nhớ HBM3e và 4,8 TB/s băng thông bộ nhớ. Sản phẩm có các phiên bản H200 SXM và H200 NVL, cùng các thông số bộ nhớ nổi bật nhưng khác nhau về kiểu dáng, giới hạn điện năng và tùy chọn mở rộng. Các số liệu đỉnh Tensor Core do NVIDIA công bố hữu ích để so sánh cấu hình sản phẩm, nhưng không phải là cam kết về thông lượng ứng dụng: các số liệu bao gồm điều kiện kiểm thử được nêu rõ và giả định về độ thưa. Hãy xem lại các thông số kỹ thuật sản phẩm H200 hiện tại trước khi chọn SKU.
| Thông số liên quan đến triển khai | H200 SXM | H200 NVL | Vì sao điều này quan trọng |
|---|---|---|---|
| Kiến trúc | Hopper | Hopper | Khả năng tương thích phần mềm và các tính năng được hỗ trợ bắt đầu từ nền tảng, không phải tên mô hình. |
| Bộ nhớ GPU | 141 GB HBM3e | 141 GB HBM3e | Nhiều không gian hơn cho trọng số, bộ nhớ đệm KV, activation và dư địa thời gian chạy. |
| Băng thông bộ nhớ | 4,8 TB/s | 4,8 TB/s | Quan trọng đối với khối lượng công việc liên tục di chuyển các tập dữ liệu làm việc lớn qua bộ nhớ. |
| Kiểu dáng | SXM | PCIe hai khe, làm mát bằng không khí | Quyết định những thiết kế máy chủ và lựa chọn fabric nào khả dụng. |
| TDP tối đa được liệt kê | Lên đến 700 W, có thể cấu hình | Lên đến 600 W, có thể cấu hình | Ảnh hưởng đến các lựa chọn về nguồn máy chủ, làm mát, rack và phiên bản đám mây. |
| Liên kết GPU | NVLink, được liệt kê ở mức 900 GB/s | Cầu nối NVLink 2 hoặc 4 chiều, được liệt kê ở mức 900 GB/s mỗi GPU; PCIe Gen5 | Cần kiểm tra cấu trúc liên kết trước khi giả định hiệu năng collective đa GPU. |
| Phân vùng | Lên đến bảy MIG, mỗi MIG 18 GB | Lên đến bảy MIG, mỗi MIG 16,5 GB | Cho phép chia sẻ có kiểm soát, nhưng làm thay đổi mô hình tài nguyên và khả năng quan sát. |
Đây là các số liệu do nhà cung cấp công bố, và NVIDIA gắn nhãn chúng là sơ bộ trên trang sản phẩm của mình. Hãy coi đây là đường cơ sở cấu hình, sau đó xác minh SKU đám mây chính xác và cấu trúc liên kết của nó trong môi trường mà bạn sẽ vận hành.
Vì sao HBM3e quan trọng đối với suy luận LLM
Đối với phục vụ LLM, bộ nhớ GPU được sử dụng cho nhiều thứ hơn là trọng số mô hình. Một phương trình ước lượng dung lượng ban đầu hữu ích là:
dung lượng bộ nhớ GPU cần thiết = trọng số + không gian làm việc thời gian chạy + bộ nhớ đệm KV tại ngữ cảnh và mức đồng thời p95 + dư địa vận hành
GPU H200 có thể hấp dẫn khi bộ nhớ đệm KV trở thành thành phần giới hạn: prompt dài hơn, nhiều chuỗi đồng thời hơn hoặc lô lớn hơn đều có thể làm tăng thành phần này. HBM bổ sung không loại bỏ rủi ro hết bộ nhớ, vì chính sách bộ nhớ đệm, hành vi của bộ cấp phát, lượng tử hóa, song song hóa mô hình và hình dạng lưu lượng vẫn quan trọng. Đối với triển khai ngữ cảnh dài, hãy kết hợp quyết định này với kế hoạch offload và phân tầng bộ nhớ đệm KV thay vì cho rằng nhiều bộ nhớ cục bộ hơn là câu trả lời toàn diện.
H200 SXM hay H200 NVL: hãy chọn cấu trúc liên kết, không chỉ chọn card
Kiểu dáng là một lựa chọn triển khai.
- H200 SXM phù hợp với các thiết kế hệ thống HGX H200 và NVIDIA-Certified có bốn hoặc tám GPU. Đây thường là điểm khởi đầu phù hợp khi một khối lượng công việc cần hệ thống đa GPU liên kết chặt chẽ và ứng dụng sẽ thường xuyên trao đổi dữ liệu giữa các GPU.
- H200 NVL là thiết kế PCIe hai khe, làm mát bằng không khí. NVIDIA liệt kê các cấu hình cầu nối NVLink 2 hoặc 4 chiều, trong khi các hệ thống của đối tác và hệ thống được chứng nhận có thể chứa tối đa tám GPU. Đừng suy ra rằng mọi máy chủ tám GPU đều cung cấp cùng đường truyền trực tiếp giữa GPU với GPU; hãy kiểm tra cấu trúc liên kết thực tế và đo điểm chuẩn các collective mà thời gian chạy của bạn sử dụng.
- Các bản sao độc lập không tự động cần fabric liên kết chặt chẽ nhất. Nếu mỗi bản sao phục vụ các yêu cầu riêng, hãy ưu tiên dung lượng, tính sẵn sàng, tài nguyên máy chủ và ranh giới lập lịch rõ ràng trước khi trả tiền cho một cấu trúc liên kết mà khối lượng công việc sẽ không dùng.
| Mẫu khối lượng công việc | Câu hỏi thiết kế H200 ban đầu | Cần xác thực trước tiên |
|---|---|---|
| Một máy chủ mô hình trên một bộ tăng tốc | Ngân sách bộ nhớ p95 có phù hợp với mức dự phòng an toàn không? | Độ ổn định cấp phát, TTFT, độ trễ giữa các token và ngưỡng bộ nhớ. |
| Một mô hình được phân chia trên nhiều GPU | Chiến lược song song hóa mô hình có phù hợp với cấu trúc liên kết NVLink/NVSwitch thực tế không? | nvidia-smi topo -m, hành vi collective và độ trễ đầu cuối. |
| Nhiều bản sao phục vụ | Các bản sao độc lập hay đang chia sẻ một máy chủ hoặc mạng bị nghẽn? | Thông lượng trên mỗi bản sao, xếp hàng, hành vi noisy neighbor và I/O máy chủ. |
| Huấn luyện hoặc tinh chỉnh phân tán | Fabric và mạng liên nút có phù hợp với mẫu collective không? | Khởi động NCCL, băng thông collective, I/O checkpoint và tỷ lệ tác vụ chậm hơn. |
| Suy luận đa thuê bao | Một GPU đầy đủ, phiên bản MIG hay tài nguyên chia lát theo thời gian là mức cô lập phù hợp? | Cô lập bộ nhớ, cô lập lỗi, phân bổ chi phí và khả năng quan sát theo từng thuê bao. |
NVIDIA có tài liệu về dung lượng MIG của H200, nhưng đừng coi các chế độ chia sẻ GPU là có thể thay thế cho nhau. Trong Kubernetes, MIG tạo các phiên bản GPU được cô lập ở cấp phần cứng, trong khi chia lát theo thời gian xen kẽ công việc và không cung cấp khả năng cô lập bộ nhớ hoặc lỗi giữa các bản sao. Hướng dẫn chia sẻ của GPU Operator giải thích sự đánh đổi và các giới hạn giám sát của nó.
Để so sánh sâu hơn phục vụ quyết định mua, xem H200 so với H100. So sánh đó hữu ích cho việc ra quyết định; trang này là cẩm nang triển khai khi H200 là ứng viên.
Khi GPU H200 là lựa chọn phù hợp
GPU H200 thường đáng để thử nghiệm khi một trong các ràng buộc sau là thực tế trong môi trường sản xuất:
- Suy luận LLM bị giới hạn bởi bộ nhớ. Độ dài ngữ cảnh hoặc mức đồng thời p95 của bạn làm cạn kiệt ngân sách bộ nhớ thực tế trước khi năng lực tính toán được sử dụng hết.
- AI hoặc HPC nhạy cảm với băng thông. Hồ sơ hiệu năng cho thấy tác vụ dành một khoảng thời gian đáng kể để chờ dịch chuyển bộ nhớ thay vì chỉ bão hòa phép toán Tensor Core.
- Tập dữ liệu làm việc lớn hơn cần lưu trong bộ nhớ. Bạn cần thêm không gian cho mô hình, ngữ cảnh truy xuất, batch, cache hoặc cấu trúc dữ liệu khoa học mà không phải lập tức thêm GPU khác.
- Công việc đa GPU liên kết chặt chẽ. Bạn có thể sử dụng hệ thống kiểu H200 SXM/HGX và có bằng chứng rằng ứng dụng được hưởng lợi từ fabric của hệ thống này.
- Yêu cầu phân vùng có kiểm soát. Bạn có lý do rõ ràng để sử dụng các cấu hình MIG được liệt kê, cùng bộ lập lịch và mô hình phân bổ chi phí phù hợp với chúng.
Đừng lựa chọn GPU H200 chỉ dựa trên số lượng tham số của mô hình. Số lượng tham số cho biết rất ít về độ chính xác, không gian làm việc thời gian chạy, chính sách KV-cache, ngữ cảnh tối đa, hình dạng batch và biên độ sẵn sàng. Nó cũng không nói lên điều gì về nút thắt CPU máy chủ, RAM, lưu trữ hoặc mạng có thể chi phối một khối lượng công việc đám mây.
Lập kế hoạch năng lực H200 trước khi thuê GPU đám mây
Hãy sử dụng bản tóm tắt một trang này trước khi tạo phiên bản hoặc yêu cầu một node pool cho cụm.
| Đầu vào | Ghi nhận | Vì sao điều này làm thay đổi kết quả |
|---|---|---|
| Mô hình và độ chính xác | Phiên bản mô hình chính xác, định dạng trọng số, lượng tử hóa và thời gian chạy | Xác định ngưỡng bộ nhớ cơ bản và ngăn xếp phần mềm tương thích. |
| Phân phối yêu cầu | Token prompt p50/p95, token đầu ra, tốc độ đến và mức đồng thời | Giá trị trung bình che giấu các điều kiện cache và xếp hàng làm hỏng SLO độ trễ. |
| Mục tiêu dịch vụ | Thời gian đến token đầu tiên p95, độ trễ giữa các token p95, ngân sách lỗi và mục tiêu khôi phục | Xác định liệu bạn có cần bản sao, năng lực dự phòng sẵn sàng hay fabric nhanh hơn hay không. |
| Kế hoạch song song hóa | Một GPU, song song tensor, song song pipeline, song song dữ liệu hoặc các bản sao độc lập | Xác định liệu bộ nhớ cục bộ, NVLink hay mạng là đường dẫn tới hạn. |
| Bề mặt triển khai | Một VM, node pool được quản lý hoặc cụm Kubernetes | Thay đổi trách nhiệm về trình điều khiển, lập lịch, khả năng quan sát và nâng cấp. |
| Đường dẫn dữ liệu | Nguồn tạo phẩm mô hình, kho checkpoint, chỉ mục vector, đường dẫn egress và chính sách mạng | Ngăn bộ tăng tốc nhanh phải chờ lưu trữ hoặc mạng. |
| Đơn vị tài chính | Yêu cầu được chấp nhận, batch hoàn thành, epoch tác vụ hoặc một triệu token được chấp nhận | Ngăn báo giá GPU theo giờ trở thành chỉ số chi phí duy nhất. |
Giá trị của bản tóm tắt này là giúp nhận ra sự không phù hợp từ sớm. Ví dụ, một cấu hình một GPU có thể thất bại do áp lực ngữ cảnh và cache p95 ngay cả khi bài kiểm tra tổng hợp với prompt ngắn trông rất tốt. Ngược lại, một cấu hình đa GPU có thể hoạt động kém nếu bị phân chia qua một fabric mà thời gian chạy không sử dụng hiệu quả.
Triển khai đám mây: runbook GPU H200 theo từng giai đoạn
1. Xác nhận cấu hình đám mây chính xác
Hãy yêu cầu nhà cung cấp hoặc nhóm nền tảng cung cấp chính xác kiểu dáng bộ tăng tốc, số lượng GPU, phân bổ CPU/RAM, lưu trữ cục bộ và lưu trữ bền vững, đặc tính mạng và cấu trúc liên kết GPU. Ghi lại câu trả lời trong phiếu triển khai. Chỉ riêng “H200” không cung cấp đủ thông tin để kỳ vọng hiệu năng đa GPU.
Trước khi đặt trước năng lực, hãy xác thực các chi tiết này trong một thử nghiệm ngắn hạn:
- H200 SXM hoặc H200 NVL
- Số lượng GPU và đầu ra của
nvidia-smi topo -m - liệu phiên bản là độc quyền, được phân vùng hay chia sẻ theo lát thời gian
- các phiên bản trình điều khiển, CUDA, container-runtime và framework
- RAM máy chủ, số lõi CPU, thông lượng lưu trữ và đường dẫn mạng khả dụng
- thời gian kéo image, tải mô hình, checkpoint và khởi động lại
2. Cài đặt một ngăn xếp phần mềm được hỗ trợ
Đối với triển khai Kubernetes, GPU Operator của NVIDIA có thể quản lý trình điều khiển NVIDIA, bộ công cụ container, plugin thiết bị, GPU Feature Discovery, giám sát dựa trên DCGM và các thành phần liên quan. Hướng dẫn cài đặt chính thức lưu ý tính nhất quán của hệ điều hành nút khi Operator quản lý trình điều khiển, cũng như các điều kiện tiên quyết về bảo mật namespace và container runtime. Hãy làm theo hướng dẫn cài đặt GPU Operator hiện hành thay vì sao chép một phiên bản chart đã lỗi thời.
Một lần cài đặt ban đầu tuân theo mẫu này; hãy thay phiên bản bằng phiên bản bạn đã xác thực theo chính sách cụm và trình điều khiển của mình:
helm install --wait gpu-operator \
-n gpu-operator --create-namespace \
oci://nvcr.io/nvidia/cloud-native-charts/gpu-operator \
--version=<validated-operator-version>
Sau khi cài đặt, hãy xác thực các pod Operator và trạng thái ClusterPolicy trước khi gửi workload đầu tiên. Hướng dẫn Operator cũng chỉ ra cách xác nhận rằng các nút báo cáo tài nguyên nvidia.com/gpu có thể cấp phát.
3. Quy định việc lập lịch một cách rõ ràng
Hãy bắt đầu bằng yêu cầu GPU đầy đủ độc quyền, trừ khi bạn đã chủ đích thiết kế cho một chế độ chia sẻ:
resources:
limits:
nvidia.com/gpu: 1
Sử dụng nhãn node pool do nền tảng sở hữu hoặc bộ chọn đám mây để nhắm đến các nút H200 đã được xác minh; không mã hóa cứng nhãn sản phẩm từ một cụm ví dụ. Kubernetes mô tả việc lập lịch GPU thông qua plugin thiết bị và tài nguyên mở rộng, bao gồm mẫu giới hạn tài nguyên ở trên. Xem tài liệu về lập lịch GPU của Kubernetes để biết hợp đồng hiện hành.
Nếu bạn bật MIG, trước tiên hãy drain hoặc cordon các nút liên quan. NVIDIA lưu ý rằng việc thay đổi chế độ hoặc cấu hình MIG yêu cầu workload người dùng không còn trên GPU và có thể yêu cầu khởi động lại trong một số môi trường đám mây. Hãy xem lại quy trình MIG của GPU Operator trước khi coi thay đổi phân vùng là một thao tác trực tuyến.
4. Chứng minh một workload đơn giản, sau đó là workload thực tế của bạn
Chạy ba cổng theo thứ tự:
- Cổng nền tảng: Trình điều khiển và CUDA tải được; bộ lập lịch nhìn thấy số lượng GPU dự kiến; container có thể tạo ngữ cảnh CUDA.
- Cổng fabric: Topology khớp với thiết kế đã định; runtime đa GPU khởi tạo và hoàn tất một bài kiểm tra collective đại diện.
- Cổng ứng dụng: Việc phát lại các prompt đại diện, kích thước batch, độ dài ngữ cảnh, mẫu checkpoint hoặc đầu vào mô phỏng đạt mục tiêu về độ trễ, thông lượng và lỗi yêu cầu.
Cổng thứ ba là cổng ra quyết định. Một benchmark chung có thể cho bạn biết GPU hoạt động; nó không thể cho bạn biết liệu phân phối lưu lượng, máy chủ mô hình và chính sách bộ đệm của bạn có hoạt động hay không.
Xác thực hiệu năng trước khi mở rộng quy mô
Xây dựng các bài kiểm tra chấp nhận xoay quanh nút thắt bạn dự kiến, sau đó kiểm tra kết quả có thể bác bỏ giả định đó.
| Giả định | Kiểm tra | Tín hiệu thành công | Lỗi cần điều tra |
|---|---|---|---|
| Mô hình phù hợp | Chạy trace ngữ cảnh/đồng thời p95 với ngưỡng bộ nhớ | Cấp phát ổn định với phần dung lượng dự phòng rõ ràng | OOM, thrash do eviction hoặc các đột biến độ trễ khi bộ đệm tăng lên. |
| Fabric là đủ | Chạy đúng chế độ song song hóa và một bài kiểm tra collective liên quan | Không treo; thời gian collective và đầu cuối ổn định | Lỗi khởi tạo NCCL, rank không đồng đều hoặc peer chậm. |
| Dịch vụ đáp ứng SLO | Đo TTFT p50/p95, độ trễ giữa các token, độ trễ đầu cuối và số yêu cầu đã hoàn thành | Các mục tiêu được duy trì dưới tải đại diện | Xếp hàng, độ trễ đuôi dài hoặc số lần thử lại tăng. |
| Nút khỏe mạnh | Kiểm tra telemetry thụ động và chẩn đoán chủ động trong cửa sổ bảo trì | Không có phát hiện nào về phần cứng, fabric hoặc triển khai cần xử lý | Sự kiện ECC/Xid, giới hạn nhiệt/nguồn, các phát hiện về PCIe/NVLink. |
| Hiệu quả kinh tế được đảm bảo | Chia thời gian được tải đầy đủ cho công việc hữu ích đã hoàn thành | Chi phí nằm trong ngưỡng ra mắt | Năng lực nhàn rỗi, công việc thất bại hoặc chi phí lưu trữ/mạng chưa được tính giá. |
NVIDIA DCGM tách biệt việc giám sát sức khỏe thụ động với chẩn đoán chủ động. Các quy trình chẩn đoán của nó có thể kiểm tra các đường dẫn triển khai, bộ nhớ, PCIe, NVLink, tính toán, nguồn, nhiệt và giao tiếp, nhưng chúng tiêu thụ tài nguyên và có thể xung đột với công việc sản xuất. Hãy drain hoặc lên lịch một cửa sổ bảo trì trước khi chạy chẩn đoán xâm lấn. Sử dụng hướng dẫn chẩn đoán hiện hành của DCGM để chọn cấp độ kiểm tra phù hợp.
Đối với các dịch vụ LLM, hãy theo dõi cả tín hiệu ứng dụng và hạ tầng:
- thời gian đến token đầu tiên p50/p95 và độ trễ giữa các token
- số token đầu ra được chấp nhận mỗi giây và số yêu cầu hoàn tất mỗi giây
- độ sâu hàng đợi, lượt hủy, lần thử lại và tỷ lệ lỗi
- bộ nhớ GPU được cấp phát so với được dành trước, mức sử dụng GPU, điện năng và nhiệt độ
- hành vi cache hit/offload và các lỗi liên quan đến bộ nhớ đệm
- mức bão hòa CPU máy chủ, áp lực RAM, I/O mô hình/checkpoint và độ trễ mạng
Nếu một chỉ số cải thiện trong khi chỉ số khác xấu đi, chưa nên mở rộng quy mô. Tốc độ token cao hơn cùng với độ trễ p95 hoặc số lần thử lại tăng có thể là một bước thụt lùi đối với dịch vụ hướng đến khách hàng.
Tối ưu chi phí theo công việc hoàn tất, không phải theo thời gian GPU mỗi giờ
Mức giá GPU H200 trên đám mây thay đổi theo khu vực, thời hạn đặt trước, cấu hình máy chủ và nguồn cung, vì vậy bảng giá tĩnh sẽ nhanh chóng lỗi thời. Thay vào đó, hãy dùng một đơn vị khối lượng công việc làm lộ rõ thời gian nhàn rỗi và công việc thất bại:
fully loaded hourly cost = accelerator + attached CPU/RAM + storage + network + licenses + operating overhead
cost per completed request = fully loaded hourly cost / completed requests per hour
cost per million accepted output tokens = fully loaded hourly cost / accepted output tokens per hour × 1,000,000
Hãy tính toán điều này theo hỗn hợp lưu lượng bạn dự kiến khi ra mắt, không phải theo bản demo thông lượng tối đa. Bao gồm cả năng lực được giữ lại cho chuyển đổi dự phòng, tải mô hình, checkpoint và bảo trì. Để xem mô hình chi tiết hơn, hãy xem Chi phí LLM tự lưu trữ trên mỗi triệu token.
Cũng có một câu hỏi về ranh giới: bạn cần vận hành runtime hay cần quyền truy cập đáng tin cậy vào đầu ra của mô hình? Nếu bạn cần kernel tùy chỉnh, một runtime cụ thể, tính cục bộ dữ liệu chuyên dụng hoặc thử nghiệm phần cứng có kiểm soát, một bản thử nghiệm GPU H200 trên đám mây có thể là hợp lý. Nếu chủ yếu cần API mô hình, hãy so sánh gánh nặng vận hành với phương án API trước khi cam kết đầu tư hạ tầng. Hướng dẫn triển khai máy chủ GPU và Hướng dẫn cụm GPU Kubernetes có thể giúp làm rõ ranh giới này.
Danh sách kiểm tra triển khai GPU H200
Trước khi xem một triển khai H200 là sẵn sàng, hãy xác minh tất cả các mục sau:
- [ ] Đã ghi nhận chính xác dạng thức H200, số lượng GPU và cấu trúc liên kết
- [ ] Đã kiểm thử ngân sách bộ nhớ ở ngữ cảnh p95 và mức đồng thời dự kiến
- [ ] Đã xác thực khả năng tương thích của driver, CUDA, framework và image container
- [ ] Đã xác nhận tình trạng GPU Operator/device plugin tại nơi sử dụng Kubernetes
- [ ] Scheduler hiển thị dung lượng
nvidia.com/gpunhư dự kiến - [ ] Kiểm thử collective đa GPU đạt trên cấu trúc liên kết sản xuất
- [ ] Kiểm thử tải đại diện đáp ứng các mục tiêu TTFT, độ trễ, thông lượng và lỗi
- [ ] Tình trạng DCGM và chẩn đoán phù hợp trong cửa sổ bảo trì là một phần của runbook
- [ ] Đã đo lường các đường dẫn lưu trữ, mạng, tải mô hình, checkpoint và khởi động lại
- [ ] Chi phí được tính trên mỗi đơn vị hữu ích hoàn tất, bao gồm năng lực nhàn rỗi và phục hồi
Câu hỏi thường gặp
GPU H200 có bao nhiêu bộ nhớ?
NVIDIA công bố 141 GB bộ nhớ HBM3e và băng thông bộ nhớ 4,8 TB/s cho cả H200 SXM lẫn H200 NVL. Hãy xác nhận SKU và cấu hình hệ thống chính xác với nhà cung cấp, vì dạng thức card và kết nối liên thông khác nhau. Thông số kỹ thuật H200 của NVIDIA là nguồn của các số liệu trong hướng dẫn này.
GPU H200 có tốt hơn H100 cho suy luận LLM không?
Có thể, đặc biệt khi dung lượng bộ nhớ hoặc băng thông bộ nhớ là giới hạn của khối lượng công việc. Câu trả lời thực tế phụ thuộc vào độ chính xác của mô hình, độ dài ngữ cảnh, hành vi KV-cache, mức đồng thời, runtime phục vụ và cấu trúc liên kết hệ thống. Hãy so sánh khối lượng công việc bằng một trace đại diện; đừng xem benchmark của nhà cung cấp là sự thay thế cho SLO dịch vụ của bạn. Xem so sánh H200 và H100 để biết khung ra quyết định về phần cứng.
Tôi nên chọn H200 SXM hay H200 NVL?
Hãy chọn theo cấu trúc liên kết trước. H200 SXM phù hợp với các cấu hình đa GPU kiểu HGX liên kết chặt chẽ. H200 NVL là tùy chọn PCIe làm mát bằng không khí, với cấu hình cầu nối NVLink 2 hoặc 4 chiều. Hãy xác minh cấu trúc liên kết, máy chủ và mô hình giao tiếp của khối lượng công việc thay vì chỉ lựa chọn dựa trên bộ nhớ.
GPU H200 có hỗ trợ MIG không?
NVIDIA công bố tối đa bảy phiên bản MIG cho H200 SXM và H200 NVL, với các mức dung lượng bộ nhớ trên mỗi phiên bản được liệt kê khác nhau. Hãy dùng MIG khi bạn cần khả năng cô lập bộ nhớ và lỗi được phần cứng hỗ trợ. Không thay thế bằng chia lát thời gian khi cần các đặc tính cô lập đó.
Tôi cần bao nhiêu GPU H200?
Hãy bắt đầu với cấu hình nhỏ nhất vượt qua bài kiểm thử đại diện về bộ nhớ, độ trễ, thông lượng và khôi phục. Chỉ thêm GPU khi ngân sách bộ nhớ, số lượng bản sao hoặc kế hoạch song song hóa đã được xác thực yêu cầu. Số lượng GPU lớn hơn mà không có khối lượng công việc nhận biết fabric có thể làm tăng chi phí và phạm vi vận hành mà không cải thiện kết quả hướng đến khách hàng.
Bắt đầu với bản thử nghiệm GPU H200 đã được xác thực
Triển khai GPU H200 phù hợp là một hệ thống được đo lường: bộ nhớ bộ tăng tốc, cấu trúc liên kết, scheduler, runtime, đường dẫn dữ liệu, khả năng quan sát và tính kinh tế của khối lượng công việc đều cần đồng bộ. Hãy bắt đầu với một bản thử nghiệm có gắn công cụ đo lường, phát lại lưu lượng thực tế, ghi lại các chế độ lỗi và chỉ mở rộng quy mô sau khi bằng chứng ủng hộ bước tăng năng lực tiếp theo.
