- Để pretraining mô hình giải quyết bài toán sử dụng máy tính, dự án đã tự xây dựng cụm lưu trữ ngay tại trung tâm San Francisco với mục tiêu lưu trữ dữ liệu video tương đương 90 triệu giờ
- Chọn phương án on-premises, qua đó có thể vận hành hạ tầng lưu trữ 30PB với chi phí $354k/năm (5 tỷ won). Nếu dùng AWS sẽ tốn $12m (17 tỷ won), tức tiết kiệm chi phí khoảng 34 lần
- Khác với đa số public cloud, hệ thống không ưu tiên tính sẵn sàng cao và toàn vẹn dữ liệu, mà áp dụng chiến lược chấp nhận mất dữ liệu do đặc tính của dữ liệu huấn luyện
- Vận hành bằng phần mềm đơn giản dựa trên Rust và Nginx, và thay vì các hệ thống phức tạp như Ceph hay MinIO thì đang quản lý bằng chương trình tự viết chỉ 200 dòng
- Trong quá trình triển khai, nhóm đã trải qua nhiều va vấp thực tế và tích lũy kinh nghiệm thực chiến về bố trí vật lý, cấu hình mạng, quản lý cáp cùng nhiều vấn đề khác
Giới thiệu và bối cảnh
- Pretraining mô hình cho tác vụ sử dụng máy tính cần lượng lớn dữ liệu video
- Một LLM văn bản thông thường (ví dụ: LLaMa-405B) chỉ cần khoảng 60TB dữ liệu, nhưng huấn luyện dựa trên video đòi hỏi không gian lưu trữ lớn hơn 500 lần
- Nếu dùng public cloud như AWS thì chi phí hằng năm sẽ lên tới 12 triệu USD, nhưng bằng cách thuê trung tâm colocaton và tự triển khai, nhóm đã giảm mạnh xuống còn khoảng 354 nghìn USD
- Việc tự lưu trữ dữ liệu quy mô lớn đã giải quyết được nút thắt khi chi phí dữ liệu là rào cản lớn nhất
Vì sao tự xây dựng
- Cloud tập trung vào độ tin cậy cao, tính dư thừa, toàn vẹn dữ liệu, nhưng dữ liệu cho pretraining không quá quan trọng đến mức đó, thậm chí có thể chấp nhận mất 5%
- Nhờ đặc tính này, nhóm có thể chọn yêu cầu độ tin cậy lỏng hơn nhiều so với doanh nghiệp thông thường (áp dụng
2 nines thay vì 13 nines)
- Giá lưu trữ bị đẩy cao hơn rất nhiều so với chi phí thực tế
- Dữ liệu là hạng mục chi phí lớn nhất, và trong phạm vi đủ dễ dự đoán, nhóm đánh giá rằng xây dựng trung tâm dữ liệu cục bộ có lợi hơn
So sánh chi phí: cloud vs tự xây dựng
- Chi phí lặp lại hàng tháng: internet $7,500 + điện $10,000 = tổng $17,500
- Chi phí một lần: ổ cứng $300,000, chassis $35,000, node CPU $6,000, phí lắp đặt $38,500, nhân công $27,000, mạng và chi phí triển khai khác $20,000 → tổng $426,500
- Tính cả khấu hao (3 năm), chi phí cố định hàng tháng là $29,500
- AWS $1,130,000/tháng, Cloudflare R2 $270,000/tháng, tự xây dựng $29,500/tháng
- AWS: khoảng 38 USD/TB/tháng
- Cloudflare: khoảng 10 USD/TB/tháng
- Tự xây dựng: 1 USD/TB/tháng
- Trong huấn luyện mô hình quy mô lớn, ngay cả Cloudflare cũng gặp vấn đề rate-limit do tải nội bộ rất nặng, trong khi môi trường tự xây dựng giải quyết được bằng đường truyền riêng 100Gbps
Triển khai và quy trình
- Để triển khai nhanh, nhóm lập kế hoạch
Storage Stacking Saturday(S3), nhờ sự hỗ trợ của người quen xung quanh và các contractor chuyên nghiệp
- Trong 36 giờ, họ gắn 2.400 ổ cứng vào rack và hoàn thiện phần cứng 30PB
- Phần mềm gồm Rust (ghi, 200 dòng) + nginx (đọc) + SQLite (theo dõi metadata)
- Không dùng Ceph, MinIO, Weka, Vast do vấn đề độ phức tạp/chi phí (quá phức tạp, không cần thiết, gánh nặng bảo trì, v.v.)
- Tất cả ổ đĩa đều được format bằng XFS
Phản hồi từ dự án và bài học rút ra
Những gì làm tốt
- Áp dụng hợp lý đánh đổi giữa tính dư thừa và hiệu năng, nhờ đó gần như khai thác đầy đủ mạng 100G
- Triển khai ở vị trí gần về mặt địa lý để đảm bảo dễ debug và dễ bảo trì
- Tìm vendor trên eBay nhưng thực tế mua trực tiếp từ từng nhà cung cấp riêng, đồng thời nhấn mạnh sự cần thiết của warranty
- Đường truyền internet 100G mang lại nhiều lợi ích, và các vấn đề mạng cũng dễ tự debug hơn
- Quản lý cáp chất lượng cao giúp ích rất nhiều cho việc xử lý sự cố về sau
- Áp dụng nguyên tắc đơn giản hóa thay vì dùng hệ thống lưu trữ mã nguồn mở phức tạp, nhờ đó giảm tối đa gánh nặng bảo trì
- Dự đoán chi phí thời gian/nhân công cũng khá chính xác, và hiệu quả tiết kiệm được xác nhận rõ ràng
Điểm khó và những lần vấp váp
- Dùng front-loader khiến việc phải tự tay gắn từng ổ trong số 2.400 HDD trở nên rất phiền phức
- Mật độ lưu trữ chưa đủ cao; nếu thiết kế ban đầu chọn mật độ cao hơn thì có thể giảm đáng kể công sức
- Daisy chain gây nghẽn tốc độ; lý tưởng nhất là mỗi chassis có kết nối HBA riêng
- Linh kiện mạng đòi hỏi tính tương thích theo thương hiệu, đặc biệt là optical transceiver
- Tốn thời gian cho việc thử nghiệm/cấu hình mạng; thay vì DHCP/NAT, nhóm cấu hình theo hướng ưu tiên hiệu năng và sự tiện lợi (chỉ áp dụng yêu cầu tối thiểu cho firewall/secure link)
- Cảm nhận rõ tầm quan trọng của khả năng tiếp cận vật lý, cũng như việc đi dây màn hình/bàn phím khi setup
Các ý tưởng đáng thử
- Tận dụng KVM và IPMI để tăng hiệu quả quản trị từ xa
- Khuyến nghị cấu hình riêng một mạng Ethernet quản trị
- Overprovisioning mạng (ví dụ: thậm chí có thể cân nhắc mạng nội bộ 400G)
- Dùng server mật độ cao hơn (90-drive Supermicro/20TB HDD, v.v.) để
có lợi về số lượng rack, điện năng tiêu thụ, hiệu quả gom CPU, v.v.
Làm thế nào để tự xây dựng
Cấu hình lưu trữ
- 10 CPU head node (Intel RR2000, v.v.; khuyến nghị mỗi server dùng dual Intel Gold 6148/128GB ECC DDR4 RAM)
- Nếu dùng các tính năng ngốn CPU như ZFS thì có thể chọn phần cứng mạnh hơn
- 100 chassis DS4246 (mỗi chassis gắn 24 HDD)
- 2.400 HDD 3.5" (nếu có thể nên dùng ổ SAS để có lợi thế về tốc độ)
- Có thể kết hợp nhiều dung lượng khác nhau (12TB, 14TB, v.v.); dung lượng càng lớn càng có lợi về triển khai và giá trị hàng đã qua sử dụng
- Ray/bracket để lắp đặt vật lý, cùng dây dẫn và cáp cho thiết bị
- Nhiều crash cart để debug sự cố mạng (màn hình + bàn phím)
Hạ tầng mạng
- Switch 100GbE (ví dụ Arista hàng đã qua sử dụng, cổng QSFP28)
- HBA cho từng server (khuyến nghị: Broadcom 9305-16E, v.v.), cùng phương thức kết nối cổng HBA/chassis
- Card mạng (Mellanox ConnectX-4, v.v., bắt buộc ở chế độ Ethernet)
- Cáp DAC/AOC — nếu xét khoảng cách giữa các rack thì DAC có lợi thế về tương thích
- Khi mua CPU head node, nên dùng nhà cung cấp có thể lắp sẵn HBA/NIC
- Cáp serial, mạng Ethernet quản trị riêng (có thể thay bằng adapter không dây dự phòng + mini switch)
Yêu cầu trung tâm dữ liệu
- Công suất điện 3.5kW mỗi cabinet, giả định cấu hình 4U×10 + 2U×1 trên chuẩn 42U
- 3PB/cabinet, cùng 1 cabinet 42U dự phòng cho switch hoặc thay bằng chassis 1U
- Cross-connect riêng 100G (thường là một cặp quang QSFP28 LR4), cần kiểm tra trước khả năng tương thích về form factor và thương hiệu
- Khuyến nghị vị trí gần văn phòng (colocation) để có thể phản ứng vật lý nhanh khi có sự cố, từ đó tối ưu năng suất debug và vận hành
Mẹo thiết lập ban đầu
- Sau khi cấu hình local console lần đầu cho switch, hãy kiểm tra trước cấu hình cổng uplink 100GbE và khả năng tương thích của optical transceiver
- Khi cần, có thể nối trực tiếp đường quang của ISP vào NIC để xác nhận link-up rồi mới chuyển sang switch
- Trong lúc cài Ubuntu, thiết lập mạng cho node bằng Netplan sẽ thuận tiện hơn
- Sau khi node có kết nối internet, nên tiến hành theo thứ tự kết nối 1 cáp cho từng DS4246 → format/mount → kiểm tra trạng thái để phát hiện sớm lỗi đi dây hoặc đĩa hỏng
Lưu ý về hiệu năng, độ ổn định và bảo mật
- Với giả định bảo mật rằng đây là dữ liệu chỉ dành cho huấn luyện, hệ thống được vận hành đơn giản bằng IP công khai nối trực tiếp + firewall theo cổng + nginx secure_link
- Nếu xử lý dữ liệu khách hàng thì cấu hình tương tự là không phù hợp; khi đó DHCP/NAT/firewall phân đoạn chi tiết là bắt buộc
- Daisy chain giúp quản lý và đi dây dễ hơn nhưng gây nghẽn băng thông; nếu có thể thì khuyến nghị HBA riêng cho từng chassis
- Optical transceiver bị khóa thương hiệu rất nặng; nên kết hợp nguồn hàng từ FS.com và Amazon, đồng thời kiểm tra kỹ sự khớp nhau về thông số và thương hiệu
Kết luận và ý nghĩa
- Với lưu trữ tự xây dựng siêu rẻ ở mức $1/TB-tháng, dự án đã biến việc pretraining video 30PB thành khả thi, đồng thời đạt mức tiết kiệm chi phí 10–38 lần so với cloud
- Kiến trúc đơn giản và khả năng tiếp cận tại chỗ đã giảm thời gian và rủi ro, còn đường truyền riêng 100G giải quyết được nút thắt I/O
- Trong kỷ nguyên của các mô hình multimodal và video quy mô lớn, hạ tầng dữ liệu dung lượng lớn chi phí thấp là năng lực cạnh tranh cốt lõi, và cách tiếp cận này cung cấp một tham chiếu thực chiến có thể được triển khai chỉ với một nhóm nhỏ
Kết thúc và hướng dẫn hợp tác
- Nếu bạn đã xây dựng cụm lưu trữ tương tự dựa trên bài viết này, tác giả mong được chia sẻ thêm về điểm cải tiến và kinh nghiệm thực tế
- Nhóm đang tuyển nhân sự cho việc pretraining mô hình sử dụng máy tính quy mô lớn, cũng như nghiên cứu AI liên quan đến tổng quát hóa và gắn kết với giá trị con người (liên hệ: jobs@si.inc)
1 bình luận
Ý kiến Hacker News
Khi mới bắt đầu sự nghiệp, môi trường on-premises là điều hiển nhiên; phần cứng dùng bền thì cuối cùng cũng khiến người ta dồn nhiều công chăm sóc, và mỗi máy chủ lại tích lũy trạng thái riêng. Theo thời gian, khi phần cứng không còn đủ hiệu năng, phải chọn phần cứng mới từ danh sách có sẵn thông qua đội ngũ nội bộ rồi còn phải xin phê duyệt chi phí bổ sung nên khá phiền. Dự án cũng có lúc bị chậm vì quá trình thay phần cứng, hoặc vì phải tách bạch kỹ lưỡng những thiết bị đã được nâng niu như thú cưng để chuyển sang thiết bị mới. Khi cloud xuất hiện, tôi đã nghĩ “giờ thì cứ chuyển hết lên cloud”. Nhưng rồi theo thời gian, bản thân và tổ chức lại quên mất cách tự quản lý phần cứng, và đến lúc phải khôi phục lại kỹ năng đó thì lựa chọn từng rất tốt là cloud dần trở nên kém hấp dẫn hơn. Vì vậy cảm ơn vì đã giúp những kỹ năng này được nuôi lại.
Bọn tôi ở trong tình huống hơi đặc biệt. Ngay từ đầu đã không thể gánh nổi chi phí vận hành của hyperscale cloud, nên bất đắc dĩ phải tự phát triển năng lực nội bộ. Thực ra nó không khó như tưởng tượng, và trước mắt chúng tôi vẫn sẽ tiếp tục theo cách này. Dù vậy, vấn đề tích lũy trạng thái như bạn nói cũng bắt đầu thấy xuất hiện.
Trong ký ức của tôi, on-premises lúc nào cũng rẻ hơn. Nó cũng giúp loại bỏ nhiều rào cản logistics và mang lại sự tiện lợi của một hóa đơn duy nhất. Hồi cloud được tung hô, lời khuyên tôi luôn nghe là cứ dùng on-premises, chỉ dùng cloud khi lưu lượng tăng giảm đột ngột. Nhưng rồi việc mở rộng tạm thời dần biến thành sử dụng thường trực, và các lập trình viên bắt đầu phụ thuộc vào việc có thể dựng máy mới ngay lập tức. Giờ thì ai cũng xem cloud là trạng thái mặc định. Trong quá trình đó, chúng ta mất đi nền tảng để cảm nhận đúng chi phí thực tế, và khoảng cách chi phí giữa cloud với on-premises ngày càng nới rộng.
Docker là một công cụ tuyệt vời để biến máy chủ thành thứ không còn là “thú cưng”. Máy chủ trong rack chỉ đơn giản được coi là một node K3 hay K8 nữa thôi, nên không bị đối xử như thú cưng nữa. Tôi thực sự rất thích điểm này. Có thể nói điều tương tự về VM, nhưng cuối cùng bản thân VM lại trở thành thú cưng. Tất nhiên vẫn có thể tạo image hoặc snapshot, nhưng cảm giác thay đổi mà Docker mang lại thì khác hẳn.
Một câu hỏi đùa kiểu “hay là thử làm lại một lần nữa nhỉ”.
Một startup giàu đến mức có thể thản nhiên mua domain .inc hai ký tự thì là startup đang có quá nhiều tiền, giống hệt kiểu ngày xưa đếm xem văn phòng có bao nhiêu ghế Aeron vậy. Không phải tín hiệu tốt.
Domain .inc hai ký tự chưa dùng đang được bán với giá 2.300 USD mỗi năm, còn chưa tới 5% chi phí của một lập trình viên.
Tôi vẫn nghi ngờ liệu tên miền .inc có giá trị thực chất gì không.
Bài viết rất thú vị, đọc xong thấy được thỏa mãn gián tiếp. Nếu có thêm nhiều ảnh hơn thì sẽ còn vui hơn khi xem những trải nghiệm kiểu này.
Tôi thích vì bài viết mô tả chi tiết khía cạnh kỹ thuật. Có điều tôi tò mò không biết quá trình tìm chỗ colocation diễn ra thế nào, có dùng broker không, và sau khi đàm phán giá thì mức báo giá ban đầu khác bao nhiêu so với số tiền thực trả.
Bài blog Discord được dẫn link cũng khá thú vị. Phần lớn là nội dung nghiêm túc, nhưng cũng có đoạn vui thế này: khi có bàn thắng ở World Cup thì dữ liệu đó lập tức phản ánh lên biểu đồ giám sát, để cả đội có thể ngụy biện rằng họ xem bóng đá trong lúc họp là đang theo dõi hệ thống phục vụ công việc. Nó cũng được trích làm cơ sở cho mức sử dụng thực tế của hệ thống, kiểu như việc Discord lưu trữ tin nhắn với dung lượng “dưới petabyte”. Tôi đoán nếu tính theo kích thước và số lượng node trong bài này thì cluster cũ cỡ 708TB, còn thiết lập mới khoảng 648TB, có tính cả dư địa tăng trưởng.
Bản thân việc lưu trữ thì rất rẻ. Nhưng tôi không hiểu phần thiết lập training và networking. Tôi thấy ở bình luận khác có nói GPU không nằm cùng một chỗ, vậy thì dữ liệu huấn luyện chỉ có thể đi qua lại giữa nhiều site bằng 100Gbps. Tôi lo như vậy sẽ tạo nút thắt trong quá trình pretraining.
Với workload cỡ này thì hoàn toàn có thể xin báo giá riêng từ AWS hay các cloud khác. Chỉ riêng S3, ở mức 0,5PB cũng đã có thể nhận báo giá riêng rồi. Điều đó không có nghĩa là tổng chi phí chắc chắn rẻ hơn so với tự quản lý, nhưng so sánh giá retail của CSP với thiết bị mua trên eBay cộng với lao động miễn phí (trừ tiền pizza) thì chưa phải là so sánh trọn vẹn.
Phí egress của AWS hay cloud mới thực sự là mấu chốt. Chỗ đó dù có thử thương lượng cũng không hề được nhượng bộ. Với AI training thì gần như không thể dùng nổi. Báo giá từ Cloudflare thuộc nhóm rẻ hơn trong số các dịch vụ object bucket storage được quản lý, nên khi tự dựng cluster thì khoảng cách với dịch vụ managed đã thu hẹp đi. Tự triển khai cũng mang lại lợi thế đàm phán. Tuy vậy, managed bucket vẫn quá thừa tính năng nếu chỉ dùng làm storage cho pretraining. Glacier thì có hiệu quả chi phí tốt cho mục đích lưu trữ lưu trữ lâu dài, nhưng vẫn chưa có sản phẩm nào thật sự khớp cho ML.
Cụ thể thì có thể đạt được mức deal đến đâu? Liệu có thể giảm hơn một nửa không?
Tôi đã rất vui khi cùng lắp các ổ đĩa. Được trực tiếp xử lý lượng dữ liệu lớn thế này luôn là trải nghiệm phấn khích nhất :P
Không thấy nhắc đến tỷ lệ hỏng đĩa. Tôi tò mò không biết sau vài tháng thì tình trạng ra sao.
Đây là trải nghiệm tôi từng đăng trước đó: khi dựng nhiều disk array cùng lúc, đã có một đợt hỏng ổ đĩa hàng loạt. Chiều thứ Sáu tôi set up rack rồi để nguyên cả cuối tuần, chỉ chạy một shell script đơn giản để test đọc/ghi dữ liệu. Đến thứ Hai quay lại thì gần nửa số đĩa đã chết mà không để lại log nào. Không rõ là do có vấn đề trong quá trình striping, do stress test làm lộ lỗi, hay gì khác. Hóa ra đó là một lô lỗi từ nhà máy, nhiều khách hàng khác của cùng công ty đó cũng phàn nàn. Nhà sản xuất đã đổi toàn bộ, và chỉ khiến việc đưa vào production bị chậm lại thôi. Sau đó thì suốt một năm không có thêm sự cố nào.
So với 10 năm trước, tỷ lệ hỏng đĩa gần đây đã giảm rất nhiều. Trước kia có tuần tôi phải thay hơn 10 ổ, còn giờ thì đó là chuyện hiếm. Chỉ cần xem thống kê ổ cứng của Backblaze là đủ.
Họ nói cluster này dùng ổ enterprise, nhưng nếu tiết kiệm quá ở khoản đó thì về sau có thể thiệt hại lớn. Cá nhân tôi từng thử dùng ổ cũ cho home server và thấy độ lệch hiệu năng quá lớn nên không ổn lắm.
Ý hay đấy