Kiến trúc Cụm GPU: Compute, Network, Storage và Control Plane

Kiến trúc cụm GPU là hình thái của toàn bộ hệ thống, chứ không chỉ là số lượng GPU. Một cụm production phải phối hợp các node compute, mạng tốc độ cao, storage, scheduler, kiểm soát truy cập, telemetry và các đường khôi phục trước khi có thể biến các accelerator đắt tiền thành các lần huấn luyện hữu ích hoặc suy luận đáng tin cậy.

Câu hỏi thực tế rất đơn giản: đội ngũ của bạn có thể di chuyển dữ liệu, lập lịch job, khôi phục lỗi và đo chi phí đủ nhanh để giữ cho GPU luôn bận không? Nếu không, một cụm có card tốt hơn vẫn có thể cho hiệu quả kinh tế tệ hơn so với một dịch vụ GPU managed nhỏ hơn hoặc API model.

Hướng dẫn này cung cấp cho các đội nền tảng AI một mô hình làm việc cho kiến trúc cụm gpu: phần nào thuộc lớp compute, mạng cần chứng minh điều gì, storage và checkpointing phù hợp ra sao, Kubernetes hoặc Slurm trở thành control plane như thế nào, và cần kiểm thử gì trước khi thuê hoặc mua năng lực multi-node.

Nguyên tắc thực tế của Flatkey là bắt đầu từ ranh giới workload. Nếu sản phẩm chỉ cần đầu ra của mô hình, hãy benchmark trước một đường đi GPU cloud vs model API. Nếu bạn cần custom weights, kiểm soát placement, training chạy dài, hoặc hạ tầng serving riêng tư, thì hãy thiết kế cụm GPU xoay quanh các yêu cầu về compute, network, storage và control plane của workload.

Câu trả lời nhanh về kiến trúc cụm GPU

Một cụm GPU hữu ích có bốn lớp:

Một kiến trúc cụm gpu multi-node thành công khi các lớp này được thiết kế cùng nhau. Compute không có fabric là năng lực bị cô lập. Fabric không có storage chỉ chuyển bottleneck đi nơi khác. Kubernetes không có quota, telemetry và runbook thì chỉ là cơ chế khởi chạy.

Sơ đồ kiến trúc cụm GPU

Hãy dùng sơ đồ này như một khung review trước khi so sánh nhà cung cấp hoặc phê duyệt thiết kế rack.

                  người dùng / CI / lưu lượng sản phẩm / client API
                                  |
                                  v
        +------------------------------------------------------+
        | control plane                                        |
        | Kubernetes hoặc Slurm scheduler, queues, quotas,     |
        | secrets, truy cập registry, policy, telemetry, bill |
        +------------------------------------------------------+
              |                    |                    |
              v                    v                    v
   +-------------------+   +-------------------+   +-------------------+
   | gpu compute node  |   | gpu compute node  |   | gpu compute node  |
   | GPUs, CPU, RAM,   |   | GPUs, CPU, RAM,   |   | GPUs, CPU, RAM,   |
   | local NVMe, NICs  |   | local NVMe, NICs  |   | local NVMe, NICs  |
   +-------------------+   +-------------------+   +-------------------+
              \                  |                  /
               \                 |                 /
                v                v                v
        +------------------------------------------------------+
        | high-speed fabric                                   |
        | NVLink/NVSwitch trong node; InfiniBand, RoCE, EFA, |
        | hoặc Ethernet giữa các node; placement và routing   |
        +------------------------------------------------------+
                                  |
                                  v
        +------------------------------------------------------+
        | storage và data path                               |
        | object store, shared filesystem, local scratch,      |
        | model cache, checkpoints, snapshots, backups        |
        +------------------------------------------------------+

Đối với một sơ đồ kiến trúc cụm gpu kubernetes, hãy bổ sung các đối tượng đặc thù của Kubernetes xung quanh control plane:

