Huấn luyện LLM mà không cần hệ thống tệp song song

Vào ngày 01 tháng 02 năm 2025, Jeff Denworth đã đăng một ý kiến đáng chú ý trên các nền tảng mạng xã hội, tuyên bố rằng việc huấn luyện các mô hình ngôn ngữ lớn (LLMs) không nhất thiết phải sử dụng các hệ thống tệp song song khổng lồ và đắt đỏ. bấm vào đây để xem bài viết

Là người đang làm việc trên một trong những siêu máy tính lớn nhất hành tinh – và hoàn toàn không sử dụng hệ thống tệp song song – tôi rất ngạc nhiên trước những phản ứng đầy hoài nghi và tò mò của mọi người. Dường như, trong tâm trí nhiều người, siêu máy tính và hệ thống tệp song song luôn đi cùng nhau, đến mức việc chạy một công việc tính toán song song quy mô lớn mà không có hệ thống tệp song song trở nên không thể tin được.

Tuy nhiên, hãy cùng nhau tìm hiểu cách mà những siêu máy tính không có hệ thống tệp song song vẫn hoạt động.

Khối lượng công việc

Dù việc huấn luyện mô hình trên các siêu máy tính GPU khổng lồ chính là tâm điểm, nhưng quy trình huấn luyện một LLM hoàn chỉnh phức tạp hơn nhiều. Hãy xem một bức tranh toàn cảnh về quy trình lưu trữ trong huấn luyện LLM tại SNIA SDC24. Tổng quát, việc huấn luyện LLM bao gồm các bước sau:

1. Thu thập dữ liệu ( Data ingestion): Crawler quét Internet và tải về dữ liệu thô (HTML, hình ảnh, video, v.v.). Sau đó, dữ liệu này được lập chỉ mục và đưa vào kho dữ liệu quy mô hàng trăm hoặc nghìn petabyte.
2. Xử lý dữ liệu (Data preparation): Dữ liệu thô được chuyển thành dữ liệu token hóa bằng các pipeline xử lý như Apache Spark, bao gồm lọc, loại bỏ trùng lặp, v.v. Dữ liệu được giảm quy mô đi 10x-1000x.
3. Huấn luyện mô hình (Model training): Huấn luyện mô hình: Đây là giai đoạn dữ liệu đã được token hóa được đưa vào mô hình LLM chạy trên các cụm GPU khổng lồ theo từng lô (batch) nhỏ. Khi dữ liệu được xử lý, các trọng số của mô hình sẽ được cập nhật và lưu lại thành các checkpoint trong hệ thống lưu trữ. Nếu một node tính toán gặp sự cố và quá trình huấn luyện bị gián đoạn, checkpoint sẽ được sử dụng để khôi phục, tương tự như cách các ứng dụng HPC khoa học truyền thống vận hành. Ngoài ra, có thể có quá trình tinh chỉnh (fine-tuning) hoặc các bước khác diễn ra.
4. Triển khai mô hình và suy luận (Model deployment and inferencing): Đây là giai đoạn mà mô hình cuối cùng được sao chép và triển khai trên các cụm máy chủ suy luận quy mô lớn. Một dịch vụ web đóng vai trò trung gian, tiếp nhận các yêu cầu REST API và chuyển đổi chúng thành các truy vấn suy luận chạy trên GPU. Mặc dù không phải là một phần của quá trình huấn luyện, nhưng đây vẫn là một bước quan trọng để mô hình có thể hoạt động trong thực tế.

Tại sao hệ thống tệp song song không mang lại lợi ích đáng kể?

Để hiểu tại sao hệ thống tệp song song không mang lại lợi ích đáng kể cho bất kỳ bước nào trong quy trình này, hãy cùng đi sâu vào từng bước cụ thể.

Thu thập dữ liệu

Quá trình thu thập dữ liệu (data ingestion) là một quy trình phân tán rộng rãi với yêu cầu tính toán tối thiểu. Điều quan trọng nhất là cần có kết nối mạng tốc độ cao và số lượng lớn CPU để điều khiển các tiến trình độc lập, thực hiện kết nối với các máy chủ HTTP công khai trên Internet. Đây không phải là một quy trình yêu cầu một siêu máy tính.

