AWS Study Group

Tối ưu hóa triển khai các Guardrailsvới rolling updates cho inference component trong Amazon SageMaker AI inference

Tác giả: Melanie Li, Andrew Smith, Dustin Liu, June Won, Shikher Mishra, và Vivek Gangasani
Ngày phát hành: 25 MAR 2025
Chuyên mục: Amazon SageMaker, Amazon SageMaker AI, Intermediate (200)

Triển khai mô hình một cách hiệu quả, đáng tin cậy và tiết kiệm chi phí là một thách thức quan trọng đối với các tổ chức ở mọi quy mô. Khi các tổ chức ngày càng triển khai các foundation model (FM) và các mô hình machine learning (ML) khác vào môi trường production, họ phải đối mặt với các thách thức liên quan đến việc sử dụng tài nguyên, hiệu quả chi phí và duy trì tính sẵn sàng cao trong quá trình cập nhật. Amazon SageMaker AI đã giới thiệu chức năng inference component có thể giúp các tổ chức giảm chi phí triển khai mô hình bằng cách tối ưu hóa việc sử dụng tài nguyên thông qua việc đóng gói và mở rộng quy mô mô hình một cách thông minh. Inference component trừu tượng hóa các mô hình ML và cho phép gán tài nguyên chuyên dụng cùng các chính sách mở rộng quy mô cụ thể cho từng mô hình.

Tuy nhiên, việc cập nhật các mô hình này—đặc biệt trong môi trường production với các SLA về độ trễ nghiêm ngặt—trước đây thường tiềm ẩn rủi ro về thời gian ngừng hoạt động hoặc tắc nghẽn tài nguyên. Các triển khai blue/green truyền thống thường gặp khó khăn với các hạn chế về dung lượng, khiến việc cập nhật trở nên khó đoán đối với các mô hình nặng về GPU. Để giải quyết vấn đề này, chúng tôi vui mừng thông báo một cải tiến mạnh mẽ khác cho SageMaker AI: cập nhật rolling updates cho các endpoint của inference component, một tính năng được thiết kế để hợp lý hóa việc cập nhật các mô hình có kích thước khác nhau đồng thời giảm thiểu chi phí vận hành.

Trong bài viết này, chúng tôi thảo luận về những thách thức mà các tổ chức phải đối mặt khi cập nhật mô hình trong môi trường production. Sau đó, chúng tôi đi sâu vào tính năng cập nhật rolling updates mới cho inference component và cung cấp các ví dụ thực tế sử dụng các mô hình DeepSeek distilled để minh họa tính năng này. Cuối cùng, chúng tôi khám phá cách thiết lập rolling updates trong các kịch bản khác nhau.

Thách thức với triển khai blue/green

Theo truyền thống, SageMaker AI inference đã hỗ trợ mô hình triển khai blue/green để cập nhật inference component trong môi trường production. Mặc dù hiệu quả cho nhiều kịch bản, phương pháp này đi kèm với những thách thức cụ thể:

  • Không hiệu quả về tài nguyên – Triển khai Blue/Green yêu cầu cấp phát tài nguyên cho cả môi trường hiện tại (blue) và môi trường mới (green) cùng một lúc. Đối với inference component chạy trên các instance GPU đắt tiền như P4d hoặc G5, điều này có nghĩa là có khả năng tăng gấp đôi yêu cầu tài nguyên trong quá trình triển khai. Hãy xem xét một ví dụ trong đó khách hàng có 10 bản sao của một inference component trải rộng trên 5 instance ml.p4d.24xlarge, tất cả đều hoạt động hết công suất. Với triển khai blue/green, SageMaker AI sẽ cần cấp phát thêm năm instance ml.p4d.24xlarge để lưu trữ phiên bản mới của inference component trước khi chuyển đổi lưu lượng truy cập và ngừng hoạt động các instance cũ.
  • Tài nguyên tính toán hạn chế – Đối với khách hàng sử dụng các instance GPU mạnh mẽ như dòng P hoặc G, dung lượng cần thiết có thể không có sẵn trong một Availability Zone hoặc Region nhất định. Điều này thường dẫn đến các ngoại lệ về dung lượng instance trong quá trình triển khai, gây ra lỗi cập nhật và rollback.
  • Chuyển đổi tất cả hoặc không có gì – Triển khai blue/green truyền thống chuyển đổi tất cả lưu lượng truy cập cùng một lúc hoặc dựa trên một lịch trình đã cấu hình. Điều này hạn chế khả năng xác thực dần dần và tăng phạm vi ảnh hưởng nếu có vấn đề phát sinh với triển khai mới.

