Scalable Machine Learning

1Statistical Query Model และ Summation Form

สังเกตว่านี่คือผลรวม (Σ) เหนือ record ทั้งหมด — ถ้าแบ่งข้อมูลเป็น N ส่วนเท่า ๆ กัน แต่ละส่วนคำนวณผลรวมย่อยของตัวเอง (partial sum) แบบอิสระโดยไม่ต้องคุยกับส่วนอื่นเลย แล้วค่อยรวมผลรวมย่อยทั้งหมดในตอนท้าย — นี่คือ "summation form" ที่แปลงเป็น MapReduce ได้โดยตรง (map = คำนวณ partial sum ของแต่ละส่วน, reduce = รวม partial sum ทั้งหมดเข้าด้วยกัน)

Sum ไม่ได้สำคัญเพราะบวกง่าย แต่เพราะรวมเป็นต้นไม้ได้

ถ้าฟังก์ชันรวมเป็น Associative เราสามารถรวมภายใน Core, เครื่อง, Rack และคลัสเตอร์เป็นลำดับ ลดข้อมูลก่อนข้าม Network รูปแบบนี้คือ Monoidification ที่พบตั้งแต่ MapReduce, Smart Window, Graph Message Aggregation จนถึง Gradient All-Reduce

// แนวคิด Distributed Gradient
localGradient_p = Σ gradient(model, x_i, y_i)  for data in partition p
globalGradient  = reduce(localGradient_1 ... localGradient_P)
model           = model - learningRate * globalGradient

แต่ละ Worker ยังต้องเห็น Model Version ที่สอดคล้องกันตาม Synchronization Scheme และต้องส่ง Gradient หรือ Parameter Update ซึ่งอาจมีขนาดเท่ากับโมเดลทุก Iteration การคำนวณแยกได้จึงไม่แปลว่าการสื่อสารหายไป

ตัวอย่าง Sufficient Statistics

k-means: ขนานได้ภายในรอบ แต่ยังต้องทำหลายรอบ

Worker แต่ละตัว Assign จุดไปยัง Centroid ที่ใกล้ที่สุด แล้วส่งผลรวมกับ Count ต่อ Cluster กลับมาเพื่อคำนวณ Centroid ใหม่ ขั้น Assignment ขนานได้ดี แต่ทุก Worker ต้องรับ Centroid ชุดล่าสุดและรอการรวมก่อนเริ่มรอบใหม่ จำนวนรอบกับ Communication จึงยังเป็น Serial Dependency ระหว่าง Iteration

2Scalability สองแบบ: ระบบเร็วขึ้น กับโมเดลเรียนรู้ดีขึ้น

ใน Parallel Computing เรามักวัด Speedup จากเวลารัน แต่ Machine Learning มีอีกแกนคือจำนวนตัวอย่างหรือ Update ที่ต้องใช้เพื่อให้ถึงคุณภาพเป้าหมาย การเพิ่ม Worker อาจทำให้ Step หนึ่งเร็วขึ้น แต่ถ้า Large Batch ทำให้ต้องใช้ Epoch มากขึ้นหรือคุณภาพลดลง เวลาถึงคำตอบที่ใช้ได้อาจไม่ดีขึ้นตามจำนวนเครื่อง

Strong Scaling กับ Weak Scaling ใน ML

Strong Scaling ตรึง Data/Model เดิมแล้วเพิ่มทรัพยากรเพื่อให้จบเร็วขึ้น ส่วน Weak Scaling เพิ่ม Data หรือ Model ตามทรัพยากรแล้วหวังว่าเวลายังใกล้เดิม งาน ML สมัยใหม่มักใช้เครื่องเพิ่มเพื่อฝึกโมเดลใหญ่ขึ้น ไม่ใช่ทำงานเดิมให้เร็วขึ้นเพียงอย่างเดียว จึงต้องระบุให้ชัดว่ากำลังเคลม Scaling แบบใด

Time-to-Train ยังไม่พอถ้าคุณภาพไม่เท่ากัน

การเปรียบเทียบระบบ A กับ B ต้องใช้ Dataset, Model, Target Metric และ Training Recipe ที่เทียบกันได้ ถ้า A จบเร็วเพราะหยุดที่ Accuracy ต่ำกว่า การเรียกว่า Speedup เป็น Overclaim เราควรรายงานทั้ง Throughput และ Time-to-Quality

