Fire-Flyer File System của DeepSeek

• Fire-Flyer File System (3FS) là hệ thống tệp phân tán hiệu năng cao được thiết kế cho các workload huấn luyện và suy luận AI, cung cấp một lớp lưu trữ dùng chung bằng cách tận dụng SSD hiện đại và mạng RDMA
• Kiến trúc tách rời kết hợp thông lượng của hàng nghìn SSD với băng thông mạng của hàng trăm nút lưu trữ, cho phép ứng dụng truy cập tài nguyên lưu trữ mà không cần quan tâm đến vị trí
• Mô hình nhất quán cung cấp tính nhất quán mạnh dựa trên CRAQ (Chain Replication with Apportioned Queries), và dịch vụ siêu dữ liệu có kiến trúc không trạng thái sử dụng backend là kho khóa-giá trị giao dịch như FoundationDB
• Các workload chính gồm chuẩn bị dữ liệu, data loader, checkpointing và KVCache cho suy luận; trong bài kiểm tra áp lực đọc trên cụm lớn, hệ thống ghi nhận thông lượng đọc tổng hợp khoảng 6.6 TiB/s
• Khi build, do từng sử dụng std::shuffle trong quá khứ nên có thể phát sinh vấn đề tương thích nhị phân giữa các phiên bản trình biên dịch; cần chỉ định kiểu g++10 hoặc g++11 bằng -DSHUFFLE_METHOD và giữ nguyên thiết lập đó sau khi triển khai cụm

---

Vấn đề mà 3FS hướng tới giải quyết

• Fire-Flyer File System (3FS) là hệ thống tệp phân tán hiệu năng cao được thiết kế để đáp ứng nhu cầu của các workload huấn luyện và suy luận AI
• Hệ thống tận dụng SSD hiện đại và mạng RDMA để cung cấp một lớp lưu trữ dùng chung, giúp đơn giản hóa việc phát triển ứng dụng phân tán
• Vì cung cấp giao diện tệp nên không cần học một API lưu trữ mới riêng biệt

Kiến trúc và tính nhất quán

• Kiến trúc tách rời kết hợp thông lượng của hàng nghìn SSD với băng thông mạng của hàng trăm nút lưu trữ
  • Ứng dụng có thể truy cập tài nguyên lưu trữ theo cách không cần biết vị trí của chúng
• Tính nhất quán mạnh được hiện thực bằng Chain Replication with Apportioned Queries (CRAQ)
  • Mục tiêu là làm cho mã ứng dụng đơn giản hơn và cấu trúc dễ suy luận hơn
• Dịch vụ siêu dữ liệu được thiết kế theo kiểu không trạng thái và sử dụng kho khóa-giá trị giao dịch như FoundationDB làm backend

Các workload được hỗ trợ

• Chuẩn bị dữ liệu

  • Tổ chức đầu ra của pipeline phân tích dữ liệu theo cấu trúc thư mục phân cấp
  • Quản lý hiệu quả lượng lớn kết quả trung gian

• Data loader

  • Cho phép truy cập ngẫu nhiên đến các mẫu huấn luyện trên toàn bộ các nút tính toán, loại bỏ nhu cầu prefetch hoặc shuffle dataset

• Checkpointing

  • Hỗ trợ checkpoint song song thông lượng cao cho huấn luyện quy mô lớn

• KVCache cho suy luận

  • Cung cấp dung lượng lớn hơn và thông lượng cao hơn như một lựa chọn thay thế hiệu quả chi phí cho cơ chế cache dựa trên DRAM

Kết quả hiệu năng

