Veriff ลดเวลาในการปรับใช้ลง 80% โดยใช้ตำแหน่งข้อมูลหลายรุ่นของ Amazon SageMaker | ได้อย่างไร อเมซอนเว็บเซอร์วิส

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

Veriff นำเสนอโครงสร้างพื้นฐานที่ได้รับการพิสูจน์แล้วซึ่งช่วยให้ลูกค้าของพวกเขาได้รับความไว้วางใจในอัตลักษณ์และคุณลักษณะส่วนบุคคลของผู้ใช้ตลอดช่วงเวลาที่เกี่ยวข้องทั้งหมดบนเส้นทางของลูกค้า Veriff ได้รับความไว้วางใจจากลูกค้าเช่น Bolt, Deel, Monese, Starship, Super Awesome, Trustpilot และ Wise

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

ในโพสต์นี้ เราจะแสดงให้คุณเห็นว่า Veriff สร้างมาตรฐานให้กับเวิร์กโฟลว์การปรับใช้โมเดลของตนได้อย่างไร อเมซอน SageMakerลดต้นทุนและระยะเวลาในการพัฒนา

ความท้าทายด้านโครงสร้างพื้นฐานและการพัฒนา

สถาปัตยกรรมแบ็กเอนด์ของ Veriff ขึ้นอยู่กับรูปแบบไมโครเซอร์วิส พร้อมด้วยบริการที่ทำงานบนคลัสเตอร์ Kubernetes ที่แตกต่างกันซึ่งโฮสต์บนโครงสร้างพื้นฐาน AWS แนวทางนี้เริ่มใช้กับบริการทั้งหมดของบริษัท รวมถึงไมโครเซอร์วิสที่ใช้โมเดล ML ของคอมพิวเตอร์วิทัศน์ราคาแพง

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

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

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

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

ภาพรวมโซลูชัน

Veriff ต้องการโซลูชันใหม่ที่แก้ไขปัญหาสองประการ:

• อนุญาตให้สร้าง REST API wrappers รอบโมเดล ML ได้อย่างง่ายดาย
• อนุญาตให้จัดการความจุของอินสแตนซ์ GPU ที่จัดเตรียมไว้อย่างเหมาะสมที่สุด และโดยอัตโนมัติ หากเป็นไปได้

ในที่สุด ทีมงานแพลตฟอร์ม ML ก็มารวมตัวกันเพื่อตัดสินใจใช้งาน จุดสิ้นสุดหลายโมเดลของ Sagemaker (MME) การตัดสินใจครั้งนี้ได้รับแรงผลักดันจากการสนับสนุนของ MME สำหรับ NVIDIA เซิร์ฟเวอร์การอนุมานไทรทัน (เซิร์ฟเวอร์ที่เน้น ML ซึ่งทำให้ง่ายต่อการรวมโมเดลเป็น REST API นอกจากนี้ Veriff ยังได้ทดลองใช้ Triton อีกด้วย) รวมถึงความสามารถในการจัดการการปรับขนาดอัตโนมัติของอินสแตนซ์ GPU ผ่านนโยบายการปรับขนาดอัตโนมัติแบบง่าย

MME สองอันถูกสร้างขึ้นที่ Veriff หนึ่งอันสำหรับการแสดงละครและอีกอันสำหรับการผลิต แนวทางนี้ช่วยให้พวกเขาสามารถรันขั้นตอนการทดสอบในสภาพแวดล้อมชั่วคราวได้โดยไม่กระทบต่อโมเดลการใช้งานจริง

MME ของ SageMaker

