เรียกใช้และเพิ่มประสิทธิภาพการอนุมานหลายรุ่นด้วยตำแหน่งข้อมูลหลายรุ่นของ Amazon SageMaker

อเมซอน SageMaker multi-model endpoint (MME) ช่วยให้คุณสามารถปรับใช้และโฮสต์หลายโมเดลได้อย่างคุ้มค่าในจุดปลายเดียว จากนั้นปรับขนาดจุดสิ้นสุดในแนวนอนเพื่อให้ได้มาตราส่วน ดังที่แสดงในรูปต่อไปนี้ นี่เป็นเทคนิคที่มีประสิทธิภาพในการใช้โมเดลหลายผู้เช่าภายในโครงสร้างพื้นฐานการเรียนรู้ของเครื่อง (ML) เราได้เห็นธุรกิจซอฟต์แวร์เป็นบริการ (SaaS) ใช้คุณลักษณะนี้เพื่อใช้ไฮเปอร์ส่วนบุคคลในโมเดล ML ของตนในขณะที่มีต้นทุนที่ต่ำลง

สำหรับภาพรวมระดับสูงเกี่ยวกับวิธีการทำงานของ MME โปรดดูวิดีโอ AWS Summit ปรับขนาด ML ไปอีกระดับ: โฮสต์โมเดลหลายพันรุ่นบน SageMaker. หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับกรณีการใช้งานแบบหลายผู้ใช้ที่มีความเป็นส่วนตัวสูงซึ่งเปิดใช้งาน MME โปรดดูที่ วิธีปรับขนาดการอนุมานการเรียนรู้ของเครื่องสำหรับกรณีการใช้งาน SaaS แบบหลายผู้เช่า.

ในส่วนที่เหลือของโพสต์นี้ เราจะเจาะลึกลงไปในสถาปัตยกรรมทางเทคนิคของ SageMaker MME และแชร์แนวทางปฏิบัติที่ดีที่สุดสำหรับการเพิ่มประสิทธิภาพจุดสิ้นสุดแบบหลายรุ่นของคุณ

ใช้เคสที่เหมาะที่สุดสำหรับ MME

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

MME ยังได้รับการออกแบบสำหรับโมเดลการโฮสต์ร่วมที่ใช้เฟรมเวิร์ก ML เดียวกัน เนื่องจากใช้คอนเทนเนอร์ที่ใช้ร่วมกันเพื่อโหลดหลายรุ่น ดังนั้น หากคุณมีเฟรมเวิร์ก ML ผสมกันในกลุ่มโมเดลของคุณ (เช่น PyTorch และ TensorFlow) จุดปลายเฉพาะของ SageMaker หรือการโฮสต์แบบหลายคอนเทนเนอร์เป็นทางเลือกที่ดีกว่า

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

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

โมเดลตู้คอนเทนเนอร์

เมื่อคุณใช้ SageMaker Inference Toolkit หรือโมเดล SageMaker ที่สร้างไว้ล่วงหน้าซึ่งให้บริการคอนเทนเนอร์ที่เข้ากันได้กับ MME คอนเทนเนอร์ของคุณจะมี เซิร์ฟเวอร์หลายรุ่น (กระบวนการ JVM) กำลังทำงานอยู่ วิธีที่ง่ายที่สุดในการรวม Multi Model Server (MMS) ไว้ในคอนเทนเนอร์ที่ให้บริการโมเดลของคุณคือการใช้ โมเดล SageMaker ที่ให้บริการคอนเทนเนอร์ เข้ากันได้กับ MME (มองหาผู้ที่มี Job Type=inference และ CPU/GPU=CPU) MMS เป็นเครื่องมือโอเพ่นซอร์สที่ใช้งานง่ายสำหรับให้บริการโมเดลการเรียนรู้เชิงลึก มันจัดเตรียม REST API พร้อมเว็บเซิร์ฟเวอร์เพื่อให้บริการและจัดการหลายรุ่นในโฮสต์เดียว อย่างไรก็ตาม ไม่จำเป็นต้องใช้ MMS; คุณสามารถใช้เซิร์ฟเวอร์โมเดลของคุณเองได้ตราบเท่าที่มันใช้ API ที่ MME . ต้องการ.

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

การกำหนดค่าขั้นสูงของ MMS

หากคุณเลือกใช้ MMS สำหรับการให้บริการโมเดล ให้พิจารณาการกำหนดค่าขั้นสูงต่อไปนี้เพื่อปรับความสามารถในการปรับขนาดและปริมาณงานของอินสแตนซ์ MME ของคุณให้เหมาะสม

เพิ่มการอนุมานขนานกันต่อโมเดล

