การฝึกอบรมแบบกระจายด้วย Amazon EKS และ Torch Distributed Elastic

การฝึกอบรมแบบจำลองการเรียนรู้เชิงลึกแบบกระจายมีความสำคัญมากขึ้นเรื่อยๆ เนื่องจากขนาดข้อมูลเติบโตขึ้นในหลายอุตสาหกรรม แอปพลิเคชั่นจำนวนมากในคอมพิวเตอร์วิทัศน์และการประมวลผลภาษาธรรมชาติตอนนี้ต้องการการฝึกอบรมแบบจำลองการเรียนรู้เชิงลึกซึ่งกำลังเติบโตอย่างทวีคูณในความซับซ้อนและมักจะได้รับการฝึกฝนด้วยข้อมูลหลายร้อยเทราไบต์ จากนั้นจึงเป็นสิ่งสำคัญที่จะใช้โครงสร้างพื้นฐานระบบคลาวด์ขนาดใหญ่เพื่อปรับขนาดการฝึกอบรมโมเดลขนาดใหญ่ดังกล่าว

นักพัฒนาสามารถใช้เฟรมเวิร์กโอเพนซอร์สเช่น PyTorch เพื่อออกแบบสถาปัตยกรรมโมเดลที่ใช้งานง่าย อย่างไรก็ตาม การปรับขนาดการฝึกโมเดลเหล่านี้ในหลายโหนดอาจเป็นเรื่องที่ท้าทายเนื่องจากความซับซ้อนในการประสานที่เพิ่มขึ้น

การฝึกอบรมแบบจำลองแบบกระจายส่วนใหญ่ประกอบด้วยสองกระบวนทัศน์:

• รุ่นขนาน – ในการฝึกโมเดลแบบขนาน ตัวโมเดลมีขนาดใหญ่มากจนไม่สามารถใส่ในหน่วยความจำของ GPU ตัวเดียวได้ และจำเป็นต้องใช้ GPU หลายตัวในการฝึกโมเดล โมเดล GPT-3 ของ Open AI ที่มีพารามิเตอร์ฝึกได้ 175 พันล้าน (ขนาดประมาณ 350 GB) เป็นตัวอย่างที่ดีของเรื่องนี้
• ข้อมูลแบบขนาน – ในการฝึกอบรมข้อมูลแบบขนาน โมเดลสามารถอยู่ใน GPU ตัวเดียว แต่เนื่องจากข้อมูลมีขนาดใหญ่มาก จึงอาจต้องใช้เวลาหลายวันหรือหลายสัปดาห์ในการฝึกแบบจำลอง การกระจายข้อมูลไปยังโหนด GPU หลายโหนดสามารถลดเวลาการฝึกได้อย่างมาก

ในโพสต์นี้ เราจัดเตรียมตัวอย่างสถาปัตยกรรมเพื่อฝึกโมเดล PyTorch โดยใช้ ไฟฉายกระจายยืดหยุ่น กรอบงานในรูปแบบข้อมูลแบบขนานแบบกระจายโดยใช้ บริการ Amazon Elastic Kubernetes (อเมซอน อีเคเอส).

เบื้องต้น

หากต้องการทำซ้ำผลลัพธ์ที่รายงานในโพสต์นี้ ข้อกำหนดเบื้องต้นเพียงอย่างเดียวคือบัญชี AWS ในบัญชีนี้ เราสร้างคลัสเตอร์ EKS และ an Amazon FSx สำหรับความมันวาว ระบบไฟล์. นอกจากนี้เรายังผลักอิมเมจคอนเทนเนอร์ไปที่ an การลงทะเบียน Amazon Elastic Container (Amazon ECR) ที่เก็บในบัญชี คำแนะนำในการตั้งค่าส่วนประกอบเหล่านี้มีให้ตามความจำเป็นตลอดทั้งโพสต์

คลัสเตอร์ EKS

Amazon EKS เป็นบริการคอนเทนเนอร์ที่มีการจัดการเพื่อเรียกใช้และปรับขนาดแอปพลิเคชัน Kubernetes บน AWS ด้วย Amazon EKS คุณสามารถรันงานการฝึกอบรมแบบกระจายได้อย่างมีประสิทธิภาพโดยใช้ล่าสุด อเมซอน อีลาสติก คอมพิวท์ คลาวด์ อินสแตนซ์ (Amazon EC2) โดยไม่ต้องติดตั้ง ใช้งาน และบำรุงรักษาส่วนควบคุมหรือโหนดของคุณเอง เป็นที่นิยม ออเคสตรา สำหรับแมชชีนเลิร์นนิง (ML) และเวิร์กโฟลว์ AI คลัสเตอร์ EKS ทั่วไปใน AWS มีลักษณะดังนี้

