GPU Nvidia H200: Kiến trúc, hiệu năng và hướng dẫn triển khai trên đám mây

GPU Nvidia H200: Kiến trúc, hiệu năng và hướng dẫn triển khai trên đám mây

GPU Nvidia H200 là bộ tăng tốc thuộc thế hệ Hopper, được thiết kế cho các khối lượng công việc AI và HPC mà ở đó dung lượng bộ nhớ, băng thông bộ nhớ và cấu trúc liên kết đa GPU ảnh hưởng đáng kể đến kết quả. Theo tài liệu của NVIDIA, mỗi H200 có 141 GB bộ nhớ HBM3e và băng thông bộ nhớ 4,8 TB/s. Đây là những thông số khởi đầu quan trọng, nhưng chỉ riêng chúng không cho biết liệu một hệ thống triển khai H200 có đáp ứng được mục tiêu độ trễ, chứa đủ mô hình cùng bộ nhớ đệm KV hay mở rộng hiệu quả trên một nút đám mây hay không. Thông số kỹ thuật H200 của NVIDIA là tài liệu tham chiếu về phần cứng; hướng dẫn này chuyển các thông số đó thành một quy trình triển khai.

Đối với các nhà phát triển AI và đội ngũ hạ tầng ML, quyết định thực tế thường là: liệu mô hình, ngữ cảnh hoạt động ở mức cao nhất và phần tài nguyên phụ trội khi chạy có thể vừa trên một GPU mà vẫn còn đủ dung lượng dự phòng hay không? Nếu không, liệu khối lượng công việc có thể được xử lý trong một nút H200 có băng thông cao trước khi phải truyền qua mạng hay không? Câu trả lời phải quyết định kiểu dáng phần cứng, phương án song song hóa và các bài kiểm tra nghiệm thu, chứ không phải con số TFLOPS đỉnh được quảng bá.

Đây là hướng dẫn về kiến trúc và triển khai, không phải bảng giá. Nếu bạn đang so sánh báo giá hoặc giá thuê đám mây theo giờ, hãy bắt đầu với hướng dẫn giá GPU H200 của chúng tôi. Nếu bạn đang cân nhắc cụ thể giữa H200 và H100, hãy xem bài so sánh H200 và H100.

Trả lời nhanh: Khi nào GPU Nvidia H200 phù hợp

Hãy chọn GPU Nvidia H200 khi tất cả hoặc phần lớn các điều kiện sau đây đúng:

• Khối lượng công việc của bạn bị giới hạn bởi bộ nhớ dành cho mô hình, mức tăng của bộ nhớ đệm KV hoặc băng thông bộ nhớ, chứ không chỉ bởi thông lượng tính toán.
• Bạn cần thêm dung lượng cho suy luận với ngữ cảnh dài hoặc các yêu cầu đồng thời mà không phải lập tức chia mô hình ra nhiều nút.
• Bạn có thể xác minh cấu trúc liên kết đám mây thực tế — kiểu dáng phần cứng SXM hoặc PCIe/NVL, số GPU trên mỗi nút và kết nối liên thông sẵn có — thay vì coi “H200” là một đặc tả triển khai đầy đủ.
• Bạn sẵn sàng đo thời gian tạo token đầu tiên, thông lượng token đầu ra, độ trễ đuôi, mức sử dụng bộ nhớ GPU và tình trạng xếp hàng với cùng đặc điểm yêu cầu dự kiến trong môi trường sản xuất.
• Bạn cần đủ quyền kiểm soát đối với phần mềm phục vụ suy luận, trọng số mô hình, việc phân lô hoặc tính cục bộ của dữ liệu để việc trực tiếp vận hành tài nguyên GPU trở nên hợp lý.

H200 không mặc nhiên là lựa chọn tốt nhất cho mọi ứng dụng AI tạo sinh. Nếu một bộ tăng tốc nhỏ hơn có thể thoải mái chứa mô hình và ngữ cảnh hoạt động của nó, hoặc nếu sản phẩm của bạn cần chuyển đổi giữa nhiều mô hình được lưu trữ sẵn mà không phải duy trì vận hành GPU, API mô hình được quản lý có thể là phương án vận hành cơ sở đơn giản hơn. Điều quan trọng cần so sánh là chi phí hoàn thành khối lượng công việc và độ tin cậy với đặc điểm lưu lượng thực tế của bạn, chứ không phải một con số phần cứng thuần túy.