Trên thực tế, thu thập dữ liệu chỉ đơn giản là lấy nội dung HTML, hình ảnh hoặc luồng video từ Internet và đóng gói chúng vào các container dữ liệu. Trong quá trình đóng gói này, một hệ thống chỉ mục riêng biệt cũng được xây dựng để lưu trữ các siêu dữ liệu của trang web (URL, mã hóa, ngày truy cập) và vị trí của nội dung trong container dữ liệu (tệp chứa và byte offset trong tệp đó). Hàng nghìn máy ảo có thể thực hiện các nhiệm vụ này một cách độc lập mà không cần phải đồng bộ hóa lẫn nhau. Chính vì vậy, thay vì tập trung tất cả trong một trung tâm dữ liệu, việc phân tán các bộ thu thập dữ liệu trên toàn thế giới có thể hiệu quả hơn.

Mặc dù có thể lưu trữ từng trang HTML đã quét dưới dạng tệp trong một hệ thống tệp song song, nhưng việc truy cập các tệp này sẽ cực kỳ chậm. Một lần quét toàn bộ dữ liệu sẽ yêu cầu đọc hàng trăm tỷ tệp nhỏ. Do đó, thay vì triển khai các container dữ liệu bằng hệ thống tệp và lập chỉ mục bằng cấu trúc thư mục của hệ thống tệp, cách tiếp cận tối ưu hơn là triển khai các container dữ liệu trên hệ thống lưu trữ đối tượng (object storage) và sử dụng kho khóa-giá trị phân tán để lập chỉ mục. Bản chất của dữ liệu thu thập được là ghi một lần (write-once) và không cần đến các tính năng như khóa tệp (file locking) hay read-modify-write, khiến cho hệ thống lưu trữ đối tượng trở thành lựa chọn tối ưu nhờ vào tính bất biến của dữ liệu (immutability).

Xử lý dữ liệu

Khi dữ liệu thô đã được lập chỉ mục và lưu trữ trong object storage, giai đoạn tính toán đầu tiên sẽ bắt đầu. Phần lớn quá trình này bao gồm các pipeline xử lý dữ liệu kiểu Apache Spark, thực hiện phân tích dữ liệu song song một cách đơn giản.

Các pipeline này được xây dựng dựa trên những nguyên tắc từ thời kỳ Hadoop, với mô hình truy cập dữ liệu phù hợp với hệ thống object storage. Mỗi tác vụ xử lý có thể đọc hàng trăm MB dữ liệu từ một object, xử lý trong bộ nhớ, và ghi trở lại object storage theo từng khối lớn. Do đó, hệ thống tệp song song không mang lại lợi ích trong trường hợp này vì mỗi tác vụ chỉ đọc và ghi một lần thay vì truy cập ngẫu nhiên trong file.

Một điểm quan trọng trong xử lý dữ liệu là quá trình đồng bộ hóa toàn bộ tác vụ, đặc biệt là bước loại bỏ dữ liệu trùng lặp (deduplication) – một bước quan trọng để đảm bảo chất lượng mô hình. Quá trình này yêu cầu so sánh từng mẩu dữ liệu với tất cả các dữ liệu khác, do đó thường được thực hiện tại một trung tâm xử lý dữ liệu nằm gần hệ thống object storage. Các cụm máy tính xử lý dữ liệu này có thể giống với các siêu máy tính dựa trên CPU truyền thống, đôi khi còn sử dụng RDMA để tăng tốc độ loại bỏ dữ liệu trùng lặp.

Quan trọng hơn, quá trình xử lý dữ liệu này không được thực hiện trên các node GPU huấn luyện mô hình. Bởi vì xử lý dữ liệu thường bị giới hạn bởi băng thông I/O lưu trữ, nếu để GPU thực hiện công việc này, chúng có thể bị gián đoạn do phải chờ dữ liệu. Một số nhà cung cấp hệ thống tệp song song có thể khuyến nghị sử dụng hệ thống tệp tốc độ cao để tránh GPU bị ngắt quãng, nhưng thực tế, hầu hết các tổ chức thực hiện bước xử lý dữ liệu này trên các siêu máy tính CPU riêng biệt trước khi bắt đầu huấn luyện trên GPU.

Các node CPU rẻ hơn đáng kể so với GPU, do đó việc sử dụng cụm CPU với object storage là lựa chọn tiết kiệm hơn so với đầu tư vào hệ thống tệp song song đắt đỏ. Ví dụ, trên nền tảng Azure:

$1.00: Một VM 96 lõi, RAM 384 GB

$1.65: Một VM HPC 176 lõi, InfiniBand NDR, RAM 768 GB

$22.55: Một VM 96 lõi, 8 GPU H100, InfiniBand NDR

Do GPU không mang lại tốc độ xử lý nhanh hơn 13-22 lần so với CPU khi xử lý dữ liệu, nên không có lý do gì để thực hiện bước này trên các node GPU.

Ngoài ra, trong thực tế, quá trình xử lý dữ liệu cho mô hình tiếp theo thường diễn ra đồng thời với quá trình huấn luyện mô hình hiện tại trên cụm GPU. Nếu cả hai cụm này không phải lúc nào cũng chạy hết công suất, các nhà cung cấp dịch vụ đám mây vẫn có thể bán lại tài nguyên CPU hoặc GPU dư thừa cho khách hàng khác trong thời gian chờ đợi giữa các chiến dịch huấn luyện.

Huấn luyện mô hình

Huấn luyện phân tán quy mô lớn thường khiến nhiều người nghĩ rằng cần có hệ thống tệp song song tốc độ cao để vừa đọc dữ liệu đầu vào, vừa ghi checkpoint nhanh chóng. Trên thực tế, lý do chính khiến hệ thống tệp song song ra đời là để hỗ trợ việc checkpoint nhanh chóng và khôi phục nhanh khi xảy ra lỗi.

Mặc dù hệ thống tệp song song có thể được sử dụng để huấn luyện mô hình, nhưng nó không phải là giải pháp tối ưu về chi phí hoặc khả năng mở rộng khi triển khai trên hàng chục nghìn GPU. Để hiểu rõ lý do, hãy phân tích riêng hai khía cạnh: đọc dữ liệu đầu vào và ghi checkpoint.

Đọc dữ liệu đầu vào

Huấn luyện một mô hình trên GPU, dù chỉ trên một hay hàng nghìn node, đều tuân theo một chu trình đơn giản (đây được gọi là một “bước” trong thuật ngữ huấn luyện LLM) và được lặp lại liên tục:

1. Một lô dữ liệu đã được token hóa được nạp vào bộ nhớ GPU.
2. Dữ liệu đó được xử lý qua mạng nơ-ron, và các trọng số của mô hình được điều chỉnh.
3. Tất cả các GPU đồng bộ hóa trọng số đã cập nhật.

Có thể dễ dàng hình dung rằng tải I/O tạo ra từ bước 1 sẽ giống như trong một tác vụ tính toán hiệu năng cao (HPC) truyền thống: dữ liệu được đọc từ một hệ thống tệp song song vào bộ nhớ tính toán vào đầu mỗi bước huấn luyện.

Trước đây, các nhà cung cấp lưu trữ thường khẳng định rằng việc đọc dữ liệu ngẫu nhiên liên tục yêu cầu một hệ thống tệp song song tốc độ cao. Tuy nhiên, có hai lý do khiến điều này không còn chính xác:

1. Dữ liệu đầu vào không phải là hàng triệu tệp văn bản hoặc hình ảnh nhỏ lẻ, mà đã được đóng gói thành các đối tượng lớn trước khi GPU xử lý.
2. Dữ liệu token hóa có mật độ cao hơn nhiều so với dữ liệu thô, do đó, lượng byte thực tế cần đọc trong hàng trăm hoặc hàng nghìn bước huấn luyện là rất nhỏ.

Ví dụ, mô hình Llama-3 405B được huấn luyện trên 15.6 nghìn tỷ token. Mỗi token có kích thước trung bình từ 3 đến 5 byte, đồng nghĩa với tổng dữ liệu token hóa chỉ khoảng 60 TB. Với 16.000 GPU trong suốt 54 ngày huấn luyện, mỗi GPU chỉ cần xử lý 3,75 GB dữ liệu trong toàn bộ quá trình.