cluster admins -> node images -> GPU Operator / device plugin -> GPU nodes
app teams      -> namespace -> quota -> job queue -> Pod / Job / RayJob
finance        -> labels -> usage export -> cost per job / team / model
security       -> secrets -> image policy -> network policy -> audit logs

Sơ đồ này cố ý rất giản dị. Mục tiêu không phải là vẽ mọi dịch vụ. Mục tiêu là phát hiện các trách nhiệm còn thiếu trước khi cụm trở thành một phụ thuộc production.

Bắt đầu từ workload, không phải từ rack

Trước khi chọn Kubernetes, Slurm, một gói đặt chỗ cloud, hay một nhà cung cấp bare-metal, hãy viết một bản tóm tắt workload dài một trang.

Nếu bạn không thể điền bảng này, thì chưa nên ký hợp đồng dung lượng dài hạn. Hãy thuê một phần nhỏ hơn, chạy benchmark, và biến log thành bản tóm tắt mua sắm. GPU cluster rental guide cung cấp checklist phía bên mua khi hình dạng kiến trúc đã rõ.

Compute plane: các node GPU không thể hoán đổi cho nhau

Compute plane xác định một job thực sự có thể dùng gì. Một đặc tả compute đầy đủ không chỉ là "8x H100" hay "B200 cluster."

Yêu cầu:

• Model GPU, dung lượng bộ nhớ, và PCIe so với SXM khi liên quan.
• Số GPU mỗi node và topology nội bộ của node.
• Model CPU, số lượng CPU, RAM hệ thống, và bố cục NUMA.
• Dung lượng local NVMe và thông lượng kỳ vọng.
• Số lượng NIC, tốc độ NIC, và liệu có hỗ trợ các đường dẫn GPU-direct hay không.
• Vòng đời driver, CUDA, container runtime, và image hệ điều hành.
• Chính sách MIG, vGPU, chia sẻ thời gian, hoặc cấp phát full-GPU.
• Tính đồng nhất của node và chính sách thay thế.

Topology nội bộ của node rất quan trọng vì tám GPU trong một server không tương đương với tám node, mỗi node một GPU. Thiết kế node quyết định áp lực bộ nhớ, điểm nghẽn CPU, tốc độ staging cục bộ, và mức độ đắt đỏ của giao tiếp liên node.

Tài liệu NVIDIA GPU Operator cho Kubernetes rất hữu ích ở đây vì nó cho thấy driver, NVIDIA Container Toolkit, device plugin, DCGM telemetry, và các thành phần liên quan có thể được quản lý như một stack của cluster thay vì cài đặt lẻ từng node. Tài liệu Kubernetes device plugin giải thích điểm mở rộng tổng quát dùng để hiển thị thiết bị của nhà cung cấp như các tài nguyên có thể lập lịch.

Network plane: chứng minh fabric bằng benchmark

Huấn luyện multi-node và serving throughput cao phụ thuộc vào network. Một đặc tả cluster nên nêu rõ fabric và bài kiểm tra chấp nhận, không chỉ con số bandwidth quảng cáo.

Yêu cầu:

• Chi tiết NVLink hoặc NVSwitch nội bộ node.
• Thiết kế InfiniBand, RoCE, EFA, hoặc Ethernet liên node.
• Số lượng NIC và tốc độ mỗi node.
• Cam kết placement và failure domain.
• Tỷ lệ oversubscription.
• Hỗ trợ GPUDirect RDMA khi liên quan.
• Mô hình networking của container và host.
• Khả năng quan sát lỗi fabric, retransmit, tắc nghẽn, và lỗi node.

Hãy dùng một bài kiểm tra chấp nhận trước khi cam kết bắt đầu:

network acceptance test:
  run NCCL all_reduce across every rented node
  record bandwidth, latency, node IDs, GPU model, driver, CUDA, NCCL version
  repeat after installing the production container image
  save logs and compare them with the provider's quoted topology