3Deep Learning: Computational Graph และหน่วยความจำ

หน่วยความจำไม่ได้มีเพียง Parameter

โมเดลที่ Weight พอดี GPU อาจฝึกไม่ได้เพราะ Activation หรือ Optimizer State กินพื้นที่มากกว่า Weight การแก้จึงมี Gradient Checkpointing, Mixed Precision, Sharding, Offloading และลด Batch/Sequence แต่แต่ละวิธีแลก Compute, Communication หรือ Accuracy

Compute-bound กับ Memory-bound

Operation บางชนิดใช้ Matrix Multiplication หนาแน่นและได้ประโยชน์จาก GPU มาก ส่วน Embedding Lookup หรือ Small Kernel อาจติด Memory Bandwidth/Latency การเพิ่ม FLOPS ไม่ช่วยถ้าข้อมูลป้อนหน่วยคำนวณไม่ทัน Roofline Thinking จึงยังใช้กับ Deep Learning ได้

เทคนิคลดขนาดโมเดล (Compression)

Compression มีเป้าหมาย Training หรือ Serving

Pruning และ Quantization อาจลด Model Size/Latency ตอน Inference แต่ไม่จำเป็นต้องลดต้นทุน Training ตั้งแต่ต้น Quantization-aware Training ยังเพิ่มขั้นตอนฝึก ส่วน Huffman Coding ช่วยขนาดจัดเก็บมากกว่าการคำนวณโดยตรง ถ้าฮาร์ดแวร์ไม่รองรับ Sparse/Low-precision Kernel โมเดลเล็กบนดิสก์อาจไม่ได้เร็วขึ้นตามสัดส่วน

4รูปแบบการขนานสำหรับ Deep Learning

Data Parallelism: Model ซ้ำ แต่ Data ต่าง

Worker ทุกตัวถือ Model Copy เดียวกันเชิงตรรกะ รับ Mini-batch คนละส่วน คำนวณ Gradient แล้วรวมก่อน Update เหมาะเมื่อโมเดลพอดีแต่ข้อมูล/Compute ต่อ Step มาก Data Parallelism เรียบง่ายที่สุด แต่เมื่อ Worker เพิ่ม Local Batch มักทำให้ Global Batch โต และปริมาณ Gradient Communication ไม่ลดตาม Worker

ถ้าต้องตรึง Global Batch เราต้องลด Batch ต่อ Worker จนอุปกรณ์ใช้ไม่เต็ม หรือใช้จำนวน Worker มากเกินประโยชน์ ถ้าปล่อย Global Batch โต Training Recipe อาจต้องปรับ Learning Rate, Warmup และ Regularization

Tensor Parallelism: แบ่ง Operation ภายใน Layer

Matrix ใหญ่หนึ่งก้อนถูกแบ่งแถวหรือคอลัมน์ไปหลายอุปกรณ์ แต่ละอุปกรณ์คำนวณ Partial Output แล้วใช้ Collective Communication เช่น All-Reduce หรือ All-Gather เหมาะเมื่อ Layer เดียวใหญ่เกินอุปกรณ์ แต่ต้องการ Interconnect เร็วเพราะสื่อสารแทบทุก Layer

Pipeline Parallelism: แบ่งโมเดลตามช่วงชั้น

อุปกรณ์ชุดหนึ่งถือชั้นต้น อีกชุดถือชั้นกลางและปลาย แล้วแบ่ง Mini-batch เป็น Micro-batch ไหลผ่าน Pipeline คล้ายสายการผลิต ช่วงเริ่มและท้ายมี Pipeline Bubble ที่บาง Stage ว่าง การจัด Stage ให้ Compute สมดุลและจำนวน Micro-batch มากพอช่วยลด Bubble แต่ Activation ต้องส่งข้าม Stage

Sequence/Context Parallelism