เราได้เปิดตัวโครงการโอเพ่นซอร์ส AWS DevOps สำหรับ EKS (aws-do-eks)ซึ่งมีชุดสคริปต์และเครื่องมือที่ใช้งานง่ายและกำหนดค่าได้จำนวนมากเพื่อจัดเตรียมคลัสเตอร์ EKS และเรียกใช้งานการฝึกอบรมแบบกระจาย โครงการนี้สร้างขึ้นตามหลักการของ ทำกรอบงาน: ความเรียบง่าย ความยืดหยุ่น และความเป็นสากล คุณสามารถกำหนดค่าคลัสเตอร์ที่คุณต้องการโดยใช้ eks.conf ไฟล์แล้วเปิดใช้งานโดยเรียกใช้ eks-create.sh สคริปต์ คำแนะนำโดยละเอียดมีอยู่ใน repo GitHub.

ฝึกโมเดล PyTorch โดยใช้ Torch Distributed Elastic

Torch Distributed Elastic (TDE) เป็นไลบรารี PyTorch ดั้งเดิมสำหรับการฝึกโมเดลการเรียนรู้เชิงลึกขนาดใหญ่ ซึ่งจำเป็นอย่างยิ่งที่จะต้องปรับขนาดทรัพยากรการประมวลผลแบบไดนามิกตามความพร้อมใช้งาน ดิ TorchElastic Controller สำหรับ Kubernetes เป็นการนำ Kubernetes มาใช้งานสำหรับ TDE ที่จัดการวงจรชีวิตของพ็อดและบริการที่จำเป็นสำหรับการฝึกอบรม TDE โดยอัตโนมัติ ช่วยให้สามารถปรับขนาดทรัพยากรการประมวลผลแบบไดนามิกในระหว่างการฝึกอบรมได้ตามต้องการ นอกจากนี้ยังมีการฝึกอบรมการทนต่อข้อผิดพลาดด้วยการกู้คืนงานจากความล้มเหลวของโหนด

ในโพสต์นี้ เราจะพูดถึงขั้นตอนในการฝึก PyTorch EfficientNet-B7 และ เรสเน็ต50 รุ่นที่ใช้ อิมเมจเน็ต ข้อมูลในลักษณะกระจายกับ TDE เราใช้ PyTorch กระจายข้อมูลแบบขนาน API และตัวควบคุม Kubernetes TorchElastic และเรียกใช้งานการฝึกอบรมของเราบนคลัสเตอร์ EKS ที่มีโหนด GPU หลายโหนด ไดอะแกรมต่อไปนี้แสดงไดอะแกรมสถาปัตยกรรมสำหรับการฝึกโมเดลนี้

TorchElastic สำหรับ Kubernetes ประกอบด้วยส่วนประกอบหลักสองส่วน: TorchElastic Kubernetes Controller (TEC) และเซิร์ฟเวอร์พารามิเตอร์ (etcd) ผู้ควบคุมมีหน้าที่ตรวจสอบและจัดการงานการฝึกอบรม และเซิร์ฟเวอร์พารามิเตอร์จะติดตามโหนดผู้ปฏิบัติงานสำหรับการซิงโครไนซ์แบบกระจายและการค้นพบเพียร์

เพื่อให้พ็อดการฝึกอบรมเข้าถึงข้อมูลได้ เราจำเป็นต้องมีวอลุ่มข้อมูลที่แชร์ซึ่งแต่ละพ็อดจะต่อเชื่อมได้ บางตัวเลือกสำหรับไดรฟ์ข้อมูลที่แชร์ผ่าน อินเทอร์เฟซการจัดเก็บคอนเทนเนอร์ (CSI) ไดรเวอร์รวมอยู่ใน AWS DevOps สำหรับ EKS เป็น ระบบไฟล์ Amazon Elastic (Amazon EFS) และ FSx สำหรับความมันวาว.

การตั้งค่าคลัสเตอร์

ในการกำหนดค่าคลัสเตอร์ของเรา เราใช้อินสแตนซ์ c5.2xlarge หนึ่งอินสแตนซ์สำหรับพ็อดระบบ เราใช้อินสแตนซ์ p4d.24xlarge สามอินสแตนซ์เป็นพ็อดผู้ปฏิบัติงานเพื่อฝึกโมเดล EfficientNet สำหรับการฝึกอบรม ResNet50 เราใช้อินสแตนซ์ p3.8xlarge เป็นพ็อดผู้ปฏิบัติงาน นอกจากนี้ เราใช้ระบบไฟล์ที่ใช้ร่วมกันของ FSx เพื่อจัดเก็บข้อมูลการฝึกอบรมและสิ่งประดิษฐ์ของแบบจำลองของเรา

อินสแตนซ์ AWS p4d.24xlarge มาพร้อมกับ อะแดปเตอร์ผ้ายืดหยุ่น (EFA) เพื่อให้ระบบเครือข่ายระหว่างโหนด เราจะพูดถึง EFA เพิ่มเติมในภายหลังในโพสต์ ในการเปิดใช้การสื่อสารผ่าน EFA เราจำเป็นต้องกำหนดค่าการตั้งค่าคลัสเตอร์ผ่านไฟล์ .yaml หนึ่ง ไฟล์ตัวอย่าง มีให้ในที่เก็บ GitHub

