Thiết lập hạ tầng và các script mã nguồn mở để huấn luyện mô hình 70B trên bare metal

 (imbue.com)
1 điểm bởi GN⁺ 2024-06-29 | 1 bình luận | Chia sẻ qua WhatsApp
  • Imbue, với một đội ngũ nhỏ, đã huấn luyện từ đầu một mô hình 70B tham số trên hạ tầng bare metal tự xây dựng và công khai quy trình vận hành cùng các script, từ thiết lập cụm đến khôi phục sự cố
  • Cụm gồm 4.088 GPU H100 và 511 máy chủ GPU, mỗi máy có 8 GPU tham gia huấn luyện đồng bộ quy mô lớn qua InfiniBand
  • Việc triển khai thực tế là quá trình lặp đi lặp lại giữa provision từng máy, chỉnh lý fabric InfiniBand, kiểm tra sức khỏe host, chẩn đoán lỗi huấn luyện và cải thiện tự động hóa; họ phải xử lý khoảng 10% máy khởi động thất bại cùng số lượng lớn cảnh báo cổng
  • Các công cụ được công khai gồm kiểm tra sức khỏe host, bản vá logging cho NCCL, bài kiểm tra tải GPU, kiểm tra mạng NVLink·InfiniBand, trình phân tích log sự kiện UFM và script tạo workload burn-in cho InfiniBand
  • Trong huấn luyện LLM quy mô lớn, chỉ một host hoặc liên kết không ổn định cũng có thể làm chậm toàn bộ tiến trình, nên kiểm tra sức khỏe tự động · cô lập sự cố · khởi động lại · vô hiệu hóa cổng trở thành cốt lõi của vận hành liên tục

Xây dựng cụm để huấn luyện mô hình 70B nội bộ

  • Imbue đã huấn luyện từ đầu một mô hình 70B tham số trên hạ tầng riêng trong nhiều tháng, và mô hình này vượt zero-shot GPT-4o trong các tác vụ liên quan đến suy luận
  • Phạm vi công bố bao trùm quy trình hạ tầng end-to-end, từ khởi động cụm ban đầu, cài đặt OS cho đến tự động khôi phục lỗi trong lúc huấn luyện
  • Các công cụ hạ tầng được công bố kèm theo gồm
    • Host-level health checks: script xác nhận host có thể được đưa vào huấn luyện mà không có lỗi đã biết
    • Bản vá NCCL: cải thiện để ghi lại nhiều log hơn khi xảy ra lỗi và treo
    • GPU stress test: kiểm tra GPU có thể cấp phát tensor lớn và thực hiện các phép toán tiêu chuẩn hay không
    • Networking tests: xác minh giao tiếp NVLink giữa các GPU trong cùng máy và giao tiếp InfiniBand giữa GPU ở các máy khác nhau
    • UFM event log parser: phân tích log sự kiện của Unified Fabric Manager để xác định các cổng mạng cần vô hiệu hóa
    • InfiniBand burn-in workload generator: tạo workload burn-in InfiniBand để gây tải lên tất cả các liên kết khả dụng

Cấu hình cụm và mạng

  • Cụm chính phân bổ 4.088 GPU H100 trên 511 máy chủ GPU, mỗi máy được trang bị 8 GPU
  • Lý do có 511 máy chủ GPU là vì một phần kết nối phải được dành riêng cho node Unified Fabric Manager (UFM) dùng để quản lý mạng InfiniBand
  • Mỗi GPU được kết nối trực tiếp với card ConnectX-7 và có thể đồng thời gửi/nhận ở tốc độ 400Gbps tới các GPU khác trong mạng InfiniBand thông qua card ConnectX-7 riêng của nó
  • Topology InfiniBand có cấu trúc fully non-blocking, cho phép về mặt lý thuyết mọi GPU đồng thời giao tiếp với GPU khác ở tốc độ tối đa
    • Kiến trúc switch InfiniBand 3 tầng cung cấp tổng thông lượng mạng
    • Giao tiếp huấn luyện được thực hiện trên InfiniBand chứ không phải Ethernet
  • Ethernet được dùng để truyền dataset, checkpoint và các dữ liệu khác
    • Nếu gửi giao tiếp huấn luyện qua Ethernet, dữ liệu phải đi từ GPU sang CPU rồi mới ra card Ethernet 100Gbps, nên chậm hơn nhiều
    • Cũng có thể huấn luyện trên Ethernet bằng RoCE, nhưng cần rất nhiều công việc bổ sung cả ở phần cứng lẫn phần mềm, và nhìn chung kém tin cậy hơn InfiniBand
  • Một mạng Ethernet quản trị riêng được dùng để truy cập BIOS, bộ nguồn và bộ điều khiển giao diện máy ở mức thấp
    • Nếu không có mạng quản trị này, họ sẽ phải cấu hình thủ công hàng trăm máy bằng USB, bàn phím và màn hình
  • Trong huấn luyện hiệu năng cao quy mô lớn, InfiniBand, Ethernet, GPU và node gần như phải hoạt động hoàn hảo
    • Chỉ một kết nối không ổn định trong hơn 12.000 kết nối cũng có thể làm chậm toàn bộ phiên huấn luyện