เมื่อ Sequence ยาว Activation และ Attention โตมาก เราอาจแบ่งตามมิติ Sequence/Context ให้อุปกรณ์แต่ละตัวถือ Token คนละช่วง แล้วประสานข้อมูลที่จำเป็น วิธีนี้ตอบ Model Workload อีกแบบ ไม่ควรรวมทุกอย่างไว้ใต้คำว่า Model Parallelism จนมองไม่เห็น Communication Pattern

Expert Parallelism

Mixture-of-Experts เปิดใช้ Expert เพียงบางส่วนต่อ Token แล้วกระจาย Expert ไปหลายอุปกรณ์ ช่วยเพิ่ม Parameter Capacity โดย Compute ต่อ Token ไม่โตเท่ากัน แต่เกิด All-to-All Communication และ Load Imbalance ถ้า Router ส่ง Token ไป Expert บางตัวมากเกินไป

5Collective Communication: ต้นทุนที่ซ่อนในคำว่า Distributed

Data Parallel Training ต้องรวม Gradient จากทุก Worker วิธีตรง ๆ คือส่งไป Parameter Server กลาง แต่เครื่องกลางอาจเป็นคอขวด Collective เช่น Ring All-Reduce กระจายงานสื่อสารไปทุก Worker โดยแบ่ง Gradient เป็น Chunk แล้ว Reduce-Scatter ตามด้วย All-Gather

All-Reduce ทำอะไร

หลัง Backward Worker แต่ละตัวมี Gradient Vector ของตน เป้าหมายคือให้ทุก Worker ได้ผลรวม/ค่าเฉลี่ยเดียวกันเพื่อ Update Model ตรงกัน การ All-Reduce รวม Reduce กับ Broadcast เป็น Collective เดียวเชิงตรรกะ Implementation ใช้ Topology และขนาด Message เลือก Algorithm ต่างกัน

Latency-bound กับ Bandwidth-bound

Gradient เล็กแต่ Collective ถี่อาจติด Latency ของการเริ่ม Message ส่วน Gradient ใหญ่ติด Bandwidth การรวม Tensor เล็กเป็น Bucket ลดจำนวน Collective แต่ถ้ารอ Bucket เต็มนานจะลด Overlap ระหว่าง Backward กับ Communication Framework จึงพยายามเริ่มส่ง Bucket ที่ Gradient พร้อมแล้ว ขณะ Layer ก่อนหน้ายังคำนวณ Backward

Communication-to-Computation Ratio

เพิ่ม Worker ทำให้ Compute ต่อ Worker ลด แต่ Gradient Size มักเท่าเดิม จุดหนึ่ง Communication จึงครองเวลา การ Scaling ที่ดีต้องเพิ่ม Arithmetic Intensity, ใช้ Local Batch เหมาะสม, Overlap Communication หรือใช้ Parallelism ที่ตรงกับ Topology ไม่ใช่เพิ่ม Worker อย่างเดียว

Topology-aware Placement

GPU ในเครื่องเดียวอาจเชื่อมกันเร็วกว่าข้ามเครื่องหลายเท่า Tensor Parallelism ที่สื่อสารถี่จึงควรอยู่ในกลุ่ม Interconnect เร็ว ส่วน Data Parallel Group อาจกระจายข้าม Node Placement ต้องสอดคล้องกับ Communication Pattern ไม่ใช่จัด GPU แบบสุ่มจาก Pool

6Synchronous, Asynchronous และ Parameter Server

Synchronous Training รอ Gradient จาก Worker ตามกลุ่มก่อน Update ทำให้ Model Version ตรงกันแต่ติด Straggler Asynchronous Training ให้ Worker ส่ง Update เมื่อพร้อม ลดการรอแต่ Gradient อาจคำนวณจาก Parameter เก่า เรียกว่า Staleness

Parameter Server

Parameter ถูก Shard ไว้บน Server หลายตัว Worker ดึง Parameter และผลัก Gradient/Update เหมาะกับ Sparse Model หรือ Embedding ขนาดใหญ่ที่แต่ละ Mini-batch แตะเพียงบาง Row แต่ Server ต้องรับ Request สูงและจัด Consistency/Staleness

Straggler และ Backup Worker