หลังจากกำหนดค่าไฟล์ .yaml อย่างถูกต้องแล้ว เราสามารถเปิดใช้คลัสเตอร์ได้โดยใช้สคริปต์ที่ให้ไว้ใน GitHub repo:

./eks-create.sh

โปรดดูที่ repo GitHub สำหรับคำแนะนำโดยละเอียด

แทบไม่มีความแตกต่างระหว่างการรันงานบน p4d.24xlarge และ p3.8xlarge ขั้นตอนที่อธิบายในโพสต์นี้ใช้ได้กับทั้งคู่ ข้อแตกต่างเพียงอย่างเดียวคือความพร้อมใช้งานของ EFA บนอินสแตนซ์ p4d.24xlarge สำหรับรุ่นที่มีขนาดเล็กกว่า เช่น ResNet50 เครือข่ายมาตรฐานเมื่อเทียบกับเครือข่าย EFA มีผลกระทบน้อยที่สุดต่อความเร็วในการฝึกอบรม

FSx สำหรับระบบไฟล์ Luster

FSx ได้รับการออกแบบสำหรับเวิร์คโหลดการประมวลผลประสิทธิภาพสูงและให้เวลาแฝงต่ำกว่ามิลลิวินาทีโดยใช้โวลุ่มการจัดเก็บข้อมูลไดรฟ์โซลิดสเทต เราเลือก FSx เนื่องจากให้ประสิทธิภาพที่ดีขึ้นเมื่อเราปรับขนาดเป็นโหนดจำนวนมาก รายละเอียดสำคัญที่ควรทราบคือ FSx สามารถมีอยู่ใน Availability Zone เดียวเท่านั้น ดังนั้น โหนดทั้งหมดที่เข้าถึงระบบไฟล์ FSx ควรมีอยู่ใน Availability Zone เดียวกันกับระบบไฟล์ FSx วิธีหนึ่งในการบรรลุเป้าหมายนี้คือการระบุ Availability Zone ที่เกี่ยวข้องในไฟล์คลัสเตอร์ .yaml สำหรับกลุ่มโหนดเฉพาะก่อนสร้างคลัสเตอร์ อีกทางหนึ่ง เราสามารถแก้ไขส่วนเครือข่ายของกลุ่มการปรับขนาดอัตโนมัติสำหรับโหนดเหล่านี้หลังจากตั้งค่าคลัสเตอร์แล้ว และจำกัดให้ใช้เครือข่ายย่อยเดียว สามารถทำได้ง่ายๆ บนคอนโซล Amazon EC2

สมมติว่าคลัสเตอร์ EKS เปิดใช้งานอยู่ และรู้จัก ID ซับเน็ตสำหรับ Availability Zone เราสามารถตั้งค่าระบบไฟล์ FSx ได้โดยการให้ข้อมูลที่จำเป็นใน fsx.conf ไฟล์ตามที่อธิบายไว้ใน README และวิ่ง ปรับใช้.sh สคริปต์ใน FSX โฟลเดอร์ ตั้งค่านโยบายและกลุ่มความปลอดภัยที่ถูกต้องสำหรับการเข้าถึงระบบไฟล์ สคริปต์ยังติดตั้ง คนขับรถซีเอสไอ สำหรับ FSx เป็น daemonset สุดท้าย เราสามารถสร้างการอ้างสิทธิ์วอลุ่มถาวร FSx ใน Kubernetes ได้โดยใช้ไฟล์ .yaml ไฟล์เดียว:

kubectl apply -f fsx-pvc-dynamic.yaml

สิ่งนี้จะสร้างระบบไฟล์ FSx ใน Availability Zone ที่ระบุใน fsx.conf ไฟล์ และยังสร้างการอ้างสิทธิ์วอลุ่มแบบถาวร fsx-pvcซึ่งสามารถติดตั้งโดยพ็อดใดก็ได้ในคลัสเตอร์ในรูปแบบอ่าน-เขียน-จำนวนมาก (RWX)

ในการทดลองของเรา เราใช้ข้อมูล ImageNet ทั้งหมด ซึ่งมีรูปภาพการฝึกอบรมมากกว่า 12 ล้านภาพ แบ่งออกเป็น 1,000 คลาส ข้อมูลสามารถดาวน์โหลดได้จาก เว็บไซต์ ImageNet. ลูกบอล TAR ดั้งเดิมมีหลายไดเร็กทอรี แต่สำหรับการฝึกโมเดลของเรา เราสนใจเพียง ILSVRC/Data/CLS-LOC/ซึ่งรวมถึง train และ val ไดเรกทอรีย่อย ก่อนการฝึกเราต้องจัดเรียงภาพใน val ไดเร็กทอรีย่อยเพื่อให้ตรงกับโครงสร้างไดเร็กทอรีที่ PyTorch . ต้องการ โฟลเดอร์รูปภาพ ระดับ. สามารถทำได้โดยใช้วิธีง่าย ๆ สคริปต์ Python หลังจากที่ข้อมูลถูกคัดลอกไปยังโวลุ่มถาวรในขั้นตอนต่อไป