Provision từng máy riêng lẻ

  • Sau khi tạo kết nối Ethernet tới cụm bằng mạng quản trị ban đầu, họ thu thập thông tin xác thực để truy cập BMC (Baseboard Management Controller)
    • BMC là bộ xử lý dịch vụ dùng để giám sát host từ xa
    • Nó cung cấp trạng thái phần cứng, thiết lập BIOS và API quản lý nguồn điện
  • Máy chủ đầu tiên được cài Ubuntu 22.04 thủ công qua iDRAC, BMC của Dell
    • Họ có thể mount ảnh ISO từ máy tính cục bộ để khởi động, đồng thời sử dụng console ảo trên trình duyệt
    • Mục tiêu là biến lần cài thủ công này thành lần cài thủ công duy nhất trong toàn bộ quá trình

  • MAAS và khởi động PXE

    • Sau khi chuẩn bị máy đầu tiên, họ cài Ubuntu MAAS (Metal-as-a-Service) để provision các máy chủ còn lại
    • Họ dùng khởi động PXE và các công cụ iDRAC tự động để chỉ thị từng máy khởi động từ mạng
    • Máy chủ nhận IP từ MAAS qua DHCP, tải kernel ban đầu rồi tự động cài OS cố định ngay cả khi ổ cục bộ trống
    • Trên thực tế, tích hợp giữa MAAS và BMC không ổn định, nên họ thu thập trước địa chỉ MAC của toàn bộ máy qua API iDRAC
    • MAAS nhìn chung đáng tin cậy trong suốt quá trình huấn luyện, nhưng ở giai đoạn đầu có các vấn đề đặc thù do cấu hình
      • Chênh lệch đồng hồ quá lớn khiến xác thực chứng chỉ HTTPS thất bại và chặn cài đặt apt
      • Máy chủ MAAS đồng thời đảm nhận DHCP, DNS, HTTP proxy, NTP, quản lý cấu hình cloud-init và vai trò cơ sở dữ liệu chuẩn cho MAC · IP · hostname · metadata, nên rất khó lần ra nguyên nhân sự cố

  • Lỗi khởi động và khả năng quan sát cơ bản

    • Như thường thấy khi thiết lập cụm GPU quy mô lớn, khoảng 10% số máy khởi động thất bại, và nguyên nhân chủ yếu là các vấn đề vật lý của máy chủ
      • Cáp Ethernet chưa cắm hoặc đấu sai
      • Sự cố phần cứng iDRAC
      • Hỏng bộ nguồn
      • Ổ NVMe lỗi
      • Thiếu dây nối nội bộ
      • Không nhận card mạng hoặc GPU
    • Imbue đã tự động hóa việc kiểm tra các vấn đề này, chuyển một số máy sang để Dell kiểm tra lại và tạo các ticket cần thiết cho nhân viên trung tâm dữ liệu
    • Nhờ trực tiếp tự triển khai hạ tầng, họ có thể đưa ngay các máy hoạt động bình thường vào sử dụng trong khi chờ sửa chữa
    • Tất cả máy chủ đều được cài Docker, driver GPU cho datacenter, Prometheus node exporter, NVIDIA DCGM exporter và một ZFS pool RAIDZ trên toàn bộ các ổ ngoài ổ chứa OS
    • ZFS giúp máy vẫn hoạt động ngay cả khi một ổ đĩa bị hỏng, đồng thời nén trong suốt để giảm đáng kể dung lượng lưu trữ cho dataset văn bản thuần và log lặp lại
    • Khi cài đặt các gói phần mềm song song trên 400 node, họ gặp nút thắt băng thông
    • Cảnh báo nhiệt độ cao lần đầu xuất hiện ở nhiều thành phần trong bố trí trung tâm dữ liệu, và phần lớn vấn đề nhiệt ban đầu được giảm bớt bằng cập nhật firmware

  • Xác nhận huấn luyện GPU trên một node

    • Họ kiểm tra xem từng máy có thể tự xử lý workload GPU thực tế một cách độc lập hay không
    • Nhiều máy không vượt qua được bài kiểm tra huấn luyện GPU trên một node do các vấn đề sau
      • Các lỗi liên quan đến GPU phần lớn được giải quyết bằng cách gắn lại card vào khe
      • Trong log máy chủ Ubuntu, kết nối PCIe hiển thị là limited width: x4 < x16
      • Ngay cả sau khi cập nhật firmware cho bus switch PCIe, họ vẫn phải gắn lại cáp PCIe nội bộ trên khoảng một phần tư số host trong cụm
      • Có các ổ NVMe không bị đánh dấu là lỗi nhưng khi truy cập lại khiến toàn bộ máy bị treo
      • Thứ tự ổ đĩa trong Linux hiển thị ngẫu nhiên khiến MAAS cài OS vào sai ổ
      • Cảm biến nhiệt độ đọc sai làm quạt luôn quay ở 100%
      • CPU dynamic frequency scaling giới hạn các lõi đang hoạt động ở 2GHz
      • Không áp dụng được GDR, tức GPUDirect RDMA Peer Memory Client

