Cải thiện hiệu suất của các mô hình Falcon với Amazon SageMaker | Dịch vụ web của Amazon

Khung và cấu hình tối ưu để lưu trữ các mô hình ngôn ngữ lớn (LLM) cho các ứng dụng AI tạo văn bản là gì? Mặc dù có rất nhiều tùy chọn để phục vụ LLM, đây vẫn là một câu hỏi khó trả lời do kích thước của mô hình, kiến ​​trúc mô hình khác nhau, yêu cầu về hiệu suất của ứng dụng, v.v. Các Amazon SageMaker Vùng chứa suy luận mô hình lớn (LMI) giúp việc phục vụ LLM trở nên đơn giản bằng cách tập hợp một loạt các khung và kỹ thuật khác nhau nhằm tối ưu hóa việc triển khai LLM. Bộ chứa LMI có ngăn xếp phục vụ mạnh mẽ được gọi là phục vụ DJL đó là điều bất khả tri đối với LLM cơ bản. Nó cung cấp các tham số cấu hình cấp hệ thống có thể được điều chỉnh để đạt được hiệu suất tốt nhất của cơ sở hạ tầng lưu trữ cho một LLM nhất định. Nó cũng hỗ trợ các tối ưu hóa gần đây như phân mẻ liên tục, còn được gọi là phân mẻ lặp hoặc phân mẻ cán, mang lại những cải tiến đáng kể về thông lượng.

Trong một sớm hơn gửi, chúng tôi đã chỉ ra cách bạn có thể sử dụng bộ chứa LMI để triển khai dòng mô hình Falcon trên SageMaker. Trong bài đăng này, chúng tôi trình bày cách cải thiện thông lượng và độ trễ khi phục vụ Falcon-40B bằng các kỹ thuật như phân mẻ liên tục. Chúng tôi cũng cung cấp sự hiểu biết trực quan về các tham số cấu hình do bộ chứa SageMaker LMI cung cấp để có thể giúp bạn tìm ra cấu hình tốt nhất cho ứng dụng trong thế giới thực của mình.

Nguyên tắc cơ bản của suy luận tạo văn bản cho LLM

Trước tiên, chúng ta hãy xem xét một số nguyên tắc cơ bản về cách thực hiện suy luận cho LLM để tạo văn bản.

Chuyển tiếp, kích hoạt và bộ đệm KV

Đưa ra một chuỗi đầu vào của các mã thông báo, chúng được chạy theo một forward pass trên tất cả các lớp của LLM (như Falcon) để tạo mã thông báo tiếp theo. MỘT forward pass đề cập đến quá trình dữ liệu đầu vào được truyền qua mạng lưới thần kinh để tạo ra đầu ra. Trong trường hợp tạo văn bản, quá trình chuyển tiếp bao gồm việc đưa hạt giống hoặc ngữ cảnh ban đầu vào mô hình ngôn ngữ và tạo ký tự hoặc mã thông báo tiếp theo trong chuỗi. Để tạo ra một chuỗi văn bản, quy trình này thường được thực hiện lặp đi lặp lại, nghĩa là nó được lặp lại cho từng bước hoặc vị trí trong chuỗi đầu ra. Ở mỗi lần lặp lại, mô hình sẽ tạo ký tự hoặc mã thông báo tiếp theo, ký tự này sẽ trở thành một phần của văn bản được tạo và quá trình này tiếp tục cho đến khi tạo được độ dài văn bản mong muốn.

Việc tạo văn bản bằng các mô hình ngôn ngữ như Falcon hoặc GPT là autoregressive. Điều này có nghĩa là mô hình tạo ra một mã thông báo tại một thời điểm trong khi điều chỉnh các mã thông báo được tạo trước đó. Nói cách khác, ở mỗi lần lặp, mô hình lấy văn bản được tạo trước đó làm đầu vào và dự đoán mã thông báo tiếp theo dựa trên ngữ cảnh đó. Như đã đề cập ở vLLM: Cung cấp LLM dễ dàng, nhanh chóng và giá rẻ với PagedAttention, trong quá trình giải mã tự hồi quy này, tất cả các mã thông báo đầu vào cho LLM đều tạo ra các tensor khóa chú ý và giá trị của chúng, đồng thời các tensor này được lưu trong bộ nhớ GPU để tạo ra các mã thông báo tiếp theo. Các tensor khóa và giá trị được lưu trong bộ nhớ đệm này thường được gọi là KV cache.