การคัดลอกข้อมูลจากan บริการจัดเก็บข้อมูลอย่างง่ายของ Amazon (Amazon S3) ที่ฝากข้อมูลกับระบบไฟล์ FSx เราสร้างอิมเมจ Docker ที่มีสคริปต์สำหรับงานนี้ ตัวอย่าง Dockerfile และเชลล์สคริปต์รวมอยู่ในไฟล์ csi โฟลเดอร์ภายใน GitHub repo เราสามารถสร้างภาพโดยใช้ build.sh สคริปต์แล้วพุชไปที่ Amazon ECR โดยใช้ push.sh สคริปต์ ก่อนใช้สคริปต์เหล่านี้ เราจำเป็นต้องจัดเตรียม URI ที่ถูกต้องสำหรับที่เก็บ ECR ในไฟล์ .env ไฟล์ในโฟลเดอร์รูทของ GitHub repo หลังจากที่เราพุชอิมเมจ Docker ไปยัง Amazon ECR เราสามารถเปิดใช้พ็อดเพื่อคัดลอกข้อมูลโดยใช้ไฟล์ .yaml ที่เกี่ยวข้อง:

kubectl apply -f fsx-data-prep-pod.yaml

พ็อดจะรันสคริปต์โดยอัตโนมัติ ข้อมูล-prep.sh เพื่อคัดลอกข้อมูลจาก Amazon S3 ไปยังไดรฟ์ข้อมูลที่ใช้ร่วมกัน เนื่องจากข้อมูล ImageNet มีไฟล์มากกว่า 12 ล้านไฟล์ กระบวนการคัดลอกจึงใช้เวลาสองสามชั่วโมง สคริปต์ Python imagenet_data_prep.py ยังวิ่งเพื่อจัดเรียง val ชุดข้อมูลตามที่คาดไว้โดย PyTorch

การเร่งความเร็วเครือข่าย

เราสามารถใช้ Elastic Fabric Adapter (EFA) ร่วมกับ ประเภทอินสแตนซ์ EC2 ที่รองรับ เพื่อเร่งการรับส่งข้อมูลเครือข่ายระหว่างโหนด GPU ในคลัสเตอร์ของคุณ สิ่งนี้มีประโยชน์เมื่อใช้งานการฝึกอบรมแบบกระจายขนาดใหญ่ ซึ่งการสื่อสารเครือข่ายมาตรฐานอาจเป็นคอขวด สคริปต์เพื่อปรับใช้และทดสอบปลั๊กอินอุปกรณ์ EFA ในคลัสเตอร์ EKS ที่เราใช้ที่นี่จะรวมอยู่ใน efa-อุปกรณ์ปลั๊กอิน โฟลเดอร์ใน GitHub repo ในการเปิดใช้งานงานด้วย EFA ในคลัสเตอร์ EKS ของคุณ นอกเหนือจากโหนดคลัสเตอร์ที่มีฮาร์ดแวร์และซอฟต์แวร์ที่จำเป็นแล้ว ปลั๊กอินอุปกรณ์ EFA จะต้องถูกปรับใช้กับคลัสเตอร์ และคอนเทนเนอร์งานของคุณต้องมี CUDA และ NCCL ที่เข้ากันได้ รุ่น การติดตั้ง

ในการสาธิตการทดสอบ NCCL ที่รันอยู่และการประเมินประสิทธิภาพของ EFA บนอินสแตนซ์ p4d.24xlarge ก่อนอื่นเราต้องปรับใช้ตัวดำเนินการ Kubeflow MPI โดยเรียกใช้ตัวดำเนินการที่เกี่ยวข้อง ปรับใช้.sh สคริปต์ใน ตัวดำเนินการ mpi โฟลเดอร์ จากนั้นเราก็เรียกใช้ ปรับใช้.sh สคริปต์และอัปเดต ทดสอบ-efa-nccl.yaml แสดงรายการดังนั้นข้อ จำกัด และการร้องขอทรัพยากร vpc.amazonaws.com ถูกตั้งค่าเป็น 4 อะแด็ปเตอร์ EFA ที่มีอยู่สี่ตัวในโหนด p4d.24xlarge ถูกรวมเข้าด้วยกันเพื่อให้ปริมาณงานสูงสุด

วิ่ง kubectl apply -f ./test-efa-nccl.yaml เพื่อใช้การทดสอบแล้วแสดงบันทึกของพ็อดทดสอบ บรรทัดต่อไปนี้ในเอาต์พุตบันทึกยืนยันว่ากำลังใช้ EFA:

