การอนุมาน ML ที่คุ้มค่าด้วยโมเดลหลายเฟรมเวิร์กบน Amazon SageMaker 

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

อเมซอน SageMaker multi-container endpoints (MCE) ช่วยให้เราสามารถจัดกลุ่มโมเดลบนเฟรมเวิร์กต่างๆ และปรับใช้โมเดลเหล่านี้ในโฮสต์เดียวกัน โดยสร้างเอ็นด์พอยท์เดียว คุณสามารถจัดเตรียมคอนเทนเนอร์สำหรับเฟรมเวิร์กต่างๆ ที่คุณใช้สร้างโมเดลได้ และ SageMaker จะนำคอนเทนเนอร์ทั้งหมดเหล่านี้ไปไว้เบื้องหลังปลายทางแห่งเดียว ตัวอย่างเช่น คุณสามารถโหลดโมเดล PyTorch และ TensorFlow บนปลายทางเฉพาะสองจุดที่ให้บริการกรณีการใช้งานเดียวกันหรือต่างกันโดยสิ้นเชิง และทั้งสองรุ่นเหล่านี้มีการรับส่งข้อมูลขาเข้าเป็นระยะ ๆ โดยไม่ได้ใช้ทรัพยากรจนถึงขีดจำกัด ในสถานการณ์เช่นนี้ คุณสามารถรวมเข้าด้วยกันโดยใช้คอนเทนเนอร์เป็นปลายทางเดียวโดยใช้ MCE ปรับปรุงการใช้ทรัพยากรในขณะที่ลดต้นทุนที่เกิดขึ้นในการให้ทั้งสองรุ่นให้บริการจากปลายทางที่แตกต่างกัน

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

ในโพสต์นี้ เราจะพูดถึงวิธีการอนุมาน ML ที่คุ้มค่าใช้จ่ายด้วยโมเดลหลายเฟรมเวิร์กบน SageMaker

รูปแบบการเรียก MCE

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

ด้วยการเรียกใช้แบบอนุกรม คุณสามารถต่อคอนเทนเนอร์ 2–15 คอนเทนเนอร์เข้าด้วยกัน และผลลัพธ์ของหนึ่งจะกลายเป็นอินพุตของคอนเทนเนอร์ถัดไปตามลำดับ นี่เป็นกรณีการใช้งานที่เหมาะสม ตัวอย่างเช่น หากคุณมีไปป์ไลน์การทำนายแบบหลายขั้นตอนซึ่งโมเดล Scikit-learn ใช้สำหรับการคาดการณ์ระดับกลาง และผลลัพธ์จะถูกป้อนไปยังโมเดล TensorFlow สำหรับการอนุมานขั้นสุดท้าย แทนที่จะปรับใช้เป็นจุดปลายทางที่แตกต่างกัน และแอปพลิเคชันหรืองานอื่นที่จัดการพวกมันและทำการเรียก API หลายรายการ คุณสามารถปรับใช้มันเป็น SageMaker MCE แยกตรรกะและตั้งค่าสำหรับการเรียกใช้อนุกรม โดยที่ SageMaker จัดการการถ่ายโอนข้อมูลระหว่างคอนเทนเนอร์เดียว ไปยังอีกอันหนึ่งโดยอัตโนมัติและส่งเอาต์พุตของคอนเทนเนอร์สุดท้ายไปยังไคลเอ็นต์ที่ส่งคำขอ API

การเรียกใช้อนุกรม SageMaker MCE นั้นแตกต่างจากไปป์ไลน์การอนุมานแบบอนุกรมของ SageMaker โดยพื้นฐาน (รายละเอียดเพิ่มเติมในส่วนด้านล่าง) ไปป์ไลน์การอนุมานแบบอนุกรมมีเป้าหมายมากกว่าเพื่อจัดการเวิร์กโฟลว์ ML ที่ซับซ้อน เช่น การประมวลผลข้อมูลล่วงหน้า การสร้างชุดโมเดล การใช้การตรวจสอบตามเงื่อนไขเพื่อกำหนดว่าโมเดลใดที่จะเรียกใช้ หรือการประมวลผลภายหลังการทำนาย ซึ่งเกี่ยวข้องกับตรรกะทางธุรกิจก่อนที่จะส่งการคาดการณ์ไปยังแอปพลิเคชันดาวน์สตรีม . ในทางตรงกันข้าม การเรียกใช้แบบอนุกรม MCE ได้รับการออกแบบมาเพื่อเชื่อมต่อโมเดล 2-14 ตัวเข้ากับไปป์ไลน์สำหรับการอนุมาน โดยแต่ละโมเดลจะรับการคาดการณ์ของโมเดลก่อนหน้าเป็นอินพุต

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

ลองดูกรณีการใช้งานสองสามกรณีและดูว่าคุณสามารถใช้ SageMaker MCE เพื่อเพิ่มประสิทธิภาพการอนุมาน ML ได้อย่างไร

กรณีการใช้งานสำหรับ SageMaker MCEs

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

englishModel = {
   'Image': container1,
   'ContainerHostname': englishModel }; ...
 
germanModel = {
   'Image': container2,
   'ContainerHostname': germanModel }; ...
 