Giai đoạn điền trước và giải mã

Trong quy trình giải mã tự hồi quy, giống như quy trình được sử dụng trong tạo văn bản với các mô hình ngôn ngữ như Falcon, thường có hai giai đoạn chính: prefill giai đoạn và decode giai đoạn. Những giai đoạn này rất quan trọng để tạo ra văn bản mạch lạc và phù hợp với ngữ cảnh.

Giai đoạn điền trước bao gồm:

• Bối cảnh ban đầu – Giai đoạn điền trước bắt đầu bằng ngữ cảnh ban đầu hoặc văn bản gốc do người dùng cung cấp. Ngữ cảnh ban đầu này có thể là một câu, một cụm từ hoặc thậm chí chỉ là một từ. Nó đặt điểm bắt đầu cho việc tạo văn bản và cung cấp bối cảnh cho những gì tiếp theo.
• Điều hòa mô hình – Ngữ cảnh được cung cấp được sử dụng để điều kiện hóa mô hình ngôn ngữ. Mô hình lấy bối cảnh này làm đầu vào và tạo mã thông báo (từ hoặc ký tự) tiếp theo trong chuỗi dựa trên sự hiểu biết của nó về ngữ cảnh.
• Tạo mã thông báo – Mô hình tạo mỗi lần một mã thông báo, dự đoán điều gì sẽ xảy ra tiếp theo trong văn bản. Mã thông báo này được thêm vào ngữ cảnh, mở rộng nó một cách hiệu quả.
• quá trình lặp đi lặp lại – Quá trình tạo mã thông báo được lặp đi lặp lại. Ở mỗi bước, mô hình sẽ tạo mã thông báo trong khi xem xét bối cảnh được cập nhật, hiện bao gồm các mã thông báo được tạo ở các bước trước đó.

Giai đoạn nạp trước tiếp tục cho đến khi đáp ứng được điều kiện dừng xác định trước. Điều kiện này có thể là độ dài tối đa cho văn bản được tạo, một mã thông báo cụ thể báo hiệu phần cuối của văn bản hoặc bất kỳ tiêu chí nào khác do người dùng hoặc ứng dụng đặt ra.

Giai đoạn giải mã bao gồm:

• Hoàn thành – Sau giai đoạn điền trước, bạn có một văn bản được tạo một phần có thể chưa hoàn chỉnh hoặc bị cắt ở một số điểm. Giai đoạn giải mã có nhiệm vụ hoàn thiện văn bản sao cho mạch lạc và đúng ngữ pháp.
• Tiếp tục từ mã thông báo cuối cùng – Trong giai đoạn giải mã, mô hình bắt đầu từ mã thông báo cuối cùng được tạo trong giai đoạn điền trước. Nó sử dụng mã thông báo này làm bối cảnh ban đầu và tạo mã thông báo tiếp theo để tiếp tục văn bản.
• Hoàn thành lặp lại – Giống như trong giai đoạn điền trước, quá trình tạo mã thông báo lại được lặp lại. Mô hình tạo ra một mã thông báo tại một thời điểm, dựa trên các mã thông báo trước đó trong chuỗi.
• Tình trạng dừng – Giai đoạn giải mã cũng có điều kiện dừng, có thể giống như trong giai đoạn điền trước, chẳng hạn như đạt độ dài tối đa hoặc gặp phải mã thông báo cuối văn bản. Khi điều kiện này được đáp ứng, quá trình tạo sẽ dừng lại.

Sự kết hợp giữa các giai đoạn điền trước và giải mã cho phép các mô hình tự hồi quy tạo ra văn bản dựa trên ngữ cảnh ban đầu và tạo ra các chuỗi văn bản mạch lạc, phù hợp với ngữ cảnh và nhất quán theo ngữ cảnh.

Tham khảo Hệ thống phục vụ phân tán cho các mô hình sáng tạo dựa trên máy biến áp để được giải thích chi tiết về quy trình.

Tối ưu hóa thông lượng bằng cách sử dụng tính năng tạo khối động