NCCL INFO NET/OFI Selected Provider is efa

ผลการทดสอบควรมีลักษณะคล้ายกับผลลัพธ์ต่อไปนี้:

[1,0]<stdout>:#                                                       out-of-place                       in-place
[1,0]<stdout>:#       size         count      type   redop     time   algbw   busbw  error     time   algbw   busbw  error
[1,0]<stdout>:#        (B)    (elements)                       (us)  (GB/s)  (GB/s)            (us)  (GB/s)  (GB/s)
[1,0]<stdout>:           8             2     float     sum    629.7    0.00    0.00  2e-07    631.4    0.00    0.00  1e-07
[1,0]<stdout>:          16             4     float     sum    630.5    0.00    0.00  1e-07    628.1    0.00    0.00  1e-07
[1,0]<stdout>:          32             8     float     sum    627.6    0.00    0.00  1e-07    628.2    0.00    0.00  1e-07
[1,0]<stdout>:          64            16     float     sum    633.6    0.00    0.00  1e-07    628.4    0.00    0.00  6e-08
[1,0]<stdout>:         128            32     float     sum    627.5    0.00    0.00  6e-08    632.0    0.00    0.00  6e-08
[1,0]<stdout>:         256            64     float     sum    634.5    0.00    0.00  6e-08    636.5    0.00    0.00  6e-08
[1,0]<stdout>:         512           128     float     sum    634.8    0.00    0.00  6e-08    635.2    0.00    0.00  6e-08
[1,0]<stdout>:        1024           256     float     sum    646.6    0.00    0.00  2e-07    643.6    0.00    0.00  2e-07
[1,0]<stdout>:        2048           512     float     sum    745.0    0.00    0.01  5e-07    746.0    0.00    0.01  5e-07
[1,0]<stdout>:        4096          1024     float     sum    958.2    0.00    0.01  5e-07    955.8    0.00    0.01  5e-07
[1,0]<stdout>:        8192          2048     float     sum    963.0    0.01    0.02  5e-07    954.5    0.01    0.02  5e-07
[1,0]<stdout>:       16384          4096     float     sum    955.0    0.02    0.03  5e-07    955.5    0.02    0.03  5e-07
[1,0]<stdout>:       32768          8192     float     sum    975.5    0.03    0.06  5e-07   1009.0    0.03    0.06  5e-07
[1,0]<stdout>:       65536         16384     float     sum   1353.4    0.05    0.09  5e-07   1343.5    0.05    0.09  5e-07
[1,0]<stdout>:      131072         32768     float     sum   1395.9    0.09    0.18  5e-07   1392.6    0.09    0.18  5e-07
[1,0]<stdout>:      262144         65536     float     sum   1476.7    0.18    0.33  5e-07   1536.3    0.17    0.32  5e-07
[1,0]<stdout>:      524288        131072     float     sum   1560.3    0.34    0.63  5e-07   1568.3    0.33    0.63  5e-07
[1,0]<stdout>:     1048576        262144     float     sum   1599.2    0.66    1.23  5e-07   1595.3    0.66    1.23  5e-07
[1,0]<stdout>:     2097152        524288     float     sum   1671.1    1.25    2.35  5e-07   1672.5    1.25    2.35  5e-07
[1,0]<stdout>:     4194304       1048576     float     sum   1785.1    2.35    4.41  5e-07   1780.3    2.36    4.42  5e-07
[1,0]<stdout>:     8388608       2097152     float     sum   2133.6    3.93    7.37  5e-07   2135.0    3.93    7.37  5e-07
[1,0]<stdout>:    16777216       4194304     float     sum   2650.9    6.33   11.87  5e-07   2649.9    6.33   11.87  5e-07
[1,0]<stdout>:    33554432       8388608     float     sum   3422.0    9.81   18.39  5e-07   3478.7    9.65   18.09  5e-07
[1,0]<stdout>:    67108864      16777216     float     sum   4783.2   14.03   26.31  5e-07   4782.6   14.03   26.31  5e-07
[1,0]<stdout>:   134217728      33554432     float     sum   7216.9   18.60   34.87  5e-07   7240.9   18.54   34.75  5e-07
[1,0]<stdout>:   268435456      67108864     float     sum    12738   21.07   39.51  5e-07    12802   20.97   39.31  5e-07
[1,0]<stdout>:   536870912     134217728     float     sum    24375   22.03   41.30  5e-07    24403   22.00   41.25  5e-07
[1,0]<stdout>:  1073741824     268435456     float     sum    47904   22.41   42.03  5e-07    47893   22.42   42.04  5e-07
[1,4]<stdout>:test-efa-nccl-worker-0:33:33 [4] NCCL INFO comm 0x7fd4a0000f60 rank 4 nranks 16 cudaDev 4 busId 901c0 - Destroy COMPLETE
[1,0]<stdout>:# Out of bounds values : 0 OK
[1,0]<stdout>:# Avg bus bandwidth    : 8.23785