sm.create_model(
   InferenceExecutionConfig = {'Mode': 'Direct'},
   Containers = [englishModel, germanModel], ...)
sm.create_endpoint_config(EndpointConfigName = ‘my-mce-epc’,
    ProductionVariants=[{
        'InstanceType':        ‘ml.m4.xlarge’,
        'InitialInstanceCount': 2,
        'InitialVariantWeight': 1,
        'ModelName':            ‘my-multi-model-name’,
        'VariantName':          'AllTraffic'}])
sm.create_endpoint(EndpointName = ‘my-mce-endpoint’, 
                  EndpointConfigName = ‘my-mce-epc’)

ในตัวอย่างนี้ เรามีสองรุ่น (englishModel และ germanModel) และเรากำหนดคอนเทนเนอร์ใน SageMaker create_model สร้างและกำหนด InferenceExecutionConfig เป็น 'โดยตรง' ตอนนี้เราสามารถเรียกจุดสิ้นสุดสำหรับการอนุมานและกำหนด TargetContainerHostname เป็นอย่างใดอย่างหนึ่ง englishModel or germanModel ขึ้นอยู่กับไคลเอนต์ที่ทำการเรียก API:

sm.invoke_endpoint(        
   EndpointName = endpoint_name,
   TargetContainerHostname = englishModel,
   Body = body, ...)

คุณยังสามารถใช้การเรียกใช้โดยตรงภายใน MCE เพื่อเรียกใช้การทดสอบ A/B เพื่อเปรียบเทียบประสิทธิภาพระหว่างรุ่นต่างๆ

แผนภาพต่อไปนี้แสดงสถาปัตยกรรมของเรา

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

สำหรับกรณีการใช้งานนี้ เราใช้รหัสต่อไปนี้:

sm_model = PipelineModel(name=model_name, role=aws_role, models=[Processing-1, Processing-2, Inference-1, Inference-2]) 

predictor = sm_model.deploy(initial_instance_count=1, instance_type="ml.c4.xlarge")                  
response = runtime.invoke_endpoint( 
EndpointName=predictor.endpoint,                                
    Body=body,...)

ในตัวอย่างนี้ เรามีคอนเทนเนอร์การประมวลผลสองคอนเทนเนอร์ (Processing-1 และ Processing-2) สำหรับการประมวลผลคุณลักษณะและการแปลงข้อมูล และคอนเทนเนอร์อนุมานสองคอนเทนเนอร์ (Inference-1 และ Inference-2) เพื่อเรียกใช้การคาดการณ์แบบจำลอง ML บนข้อมูลที่ประมวลผลล่วงหน้า ดิ PipelineModel อินสแตนซ์ช่วยให้คุณกำหนดไปป์ไลน์การอนุมานที่ประกอบด้วยลำดับเชิงเส้นของคอนเทนเนอร์สี่ตัวที่ประมวลผลคำขอสำหรับการอนุมานข้อมูล คอนเทนเนอร์ถูกจัดวางร่วมกันในอินสแตนซ์เดียวกัน ทำให้คุณสามารถทำการอนุมานได้โดยมีเวลาแฝงต่ำ

ปรับขนาดจุดปลายหลายรุ่นสำหรับรุ่นจำนวนมาก

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

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

# AutoScaling client
asg = boto3.client('application-autoscaling')

# Resource type is variant and the unique identifier is the resource ID.
resource_id=f"endpoint/{endpoint_name}/variant/AllTraffic"

# scaling configuration
response = asg.register_scalable_target(
    ServiceNamespace='sagemaker', #
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount', 
    MinCapacity=1,
    MaxCapacity=4
)
#Target Scaling
response = asg.put_scaling_policy(
    PolicyName=f'Request-ScalingPolicy-{endpoint_name}',
    ServiceNamespace='sagemaker',
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount',
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 70.0, # Threshold
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'SageMakerVariantInvocationsPerInstance',
        },
        'ScaleInCooldown': 300, # duration until scale in
        'ScaleOutCooldown': 60 # duration between scale out
    }
)

ตามตัวอย่างการกำหนดค่านโยบายก่อนหน้านี้ เราใช้ SageMakerVariantInvocationsPerInstance เมตริกที่กำหนดไว้ล่วงหน้าเพื่อปรับจำนวนอินสแตนซ์ตัวแปรเพื่อให้แต่ละอินสแตนซ์มี InvocationsPerInstance เมตริก 70

เรายังปรับขนาด SageMaker MCE ตามเมตริกที่เรากำหนดเองได้ เช่น CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilization,หรือ DiskUtilizationเพื่อเพิ่มหรือลดจำนวนอินสแตนซ์ตามการใช้ทรัพยากรเฉพาะ สำหรับข้อมูลเพิ่มเติม โปรดดูที่ ปรับขนาดโมเดล Amazon SageMaker โดยอัตโนมัติ.

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

MCE ที่ปลอดภัย