Cho đến nay, chúng ta chỉ nói về một đầu vào duy nhất. Trong thực tế, chúng tôi dự kiến ​​sẽ xử lý được nhiều yêu cầu đến ngẫu nhiên từ ứng dụng khách để suy luận đồng thời hoặc theo kiểu so le. Theo cách truyền thống, việc tạo khối cơ bản có thể được sử dụng để tăng thông lượng và mức sử dụng tài nguyên tính toán của GPU. Batching là sự kết hợp hiệu quả các biểu diễn số của nhiều yêu cầu trong một batch và thực hiện các lần chạy song song của các bước chuyển tiếp tự động hồi quy. Việc phân nhóm thông minh này được thực hiện ở phía phục vụ. Máy chủ DJLServing của SageMaker LMI có thể được định cấu hình để gộp nhiều yêu cầu lại với nhau nhằm xử lý chúng song song bằng cách đặt các tham số sau trong phục vụ.properties:

• max_batch_delay = 100 – Độ trễ tối đa để tổng hợp lô tính bằng mili giây. Giá trị mặc định là 100 mili giây.
• batch_size = 32 – Kích thước lô động. Mặc định là 1.

Về cơ bản, điều này cho thấy rằng DJLServing sẽ xếp hàng các yêu cầu trong 100 mili giây mỗi lần hoặc nếu số lượng yêu cầu được xếp hàng lên đến batch_size được chỉ định, thì lô đó sẽ được lên lịch để chạy đến phần phụ trợ để suy luận. Điều này được gọi là dynamic batching. Tính năng này linh hoạt vì kích thước lô có thể thay đổi giữa các lô tùy thuộc vào số lượng yêu cầu được thêm vào trong khoảng thời gian đó. Tuy nhiên, vì các yêu cầu có thể có các đặc điểm khác nhau (ví dụ: một số yêu cầu có thể có dạng 20 mã thông báo đầu vào và 500 mã thông báo đầu ra, trong khi các yêu cầu khác có thể bị đảo ngược, với 500 mã thông báo đầu vào nhưng chỉ có 20 mã thông báo đầu ra), một số yêu cầu có thể hoàn thành xử lý nhanh hơn những người khác trong cùng một đợt. Điều này có thể dẫn đến việc sử dụng GPU không đúng mức trong khi chờ tất cả các yêu cầu đang thực hiện trong lô hoàn tất giai đoạn giải mã, ngay cả khi có các yêu cầu bổ sung đang chờ xử lý trong hàng đợi. Sơ đồ sau đây minh họa quá trình này.

Tối ưu hóa thông lượng bằng cách sử dụng phân mẻ liên tục

Với continuous batching, còn được biết là iterative or rolling theo đợt, chúng tôi tận dụng sự khác biệt giữa giai đoạn điền trước và giải mã. Để kích hoạt tính năng tạo khối liên tục, DJServing cung cấp các cấu hình bổ sung sau theo phân phối.properties:

• động cơ=MPI – Chúng tôi khuyến khích bạn sử dụng công cụ MPI để tạo khối liên tục.
• tùy chọn.rolling_batch=auto hoặc lmi-dist – Chúng tôi khuyên bạn nên sử dụng auto vì nó sẽ tự động chọn thuật toán lô cuộn thích hợp nhất cùng với các tối ưu hóa khác trong tương lai.
• tùy chọn.max_rolling_batch_size=32 – Điều này giới hạn số lượng yêu cầu đồng thời. Mặc định là 32.

Với tính năng phân nhóm liên tục, ngăn xếp phân phối (DJLServing) không đợi tất cả các yêu cầu đang thực hiện trong một lô hoàn thành giai đoạn giải mã của nó. Đúng hơn, tại các điểm ngắt logic (ở cuối một lần lặp trong giai đoạn giải mã), nó sẽ lấy thêm các yêu cầu đang chờ trong hàng đợi trong khi lô hiện tại vẫn đang xử lý (do đó có tên mẻ cán). Nó thực hiện việc kiểm tra các yêu cầu đang chờ xử lý ở cuối mỗi lần lặp của giai đoạn giải mã. Hãy nhớ rằng, đối với mỗi yêu cầu, chúng ta cần chạy giai đoạn điền trước, sau đó là giai đoạn giải mã tuần tự. Bởi vì chúng tôi có thể xử lý song song tất cả các mã thông báo từ lời nhắc ban đầu của một yêu cầu cho giai đoạn điền trước của nó, nên bất cứ khi nào một yêu cầu mới được đưa vào, chúng tôi sẽ tạm dừng giai đoạn giải mã của các yêu cầu đang thực hiện trong lô—chúng tôi tạm thời lưu bộ nhớ đệm KV của yêu cầu đó và kích hoạt trong bộ nhớ cũng như chạy giai đoạn điền trước các yêu cầu mới.