เราสามารถสังเกตได้จากผลการทดสอบว่าทรูพุตสูงสุดประมาณ 42 GB/วินาที และแบนด์วิดท์บัสเฉลี่ยประมาณ 8 GB

เรายังทำการทดลองโดยเปิดใช้อะแดปเตอร์ EFA ตัวเดียว และไม่มีอะแดปเตอร์ EFA ผลลัพธ์ทั้งหมดสรุปไว้ในตารางต่อไปนี้

เรายังพบว่าสำหรับรุ่นที่ค่อนข้างเล็ก เช่น ImageNet การใช้เครือข่ายแบบเร่งจะลดเวลาการฝึกอบรมต่อยุคเพียง 5-8% ที่ขนาดแบทช์ที่ 64 สำหรับรุ่นที่ใหญ่กว่าและขนาดแบทช์ที่เล็กกว่า เมื่อต้องการการสื่อสารทางเครือข่ายของน้ำหนักที่เพิ่มขึ้น การใช้เครือข่ายแบบเร่งมีผลกระทบมากขึ้น เราสังเกตพบว่าเวลาการฝึกอบรมในยุคนั้นลดลง 15–18% สำหรับการฝึกอบรม EfficientNet-B7 ที่มีขนาดแบทช์ 1 ผลกระทบที่แท้จริงของ EFA ต่อการฝึกอบรมของคุณจะขึ้นอยู่กับขนาดของโมเดลของคุณ

การตรวจสอบ GPU

ก่อนลุยงานเทรน เราก็ตั้งได้ อเมซอน คลาวด์วอตช์ เมตริกเพื่อให้เห็นภาพการใช้ GPU ระหว่างการฝึก การรู้ว่ามีการใช้ทรัพยากรอย่างเหมาะสมหรืออาจระบุถึงความอดอยากของทรัพยากรและปัญหาคอขวดในกระบวนการฝึกอบรมอาจเป็นประโยชน์

สคริปต์ที่เกี่ยวข้องในการตั้งค่า CloudWatch อยู่ใน GPU-เมตริก โฟลเดอร์ ขั้นแรก เราสร้างอิมเมจ Docker ด้วย amazon-cloudwatch-agent และ nvidia-smi. เราสามารถใช้ Dockerfile ในการ gpu-metrics โฟลเดอร์เพื่อสร้างภาพนี้ สมมติว่ารีจิสตรี ECR ถูกตั้งค่าไว้แล้วในไฟล์ .env ไฟล์จากขั้นตอนที่แล้ว เราสามารถสร้างและดันภาพได้โดยใช้ build.sh และ push.sh. หลังจากนี้ให้เรียกใช้ deploy.sh สคริปต์จะตั้งค่าให้เสร็จสิ้นโดยอัตโนมัติ มันเปิดตัว daemonset ด้วย amazon-cloudwatch-agent และผลักดันตัววัดต่างๆ ไปยัง CloudWatch ตัวชี้วัด GPU ปรากฏภายใต้ CWAgent เนมสเปซบนคอนโซล CloudWatch เมตริกคลัสเตอร์ที่เหลือจะแสดงภายใต้ ContainerInsights เนมสเปซ

การฝึกโมเดล

สคริปต์ทั้งหมดที่จำเป็นสำหรับการฝึกอบรม PyTorch อยู่ใน งานยืดหยุ่น โฟลเดอร์ใน GitHub repo ก่อนเริ่มงานฝึกอบรม เราต้องเรียกใช้ etcd เซิร์ฟเวอร์ซึ่ง TEC ใช้สำหรับการค้นพบผู้ปฏิบัติงานและการแลกเปลี่ยนพารามิเตอร์ ดิ ปรับใช้.sh สคริปต์ใน elasticjob โฟลเดอร์ทำอย่างนั้น

ในการใช้ประโยชน์จาก EFA ในอินสแตนซ์ p4d.24xlarge เราจำเป็นต้องใช้อิมเมจ Docker เฉพาะที่มีอยู่ใน แกลเลอรีสาธารณะ Amazon ECR ที่รองรับการสื่อสาร NCCL ผ่าน EFA เราเพียงแค่ต้องคัดลอกรหัสการฝึกอบรมของเราไปยังอิมเมจ Docker นี้ ดิ ไฟล์นักเทียบท่า ภายใต้ ตัวอย่าง โฟลเดอร์สร้างอิมเมจเพื่อใช้เมื่อรันงานการฝึกบนอินสแตนซ์ p4d และเช่นเคย เราสามารถใช้ สร้าง.sh และ ดัน.sh สคริปต์ในโฟลเดอร์เพื่อสร้างและผลักรูปภาพ

พื้นที่ imagenet-efa.yaml ไฟล์อธิบายงานฝึกอบรม ไฟล์ .yaml นี้ตั้งค่าทรัพยากรที่จำเป็นสำหรับการเรียกใช้งานการฝึกอบรม และยังต่อเชื่อมไดรฟ์ข้อมูลแบบถาวรด้วยการตั้งค่าข้อมูลการฝึกอบรมในส่วนก่อนหน้า