Mặc dù triển khai blue/green là một chiến lược đáng tin cậy cho các bản cập nhật không downtime, nhưng những hạn chế của nó trở nên rõ ràng khi triển khai các large language model (LLM) quy mô lớn hoặc các mô hình thông lượng cao trên các instance GPU cao cấp. Những thách thức này đòi hỏi một cách tiếp cận tinh tế hơn—một cách tiếp cận xác thực các bản cập nhật một cách tăng dần đồng thời tối ưu hóa việc sử dụng tài nguyên. Rolling updates cho inference component được thiết kế để loại bỏ sự cứng nhắc của triển khai blue/green. Bằng cách cập nhật các mô hình theo các lô được kiểm soát, mở rộng quy mô cơ sở hạ tầng một cách linh hoạt và tích hợp các kiểm tra an toàn theo thời gian thực, chiến lược này đảm bảo việc triển khai vẫn hiệu quả về chi phí, đáng tin cậy và dễ thích ứng—ngay cả đối với các tải công việc nặng về GPU.

Triển khai Rolling để cập nhật inference component

Như đã đề cập trước đó, inference component được giới thiệu như một tính năng của SageMaker AI để tối ưu hóa chi phí; chúng cho phép bạn xác định và triển khai các tài nguyên cụ thể cần thiết cho tải công việc suy luận mô hình của bạn. Bằng cách điều chỉnh kích thước tài nguyên tính toán (right-sizing) để phù hợp với yêu cầu của mô hình, bạn có thể tiết kiệm chi phí trong quá trình cập nhật so với các phương pháp triển khai truyền thống.

Với rolling updates, SageMaker AI triển khai các phiên bản mô hình mới theo các lô inference component có thể cấu hình được trong khi tự động mở rộng quy mô instance. Điều này đặc biệt có tác động lớn đối với LLM:

  • Linh hoạt về kích thước lô – Khi cập nhật inference component trong một endpoint của SageMaker AI, bạn có thể chỉ định kích thước lô (batch size) cho mỗi bước Rolling. Đối với mỗi bước, SageMaker AI cấp phát dung lượng dựa trên kích thước lô đã chỉ định trên fleet endpoint mới, định tuyến lưu lượng truy cập đến fleet đó và dừng dung lượng trên fleet endpoint cũ. Các mô hình nhỏ hơn như DeepSeek Distilled Llama 8B có thể sử dụng các lô lớn hơn để cập nhật nhanh chóng, và các mô hình lớn hơn như DeepSeek Distilled Llama 70B sử dụng các lô nhỏ hơn để hạn chế tranh chấp GPU.
  • Các rào chắn an toàn tự động – Các Amazon CloudWatch alarm được tích hợp sẽ giám sát các metric trên một inference component. Bạn có thể cấu hình các alarm để kiểm tra xem phiên bản inference component mới được triển khai có hoạt động bình thường hay không. Nếu các CloudWatch alarm được kích hoạt, SageMaker AI sẽ bắt đầu quá trình rollback tự động.

Chức năng mới được triển khai thông qua các phần mở rộng cho SageMaker AI API, chủ yếu với các tham số mới trong API UpdateInferenceComponent:

sagemaker_client.update_inference_component(
    InferenceComponentName=inference_component_name,
    RuntimeConfig={ "CopyCount": number }, 
    Specification={ ... },
    DeploymentConfig={
        "RollingUpdatePolicy": {
            "MaximumBatchSize": { # Value must be between 5% to 50% of the IC's total copy count.
                "Type": "COPY_COUNT", # COPY_COUNT | CAPACITY_PERCENT
                "Value": 1 # Minimum value of 1
            },
            "MaximumExecutionTimeoutInSeconds": 600, #Minimum value of 600. Maximum value of 28800.
            "RollbackMaximumBatchSize": { 
               "Type": "COPY_COUNT", # COPY_COUNT | CAPACITY_PERCENT
               "Value":1
            },
            "WaitIntervalInSeconds": 120 # Minimum value of 0. Maximum value of 3600
        }
    },
    AutoRollbackConfiguration={ 
         "Alarms": [ 
            { 
               "AlarmName": "string" #Optional
            }
         ]
      },
)

