สร้างคลัสเตอร์สตอเรจสำหรับพรีเทรนด้วยฮาร์ดไดรฟ์ขนาด 30 เพตะไบต์

• เพื่อ พรีเทรนโมเดลสำหรับการแก้ปัญหาการใช้งานคอมพิวเตอร์ ได้มีการสร้าง คลัสเตอร์สตอเรจด้วยตนเอง ใจกลางซานฟรานซิสโก โดยมีเป้าหมายเพื่อ จัดเก็บข้อมูลวิดีโอ ปริมาณ 90 ล้านชั่วโมง
• เลือกใช้แนวทาง on-premises ทำให้สามารถดำเนินงานโครงสร้างพื้นฐานจัดเก็บข้อมูล 30PB ได้ด้วยค่าใช้จ่ายรายปี $354k (ประมาณ 500 ล้านบาทวอน) เทียบกับ AWS ที่ต้องใช้ $12m (ประมาณ 17,000 ล้านบาทวอน) จึงประหยัดต้นทุนได้ราว 34 เท่า
• ต่างจากพับลิกคลาวด์ส่วนใหญ่ที่ให้ความสำคัญกับ high availability และ integrity โครงการนี้ใช้กลยุทธ์ ยอมรับการสูญหายของข้อมูลได้ ตามลักษณะของข้อมูลฝึก
• ดำเนินงานด้วย ซอฟต์แวร์เรียบง่ายบน Rust และ Nginx และแทนที่จะใช้ระบบซับซ้อนอย่าง Ceph หรือ MinIO ก็ใช้ โปรแกรมที่ทำขึ้นเอง 200 บรรทัด ในการจัดการ
• ระหว่างดำเนินโครงการได้พบทั้ง บทเรียนและประสบการณ์จริง เกี่ยวกับการ จัดวางทางกายภาพ การออกแบบเครือข่าย และการจัดการสายเคเบิล

---

บทนำและที่มา

• การพรีเทรนโมเดลสำหรับการใช้งานคอมพิวเตอร์ต้องใช้ ข้อมูลวิดีโอปริมาณมหาศาล
• ในขณะที่ LLM แบบข้อความทั่วไป (เช่น LLaMa-405B) ใช้ข้อมูลเพียงราว 60TB ก็เพียงพอ แต่การฝึกแบบวิดีโอต้องการ พื้นที่จัดเก็บมากกว่า 500 เท่า
• หากใช้พับลิกคลาวด์อย่าง AWS จะมีค่าใช้จ่าย 12 ล้านดอลลาร์ต่อปี แต่การ เช่าศูนย์โคโลเคชันและสร้างระบบเอง ช่วยลดลงมาเหลือประมาณ 354,000 ดอลลาร์ ได้
• การเก็บข้อมูลขนาดใหญ่ไว้เองช่วยแก้ปัญหาที่ ต้นทุนข้อมูลเป็นข้อจำกัดที่ใหญ่ที่สุด

ทำไมถึงสร้างเอง

• คลาวด์เน้น ความน่าเชื่อถือสูง ความซ้ำซ้อน และความถูกต้องสมบูรณ์ของข้อมูล แต่ข้อมูลสำหรับพรีเทรนนั้นไม่ได้วิกฤตถึงขั้นนั้น และสามารถ ยอมรับการสูญหาย 5% ได้
• ด้วยคุณลักษณะนี้ จึงสามารถกำหนดเงื่อนไขด้านความน่าเชื่อถือให้ผ่อนคลายกว่าองค์กรทั่วไปมากได้ (ใช้ 2 nines แทน 13 nines)
• ราคาสตอเรจถูกตั้งไว้สูงกว่าต้นทุนจริงมาก
• เนื่องจากข้อมูลเป็นองค์ประกอบต้นทุนที่ใหญ่ที่สุด และค่าใช้จ่ายของดาต้าเซ็นเตอร์ภายในก็คาดการณ์ได้เพียงพอ จึงตัดสินใจว่าการสร้างแบบโลคัลคุ้มกว่า

เปรียบเทียบต้นทุน: คลาวด์ vs สร้างเอง