Khi bạn xem xét lượng byte rất nhỏ cần thiết để huấn luyện một mô hình LLM, sẽ trở nên rõ ràng rằng thách thức I/O lớn nhất trong vòng lặp huấn luyện hiệu suất cao không phải là băng thông thô, mà là sự biến động hiệu suất. Do đó, cách tốt nhất để đảm bảo rằng GPU không bị đình trệ do các yêu cầu đọc là loại bỏ càng nhiều sự biến động hiệu suất I/O càng tốt. Để làm được điều này, bạn phải giảm thiểu các nguồn gây tranh chấp có thể phát sinh giữa các thiết bị lưu trữ và mạng kết nối chúng với GPU. Mặc dù bạn có thể làm điều này bằng cách sử dụng các cơ chế quản lý chất lượng dịch vụ (QoS) tiên tiến trên cả máy chủ lưu trữ và mạng kết nối, nhưng vẫn có một cách đơn giản hơn.

Chỉ cần trang bị một số ổ SSD cục bộ cho mỗi nút GPU.

Điều này đảm bảo rằng không có sự tranh chấp nào xảy ra khi tải dữ liệu từ bộ lưu trữ vào GPU, vì mạng duy nhất giữa chúng là PCIe trên chính nút đó. Ngoài ra, việc sử dụng ổ NVMe cục bộ giúp dung lượng lưu trữ và hiệu suất lưu trữ có thể mở rộng tuyến tính với hiệu suất GPU. Ngược lại, một hệ thống lưu trữ từ xa (dù là hệ thống tệp song song hay đối tượng) sẽ không thể mở rộng kích thước hoặc tốc độ khi bạn thêm nhiều GPU vào công việc huấn luyện, dẫn đến việc mỗi GPU sẽ bị giảm hiệu suất do I/O khi số lượng GPU tăng lên.

Trong thực tế, quá trình huấn luyện mô hình sử dụng ổ SSD cục bộ như sau:

Khi bắt đầu một công việc huấn luyện, dữ liệu được đọc từ bộ lưu trữ từ xa vào ổ SSD cục bộ trên các nút GPU một lần theo cách phân tán. Vì dữ liệu đã được mã hóa thành token rất nhỏ, nhiều bản sao của toàn bộ tập dữ liệu có thể được lưu trữ trên các nút GPU. Ví dụ, nếu bạn huấn luyện mô hình Llama-3 405b trên các nút NVIDIA DGX H100, bạn có thể chứa toàn bộ tập dữ liệu huấn luyện (tất cả 60 TB) chỉ trên ba nút, vì mỗi nút có 30 TB SSD cục bộ. Vì mô hình này được huấn luyện trên 16.000 GPU (tương đương 2.000 nút), điều đó có nghĩa là hàng trăm bản sao của toàn bộ tập dữ liệu có thể được lưu trữ. Điều này mang lại một số lợi ích lớn:

1. GPU không bao giờ phải chờ bộ lưu trữ dùng chung trả dữ liệu trước khi có thể tính toán. Mọi thứ cần thiết đều nằm trên ổ SSD cục bộ.
2. Khi một nút GPU bị lỗi, dữ liệu đầu vào của nó có thể được phục hồi từ một nút GPU khác thông qua InfiniBand. Sau khi huấn luyện bắt đầu, dữ liệu đầu vào không bao giờ cần phải đọc lại từ bộ lưu trữ chung.
3. Thông thường, huấn luyện sẽ mở rộng theo thời gian bằng cách thêm nhiều GPU hơn (nhiều miền song song dữ liệu hơn) khi công việc ổn định. Khi điều này xảy ra, hiệu suất I/O cũng mở rộng tuyến tính vì các GPU mới không phải cạnh tranh để truy xuất dữ liệu từ bộ lưu trữ dùng chung.

Một điểm đáng lưu ý về cách tiếp cận này là việc quản lý dữ liệu sẽ trở nên phức tạp hơn. Khung huấn luyện sẽ phải theo dõi xem ổ SSD và nút nào có bản sao của dữ liệu đầu vào nào, hoặc cần có một không gian tên dùng chung, phân tán trên phía máy khách, chẳng hạn như WEKA Converged Mode hoặc CoreWeave LOTA, để kết nối ứng dụng của bạn với dữ liệu. Tuy nhiên, trong thực tế, các mô hình tiên tiến chỉ được huấn luyện một epoch duy nhất—tức là mỗi token đầu vào chỉ được xử lý đúng một lần để đạt chất lượng mô hình tối ưu. Vì không có hai GPU nào cần đọc cùng một token đầu vào, nên không bao giờ có nhu cầu sao chép token giữa các nút trong vòng lặp huấn luyện.