Đoạn code trên sử dụng các tham số sau:

  • MaximumBatchSize – Đây là tham số bắt buộc và xác định kích thước lô cho mỗi bước Rolling trong quá trình triển khai. Đối với mỗi bước, SageMaker AI cấp phát dung lượng trên fleet endpoint mới, định tuyến lưu lượng truy cập đến fleet đó và dừng dung lượng trên fleet endpoint cũ. Giá trị phải nằm trong khoảng từ 5–50% tổng số bản sao (copy count) của inference component.
    • Type – Tham số này có thể chứa giá trị như COPY_COUNT | CAPACITY_PERCENT, chỉ định loại dung lượng endpoint.
    • Value – Tham số này xác định kích thước dung lượng, dưới dạng số lượng bản sao của inference component hoặc tỷ lệ phần trăm dung lượng.
  • MaximumExecutionTimeoutInSeconds – Đây là thời gian tối đa mà quá trình triển khai Rolling sẽ dành cho việc thực thi tổng thể. Vượt quá giới hạn này sẽ gây ra timeout.
  • RollbackMaximumBatchSize – Đây là kích thước lô cho quá trình rollback về fleet endpoint cũ. Nếu trường này không có, giá trị sẽ được đặt thành mặc định, là 100% tổng dung lượng. Khi sử dụng giá trị mặc định, SageMaker AI sẽ cấp phát toàn bộ dung lượng của fleet cũ cùng một lúc trong quá trình rollback.
    • Value – Tham số Value của cấu trúc này sẽ chứa giá trị mà Type sẽ được thực thi. Đối với chiến lược rollback, nếu bạn không chỉ định các trường trong đối tượng này, hoặc nếu bạn đặt Value thành 100%, thì SageMaker AI sẽ sử dụng chiến lược rollback blue/green và chuyển lưu lượng truy cập trở lại fleet blue.
  • WaitIntervalInSeconds – Đây là giới hạn thời gian cho toàn bộ quá trình triển khai. Vượt quá giới hạn này sẽ gây ra timeout.
  • AutoRollbackConfiguration – Đây là cấu hình rollback tự động để xử lý các lỗi và phục hồi triển khai endpoint.
    • AlarmName – CloudWatch alarm này được cấu hình để giám sát các metric trên một InferenceComponent. Bạn có thể cấu hình nó để kiểm tra xem phiên bản InferenceComponent mới được triển khai có hoạt động bình thường hay không.

Để biết thêm thông tin về SageMaker AI API, hãy tham khảo Tài liệu tham khảo SageMaker AI API.

Trải nghiệm khách hàng

Hãy cùng khám phá cách rolling updates hoạt động trong thực tế với một số kịch bản phổ biến, sử dụng các LLM có kích thước khác nhau. Bạn có thể tìm thấy sổ tay ví dụ trong repo GitHub.

Kịch bản 1: Nhiều cluster GPU đơn lẻ

Trong kịch bản này, giả sử bạn đang chạy một endpoint với ba instance ml.g5.2xlarge, mỗi instance có một GPU đơn lẻ. Endpoint lưu trữ một inference component yêu cầu một bộ tăng tốc GPU, nghĩa là mỗi instance chứa một bản sao. Khi bạn muốn cập nhật inference component để sử dụng phiên bản inference component mới, bạn có thể sử dụng rolling updates để giảm thiểu sự gián đoạn.

Bạn có thể cấu hình rolling updates với kích thước lô là một, nghĩa là SageMaker AI sẽ cập nhật từng bản sao một. Trong quá trình cập nhật, SageMaker AI trước tiên xác định dung lượng có sẵn trong các instance hiện có. Vì không có instance hiện có nào có không gian cho các tải công việc tạm thời bổ sung, SageMaker AI sẽ khởi chạy các instance ml.g5.2xlarge mới từng cái một để triển khai một bản sao của phiên bản inference component mới tới một instance GPU. Sau khoảng thời gian chờ được chỉ định và container của inference component mới vượt qua kiểm tra sức khỏe (healthy check), SageMaker AI sẽ loại bỏ một bản sao của phiên bản cũ (vì mỗi bản sao được lưu trữ trên một instance, instance này sẽ bị hủy tương ứng), hoàn thành việc cập nhật cho lô đầu tiên.