• ค่าใช้จ่ายรายเดือนแบบ recurring: อินเทอร์เน็ต $7,500 + ไฟฟ้า $10,000 = รวม $17,500
• ค่าใช้จ่ายครั้งเดียว: ฮาร์ดไดรฟ์ $300,000, แชสซี $35,000, โหนด CPU $6,000, ค่าติดตั้ง $38,500, ค่าแรง $27,000, ค่าเครือข่ายและค่าใช้จ่ายติดตั้งอื่น ๆ $20,000 → รวม $426,500
• เมื่อรวมค่าเสื่อมราคา (3 ปี) คิดเป็นต้นทุนคงที่รายเดือน $29,500
• AWS เดือนละ $1,130,000, Cloudflare R2 เดือนละ $270,000, สร้างเองเดือนละ $29,500
  • AWS: ประมาณ 38 ดอลลาร์ต่อ TB/เดือน
  • Cloudflare: ประมาณ 10 ดอลลาร์ต่อ TB/เดือน
  • สร้างเอง: 1 ดอลลาร์ต่อ TB/เดือน
• ในการฝึกโมเดลขนาดใหญ่ แม้แต่ Cloudflare ก็ยังเกิดปัญหา rate-limit จากภาระหนักในระบบภายใน แต่ในสภาพแวดล้อมที่สร้างเองสามารถแก้ด้วยลิงก์เฉพาะ 100Gbps

การสร้างและกระบวนการ

• เพื่อให้สร้างได้อย่างรวดเร็ว จึงวางแผน Storage Stacking Saturday(S3) โดยอาศัยความช่วยเหลือจากคนรู้จักและผู้รับเหมามืออาชีพ
• ภายใน 36 ชั่วโมง มีการติดตั้งฮาร์ดไดรฟ์ 2,400 ลูกลงแร็กจนฮาร์ดแวร์ 30PB เสร็จสมบูรณ์
• ซอฟต์แวร์คือ Rust (เขียนข้อมูล, 200 บรรทัด) + nginx (อ่านข้อมูล) + SQLite (ติดตามเมทาดาทา)
  • ไม่ใช้ Ceph, MinIO, Weka, Vast เป็นต้น เพราะปัญหาด้านความซับซ้อน/ต้นทุน (ซับซ้อนเกินไป ไม่จำเป็น ภาระดูแลรักษาสูง)
  • ฟอร์แมตไดรฟ์ทั้งหมดเป็น XFS

ข้อเสนอแนะและบทเรียนจากโครงการ

สิ่งที่ทำได้ดี

• ใช้ trade-off ระหว่างความซ้ำซ้อนกับประสิทธิภาพ ได้เหมาะสม จนใช้งานเครือข่าย 100G ได้เกือบเต็ม
• สร้างไว้ใกล้สถานที่ทำงานจริง จึงได้ ความสะดวกในการดีบักและบำรุงรักษา
• หาเวนเดอร์ผ่าน eBay แต่ซื้อจริงโดยติดต่อกับซัพพลายเออร์รายบุคคลโดยตรง พร้อมเน้นความสำคัญของประกัน
• ลิงก์อินเทอร์เน็ต 100G มีข้อดีมาก และปัญหาเครือข่ายก็สามารถดีบักเองได้ง่าย
• การจัดการสายเคเบิลคุณภาพสูง ช่วยได้มากในการแก้ปัญหาภายหลัง
• ใช้หลักการ ทำให้ง่ายเข้าไว้ แทนระบบจัดเก็บโอเพนซอร์สที่ซับซ้อน เพื่อลดภาระการดูแลรักษาให้น้อยที่สุด
• การคาดการณ์ต้นทุนเวลา/แรงงานก็แม่นยำ และยืนยันได้ชัดเจนถึงผลของการลดต้นทุน

ความยากและสิ่งที่ลองผิดลองถูก

• การใช้ front-loader ทำให้ต้องใส่ HDD ทั้ง 2,400 ลูกทีละลูกด้วยมือ ซึ่งยุ่งยากมาก
• ความหนาแน่นของสตอเรจยังไม่พอ และหากเลือกความหนาแน่นสูงกว่านี้ตั้งแต่ต้นอาจลดแรงงานได้
• การทำ daisy chain ก่อให้เกิดคอขวดด้านความเร็ว และอุดมคติคือเชื่อม HBA แยกให้แต่ละแชสซี
• อุปกรณ์เครือข่ายต้องคำนึงถึงความเข้ากันได้ของแบรนด์ โดยเฉพาะ optical transceiver
• ใช้เวลาไปกับการทดลอง/ตั้งค่าเครือข่ายพอสมควร โดยจัดระบบให้เน้นประสิทธิภาพและความสะดวกมากกว่า DHCP/NAT (ใช้เพียงข้อกำหนดขั้นต่ำของ firewall/secure link)
• ได้ตระหนักถึงความสำคัญของการเข้าถึงอุปกรณ์ทางกายภาพ รวมถึงการเดินสายสำหรับมอนิเตอร์/คีย์บอร์ดตอนตั้งระบบ