Toàn bộ dung lượng SSD cục bộ của nút không thể chỉ chứa dữ liệu đầu vào, vì vẫn cần không gian cho các điểm kiểm tra (checkpoints) và dữ liệu tạm thời khác. Tuy nhiên, thực tế vẫn là các hệ thống tệp song song có băng thông siêu cao hoặc dung lượng siêu lớn không cần thiết để tải token đầu vào trong quá trình huấn luyện. Các cụm huấn luyện AI được xây dựng với một số lượng lớn ổ SSD cục bộ để đảm nhiệm công việc nặng, và dữ liệu đầu vào cho các mô hình LLM đủ nhỏ để chỉ cần một số ít nút GPU để lưu trữ.

Ghi Checkpoint Mô Hình

Mặc dù khối lượng đọc trong quá trình huấn luyện LLM khá nhỏ, nhưng khối lượng ghi có thể rất lớn ở quy mô lớn do xác suất lỗi tăng theo cấp số nhân khi kích thước của tác vụ huấn luyện tăng lên. Tuy nhiên, không giống như các tác vụ HPC khoa học, kích thước checkpoint không tỷ lệ thuận với số lượng node tham gia huấn luyện; checkpoint cho một mô hình 405 tỷ tham số huấn luyện trên 16.000 node có cùng kích thước như khi huấn luyện trên ba node. Điều này là do sau mỗi bước huấn luyện, quá trình đồng bộ hóa toàn cục giúp mỗi bản sao dữ liệu song song của mô hình trở nên giống hệt nhau. Do đó, chỉ cần lưu một bản sao duy nhất của trọng số mô hình, thường dưới 100 terabyte đối với các LLM hiện đại.

Một cách tiếp cận đơn giản để checkpoint là cho một bản sao của mô hình ghi trực tiếp trọng số vào bộ nhớ lưu trữ chung. Tuy nhiên, cách này có thể gây ra nghẽn cổ chai khi hàng nghìn GPU cùng ghi dữ liệu đồng thời.

Bài phân tích của Kartik và Colleen Tartow tại VAST đã chỉ ra rằng ngay cả một mô hình với một nghìn tỷ tham số vẫn có thể đạt 99,7% tiến trình huấn luyện (chỉ 0,3% thời gian dành cho checkpoint) khi sử dụng 3.072 GPU với một hệ thống tệp 273 GB/s. Điều này cho thấy không cần một hệ thống tệp song song quá mạnh để đạt hiệu suất checkpoint tốt.

Tuy nhiên, giống như với việc đọc dữ liệu đầu vào, mục tiêu thực sự của checkpointing ở quy mô lớn là loại bỏ hoàn toàn sự phụ thuộc vào bộ nhớ lưu trữ dùng chung khỏi vòng lặp huấn luyện. Cách tốt nhất để làm điều này là lưu checkpoint vào bộ nhớ cục bộ của node. Tuy nhiên, cần có biện pháp đặc biệt để đảm bảo rằng checkpoint không bị mất khi một node gặp sự cố.

Checkpointing không đồng bộ và phân cấp

Trong thực tế, việc huấn luyện LLM ngày nay sử dụng phương pháp checkpointing không đồng bộ, nhiều cấp độ. Kỹ thuật này kết hợp khả năng mở rộng của việc checkpoint vào bộ nhớ cục bộ với tính bền vững của bộ nhớ dùng chung:

Một hình ảnh động mô tả cách tiếp cận checkpoint phân cấp, trong đó dữ liệu trước tiên được sao chép từ bộ nhớ GPU vào bộ nhớ CPU, sau đó từ bộ nhớ CPU vào SSD cục bộ của một node đối tác. Cuối cùng, dữ liệu được sao chép tập trung từ SSD cục bộ vào bộ nhớ lưu trữ dùng chung.

Chìa khóa của quá trình checkpoint này là sự đồng bộ dữ liệu theo cấp bậc:

1. Trọng số của mô hình trước tiên được sao chép từ bộ nhớ GPU vào bộ nhớ CPU (DRAM) của node sau mỗi bước huấn luyện. Việc checkpoint này bị giới hạn bởi băng thông CPU-GPU (PCIe, NVLink, hoặc Infinity Fabric), nhưng một checkpoint có kích thước 500 GB có thể hoàn thành trong một giây.
   • Lợi ích của việc checkpoint vào DRAM là GPU có thể nhanh chóng tiếp tục huấn luyện bước tiếp theo.
   • Tuy nhiên, checkpoint trong DRAM không được bảo vệ và sẽ bị mất nếu node gặp sự cố.