Quá trình này lặp lại cho bản sao thứ hai của inference component, cung cấp một quá trình chuyển đổi suôn sẻ với zero downtime. Bản chất dần dần của bản cập nhật giảm thiểu rủi ro và cho phép bạn duy trì tính sẵn sàng nhất quán trong suốt quá trình triển khai. Sơ đồ sau minh họa quá trình này.

Permissions guardrails implementation journey

Kịch bản 2: Cập nhật với rollback tự động

Trong một kịch bản khác, bạn có thể đang cập nhật inference component của mình từ Llama-3.1-8B-Instruct sang DeepSeek-R1-Distill-Llama-8B, nhưng phiên bản mô hình mới có các kỳ vọng API khác nhau. Trong trường hợp sử dụng này, bạn đã cấu hình một CloudWatch alarm để giám sát các lỗi 4xx, điều này sẽ cho thấy các vấn đề tương thích API.

Bạn có thể bắt đầu rolling updates với kích thước lô là một bản sao. SageMaker AI triển khai bản sao đầu tiên của phiên bản mới trên một instance GPU mới. Khi instance mới sẵn sàng phục vụ lưu lượng truy cập, SageMaker AI sẽ chuyển tiếp một tỷ lệ các yêu cầu gọi hàm (invocation requests) đến mô hình mới này. Tuy nhiên, trong ví dụ này, phiên bản mô hình mới, thiếu cấu hình biến môi trường “MESSAGES_API_ENABLED”, sẽ bắt đầu trả về lỗi 4xx khi nhận các yêu cầu ở định dạng Messages API.

Image showing automatic rollback process

CloudWatch alarm đã cấu hình phát hiện các lỗi này và chuyển sang trạng thái alarm. SageMaker AI tự động phát hiện trạng thái alarm này và bắt đầu quá trình rollback theo cấu hình rollback. Theo kích thước lô rollback đã chỉ định, SageMaker AI loại bỏ phiên bản mô hình mới có vấn đề và duy trì phiên bản gốc đang hoạt động, ngăn chặn sự gián đoạn dịch vụ trên diện rộng. Endpoint trở về trạng thái ban đầu với lưu lượng truy cập được xử lý bởi phiên bản mô hình gốc đang hoạt động bình thường.

Đoạn code sau đây cho thấy cách thiết lập CloudWatch alarm để giám sát các lỗi 4xx:

# Create alarm
cloudwatch.put_metric_alarm(
    AlarmName=f'SageMaker-{endpoint_name}-4xx-errors',
    ComparisonOperator='GreaterThanThreshold',
    EvaluationPeriods=1,
    MetricName='Invocation4XXErrors',
    Namespace='AWS/SageMaker',
    Period=300,
    Statistic='Sum',
    Threshold=5.0,
    ActionsEnabled=True,
    AlarmDescription='Alarm when greather than 5 4xx errors',
    Dimensions=[
        {
          'Name': 'InferenceComponentName',
          'Value': inference_component_name
        },
    ],
)

Sau đó, bạn có thể sử dụng CloudWatch alarm này trong yêu cầu cập nhật:

sagemaker_client.update_inference_component(
    InferenceComponentName=inference_component_name,
    ... ...
    DeploymentConfig={
        "RollingUpdatePolicy": {
            "MaximumBatchSize": {
                "Type": "COPY_COUNT",
                "Value": 1
            },
            "WaitIntervalInSeconds": 120,
            "RollbackMaximumBatchSize": {
                "Type": "COPY_COUNT",
                "Value": 1
            }
        },
        'AutoRollbackConfiguration': {
            "Alarms": [
                {"AlarmName": f'SageMaker-{endpoint_name}-4xx-errors'}
            ]
        }
    }
)

Kịch bản 3: Cập nhật với dung lượng đủ trong các instance hiện có