ไอเดียที่น่าลอง

• ใช้ KVM และ IPMI เพื่อเพิ่มประสิทธิภาพการจัดการระยะไกล
• แนะนำให้แยกเครือข่าย Ethernet สำหรับผู้ดูแลระบบต่างหาก
• ควรเผื่อขนาดเครือข่ายไว้เกินความต้องการ (เช่น อาจพิจารณาเครือข่ายภายใน 400G)
• ใช้เซิร์ฟเวอร์ความหนาแน่นสูงกว่า (เช่น 90-drive Supermicro / 20TB HDD) เพื่อ
  ลดจำนวนแร็ก ลดการใช้พลังงาน และได้ประโยชน์ด้านการรวม CPU

จะสร้างเองได้อย่างไร

องค์ประกอบสตอเรจ

• CPU head node 10 เครื่อง (เช่น Intel RR2000 โดยแนะนำ dual Intel Gold 6148 / 128GB ECC DDR4 RAM ต่อเซิร์ฟเวอร์)
  • หากใช้ฟังก์ชันที่กิน CPU สูง (เช่น ZFS) อาจเลือกอุปกรณ์ประสิทธิภาพสูงกว่านี้ได้
• แชสซี DS4246 จำนวน 100 ตัว (แต่ละตัวใส่ HDD ได้ 24 ลูก)
• HDD ขนาด 3.5" จำนวน 2,400 ลูก (ถ้าเป็นไปได้แนะนำ SAS drive เพราะได้เปรียบด้านความเร็ว)
  • ผสมหลายความจุได้ (12TB, 14TB เป็นต้น) และยิ่งความจุสูงยิ่งได้เปรียบเรื่องการจัดวาง/มูลค่ามือสอง
• ราง/ขายึดสำหรับติดตั้งจริง รวมถึงสายอุปกรณ์และสายเคเบิลต่าง ๆ
• crash cart หลายชุดสำหรับดีบักปัญหาเครือข่าย (มอนิเตอร์ + คีย์บอร์ด)

โครงสร้างพื้นฐานเครือข่าย

• สวิตช์ 100GbE (เช่น Arista มือสอง พร้อมพอร์ต QSFP28)
• HBA สำหรับแต่ละเซิร์ฟเวอร์ (แนะนำ: Broadcom 9305-16E เป็นต้น) รวมถึงรูปแบบการเชื่อมต่อพอร์ต HBA/แชสซี
• การ์ดเครือข่าย (เช่น Mellanox ConnectX-4 และต้องเป็นโหมด Ethernet)
• สาย DAC/AOC — หากต้องพิจารณาระยะห่างระหว่างแร็ก DAC จะได้เปรียบด้านความเข้ากันได้
• แนะนำให้ใช้ซัพพลายเออร์ที่ติดตั้ง HBA/NIC มาให้ล่วงหน้าเมื่อซื้อ CPU head node
• สาย serial, เครือข่าย Ethernet สำหรับจัดการแยกต่างหาก (หรือใช้อะแดปเตอร์ไร้สายสำรอง + mini switch เป็นทางเลือก)

ข้อกำหนดของดาต้าเซ็นเตอร์

• สมมติ กำลังไฟ 3.5kW ต่อหนึ่งตู้, และใช้รูปแบบ 4U×10 + 2U×1 บนมาตรฐาน 42U
• 3PB ต่อตู้, และมี ตู้ 42U สำรอง 1 ตู้ สำหรับสวิตช์ หรืออาจแทนด้วยแชสซี 1U
• ต้องมี 100G cross-connect เฉพาะ (โดยทั่วไปใช้ QSFP28 LR4 แบบไฟเบอร์หนึ่งคู่) และต้องตรวจสอบ ความเข้ากันได้ของ form factor และแบรนด์ ล่วงหน้า
• แนะนำให้เลือก โคโลเคชันที่อยู่ใกล้ออฟฟิศ เพราะหากมีปัญหาจะเข้าถึงหน้างานได้เร็ว ช่วยเพิ่ม ประสิทธิภาพในการดีบักและปฏิบัติการ

