สถาปัตยกรรม AI Data Pipeline: ป้อนข้อมูลการฝึกสอนระดับ Petabyte ด้วยความเร็ว 100GB/s

อัปเดต 11 ธันวาคม 2025

อัปเดตธันวาคม 2025: Data PreProcessing Service (DPP) ของ Meta ขจัดปัญหาการรอข้อมูลในคลัสเตอร์ฝึกสอนระดับ Exabyte แล้ว WEKApod บรรลุ throughput 720GB/s จาก 8 storage node สำหรับ H100 GPU 768 ตัว NVMe SSD แบบ PCIe Gen5 ที่อ่านข้อมูลแบบ sequential ได้เกิน 14GB/s กลายเป็นมาตรฐานสำหรับ storage ระดับ training tier Feature store และสถาปัตยกรรม tiered caching ลด latency ในการเข้าถึง cold data ได้ถึง 10 เท่า

Meta ค้นพบว่า 56% ของ GPU cycle หยุดรอข้อมูลสำหรับการฝึกสอน[^1] บริษัทเก็บข้อมูลฝึกสอนระดับ Exabyte ใน Tectonic ซึ่งเป็น distributed file system ของพวกเขา แต่ขาดความจุ storage ที่จะเก็บ dataset ระดับ Petabyte ไว้ใกล้กับ training hardware[^2] ทางออกคือการสร้าง Data PreProcessing Service (DPP) ที่ scale ได้เพื่อขจัดการรอข้อมูลทั้งหมด องค์กรที่ฝึกสอน large model เผชิญความท้าทายพื้นฐานเดียวกัน: GPU ที่ทรงพลังที่สุดไม่สามารถทำอะไรได้เลยขณะรอข้อมูล input

Storage ที่ป้อนการฝึกสอน AI กำหนดว่าการลงทุนใน GPU จะได้ผลตอบแทนตามที่คาดหวังหรือไม่ WEKApod บรรลุ throughput มากกว่า 720GB/s และ 18 ล้าน IOPS ด้วย latency ต่ำกว่า 150 microsecond สำหรับ H100 GPU 768 ตัวจาก storage node เพียง 8 ตัว[^3] RSC supercomputer ของ Meta ใช้ cache storage 46 petabyte เพื่อป้อน GPU อย่างต่อเนื่อง[^4] การฝึกสอน GPT-4 ใช้ A100 GPU ประมาณ 25,000 ตัวประมวลผล 13 ล้านล้าน token ตลอด 90-100 วัน[^5] ในระดับนี้ สถาปัตยกรรม data pipeline มีความสำคัญเทียบเท่ากับสถาปัตยกรรม compute

ความท้าทายของ data pipeline

Large language model ต้องการเข้าถึงข้อมูลที่ผ่านการ preprocess และมีคุณภาพสูงในระดับ Petabyte หากไม่มี storage ที่เร็วและเชื่อถือได้ แม้แต่ GPU ที่ทรงพลังที่สุดก็หยุดรอ input[^6] Performance tier ของโครงสร้างพื้นฐาน storage ช่วยให้ข้อมูลไหลอย่างราบรื่นผ่านขั้นตอน pipeline ที่ใช้ compute หนัก: normalization, tokenization และ training

Machine learning pipeline ทั่วไปประกอบด้วย data preprocessing ที่จัดการโดย CPU, model training ที่ส่งไปยัง GPU และ post-processing ที่กลับมาที่ CPU[^7] Bottleneck เกิดขึ้นเมื่อถ่ายโอนข้อมูลระหว่าง CPU RAM และ GPU DRAM ความไม่สมดุลระหว่าง storage throughput, network bandwidth, preprocessing compute และการบริโภคของ GPU สร้างการหยุดชะงักที่ทำให้เสีย accelerator capacity ราคาแพง

สถาปัตยกรรม data storage และ ingestion ของ Meta

End-to-end DSI pipeline ของ Meta ประกอบด้วย central data warehouse ที่สร้างบน distributed storage และ Data PreProcessing Service ที่ scale preprocessing แยกจาก training compute[^8] สถาปัตยกรรมแยก storage, preprocessing และ training ออกเป็น tier ที่ scale ได้แยกกัน