NVIDIA NCCL và các bài test NCCL là các tham chiếu tiêu chuẩn để xác thực hành vi giao tiếp collective trong workload GPU phân tán. Mấu chốt không phải là theo đuổi một con số benchmark. Mấu chốt là phát hiện node không khớp, placement kém, tắc nghẽn fabric, hoặc lệch driver/container trước khi một lần huấn luyện đầy đủ thất bại.

Với inference, bài test network nên bao gồm đúng đường đi lưu lượng thực tế: ingress yêu cầu, giao tiếp model shard, hành vi KV-cache khi liên quan, lấy dữ liệu từ storage, và egress. Một fabric phục vụ huấn luyện có vẻ mạnh khi đứng riêng lẻ vẫn có thể tạo ra độ trễ người dùng kém nếu stack serving đi qua quá nhiều ranh giới mạng.

Storage plane: giữ dữ liệu, trọng số, và checkpoint ra khỏi đường tới hạn

Storage là nơi nhiều kế hoạch kiến trúc GPU cluster trở nên đắt đỏ. Báo giá GPU thì nhìn thấy được. Đường đi dữ liệu thường bị ẩn cho đến lần chạy production đầu tiên.

Thiết kế storage xoay quanh bốn luồng:

Đối với huấn luyện, thông lượng checkpoint và thời gian khôi phục là vấn đề kiến trúc, không phải chi tiết sao lưu. Đối với inference, việc nạp trọng số mô hình, làm ấm cache cục bộ, và hành vi persistent volume ảnh hưởng đến thời gian triển khai và thời gian failover.

Tài liệu GPUDirect Storage của NVIDIA là một nguồn tham khảo hữu ích khi kiến trúc đòi hỏi một đường dữ liệu trực tiếp giữa bộ nhớ lưu trữ cục bộ hoặc từ xa và bộ nhớ GPU. Không phải cụm nào cũng cần GPUDirect Storage, nhưng các nhóm di chuyển tập dữ liệu lớn hoặc checkpoint nên quyết định rõ ràng liệu tầng lưu trữ là thông thường, được tối ưu, hay là một nút thắt mà họ chấp nhận.

Control plane: Kubernetes, Slurm, hay cả hai?

Control plane biến phần cứng thành một nền tảng. Nó quyết định ai có thể chạy gì, khi nào job bắt đầu, cách thử lại khi xảy ra lỗi, và cách các nhóm hiểu mức sử dụng.

Kiến trúc cụm GPU Kubernetes

Kubernetes phù hợp với các nền tảng GPU cần triển khai dịch vụ, namespace đa thuê, quy trình làm việc gốc container, tự động hóa dựa trên API, chính sách, và tích hợp với khả năng quan sát kiểu cloud-native. Một kubernetes gpu cluster architecture production thường bao gồm:

• Image node và tự động hóa bootstrap.
• GPU Operator hoặc quản lý driver/device plugin theo từng nhà cung cấp.
• Device plugin hoặc Dynamic Resource Allocation để hiển thị GPU.
• Namespace, RBAC, secret, image pull policy, và network policy.
• Jobs, Deployments, RayJob, training operator, hoặc các dịch vụ inference.
• Kueue hoặc một lớp xếp hàng khác khi tính công bằng cho batch là quan trọng.
• Quota theo nhóm, dự án, môi trường, hoặc khách hàng.
• DCGM, Prometheus, logs, traces, và nhãn billing.
• Admission control cho image, workload đặc quyền, host mount, và chia sẻ GPU.

Device plugin của Kubernetes hiển thị GPU như các extended resource. Kubernetes Dynamic Resource Allocation bổ sung một mô hình tài nguyên dựa trên claim phong phú hơn cho thiết bị và các tài nguyên chuyên biệt khác. Kueue bổ sung các khái niệm xếp hàng job như workloads, queues, cohorts, và resource flavors cho lập lịch batch và AI/ML. Kết hợp lại, các công cụ này có thể biến một pool GPU thành một nền tảng có quản trị thay vì một tập máy có thể truy cập qua SSH.