Kiến trúc GPU Nvidia H200: Các thông số ảnh hưởng đến lựa chọn triển khai

H200 sử dụng kiến trúc Hopper của NVIDIA. Hopper bao gồm Transformer Engine và NVLink thế hệ thứ tư; NVIDIA định vị các tính năng này cho xử lý transformer với độ chính xác hỗn hợp và giao tiếp đa GPU. Tổng quan kiến trúc Hopper của NVIDIA cũng giải thích vì sao cấu trúc liên kết máy chủ quan trọng khi khối lượng công việc vượt ra ngoài một bộ tăng tốc.

Nguồn: Thông số kỹ thuật NVIDIA H200. NVIDIA lưu ý rằng một số số liệu hiệu năng được công bố có sử dụng tính thưa; hãy dùng các số liệu đó làm tham chiếu về khả năng, không phải cam kết về thông lượng trong môi trường sản xuất.

Dung lượng bộ nhớ là một biến số triển khai, không phải con số tiếp thị

Để phục vụ LLM, hãy lập kế hoạch HBM dựa trên toàn bộ tập dữ liệu làm việc:

required GPU memory ≈ model weights
                    + peak active KV cache
                    + runtime workspaces
                    + fragmentation and safety margin

Điểm kiểm tra của mô hình chỉ là yếu tố đầu tiên. Một cấu hình tải thành công vẫn có thể có quá ít chỗ cho cửa sổ ngữ cảnh đang hoạt động và các chuỗi đồng thời mà bạn định phục vụ. Đó là lý do 141 GB HBM3e của H200 có thể hữu ích ngay cả khi về mặt kỹ thuật mô hình vừa với một cấu hình thuộc lớp H100: nó cho triển khai nhiều dư địa hơn để đánh đổi kích thước lô, độ dài ngữ cảnh và tính đồng thời với độ trễ.

Trước khi đặt trước năng lực, hãy ghi lại các thông số đầu vào của khối lượng công việc này:

1. Mô hình, định dạng trọng số và mọi chế độ lượng tử hóa hoặc độ chính xác.
2. Số token đầu vào tối đa và số token được tạo tối đa cho một yêu cầu thực tế.
3. Số chuỗi hoạt động đồng thời dự kiến — không chỉ số yêu cầu mỗi giây.
4. Các SLO về độ trễ, bao gồm thời gian đến token đầu tiên và độ trễ đuôi.
5. Ứng dụng cần một GPU đầy đủ duy nhất, một phân vùng cô lập hay một bản sao mô hình đa GPU.

Thực hiện bài toán định cỡ đầu tiên với các prompt có chủ ý khó. Một bài kiểm tra prompt ngắn trông có vẻ ổn có thể che giấu áp lực bộ nhớ đệm KV xuất hiện ở độ dài ngữ cảnh trong môi trường sản xuất.

Băng thông và cấu trúc liên kết là các kiểm tra riêng biệt

Băng thông bộ nhớ có thể quan trọng ít nhất ngang với năng lực tính toán đối với quá trình giải mã tự hồi quy và các khối lượng công việc nặng về bộ nhớ. Băng thông liên GPU trở nên quan trọng khi mô hình được phân mảnh. Đừng cho rằng tám GPU H200 có một vùng nhớ dùng chung duy nhất 1.128 GB: phần mềm phục vụ phân tán phải đặt các tensor và trao đổi các kích hoạt qua những liên kết thực tế sẵn có cho nó.

NVIDIA mô tả NVLink thế hệ thứ tư cung cấp băng thông hai chiều 900 GB/s cho mỗi GPU trong các hệ thống DGX và HGX, trong khi NVSwitch hỗ trợ miền tám GPU. Đó là lý do cấu trúc liên kết một nút cần được đánh giá riêng biệt so với cụm đa nút. Tài liệu tham khảo về kiến trúc Hopper của NVIDIA là nguồn về năng lực liên kết; tài liệu phiên bản máy chủ của nhà cung cấp đám mây là nguồn về cấu trúc liên kết mà bạn thực sự nhận được.

H200 SXM so với H200 NVL: chọn dạng triển khai trước khi chọn phiên bản

“H200” không xác định một thiết kế máy chủ duy nhất. Hai dạng triển khai phổ biến có các hệ quả vận hành khác nhau.