Provisioning InfiniBand

  • InfiniBand có một chủ thể điều khiển duy nhất cho toàn bộ mạng nhờ thiết kế tập trung, và có thể xử lý 320 switch mạng như một fabric duy nhất
  • Công việc đầu tiên là xác định switch nào được nối với máy nào, đối chiếu với sơ đồ đi dây, rồi đổi tên switch theo vị trí vật lý

  • Thiết kế fabric sai và đi dây lại

    • Ban đầu UFM không phát hiện được 320 switch mạng và cũng không tìm thấy các host lẽ ra phải có trong fabric
    • Sau khi xác nhận với đối tác trung tâm dữ liệu, các switch đều đang bật và đã được đấu dây nhưng vẫn không bị phát hiện
    • Khi kiểm tra danh sách đấu dây mạng, hóa ra fabric cấp trên không phải là một fabric hợp nhất mà gồm 8 mạng tách biệt không có tuyến định tuyến chung
    • Sau khi đi dây lại, họ bổ sung bước kiểm tra để xác nhận mọi kết nối vật lý đều khớp với thiết kế mới

  • Cảnh báo nhiệt độ và lỗi cổng

    • Sau khi xử lý vấn đề đấu dây vật lý, UFM đã kết nối được với tất cả switch InfiniBand, nhưng gần như mọi cổng switch đều báo nhiệt độ quá cao
    • Ngay cả trước khi truyền dữ liệu thực tế, một số cổng đã vượt quá 70 độ C; nguyên nhân là khoảng trống giữa các switch trong rack mạng khiến khí nóng tuần hoàn trở lại mặt trước
    • Nhiều cổng có tỷ lệ lỗi cao hoặc xảy ra link flapping, tức liên tục chuyển qua lại giữa trạng thái bình thường và lỗi; vấn đề này chỉ xuất hiện khi cổng thực sự được sử dụng nên khó phát hiện trước
    • Toàn bộ fabric có 10.000 liên kết và độ dư thừa cao, nhưng khi khoảng 10% fabric có vấn đề thì các tính năng như adaptive routing cũng không thể né tránh đầy đủ các liên kết bị ngắt quãng thất thường
    • Đối tác trung tâm dữ liệu đã vệ sinh và gắn lại các cổng cảnh báo, đồng thời vô hiệu hóa các transceiver cảnh báo còn lại đang chờ thay thế
    • Trong giai đoạn này, họ chạy huấn luyện đa nút với 100–200 máy để tìm ra tập con InfiniBand ổn định

  • Burn-in InfiniBand và GPUDirect RDMA

    • Để chẩn đoán vấn đề InfiniBand hiệu quả hơn, họ tạo một workload đặc biệt để đẩy nhiều dữ liệu nhất có thể đồng thời qua mọi cổng của toàn bộ fabric
    • Cách này khác với việc chạy một all-reduce lớn trên toàn cụm
      • Vì NCCL tối ưu giao tiếp trong một nút đơn thông qua NVLink và đường socket SXM
    • UFM gửi cảnh báo rằng phần lớn cổng đang truyền dữ liệu vượt 97% dung lượng lý thuyết, và một số switch tạm thời bị crash
    • Đến cuối ngày, các cổng còn trụ được được xem là đủ vững; phần còn lại bị vô hiệu hóa hoặc chuyển sang diện sửa chữa sau đó
    • Họ bật GPUDirect RDMA để GPU có thể giao tiếp mà không cần CPU gánh overhead

  • Tập máy ổn định và bảo trì

    • Theo kinh nghiệm thực tế với cụm GPU phần cứng mới nhất, nên dự đoán khoảng 3% số máy hỏng mỗi tuần
    • Không phải mọi máy đều có xác suất hỏng 3% như nhau; một số máy nhiều vấn đề sẽ lặp đi lặp lại lỗi theo nhiều cách khác nhau
    • Khi đặt nhiều máy trong cùng một fabric, có thể mở rộng tập máy golden đã được biết là ổn định thay vì liên tục đuổi theo các sự cố ngẫu nhiên của từng máy
    • Việc bảo trì InfiniBand chủ yếu gồm xử lý cảnh báo UFM, thay cáp và transceiver, và chẩn đoán switch lỗi
    • Các đợt hồi quy quy mô lớn thường đến từ hai nguyên nhân
      • Một đợt nâng cấp firmware chỉ áp dụng cho một nửa cụm đã làm hỏng trạng thái UFM, khiến phải khởi động lại UFM trên mọi switch InfiniBand
      • Việc khởi động lại đồng loạt số lượng lớn hộp GPU làm bùng nổ cập nhật trạng thái UFM, khiến dịch vụ UFM phải khởi động lại

