1 คะแนน โดย GN⁺ 2025-03-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

ระบบไฟล์ Fire-Flyer

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

ประสิทธิภาพและการใช้งาน

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

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

  • การเตรียมข้อมูล: จัดระเบียบผลลัพธ์ของ data analysis pipeline ให้อยู่ในโครงสร้างไดเรกทอรีแบบลำดับชั้น และจัดการผลลัพธ์กลางจำนวนมากได้อย่างมีประสิทธิภาพ
  • Data loader: เปิดให้เข้าถึงตัวอย่างสำหรับการเทรนแบบสุ่มได้ข้าม compute node โดยไม่จำเป็นต้อง preload หรือ shuffle ชุดข้อมูลล่วงหน้า
  • Checkpointing: รองรับการทำ checkpoint แบบขนานความเร็วสูงสำหรับการเทรนขนาดใหญ่
  • KVCache for Inference: เป็นทางเลือกที่คุ้มค่ากว่าการแคชบน DRAM พร้อมมอบ throughput สูงและความจุขนาดใหญ่พอสมควร

ประสิทธิภาพ

1. Peak throughput

  • ในการทดสอบโหลดการอ่านขนาดใหญ่ของคลัสเตอร์ 3FS สามารถทำ aggregated read throughput สูงสุดได้ประมาณ 6.6 TiB/s

2. GraySort

  • ประเมินด้วย GraySort benchmark ที่ใช้วัดประสิทธิภาพการเรียงลำดับของชุดข้อมูลขนาดใหญ่ โดยใช้เวลา 30 นาที 14 วินาทีในการเรียงข้อมูล 110.5 TiB เป็น 8,192 พาร์ทิชัน และทำ average throughput ได้ 3.66 TiB/นาที

3. KVCache

  • ใช้เทคนิค KVCache เพื่อเพิ่มประสิทธิภาพกระบวนการอนุมานของ LLM โดยแคชเวกเตอร์คีย์และค่า ของโทเค็นก่อนหน้าใน decoder layer เพื่อหลีกเลี่ยงการคำนวณซ้ำ โดยมี peak throughput สูงสุดถึง 40 GiB/s

เอกสาร

  • บันทึกการออกแบบ
  • คู่มือการตั้งค่า
  • เอกสารอ้างอิง USRBIO API
  • สเปก P

ตรวจสอบซอร์สโค้ด

  • สามารถโคลนรีโพซิทอรี 3FS จาก GitHub เพื่อตรวจสอบซอร์สโค้ดได้

การรายงานปัญหา