เคล็ดลับสำหรับการตั้งค่าเริ่มต้น

• หลังจาก ตั้งค่าสวิตช์ผ่าน local console ครั้งแรก ควรตรวจสอบ การตั้งค่าพอร์ต uplink 100GbE และ ความเข้ากันได้ของ optical transceiver ก่อน
  • หากจำเป็น สามารถ ต่อไฟเบอร์จาก ISP เข้ากับ NIC โดยตรง เพื่อตรวจสอบ link-up ก่อนแล้วค่อยย้ายกลับมาที่สวิตช์
• ระหว่างติดตั้ง Ubuntu ควรตั้งค่าเครือข่ายของโหนดให้เสร็จผ่าน Netplan ไปเลย จะสะดวกกว่า
• หลังจากให้โหนดเชื่อมต่ออินเทอร์เน็ตแล้ว ให้ทำตามลำดับ เชื่อม DS4246 ทีละ 1 สาย → ฟอร์แมต/เมานต์ → ตรวจสอบสถานะ เพื่อให้ตรวจพบ ปัญหาการเดินสายหรือดิสก์เสีย ได้เร็ว

ข้อควรระวังด้านประสิทธิภาพ·เสถียรภาพและความปลอดภัย

• ภายใต้สมมติฐานด้านความปลอดภัยว่าใช้สำหรับ ข้อมูลฝึกเท่านั้น จึงดำเนินงานแบบเรียบง่ายด้วย ต่อ public IP ตรง + firewall รายพอร์ต + nginx secure_link
  • หากเป็น ข้อมูลลูกค้า โครงสร้างแบบเดียวกันนี้ ไม่เหมาะสม และจำเป็นต้องมี DHCP/NAT/ไฟร์วอลล์แบบแยกละเอียด
• daisy chain แม้จะจัดการและเดินสายง่าย แต่ก่อให้เกิด คอขวดด้านแบนด์วิดท์ ดังนั้นถ้าเป็นไปได้ควรใช้ HBA แยกต่อหนึ่งแชสซี
• optical transceiver มี brand lock-in สูงมาก ควรจัดหาจากทั้ง FS.com และ Amazon ควบคู่กัน แต่ต้องตรวจสอบ สเปกและแบรนด์ให้ตรงกัน อย่างเคร่งครัด

บทสรุปและความหมาย

• สตอเรจภายในต้นทุนต่ำมากระดับ $1/TB-เดือน ทำให้การ พรีเทรนวิดีโอ 30PB เป็นจริงได้ พร้อมลดต้นทุนได้ 10–38 เท่าเมื่อเทียบกับคลาวด์
• สถาปัตยกรรมที่เรียบง่าย และ การเข้าถึงหน้างานได้สะดวก ช่วยลดทั้ง เวลาและความเสี่ยง ขณะที่ ลิงก์เฉพาะ 100G ช่วยแก้ปัญหา คอขวด I/O
• ในยุคของโมเดล มัลติโหมดและวิดีโอ ขนาดใหญ่ ความสามารถแข่งขันที่สำคัญคือ โครงสร้างพื้นฐานข้อมูลขนาดใหญ่ต้นทุนต่ำ และแนวทางนี้ก็เป็น ตัวอย่างใช้งานจริง ที่ทีมขนาดเล็กก็ทำได้

ปิดท้ายและการร่วมมือ

• หากอ้างอิงบทความนี้ไปสร้างคลัสเตอร์สตอเรจลักษณะคล้ายกัน ยินดีให้แบ่งปันประสบการณ์และข้อปรับปรุง
• ขณะนี้กำลังรับสมัครบุคลากรด้านการพรีเทรนโมเดลการใช้งานคอมพิวเตอร์ขนาดใหญ่ รวมถึงงานวิจัย AI ด้านการทำให้เป็นสากลและการสอดคล้องกับคุณค่ามนุษย์ (ติดต่อ [e-mail])

[GN⁺]

ความเห็นจาก Hacker News