Hệ thống kiểm tra sức khỏe host

  • Imbue phát hiện nhiều kiểu lỗi đơn máy có thể làm tác vụ huấn luyện thất bại hoặc chậm đi, và đã viết các bài kiểm tra sức khỏe để xác định host có đủ khỏe cho huấn luyện hay không
  • Mã nguồn được công khai tại cluster-health
  • Nhiều bài kiểm tra được thiết kế riêng cho môi trường runtime của Imbue, nhưng mục tiêu là có một điểm vào duy nhất trả về yes/no về mức độ sẵn sàng cho huấn luyện

  • Kiểm tra sức khỏe nhanh

    • GPU Health Check: kiểm tra số lượng GPU, ECC có được bật hay không, lỗi ECC, topology NVLink và lỗi liên quan
    • Disk Space Health Check: kiểm tra mức sử dụng đĩa của host không vượt quá 95%
    • Docker Health Check: kiểm tra container gắn GPU có chạy hay không và quyền của các container giám sát, profiling
    • Dmesg Health Check: tìm lỗi Xid và SXid của GPU hoặc switch NVIDIA, đồng thời kiểm tra các dòng log dmesg có được phân loại vào danh sách log dự kiến hay không
    • iDRAC Health Check: kiểm tra lỗi iDRAC của máy Dell và bỏ qua các thông báo lỗi không nghiêm trọng
      • Bài kiểm tra này không nằm trong phạm vi phát hành mã nguồn mở
    • Disk Health Check: kiểm tra mount zpool, kết nối Docker, và việc CPU có bị treo khi truy cập đĩa hay không
    • InfiniBand Health Check: kiểm tra tốc độ tăng lỗi InfiniBand và firmware driver đã cũ
    • Nvlink Health Check: kiểm tra lỗi NVLink của máy
      • Theo kinh nghiệm thì không gây lỗi huấn luyện nhưng có thể làm chậm
    • GDR Health Check: kiểm tra GDR có được bật trên máy hay không
    • VBIOS Health Check: kiểm tra phiên bản GPU VBIOS và firmware baseboard H100 có phải mới nhất hay không
    • Flint Health Check: dùng flint và hca_self_test để kiểm tra driver Mellanox OFED, firmware card, phiên bản firmware transceiver và trạng thái biên dịch driver NVIDIA
    • PSB Health Check: truy vấn thiết bị PCIe để kiểm tra tốc độ và bề rộng kết nối giữa GPU, PSB và card mạng có khớp kỳ vọng hay không
      • Đây là script do Dell phát triển nên hiện chưa thể chia sẻ

  • Kiểm tra sức khỏe dài hơn

    • Khởi tạo phép tính ma trận bằng PyTorch để đo băng thông NVLink, tốc độ tính toán GPU và bộ nhớ
    • Bật cờ GDR để kiểm tra cả InfiniBand lẫn NVLink
    • Dùng ib_write_bw với --use_cuda để gửi dữ liệu tới card IB và đo băng thông PCIe cùng card InfiniBand
    • Chạy trong khoảng 15 phút để bắt các liên kết InfiniBand bị flapping
    • Chạy chẩn đoán đa nút để kiểm tra khả năng khởi tạo NCCL và việc treo ngẫu nhiên
      • Nếu treo, mã NCCL đã fork sẽ ghi thêm log
    • Vì có thể mất 12–24 giờ mới phát hiện được vấn đề, các bài kiểm tra này chủ yếu chạy với nút mới hoặc khi có tình huống đáng ngờ
    • Kiểm tra các sự kiện throttle xung nhịp GPU từ DCGM exports, nhưng loại trừ gpu_idle và power_cap là các trường hợp được dự đoán trước
    • Huấn luyện đa nút sử dụng đồng thời mọi GPU, card InfiniBand, CPU và đĩa là cách bộc lộ tốt nhất các sự kiện điện năng

Chẩn đoán các lỗi thường gặp trong quá trình huấn luyện

  • Crash ngay sau khi khởi động

    • Crash xảy ra ngay sau khi khởi động tương đối dễ tái hiện và lặp lại, nên là loại lỗi dễ xử lý nhất
    • Trước tiên cần kiểm tra xem phiên bản mã, cấu hình và biến môi trường có đúng hay không
    • Các lớp trừu tượng trung gian như cache image Docker hay thiết lập secrets thiếu minh bạch có thể làm mờ nguyên nhân gốc
    • Cũng cần kiểm tra xem mọi máy có đang online hay không, và có thể dễ dàng tổng hợp·kiểm tra stack trace cùng log hay không
      • Imbue sử dụng stack Loki, Prometheus, Grafana
    • Trong môi trường chạy phân tán đồng bộ, lỗi đầu tiên thường gây ra chuỗi lỗi dây chuyền không liên quan
    • Khi xây dựng hệ thống tự động chạy lại, việc tổng hợp log·lỗi trở nên quan trọng hơn để log và lỗi từ các lần chạy lại khác nhau không bị trộn lẫn
    • Các lỗi thường gặp gồm có
      • Forward order differs across ranks...: do đặc tính triển khai PyTorch FSDP, có thể khắc phục bằng cách chạy lại
      • CUDA out of memory...: giải quyết bằng cách kiểm tra cấu hình và mã, rồi rollback các thay đổi mã gần đây
      • CPU/RAM OOM: tốt nhất nên phát hiện qua log dmesg của host bên ngoài container, nơi cho biết OOM Killer đã được kích hoạt

  • Crash giữa chừng khi huấn luyện

    • Khi phần cứng đã bắt đầu hoạt động, ưu tiên trước hết là một hệ thống tự động khởi động lại sau khi chạy lại mọi health check chẩn đoán và loại trừ các host không khỏe
    • Các lỗi phần cứng ngẫu nhiên như Xid·SXid có thể làm tiến trình crash mà không có stack trace Python có ý nghĩa
    • Một số trường hợp như row remapping có thể phục hồi bằng cách khởi động lại, nhưng lỗi uncorrectable ECC thường cần bảo trì phần cứng hoặc thay linh kiện
    • Dữ liệu huấn luyện có định dạng đặc biệt xấu cũng có thể gây crash
      • Một tài liệu đơn lẻ quá lớn trong corpus có thể gây GPU hoặc CPU OOM
      • Sử dụng data loader hoàn toàn quyết định giúp dễ dàng liên hệ crash với số epoch hoặc step
      • Để kiểm tra có phải do dữ liệu hay không, có thể tắt data loading hoặc thay bằng dữ liệu giả toàn số 0
    • Các sự cố như Ethernet chập chờn hay hết dung lượng đĩa có thể không hiện ra bằng thông báo lỗi hữu ích, nên cần ghi lại các chỉ số trạng thái mạng và node để kiểm tra tương quan

  • Treo không có stack trace

    • Các lỗi treo hoặc timeout mà không có stack trace đặc biệt khó debug vì thiếu thông tin và khó tái hiện ổn định
    • Thông báo điển hình có dạng Watchdog caught collective operation timeout...
    • Nếu một hay nhiều host không hoàn thành tác vụ NCCL hoặc bị rơi khỏi kết nối NCCL·InfiniBand, thì mọi host còn lại sẽ bị chặn đồng bộ ở phép toán tensor đó cho đến NCCL_TIMEOUT
    • Do đặc tính của thư viện NCCL, rất khó tìm ra host nào là nguyên nhân
    • Imbue đã thêm các thay đổi logging vào NCCL fork để hiển thị rõ hơn các message hoặc tác vụ đang in-flight tại thời điểm crash và xác định host hoặc GPU gây lỗi
    • Để tìm host hoạt động sai, nhiều khi phải kiểm tra các host không tạo ra một thông điệp log cụ thể
    • Dùng Py-Spy và GDB để debug trực tiếp các tiến trình bị treo, từ đó phân biệt giữa treo NCCL, treo driver, và race condition·deadlock trong mã Python