1 ความคิดเห็น

 
GN⁺ 2025-03-01
ความเห็นจาก Hacker News
  • เดิมทีดีไซน์นี้ถูกนำเสนอไว้ที่นี่: ลิงก์

    • ระบบไฟล์นี้ถูกพัฒนาและใช้งานมาหลายปีแล้ว
    • เมื่อเทียบกับระบบไฟล์แบบดั้งเดิมแล้ว มันเน้นไปที่การฝึกโมเดลมากกว่า
    • หากมีการอ่านแบบสุ่มจำนวนมาก read cache และ prefetch จะไม่มีประโยชน์
    • เพื่อเพิ่มประสิทธิภาพ จึงออกแบบระบบไฟล์โดยตัดความสามารถเหล่านี้ออก
  • 3FS ถูกใช้ในสถานการณ์ระหว่างการฝึก AI ที่โหนดคอมพิวต์อ่านข้อมูลตัวอย่างเป็นชุด

    • มันช่วยเร่งการฝึกโมเดลผ่านปฏิสัมพันธ์ความเร็วสูงระหว่างคอมพิวต์กับสตอเรจ
    • เป็นงานอ่านแบบสุ่มขนาดใหญ่ และข้อมูลที่อ่านแล้วจะไม่ถูกนำกลับมาใช้อีกในเวลาอันสั้น
    • ดังนั้นจึงใช้ "read cache" ไม่ได้ และการอ่านล่วงหน้าก็ไม่มีประโยชน์
    • 3FS จึงมีการติดตั้งใช้งานที่แตกต่างจากระบบไฟล์อื่นค่อนข้างมาก
  • 3FS ใช้ Linux-based AIO และอินเทอร์เฟซ io_uring เพื่อทำการอ่านตัวอย่างให้เสร็จสิ้น

    • file cache ไม่มีประสิทธิผลเลย และยังใช้หน่วยความจำของระบบจนกระทบกับงานถัดไป
    • จึงปิด file cache และอ่านข้อมูลโดยใช้เฉพาะโหมด Direct I/O
    • ต้องจัดแนว buffer pointer, offset และความยาว
    • หากให้ผู้ใช้จัดแนวเองจะเกิดการคัดลอกหน่วยความจำเพิ่มเติม จึงทำการจัดแนวภายในระบบไฟล์
    • ช่วยปรับประสิทธิภาพให้เหมาะสมและเพิ่มความสะดวกแก่ผู้ใช้
  • ความต่างระหว่าง Deepseek กับ OpenAI/Anthropic อย่างหนึ่งคือความต่างระหว่างคนทำงานภาคปฏิบัติกับนักวิชาการ

    • OpenAI มีบุคลากรระดับโลก แต่ก็มีคนที่เปิดเผยรายละเอียดทางเทคนิคน้อยอยู่ด้วย
  • ระบบไฟล์แบบกระจายถูกมองว่าเป็นซอฟต์แวร์ที่ทำยากที่สุดอย่างหนึ่ง

    • มีคำแนะนำว่าอย่าเขียนระบบไฟล์ขึ้นใหม่ตั้งแต่ต้น แม้จะอยู่บน FUSE ก็ตาม
    • ขณะที่บริษัทในซิลิคอนแวลลียังประชุมกันเป็นครั้งที่ 100 ทีมที่มีคนน้อยกว่า 60 คนกลับพัฒนาระบบไฟล์ขนานประสิทธิภาพสูงได้แล้ว
  • งานวิจัยที่เกี่ยวข้อง: ลิงก์

    • "Fire-Flyer AI-HPC: การออกแบบร่วมระหว่างซอฟต์แวร์และฮาร์ดแวร์ที่คุ้มค่าสำหรับดีปเลิร์นนิง"
    • ความก้าวหน้าอย่างรวดเร็วของดีปเลิร์นนิงและโมเดลภาษาขนาดใหญ่ทำให้ความต้องการด้านพลังประมวลผลและแบนด์วิดท์พุ่งสูงขึ้น
    • นำเสนอสถาปัตยกรรม Fire-Flyer AI-HPC เพื่อลดต้นทุนและการใช้พลังงาน
    • ออกแบบ HFReduce เพื่อเร่งการสื่อสาร allreduce
    • ติดตั้งใช้งานมาตรการหลายอย่างเพื่อป้องกันความแออัดใน Computation-Storage Integrated Network
  • ฉันสงสัยว่าด้วยดีไซน์ที่อิง FUSE พวกเขาได้ประสิทธิภาพระดับนั้นมาได้อย่างไร

    • FUSE ถูกใช้เพื่อจัดการ metadata และต้องเชื่อมต่อ C++ client library เพื่อให้ได้ประสิทธิภาพสูง
    • มันไม่ใช่การใช้งานทั่วไป และจำเป็นต้องแก้ไขแอปพลิเคชัน
    • ถึงอย่างนั้นก็ยังเป็นวิธีที่ชาญฉลาด และฉันก็สงสัยว่ากลยุทธ์ LD_PRELOAD จะทำให้ใช้งานได้ทั่วไปขึ้นหรือไม่
  • OpenAI และที่อื่น ๆ ก็มีส่วนร่วมกับระบบอย่างลึกซึ้งเช่นกัน แต่ที่อื่นกลับไม่ค่อยเห็นความใส่ใจละเอียดระดับนี้

    • เป็นงานที่ยอดเยี่ยม และหวังว่า Deepseek จะทำสิ่งที่น่าทึ่งยิ่งกว่านี้ต่อไป
  • พวกเขาผลิตงานได้มากจริง ๆ

    • พรุ่งนี้เราจะได้เห็นอะไรอีก? อย่าง DeepSeek OS หรือเปล่า?
  • ตอนนี้ยังไม่ชัดเจนว่าระบบยอดนิยมในปัจจุบันมีข้อบกพร่องตรงไหนและอย่างไร

    • ฉันสงสัยว่ารูปแบบการเข้าถึงข้อมูลต่างจากกรณีใช้งานแบบดั้งเดิมอย่างไร
  • ฉันสงสัยว่าการพอร์ตไปยัง orchestrator อย่าง K8s จะมีข้อดีหรือไม่

    • มันอาจมากเกินไปสำหรับการฝึก แต่ KVCache อาจมีประโยชน์ต่อการทำ inference สำหรับหลาย replica
  • ฉันสงสัยว่าจะมีใครอธิบายให้เชื่อได้ไหมว่านี่ไม่ใช่อาการ NIH syndrome

    • ฉันสงสัยว่าทำไมต้องใช้สิ่งนี้แทน SeaweedFS, Ceph, MinIO