สำหรับ MCE ที่มีการเรียกใช้โดยตรง คอนเทนเนอร์หลายรายการจะถูกโฮสต์ในอินสแตนซ์เดียวโดยการแชร์หน่วยความจำและโวลุ่มพื้นที่เก็บข้อมูล สิ่งสำคัญคือต้องรักษาความปลอดภัยคอนเทนเนอร์ รักษาการแมปคำขอไปยังคอนเทนเนอร์เป้าหมายที่ถูกต้อง และให้ผู้ใช้เข้าถึงคอนเทนเนอร์เป้าหมายได้อย่างถูกต้อง คุณสามารถจำกัด invoke_endpoint เข้าถึงชุดคอนเทนเนอร์ที่จำกัดภายใน MCE โดยใช้ sagemaker:TargetContainerHostname AWS Identity และการจัดการการเข้าถึง (IAM) คีย์เงื่อนไข SageMaker ใช้ บทบาท IAM เพื่อจัดเตรียมนโยบายตามข้อมูลประจำตัว IAM ที่คุณใช้เพื่อระบุการดำเนินการและทรัพยากรที่อนุญาตหรือปฏิเสธ และเงื่อนไขภายใต้การดำเนินการที่อนุญาตหรือปฏิเสธ นโยบายต่อไปนี้แสดงวิธีจำกัดการเรียกไปยังคอนเทนเนอร์เฉพาะภายในปลายทาง:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sagemaker:InvokeEndpoint"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:sagemaker:region:account-id:endpoint/endpoint_name",
            "Condition": {
                "StringLike": {
                    "sagemaker:TargetContainerHostname": ["customIps*", "common*"]
                }
            }
        }
    ]
}

ตรวจสอบตำแหน่งข้อมูลหลายรุ่นโดยใช้ตัววัด Amazon CloudWatch

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

• รุ่นกำลังโหลดWaitTime – ช่วงเวลาที่คำขอเรียกใช้รอให้ดาวน์โหลดหรือโหลดโมเดลเป้าหมายเพื่อทำการอนุมาน
• รุ่นUnloadingTime – ช่วงเวลาที่ใช้ในการขนถ่ายโมเดลผ่านคอนเทนเนอร์ UnloadModel การเรียก API
• โมเดลการดาวน์โหลดเวลา – ช่วงเวลาที่ใช้ในการดาวน์โหลดโมเดลจาก Amazon S3
• รุ่นLoadingTime – ช่วงเวลาที่ใช้ในการโหลดโมเดลผ่านคอนเทนเนอร์ LoadModel การเรียก API
• รุ่น CacheHit - จำนวน InvokeEndpoint คำขอที่ส่งไปยังปลายทางที่โหลดโมเดลแล้ว การ Average สถิติแสดงอัตราส่วนของคำขอที่โหลดแบบจำลองแล้ว
• โหลด ModelCount – จำนวนรุ่นที่โหลดในคอนเทนเนอร์ในปลายทาง เมตริกนี้ปล่อยออกมาต่ออินสแตนซ์ ดิ Average สถิติที่มีระยะเวลา 1 นาทีจะบอกให้คุณทราบจำนวนเฉลี่ยของโมเดลที่โหลดต่ออินสแตนซ์ และ Sum สถิติจะบอกให้คุณทราบถึงจำนวนโมเดลทั้งหมดที่โหลดในทุกอินสแตนซ์ในปลายทาง โมเดลที่ตัววัดนี้ติดตามไม่จำเป็นต้องซ้ำกัน เนื่องจากคุณสามารถโหลดโมเดลในคอนเทนเนอร์หลายตัวในปลายทางได้

นอกจากนี้ยังมีตัวชี้วัดอื่นๆ อีกหลายตัวที่ใช้โดยคอนเทนเนอร์แต่ละตัวที่ทำงานบนอินสแตนซ์ เช่น Invocations ระบุจำนวน InvokeEndpoint คำขอที่ส่งไปยังคอนเทนเนอร์ภายในปลายทาง ContainerLatency ระบุเวลาที่ปลายทางใช้สำหรับคอนเทนเนอร์เป้าหมายหรือคอนเทนเนอร์ทั้งหมดในการร้องขอแบบอนุกรมเพื่อตอบสนองตามที่ดูจาก SageMaker และ CPUUtilization และ MemoryUtilizaton ระบุหน่วย CPU และเปอร์เซ็นต์ของหน่วยความจำ

สรุป

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

• โมเดลการโฮสต์บนเฟรมเวิร์กต่างๆ (เช่น TensorFlow, PyTorch และ Scikit-learn) ที่มีทราฟฟิกไม่เพียงพอที่จะทำให้อินสแตนซ์เต็มความจุ
• โมเดลการโฮสต์จากเฟรมเวิร์กเดียวกันกับอัลกอริธึม ML ที่แตกต่างกัน (เช่น คำแนะนำ การคาดการณ์ หรือการจัดประเภท) และฟังก์ชันตัวจัดการ
• การเปรียบเทียบสถาปัตยกรรมที่คล้ายกันที่ทำงานบนเฟรมเวิร์กเวอร์ชันต่างๆ (เช่น TensorFlow 1.x กับ TensorFlow 2.x) สำหรับสถานการณ์ต่างๆ เช่น การทดสอบ A/B

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

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

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

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

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