• ตอนเริ่มต้นอาชีพใหม่ ๆ สภาพแวดล้อมแบบ on-premises เป็นเรื่องปกติ ฮาร์ดแวร์ที่ใช้งานได้นานสุดท้ายก็มักถูกดูแลเอาใจใส่จนแต่ละเซิร์ฟเวอร์มีสภาพเฉพาะตัวสะสมไปตามเวลา พอเวลาผ่านไปและประสิทธิภาพของฮาร์ดแวร์เริ่มไม่พอ ก็ต้องเลือกฮาร์ดแวร์ใหม่จากรายการเดิมผ่านทีมภายใน และยังต้องขออนุมัติงบเพิ่มด้วย เลยค่อนข้างยุ่งยาก บางครั้งโปรเจ็กต์ก็ล่าช้าระหว่างกระบวนการเปลี่ยนฮาร์ดแวร์ หรือช่วงที่ต้องแยกอุปกรณ์ที่ดูแลกันเหมือนสัตว์เลี้ยงออกอย่างละเอียดเพื่อย้ายไปใช้อุปกรณ์ใหม่ พอคลาวด์เข้ามา ก็เลยคิดว่า “ต่อจากนี้ต้องย้ายขึ้นคลาวด์ทั้งหมด” แต่พอเวลาผ่านไป ตัวเราและองค์กรก็ลืมวิธีจัดการฮาร์ดแวร์ด้วยตัวเองไป สุดท้ายถ้าไม่ฟื้นทักษะนั้นกลับมา คลาวด์ที่เคยเป็นตัวเลือกที่ดี ก็จะค่อย ๆ น่าดึงดูดน้อยลงเรื่อย ๆ เพราะงั้นขอบคุณที่ช่วยให้ทักษะแบบนี้กลับมาอีกครั้ง

  • พวกเราอยู่ในสถานการณ์ที่ค่อนข้างแปลก ตั้งแต่แรกก็ไม่สามารถแบกรับค่าใช้จ่ายการดำเนินงานของ hyperscale cloud ได้อยู่แล้ว เลยจำเป็นต้องพัฒนาความสามารถภายในของตัวเองมา คิดดูแล้วก็ไม่ได้ยากอย่างที่คิด และอย่างน้อยช่วงนี้ก็มีแผนจะทำแบบนี้ต่อไป เพียงแต่ปัญหาเรื่องสภาพสะสมที่พูดถึงก็เริ่มเห็นบ้างแล้ว

  • on-premises ในความทรงจำของผมถูกกว่ามาโดยตลอด มีข้อดีตรงที่อุปสรรคด้านโลจิสติกส์หลายอย่างหายไป และทุกอย่างสะดวกขึ้นด้วยบิลใบเดียว ตอนที่คลาวด์กำลังบูม คำแนะนำที่ได้ยินตลอดคือให้ใช้ on-premises เป็นหลัก และใช้คลาวด์เฉพาะเวลาที่ทราฟฟิกขึ้นลงแบบฉับพลัน แต่การขยายระบบชั่วคราวค่อย ๆ กลายเป็นการใช้งานถาวร และนักพัฒนาก็เริ่มพึ่งพาการเปิดเครื่องใหม่ได้ทันทีเพียงอย่างเดียว ตอนนี้ทุกคนมองว่าคลาวด์คือสภาวะปกติไปแล้ว ในกระบวนการนั้นเราสูญเสียพื้นฐานในการรับรู้ต้นทุนที่แท้จริงไป และช่องว่างด้านต้นทุนระหว่างคลาวด์กับ on-premises ก็ยิ่งกว้างขึ้นเรื่อย ๆ

  • Docker เป็นเครื่องมือที่ยอดเยี่ยมมากในการทำให้เซิร์ฟเวอร์ไม่ถูกมองเป็นสัตว์เลี้ยงอีกต่อไป เซิร์ฟเวอร์ในแร็กก็กลายเป็นแค่อีกหนึ่ง K3 หรือ K8 node จึงไม่ถูกปฏิบัติแบบของรักของหวง จุดนี้ดีมาก จะพูดแบบเดียวกันกับ VM ก็ได้เหมือนกัน แต่สุดท้ายตัว VM เองก็มักกลายเป็นสัตว์เลี้ยงอยู่ดี ถึงจะสร้าง image หรือ snapshot ได้ก็เถอะ แต่ความเปลี่ยนแปลงที่รู้สึกจาก Docker มันคนละแบบ

  • ขอถามแบบติดตลกหน่อยว่า จะลองท้าทายแบบนี้อีกสักรอบไหม