Worker อาจช้าจาก Data Skew, Hardware, Network หรือ Background Load วิธีรับมือมี Speculative/Backup Task, Gradient Coding, ตัด Worker ช้า หรือ Elastic Training แต่ทุกวิธีเปลี่ยน Cost และ Statistical Semantics ถ้าข้อมูลของ Worker ที่ถูกตัดมี Distribution ต่างจากกลุ่ม

7Large Batch: Throughput ดีขึ้น แต่การเรียนรู้อาจเปลี่ยน

Batch ใหญ่เพิ่ม Matrix Utilization และลดจำนวน Synchronization ต่อ Sample แต่ Gradient มี Noise น้อยลงและจำนวน Update ต่อ Epoch ลดลง Recipe ที่ใช้กับ Batch เล็กจึงอาจไม่ให้คุณภาพเท่าเดิมเมื่อขยาย Batch หลายร้อยเท่า

Gradient Accumulation

ถ้า Memory ไม่พอ Global Batch ที่ต้องการ เราคำนวณหลาย Micro-batch สะสม Gradient แล้ว Update ครั้งเดียว วิธีนี้เลียนแบบ Batch ใหญ่เชิง Gradient ภายใต้เงื่อนไขบางอย่าง แต่ไม่ได้ลดจำนวน Forward/Backward และ Interaction กับ Batch-dependent Layer/Randomness ต้องพิจารณา

Learning Rate Scaling และ Warmup

กฎ Linear/Square-root Scaling เป็น Heuristic ที่ใช้ในบางบริบท ไม่ใช่ทฤษฎีรับประกันทุก Model การ Warmup ช่วยลดความรุนแรงช่วงต้นเมื่อ Parameter และ Optimizer State ยังไม่เสถียร แต่ต้องทดลองและประเมิน Time-to-Quality จริง

Critical Batch Size

โดยแนวคิด เมื่อ Batch โตเกินจุดหนึ่ง การเพิ่ม Batch ลด Gradient Noise น้อยลงและไม่ลดจำนวน Step ที่ต้องใช้ตามสัดส่วน เราจึงได้ Throughput ต่อ Step ดีขึ้นแต่ Scaling ทางสถิติอิ่มตัว จุดนี้ขึ้นกับ Model, Data และ Training Stage

8Fault Tolerance และ Checkpoint ในการฝึกระยะยาว

งานฝึกที่ใช้เวลาหลายวันมีโอกาสพบ GPU, Node, Network หรือ Storage Failure สูงขึ้น Checkpoint จึงเป็นส่วนของ Expected Runtime ถ้าบันทึกถี่เกินไป Training เสีย I/O มาก ถ้าห่างเกินไป Failure หนึ่งครั้งทำให้สูญงานหลายชั่วโมง

Checkpoint ต้องเก็บอะไร

• Model Parameters
• Optimizer State และ Learning-rate Scheduler
• Training Step/Epoch และ Random State ที่จำเป็น
• Data Loader/Sampler Progress ตามระดับ Reproducibility ที่ต้องการ
• Configuration, Code Version และ Data Version

Distributed Checkpoint

เมื่อ State ถูก Shard หลายอุปกรณ์ การรวม Checkpoint ทั้งหมดไป Rank เดียวอาจใช้ Memory/Network สูง ระบบจึงบันทึก Shard แบบกระจายแล้วมี Metadata ประกอบ การ Restore ด้วยจำนวน Worker ต่างจากเดิมต้อง Reshard ซึ่งไม่ฟรี

Elastic Training

การเพิ่มลด Worker ระหว่างงานช่วยรับมือ Preemption หรือทรัพยากรเปลี่ยน แต่ Global Batch, Learning Rate และ Data Assignment อาจเปลี่ยนตาม World Size Training Semantics จึงต้องออกแบบ ไม่ใช่เพียงให้ Scheduler เพิ่ม Pod แล้วหวังว่าผลเหมือนเดิม

9Scalable Inference: Training ใหญ่ไม่เท่ากับ Serving ใหญ่

Inference ไม่มี Backpropagation จึงใช้ Memory น้อยกว่า Training แต่ต้องตอบ Request ภายใต้ Latency/Throughput/Cost SLO และอาจมี Sequence Length หรือ Output Length เปลี่ยนไปแต่ละ Request

Batching