Suy giảm tốc độ huấn luyện nhìn từ MFU

  • Hiện tượng chậm nói chung hoặc MFU (Model FLOPs Utilization) thấp hơn mức từng quan sát trước đó có thể đến từ nhiều nguyên nhân
  • Trước hết, việc kiểm tra lại cấu hình, mã và biến môi trường là hữu ích
    • Sai mô hình
    • Sai kích thước batch
    • Sai cấu hình UFM hoặc NCCL
    • Sai CUDA_DEVICE_MAX_CONNECTIONS
  • Việc đo MFU tức thời theo từng batch hữu ích hơn cho chẩn đoán loại vấn đề so với giá trị trung bình đã được làm mượt

  • Nguyên nhân theo từng mẫu MFU

    • Nếu MFU ổn định ở dưới 1/10 mức kỳ vọng ngay sau khi bắt đầu huấn luyện, thì thường là sự cố phần cứng InfiniBand như switch chết ở tầng T2 hoặc T3
      • Sự cố phần cứng giữa GPU và NIC cũng có thể là nguyên nhân, và sẽ hiện trong dmesg dưới dạng PCIe x16 lanes limited by ...
    • Nếu MFU ổn định ở mức 30% kỳ vọng ngay sau khi bắt đầu, có thể cấu hình GDR hoặc biến môi trường GDR trên một host bị sai
    • Nếu MFU ổn định ở mức 60~80% kỳ vọng ngay sau khi bắt đầu, nguyên nhân thường là liên kết InfiniBand bị suy giảm hoặc lỗi
      • Nếu NIC InfiniBand gắn với một GPU cụ thể bị lỗi, NCCL sẽ cố dùng NIC của GPU khác trên cùng host thông qua NVLink cục bộ
      • CPU throttling cũng có thể là nguyên nhân, khi đó cần điều chỉnh thiết lập BIOS của host tương ứng
    • Nếu mức sụt 10 lần xuất hiện đều đặn ở một batch đơn lẻ, thì gần như luôn liên quan đến checkpointing hoặc evaluation, và có thể xác minh bằng cách đối chiếu với số epoch·step
      • Nếu chỉ đặt cảnh báo tự động dựa trên bất thường MFU thì sẽ có nhiều false positive
    • Nếu mức sụt 10 lần ở một batch đơn lẻ xảy ra hiếm và ngẫu nhiên rồi phục hồi ngay, nguyên nhân thường là một workload nặng CPU được scheduler gán lên một trong các host đang chạy
      • Vấn đề mạng gián đoạn hoặc nút thắt ở data loader cũng có thể là nguyên nhân
    • Nếu đồ thị MFU giảm dần theo thời gian chạy rồi quay lại 100% sau khi khởi động lại, có thể xác minh bằng profiler Python và NVIDIA rằng nguyên nhân là garbage collection tự động
      • Khi tắt garbage collection tự động và thực hiện garbage collection theo chu kỳ xác định trên tất cả host, hiện tượng giảm throughput biến mất
    • Nếu hiệu năng ban đầu tốt nhưng sau đó thường xuyên tụt xuống 70% mức kỳ vọng, điều này có tương quan với các lý do clock throttle của GPU NVIDIA
      • Nguyên nhân là nhiệt độ GPU, quạt làm mát của host hỏng·suy giảm, hoặc nguồn điện bị lỗi
    • Nếu hiệu năng tốt nhưng có nhiễu tần suất cao lớn trong khoảng 90~100% MFU kỳ vọng, thì thường là sự cố phần cứng InfiniBand như suy giảm mức vừa ở tầng mạng trên hoặc link flapping

  • Các câu hỏi kiểm tra hồi quy throughput

    • Kiểm tra xem trước đây hệ thống đã từng chạy bình thường hay chưa
    • Kiểm tra xem gần đây có thay đổi gì như merge mã hay cập nhật driver hay không
    • Kiểm tra xem có đang chạy trên các host khỏe hay không, và các dịch vụ phụ thuộc như Docker Hub·GitHub có hoạt động hay không
    • Kiểm tra xem có đang chạy với cùng mã, môi trường, cấu hình, phiên bản, danh sách host, thứ tự rank và random seed như lần chạy gần nhất hoạt động bình thường hay không
    • Kiểm tra xem có thể tái hiện lỗi hay không
    • Kiểm tra xem có tương quan với các tiến trình khác, crontab hằng ngày, hay các chỉ số host·DCGM·UFM hay không
    • Kiểm tra xem công cụ đo chỉ số có chính xác hay không
    • Kiểm tra xem vấn đề có xảy ra cả trên phiên bản rút gọn của mã, như mô hình nhỏ hơn, dữ liệu giả, hoặc loại bỏ lưu·tải checkpoint hay không