MMS สร้างกระบวนการของผู้ปฏิบัติงาน Python อย่างน้อยหนึ่งกระบวนการต่อรุ่นตามค่าของ default_workers_per_model พารามิเตอร์การกำหนดค่า ผู้ปฏิบัติงาน Python เหล่านี้จัดการคำขออนุมานแต่ละรายการโดยเรียกใช้ฟังก์ชันการประมวลผลล่วงหน้า การคาดคะเน และการประมวลผลภายหลังที่คุณให้ไว้ ดูรายละเอียดเพิ่มเติมได้ที่ ตัวจัดการบริการที่กำหนดเอง ที่เก็บ GitHub

การมีผู้ปฏิบัติงานแบบจำลองมากกว่าหนึ่งรายจะเพิ่มการทำนายที่ขนานกันซึ่งสามารถให้บริการโดยแบบจำลองที่กำหนด อย่างไรก็ตาม เมื่อมีการโฮสต์โมเดลจำนวนมากบนอินสแตนซ์ที่มี CPU จำนวนมาก คุณควรทำการทดสอบโหลด MME ของคุณเพื่อค้นหาค่าที่เหมาะสมที่สุดสำหรับ default_workers_per_model เพื่อป้องกันหน่วยความจำหรือทรัพยากร CPU หมด

การออกแบบสำหรับการจราจรติดขัด

แต่ละกระบวนการ MMS ภายในอินสแตนซ์ปลายทางมีคิวคำขอที่สามารถกำหนดค่าได้ด้วย job_queue_size พารามิเตอร์ (ค่าเริ่มต้นคือ 100) ซึ่งจะกำหนดจำนวนคำขอ MMS จะเข้าคิวเมื่อกระบวนการของผู้ปฏิบัติงานทั้งหมดไม่ว่าง ใช้พารามิเตอร์นี้เพื่อปรับแต่งการตอบสนองของอินสแตนซ์ปลายทางของคุณอย่างละเอียด หลังจากที่คุณได้ตัดสินใจเลือกจำนวนผู้ปฏิบัติงานที่เหมาะสมที่สุดต่อแบบจำลองแล้ว

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

เพิ่มทรัพยากรหน่วยความจำสูงสุดต่ออินสแตนซ์

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

ตั้งค่าสำหรับการกำหนดค่าขั้นสูง MMS

MMS ใช้ไฟล์ config.properties เพื่อจัดเก็บการกำหนดค่า MMS ใช้ลำดับต่อไปนี้เพื่อค้นหาไฟล์ config.properties นี้:

1. ถ้า MMS_CONFIG_FILE มีการตั้งค่าตัวแปรสภาพแวดล้อม MMS จะโหลดการกำหนดค่าจากตัวแปรสภาพแวดล้อม
2. ถ้า --mms-config พารามิเตอร์ถูกส่งผ่านไปยัง MMS โดยจะโหลดการกำหนดค่าจากพารามิเตอร์
3. หากมี config.properties ในโฟลเดอร์ปัจจุบันที่ผู้ใช้เริ่ม MMS จะโหลดไฟล์ config.properties ไฟล์จากไดเร็กทอรีการทำงานปัจจุบัน

หากไม่มีการระบุข้างต้น MMS จะโหลดการกำหนดค่าในตัวด้วยค่าเริ่มต้น

ต่อไปนี้คือตัวอย่างบรรทัดคำสั่งของการเริ่ม MMS ด้วยไฟล์การกำหนดค่าที่ชัดเจน:

multi-model-server --start --mms-config /home/mms/config.properties

ตัวชี้วัดหลักในการตรวจสอบประสิทธิภาพปลายทางของคุณ

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

เมตริกระดับอินสแตนซ์ปลายทาง (เมตริก MMS)

จาก รายการเมตริก MMS, CPUUtilization และ MemoryUtilization สามารถช่วยคุณประเมินว่าอินสแตนซ์หรือคลัสเตอร์ MME ของคุณมีขนาดที่เหมาะสมหรือไม่ หากตัวชี้วัดทั้งสองมีเปอร์เซ็นต์ระหว่าง 50–80% แสดงว่า MME ของคุณมีขนาดที่เหมาะสม

โดยทั่วไป CPUUtilization ต่ำและ MemoryUtilization สูงเป็นตัวบ่งชี้ของคลัสเตอร์ MME ที่มีการจัดสรรมากเกินไป เนื่องจากบ่งชี้ว่าโมเดลที่เรียกใช้ไม่บ่อยจะไม่ถูกยกเลิกการโหลด อาจเป็นเพราะจำนวนอินสแตนซ์ปลายทางที่จัดเตรียมไว้สำหรับ MME สูงกว่าจำนวนที่เหมาะสม ดังนั้นจึงมีหน่วยความจำรวมที่สูงกว่าที่เหมาะสมสำหรับรุ่นที่เข้าถึงไม่บ่อยเพื่อให้คงอยู่ในหน่วยความจำ ในทางกลับกัน การใช้เมตริกเหล่านี้เกือบ 100% หมายความว่าคลัสเตอร์ของคุณไม่ได้รับการจัดสรร ดังนั้นคุณต้องปรับนโยบายการปรับขนาดคลัสเตอร์อัตโนมัติ