2. Để bảo vệ checkpoint khỏi việc node bị crash, nó được sao chép không đồng bộ từ DRAM của CPU sang SSD cục bộ của một node lân cận bằng RDMA.
   • Nếu một node gặp sự cố, nó có thể khôi phục từ checkpoint được lưu trên SSD của node lân cận thông qua InfiniBand.
   • Việc đọc/ghi một checkpoint 500 GB từ SSD lân cận có thể mất khoảng 10 giây, vì vậy checkpoint không đồng bộ này thường được thực hiện sau mỗi 10 lần checkpoint vào DRAM.
3. Để lưu trữ checkpoint trong dài hạn, các checkpoint cũng được sao chép không đồng bộ từ SSD cục bộ lên bộ nhớ dùng chung.
   • Quá trình này có thể mất một đến hai phút cho mỗi checkpoint 500 GB, do đó việc sao chép checkpoint cấp cuối này có thể được thực hiện mỗi 10 phút một lần.

Cơ chế checkpoint phân cấp này cho phép GPU chỉ mất một giây để checkpoint, nhưng vẫn có thể phục hồi sau sự cố của job, node, hoặc thậm chí cả cụm, bằng cách điều chỉnh tần suất checkpoint theo từng cấp bộ nhớ lưu trữ.

• Chi phí khôi phục sau sự cố nghiêm trọng có thể là việc tính toán lại tối đa 10 phút huấn luyện.
• Tuy nhiên, vì sự cố nghiêm trọng xảy ra rất hiếm, nên cơ chế này đạt được sự cân bằng giữa hiệu suất của DRAM và chi phí lưu trữ lâu dài trên ổ cứng hoặc object store.

Yêu cầu đối với bộ nhớ dùng chung rất khiêm tốn

Hệ thống lưu trữ dùng chung trong sơ đồ checkpoint phân cấp này không cần hiệu suất cao, bởi vì:

1. Checkpoint chỉ cần hoàn thành trước khi lần sao chép cấp cuối tiếp theo diễn ra.
   • Nếu checkpoint 500 GB chỉ được sao chép lên bộ nhớ dùng chung mỗi 10 phút, thì hệ thống lưu trữ chỉ cần cung cấp băng thông tổng cộng 1 GB/s.
2. Mô hình ghi dữ liệu từ SSD cục bộ lên bộ nhớ dùng chung rất đơn giản:
   • Vì checkpoint đã được tạo sẵn, nên nó chỉ cần sao chép thẳng từ một file lên object storage.
   • Không có các tensor hình dạng phức tạp được serialize vào file theo thời gian thực.
   • Dữ liệu chỉ cần stream từ file checkpoint cục bộ lên object store theo kích thước khối tối ưu để đạt hiệu suất ghi cao nhất.

Tổng hợp lại, các object store là lựa chọn lý tưởng cho phương pháp checkpoint này, nhờ băng thông ghi tuần tự cao và không cần đến cấu trúc thư mục phức tạp hay tính nhất quán chi tiết như trong hệ thống tệp song song (Parallel File System).

Dĩ nhiên, việc triển khai các cơ chế checkpoint phân cấp và không đồng bộ này có thể phức tạp. Tuy nhiên, ngày càng có nhiều framework hỗ trợ checkpoint và khôi phục dữ liệu theo cách tiếp cận này.

• Nhà phát triển mô hình không cần trực tiếp làm việc với các file hoặc object storage.
• Framework sẽ tự động quản lý dữ liệu trong quá trình checkpoint và khôi phục, thông qua một API cấp cao.

Triển khai mô hình và suy luận

Sau khi một mô hình được huấn luyện, việc đưa nó vào sản xuất dưới dạng dịch vụ suy luận là bước cuối cùng trong vòng đời của nó. Từ góc độ lưu trữ và I/O, quá trình này phức tạp hơn nhiều so với huấn luyện, vì nó kết hợp mô hình triển khai dịch vụ doanh nghiệp (failover, cân bằng tải, xác thực và mở rộng quy mô) với các bản sao của mô hình đã được huấn luyện chạy trên hạ tầng HPC. Khi nghe các nhà cung cấp nói về kho khóa-giá trị (key-value store), cơ sở dữ liệu vector (vector database) và RAG (retrieval-augmented generation), tất cả đều diễn ra trong giai đoạn này.