Công cụ tự động hóa và cải thiện vận hành

  • Dù việc huấn luyện có thể khởi đầu với hiệu năng tốt, cuối cùng vẫn sẽ có thứ gì đó hỏng hóc, nên cần các công cụ và hệ thống để giảm thiểu sự can thiệp của con người
  • Imbue là một đội ngũ nhỏ nên không có đủ nhân lực để liên tục sửa chữa thủ công, vì vậy họ đã tự động hóa nhiều quy trình nhất có thể
  • Phần lớn các vấn đề trong quá trình chạy huấn luyện đều được thu hẹp về các máy bị lỗi hoặc thành phần mạng gặp trục trặc

  • Tự động loại trừ máy lỗi

    • Họ đã phát triển một hệ thống tự động khởi động lại các phiên chạy bị crash từ checkpoint mới nhất
    • Quá trình khởi động lại sẽ chạy health check trên tất cả các máy khả dụng và phân loại tình trạng sức khỏe của máy dựa trên kết quả kiểm tra đạt được
    • Sau đó chạy lại tác vụ huấn luyện trên các máy có tình trạng tốt nhất

  • Tự động xử lý thành phần mạng

    • Tất cả các lỗi thành phần mạng được quan sát đều được UFM phát hiện và ghi vào log sự kiện của UFM
    • Trong thực tế, chỉ một số ít trong hàng chục loại sự kiện là thực sự có vấn đề, và phần lớn liên quan đến link down hoặc symbol error count cao
    • Script sẽ phân tích log sự kiện UFM để vô hiệu hóa các link và port liên quan đến sự kiện gần đây, tạo ticket bảo trì, rồi kích hoạt lại sau khi sửa xong

  • Mirror hệ thống tệp cục bộ

    • Tốc độ Ethernet bên trong và bên ngoài cluster có thể trở thành nút thắt trong huấn luyện phân tán quy mô lớn
    • Kết nối Ethernet dùng chung khoảng 10Gbit/s sẽ nhanh chóng bão hòa khi hàng trăm worker cùng lúc tải dataset và model checkpoint
    • Imbue đã xây dựng một hệ thống tệp cục bộ trong cluster để mirror cloud storage, giúp giảm số lượng tệp cần lấy từ S3
    • Để đối phó với churn khi máy thường xuyên bị vô hiệu hóa hoặc thay thế, họ sao chép mỗi tệp thành 3 bản
    • Sử dụng consistent hashing để phân bổ tải đồng đều và giảm thiểu việc di chuyển tệp trong lúc churn
    • Do dung lượng đĩa hạn chế, họ cũng phát triển công cụ theo dõi vòng đời tệp và xóa các tệp không cần thiết

  • Docker registry phân tán cục bộ

    • Họ sử dụng Kraken để truyền Docker image
    • Kraken là phần mềm mã nguồn mở cho phép truyền Docker image theo kiểu peer-to-peer, và Imbue cho biết họ hầu như không gặp vấn đề gì

  • Giám sát hiệu năng và xác định host lỗi

    • Họ thiết lập Torch profiler và NVIDIA Nsight Systems
    • Nsight Systems hữu ích để xác định forward/backward pass và giao tiếp NCCL mất bao lâu
    • Điều này giúp đánh giá liệu nút thắt nằm ở giao tiếp hay tính toán dựa trên kích thước mô hình và số lượng worker
    • Việc sử dụng hơi khó khăn do yêu cầu Docker privileged mode, tắt các security check liên quan đến sự kiện giám sát hiệu năng, và phải tạm dừng huấn luyện để lưu profile
    • Họ cũng viết công cụ để phát hiện batch huấn luyện chậm và xác định nguyên nhân
      • Công cụ hữu ích nhất là theo dõi thời gian của từng batch, rồi dump stack trace của tất cả worker khi gặp một batch chậm bất thường
      • Nhờ đó dễ xác định các host cụ thể có vấn đề phần cứng hoặc phần mềm tinh vi
    • Trước khi health check đủ trưởng thành, ngay cả khi huấn luyện thất bại trên một tập hợp máy cụ thể thì vẫn không rõ máy nào là nguyên nhân
      • Ví dụ, nếu một nhóm 48 máy bị lỗi, họ sẽ tạo các phiên chạy nhỏ hơn theo 6 nhóm 8 máy hoặc 8 nhóm 6 máy
      • Những máy xuất hiện trong các nhóm lỗi ở cả hai bước sẽ được xem là máy có vấn đề với độ tin cậy cao