Tectonic ทำหน้าที่เป็น distributed file system ระดับ Exabyte ของ Meta โดยให้โครงสร้างพื้นฐาน disaggregated storage สำหรับ AI training model[^9] บริษัทฝึกสอน model บน dataset ระดับ Terabyte ถึง Petabyte โดยไม่ต้องมีความจุ local storage ที่ตรงกับขนาดเหล่านั้น Disaggregated storage ช่วยให้จัดสรรทรัพยากรได้ยืดหยุ่น แต่ต้องการ network bandwidth สูงที่เชื่อมต่อ storage กับ compute

DPP Master รับ session specification ที่มี dataset table, partition, feature ที่ต้องการ และ transformation operation[^10] Master แบ่งงาน preprocessing บนข้อมูลระดับ Petabyte ออกเป็น work item อิสระที่เรียกว่า split DPP Worker ขอ split จาก Master และดำเนินการ preprocessing transformation โดยแยก preprocessing throughput ออกจาก CPU capacity ของ training node

Storage hierarchy และ caching

Meta สร้างทางไปสู่ tiered storage solution ที่รวม HDD และ SSD โดยให้ SSD ทำหน้าที่เป็น caching tier สำหรับ feature ที่ใช้บ่อย[^11] ไม่ใช่ training data ทั้งหมดที่ต้องการ access pattern เดียวกัน: feature ที่เข้าถึงบ่อยได้ประโยชน์จาก flash storage ขณะที่ cold data ยังอยู่บน media ที่เน้นความจุ

กลยุทธ์ caching ลดต้นทุน storage โดยไม่เสียสละ training throughput Hot data ที่อยู่ใน fast tier ให้บริการการอ่านส่วนใหญ่ ขณะที่ cold data stream จาก capacity storage ในช่วง epoch แรก การเข้าใจ data access pattern ช่วยให้ตัดสินใจ tiering อย่างชาญฉลาดที่สมดุลต้นทุนกับประสิทธิภาพ

เทคโนโลยี storage สำหรับ AI training

เทคโนโลยี storage แต่ละชนิดให้บริการบทบาทต่างกันใน AI data pipeline การเลือกขึ้นอยู่กับ access pattern, ความต้องการความจุ และข้อจำกัดด้านงบประมาณ

Parallel file system

Parallel file system เช่น Lustre และ GPFS ให้ประสิทธิภาพสูงสุดด้วย concurrency มหาศาล เหมาะสำหรับ AI workload ที่ต้องการ synchronous I/O หนัก[^12] ระบบเหล่านี้ stripe ข้อมูลข้าม storage server หลายตัว ให้ aggregate bandwidth ที่ scale ตามจำนวน server

Google Cloud เสนอ Managed Lustre เป็น high-performance cache เหนือ Cloud Storage เร่ง AI workload ที่ต้องการ throughput สูงมากและ I/O operation ที่ latency ต่ำ[^13] องค์กร import และ export ข้อมูลระหว่าง Managed Lustre และ Cloud Storage ใช้ parallel file system เป็น performance tier สำหรับ active training ขณะรักษาข้อมูลใน object storage เพื่อความทนทาน

NVMe storage

NVMe SSD แบบ PCIe Gen5 อ่าน sequential throughput เกิน 14 GB/s และรองรับ random read IOPS หลายล้าน[^14] เทคโนโลยีนี้ขจัด storage ในฐานะ bottleneck เมื่อฝึกสอน AI model บนข้อมูลหลายสิบ terabyte การนำ PCIe Gen5 มาใช้ตลอดปี 2024-2025 เพิ่ม throughput ต่อ lane เป็นสองเท่าเป็นประมาณ 4 GB/s ต่อ lane ถึง 64 GB/s ใน configuration แบบ x16

NVMe-oF (NVMe over Fabrics) ขยายประสิทธิภาพ NVMe ข้าม network ทำให้สถาปัตยกรรม disaggregated storage รักษา latency ใกล้เคียง local ได้ Training cluster เข้าถึง shared NVMe storage pool โดยไม่เสียข้อได้เปรียบด้านประสิทธิภาพของ drive ที่ต่อตรง

Object storage สำหรับ cold data