สองสามสิ่งที่ควรค่าแก่การชี้ให้เห็นที่นี่ ควรตั้งค่าจำนวนเรพลิกาเป็นจำนวนโหนดที่มีอยู่ในคลัสเตอร์ ในกรณีของเรา เราตั้งค่านี้เป็น 3 เนื่องจากเรามีโหนด p4d.24xlarge สามโหนด ใน imagenet-efa.yaml ไฟล์ the nvidia.com/gpu พารามิเตอร์ภายใต้ทรัพยากรและ nproc_per_node ภายใต้ args ควรตั้งค่าเป็นจำนวน GPU ต่อโหนด ซึ่งในกรณีของ p4d.24xlarge คือ 8 นอกจากนี้ อาร์กิวเมนต์ของผู้ปฏิบัติงานสำหรับสคริปต์ Python จะกำหนดจำนวน CPU ต่อกระบวนการ เราเลือกค่านี้เป็น 4 เนื่องจากในการทดสอบของเรา ค่านี้ให้ประสิทธิภาพที่ดีที่สุดเมื่อทำงานบนอินสแตนซ์ p4d.24xlarge การตั้งค่าเหล่านี้จำเป็นสำหรับการใช้ทรัพยากรฮาร์ดแวร์ทั้งหมดที่มีอยู่ในคลัสเตอร์ให้เกิดประโยชน์สูงสุด

เมื่องานกำลังทำงาน เราสามารถสังเกตการใช้ GPU ใน CloudWatch สำหรับ GPU ทั้งหมดในคลัสเตอร์ ต่อไปนี้คือตัวอย่างจากงานการฝึกอบรมงานหนึ่งของเราที่มีโหนด p4d.24xlarge สามโหนดในคลัสเตอร์ ที่นี่เราได้เลือก GPU หนึ่งตัวจากแต่ละโหนด ด้วยการตั้งค่าที่กล่าวถึงก่อนหน้านี้ การใช้งาน GPU เกือบ 100% ในระหว่างขั้นตอนการฝึกของยุคสำหรับโหนดทั้งหมดในคลัสเตอร์

สำหรับการฝึกโมเดล ResNet50 โดยใช้อินสแตนซ์ p3.8xlarge เราจำเป็นต้องมีขั้นตอนเดียวกันกับที่อธิบายไว้สำหรับการฝึกอบรม EfficientNet โดยใช้ p4d.24xlarge เรายังสามารถใช้อิมเมจ Docker เดียวกันได้ ดังที่กล่าวไว้ก่อนหน้านี้ อินสแตนซ์ p3.8xlarge ไม่ได้ติดตั้ง EFA อย่างไรก็ตาม สำหรับรุ่น ResNet50 นี่ไม่ใช่ข้อเสียที่สำคัญ ดิ imagenet-fsx.yaml สคริปต์ที่ให้ไว้ในที่เก็บ GitHub จะตั้งค่างานการฝึกอบรมด้วยทรัพยากรที่เหมาะสมสำหรับประเภทโหนด p3.8xlarge งานใช้ชุดข้อมูลเดียวกันจากระบบไฟล์ FSx

สเกล GPU

เราทำการทดลองบางอย่างเพื่อสังเกตว่าเวลาในการฝึกสำหรับรุ่น EfficientNet-B7 โดยการเพิ่มจำนวน GPU ในการทำเช่นนี้ เราได้เปลี่ยนจำนวนการจำลองจาก 1 เป็น 3 ในไฟล์ .yaml การฝึกอบรมของเราสำหรับการฝึกแต่ละครั้ง เราสังเกตเวลาสำหรับยุคเดียวเท่านั้นในขณะที่ใช้ชุดข้อมูล ImageNet ที่สมบูรณ์ รูปต่อไปนี้แสดงผลสำหรับการทดสอบการปรับขนาด GPU ของเรา เส้นประสีแดงแสดงว่าเวลาการฝึกควรลดลงจากการวิ่งโดยใช้ GPU 8 ตัวโดยการเพิ่มจำนวน GPU ดังที่เราเห็น การปรับขนาดค่อนข้างใกล้เคียงกับที่คาดไว้

ในทำนองเดียวกัน เราได้รับพล็อตการปรับขนาด GPU สำหรับการฝึกอบรม ResNet50 บนอินสแตนซ์ p3.8xlarge สำหรับกรณีนี้ เราเปลี่ยนแบบจำลองในไฟล์ .yaml จาก 1 เป็น 4 ผลลัพธ์ของการทดลองนี้แสดงในรูปต่อไปนี้

ทำความสะอาด