Nguyên tắc vận hành rút ra trong quá trình xây dựng

  • Nếu có nhiều hơn 10~20% số máy so với mức cần cho một phiên huấn luyện cụ thể, có thể dễ dàng chạy lại khi máy gặp lỗi
  • Nếu cấu hình mạng cluster để mọi máy đều được kết nối gần nhau, có thể sử dụng bất kỳ tập con hoạt động nào
  • Các lỗi phần cứng và phần mềm gặp trong quá trình huấn luyện sẽ tái diễn, nên rất đáng để viết test và giải pháp tự động hóa cho từng loại lỗi
  • Với mỗi thông báo lỗi khó hiểu, việc tạo ra công cụ dễ diễn giải hơn là rất hữu ích
  • Để đảm bảo khả năng tái lập, họ áp dụng quy tắc chỉ thay đổi một điều tại mỗi thời điểm, kể cả với những thay đổi đơn giản nhất
  • Khi đưa công cụ bên ngoài vào hoặc có người mới tham gia quy trình, cần xác minh lại các giả định, đặc biệt nếu các bước tiếp theo phụ thuộc vào kết quả đó
  • Toàn bộ quá trình đòi hỏi nhiều giám sát và lặp lại, nhưng yếu tố mang tính quyết định là họ có thể kiểm soát hoàn toàn hạ tầng và debug vấn đề ở mọi lớp trừu tượng

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-06-29
Các ý kiến trên Hacker News
  • Một nhóm nghiên cứu và kỹ thuật nhỏ đã huấn luyện từ đầu một mô hình 70 tỷ tham số trên hạ tầng tự vận hành trong vài tháng, và vượt zero-shot GPT-4o ở các tác vụ liên quan đến suy luận.
    Để dùng cụm máy tự xây cho huấn luyện hiệu năng cao, mọi thành phần từ InfiniBand, Ethernet, GPU đến node đều phải hoạt động hoàn hảo; chỉ một trong hơn 12.000 kết nối không ổn định cũng có thể làm chậm toàn bộ quá trình huấn luyện.
    Họ đã công bố các script mã nguồn mở và hướng dẫn từ đầu đến cuối để thiết lập hạ tầng; đây là một phần trong bộ ba toolkit huấn luyện mô hình 70 tỷ. Các công cụ đánh giá và tối ưu siêu tham số CARBS có thể xem tại đây: https://imbue.com/research/70b-intro/
    • Chi tiết thật sự rất hay, và đây là lần đầu tôi thấy một bài viết cho thấy kỹ đến vậy về mặt nội bộ các công việc kỹ thuật đằng sau một mô hình như thế này.
      Tôi có hai điều tò mò. Thứ nhất, nếu huấn luyện một mô hình 400 tỷ tham số thì điều gì sẽ khác đi? Nhìn toàn cụm thì có vẻ đủ bộ nhớ video, nhưng tôi muốn biết đánh giá thực tế.
      Thứ hai, tôi tò mò liệu họ có xem kiến trúc kiểu này là hình thái cuối cùng của việc huấn luyện mô hình không. Nó trông quá mong manh; tôi muốn biết liệu có cơ chế hay kiến trúc huấn luyện chia sẻ tốt hơn, hoặc cấu trúc cụm tốt hơn hay không.
    • Tôi tò mò không biết thế giới 3D giống Minecraft mà nhóm đang làm đã ra sao rồi. Họ đã đổi hướng à?
    • Phần “vượt zero-shot GPT-4o” khá thú vị. Không biết mô hình này đã làm đến RLHF chưa, hay chỉ mới tiền huấn luyện?
      Nếu là trường hợp sau thì tôi muốn biết họ đã thắng GPT-4 bằng cách nào.
    • Câu nói rằng chỉ một trong hơn 12.000 kết nối không ổn định cũng có thể làm chậm toàn bộ huấn luyện khá đặc biệt, nên tôi đã nghĩ “hình như mình từng thấy câu này trước đó”.
      Thực tế có vẻ câu này và phần lớn bài viết đã được đăng gần như nguyên văn trên Twitter, LinkedIn, Reddit; vậy chỉ là spam thôi à?
      https://x.com/imbue_ai/status/1805629547473518695
      https://reddit.com/r/learnmachinelearning/comments/1dobgbs/t...
      https://www.linkedin.com/posts/mattboulos_training-a-70b-mod...
  • Nếu nói “511 máy tính với 4.092 GPU H100, 8 GPU mỗi máy” thì hiểu rằng riêng GPU đã hơn 100 triệu USD có đúng không?
    Tôi tò mò bao nhiêu phần trong số này, và vào khoảng khi nào, sẽ lọt vào phạm vi của những lập trình viên hobbyist với ngân sách của một PC gaming.
    • Khá thú vị là họ chi 100 triệu USD cho GPU nhưng vẫn phải loay hoay với các máy Dell có cổng Ethernet lỗi.
      Nghe các vấn đề họ gặp phải cũng vui.
    • Có vẻ đúng. Họ đã huy động 200 triệu USD từ NVIDIA, có lẽ thuần túy dưới dạng GPU: https://news.crunchbase.com/ai-robotics/new-ai-unicorn-imbue...
    • Nếu riêng GPU đã hơn 100 triệu USD, thì có lẽ phần lớn độc giả không có nguồn vốn cỡ đó nên chuyển sang bài HN tiếp theo.
  • Thật sự rất ấn tượng. Cisco mới hợp tác với NVIDIA và ra thiết bị cung cấp 800G mỗi cổng, nhưng tôi không nhớ có phải RoCE không.
    Ở đây có vẻ GPU có thể truy cập InfiniBand, cấu trúc này đẹp thật. Đây là một trong những bài thực sự hữu ích trực tiếp.
  • Vài ngày trước podcast Latent Space cũng đã nói về nội dung này: https://www.latent.space/p/llm-training-2024
    Đó là một tập hay, đáng nghe để biết cơ sở vì sao những quyết định như vậy được đưa ra.
    • Tôi không quen kiểu phỏng vấn này nên cảm thấy hơi vượt quá năng lực. Nếu có câu hỏi nào lẽ ra nên hỏi mà đã bỏ sót, mong mọi người gợi ý.
  • Tôi tò mò về tổng mức tiêu thụ điện để tạo ra mô hình. Muốn biết có số liệu nào tính cả điện năng và làm mát không.
    Zuckerberg nói trên podcast rằng họ đang lên kế hoạch cho mô hình 1GW tiếp theo, về cơ bản có nghĩa là một data center gắn với một nhà máy điện cỡ vừa, nên tôi càng tò mò hơn.
  • Bài viết rất có giá trị và tôi học được nhiều khi đọc. Mã nguồn mở mà họ công bố cũng tuyệt vời.
    Tôi có vài điều tò mò. Vì sao họ tự xây cụm máy, trải nghiệm làm việc với đối tác cloud và xử lý thiết bị hoặc switch lỗi như thế nào.
    Ngoài giao tiếp all-to-all, họ coi trọng điều gì nhất khi chọn kiến trúc cụm và điều gì thực sự có giá trị nhất; hạ tầng logging ra sao ngoài việc dựa trên Loki; vì sao cần Docker registry cục bộ; và ngoài nvidia-container-runtime thì họ có dùng image nào khác không.
  • Hỏi thật lòng: vì sao ở đây lại trộn nhiều phần cứng PC đến vậy?
    Không thể gắn GPU vào backend PCI và InfiniBand, rồi chỉ dùng một bộ điều khiển điều phối ARM rất nhỏ để chúng phối hợp với nhau sao? Tôi không rõ đây là quán tính từ thiết kế cũ, hay vì thị trường thiếu các bộ điều khiển GPU chuyên dụng.
    • Nếu ý bạn là hỏi vì sao phải trả thêm chi phí cho CPU và RAM, thì không thể làm mọi việc trên GPU. Ví dụ có việc giải nén .png.
      Nếu thật sự phân tích mã huấn luyện và tiền xử lý dữ liệu rất nhiều, có thể dùng tài nguyên CPU/RAM rất nhẹ, nhưng vì GPU đắt nên CPU/RAM chỉ chiếm tỷ trọng nhỏ trong chi phí toàn hệ thống; do đó không nhất thiết phải bỏ thời gian phát triển để tối ưu đến mức đó.