SageMaker เป็นบริการที่มีการจัดการเต็มรูปแบบซึ่งช่วยให้นักพัฒนาและนักวิทยาศาสตร์ข้อมูลสามารถสร้าง ฝึกฝน และปรับใช้โมเดล ML ได้อย่างรวดเร็ว SageMaker MME มอบโซลูชันที่ปรับขนาดได้และคุ้มค่าสำหรับการปรับใช้โมเดลจำนวนมากสำหรับการอนุมานแบบเรียลไทม์ MME ใช้คอนเทนเนอร์ที่ให้บริการร่วมกันและกลุ่มทรัพยากรที่สามารถใช้อินสแตนซ์แบบเร่ง เช่น GPU เพื่อโฮสต์โมเดลทั้งหมดของคุณ สิ่งนี้ช่วยลดต้นทุนการโฮสต์โดยเพิ่มการใช้งานปลายทางให้สูงสุดเมื่อเทียบกับการใช้อุปกรณ์ปลายทางรุ่นเดียว นอกจากนี้ยังลดค่าใช้จ่ายในการปรับใช้เนื่องจาก SageMaker จัดการการโหลดและยกเลิกการโหลดโมเดลในหน่วยความจำและปรับขนาดตามรูปแบบการรับส่งข้อมูลของปลายทาง นอกจากนี้ จุดสิ้นสุดตามเวลาจริงของ SageMaker ทั้งหมดยังได้รับประโยชน์จากความสามารถในตัวในการจัดการและตรวจสอบโมเดล เช่น ตัวแปรเงา, ปรับขนาดอัตโนมัติและการรวมเนทีฟด้วย อเมซอน คลาวด์วอตช์ (ดูข้อมูลเพิ่มเติมได้ที่ เมตริก CloudWatch สำหรับการปรับใช้ปลายทางหลายรุ่น).

โมเดลชุดแต่ง Triton แบบกำหนดเอง

มีสาเหตุหลายประการที่ทำให้ Veriff ตัดสินใจใช้ Triton Inference Server เหตุผลหลักคือ:

• ช่วยให้นักวิทยาศาสตร์ข้อมูลสามารถสร้าง REST API จากแบบจำลองโดยการจัดเรียงไฟล์สิ่งประดิษฐ์ของแบบจำลองในรูปแบบไดเร็กทอรีมาตรฐาน (ไม่มีโซลูชันโค้ด)
• มันเข้ากันได้กับเฟรมเวิร์ก AI หลักทั้งหมด (PyTorch, Tensorflow, XGBoost และอื่น ๆ )
• โดยนำเสนอการเพิ่มประสิทธิภาพเซิร์ฟเวอร์ระดับต่ำและเฉพาะเจาะจงของ ML เช่น แบทช์แบบไดนามิก ของการร้องขอ

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

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

ต่อไปนี้คือลักษณะของพื้นที่เก็บข้อมูลโมเดล Triton โดยทั่วไปสำหรับปริมาณงานนี้:

พื้นที่ model.py ไฟล์มีโค้ดการประมวลผลล่วงหน้าและการประมวลผลภายหลัง ตุ้มน้ำหนักแบบจำลองที่ผ่านการฝึกอบรมอยู่ใน screen_detection_inferencer ไดเร็กทอรีภายใต้เวอร์ชันโมเดล 1 (โมเดลอยู่ในรูปแบบ ONNX ในตัวอย่างนี้ แต่อาจเป็นรูปแบบ TensorFlow, PyTorch หรืออื่นๆ ก็ได้) คำจำกัดความของโมเดลทั้งมวลอยู่ใน screen_detection_pipeline ไดเร็กทอรีที่อินพุตและเอาต์พุตระหว่างขั้นตอนถูกแมปในไฟล์คอนฟิกูเรชัน

การขึ้นต่อกันเพิ่มเติมที่จำเป็นในการรันโมเดล Python มีรายละเอียดอยู่ในไฟล์ requirements.txt และจำเป็นต้องบรรจุ conda เพื่อสร้างสภาพแวดล้อม Conda (python_env.tar.gz). สำหรับข้อมูลเพิ่มเติม โปรดดูที่ การจัดการรันไทม์และไลบรารีของ Python. นอกจากนี้ ไฟล์กำหนดค่าสำหรับขั้นตอน Python จะต้องชี้ไปที่ด้วย python_env.tar.gz โดยใช้โปรแกรม EXECUTION_ENV_PATH คำสั่ง

โฟลเดอร์โมเดลจะต้องได้รับการบีบอัด TAR และเปลี่ยนชื่อโดยใช้ model_version.txt. สุดท้ายก็เกิดผล <model_name>_<model_version>.tar.gz ไฟล์จะถูกคัดลอกไปที่ บริการจัดเก็บข้อมูลอย่างง่ายของ Amazon ที่เก็บข้อมูล (Amazon S3) เชื่อมต่อกับ MME ทำให้ SageMaker สามารถตรวจจับและให้บริการโมเดลได้