Object storage ให้ความจุที่คุ้มค่าสำหรับ dataset ระดับ Petabyte ที่ทน latency สูงได้ บริษัท e-commerce ขนาดใหญ่แห่งหนึ่งเก็บ training data หลายร้อย petabyte ใน AWS S3 โดย AI/ML training workload กระจายข้ามหลาย AWS region และ data center ภายในองค์กร[^15]

Object storage เหมาะที่สุดสำหรับ batch ingestion pattern ที่ training job โหลดข้อมูลเข้า tier ที่เร็วกว่าก่อนเริ่มการประมวลผลหนัก เศรษฐศาสตร์เอื้อให้ object storage สำหรับ archive และ backup ขณะที่ performance tier จัดการ active training I/O

Preprocessing ในระดับใหญ่

Data preprocessing ใช้ทรัพยากร compute มาก และมักกลายเป็น bottleneck ที่ป้องกันการใช้ GPU เต็มที่ ประสบการณ์ของ Meta แสดงว่า CPU บน trainer node ไม่สามารถ preprocess ข้อมูลเร็วพอที่จะป้อน GPU ทำให้เกิดสถาปัตยกรรม DPP แบบกระจาย[^16]

Distributed preprocessing worker

สถาปัตยกรรม DPP scale preprocessing worker แยกจาก training node[^17] การเพิ่มความจุ preprocessing ต้องการเพียงเพิ่ม worker instance ไม่ต้องแก้ไขโครงสร้างพื้นฐาน training การแยกนี้ช่วยให้องค์กรปรับขนาด preprocessing compute ให้เหมาะกับ dataset และความซับซ้อนของ transformation เฉพาะได้

Worker instance ดำเนินการ transformation operation รวมถึง cleaning, normalization, tokenization และ feature extraction Transformation ที่ซับซ้อนต้องการ preprocessing compute มากขึ้นต่อหน่วย training throughput Transformation ที่ง่ายอาจตามทัน training ได้ด้วยทรัพยากร preprocessing น้อยที่สุด

Accelerated preprocessing

ความพยายามในอุตสาหกรรมเพิ่มมากขึ้นในการดำเนินการ preprocessing transformation operation บน accelerator แทน CPU[^18] NVIDIA DALI (Data Loading Library) ย้าย image decoding, augmentation และ format conversion ไปที่ GPU Accelerated preprocessing ขจัด CPU bottleneck สำหรับ image และ video training pipeline

การย้าย preprocessing ไปที่ GPU ต้องการการออกแบบ pipeline อย่างระมัดระวังเพื่อหลีกเลี่ยงการสร้าง bottleneck ใหม่ GPU memory ที่ใช้สำหรับ preprocessing ลด memory ที่มีสำหรับ model parameter และ activation การแลกเปลี่ยนระหว่าง preprocessing acceleration และ training capacity ขึ้นอยู่กับลักษณะของ workload

Feature store

Google แนะนำให้ใช้ Vertex AI Feature Store สำหรับ feature ที่พร้อมสำหรับ online serving[^19] Feature store precompute และ cache feature value ขจัดการคำนวณซ้ำข้าม training run การตั้งเวลา feature engineering job ให้คำนวณ feature value ใหม่ตาม cadence ที่ต้องการช่วยให้ข้อมูลสดใหม่โดยไม่มี overhead ของ real-time preprocessing

Feature store มีค่าเป็นพิเศษสำหรับ recommendation model ที่ความซับซ้อนของ feature computation เกิน time budget ต่อ request Training และ inference สามารถเข้าถึง precomputed feature เดียวกันได้ รักษาความสอดคล้องระหว่าง development และ production

สถาปัตยกรรม network สำหรับ data pipeline

High-bandwidth interconnect เป็นรากฐานสำหรับสถาปัตยกรรม disaggregated storage InfiniBand และ RoCE (RDMA over Converged Ethernet) ให้ ultra-low latency และ high throughput ที่จำเป็นสำหรับ distributed training ข้าม GPU cluster และการเข้าถึง dataset อย่างรวดเร็ว[^20]

การออกแบบ storage network