• สตาร์ตอัปที่มีเงินมากพอจะซื้อโดเมนสองตัวอักษร .inc ได้แบบไม่สะทกสะท้าน คือสตาร์ตอัปที่มีเงินมากเกินไป เป็นอาการแบบเดียวกับการนับจำนวนเก้าอี้ Aeron ในออฟฟิศของสตาร์ตอัปสมัยก่อน ซึ่งไม่ใช่สัญญาณที่ดี

  • โดเมน .inc สองตัวอักษรที่ยังไม่ได้ใช้งานกำลังขายอยู่ที่ปีละ $2300 ซึ่งยังไม่ถึง 5% ของต้นทุนพนักงานนักพัฒนาหนึ่งคนด้วยซ้ำ

  • ยังสงสัยว่าโดเมน .inc มีมูลค่าจริงในทางปฏิบัติหรือไม่

• เป็นบทความที่สนุก อ่านแล้วรู้สึกเหมือนได้สนองแทน ถ้ามีรูปมากกว่านี้อีกหน่อยน่าจะสนุกขึ้นไปอีก

  • ถ้าผู้เขียนเข้ามาคอมเมนต์ ผมอยากถามตรง ๆ ว่า Standard Intelligence PBC ทำอะไรกันแน่ เป็น Public Benefit Corporation หรือเปล่า หรือกำลังทำโปรเจ็กต์อะไรอยู่

• ชอบที่เขียนรายละเอียดเชิงเทคนิคไว้เยอะดี แต่อยากรู้ว่ากระบวนการหา colocation space เป็นอย่างไร ใช้ broker หรือไม่ และหลังเจรจาราคาแล้ว ราคาที่จ่ายจริงต่างจากใบเสนอราคาแรกมากแค่ไหน

  • เราส่งคำขอใบเสนอราคาไปยังผู้ให้บริการ colocation ส่วนใหญ่ในซานฟรานซิสโกและฟรีมอนต์ ไม่มีความต่างระหว่างใบเสนอราคากับราคาที่จ่ายจริง แต่มีการเจรจาเรื่องเงื่อนไขและค่าใช้จ่ายแบบครั้งเดียว

• บล็อกโพสต์ของ Discord ที่ลิงก์ไว้ก็น่าสนใจเช่นกัน ส่วนใหญ่เป็นเรื่องจริงจัง แต่ก็มีช่วงสนุก ๆ แบบนี้: พอมีประตูในฟุตบอลโลก ข้อมูลนั้นจะสะท้อนขึ้นบนกราฟมอนิเตอร์ทันที ทำให้สมาชิกทีมสามารถอ้างได้ว่ากำลังดูฟุตบอลระหว่างประชุมในนามของการมอนิเตอร์งาน และยังถูกอ้างเป็นหลักฐานการใช้งานจริงของระบบ หรือเป็นหลักฐานว่า Discord เก็บข้อความไว้ด้วยสตอเรจ “ต่ำกว่าระดับเพตะไบต์” ถ้าเดาจากขนาดและจำนวน node ในบทความนี้ คลัสเตอร์เดิมน่าจะอยู่ราว 708TB และเซ็ตอัปใหม่ราว 648TB (รวมเผื่อการเติบโตแล้ว)

• ตัวสตอเรจเองราคาถูกมาก แต่ผมไม่เข้าใจส่วนการเทรนนิงกับการตั้งค่าเครือข่าย จากคอมเมนต์อื่นเหมือนจะได้ยินว่า GPU ไม่ได้อยู่ที่เดียวกัน ถ้าเป็นแบบนั้นก็ต้องส่งข้อมูลเทรนนิงข้ามหลายไซต์ด้วย 100Gbps เท่านั้น แบบนี้จะไม่เกิดคอขวดระหว่าง pretraining หรือ

  • ตอนนี้เรามีเพียงลิงก์ 100 กิกะเส้นเดียว และตอนนี้ GPU cluster เองก็รองรับการรับส่งข้อมูลได้ประมาณเท่านั้นเหมือนกัน อนาคตเมื่อขยายระบบก็จะเพิ่มทั้งแบนด์วิดท์และสตอเรจ อีกอย่างคือเรามี 4090 หลายตัวอยู่ใน colo ซึ่งมีประโยชน์มากสำหรับงานแบ่งข้อมูลหรือทำ embedding