สิ่งสำคัญคือต้องแยกทรัพยากรออกหลังจากการฝึกโมเดล เพื่อหลีกเลี่ยงค่าใช้จ่ายที่เกี่ยวข้องกับอินสแตนซ์ที่ไม่ได้ใช้งานที่ทำงานอยู่ ด้วยสคริปต์แต่ละตัวที่สร้างทรัพยากร repo GitHub จัดเตรียมสคริปต์ที่ตรงกันเพื่อลบออก เพื่อล้างการตั้งค่าของเรา เราต้องลบระบบไฟล์ FSx ก่อนลบคลัสเตอร์ เนื่องจากระบบเชื่อมโยงกับซับเน็ตใน VPC ของคลัสเตอร์ ในการลบระบบไฟล์ FSx เราเพียงแค่เรียกใช้คำสั่งต่อไปนี้ (จากภายใน FSX โฟลเดอร์):

kubectl delete -f fsx-pvc-dynamic.yaml
./delete.sh

โปรดทราบว่าการดำเนินการนี้ไม่เพียงแต่จะลบโวลุ่มถาวร แต่ยังลบระบบไฟล์ FSx ด้วย และข้อมูลทั้งหมดบนระบบไฟล์จะสูญหาย เมื่อขั้นตอนนี้เสร็จสมบูรณ์ เราสามารถลบคลัสเตอร์โดยใช้สคริปต์ต่อไปนี้ใน อดีต โฟลเดอร์:

./eks-delete.sh

การดำเนินการนี้จะลบพ็อดที่มีอยู่ทั้งหมด ลบคลัสเตอร์ และลบ VPC ที่สร้างขึ้นในตอนเริ่มต้น

สรุป

ในโพสต์นี้ เราได้ให้รายละเอียดขั้นตอนที่จำเป็นสำหรับการรัน PyTorch การฝึกอบรมแบบจำลองข้อมูลแบบขนานแบบกระจายบนคลัสเตอร์ EKS งานนี้อาจดูน่ากลัว แต่ AWS DevOps สำหรับ EKS โปรเจ็กต์ที่สร้างโดยทีม ML Frameworks ที่ AWS มีสคริปต์และเครื่องมือที่จำเป็นทั้งหมดเพื่อทำให้กระบวนการง่ายขึ้นและทำให้เข้าถึงการฝึกอบรมโมเดลแบบกระจายได้อย่างง่ายดาย

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับเทคโนโลยีที่ใช้ในโพสต์นี้ โปรดไปที่ อเมซอน EKS และ ไฟฉายกระจายยืดหยุ่น. เราขอแนะนำให้คุณใช้แนวทางที่อธิบายไว้ที่นี่กับกรณีการใช้งานการฝึกอบรมแบบกระจายของคุณเอง

แหล่งข้อมูล

เกี่ยวกับผู้แต่ง

อิมราน ยูนุส เป็น Principal Solutions Architect สำหรับทีม ML Frameworks ที่ AWS เขามุ่งเน้นไปที่แมชชีนเลิร์นนิงขนาดใหญ่และปริมาณงานการเรียนรู้เชิงลึกในบริการต่างๆ ของ AWS เช่น Amazon EKS และ AWS ParallelCluster เขามีประสบการณ์อย่างกว้างขวางในการประยุกต์ใช้ Deep Leaning ใน Computer Vision และ Industrial IoT Imran สำเร็จการศึกษาระดับปริญญาเอกสาขาฟิสิกส์อนุภาคพลังงานสูง ซึ่งเขามีส่วนร่วมในการวิเคราะห์ข้อมูลการทดลองในระดับเพตาไบต์

อเล็กซ์ เอียนคูลสกี้ เป็นสถาปนิกซอฟต์แวร์และโครงสร้างพื้นฐานแบบฟูลสแตก ซึ่งชอบทำงานเชิงลึกและลงมือปฏิบัติจริง ปัจจุบันเขาเป็น Principal Solutions Architect for Self-managed Machine Learning ที่ AWS ในบทบาทของเขา เขามุ่งเน้นที่การช่วยเหลือลูกค้าในการจัดคอนเทนเนอร์และประสานปริมาณงาน ML และ AI บนบริการ AWS ที่ขับเคลื่อนด้วยคอนเทนเนอร์ เขายังเป็นผู้เขียนโอเพ่นซอร์ส ทำกรอบงาน และกัปตัน Docker ที่รักการนำเทคโนโลยีคอนเทนเนอร์มาใช้เพื่อเร่งความเร็วของนวัตกรรมไปพร้อมกับแก้ปัญหาที่ท้าทายที่ใหญ่ที่สุดในโลก ในช่วง 10 ปีที่ผ่านมา Alex ได้ทำงานเพื่อต่อสู้กับการเปลี่ยนแปลงสภาพภูมิอากาศ ทำให้ AI และ ML เป็นประชาธิปไตย ทำให้การเดินทางปลอดภัยยิ่งขึ้น ดูแลสุขภาพดีขึ้น และใช้พลังงานอย่างชาญฉลาดขึ้น