Nếu là một nhà cung cấp đám mây siêu quy mô, rất có thể họ cũng sẽ theo đuổi mức hiệu quả chi phí 0,x% như vậy. Ví dụ, có thể họ sẽ muốn tiền xử lý .png thành .webp (không mất dữ liệu, đa luồng) hoặc .jpeg (có mất dữ liệu), nhưng việc chuyển sang định dạng mà GPU có thể giải nén có thể giảm chi phí CPU trong khi huấn luyện, song lại làm tăng chi phí lưu trữ và truyền tải, nên nhiều khả năng không phù hợp
Nói chính xác hơn, nếu tác vụ CPU là nút thắt của quá trình huấn luyện thì cần tối ưu hết mức bằng tiền xử lý dữ liệu và điều chỉnh script huấn luyện. Điều đang nói ở đây là khoảng cách giữa “đủ nhanh” và “nhanh hơn”: CPU không đủ nhanh cho huấn luyện < CPU vừa đủ nhanh cho huấn luyện < CPU nhanh hơn mức cần thiết cho huấn luyện

  • Nếu mỗi máy chứa 250.000 USD GPU, thì việc băn khoăn để tiết kiệm vài nghìn USD phần cứng điều khiển là ngớ ngẩn. Rủi ro khi dùng cấu hình phần cứng mới là quá lớn
    Một vấn đề khác là phần cứng, driver và kinh nghiệm vận hành liên quan đến GPU đều nằm ở phía PC. Nếu muốn chạy trên ARM thì gần như phải bắt đầu lại từ đầu, và cũng cần rất nhiều công sức bổ sung để ổn định. Rốt cuộc là phải trả một cái giá lớn chỉ để tiết kiệm chút ít chi phí bộ xử lý
  • Việc liên tục nạp dữ liệu cho GPU là một công việc khá khó trong huấn luyện deep learning
    Tôi không có kinh nghiệm với LLM/NLP, nhưng với workload hình ảnh và âm thanh, đôi khi ngay cả CPU 4–8 lõi thông thường cũng khó tận dụng hết GPU RTX 2/3/4xxx. Không khó để CPU hoặc I/O trở thành nút thắt
  • 4.092 GPU H100 — quy mô thật lớn
    Họ nói đang làm “self-coding”, tôi tò mò không biết nó gần với giải pháp no-code hay low-code hơn
    Trên website cũng có khá nhiều bài viết đáng quan tâm: https://imbue.com/our-work/
  • Tôi tò mò chi phí đã tốn bao nhiêu. Từ con số không đến các file mô hình có thể sử dụng, nếu cộng tất cả chi phí phần cứng, thời gian phát triển, điện và làm mát thì khoảng bao nhiêu?
  • Tôi tò mò liệu rất nhiều lập trình viên làm vì sở thích có thể cùng nhau huấn luyện mô hình theo cách phân tán như seti@home hay folding@home không
    Những dự án như vậy có đặc điểm là có thể chia công việc thành các gói tác vụ khá độc lập, nhưng tôi không rõ việc huấn luyện mô hình có thể chia như thế không
    • Nhiều khả năng là không ổn. Trong số các lập trình viên làm vì sở thích, hầu như không có, hoặc hoàn toàn không có, trường hợp nào có thể đảm bảo thông lượng mạng 400Gbps giữa các GPU của nhau