รวม Request หลายรายการให้ Accelerator ทำพร้อมกันเพิ่ม Throughput แต่ Request แรกต้องรอ Batch Dynamic Batching จึงรอช่วงสั้นแล้วรวมงานที่เข้ามาใกล้กัน Trade-off คือ Throughput กับ Tail Latency

Model Replication กับ Model Sharding

ถ้าโมเดลพอดีอุปกรณ์ เราทำ Replica หลายชุดเพื่อรับ Request ขนาน แต่ถ้าโมเดลไม่พอดีต้อง Shard หนึ่ง Request ข้ามหลายอุปกรณ์ ทำให้ Communication อยู่ใน Critical Path การ Autoscale ยังต้องคิดเวลาที่ใช้โหลด Weight ขนาดใหญ่

Caching และ Speculative Decoding

งาน Generative Model ใช้ KV Cache ตาม Sequence และจำนวนผู้ใช้ Memory ของ Cache อาจเป็นคอขวดแม้ Weight พอดี เทคนิคอย่าง Quantized Cache, Paging หรือ Speculative Decoding แลก Memory/Compute/Complexity ต่างกัน ควรวัด End-to-end ไม่ใช่ดู FLOPS อย่างเดียว

Compression ต้องวัดบน Hardware จริง

โมเดล INT8 อาจเร็วบน Hardware ที่มี Kernel รองรับ แต่ไม่ช่วยบนเส้นทางที่แปลงกลับ FP32 บ่อย Sparse Model อาจเล็กแต่ช้ากว่า Dense ถ้า Access ไม่ต่อเนื่อง การอ้างลด Parameter 90% จึงไม่เท่ากับลด Latency 90%

10การทดลองที่ขยายขนาดได้โดยไม่เผาทรัพยากรทิ้ง

Hyperparameter Search ขนานได้ง่ายเพราะแต่ละ Trial อิสระ แต่การรัน Grid ใหญ่แบบไม่ใช้ข้อมูลระหว่างทางเป็นวิธีใช้คลัสเตอร์อย่างตรงไปตรงมาเกินไป เราควรหยุด Trial ที่ไม่มีแนวโน้มดี จัด Budget และใช้ Multi-fidelity Search

Cross-validation คูณ Cost อย่างเงียบ ๆ

30 Parameter Sets × 5 Folds = 150 Training Runs ยังไม่รวม Retry และ Final Refit การ Parallelize ช่วย Wall-clock แต่ไม่ลด Compute Cost โดยอัตโนมัติ ควรเริ่มจาก Baseline, ลด Search Space ด้วยความรู้โดเมน และใช้ Validation Scheme ที่ตรงการใช้งาน

Reproducibility ของ Experiment

บันทึก Data Snapshot, Code, Environment, Seed, World Size, Batch, Optimizer, Metric และ Failure/Resume การเปลี่ยนจำนวน Worker อาจเปลี่ยนลำดับ Floating-point และ Data Shuffling จึงไม่ควรสัญญา Bitwise Reproducibility ถ้าระบบรับประกันได้เพียง Statistical Reproducibility

11เลือกวิธีกระจายตามชนิดของอัลกอริทึม

คำว่า Distributed ML มักถูกเล่าเหมือนทุกโมเดลมี Gradient แล้วทำ All-Reduce แต่ Algorithm แต่ละตระกูลมี State และ Communication ต่างกัน การเลือก Framework ก่อนเข้าใจรูปคำนวณทำให้เราใช้เครื่องมือหนักเกินจำเป็นหรือกระจายจุดที่ไม่ใช่คอขวด

Linear และ Logistic Regression

Gradient เป็นผลรวมต่อ Record จึงเหมาะกับ Data Parallelism แต่ถ้า Feature Dimension สูงมาก Gradient Vector ใหญ่และสื่อสารทุก Iteration อาจแพง Sparse Feature ช่วย Compute แต่ Dense All-Reduce อาจทำให้ประโยชน์หาย Parameter Server/Sparse Update จึงเหมาะในบาง Workload

Decision Tree และ Gradient-boosted Trees