Kích thước của bộ đệm này có thể được cấu hình bằng tùy chọn sau:

Khi quá trình điền trước hoàn tất, chúng tôi kết hợp các yêu cầu mới và các yêu cầu cũ bị tạm dừng trong một lô mới, có thể tiến hành song song giai đoạn giải mã. Lưu ý rằng các yêu cầu cũ bị tạm dừng có thể tiếp tục giai đoạn giải mã nơi chúng đã dừng lại và các yêu cầu mới sẽ bắt đầu từ mã thông báo mới đầu tiên.

Bạn có thể đã nhận ra rằng việc phân nhóm liên tục là một cách tiếp cận gần như tương tự mà chúng ta thực hiện song song các nhiệm vụ trong cuộc sống hàng ngày một cách tự nhiên. Chúng tôi có tin nhắn, email, thông báo qua điện thoại (có thể là các yêu cầu mới) đến vào những thời điểm ngẫu nhiên (tương tự như nhiều yêu cầu đến theo kiểu so le ngẫu nhiên đối với GPU). Tất cả điều này xảy ra khi chúng ta hoàn thành các nhiệm vụ đang diễn ra—soạn email, mã hóa, tham gia các cuộc họp (tương tự như các tác vụ hiện đang xử lý trong GPU). Vào những thời điểm nghỉ hợp lý, chúng tôi tạm dừng các nhiệm vụ trên chuyến bay và kiểm tra thông báo để quyết định xem liệu chúng tôi có cần thực hiện một số hành động nào đó hay không và nếu có, chúng tôi sẽ thêm hành động đó vào các nhiệm vụ trên chuyến bay của mình (lô luân phiên ngoài đời thực) hoặc đưa nó vào danh sách việc cần làm (hàng đợi).

Tổng hợp tất cả lại với nhau: Cách suy nghĩ về việc sử dụng bộ nhớ của GPU

Bạn nên tải thử mô hình của mình để xem cấu hình nào tiết kiệm chi phí nhất cho trường hợp sử dụng của doanh nghiệp bạn. Để hiểu rõ hơn, hãy hình dung dung lượng bộ nhớ của GPU khi mô hình được tải và khi các yêu cầu liên tiếp được xử lý theo đợt luân phiên. Đối với bài đăng này, giả sử chúng ta đang tải mẫu Falcon-40B lên một trong các phiên bản loại phiên bản G5 được cài đặt với GPU NVIDIA A10G, mỗi GPU có 24 GB bộ nhớ. Lưu ý rằng cách hiểu tương tự cũng có thể áp dụng cho các loại phiên bản p3, p4 và p5 đi kèm với dòng GPU V100, A100 và H100.

Sau đây là tổng quan về cách lấy giá trị gần đúng của tổng bộ nhớ cần thiết để phục vụ Falcon-40B:

• Kích thước mô hình = Số lượng tham số mô hình (40 tỷ đối với Falcon-40B) x 4 byte mỗi tham số (đối với FP32) = 160 GB
• Tổng bộ nhớ gần đúng cần thiết để tải Falcon-40B cho suy luận = Kích thước mô hình (=160 GB) + KV Cache (Attention Cache) (=*20 GB) + Chi phí bộ nhớ bổ sung theo ML Framework (khoảng 2 GB)