ตัววัดระดับแพลตฟอร์ม (ตัววัด MME)

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

บทเรียนจากภาคสนามและกลยุทธ์ในการเพิ่มประสิทธิภาพ MME

เราได้เห็นคำแนะนำต่อไปนี้จากการใช้ MME ในระดับสูงกับลูกค้าจำนวนหนึ่ง

การปรับขนาดแนวนอนด้วยอินสแตนซ์ที่เล็กกว่านั้นดีกว่าการปรับขนาดในแนวตั้งที่มีอินสแตนซ์ที่ใหญ่กว่า

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

ข้อดีอีกประการของการปรับขนาดในแนวนอนด้วยอินสแตนซ์ที่มีขนาดเล็กกว่าคือ คุณสามารถลดความเสี่ยงของการใช้ทรัพยากร CPU และหน่วยความจำของอินสแตนซ์เมื่อใช้งาน MMS ที่มีระดับความขนานที่สูงกว่า พร้อมกับจำนวนรุ่นในหน่วยความจำที่สูงขึ้น (ตามที่อธิบายไว้ก่อนหน้าในโพสต์นี้)

การหลีกเลี่ยงการฟาดฟันเป็นความรับผิดชอบร่วมกัน

ฟาดฟัน ใน MME คือเวลาที่โมเดลมักถูกยกเลิกการโหลดจากหน่วยความจำและโหลดซ้ำเนื่องจากหน่วยความจำไม่เพียงพอ ไม่ว่าจะในอินสแตนซ์เดี่ยวหรือแบบรวมในคลัสเตอร์

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

อย่าก้าวร้าวกับ bin ที่แพ็กโมเดลมากเกินไปในอินสแตนซ์หน่วยความจำที่น้อยกว่าและใหญ่กว่า

หน่วยความจำไม่ใช่ทรัพยากรเดียวบนอินสแตนซ์ที่ควรทราบ ทรัพยากรอื่นๆ เช่น CPU อาจเป็นปัจจัยจำกัด ดังที่เห็นในผลการทดสอบโหลดต่อไปนี้ ในบางกรณี เรายังสังเกตเห็นทรัพยากรเคอร์เนลอื่นๆ เช่น ID กระบวนการหมดในอินสแตนซ์ เนื่องจากการโหลดโมเดลจำนวนมากเกินไปและเฟรมเวิร์ก ML พื้นฐาน (เช่น TensorFlow) ทำให้เกิดเธรดต่อโมเดลที่มีหลายรายการ vCPU

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

เวลาแฝงของโมเดลปลายทางอินสแตนซ์เดียว

การใช้ CPU และหน่วยความจำปลายทางอินสแตนซ์เดียว

เวลาแฝงของโมเดลปลายทางอินสแตนซ์สี่อินสแตนซ์

การใช้ CPU และหน่วยความจำปลายทางสี่อินสแตนซ์

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

แบบจำลองทางจิตสำหรับการเพิ่มประสิทธิภาพ MME

มีเมตริกหลักสี่ประการที่คุณควรพิจารณาเสมอเมื่อปรับขนาด MME ให้เหมาะสม:

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

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

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

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

สรุป

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

ในการเริ่มต้นใช้งาน MME ให้ทบทวน จุดยุติหลายรุ่นของ Amazon SageMaker โดยใช้ XGBoost และ โฮสต์หลายรุ่นในคอนเทนเนอร์เดียวหลังปลายทางเดียว.

เกี่ยวกับผู้เขียน

ไซด แจฟฟรี เป็น Principal Solutions Architect กับ AWS เขาทำงานร่วมกับบริษัทต่างๆ ตั้งแต่องค์กรขนาดกลาง องค์กรขนาดใหญ่ บริการทางการเงิน และ ISV เพื่อช่วยสร้างและดำเนินการแอปพลิเคชัน AI/ML ที่คุ้มค่าและปรับขนาดได้ในระบบคลาวด์

ซอราภ ตรีกันเด เป็นผู้จัดการผลิตภัณฑ์อาวุโสสำหรับการอนุมานของ Amazon SageMaker เขาหลงใหลในการทำงานกับลูกค้าและมีแรงจูงใจโดยเป้าหมายของการทำให้แมชชีนเลิร์นนิงเป็นประชาธิปไตย เขามุ่งเน้นไปที่ความท้าทายหลักที่เกี่ยวข้องกับการปรับใช้งานแอปพลิเคชัน ML ที่ซับซ้อน โมเดล ML แบบหลายผู้เช่า การเพิ่มประสิทธิภาพต้นทุน และทำให้การปรับใช้โมเดลการเรียนรู้เชิงลึกสามารถเข้าถึงได้มากขึ้น ในเวลาว่าง Saurabh สนุกกับการเดินป่า เรียนรู้เกี่ยวกับเทคโนโลยีที่เป็นนวัตกรรม ติดตาม TechCrunch และใช้เวลากับครอบครัวของเขา