Nếu một endpoint hiện có có nhiều bộ tăng tốc GPU và không phải tất cả các bộ tăng tốc đều được sử dụng, bản cập nhật có thể sử dụng các bộ tăng tốc GPU hiện có mà không cần khởi chạy các instance mới vào endpoint. Hãy xem xét nếu bạn có một endpoint được cấu hình ban đầu với hai instance ml.g5.12xlarge có bốn bộ tăng tốc GPU trong mỗi instance. Endpoint lưu trữ hai inference component: IC-1 yêu cầu một bộ tăng tốc và IC-2 cũng yêu cầu một bộ tăng tốc. Trên một instance ml.g5.12xlarge, có bốn bản sao của IC-1 đã được tạo; trên instance kia, hai bản sao của IC-2 đã được tạo. Vẫn còn hai bộ tăng tốc GPU có sẵn trên instance thứ hai.

Khi bạn bắt đầu cập nhật cho IC-1 với kích thước lô là hai bản sao, SageMaker AI xác định rằng có đủ dung lượng trong các instance hiện có để lưu trữ các phiên bản mới trong khi vẫn duy trì các phiên bản cũ. Nó sẽ tạo hai bản sao của phiên bản IC-1 mới trên instance thứ hai. Khi các container đã hoạt động, SageMaker AI sẽ chuyển lưu lượng truy cập đến các IC-1 mới và sau đó bắt đầu định tuyến lưu lượng truy cập đến các inference component mới. SageMaker AI cũng sẽ loại bỏ hai bản sao IC-1 cũ khỏi instance. Bạn sẽ không bị tính phí cho đến khi các inference component mới bắt đầu nhận các yêu cầu gọi hàm và tạo ra phản hồi.

Bây giờ, hai khe GPU trống khác đã có sẵn. SageMaker AI sẽ cập nhật lô thứ hai và nó sẽ sử dụng các bộ tăng tốc GPU trống vừa có sẵn. Sau khi quá trình hoàn tất, endpoint có bốn IC-1 với phiên bản mới và hai bản sao của IC-2 không thay đổi.

Image showing update with sufficient capacity in existing instances

Kịch bản 4: Cập nhật yêu cầu dung lượng instance bổ sung

Hãy xem xét nếu bạn có một endpoint được cấu hình ban đầu với một instance ml.g5.12xlarge (tổng cộng 4 GPU) và cấu hình managed instance scaling (MIS) với số lượng instance tối đa được đặt là hai. Endpoint lưu trữ hai inference component: IC-1 yêu cầu 1 GPU với hai bản sao (Llama 8B), và IC-2 (mô hình DeepSeek Distilled Llama 14B model) cũng yêu cầu 1 GPU với hai bản sao—sử dụng hết 4 GPU có sẵn.

Khi bạn bắt đầu cập nhật cho IC-1 với kích thước lô là hai bản sao, SageMaker AI xác định rằng không đủ dung lượng trong các instance hiện có để lưu trữ các phiên bản mới trong khi vẫn duy trì các phiên bản cũ. Thay vì làm cho bản cập nhật thất bại, vì bạn đã cấu hình MIS, SageMaker AI sẽ tự động cấp phát một instance g5.12.xlarge thứ hai để lưu trữ các inference component mới.

Trong quá trình cập nhật, SageMaker AI triển khai hai bản sao của phiên bản IC-1 mới lên instance vừa được cấp phát, như được hiển thị trong sơ đồ sau. Sau khi các inference component mới đã hoạt động, SageMaker AI bắt đầu loại bỏ các bản sao IC-1 cũ khỏi các instance ban đầu. Đến cuối quá trình cập nhật, instance đầu tiên sẽ lưu trữ IC-2 sử dụng 2 GPU, và instance thứ hai vừa được cấp phát sẽ lưu trữ IC-1 đã cập nhật với hai bản sao sử dụng 2 GPU. Sẽ có không gian mới có sẵn trong hai instance, và bạn có thể triển khai thêm các bản sao inference component hoặc các mô hình mới vào cùng một endpoint bằng cách sử dụng các tài nguyên GPU có sẵn. Nếu bạn thiết lập tự động mở rộng quy mô instance được quản lý (managed instance auto scaling) và đặt tự động mở rộng quy mô inference component về 0, bạn có thể giảm quy mô các bản sao inference component về 0, điều này sẽ dẫn đến việc instance tương ứng được giảm quy mô. Khi inference component được mở rộng quy mô, SageMaker AI sẽ khởi chạy các inference component trong instance hiện có với các bộ tăng tốc GPU có sẵn, như đã đề cập trong kịch bản 3.