การกำหนดเวอร์ชันโมเดลและการปรับใช้อย่างต่อเนื่อง

ตามที่อธิบายไว้ในหัวข้อที่แล้ว การสร้างที่เก็บแบบจำลอง Triton นั้นตรงไปตรงมา อย่างไรก็ตาม การรันขั้นตอนที่จำเป็นทั้งหมดเพื่อปรับใช้เป็นเรื่องที่น่าเบื่อและเกิดข้อผิดพลาดได้ง่าย หากดำเนินการด้วยตนเอง เพื่อเอาชนะสิ่งนี้ Veriff ได้สร้าง monorepo ที่มีโมเดลทั้งหมดเพื่อนำไปใช้กับ MME โดยที่นักวิทยาศาสตร์ข้อมูลร่วมมือกันในแนวทางที่คล้ายกับ Gitflow monorepo นี้มีคุณสมบัติดังต่อไปนี้:

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

monorepo นี้ถูกรวมเข้ากับเครื่องมือการรวมอย่างต่อเนื่อง (CI) สำหรับการพุชใหม่ไปยัง repo หรือโมเดลใหม่ทุกครั้ง จะมีการดำเนินการขั้นตอนต่อไปนี้:

1. ผ่านการตรวจสอบคุณภาพรหัส
2. ดาวน์โหลดตุ้มน้ำหนักโมเดล
3. สร้างสภาพแวดล้อม Conda
4. หมุนเซิร์ฟเวอร์ Triton โดยใช้สภาพแวดล้อม Conda และใช้เพื่อประมวลผลคำขอที่กำหนดไว้ในการทดสอบหน่วย
5. สร้างไฟล์ TAR ของโมเดลสุดท้าย (<model_name>_<model_version>.tar.gz).

ขั้นตอนเหล่านี้ช่วยให้แน่ใจว่าโมเดลมีคุณภาพที่จำเป็นสำหรับการปรับใช้ ดังนั้นทุกครั้งที่พุชไปยังสาขา Repo ไฟล์ TAR ที่เป็นผลลัพธ์จะถูกคัดลอก (ในขั้นตอน CI อื่น) ไปยังบัคเก็ต Staging S3 เมื่อพุชเสร็จสิ้นในสาขาหลัก ไฟล์โมเดลจะถูกคัดลอกไปยังบัคเก็ต S3 ที่ใช้งานจริง แผนภาพต่อไปนี้แสดงระบบ CI/CD นี้

ประโยชน์ด้านต้นทุนและความเร็วในการปรับใช้

การใช้ MME ช่วยให้ Veriff สามารถใช้แนวทาง monorepo เพื่อปรับใช้โมเดลกับการใช้งานจริง โดยสรุป เวิร์กโฟลว์การปรับใช้โมเดลใหม่ของ Veriff ประกอบด้วยขั้นตอนต่อไปนี้:

1. สร้างสาขาใน monorepo ด้วยโมเดลใหม่หรือเวอร์ชันโมเดล
2. กำหนดและรันการทดสอบหน่วยในเครื่องสำหรับการพัฒนา
3. พุชสาขาเมื่อโมเดลพร้อมที่จะทดสอบในสภาพแวดล้อมชั่วคราว
4. รวมสาขาเข้ากับสาขาหลักเมื่อโมเดลพร้อมที่จะใช้ในการผลิต

ด้วยโซลูชันใหม่นี้ การปรับใช้โมเดลที่ Veriff ถือเป็นส่วนที่ตรงไปตรงมาของกระบวนการพัฒนา เวลาในการพัฒนาโมเดลใหม่ลดลงจาก 10 วันเหลือเฉลี่ย 2 วัน

การจัดเตรียมโครงสร้างพื้นฐานที่มีการจัดการและคุณสมบัติการปรับขนาดอัตโนมัติของ SageMaker ทำให้ Veriff ได้รับประโยชน์เพิ่มเติม พวกเขาใช้ การเรียกใช้ต่ออินสแตนซ์ ตัววัด CloudWatch จะปรับขนาดตามรูปแบบการรับส่งข้อมูล ประหยัดค่าใช้จ่ายโดยไม่สูญเสียความน่าเชื่อถือ เพื่อกำหนดค่าเกณฑ์สำหรับเมตริก พวกเขาทำการทดสอบโหลดบนตำแหน่งข้อมูลชั่วคราวเพื่อค้นหาจุดแลกเปลี่ยนที่ดีที่สุดระหว่างเวลาแฝงและต้นทุน