Đối với Falcon-40B, nếu chúng ta nén mô hình bằng cách lượng tử hóa mô hình thành kiểu dữ liệu bfloat16 (2 byte), kích thước mô hình sẽ trở thành khoảng 80 GB. Như bạn có thể thấy, bộ nhớ này vẫn lớn hơn bộ nhớ được hỗ trợ bởi một thiết bị tăng tốc, vì vậy chúng ta cần áp dụng kỹ thuật phân vùng mô hình (sharding) với một kỹ thuật đặc biệt. tính song song tensor (TP) tiếp cận và phân chia mô hình trên nhiều thiết bị tăng tốc. Giả sử rằng chúng tôi đã chọn g5.24xlarge, có 4 thiết bị GPU A10G. Nếu chúng ta định cấu hình DJLServing (phục vụ.properties) như sau, chúng ta có thể mong đợi rằng trọng lượng mô hình 80 GB sẽ được chia đều cho cả 4 GPU:

Với tensor_parallel_degree được đặt thành 4, khoảng 20 GB trong bộ nhớ GPU 24 GB (khoảng 84%) đã được sử dụng ngay cả trước khi một yêu cầu được xử lý. 16% GPU còn lại sẽ được sử dụng cho bộ nhớ đệm KV cho các yêu cầu gửi đến. Có thể đối với kịch bản kinh doanh của bạn cũng như các yêu cầu về độ trễ và thông lượng của nó, 2–3 GB bộ nhớ còn lại là quá đủ. Nếu không, bạn có thể tăng kích thước phiên bản lên g5.48xlarge, phiên bản này có 8 GPU và sử dụng tensor_parallel_degree được đặt thành 8. Trong trường hợp đó, chỉ khoảng 10 GB trong bộ nhớ 24 GB khả dụng của mỗi GPU được sử dụng cho trọng lượng mô hình và chúng tôi có khoảng 60% GPU còn lại để kích hoạt và bộ đệm KV. Bằng trực quan, chúng ta có thể thấy rằng cấu hình này có thể cho phép chúng ta có thông lượng cao hơn. Ngoài ra, vì hiện tại chúng tôi có bộ đệm lớn hơn nên chúng tôi có thể tăng max_rolling_batch_prefill_tokens và max_rolling_batch_size các thông số để tối ưu hóa hơn nữa thông lượng. Cùng với nhau, hai tham số này sẽ kiểm soát việc phân bổ trước của các lần điền trước kích hoạt và bộ nhớ đệm KV cho mô hình. Số lượng lớn hơn cho hai tham số này sẽ liên quan đến thông lượng lớn hơn, giả sử bạn có đủ bộ đệm cho bộ đệm KV trong bộ nhớ GPU.

Phân nhóm liên tục với PagedAttention

PagedAttention là một thuật toán tối ưu hóa mới được phát triển bởi UC Berkeley nhằm cải thiện quy trình tạo khối liên tục bằng cách cho phép bộ đệm chú ý (bộ đệm KV) không liền kề bằng cách phân bổ bộ nhớ trong các trang hoặc khối có kích thước cố định. Điều này được lấy cảm hứng từ các khái niệm bộ nhớ ảo và phân trang được sử dụng bởi các hệ điều hành.

Theo vLLM giấy, bộ đệm chú ý của từng chuỗi mã thông báo được phân chia thành các khối và ánh xạ tới các khối vật lý thông qua bảng khối. Trong quá trình tính toán mức độ chú ý, hạt nhân PagedAttention có thể sử dụng bảng khối để tìm nạp các khối từ bộ nhớ vật lý một cách hiệu quả. Điều này giúp giảm đáng kể sự lãng phí bộ nhớ và cho phép kích thước lô lớn hơn, tăng mức sử dụng GPU và thông lượng cao hơn.

So sánh hiệu suất

Để đảm bảo kiểm tra tải hiệu quả cho cấu hình triển khai của bạn, bạn nên bắt đầu bằng cách xem xét kịch bản kinh doanh và xác định rõ ràng các đặc điểm của đầu vào và đầu ra cho ứng dụng dựa trên LLM. Ví dụ: nếu bạn đang làm việc trong trường hợp sử dụng tóm tắt trung tâm cuộc gọi, đầu vào có thể bao gồm văn bản lớn hơn, chẳng hạn như bản ghi trò chuyện 500 mã thông báo giữa nhân viên dịch vụ khách hàng và khách hàng, nhưng đầu ra có thể tương đối nhỏ hơn, khoảng 100 mã thông báo, đại diện cho một bản tóm tắt của bảng điểm. Mặt khác, nếu bạn đang làm việc trên một kịch bản tạo mã, đầu vào có thể chỉ có 15 mã thông báo, chẳng hạn như “viết một triển khai hiệu quả bằng Python để mô tả tất cả tài nguyên EC2, bao gồm cả phân trang”, nhưng đầu ra có thể nhiều lớn hơn, đạt 500 token. Điều quan trọng nữa là phải cân nhắc xem việc đạt được độ trễ thấp hơn hay tối đa hóa thông lượng có phải là ưu tiên hàng đầu cho kịch bản cụ thể của bạn hay không.