• สำหรับเวิร์กโหลดระดับนี้ ก็น่าจะขอใบเสนอราคาแบบ private จาก AWS หรือคลาวด์เจ้าอื่นได้สบาย ๆ แล้ว อย่าง S3 ถ้ามีแค่ 0.5PB ก็น่าจะขอราคาเฉพาะได้ ต้นทุนรวมอาจไม่ได้แปลว่าถูกกว่าการดูแลเองเสมอไป แต่การเอาราคา retail ของ CSP มาเทียบกับอุปกรณ์จาก eBay + แรงงานฟรี (ไม่รวมค่าพิซซ่า) ก็ไม่ใช่การเปรียบเทียบที่สมบูรณ์นัก

  • สำหรับ AWS หรือคลาวด์ ต้นทุน egress คือประเด็นสำคัญจริง ๆ ส่วนนั้นต่อให้พยายามเจรจาก็ไม่ยอมลดให้เลย สำหรับ AI training ถือว่าแทบใช้งานไม่ได้เลย ส่วนใบเสนอราคาของ Cloudflare ก็ถือว่าถูกเมื่อเทียบกับ managed object bucket storage เจ้าอื่น การสร้างคลัสเตอร์เองทำให้ช่องว่างกับ managed service แคบลงจริง และการทำเองก็ช่วยเพิ่มอำนาจต่อรองด้วย แต่ managed bucket นั้นเกินความจำเป็นมากสำหรับการเก็บข้อมูล pretraining อย่างเดียว ส่วน Glacier คุ้มค่าสำหรับงาน archive แต่ยังไม่มีผลิตภัณฑ์ที่ลงตัวพอดีสำหรับงาน ML

  • อยากรู้ว่าจริง ๆ แล้วจะต่อรองดีลได้ระดับไหน ลดเกินครึ่งได้ไหม

• สนุกมากที่ได้ช่วยกันใส่ไดรฟ์ งานที่ได้จัดการกับข้อมูลมหาศาลแบบนี้คือประสบการณ์ที่น่าตื่นเต้นที่สุด :P

• ไม่มีการพูดถึงอัตราการเสียของดิสก์เลย เลยอยากรู้ว่าผ่านไปหลายเดือนแล้วสภาพเป็นอย่างไรบ้าง

  • เป็นประสบการณ์ที่เคยเล่าไว้ก่อนหน้านี้ ตอนติดตั้ง disk array หลายชุด เคยเจอไดรฟ์เสียเป็นจำนวนมาก วันศุกร์ช่วงบ่ายเราตั้งแร็กเสร็จแล้วปล่อยทิ้งไว้ทั้งสุดสัปดาห์ โดยรันการทดสอบอ่าน/เขียนข้อมูลด้วยเชลล์สคริปต์ง่าย ๆ โดยไม่แตะต้องอะไร พอมาถึงวันจันทร์ ดิสก์เกือบครึ่งเสียไปแล้วโดยไม่มี log ใด ๆ ทิ้งไว้เลย ไม่รู้ว่าเป็นปัญหาจากขั้นตอน striping หรือพังเพราะ stress test กันแน่ รู้แค่ว่าเป็นล็อตเสียจากโรงงาน และลูกค้าหลายรายของบริษัทเดียวกันก็ร้องเรียนเหมือนกัน ผู้ผลิตเปลี่ยนให้ทั้งหมด และมีแค่การนำขึ้น production ที่ล่าช้าไป หลังจากนั้นตลอด 1 ปีก็ไม่มีปัญหาอีกเลย

  • ช่วง 10 ปีหลังมานี้อัตราการเสียของดิสก์ลดลงมากเมื่อเทียบกับเมื่อก่อน สมัยก่อนเคยเปลี่ยนมากกว่า 10 ลูกต่อสัปดาห์ แต่ตอนนี้กลายเป็นเรื่องที่เกิดขึ้นไม่บ่อย คิดว่าแค่ดูสถิติฮาร์ดดิสก์ของ Backblaze ก็เพียงพอแล้ว

  • ในคลัสเตอร์นั้นบอกว่าใช้ไดรฟ์ระดับ enterprise แต่ถ้าประหยัดต้นทุนมากเกินไป สุดท้ายอาจขาดทุนหนักกว่าเดิม ส่วนตัวเคยลองใช้ไดรฟ์มือสองกับโฮมเซิร์ฟเวอร์แล้วพบว่าความแปรปรวนด้านประสิทธิภาพสูงมาก เลยไม่ค่อยชอบ

  • เป็นข้อสังเกตที่ดี