การสร้าง Split ต้องรวม Histogram ของ Feature/Threshold จาก Worker State ที่สื่อสารคือ Histogram ไม่ใช่ Gradient แบบ Neural Network Data ถูก Partition ได้ แต่ Tree Node ที่กำลังขยายและ Feature Binning มีผลต่อ Load Balance เมื่อ Tree โต ตัวอย่างใน Leaf บางส่วนลดลงและ Parallelism เปลี่ยน

Random Forest

Tree หลายต้นมีความเป็นอิสระสูง จึงกระจายตาม Tree และ Data Sample ได้ง่ายกว่า Boosting ซึ่งต้นถัดไปพึ่ง Prediction/Error ของ Ensemble เดิม แต่ Tree แต่ละต้นอาจใช้เวลาไม่เท่ากันและต้องรวม Model ขนาดใหญ่ตอนท้าย

k-means และ EM

ทั้งสองมี Local Sufficient Statistics แล้วรวม Global State ต่อ Iteration k-means ส่ง Sum/Count ต่อ Cluster; EM ส่ง Expected Statistics แต่ถ้า Cluster/Component มาก State โตและ Data Skew ทำให้บาง Cluster หนัก การ Initialize ที่ดีลดจำนวน Iteration จึงอาจคุ้มกว่าการเพิ่ม Worker

kNN

kNN แทบไม่มี Training แต่ต้นทุนย้ายไป Query เพราะต้องค้นเพื่อนบ้านในข้อมูลใหญ่ การกระจาย brute-force ช่วย Throughput แต่ Latency/Network สูง ระบบจริงใช้ Approximate Nearest Neighbor Index, Vector Partitioning และ Replication การเรียกว่า “Training เร็ว” จึงปิดบังคอขวด Serving

Naive Bayes

Count ต่อ Class/Feature รวมได้ดีมากและรองรับ Incremental Update แต่ Vocabulary ใหญ่ทำให้ State ใหญ่ ต้องใช้ Sparse Representation และจัดการ Unknown Feature การฝึกกระจายง่ายไม่ได้แปลว่า Data Cleaning/Tokenization ง่าย

Embedding Table

Recommendation/Language Model อาจมี Embedding Parameter ใหญ่แต่ Mini-batch แตะเพียงบาง Row Parameter Server, Row-wise Sharding และ Sparse Optimizer จึงเหมาะกว่า All-Reduce Dense ทั้ง Table แต่ Hot Item/Token ทำให้ Shard บางส่วนรับ Request มาก

Spark ML เหมาะตรงไหน

Spark ML เหมาะกับ Classical ML ที่ต่อกับ DataFrame Feature Pipeline และข้อมูลกระจายอยู่ใน Spark อยู่แล้ว จุดแข็งคือ ETL, Feature และ Model อยู่กระบวนการเดียวกัน ไม่ใช่ทุก Algorithm จะเร็วที่สุดเมื่อเทียบ Library เฉพาะทาง หากข้อมูลพอดีเครื่องและโมเดลเล็ก การดึง Feature ที่สรุปแล้วไป Library เครื่องเดียวอาจง่ายและเร็วกว่า

ย้าย Code ไปหา Data แต่ไม่จำเป็นต้องฝึกทุกอย่างตรงนั้น

หลัก Data Locality บอกให้ทำ Filter, Join และ Aggregate ใกล้ Data ขนาดใหญ่ แต่หลังลดข้อมูลเป็น Feature Matrix ขนาดพอดี เราอาจย้ายผลสรุปไป Training System เฉพาะทาง แนวคิดไม่ใช่ห้ามย้ายข้อมูลทุกกรณี แต่หลีกเลี่ยงการขน Raw Data มหาศาลโดยไม่จำเป็น

12เมื่อยุคเปลี่ยน: จาก Multicore Summation สู่ Distributed Model Training

13กรณีศึกษา: จาก Single GPU ไปสู่ Distributed Training

สมมุติทีมมีโมเดล Classification ที่ฝึกบน GPU เดียว 20 ชั่วโมง เป้าหมายคือให้จบภายใน 4 ชั่วโมงโดยคุณภาพเท่าเดิม ขั้นแรกไม่ควรกระโดดไปใช้ Tensor Parallelism แต่ควร Profile ว่าเวลาอยู่ที่ Data Loading, Forward/Backward, Optimizer หรือ Evaluation