Cả hai dạng đều liệt kê 141 GB HBM3e và băng thông bộ nhớ 4,8 TB/s trong bảng thông số kỹ thuật của NVIDIA. Yếu tố khác biệt đối với khối lượng công việc đa GPU thường là cấu trúc liên kết máy chủ và liên kết xung quanh bộ nhớ đó. Hãy coi sơ đồ cấu trúc liên kết của nhà cung cấp và việc kiểm tra cấu trúc liên kết trong phiên bản là các tài liệu cần thiết khi mua sắm.

Ma trận quyết định từ khối lượng công việc đến cấu trúc liên kết

Sử dụng ma trận này để quyết định thử nghiệm triển khai đầu tiên. Đây là một giả thuyết khởi đầu, không thay thế cho phép đo điểm chuẩn.

Đối với suy luận phân tán, tài liệu của vLLM trình bày cùng một lộ trình cơ bản: dùng một GPU khi mô hình vừa, dùng song song tensor khi mô hình vừa trên một nút, và thêm song song pipeline khi phải trải qua nhiều nút. Các cờ chính xác và chiến lược được hỗ trợ phụ thuộc vào phiên bản vLLM và kiến trúc mô hình, vì vậy hãy xác thực theo bản phát hành đã cài đặt của bạn. Xem tài liệu về suy luận phân tán của vLLM.

Cẩm nang triển khai trên đám mây cho khối lượng công việc GPU Nvidia H200

Cách triển khai an toàn nhất là theo từng giai đoạn. Mỗi giai đoạn trả lời một câu hỏi trước khi bạn thêm một nguồn biến thiên khác.

1. Viết hợp đồng khối lượng công việc

Xác định lưu lượng kiểm thử trước khi cấp phát tài nguyên. Bao gồm phiên bản mô hình, độ chính xác, phân phối token đầu vào và đầu ra, mức độ đồng thời, mục tiêu mức dịch vụ, vị trí địa lý, yêu cầu dữ liệu và đường cơ sở chi phí. Duy trì một tập hồi quy cố định nhỏ cùng với một tập phát lại thực tế.

Điều này ngăn ngừa một sai lầm phổ biến: so sánh phần cứng bằng bài kiểm tra thông lượng tổng hợp, rồi phát hiện cấu hình đã chọn thất bại với các prompt dài hoặc điều kiện độ trễ đuôi quan trọng đối với ứng dụng.

2. Xác minh nút trước khi triển khai máy chủ mô hình

Sau khi phiên bản khởi động, hãy xác định bố trí vật lý thay vì dựa vào tên sản phẩm:

nvidia-smi topo -m
nvidia-smi topo -p2p n

NVIDIA khuyến nghị các kiểm tra này khi chẩn đoán cấu trúc liên kết và hành vi NVLink. Hướng dẫn về hiệu năng và tinh chỉnh NCCL của hãng cũng đề cập đến nvbandwidth hoặc nvloom để kiểm tra xem băng thông GPU-đến-GPU đo được có khớp với đường truyền phần cứng dự kiến hay không.

Ghi lại đầu ra cấu trúc liên kết trong runbook triển khai. Điều này giúp có thể kiểm tra một sự suy giảm hiệu năng về sau: bạn có thể phân biệt thay đổi ứng dụng với bố trí PCIe, NVLink hoặc mạng khác.

3. Cài đặt ngăn xếp phần mềm GPU được hỗ trợ

Đối với Kubernetes, cụm cần trình điều khiển NVIDIA, đường dẫn thời gian chạy container và plugin thiết bị của nhà cung cấp trước khi khối lượng công việc có thể yêu cầu GPU. Kubernetes hiển thị GPU dưới dạng tài nguyên tùy chỉnh có thể lập lịch sau khi plugin thiết bị được cài đặt. Hướng dẫn lập lịch GPU của Kubernetes giải thích mô hình tài nguyên và việc dùng nhãn hoặc affinity cho các cụm bộ tăng tốc hỗn hợp.

GPU Operator của NVIDIA có thể quản lý trình điều khiển, NVIDIA Container Toolkit, plugin thiết bị, DCGM Exporter và MIG Manager như một ngăn xếp phối hợp trên các nút worker GPU. Hãy sử dụng tài liệu cài đặt GPU Operator hiện hành và xác nhận rằng các pod validator và operator hoạt động tốt trước khi bạn đưa vào một máy chủ mô hình.

Một yêu cầu tài nguyên tối thiểu về mặt khái niệm rất đơn giản:

resources:
  limits:
    nvidia.com/gpu: 4