Sau khi hiểu biết toàn diện về tình huống kinh doanh, bạn có thể phân tích và xác định cấu hình tối ưu cho môi trường lưu trữ của mình. Trong bối cảnh này, môi trường lưu trữ bao gồm nhiều thành phần chính khác nhau, bao gồm loại phiên bản và các tham số cấu hình khác như tensor_parallel_degree, max_rolling_batch_size, max_rolling_batch_prefill_tokens, và hơn thế nữa. Mục tiêu của chúng tôi là xác định cách thiết lập hiệu quả nhất để hỗ trợ các yêu cầu về thời gian phản hồi, thông lượng và chất lượng đầu ra của mô hình.

Trong phân tích của mình, chúng tôi đã đánh giá hiệu suất để minh họa lợi ích của việc tạo khối liên tục so với việc tạo khối động truyền thống. Chúng tôi đã sử dụng các cấu hình chi tiết trong bảng sau trong Serve.properties để tạo khối động và tạo khối lặp lại bằng cách sử dụng bộ chứa LMI trên SageMaker.

Lô động	Batch liên tục	Tạo hàng loạt liên tục với PagedAttention
động cơ=Python option.model_id=tiiuae/falcon-40b tùy chọn.tensor_parallel_degree=8 tùy chọn.dtype=fp16 batch_size=4 max_batch_delay=100 option.trust_remote_code = true	động cơ = MPI tùy chọn.model_id = {{s3_url}} option.trust_remote_code = true tùy chọn.tensor_parallel_degree = 8 tùy chọn.max_rolling_batch_size = 32 option.rolling_batch = tự động tùy chọn.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = Sai	động cơ = MPI tùy chọn.model_id = {{s3_url}} option.trust_remote_code = true tùy chọn.tensor_parallel_degree = 8 tùy chọn.max_rolling_batch_size = 32 option.rolling_batch = tự động tùy chọn.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = Đúng

Hai cấu hình đã được đo điểm chuẩn cho Falcon-40B với kiểu dữ liệu FP16 được triển khai trên ml.g5.48xlarge trong một số trường hợp khác nhau đại diện cho các ứng dụng trong thế giới thực:

• Một số lượng nhỏ mã thông báo đầu vào với số lượng lớn mã thông báo được tạo – Trong trường hợp này, số lượng mã thông báo đầu vào được cố định ở mức 32 và 128 mã thông báo mới được tạo

Chiến lược hàng loạt	Thông lượng (mã thông báo/giây)	Độ trễ p90 (giây)
Lô động	5.53	58.34
Batch liên tục	56.04	4.74
Tạo hàng loạt liên tục với PagedAttention	59.18	4.76

• Đầu vào lớn với số lượng mã thông báo nhỏ được tạo – Ở đây, chúng tôi sửa số lượng mã thông báo đầu vào là 256 và nhắc LLM tổng hợp đầu vào thành 32 mã thông báo

Chiến lược hàng loạt	Thông lượng (mã thông báo/giây)	Độ trễ p90 (giây)
Lô động	19.96	59.31
Batch liên tục	46.69	3.88
Tạo hàng loạt liên tục với PagedAttention	44.75	2.67

Chúng ta có thể thấy rằng việc tạo khối liên tục với PagedAttention mang lại sự cải thiện thông lượng lớn hơn 10 lần trong kịch bản 1 và 2.3 lần trong kịch bản 2 so với việc sử dụng tính năng tạo khối động trên SageMaker trong khi sử dụng bộ chứa LMI.

Kết luận