Image showing update requiring additional instance capacity

Kịch bản 5: Cập nhật gặp phải dung lượng không đủ

Trong các kịch bản không có đủ dung lượng GPU, SageMaker AI cung cấp phản hồi rõ ràng về các hạn chế về dung lượng. Hãy xem xét nếu bạn có một endpoint đang chạy trên 30 instance ml.g6e.16xlarge, mỗi instance đã được sử dụng hết với các inference component. Bạn muốn cập nhật một inference component hiện có bằng cách sử dụng triển khai Rolling với kích thước lô là 4, nhưng sau khi bốn lô đầu tiên được cập nhật, không còn đủ dung lượng GPU cho phần cập nhật còn lại. Trong trường hợp này, SageMaker AI sẽ tự động rollback về thiết lập trước đó và dừng quá trình cập nhật.

Có thể có hai trường hợp cho trạng thái cuối cùng của rollback này. Trong trường hợp đầu tiên, rollback thành công vì có dung lượng mới có sẵn để khởi chạy các instance cho phiên bản mô hình cũ. Tuy nhiên, có thể có một trường hợp khác là vấn đề dung lượng vẫn tồn tại trong quá trình rollback, và endpoint sẽ hiển thị là UPDATE_ROLLBACK_FAILED. Các instance hiện có vẫn có thể phục vụ lưu lượng truy cập, nhưng để đưa endpoint ra khỏi trạng thái lỗi, bạn cần liên hệ với đội ngũ hỗ trợ AWS của mình.

Các cân nhắc bổ sung

Như đã đề cập trước đó, khi sử dụng triển khai blue/green để cập nhật inference component trên một endpoint, bạn cần cấp phát tài nguyên cho cả môi trường hiện tại (blue) và môi trường mới (green) cùng một lúc. Khi bạn sử dụng rolling updates cho inference component trên endpoint, bạn có thể sử dụng phương trình sau để tính toán số lượng hạn mức dịch vụ tài khoản (account service quotas) cho loại instance cần thiết. Instance GPU cần thiết cho endpoint có X số lượng bộ tăng tốc GPU, và mỗi bản sao inference component yêu cầu Y số lượng bộ tăng tốc GPU. Kích thước lô tối đa được đặt là Z và endpoint hiện tại có N instance. Do đó, hạn mức dịch vụ cấp tài khoản cần thiết cho loại instance này đối với endpoint phải lớn hơn kết quả của phương trình:

ROUNDUP(Z x Y / X) + N

Ví dụ, giả sử endpoint hiện tại có 8 (N) instance ml.g5.12xlarge, mỗi instance có 4 bộ tăng tốc GPU. Bạn đặt kích thước lô tối đa là 2 (Z) bản sao, và mỗi bản sao cần 1 (Y) bộ tăng tốc GPU. Giá trị hạn mức dịch vụ AWS tối thiểu cho ml.g5.12xlarge là ROUNDUP(2 x 1 / 4) + 8 = 9. Trong một kịch bản khác, khi mỗi bản sao của inference component yêu cầu 4 bộ tăng tốc GPU, thì hạn mức dịch vụ cấp tài khoản cần thiết cho cùng một instance phải là ROUNDUP(2 x 4 / 4) + 8 = 10.

Kết luận

Rolling updates cho inference component đại diện cho một cải tiến đáng kể đối với khả năng triển khai của SageMaker AI. Tính năng này trực tiếp giải quyết các thách thức trong việc cập nhật triển khai mô hình trong môi trường production, đặc biệt đối với các tải công việc nặng về GPU, đồng thời loại bỏ việc phỏng đoán dung lượng và giảm thiểu rủi ro rollback. Bằng cách kết hợp các bản cập nhật theo lô với các biện pháp bảo vệ tự động, SageMaker AI đảm bảo việc triển khai linh hoạt và bền bỉ.