หลังจากปรับใช้โมเดลการผลิตเจ็ดโมเดลกับ MME และวิเคราะห์การใช้จ่าย Veriff รายงานว่าต้นทุนโมเดล GPU ลดลง 75% เมื่อเทียบกับโซลูชันที่ใช้ Kubernetes ดั้งเดิม ค่าใช้จ่ายในการดำเนินงานก็ลดลงเช่นกัน เนื่องจากวิศวกร DevOps ของบริษัทมีภาระในการจัดเตรียมอินสแตนซ์ด้วยตนเอง

สรุป

ในโพสต์นี้ เราได้ตรวจสอบสาเหตุที่ Veriff เลือก Sagemaker MME แทนที่จะปรับใช้โมเดลแบบจัดการด้วยตนเองบน Kubernetes SageMaker รับมือกับการยกของหนักที่ไม่มีความแตกต่าง ช่วยให้ Veriff ลดเวลาในการพัฒนาโมเดล เพิ่มประสิทธิภาพทางวิศวกรรม และลดต้นทุนสำหรับการอนุมานแบบเรียลไทม์ได้อย่างมาก ขณะเดียวกันก็รักษาประสิทธิภาพที่จำเป็นสำหรับการดำเนินงานที่สำคัญทางธุรกิจ สุดท้ายนี้ เราได้จัดแสดงไปป์ไลน์ CI/CD การปรับใช้โมเดลที่เรียบง่ายแต่มีประสิทธิภาพของ Veriff และกลไกการกำหนดเวอร์ชันโมเดล ซึ่งสามารถใช้เป็นการดำเนินการอ้างอิงในการรวมแนวทางปฏิบัติที่ดีที่สุดในการพัฒนาซอฟต์แวร์และ SageMaker MME คุณสามารถค้นหาตัวอย่างโค้ดได้บนโฮสต์หลายโมเดลโดยใช้ SageMaker MME GitHub.

---

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

ริคาร์ด บอร์ราส เป็น Machine Learning อาวุโสที่ Veriff ซึ่งเขาเป็นผู้นำด้าน MLOps ในบริษัท เขาช่วยนักวิทยาศาสตร์ข้อมูลสร้างผลิตภัณฑ์ AI / ML ที่รวดเร็วและดีขึ้นโดยการสร้างแพลตฟอร์มวิทยาศาสตร์ข้อมูลที่บริษัท และผสมผสานโซลูชันโอเพ่นซอร์สหลายรายการเข้ากับบริการของ AWS

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

มิเกลเฟอร์เรรา ทำงานเป็น Sr. Solutions Architect ที่ AWS ในเมืองเฮลซิงกิ ประเทศฟินแลนด์ AI/ML ได้รับความสนใจมาตลอดชีวิต และเขาได้ช่วยลูกค้าหลายรายในการรวม Amazon SageMaker เข้ากับเวิร์กโฟลว์ ML ของพวกเขา

• เนื้อหาที่ขับเคลื่อนด้วย SEO และการเผยแพร่ประชาสัมพันธ์ รับการขยายวันนี้
• PlatoData.Network Vertical Generative Ai เพิ่มพลังให้กับตัวเอง เข้าถึงได้ที่นี่.
• เพลโตไอสตรีม. Web3 อัจฉริยะ ขยายความรู้ เข้าถึงได้ที่นี่.
• เพลโตESG. คาร์บอน, คลีนเทค, พลังงาน, สิ่งแวดล้อม แสงอาทิตย์, การจัดการของเสีย. เข้าถึงได้ที่นี่.
• เพลโตสุขภาพ เทคโนโลยีชีวภาพและข่าวกรองการทดลองทางคลินิก เข้าถึงได้ที่นี่.
• ที่มา: https://aws.amazon.com/blogs/machine-learning/how-veriff-decreased-deployment-time-by-80-using-amazon-sagemaker-multi-model-endpoints/