ขั้นที่ 1: สร้าง Baseline ที่เชื่อถือได้

ตรึง Data Version, Model, Batch, Seed, Target Metric และวัด GPU Utilization, Throughput, Memory, I/O ถ้า GPU ว่างรอ Data 60% การเพิ่ม GPU แปดตัวจะสร้างผู้รอเพิ่ม ไม่ได้แก้ Data Pipeline

ขั้นที่ 2: แก้คอขวดเครื่องเดียวก่อน

ปรับ Data Format, Prefetch, Mixed Precision, Kernel และ Batch ให้ GPU ทำงานคุ้ม หาก Baseline ไม่มีประสิทธิภาพ Distributed Version จะขยาย Overhead และทำให้ Debug ยากขึ้น

ขั้นที่ 3: ทดลอง Data Parallelism

ใช้ 4 GPU โดยตรึงหรือบันทึก Global Batch อย่างชัดเจน เปรียบเทียบ Learning Curve ต่อ Wall-clock ไม่ใช่ Throughput อย่างเดียว ถ้าเพิ่ม Batch 4 เท่าแล้ว Accuracy ลด ต้องปรับ Recipe หรือใช้ Gradient Accumulation/จำนวน Worker ที่น้อยกว่า

ขั้นที่ 4: วัด Scaling Efficiency

ถ้า 4 GPU เร็วขึ้น 3.2 เท่า Efficiency = 80% แต่ต้องตรวจว่าใช้ Target Metric เดียวกัน ถ้าเวลาต่อ Epoch ลดแต่ Epoch ที่ต้องใช้เพิ่ม ค่า Time-to-Quality อาจต่ำกว่า 80%

ขั้นที่ 5: หา Communication Knee

เพิ่มเป็น 8 และ 16 GPU แล้วดู All-Reduce Time เมื่อ Compute ต่อ Worker เล็กลง จุดที่เพิ่ม GPU แล้ว Speedup น้อยกว่าค่าใช้จ่าย/ความซับซ้อนคือ Scaling Knee ระบบผลิตไม่จำเป็นต้องใช้ Worker สูงสุดที่มี ถ้า Cost per Training Run แย่ลง

ขั้นที่ 6: Model Parallelism เมื่อจำเป็นจริง

ถ้า Model ไม่พอดีอุปกรณ์ค่อยใช้ Sharding/Tensor/Pipeline Parallelism เลือก Parallel Group ตาม Network Topology และวัด Activation/Optimizer State ไม่ใช่ Weight อย่างเดียว

ขั้นที่ 7: Failure Test

ฆ่า Worker ระหว่างฝึก ตรวจ Checkpoint/Resume, Data Duplication และ Lost Progress วัด Restore Time เพราะงานหลายวันมี Failure เป็น Expected Event ไม่ใช่กรณีสมมุติที่ไม่เกิด

14สรุปและขั้นตอนถัดไป

Scalable ML เริ่มจากการมอง Algorithm เป็นสถิติที่แบ่งคำนวณและรวมได้ Summation Form อธิบายเหตุผลที่ Count, Gradient และ Sufficient Statistics กระจายได้ แต่ Iteration, Synchronization และ State ทำให้เราไม่ได้ Parallelize ฟรี เมื่อเข้าสู่ Deep Learning ปัญหาขยายจาก Data ไปยัง Parameter, Gradient, Optimizer State และ Activation

การเลือก Data, Tensor, Pipeline, Sequence หรือ Expert Parallelism ต้องสอดคล้องกับ Communication Pattern และ Hardware Topology พร้อมวัดทั้ง System Efficiency กับ Statistical Efficiency เป้าหมายสุดท้ายคือ Time/Cost-to-Quality ไม่ใช่ Samples/s ที่ดูสวยที่สุด

ขั้นตอนถัดไป คือบทกรณีศึกษาทางธุรกิจ ซึ่งจะนำ Data Architecture, Streaming, Graph และ Scalable ML มาประกอบเป็นระบบเดียว แล้วถามต่อว่าความแม่น ความเร็ว ต้นทุน ความเสี่ยง และผลลัพธ์ทางธุรกิจสมดุลกันหรือไม่