Fire-Flyer File System ของ DeepSeek

 (github.com/deepseek-ai)
1 คะแนน โดย GN⁺ 2025-03-01 | ยังไม่มีความคิดเห็น | แชร์ทาง WhatsApp
  • Fire-Flyer File System(3FS) เป็นระบบไฟล์แบบกระจายประสิทธิภาพสูงสำหรับเวิร์กโหลดการฝึกและการอนุมาน AI โดยใช้ SSD รุ่นใหม่และเครือข่าย RDMA เพื่อให้เลเยอร์สตอเรจแบบแชร์
  • สถาปัตยกรรมแบบแยกส่วน รวมปริมาณงานของ SSD หลายพันตัวกับแบนด์วิดท์เครือข่ายของโหนดสตอเรจหลายร้อยโหนด ทำให้แอปพลิเคชันเข้าถึงทรัพยากรสตอเรจได้โดยไม่ต้องรับรู้ตำแหน่ง
  • โมเดลความสอดคล้องให้ความสอดคล้องแบบแข็งแกร่งบนพื้นฐาน CRAQ(Chain Replication with Apportioned Queries) และบริการเมทาดาทาเป็นโครงสร้างแบบไร้สถานะที่ใช้สตอเรจคีย์-แวลูแบบทรานแซกชัน เช่น FoundationDB เป็นแบ็กเอนด์
  • เวิร์กโหลดหลักคือการเตรียมข้อมูล, dataloader, checkpointing และ KVCache สำหรับการอนุมาน โดยในการทดสอบ stress test การอ่านของคลัสเตอร์ขนาดใหญ่ทำปริมาณงานอ่านรวมได้ราว 6.6 TiB/s
  • ขณะบิลด์มีปัญหาความเข้ากันได้ของไบนารีระหว่างเวอร์ชันคอมไพเลอร์จากการใช้ std::shuffle ในอดีต จึงต้องระบุวิธี g++10 หรือ g++11 ด้วย -DSHUFFLE_METHOD และคงการตั้งค่าเดิมหลังนำไปใช้ในคลัสเตอร์

ปัญหาที่ 3FS ต้องการแก้

  • Fire-Flyer File System(3FS) เป็นระบบไฟล์แบบกระจายประสิทธิภาพสูงที่ออกแบบมาเพื่อรองรับความต้องการของเวิร์กโหลดการฝึกและการอนุมาน AI
  • ใช้ SSD รุ่นใหม่และ เครือข่าย RDMA เพื่อให้เลเยอร์สตอเรจแบบแชร์ที่ทำให้การพัฒนาแอปพลิเคชันแบบกระจายง่ายขึ้น
  • ให้ไฟล์อินเทอร์เฟซ จึงไม่จำเป็นต้องเรียนรู้ API สตอเรจใหม่แยกต่างหาก

สถาปัตยกรรมและความสอดคล้อง

  • สถาปัตยกรรมแบบแยกส่วน รวมปริมาณงานของ SSD หลายพันตัวกับแบนด์วิดท์เครือข่ายของโหนดสตอเรจหลายร้อยโหนด
    • แอปพลิเคชันสามารถเข้าถึงทรัพยากรสตอเรจในแบบที่ไม่ต้องรับรู้ตำแหน่ง
  • ความสอดคล้องแบบแข็งแกร่ง ถูกใช้งานด้วย Chain Replication with Apportioned Queries(CRAQ)
    • มีเป้าหมายให้โค้ดแอปพลิเคชันเรียบง่ายขึ้นและเป็นโครงสร้างที่ให้เหตุผลได้ง่าย
  • บริการเมทาดาทาออกแบบให้ไร้สถานะ และใช้ สตอเรจคีย์-แวลูแบบทรานแซกชัน เช่น FoundationDB เป็นแบ็กเอนด์

เวิร์กโหลดที่รองรับ

  • การเตรียมข้อมูล

    • จัดระเบียบผลลัพธ์ของ data analysis pipeline เป็นโครงสร้างไดเรกทอรีแบบลำดับชั้น
    • จัดการผลลัพธ์ขั้นกลางจำนวนมากได้อย่างมีประสิทธิภาพ

  • Dataloader

    • ทำให้สามารถสุ่มเข้าถึงตัวอย่างการฝึกจากทั่วทั้ง compute node ได้ จึงลดความจำเป็นในการ prefetch หรือ shuffle ชุดข้อมูล

  • Checkpointing

    • รองรับ checkpointing แบบขนานที่มีปริมาณงานสูงสำหรับการฝึกขนาดใหญ่

  • KVCache สำหรับการอนุมาน

    • ให้ความจุที่ใหญ่กว่าและปริมาณงานสูงกว่า ในฐานะทางเลือกที่คุ้มค่ากว่าการแคชบน DRAM