Nếu bỏ qua mọi thứ khác và chỉ xem xét hệ thống lưu trữ gắn với cụm GPU, yêu cầu I/O của suy luận tương đối đơn giản:

Khi cung cấp một node GPU cho suy luận, trọng số của mô hình phải được tải từ hệ thống lưu trữ chia sẻ nhanh nhất có thể.

Khi sử dụng một LLM để tìm kiếm tài liệu, một cơ sở dữ liệu vector là cần thiết để thực hiện tìm kiếm tương đồng, hỗ trợ LLM truy vấn các tài liệu liên quan. Đây chính là nền tảng của RAG.

Bộ nhớ đệm khóa-giá trị (key-value cache) thường được sử dụng để giảm độ trễ trong các phần khác nhau của pipeline suy luận bằng cách lưu trữ ngữ cảnh, bao gồm lịch sử hội thoại hoặc các tài liệu thường xuyên được truy cập.

Khi nhu cầu suy luận thay đổi, các mô hình và trọng số có thể được thay thế linh hoạt trên các máy chủ GPU riêng lẻ.

Một hệ thống tệp song song không thực sự hữu ích cho bất kỳ bước nào kể trên. Vị trí duy nhất mà nó có thể mang lại lợi ích nhờ băng thông cao là trong quá trình tải và nạp lại trọng số mô hình (#1 và #4). Tuy nhiên, giống như checkpointing phân cấp, các thao tác I/O này đều là sao chép toàn bộ đối tượng và chỉ đọc, rất phù hợp với API đối tượng (object API). Các cấu trúc thư mục phức tạp và tính nhất quán mạnh không thực sự cần thiết trong trường hợp này.

Hệ thống lưu trữ đối tượng đủ tốt, thậm chí tốt hơn

Không có bước nào trong vòng đời huấn luyện mô hình thực sự hưởng lợi đáng kể từ hệ thống tệp song song:

Thu thập dữ liệu: Hàng trăm petabyte tài liệu nhỏ lẻ được đóng gói và lập chỉ mục vào các container dữ liệu lớn ngay lập tức. Siêu dữ liệu được lưu trữ trong một kho khóa-giá trị riêng biệt, do đó không cần đến cây thư mục của hệ thống tệp. Hơn nữa, dữ liệu sau khi được đóng gói và lập chỉ mục sẽ không bị thay đổi.

Xử lý dữ liệu: Đây là một khối lượng công việc phân tích dữ liệu đòi hỏi I/O cao. Băng thông đọc rất quan trọng, nhưng dữ liệu được truy cập theo các giao dịch lớn và phần lớn xử lý là song song.

Huấn luyện mô hình: Dữ liệu token hóa được tải vào bộ nhớ cục bộ của GPU chỉ một lần duy nhất khi bắt đầu chiến dịch huấn luyện. Checkpoint được đẩy ra bộ nhớ chung theo cơ chế bất đồng bộ, giúp không ảnh hưởng đến hiệu suất GPU.

Suy luận: Việc tải trọng số mô hình vào GPU là một quy trình chỉ đọc, có thể được tối ưu hóa bằng hệ thống lưu trữ đối tượng.

Với những mô hình lưu trữ I/O như trên, hệ thống lưu trữ đối tượng là lựa chọn phù hợp nhất. Hệ thống tệp song song có thể được sử dụng, nhưng đi kèm với chi phí cao và độ phức tạp không cần thiết.

Hệ thống tệp song song vẫn có chỗ đứng

Mặc dù không còn là lựa chọn ưu tiên, hệ thống tệp song song vẫn có giá trị nhất định. Những nền tảng như WEKA, VAST, và Qumulo hiện hỗ trợ cả giao diện file lẫn object, giúp cân bằng nhu cầu giữa các môi trường truyền thống và hiện đại. Một số nền tảng như WEKA WARRP hay VAST InsightEngine còn cung cấp khả năng tìm kiếm vector nhanh hơn so với cơ sở dữ liệu vector thông thường.

Tóm lại, hệ thống tệp song song không hề biến mất, nhưng cũng không còn là điều kiện tiên quyết để huấn luyện mô hình AI quy mô lớn. Các siêu máy tính tiên tiến nhất hiện nay đều được thiết kế mà không cần đến nó.