Trong Kubernetes, GPU thường được chỉ định trong limits; nếu bạn cũng chỉ định yêu cầu GPU, yêu cầu đó phải bằng giới hạn. Thêm nhãn nút, affinity, taint và nhãn lớp khối lượng công việc để một dịch vụ H200 nhạy cảm với độ trễ không bị lập lịch vào nhóm bộ tăng tốc không mong muốn.

4. Bắt đầu bằng bài kiểm tra phục vụ một biến

Khởi chạy một bản sao mô hình với cấu trúc liên kết nhỏ nhất có thể chứa khối lượng công việc. Đối với triển khai vLLM nhiều GPU trên một nút, kích thước song song tensor phải khớp với số GPU được gán cho bản sao. Ví dụ:

vllm serve <model-identifier> \
  --tensor-parallel-size 4

Đây chủ ý là ví dụ về cấu trúc liên kết, không phải lệnh sản xuất có thể sao chép và chạy ngay. Ghim image container, khả năng tương thích driver/CUDA, bản sửa đổi mô hình, tokenizer và phiên bản công cụ phục vụ trong manifest triển khai của riêng bạn. Sau đó chỉ thay đổi từng biến một: kích thước song song tensor, số chuỗi hoạt động tối đa, chính sách cấp phát bộ nhớ đệm hoặc số lượng bản sao.

5. Kiểm tra prefill và decode riêng biệt

Thông lượng token có thể che giấu đường dẫn độ trễ mà người dùng của bạn trải nghiệm. Hãy đo ít nhất:

• Thời gian đến token đầu tiên cho prompt đầu vào ngắn và dài.
• Thông lượng token đầu ra sau token đầu tiên.
• Độ trễ đầu cuối P50, P95 và P99.
• Bộ nhớ GPU đã sử dụng, áp lực bộ nhớ đệm và các sự kiện hết bộ nhớ.
• Thời gian trong hàng đợi, yêu cầu bị hủy, lần thử lại và tỷ lệ lỗi.

GPU Nvidia H200 có thể cải thiện một triển khai bị hạn chế vì bộ nhớ lớn hơn và nhanh hơn của nó tạo thêm dư địa lập lịch, nhưng chỉ tổ hợp yêu cầu được đo lường mới cho thấy liệu dư địa đó có trở thành năng lực hữu ích hướng đến người dùng hay không.

6. Thêm bản sao trước khi thêm nút khi có thể

Nếu một nút H200 chứa được mô hình và đáp ứng các mục tiêu độ trễ, việc thêm bản sao có thể đơn giản hơn về vận hành so với đưa vào nút thứ hai. Khi mở rộng qua nhiều nút, hãy kiểm tra mạng và đường dẫn collective trước. Đối với suy luận đa nút, hãy giữ môi trường và tạo phẩm mô hình nhất quán giữa các nút; sự không khớp về container, driver, bản sửa đổi mô hình hoặc tokenizer có thể trông giống như một vấn đề phần cứng.

Không ép buộc các cài đặt thuật toán NCCL trước khi thu thập đường cơ sở cấu trúc liên kết. Tài liệu NCCL của NVIDIA cho biết lựa chọn mặc định nhận biết cấu trúc liên kết; các cài đặt thủ công là phản hồi đối với hành vi đã đo lường, không phải sự thay thế cho việc đo lường.

7. Trang bị công cụ giám sát năng lực trước khi lưu lượng gặp rủi ro

DCGM Exporter có thể cung cấp dữ liệu đo từ xa của GPU cho một ngăn xếp giám sát Kubernetes. NVIDIA ghi nhận đây là một phần của ngăn xếp do GPU Operator quản lý và cung cấp hướng dẫn cài đặt cho môi trường Prometheus trong tài liệu DCGM Exporter.

Xây dựng bảng điều khiển liên kết tình trạng hạ tầng với kết quả dịch vụ:

8. Lập kế hoạch cho hành vi khi xảy ra lỗi và bảo trì

Một triển khai H200 chỉ sẵn sàng cho môi trường sản xuất khi có phương án khôi phục. Hãy kiểm thử việc khởi động lại bản sao, rút cạn nút, tải lại mô hình, khởi động lạnh bộ nhớ đệm và gián đoạn mạng phía thượng nguồn. Xác định điều gì sẽ xảy ra khi năng lực tạm thời không khả dụng: xếp hàng, loại bỏ tải, định tuyến đến mô hình nhỏ hơn hoặc dùng phương án dự phòng bằng API được quản lý. Lựa chọn tốt nhất phụ thuộc vào yêu cầu về tính chính xác và độ trễ của sản phẩm.