Các lợi ích chính bao gồm:

  • Giảm chi phí tài nguyên trong quá trình triển khai, loại bỏ nhu cầu cấp phát các fleet trùng lặp
  • Cải thiện các rào chắn triển khai với các bản cập nhật dần dần và khả năng rollback tự động
  • Duy trì tính sẵn sàng liên tục trong quá trình cập nhật với kích thước lô có thể cấu hình
  • Triển khai đơn giản các mô hình cần nhiều tài nguyên và yêu cầu nhiều bộ tăng tốc

Cho dù bạn đang triển khai các mô hình nhỏ gọn hay các mô hình đa bộ tăng tốc lớn hơn, Rolling updates cung cấp một con đường hiệu quả hơn về chi phí, an toàn hơn để giữ cho các mô hình ML của bạn luôn được cập nhật trong môi trường production.

Chúng tôi khuyến khích bạn dùng thử khả năng mới này với các endpoint SageMaker AI của mình và khám phá cách nó có thể nâng cao hoạt động ML của bạn. Để biết thêm thông tin, hãy xem tài liệu SageMaker AI hoặc liên hệ với đội ngũ tài khoản AWS của bạn.

Về tác giả

Melanie Li, PhD, là Kiến trúc sư Giải pháp Chuyên gia Generative AI Cấp cao tại AWS có trụ sở tại Sydney, Úc, nơi cô tập trung vào việc hợp tác với khách hàng để xây dựng các giải pháp tận dụng các công cụ AI và machine learning tiên tiến. Cô đã tích cực tham gia vào nhiều sáng kiến Generative AI trên khắp APJ, khai thác sức mạnh của Large Language Models (LLM). Trước khi gia nhập AWS, Tiến sĩ Li đã giữ các vai trò khoa học dữ liệu trong ngành tài chính và bán lẻ.

Andrew Smith là Kỹ sư Hỗ trợ Cloud trong đội SageMaker, Vision & Other tại AWS, có trụ sở tại Sydney, Úc. Anh hỗ trợ khách hàng sử dụng nhiều dịch vụ AI/ML trên AWS với chuyên môn làm việc với Amazon SageMaker. Ngoài công việc, anh thích dành thời gian cho bạn bè và gia đình cũng như tìm hiểu về các công nghệ khác nhau.

Dustin Liu là kiến trúc sư giải pháp tại AWS, tập trung hỗ trợ các công ty khởi nghiệp dịch vụ tài chính và bảo hiểm (FSI) và các công ty SaaS. Anh có nền tảng đa dạng bao gồm kỹ thuật dữ liệu, khoa học dữ liệu và machine learning, và anh đam mê tận dụng AI/ML để thúc đẩy đổi mới và chuyển đổi kinh doanh.

Vivek Gangasani là Kiến trúc sư Giải pháp Chuyên gia GenAI Cấp cao tại AWS. Anh giúp các công ty generative AI mới nổi xây dựng các giải pháp sáng tạo bằng cách sử dụng các dịch vụ AWS và tính toán tăng tốc. Hiện tại, anh tập trung phát triển các chiến lược để tinh chỉnh và tối ưu hóa hiệu suất suy luận của các large language model. Trong thời gian rảnh, Vivek thích đi bộ đường dài, xem phim và thử các món ăn khác nhau.

Shikher Mishra là Kỹ sư Phát triển Phần mềm thuộc đội SageMaker Inference với hơn 9 năm kinh nghiệm trong ngành. Anh đam mê xây dựng các giải pháp có khả năng mở rộng và hiệu quả nhằm trao quyền cho khách hàng triển khai và quản lý các ứng dụng machine learning một cách liền mạch. Trong thời gian rảnh, Shikher thích các môn thể thao ngoài trời, đi bộ đường dài và du lịch.

June Won là giám đốc sản phẩm của Amazon SageMaker JumpStart. Anh tập trung vào việc làm cho các foundation model dễ dàng được khám phá và sử dụng để giúp khách hàng xây dựng các ứng dụng generative AI. Kinh nghiệm của anh tại Amazon cũng bao gồm các ứng dụng mua sắm di động và giao hàng chặng cuối.

←
→

Leave a comment