ผลลัพธ์ด้านประสิทธิภาพ

  • ปริมาณงานสูงสุด

    • ใน stress test การอ่านของคลัสเตอร์ 3FS ขนาดใหญ่ ปริมาณงานอ่านรวมแตะประมาณ 6.6 TiB/s
    • คลัสเตอร์ทดสอบประกอบด้วยโหนดสตอเรจ 180 โหนด
      • โหนดสตอเรจแต่ละโหนดติดตั้ง InfiniBand NIC 2×200Gbps และ NVMe SSD 14TiB จำนวน 16 ตัว
      • ใช้โหนดไคลเอนต์มากกว่า 500 โหนด
      • โหนดไคลเอนต์แต่ละโหนดประกอบด้วย InfiniBand NIC 1×200Gbps
    • ผลลัพธ์ถูกวัดในสภาวะที่มีทราฟฟิกเบื้องหลังจากงานฝึกอยู่
    • เบนช์มาร์ก 3FS สามารถใช้ USRBIO engine สำหรับ fio ได้

  • GraySort

    • ประเมิน smallpond ด้วยเบนช์มาร์ก GraySort
    • การใช้งานประกอบด้วยสองขั้นตอน
      • การแบ่งพาร์ทิชันข้อมูลแบบ shuffle โดยใช้ prefix bit ของคีย์
      • การจัดเรียงภายในพาร์ทิชัน
    • ทั้งสองขั้นตอนอ่านข้อมูลจาก 3FS และเขียนข้อมูลไปยัง 3FS
    • การตั้งค่าคลัสเตอร์ทดสอบ:
      • โหนดสตอเรจ 25 โหนด
      • 2 NUMA domain ต่อโหนด
      • บริการสตอเรจ 1 รายการต่อ NUMA
      • NIC 2×400Gbps ต่อโหนด
      • โหนดคอมพิวต์ 50 โหนด
      • โหนดคอมพิวต์ประกอบด้วย 2 NUMA domain, คอร์กายภาพ 192 คอร์, RAM 2.2TiB และ NIC 1×200Gbps ต่อโหนด
    • งานจัดเรียงข้อมูล 110.5TiB กระจายบน 8,192 พาร์ทิชันเสร็จใน 30 นาที 14 วินาที
    • ปริมาณงานเฉลี่ยคือ 3.66 TiB/min

  • KVCache

    • KVCache เป็นเทคนิคที่แคชเวกเตอร์ key/value ของโทเคนก่อนหน้าไว้ใน decoder layer ระหว่างการอนุมาน LLM เพื่อหลีกเลี่ยงการคำนวณซ้ำ
    • ไคลเอนต์ KVCache ใช้ NIC 1×400Gbps ต่อโหนด
    • ปริมาณงานอ่านแตะสูงสุด 40 GiB/s
    • ในช่วงเวลาเดียวกันมีการวัด IOPS ของงานลบของ GC ด้วย

เอกสารและการบิลด์

  • เอกสารที่ให้มา:
    • Design Notes
    • Setup Guide
    • USRBIO API Reference
    • P Specifications
  • หลังจาก clone ซอร์สโค้ดจาก GitHub ให้เริ่มต้น submodule และใช้แพตช์
    • git submodule update --init --recursive
    • ./patches/apply.sh
  • ตัวอย่างการติดตั้ง dependency ที่รองรับมีให้สำหรับสภาพแวดล้อมต่อไปนี้
    • Ubuntu 20.04
    • Ubuntu 22.04
    • openEuler 2403sp1
    • OpenCloudOS 9
    • TencentOS 4
  • ข้อกำหนดเพิ่มเติมก่อนบิลด์:
    • libfuse 3.16.1 ขึ้นไป
    • FoundationDB 7.1 ขึ้นไป
    • Rust toolchain ขั้นต่ำ 1.75.0, แนะนำ 1.85.0 ขึ้นไป หรือเวอร์ชัน stable ล่าสุด
  • 3FS บิลด์ด้วย CMake ในโฟลเดอร์ build
    • ตัวอย่างคอมไพเลอร์ C/C++ คือ clang-14, clang++-14
    • ใช้ตัวอย่าง build type เป็น RelWithDebInfo

  • ความเข้ากันได้ของอัลกอริทึม shuffle

    • จากการใช้ std::shuffle ในอดีต ไบนารีที่บิลด์ด้วยคอมไพเลอร์ต่างเวอร์ชันกัน เช่น g++10 และ g++11+ อาจไม่เข้ากัน
    • ขณะบิลด์ต้องระบุ -DSHUFFLE_METHOD เพื่อกำหนดอัลกอริทึม shuffle ที่สอดคล้องกัน
    • คลัสเตอร์เดิมต้องใช้วิธีที่ตรงกับเวอร์ชันคอมไพเลอร์ที่ใช้ในการ deploy ก่อนหน้า
    • คลัสเตอร์ใหม่สามารถเลือกหนึ่งใน g++10 หรือ g++11 ได้ แต่หลัง deploy แล้วต้องคงการตั้งค่าเดียวกันในการบิลด์ทั้งหมดในอนาคต
    • มีอิมเมจบิลด์ Docker สำหรับ TencentOS-4 และ OpenCloudOS-9
    • การรันคลัสเตอร์ทดสอบให้ทำตาม Setup Guide
    • รายงาน issue ผ่าน GitHub Issues

บทความที่เกี่ยวข้อง

ยังไม่มีความคิดเห็น

ยังไม่มีความคิดเห็น