Trong bài đăng này, chúng tôi đã xem xét cách LLM sử dụng bộ nhớ và giải thích cách phân nhóm liên tục cải thiện thông lượng bằng cách sử dụng bộ chứa LMI trên SageMaker. Chúng tôi đã chứng minh lợi ích của việc phân mẻ liên tục cho Falcon-40B bằng cách sử dụng thùng chứa LMI trên SageMaker bằng cách hiển thị kết quả điểm chuẩn. Bạn có thể tìm thấy mã trên Repo GitHub.

---

Về các tác giả

Abhi Shivaditya là Kiến trúc sư giải pháp cấp cao tại AWS, làm việc với các tổ chức doanh nghiệp toàn cầu chiến lược để tạo điều kiện thuận lợi cho việc áp dụng các dịch vụ AWS trong các lĩnh vực như Trí tuệ nhân tạo, điện toán phân tán, kết nối mạng và lưu trữ. Chuyên môn của anh ấy là Học sâu trong các lĩnh vực Xử lý ngôn ngữ tự nhiên (NLP) và Thị giác máy tính. Abhi hỗ trợ khách hàng triển khai các mô hình máy học hiệu năng cao một cách hiệu quả trong hệ sinh thái AWS.

Dhawal Patel là một Kiến trúc sư chính về Học máy tại AWS. Ông đã làm việc với các tổ chức khác nhau, từ các doanh nghiệp lớn đến các công ty khởi nghiệp quy mô trung bình về các vấn đề liên quan đến máy tính phân tán và Trí tuệ nhân tạo. Ông tập trung vào Học sâu bao gồm các lĩnh vực NLP và Thị giác máy tính. Anh ấy giúp khách hàng đạt được khả năng suy luận mô hình hiệu suất cao trên SageMaker.

Pinak Panigrahi làm việc với khách hàng để xây dựng các giải pháp dựa trên máy học nhằm giải quyết các vấn đề kinh doanh chiến lược trên AWS. Khi không bận tâm đến việc học máy, người ta có thể thấy anh ấy đang đi bộ đường dài, đọc sách hoặc xem thể thao.

Abhi Sodhani giữ vị trí Kiến trúc sư giải pháp AI/ML cấp cao tại AWS, nơi ông chuyên cung cấp kiến ​​thức chuyên môn kỹ thuật và hướng dẫn về các giải pháp Generative AI và ML cho khách hàng. Trọng tâm chính của anh là hỗ trợ các Doanh nghiệp bản địa kỹ thuật số nhận ra toàn bộ tiềm năng của công nghệ Generative AI và ML, cho phép họ đạt được mục tiêu kinh doanh của mình một cách hiệu quả. Ngoài nỗ lực nghề nghiệp, Abhi còn thể hiện niềm đam mê mãnh liệt với các hoạt động trí tuệ như đọc sách, cũng như tham gia vào các hoạt động nâng cao sức khỏe thể chất và tinh thần, chẳng hạn như yoga, thiền.

Thanh Lan là Kỹ sư phát triển phần mềm trong AWS. Anh ấy đã làm việc trên một số sản phẩm đầy thử thách ở Amazon, bao gồm các giải pháp suy luận ML hiệu suất cao và hệ thống ghi nhật ký hiệu suất cao. Nhóm của Qing đã khởi chạy thành công mô hình Tỷ tham số đầu tiên trong Quảng cáo Amazon với độ trễ yêu cầu rất thấp. Qing có kiến ​​thức chuyên sâu về tối ưu hóa cơ sở hạ tầng và tăng tốc Deep Learning.

• Phân phối nội dung và PR được hỗ trợ bởi SEO. Được khuếch đại ngay hôm nay.
• PlatoData.Network Vertical Generative Ai. Trao quyền cho chính mình. Truy cập Tại đây.
• PlatoAiStream. Thông minh Web3. Kiến thức khuếch đại. Truy cập Tại đây.
• Trung tâmESG. Than đá, công nghệ sạch, Năng lượng, Môi trường Hệ mặt trời, Quản lý chất thải. Truy cập Tại đây.
• PlatoSức khỏe. Tình báo thử nghiệm lâm sàng và công nghệ sinh học. Truy cập Tại đây.
• nguồn: https://aws.amazon.com/blogs/machine-learning/improve-performance-of-falcon-models-with-amazon-sagemaker/