• Thông lượng đỉnh

  • Trong bài kiểm tra áp lực đọc trên cụm 3FS quy mô lớn, thông lượng đọc tổng hợp đạt khoảng 6.6 TiB/s
  • Cụm thử nghiệm gồm 180 nút lưu trữ
    • Mỗi nút lưu trữ được trang bị 2×200Gbps InfiniBand NIC và 16 ổ NVMe SSD 14TiB
    • Có hơn khoảng 500 nút client được sử dụng
    • Mỗi nút client được cấu hình với 1×200Gbps InfiniBand NIC
  • Kết quả được đo trong điều kiện có lưu lượng nền từ các tác vụ huấn luyện
  • Benchmark của 3FS có thể sử dụng engine USRBIO cho fio

• GraySort

  • smallpond được đánh giá bằng benchmark GraySort
  • Triển khai gồm hai giai đoạn
    • Phân vùng dữ liệu dựa trên shuffle sử dụng các bit tiền tố của khóa
    • Sắp xếp bên trong từng phân vùng
  • Cả hai giai đoạn đều đọc dữ liệu từ 3FS và ghi dữ liệu trở lại 3FS
  • Cấu hình cụm thử nghiệm:
    • 25 nút lưu trữ
    • 2 miền NUMA trên mỗi nút
    • 1 dịch vụ lưu trữ trên mỗi NUMA
    • 2×400Gbps NIC trên mỗi nút
    • 50 nút tính toán
    • Các nút tính toán gồm 2 miền NUMA, 192 lõi vật lý, 2.2TiB RAM và 1×200Gbps NIC trên mỗi nút
  • Tác vụ sắp xếp 110.5TiB dữ liệu trên 8,192 phân vùng hoàn tất trong 30 phút 14 giây
  • Thông lượng trung bình là 3.66 TiB/phút

• KVCache

  • KVCache là kỹ thuật lưu cache các vector key/value của những token trước đó vào các lớp decoder trong quá trình suy luận LLM để tránh tính toán lặp lại
  • Client KVCache sử dụng 1×400Gbps NIC trên mỗi nút
  • Thông lượng đọc đạt đỉnh tới 40 GiB/s
  • IOPS của tác vụ loại bỏ của GC trong cùng giai đoạn cũng được đo đạc

Tài liệu và build

• Tài liệu được cung cấp:
  • Design Notes
  • Setup Guide
  • USRBIO API Reference
  • P Specifications
• Mã nguồn được clone từ GitHub, sau đó khởi tạo submodule và áp dụng patch
  • git submodule update --init --recursive
  • ./patches/apply.sh
• Ví dụ cài đặt các dependency được hỗ trợ được cung cấp cho các môi trường sau
  • Ubuntu 20.04
  • Ubuntu 22.04
  • openEuler 2403sp1
  • OpenCloudOS 9
  • TencentOS 4
• Điều kiện tiên quyết bổ sung cho build:
  • libfuse 3.16.1 trở lên
  • FoundationDB 7.1 trở lên
  • Rust toolchain tối thiểu 1.75.0, khuyến nghị 1.85.0 trở lên hoặc bản ổn định mới nhất
• 3FS được build bằng CMake trong thư mục build
  • Ví dụ trình biên dịch C/C++ là clang-14, clang++-14
  • Loại build sử dụng ví dụ RelWithDebInfo

• Tương thích thuật toán shuffle

  • Do từng sử dụng std::shuffle trong quá khứ, các binary được build bằng những phiên bản trình biên dịch khác nhau như g++10 và g++11+ có thể không tương thích với nhau
  • Khi build cần chỉ định -DSHUFFLE_METHOD để cố định một thuật toán shuffle nhất quán
  • Các cụm hiện có phải sử dụng phương thức phù hợp với phiên bản trình biên dịch đã dùng cho lần triển khai trước đó
  • Cụm mới có thể chọn một trong hai kiểu g++10 hoặc g++11, nhưng sau khi triển khai phải giữ nguyên thiết lập đó cho mọi bản build về sau
  • Docker build image được cung cấp cho TencentOS-4 và OpenCloudOS-9
  • Việc chạy cụm thử nghiệm tuân theo Setup Guide
  • Báo cáo issue qua GitHub Issues