Hiệu năng: đo điểm chuẩn khối lượng công việc, không phải tài liệu quảng cáo

NVIDIA công bố tài liệu về năng lực và điểm chuẩn cho H200, bao gồm tuyên bố về hiệu năng suy luận LLM cao hơn trong một số so sánh được chọn. Các kết quả đó hữu ích để hiểu những gì bộ tăng tốc có thể mang lại, nhưng không phải là cam kết cho một mô hình, độ dài ngữ cảnh, phương pháp lượng tử hóa, ngăn xếp phục vụ hoặc cấu trúc liên kết đám mây cụ thể. Bảng dữ liệu H200 nên được đọc cùng với các điều kiện thử nghiệm và chú thích.

Để so sánh H200 có thể áp dụng thực tế, hãy giữ cố định các biến sau:

1. Phiên bản mô hình, tokenizer, độ chính xác và lượng tử hóa.
2. Phân phối token đầu vào và token đầu ra.
3. Chính sách đồng thời và kiểm soát tiếp nhận.
4. Bố cục song song tensor/pipeline và cấu trúc liên kết phần cứng thực tế.
5. Phiên bản công cụ phục vụ và CUDA/NCCL.
6. Phương pháp đo SLA, bao gồm trạng thái khởi động và bộ nhớ đệm.
7. Đơn vị định giá đám mây và các chi phí ngoài GPU như lưu trữ, truyền dữ liệu ra ngoài, CPU và vận hành.

Kế hoạch kiểm thử đó có giá trị hơn so sánh chung chung về “token mỗi giây” vì nó cho biết liệu GPU Nvidia H200 có thay đổi SLO hướng đến khách hàng hoặc chi phí cho mỗi yêu cầu hoàn thành hay không.

Danh sách kiểm tra triển khai H200

Dùng danh sách kiểm tra này làm cổng phê duyệt triển khai cho một khối lượng công việc H200 mới.

• [ ] Ghi lại mô hình, độ chính xác, độ dài ngữ cảnh đỉnh, độ dài đầu ra và mức đồng thời mục tiêu.
• [ ] Tính ngân sách bộ nhớ cho trọng số, bộ nhớ đệm KV, không gian làm việc thời gian chạy và biên độ an toàn.
• [ ] Xác nhận H200 được cấp phát là SXM hay NVL và ghi lại nvidia-smi topo -m.
• [ ] Xác minh khả năng tương thích của driver, CUDA, container, framework và công cụ phục vụ.
• [ ] Yêu cầu số lượng GPU dự kiến với các ràng buộc về vị trí trong trình điều phối.
• [ ] Chạy kiểm tra sức khỏe CUDA/toán tử trước khi tải mô hình.
• [ ] Chạy xác thực cấu trúc liên kết và băng thông collective trước khi chấp nhận kết quả đa GPU.
• [ ] Đo riêng lưu lượng ngữ cảnh ngắn và ngữ cảnh dài.
• [ ] Theo dõi TTFT, thông lượng token đầu ra, độ trễ P95/P99, thời gian xếp hàng, lỗi và bộ nhớ GPU.
• [ ] Kiểm thử tình huống khởi động lại, rút cạn nút và giảm năng lực.
• [ ] So sánh kết quả với đường cơ sở API mô hình được quản lý ở cùng khối lượng công việc và SLO.
• [ ] Lưu cấu trúc liên kết, cấu hình điểm chuẩn và các giả định chi phí cùng với quyết định triển khai.

Khi API mô hình là lựa chọn triển khai đám mây tốt hơn

Vận hành trực tiếp GPU Nvidia H200 cho phép bạn kiểm soát trọng số mô hình, cấu hình phục vụ, vị trí dữ liệu và năng lực. Việc này cũng bổ sung công việc lập kế hoạch năng lực, xác thực cấu trúc liên kết, khả năng quan sát và khôi phục. Nếu các quyền kiểm soát đó không tạo ra lợi thế sản phẩm đáng kể, hãy giữ cho việc so sánh khách quan: đánh giá API mô hình được quản lý theo cùng các chỉ số về chất lượng, độ trễ, tính sẵn sàng và khối lượng công việc đã hoàn thành.