Kiến trúc cụm GPU Slurm

Slurm phù hợp với nhiều môi trường kiểu HPC và nghiên cứu vì nó được xây dựng xoay quanh queue, partition, accounting, reservation, và batch job. Tài liệu GRES của Slurm bao quát tài nguyên GPU và cách job yêu cầu chúng.

Slurm thường là lựa chọn mạnh khi:

• Người dùng gửi các batch training job.
• Chính sách queue là trọng tâm.
• Các nhóm đã có kinh nghiệm vận hành HPC.
• Workload ít thiên về dịch vụ hơn.
• MPI, bài test NCCL, và batch accounting là các nguyên tử vận hành quen thuộc.

Một số tổ chức vận hành cả hai: Slurm cho nghiên cứu và các hàng đợi training lớn, Kubernetes cho dịch vụ inference và API nền tảng. Cách này có thể hoạt động, nhưng chỉ khi nhận dạng, truy cập dữ liệu, khả năng quan sát, và phân bổ chi phí được thiết kế xuyên suốt cả hai hệ thống.

Khả năng quan sát và kiểm soát chi phí phải nằm trong thiết kế đầu tiên

Đừng thêm telemetry sau khi cụm đã hoạt động. Những câu hỏi quan trọng đối với kỹ thuật và tài chính là có thể dự đoán được:

• Job nào đã dùng GPU nào?
• Namespace, nhóm, khách hàng, model, hay thử nghiệm nào gây ra chi phí?
• Mức sử dụng hữu ích là bao nhiêu, chứ không chỉ là thời gian GPU được cấp phát?
• Đã mất bao nhiêu thời gian chờ trong queue?
• Lỗi nào làm tiêu tốn nhiều GPU-hour nhất?
• Nút thắt lưu trữ hoặc mạng nào khiến GPU nhàn rỗi?
• Chi phí cho mỗi lần chạy hoàn tất hoặc mỗi đầu ra được chấp nhận là bao nhiêu?

Telemetry tối thiểu nên bao gồm:

• Mức sử dụng GPU, mức sử dụng bộ nhớ, điện năng, nhiệt độ, và các sự kiện ECC.
• Thời gian chạy từng job, thời gian chờ queue, số lần thử lại, lý do thoát, và chủ sở hữu.
• Tình trạng sức khỏe fabric mạng và lịch sử benchmark.
• Throughput lưu trữ, độ trễ, thời gian checkpoint, và thời gian khôi phục.
• Các sự kiện cấp phát của scheduler và các từ chối do quota.
• Nhãn billing hoặc xuất dữ liệu sử dụng gắn với các đơn vị kinh doanh.

Baseline model/API của Flatkey có ý nghĩa ở đây. Nếu một managed model API tạo ra cùng một đầu ra được chấp nhận với chi phí đơn vị rõ ràng hơn và gánh nặng vận hành thấp hơn, thì cụm phải vượt qua baseline đó sau khi tính đến thời gian nhàn rỗi, lần thử lại, lưu trữ, và nhân công.

Bảo mật, cô lập, và thiết kế truy cập

Các cụm GPU thường bắt đầu như một dự án kỹ thuật và trở thành hạ tầng dùng chung. Hãy coi thiết kế truy cập là một phần của kiến trúc.

Xác định:

• Xác thực và nguồn danh tính.
• Cô lập theo namespace, dự án, hoặc tài khoản.
• Chính sách SSH, nếu có.
• Registry image container, ký và quét image.
• Quản lý secret.
• Chính sách egress mạng.
• Xóa dữ liệu và dọn dẹp sau job.
• Thời gian lưu trữ audit log.
• Quyền truy cập khẩn cấp.
• Quyền truy cập hỗ trợ của nhà cung cấp và quy trình remote hands.

