Huấn luyện LLM từ con số không tại startup
(yitay.net)- Reka xây dựng hạ tầng huấn luyện mô hình ngôn ngữ và đa phương thức quy mô lớn từ trạng thái hoàn toàn mới; so với việc bảo đảm compute, độ chênh lệch chất lượng cluster và sự bất ổn trong vận hành mới là nút thắt lớn hơn
- Ngay cả với cùng GPU H100, tùy nhà cung cấp và cluster, các vấn đề như lỗi node, lỗi cabling, lỗi GPU, nghẽn I/O và hệ thống tệp, checkpoint bị xóa, giao hàng chậm có thể chồng chất, tạo ra tình huống giống như xổ số phần cứng
- Khác với trải nghiệm dùng TPU và hạ tầng nội bộ của Google, trong môi trường GPU bên ngoài, khác biệt về huấn luyện multi-node, dây nối và chất lượng hỗ trợ rất lớn, khiến MFU và downtime thay đổi mạnh theo từng cluster
- Họ phải chấp nhận vận hành nhiều cluster, di chuyển dữ liệu khối lượng lớn và các ràng buộc từ codebase bên ngoài; Reka chuyển sang nền tảng PyTorch và tự xây dựng monitoring, checkpoint hiệu quả, hệ thống tệp tùy chỉnh
- Do compute hạn chế, thay vì scaling có hệ thống kiểu Big Tech, họ phải dựa vào một số ít thí nghiệm ablation ngắn, có kiểm soát và các Yolo run; nhờ đó đã tạo được Reka Flash 21B và mô hình edge 7B
Xây dựng hạ tầng huấn luyện từ trạng thái sạch
- Khi huấn luyện một mô hình ngôn ngữ đa phương thức mạnh, Reka đã xây dựng mới hạ tầng cần thiết để huấn luyện từ đầu các mô hình ngôn ngữ và đa phương thức quy mô lớn
- Khó khăn cốt lõi không phải là chọn TPU hay GPU, mà là đảm bảo được chất lượng vận hành đủ để việc huấn luyện thực tế chạy ổn định trong môi trường hạ tầng và code bên ngoài
Xổ số phần cứng trong kỷ nguyên LLM
- Điều kiện đầu tiên để huấn luyện mô hình là bảo đảm compute, nhưng trên thực tế, độ chênh lệch giữa nhà cung cấp, cluster và chất lượng kết nối accelerator mới là biến số lớn nhất
- Ngay cả với cùng GPU H100, chất lượng toàn cluster khác nhau rất lớn; phần cứng được nói tới ở đây gần với chất lượng tổng thể của cluster hơn là bản thân chip
- Reka đã thuê các cluster quy mô từ hàng trăm đến hàng nghìn chip từ nhiều nhà cung cấp compute, với tình trạng dao động từ mức tương đối có thể xử lý đến mức cứ vài giờ lại thất bại
- Một số cluster có node thất bại theo chu kỳ ngắn vì vấn đề cabling hoặc lỗi phần cứng GPU
- Ngay cả các cluster của cùng một nhà cung cấp cũng khác nhau rất nhiều về độ vững chắc
- Dù có node ổn định, nếu I/O và hệ thống tệp kém, việc lưu checkpoint có thể timeout hoặc mức sử dụng cluster giảm mạnh
- Một số nguồn compute yêu cầu một tầng phần mềm hoàn toàn khác để chạy, khiến các nhóm mang theo codebase riêng phải chịu thêm chi phí migration
- Rất khó biết trước sẽ nhận được phần cứng nào, trải nghiệm sẽ vững chắc và chịu lỗi đến đâu
- Nếu nhà cung cấp không giao đúng hạn, có thể bị trễ nhiều tháng, và cũng có thể xảy ra tình huống không thể mua được từ nguồn khác trong nhiều tuần hoặc nhiều tháng
- Một số nhà cung cấp thậm chí còn vô tình xóa checkpoint
Công cụ nội bộ cho MFU và ứng phó sự cố
- Model Flop Utilisation(MFU) thay đổi theo từng cluster, và khi gặp node bị cabling sai hoặc vấn đề từ nhà cung cấp, một lượng compute không thể xem nhẹ bị lãng phí
- Trong môi trường hệ thống tệp cực kỳ kém hiệu quả, chỉ cần ai đó bắt đầu truyền dữ liệu dung lượng lớn giữa các cluster cũng có thể làm MFU của phiên huấn luyện giảm mạnh
- Mức hỗ trợ của nhà cung cấp cũng rất khác nhau
- Có nơi hỗ trợ lịch sự, có nơi phản hồi thờ ơ
- Cũng có phản hồi kiểu “ChatGPT style” theo mẫu, hoặc quy mọi vấn đề là lỗi của người dùng
- Mỗi cluster có những nỗi đau và failure mode riêng, tạo cảm giác như mỗi cluster đều cần hotfix riêng
- Để tạo ra môi trường có thể sử dụng, Reka đã xây dựng nhiều công cụ nội bộ
- Công cụ monitoring
- Checkpoint hiệu quả
- Nhiều tối ưu hóa
- Cài đặt hệ thống tệp tùy chỉnh để lưu trữ dữ liệu có khả năng mở rộng
- Tổ hợp công cụ này giúp giảm downtime và cải thiện MFU một cách đáng kể ngay cả trên phần cứng tệ
Khác biệt giữa trải nghiệm GPU và TPU
- Reka huấn luyện mô hình chủ yếu bằng GPU
- So với trải nghiệm chủ yếu dùng TPUs để huấn luyện mô hình ngôn ngữ quy mô lớn tại Google, CUDA và nccl là môi trường xa lạ
- Tỷ lệ lỗi GPU khác rất nhiều so với trải nghiệm dùng TPUs tại Google
- UL2 20B của Google từng vô tình tiếp tục chạy trong một tháng nhưng không thất bại
- Họ cho rằng nếu là môi trường GPU thì nó đã thất bại trong vài ngày đầu
- Tuy nhiên, khác biệt này có thể liên quan nhiều hơn đến năng lực của đội phần cứng quản lý accelerator và chất lượng hỗ trợ của nhà cung cấp, hơn là bản thân chip
- Huấn luyện multi-node trong môi trường GPU không có cảm giác coi huấn luyện phân tán là khái niệm hạng nhất như TPU pod, mà giống như một thành phần được gắn thêm sau
- Cách đi dây cho phép huấn luyện multi-node dường như khác nhau tùy nhà cung cấp, và sự khác biệt này làm tăng độ chênh lệch theo địa điểm
Gánh nặng vận hành đa cluster
- Hạ tầng nội bộ của Google là môi trường có thể truy cập từ mọi nơi dựa trên Borg, Xmanager, Colossus
- Trong môi trường bên ngoài, họ phải tự cấu hình môi trường mới trên nhiều cluster, rất khác với trải nghiệm trước đây
- Trừ khi tự xây dựng một pool accelerator quy mô lớn ở một địa điểm, việc phải dùng pool accelerator của nhiều cluster dường như là không thể tránh khỏi
- Tình trạng thiếu GPU khiến việc mua sắm tự nhiên chuyển thành dạng cluster phân tán
- Huấn luyện mô hình quy mô lớn cần dữ liệu ở mức hàng chục TB, nên bản thân việc di chuyển dữ liệu đã là một gánh nặng lớn
- Ở quy mô rất lớn, việc sao chép dữ liệu cũng không đơn giản và tốn kém
- Hình thái lý tưởng là một tầng orchestration gửi job đến nhiều server, nhưng với một startup mới và gọn nhẹ, rất khó có hạ tầng huấn luyện ML tinh vi như vậy ngay từ đầu
- Reka đã giảm nhẹ vấn đề bằng nhiều workflow nội bộ và đang tiếp tục tiến tới hạ tầng thử nghiệm đẳng cấp thế giới
- Họ nói rằng đã nghe rằng cấu hình scrappy kiểu này nhìn chung khá phổ biến ở những nơi không thuộc nhóm hàng đầu hoặc các công ty lớn
Codebase bên ngoài và lựa chọn PyTorch
- Codebase họ ưa thích là T5X và Mesh Tensorflow, nhưng ở Reka đó không phải lựa chọn thực tế
- Không được hỗ trợ nhiều bên ngoài Google
- Đã ở trạng thái deprecated ở một mức độ nào đó
- Không thân thiện với những người trong nhóm không xuất thân từ Google
- Reka chọn PyTorch, vốn gần với vanilla hơn, trông ổn định hơn và được dùng rộng rãi
- Ban đầu họ phải thích nghi với môi trường phát triển bên ngoài như pip, git, docker
- Cũng có khả năng khó dùng codebase của Google một cách ổn định và thân thiện với người dùng ở bên ngoài
- Họ cảm thấy chất lượng codebase bên ngoài thua khá xa những codebase quen thuộc tại Google
- Họ cho rằng codebase nội bộ của Google thường do chính các nhà nghiên cứu ML như Noam Shazeer, Barret Zoph, Adam Roberts, Hyung Won Chung viết
- Trong số code do các công ty khác tạo ra, có những trường hợp chất lượng code đặc biệt gây bất mãn
- Ở một số codebase, để thay đổi cấu hình song song hóa mô hình, họ phải viết converter riêng, và thay đổi song song hóa không được cung cấp tự động
- Hỗ trợ cho huấn luyện encoder-decoder quy mô lớn hoặc huấn luyện prefixLM cũng thiếu
- Dù có nhu cầu hợp lý trong GitHub issue, flash attention được nói là vẫn không cung cấp hỗ trợ huấn luyện prefixLM, tức là custom mask
- Họ nhận thức rằng nên dùng Jax, nhưng để di chuyển nhanh trong startup, họ chọn PyTorch
Compute hạn chế và Yolo run
- Scaling mô hình có hệ thống thường là cách chạy nhiều giai đoạn thí nghiệm từ mô hình nhỏ đến lớn như 1B → 8B → 64B → 300B, chọn phương án thắng rồi tiếp tục mở rộng
- Ở startup, họ thiếu compute hơn nhiều để thực hiện các sweep quy mô lớn nhằm kiểm tra hyperparameter
- Reka phụ thuộc vào nhiều Yolo run, và cho rằng cuối cùng mọi thứ diễn ra tốt
- Chỉ với một số ít thí nghiệm ablation quy mô nhỏ hơn và ngắn hơn, họ đã đạt được Reka Flash 21B mạnh, mô hình edge 7B, và cả mô hình core lớn nhất sắp tới
- Việc tìm recipe tốt với số lần chạy hạn chế là khó, không gian tìm kiếm rất lớn nên phải thay đổi nhiều biến cùng lúc
- Thay vì tính hệ thống kiểu Big Tech, họ phải dựa nhiều vào Yolo, cảm giác và trực giác
- Trực giác mà các thành viên nhóm tích lũy từ sự nghiệp ML trước đây giúp họ chọn đúng trong số ít lần thử
- Ngay cả khi từng có kinh nghiệm huấn luyện mô hình tốt ở nơi làm việc trước, khác biệt về hạ tầng huấn luyện, dữ liệu, tích hợp ý tưởng mới và vấn đề môi trường vẫn có thể tạo ra khác biệt không nhỏ về kết quả
- Kinh nghiệm mạnh từ trước đã thu hẹp đáng kể không gian tìm kiếm, và có thể xem là một trong những lời giải thích dễ hiểu cho việc họ có thể huấn luyện mô hình mạnh với ít lần thử, tài nguyên và thí nghiệm
Kết quả trong chưa đầy một năm và các vấn đề còn lại
- Thiếu compute và nguồn cung compute không ổn định đã tạo ra khó khăn lớn hơn nhiều so với dự đoán
- Reka bắt đầu công ty, gọi vốn, mua chip rồi xây dựng mọi thứ từ con số không
- Họ nói rằng trong chưa đầy một năm, họ đã đạt mức ngang Gemini Pro/GPT-3.5 và vượt qua nhiều mô hình
- Pipeline dữ liệu và đánh giá bằng con người vẫn là các chủ đề còn cần bàn thêm
1 bình luận
Ý kiến trên Hacker News
Trong bối cảnh này, startup rốt cuộc trông giống một tổ chức có ít nhân sự và nguồn vốn lớn để chi cho cụm huấn luyện
Bài viết giả định rằng có nhiều nhà cho thuê máy chủ, và các máy chủ đó sẽ được chuyển đến nhiều startup hoặc doanh nghiệp hiện hữu
Rốt cuộc, nhiều bên làm LLM đang làm gần như cùng một việc: huấn luyện văn bản và hình ảnh trên phần cứng tương tự, với dữ liệu tương tự, rồi mỗi bên cố tạo khác biệt bằng “công thức bí mật” của mình
Những công thức bí mật đó có thể tạo khác biệt về chất lượng đầu ra của LLM, nhưng nhìn tổng thể thì đây giống một khối lượng công việc trùng lặp khổng lồ, tiêu tốn rất nhiều năng lượng
Cuối cùng chỉ một tỷ lệ rất nhỏ đạt được thành công ở mức vừa phải, nhưng đó là cái giá phải trả ở tuyến đầu của tiến bộ
Một độc quyền được lên kế hoạch có thể hiệu quả hơn, nhưng những cấu trúc như vậy hiếm khi thắng được thị trường về đổi mới
Có vẻ các nhà sáng lập chỉ hy vọng được mua lại vì họ có thể huấn luyện một LLM “gần đạt mức tiên tiến nhất”, và năng lực cùng hạ tầng ở mức đó có thể đủ giá trị để xây thứ gì đó lên trên
Chỉ là câu chuyện đó khó giải thích với nhà đầu tư hơn nhiều
Trên thực tế, có lẽ nhiều startup đang thuê nhà văn và nhiếp ảnh gia để tạo dữ liệu huấn luyện không bị nhiễm bẩn và được gắn nhãn cực kỳ tốt
Nhìn phía civitai có thể thấy chỉ với ngân sách tính toán nhỏ, việc gắn nhãn dày đặc có thể đưa bạn đi xa đến đâu
Phần lớn trường hợp sử dụng LLM có thể được hỗ trợ bằng cách tinh chỉnh mô hình nền tảng có sẵn
Nếu huấn luyện mô hình nền tảng từ đầu, tức là bạn bước vào một thị trường khó kiếm tiền; và chỉ cần một ông lớn tung ra một mô hình nền tảng mới, nó có thể làm hơn 95% những gì mô hình của bạn làm
Theo bối cảnh, Yi Tay từng là tech lead của Google PaLM, UL2, Flan, Bard, v.v., và hiện là đồng sáng lập Reka
Reka đã phát hành các mô hình đa phương thức cỡ nhỏ khá thú vị, từng được đăng ở đây
Vì anh ấy là người từ Google ra và đang ở vị trí huấn luyện LLM trong một startup độc lập, tôi đã đề nghị anh ấy viết bài này: https://twitter.com/YiTayML/status/1765105066263052718
Bản ghi âm cuộc trò chuyện ở đây: https://sub.thursdai.news/p/thursdai-feb-15-2024-openai-chan...
Nhờ bài viết này tôi biết đến reka.ai, và có vẻ LLM của Reka chưa được bàn nhiều trên HN [1]
Vì tò mò, trong một giờ vừa qua tôi đã dùng giao diện chat [2] để thử prompt và so sánh với ChatGPT 4, Gemini Advanced, Claude 3, Mistral Large, rồi đăng kết quả ở [3]
Nhìn chung Reka Flash có vẻ không tệ hơn hay tốt hơn đáng kể so với các mô hình khác
Tất nhiên để chắc chắn thì cần thử nghiệm nhiều hơn rất nhiều
[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
[2] https://chat.reka.ai/chat
[3] https://gally.net/temp/20240307llmcomparison.html
Cũng đáng lưu ý là tác giả cứ mặc nhiên cho rằng độc giả hiểu “vùng hoang dã” là những nơi không phải Google
Bài viết dành nhiều công lao cho đội hạ tầng và phần cứng của Google, nên tôi cũng muốn đọc góc nhìn của một người từng ở bên trong rồi sau đó làm việc liên quan ở nơi khác
Chính xác hơn thì gần như là “trong suốt sự nghiệp, tôi dùng TPU của Google bên trong Google và quen với kiểu hỏng của nó, nhưng hoàn toàn không biết kiểu hỏng của GPU”
Khi tôi chủ yếu dùng GPU rồi thử dùng TPU, các tác vụ cứ liên tục thất bại vì những lý do khó debug
Lớp gián tiếp giữa chip x86 và thiết bị TPU thường khiến tôi phải vò đầu bứt tóc hàng giờ, thuộc loại vấn đề không gặp với x86+NVIDIA+PyTorch
10–15 năm trước, Google đã sản sinh ra nhiều nhà khoa học dữ liệu trị giá hơn 10 triệu USD, tức các kỹ sư Sawzall, và khi họ ra “vùng hoang dã” họ cũng phản ứng tương tự
Bài này có vẻ thiên về việc người viết quảng bá công ty và thương hiệu cá nhân hơn là để lại một ghi chép hữu ích cho cộng đồng
Theo tôi, ngay cả trong huấn luyện quy mô lớn tôi cũng chưa từng gặp hỏng GPU
Job huấn luyện hiện tại là một file JSON 20GB chỉ riêng việc load đã mất 6 giờ, đã chạy hơn 15 ngày không vấn đề gì, và đang dùng Tesla T4 cũ hơn
GPU có vấn đề về giới hạn bộ nhớ, nhưng nếu có thể lập kế hoạch và né tránh thì thực tế tôi chưa từng thấy nó crash
Nó có vẻ là một ẩn dụ khá rõ ràng, và nếu là startup làm dự án hạ tầng quy mô lớn thì họ phải tự xây hệ thống logistics, giống như dựng trại giữa vùng hoang dã thật sự
Đọc giống cảnh Seven of Nine tách khỏi Collective và nhận ra mình phải dựa vào năng lực tầm thường của con người
Những insight về nhà cung cấp thì hữu ích
Chắc hẳn không mất toàn bộ tiến độ huấn luyện, vậy nỗi đau chủ yếu nằm ở việc chẩn đoán vấn đề và khởi động lại cụm, còn mất dữ liệu thì không cần lo đúng không?
Nhưng sản phẩm mà họ bán là gì?
Trang chính của Reka.AI trông giống một bản clone ChatGPT thông thường tính phí theo token
Tôi không rõ nó khác gì so với các công ty khác, và giá cũng có vẻ tương tự ChatGPT 3.5-Turbo
Vấn đề huấn luyện LLM từ đầu là một chủ đề cực kỳ quan trọng, có tác động đến tốc độ và phạm vi lặp lại của AI lớn không kém gì việc cải thiện phần cứng thô
Bài viết thú vị nhưng hơi nông; nếu từng làm việc với các cụm GPU dưới hình thức nào đó trong nhiều năm thì về mặt kỹ thuật nó không sâu sắc hay đáng ngạc nhiên lắm
Góc nhìn của một cựu Googler thì hay, nhưng tôi không rõ vì sao các đồng nghiệp cũ của họ lại khuyên dùng JAX hơn PyTorch khi làm LLM bên ngoài Google
Mong sau này công ty mới này sẽ công bố một báo cáo kỹ thuật hơn về hành trình huấn luyện của họ. Chẳng hạn như PDF ở đây: https://github.com/facebookresearch/metaseq/tree/main/projec...
Có lẽ cũng có phần thiên kiến Google trong đó
Câu hỏi lớn là: một startup nhỏ không có nền tảng và phả hệ đúng chuẩn sẽ gọi vốn bằng sản phẩm LLM như thế nào
Thế giới startup LLM đang dần giống với thế giới quỹ phòng hộ và quỹ đầu tư tư nhân
Điều kiện tiên quyết để gọi vốn seed và huy động vốn có vẻ là A) lý lịch danh giá và đúng phả hệ, B) mạng lưới nhà đầu tư vững chắc sẵn sàng nhảy vào ngay cả trước khi sản phẩm bắt đầu
Có lẽ đó cũng là lý do các VC đầu tư vào những công ty kiểu này
Trên toàn thế giới, số người có kinh nghiệm phù hợp để gọi vốn là rất hạn chế, và chỉ những người gọi được vốn mới có thể tích lũy được kinh nghiệm đó, nên tự nhiên hình thành rào cản gia nhập
Ít nhất thì có vẻ sẽ như vậy cho đến khi chi phí tính toán đủ rẻ
Khi đọc đoạn “lập công ty, gọi vốn, mua chip, và trong chưa đầy một năm xây dựng mọi thứ từ con số 0, đạt ngang Gemini Pro/GPT 3.5 và vượt qua nhiều mô hình”, tôi tò mò quy mô ngân sách họ đã chi cho chip hoặc GPU đám mây để đạt đến mức LLM ngang GPT 3.5
Liệu ước chừng theo bậc độ lớn có phải khoảng 2–5 triệu USD không?
Tôi nghĩ tiêu đề lẽ ra nên là “from the ground up” hơn là “ground zero”: https://en.wikipedia.org/wiki/Hypocenter
Là thành ngữ thì cách dùng này hoàn toàn chấp nhận được
Có thể ý nói LLM là một quả bom hạt nhân theo nghĩa ẩn dụ đối với ngành công nghệ, nhưng nói thật tôi cũng thấy bối rối
Tôi không muốn học hỏi từ kiểu tác giả như vậy
Lý do hệ thống của Google ổn định là vì Google đã đầu tư hàng chục tỷ USD trong 25 năm vào phát triển phần cứng, phần mềm và quy trình cho trung tâm dữ liệu
Ngay cả một đội ngũ rất giỏi trong một tổ chức nhỏ hơn và kém trưởng thành hơn cũng sẽ luôn buộc phải tạo ra kết quả có chất lượng thấp hơn nhiều
Một điều khác cần cân nhắc là ưu tiên
Google ưu tiên độ ổn định, và sẽ loại bỏ các linh kiện hỏng lặp lại, kể cả khi lỗi tương đối hiếm
Các trung tâm dữ liệu nhỏ hơn, kém tinh vi hơn thì vẫn tiếp tục dùng các linh kiện hay hỏng, hoặc thậm chí không theo dõi tỷ lệ hỏng của từng linh kiện
Các trung tâm dữ liệu nhỏ đôi khi còn mua và dùng các linh kiện cũ của Google cùng những linh kiện có độ tin cậy thấp
Vì vậy, việc máy móc không ổn định không nói lên năng lực của đội phần cứng
Nếu độ ổn định thấp của phần cứng làm chậm công việc, thì có thể cải thiện phần mềm để chịu được phần cứng bất ổn, hoặc chuyển sang nhà cung cấp phần cứng ổn định hơn và đắt hơn