Flatkey có thể là một đường cơ sở như vậy cho các nhóm cần kiểm thử hoặc định tuyến qua các API mô hình chính thức mà không phải duy trì các tích hợp nhà cung cấp riêng biệt. Phần tổng quan sản phẩm của dịch vụ này mô tả một khóa API và một số dư dùng chung cho các mô hình và công cụ; lựa chọn đúng là lựa chọn đáp ứng yêu cầu khối lượng công việc của bạn với ít bề mặt vận hành không cần thiết nhất. Khám phá danh mục mô hình của Flatkey hoặc lấy khóa API khi API định tuyến phù hợp với khối lượng công việc hơn năng lực GPU chuyên dụng.

Các câu hỏi thường gặp

Dung lượng bộ nhớ của một GPU Nvidia H200 là bao nhiêu?

NVIDIA công bố mỗi GPU H200 có 141 GB bộ nhớ HBM3e, với băng thông bộ nhớ 4,8 TB/s. Đây là thông số cho mỗi bộ tăng tốc, vì vậy bạn vẫn cần một kế hoạch phục vụ phân tán nếu mô hình và bộ nhớ đệm đang hoạt động vượt quá dung lượng khả dụng của một GPU.

H200 chủ yếu là GPU suy luận hay GPU huấn luyện?

H200 được định vị cho cả khối lượng công việc AI và HPC. Khi lập kế hoạch triển khai, hãy phân biệt theo khối lượng công việc thay vì nhãn gọi: phục vụ LLM ngữ cảnh dài, tinh chỉnh, huấn luyện phân tán và tính toán khoa học tạo áp lực khác nhau lên bộ nhớ, truyền thông và việc lập lịch. Hãy đo điểm chuẩn với framework và cấu trúc liên kết mà bạn thực sự sẽ vận hành.

Sự khác biệt giữa H200 SXM và H200 NVL là gì?

Đây là các dạng thức H200 và các hướng tích hợp máy chủ khác nhau. NVIDIA liệt kê các hệ thống SXM có kết nối NVLink trong cấu hình kiểu HGX 4 hoặc 8 GPU, trong khi H200 NVL là dạng thức PCIe hai khe cắm với các tùy chọn cầu nối được tài liệu hóa. Hãy xác nhận cấu trúc liên kết thực tế của nhà cung cấp đám mây trước khi giả định hành vi đa GPU tương đương.

Tôi có thể chạy khối lượng công việc H200 trên Kubernetes không?

Có, miễn là cụm có trình điều khiển NVIDIA tương thích, đường dẫn runtime container và plugin thiết bị. Kubernetes lập lịch GPU dưới dạng tài nguyên mở rộng, còn NVIDIA GPU Operator có thể quản lý ngăn xếp phần mềm GPU và các thành phần đo từ xa. Hãy xác thực nhãn nút, yêu cầu tài nguyên GPU, tình trạng của operator và các SLO ở cấp ứng dụng trước khi gửi lưu lượng production.

Tôi có nên chọn H200 thay vì H100 không?

Hãy lựa chọn dựa trên điểm nghẽn. Dung lượng HBM3e lớn hơn và băng thông bộ nhớ được công bố cao hơn của H200 có thể hữu ích cho hoạt động phục vụ bị giới hạn bởi bộ nhớ, nhưng H100 vẫn có thể đáp ứng một khối lượng công việc nhỏ hơn với mức độ phù hợp hơn về vận hành hoặc thương mại. Hãy so sánh các dạng thức giống hệt nhau và chạy cùng một khối lượng công việc trên cả hai cấu hình. Hướng dẫn H200 so với H100 của chúng tôi cung cấp khung ra quyết định.

Đảm bảo quyết định triển khai có thể tái lập

Kiến trúc của H200 rất thuyết phục khi bộ nhớ và cấu trúc liên kết là các ràng buộc thực sự. Hãy giúp quyết định về GPU Nvidia H200 có thể tái lập bằng cách lưu cùng nhau hợp đồng khối lượng công việc, kế hoạch bộ nhớ, cấu trúc liên kết phần cứng, các phiên bản phần mềm và kết quả kiểm thử tải. Hồ sơ đó cho phép kỹ sư tiếp theo giải thích lý do triển khai hoạt động — và xác định điều gì đã thay đổi nếu nó ngừng hoạt động.

Để thực hiện các bước lập kế hoạch tiếp theo, hãy đọc hướng dẫn kiến trúc cụm GPU về thiết kế điện toán, mạng, lưu trữ và control plane, sau đó sử dụng hướng dẫn suy luận đa GPU vLLM để thiết lập song song tensor và pipeline.