Storage network ต้องตรงกับ aggregate read throughput กับการบริโภคของ GPU training Cluster ของ H100 GPU 1,000 ตัวที่ฝึกสอน workload ที่ต้องการข้อมูลมากอาจต้องการ storage throughput ที่ยั่งยืนหลายสิบ gigabyte ต่อวินาที Network capacity ระหว่าง storage และ compute tier ต้องเกินความต้องการนี้พร้อม headroom สำหรับ burst pattern

Network topology ส่งผลต่อ throughput ที่ทำได้ Fat-tree topology ให้ full bisection bandwidth แต่มีค่าใช้จ่ายมากกว่าการออกแบบแบบ oversubscribed Training workload ที่มี storage I/O หนักได้ประโยชน์จาก non-blocking fabric ที่ขจัด network congestion ในฐานะ bottleneck

การ optimize การถ่ายโอนข้อมูล

เทคนิค data transfer optimization รวมถึง parallel I/O, prefetching, caching, compression และ data locality optimization ช่วยให้การเคลื่อนย้ายข้อมูลระหว่าง storage system และ compute node มีประสิทธิภาพ[^21] Prefetching คาดการณ์ความต้องการข้อมูลและ stage ข้อมูลก่อนที่ compute node จะร้องขอ Compression ลดความต้องการ network bandwidth โดยแลกกับ compute cycle

การ batch ข้อมูลลดความถี่ของ transaction กระจาย per-request overhead ข้ามการถ่ายโอนที่ใหญ่กว่า[^22] การ filter ข้อมูลลดขนาด sample ก่อนส่งไปยัง GPU ลดทั้ง storage read และ network transfer การรวมเทคนิคเหล่านี้สามารถลดความต้องการ storage bandwidth ที่แท้จริงได้อย่างมาก

การสร้าง data pipeline ในระดับใหญ่

องค์กรที่ deploy โครงสร้างพื้นฐาน training ระดับ Petabyte ต้องการแนวทางแบบบูรณาการสำหรับ storage, preprocessing และ networking ที่ตรงกับความจุ GPU compute

การวางแผนความจุ

การวางแผนความจุ storage ต้องคำนึงถึงการเติบโตของ training data ควบคู่กับการ scale model Training dataset เติบโตเมื่อองค์กรสะสมข้อมูลมากขึ้นและไล่ตาม model ขนาดใหญ่ที่ต้องการ token มากขึ้น ความต้องการความจุทบต้นเมื่อองค์กรเก็บ dataset version หลายรุ่นเพื่อ reproducibility

การวางแผน throughput ท้าทายกว่าการวางแผนความจุ ความสัมพันธ์ระหว่างขนาด model, batch size และความต้องการ data throughput แตกต่างกันตามสถาปัตยกรรมและ training configuration การ benchmark workload เฉพาะบนโครงสร้างพื้นฐานเป้าหมายให้ความต้องการ throughput ที่เชื่อถือได้ที่สุด

ความเชี่ยวชาญในการ deploy โครงสร้างพื้นฐาน

ความซับซ้อนของโครงสร้างพื้นฐาน data pipeline เทียบเท่าหรือเกินความซับซ้อนของโครงสร้างพื้นฐาน compute Storage system, high-speed network และ preprocessing service ต้องบูรณาการอย่างราบรื่นกับ GPU cluster ข้อผิดพลาดในการ config ส่วนประกอบใดก็ตามสร้าง bottleneck ที่ทำให้เสียการลงทุน GPU

เครือข่าย field engineer 550 คนของ Introl เชี่ยวชาญในการ deploy โครงสร้างพื้นฐานแบบบูรณาการที่ AI training ระดับใหญ่ต้องการ[^23] บริษัทอยู่อันดับ #14 ใน Inc. 5000 ปี 2025 ด้วยการเติบโต 9,594% ในสามปี สะท้อนความต้องการบริการโครงสร้างพื้นฐานแบบมืออาชีพ[^24] องค์กรที่สร้าง training cluster ได้ประโยชน์จากความเชี่ยวชาญในการ deploy ที่จัดการ storage, networking และ compute เป็นระบบบูรณาการ

การจัดการ deployment ที่มี GPU ถึง 100,000 ตัวพร้อมโครงสร้างพื้นฐาน fiber optic network กว่า 40,000 ไมล์ต้องการ operational scale ที่ตรงกับ training initiative ขนาดใหญ่ที่สุด