Đối với cụm đa thuê, hãy quyết định liệu có cho phép chia sẻ GPU hay không. Phân bổ nguyên GPU đơn giản hơn. MIG, vGPU, hoặc time-slicing có thể cải thiện mức sử dụng, nhưng chúng cũng thay đổi kỳ vọng về cô lập, telemetry, lập lịch, và hiệu năng.

Định cỡ cụm: biến kiến trúc thành con số

Việc định cỡ nên được dẫn dắt bởi đơn vị hữu ích:

required_gpu_capacity =
  target_work_completed_per_month
  / useful_work_per_gpu_month_after_failures_idle_and_retries

Sau đó kiểm tra sức chịu tải của nó:

Để xây dựng mô hình chi phí, hãy liên kết bài viết này với bảng tính TCO cụm GPU của bạn:

effective_cluster_unit_cost =
  (compute + network + storage + support + operations + idle + retries)
  / accepted workload units

Mẫu số nên khớp với sản phẩm: các lần huấn luyện hoàn tất, token suy luận được chấp nhận, job tạo media, cập nhật chỉ mục tìm kiếm, hoặc yêu cầu của khách hàng.

Danh sách kiểm tra rà soát kiến trúc

Hãy dùng danh sách kiểm tra này trước khi phê duyệt multi node gpu cluster architecture diagram hoặc báo giá từ nhà cung cấp.

Các tài liệu chính thức nên mở sẵn

Hãy dùng tài liệu chính thức làm nguồn kiểm tra trong quá trình rà soát kiến trúc:

Hãy xem các tài liệu này như tham chiếu kiến trúc, không phải sự thay thế cho kiểm thử chấp nhận trên chính xác cụm mà bạn sẽ vận hành.

Khi cụm GPU là kiến trúc sai

Đừng xây dựng hoặc đặt trước cụm chỉ vì giá GPU-hour có vẻ hấp dẫn. Một cụm GPU trực tiếp có thể là kiến trúc sai khi:

• Sản phẩm chỉ cần đầu ra của model.
• Tổ hợp model thay đổi hàng tuần.
• Nhóm không thể vận hành driver, scheduler, storage, networking và sự cố.
• Workload có tính bùng nổ và sử dụng thấp.
• Di chuyển dữ liệu chiếm ưu thế so với compute.
• Bộ phận mua sắm muốn cam kết ba năm trước khi có bằng chứng benchmark.
• Tài chính không thể ánh xạ chi tiêu của cụm sang đầu ra được chấp nhận.

Trong những trường hợp đó, hãy so sánh trước giá thuê GPU cloud, serverless GPU hoặc model API. Kiến trúc đúng là kiến trúc mang lại đầu ra được chấp nhận một cách ổn định với tổng chi phí vận hành thấp nhất, chứ không phải kiến trúc có lượng accelerator lớn nhất. Để quét thị trường ở cấp nhà cung cấp, hãy dùng so sánh GPU cloud trước khi yêu cầu báo giá.

Kết luận cuối cùng

Một kiến trúc cụm GPU vững mạnh là một thiết kế hệ thống: các nút compute phù hợp với khối lượng công việc, hạ tầng mạng đã được kiểm chứng bằng benchmark, bộ lưu trữ không làm GPU bị thiếu dữ liệu, và một control plane có thể lập lịch, bảo mật, quan sát và phân bổ chi phí sử dụng.

Đối với các thử nghiệm nhỏ, hãy bắt đầu với thuê dịch vụ hoặc các API được quản lý. Với huấn luyện đa nút nghiêm túc hoặc suy luận riêng tư, hãy sử dụng sơ đồ và danh sách kiểm tra ở trên trước khi cam kết với một nhà cung cấp, một rack, hoặc một gói đặt trước. Sai lầm tốn kém không phải là chọn Kubernetes thay vì Slurm, hay H100 thay vì H200. Sai lầm tốn kém là mua năng lực GPU trước khi kiến trúc chứng minh được rằng nó có thể biến năng lực đó thành công việc hữu ích.