Підвищення продуктивності логічного висновку для моделей Mixtral і Llama 2 за допомогою нових контейнерів Amazon SageMaker | Веб-сервіси Amazon

У січні 2024, Amazon SageMaker запустив нову версію (0.26.0) Контейнери глибокого навчання (DLC) у великій моделі висновку (LMI). Ця версія пропонує підтримку нових моделей (включно з Mixture of Experts), покращення продуктивності та зручності використання всіх серверних модулів висновку, а також нові деталі генерації для покращеного контролю та пояснення прогнозів (наприклад, причину завершення генерації та ймовірності журналу рівня маркера).

LMI DLC пропонують інтерфейс із низьким кодом, який спрощує використання найсучасніших методів оптимізації висновків і обладнання. LMI дозволяє застосовувати тензорний паралелізм; новітні ефективні методи управління увагою, пакетуванням, квантуванням і пам'яттю; потік токенів; і багато іншого, лише вимагаючи ідентифікатора моделі та додаткових параметрів моделі. За допомогою LMI DLC на SageMaker ви можете пришвидшити час окупності генеративний штучний інтелект (AI) додатків, розвантажте важку роботу, пов’язану з інфраструктурою, і оптимізуйте великі мовні моделі (LLM) для апаратного забезпечення на ваш вибір, щоб досягти найкращого у своєму класі співвідношення ціни та продуктивності.

У цій публікації ми досліджуємо найновіші функції, представлені в цьому випуску, перевіряємо контрольні показники продуктивності та надаємо детальний посібник із розгортання нових LLM із LMI DLC із високою продуктивністю.

Нові функції з LMI DLC

У цьому розділі ми обговорюємо нові функції серверних модулів LMI і докладніше розглянемо деякі інші, які стосуються окремих серверних модулів. Наразі LMI підтримує наступні серверні модулі:

• LMI-розподілена бібліотека – Це структура AWS для виконання логічних висновків за допомогою LLM, натхненних OSS, для досягнення найкращої можливої ​​затримки та точності результату
• LMI vLLM – Це базова реалізація AWS для ефективного використання пам’яті vLLM бібліотека висновків
• Набір інструментів LMI TensorRT-LLM – Це базова реалізація AWS NVIDIA TensorRT-LLM, який створює механізми для GPU для оптимізації продуктивності на різних GPU
• LMI DeepSpeed – Це адаптація AWS DeepSpeed, який додає справжнє безперервне пакетування, квантування SmoothQuant і можливість динамічного налаштування пам’яті під час висновку
• LMI NeuronX – Ви можете використовувати це для розгортання на AWS Inferentia2 та AWS Trainiumекземпляри на основі безперервного пакетування та прискорення на основі AWS Neuron SDK

У наведеній нижче таблиці підсумовано нещодавно додані функції, як загальні, так і специфічні для серверної частини.

Підтримуються нові моделі

Нові популярні моделі підтримуються між серверними модулями, такими як Mistral-7B (усі серверні модулі), Mixtral на базі MoE (усі серверні модулі, крім Transformers-NeuronX) і Llama2-70B (Transformers-NeuronX).

Техніка розширення контекстного вікна

Масштабування контексту на основі Rotary Positional Embedding (RoPE) тепер доступне на серверах LMI-Dist, vLLM і TensorRT-LLM. Масштабування RoPE дозволяє збільшити довжину послідовності моделі під час висновку практично до будь-якого розміру без необхідності тонкого налаштування.

Нижче наведено два важливі міркування при використанні RoPE:

• Розгубленість моделі – Зі збільшенням довжини послідовності так можна моделі спантеличеність. Цей ефект можна частково компенсувати, виконавши мінімальну точну настройку на вхідних послідовностях, більших за ті, що використовувалися в початковому навчанні. Для поглибленого розуміння того, як RoPE впливає на якість моделі, див Розширення RoPE.
• Продуктивність висновку – Більша довжина послідовності споживатиме пам’ять високої пропускної здатності прискорювача (HBM). Таке збільшення використання пам’яті може негативно вплинути на кількість одночасних запитів, які може обробити ваш прискорювач.

Додано деталі покоління

Тепер ви можете отримати дві детальні відомості про результати генерації:

• закінчити_причину – Це пояснює причину завершення генерації, яка може бути досягнута максимальної довжини генерації, генерація маркера кінця речення (EOS) або генерація визначеного користувачем маркера зупинки. Він повертається разом із фрагментом останньої потокової послідовності.
• log_probs – Це повертає ймовірність журналу, призначену моделлю для кожного маркера в потоковій послідовності. Ви можете використовувати їх як приблизну оцінку достовірності моделі, обчислюючи спільну ймовірність послідовності як суму log_probs окремих токенів, що може бути корисним для підрахунку балів і ранжування результатів моделі. Майте на увазі, що без калібрування ймовірності токенів LLM зазвичай занадто впевнені.

Ви можете ввімкнути виведення результатів генерації, додавши details=True у вхідне корисне навантаження в LMI, залишивши всі інші параметри незмінними:

payload = {“inputs”:“your prompt”,
“parameters”:{max_new_tokens”:256,...,“details”:True}
}

Консолідовані параметри конфігурації

Нарешті, параметри конфігурації LMI також були консолідовані. Щоб отримати додаткові відомості про всі загальні та специфічні параметри конфігурації розгортання, див Конфігурації висновку великої моделі.

LMI-розподілене серверне забезпечення

На AWS re:Invent 2023 LMI-Dist додав нові оптимізовані колективні операції для прискорення зв’язку між графічними процесорами, що призвело до меншої затримки та вищої пропускної здатності для моделей, які занадто великі для одного графічного процесора. Ці колективи доступні виключно для SageMaker, для екземплярів p4d.

У той час як попередня ітерація підтримувала лише сегментування для всіх 8 графічних процесорів, LMI 0.26.0 представляє підтримку тензорного паралельного ступеня 4 у частковому шаблоні "всі-до-всіх". Це можна поєднувати з Компоненти висновку SageMaker, за допомогою якого можна детально налаштувати, скільки прискорювачів має бути виділено для кожної моделі, розгорнутої за кінцевою точкою. Разом ці функції забезпечують кращий контроль над використанням ресурсів базового екземпляра, дозволяючи вам збільшити багатокористувацький доступ моделі, розміщуючи різні моделі за однією кінцевою точкою, або точно налаштувати сукупну пропускну здатність вашого розгортання відповідно до вашої моделі та характеристик трафіку.

На наступному малюнку порівнюється пряме "всіх до всіх" із частковим "всіх до всіх".

Сервер TensorRT-LLM

TensorRT-LLM від NVIDIA був представлений як частина попереднього випуску LMI DLC (0.25.0), що забезпечує найсучаснішу продуктивність графічного процесора та оптимізацію, як-от SmoothQuant, FP8 і безперервне пакетування для LLM при використанні графічних процесорів NVIDIA.

TensorRT-LLM вимагає, щоб моделі були скомпільовані в ефективні механізми перед розгортанням. LMI TensorRT-LLM DLC може автоматично обробляти оперативне складання списку підтримуваних моделей (JIT) перед запуском сервера та завантаженням моделі для висновку в реальному часі. Версія 0.26.0 DLC розширює список підтримуваних моделей для JIT-компіляції, представляючи моделі Baichuan, ChatGLM, GPT2, GPT-J, InternLM, Mistral, Mixtral, Qwen, SantaCoder і StarCoder.

JIT-компіляція додає кілька хвилин накладних витрат на підготовку кінцевої точки та час масштабування, тому завжди рекомендується скомпілювати вашу модель заздалегідь. Посібник щодо того, як це зробити, і список підтримуваних моделей див Посібник TensorRT-LLM із завчасної компіляції моделей. Якщо вибрана модель ще не підтримується, зверніться до Підручник TensorRT-LLM зі складання моделей вручну для компіляції будь-якої іншої моделі, яка підтримується TensorRT-LLM.

Крім того, LMI тепер надає власне квантування TensorRT-LLM SmootQuant із параметрами для керування альфа-каналом і коефіцієнтом масштабування за маркером або каналом. Додаткову інформацію про відповідні конфігурації див TensorRT-LLM.

сервер vLLM

Оновлений випуск vLLM, включений у LMI DLC, має покращення продуктивності до 50% за рахунок режиму графіка CUDA замість режиму Eager. Графіки CUDA прискорюють робочі навантаження графічного процесора, запускаючи кілька операцій графічного процесора одночасно, а не запускаючи їх окремо, що зменшує накладні витрати. Це особливо ефективно для малих моделей при використанні тензорного паралелізму.

Додаткова продуктивність досягається за рахунок додаткового споживання пам’яті GPU. Режим графіка CUDA тепер є типовим для серверної частини vLLM, тому, якщо ви обмежені обсягом доступної пам’яті GPU, ви можете встановити option.enforce_eager=True щоб увімкнути активний режим PyTorch.

Сервер Transformers-NeuronX

Оновлений випуск NeuronX включений у LMI NeuronX DLC тепер підтримує моделі, які мають механізм звернення згрупованих запитів, наприклад Mistral-7B і LLama2-70B. Увага згрупованого запиту є важливою оптимізацією механізму уваги трансформатора за замовчуванням, де модель навчається з меншою кількістю головок ключів і значень, ніж головок запиту. Це зменшує розмір кешу KV у пам’яті графічного процесора, забезпечуючи більший паралелізм і покращуючи співвідношення ціни та якості.

На наступному малюнку показано методи звернення уваги з кількома голами, згрупованими запитами та багатозапитовими (джерело).

Для різних типів навантажень доступні різні стратегії шардингу кешу KV. Щоб отримати додаткові відомості про стратегії шардингу, див Підтримка групового запиту (GQA).. Ви можете ввімкнути бажану стратегію (shard-over-heads, наприклад) з таким кодом:

option.group_query_attention=shard-over-heads

Крім того, нова реалізація NeuronX DLC представляє API кешу для TransformerNeuronX, який забезпечує доступ до кешу KV. Це дозволяє вам вставляти та видаляти рядки кешу KV з нових запитів, поки ви передаєте пакетний висновок. Перед запровадженням цього API кеш KV було переобчислено для всіх щойно доданих запитів. У порівнянні з LMI V7 (0.25.0), ми покращили затримку більш ніж на 33% з одночасними запитами та підтримуємо набагато вищу пропускну здатність.

Вибір правильного бекенда

Щоб вирішити, яку серверну частину використовувати на основі вибраної моделі та завдання, скористайтеся наведеною нижче блок-схемою. Окремі посібники користувача серверної частини та підтримувані моделі див Посібники користувача LMI Backend.

Розгорніть Mixtral із LMI DLC із додатковими атрибутами

Давайте розглянемо, як можна розгорнути модель Mixtral-8x7B з контейнером LMI 0.26.0 і створити додаткові деталі, наприклад log_prob та finish_reason як частина виходу. Ми також обговорюємо, як ви можете отримати вигоду з цих додаткових атрибутів через сценарій використання генерації вмісту.

Повний блокнот із докладними інструкціями доступний у GitHub репо.

Ми починаємо з імпорту бібліотек і налаштування середовища сеансу:

import boto3
import sagemaker 
import json 
import io 
import numpy as np 
from sagemaker import Model, image_uris, serializers, deserializers 

role = sagemaker.get_execution_role() # execution role for the endpoint 
session = sagemaker.session.Session() # sagemaker session for interacting with different AWS APIs 
region = session._region_name # region name of the current SageMaker Studio environment

Ви можете використовувати контейнери SageMaker LMI для розміщення моделей без додаткового коду висновку. Сервер моделі можна налаштувати за допомогою змінних середовища або a serving.properties файл. За бажанням ви можете мати a model.py файл для будь-якої попередньої або постобробки та a requirements.txt файл для будь-яких додаткових пакетів, які потрібно встановити.

У цьому випадку ми використовуємо serving.properties файл, щоб налаштувати параметри та налаштувати поведінку контейнера LMI. Для отримання додаткової інформації зверніться до GitHub репо. Репо пояснює деталі різних параметрів конфігурації, які можна встановити. Нам потрібні наступні ключові параметри:

• двигун – Визначає механізм виконання для DJL. Це керує шардингом і стратегією завантаження моделі в прискорювачах для моделі.
• option.model_id – Вказує на Служба простого зберігання Amazon (Amazon S3) URI попередньо навченої моделі або ідентифікатор моделі попередньо навченої моделі, розміщеної в репозиторії моделей на Обіймати обличчя. У цьому випадку ми надаємо ідентифікатор моделі для моделі Mixtral-8x7B.
• option.tensor_parallel_degree – Встановлює кількість пристроїв GPU, на які Accelerate потрібно розділити модель. Цей параметр також контролює кількість робітників на модель, яка буде запущена під час запуску служби DJL. Ми встановили це значення max (максимальний GPU на поточній машині).
• option.rolling_batch – Дозволяє безперервне дозування для оптимізації використання прискорювача та загальної пропускної здатності. Для контейнера TensorRT-LLM ми використовуємо auto.
• option.model_loading_timeout – Встановлює значення часу очікування для завантаження та завантаження моделі для обслуговування висновків.
• option.max_rolling_batch – Встановлює максимальний розмір безперервної партії, визначаючи, скільки послідовностей можна обробляти паралельно в будь-який момент часу.

%%writefile serving.properties 
engine=MPI 
option.model_id=mistralai/Mixtral-8x7B-v0.1 
option.tensor_parallel_degree=max 
option.max_rolling_batch_size=32 
option.rolling_batch=auto 
option.model_loading_timeout = 7200

Пакуємо serving.properties конфігураційний файл у форматі tar.gz, щоб він відповідав вимогам хостингу SageMaker. Ми налаштовуємо контейнер DJL LMI за допомогою tensorrtllm як серверний механізм. Додатково вказуємо останню версію контейнера (0.26.0).

image_uri = image_uris.retrieve(
   framework="djl-tensorrtllm",
   region=sess.boto_session.region_name,
   version="0.26.0"
)

Далі ми завантажуємо локальний архів (містить serving.properties файл конфігурації) до префікса S3. Для створення об’єкта моделі SageMaker ми використовуємо URI зображення для контейнера DJL і розташування Amazon S3, куди було завантажено архівний файл моделі, що обслуговує артефакти.

model = Model(image_uri=image_uri, model_data=code_artifact, role=role) 

instance_type = "ml.p4d.24xlarge" 
endpoint_name = sagemaker.utils.name_from_base("mixtral-lmi-model") 

model.deploy(
   initial_instance_count=1,
   instance_type=instance_type,
   endpoint_name=endpoint_name,
   container_startup_health_check_timeout=1800
)

Як частина LMI 0.26.0, тепер ви можете використовувати дві додаткові детальні відомості про згенерований результат:

• log_probs – Це ймовірність журналу, призначена моделлю для кожного маркера в потоковій послідовності. Ви можете використовувати їх як приблизну оцінку достовірності моделі, обчислюючи спільну ймовірність послідовності як суму логарифмічних ймовірностей окремих токенів, що може бути корисним для підрахунку балів і ранжування результатів моделі. Майте на увазі, що без калібрування ймовірності токенів LLM зазвичай занадто впевнені.
• закінчити_причину – Це причина завершення генерації, яка може бути досягнута максимальної довжини генерації, генерація маркера EOS або генерація визначеного користувачем маркера зупинки. Це повертається з останнім потоковим блоком послідовності.

Ви можете ввімкнути їх, пройшовши "details"=True як частину вашого внеску в модель.

Давайте подивимося, як ви можете створити ці деталі. Ми використовуємо приклад генерації вмісту, щоб зрозуміти їх застосування.

Визначимо a LineIterator допоміжний клас, який має функції для лінивого отримання байтів із потоку відповідей, їх буферизації та розбиття буфера на рядки. Ідея полягає в тому, щоб обслуговувати байти з буфера, одночасно одержуючи більше байтів із потоку асинхронно.

class LineIterator:
    def __init__(self, stream):
        # Iterator to get bytes from stream 
        self.byte_iterator = iter(stream)  
        # Buffer stream bytes until we get a full line
        self.buffer = io.BytesIO()  
        # Track current reading position within buffer
        self.read_pos = 0

   def __iter__(self):
        # Make class iterable 
        return self

    def __next__(self):
        while True:
           # Seek read position within buffer
           self.buffer.seek(self.read_pos)  
           # Try reading a line from current position
           line = self.buffer.readline()
           # If we have a full line
           if line and line[-1] == ord('n'):
               # Increment reading position past this line
               self.read_pos += len(line)  
               # Return the line read without newline char
               return line[:-1] 
           # Fetch next chunk from stream  
           try:
               chunk = next(self.byte_iterator)
           # Handle end of stream 
           except StopIteration:
               # Check if we have any bytes still unread
               if self.read_pos < self.buffer.getbuffer().nbytes:
                   continue
               # If not, raise StopIteration
               raise
           # Add fetched bytes to end of buffer
           self.buffer.seek(0, io.SEEK_END)  
           self.buffer.write(chunk['PayloadPart']['Bytes'])

Створіть і використовуйте ймовірність маркера як додаткову деталь

Розглянемо приклад використання, коли ми генеруємо вміст. Зокрема, нам доручено написати короткий параграф про переваги регулярних фізичних вправ для веб-сайту, орієнтованого на спосіб життя. Ми хочемо згенерувати вміст і вивести деяку індикативну оцінку впевненості, яку модель має щодо згенерованого вмісту.

Ми викликаємо кінцеву точку моделі за допомогою підказки та фіксуємо згенеровану відповідь. Ми поставили "details": True як параметр часу виконання у вхідних даних моделі. Оскільки ймовірність журналу генерується для кожного вихідного маркера, ми додаємо окремі ймовірності журналу до списку. Ми також беремо повний згенерований текст відповіді.

sm_client = boto3.client("sagemaker-runtime")

# Set details: True as a runtime parameter within the input.
body = {"inputs": prompt, "parameters": {"max_new_tokens":512, "details": True}}
resp = sm_client.invoke_endpoint_with_response_stream(EndpointName=endpoint_name, Body=json.dumps(body), ContentType="application/json")
event_stream = resp['Body']

overall_log_prob = []

for line in LineIterator(event_stream):
    resp = json.loads(line)
    if resp['token'].get('text') != None:
        token_log_prob = resp['token']['log_prob']
        overall_log_prob.append(token_log_prob)
    elif resp['generated_text'] != None:
        generated_text= resp['generated_text']

Щоб обчислити загальну оцінку достовірності, ми обчислюємо середнє значення ймовірностей усіх окремих токенів і згодом отримуємо експоненціальне значення від 0 до 1. Це наша припущена загальна оцінка довіри для створеного тексту, який у цьому випадку є абзацом про переваги регулярних занять спортом.

print(generated_text) 
overall_score=np.exp(np.mean(overall_log_prob)) 
print(f"nnOverall confidence score in the generated text: {overall_score}")

Це був один із прикладів того, як можна генерувати та використовувати log_prob, у контексті сценарію використання генерації вмісту. Аналогічно можна використовувати log_prob як міра достовірності для випадків використання класифікації.

Крім того, ви можете використовувати його для загальної послідовності вихідних даних або підрахунку балів на рівні речення, щоб оцінити вплив таких параметрів, як температура, на згенерований результат.

Створіть і використовуйте причину завершення як додаткову деталь

Давайте розглянемо той самий варіант використання, але цього разу нам доручено написати більшу статтю. Крім того, ми хочемо переконатися, що вихідні дані не скорочуються через проблеми з довжиною генерації (максимальна довжина маркера) або через виявлення маркерів зупинки.

Для цього ми використовуємо finish_reason атрибут, згенерований у виводі, відстежуйте його значення та продовжуйте генерувати, доки не буде згенеровано весь вивід.

Ми визначаємо функцію висновку, яка приймає введення корисного навантаження та викликає кінцеву точку SageMaker, повертає відповідь і обробляє відповідь для вилучення згенерованого тексту. Корисне навантаження містить текст підказки як вхідні дані та параметри, як-от максимальні токени та деталі. Відповідь зчитується в потоці та обробляється рядок за рядком, щоб витягти згенеровані текстові маркери в список. Витягуємо деталі як finish_reason. Ми викликаємо функцію висновку в циклі (ланцюгові запити), додаючи щоразу більше контексту, і відстежуємо кількість згенерованих токенів і кількість надісланих запитів, доки модель не завершиться.

def inference(payload):
    # Call SageMaker endpoint and get response stream
    resp = sm_client.invoke_endpoint_with_response_stream(EndpointName=endpoint_name, Body=json.dumps(payload), ContentType="application/json")
    event_stream = resp['Body']
    text_output = []
    for line in LineIterator(event_stream):
        resp = json.loads(line) 
        # Extract text tokens if present
        if resp['token'].get('text') != None:
            token = resp['token']['text']
            text_output.append(token)  
            print(token, end='')
        # Get finish reason if details present
        if resp.get('details') != None:
            finish_reason = resp['details']['finish_reason']
            # Return extracted output, finish reason and token length
            return payload['inputs'] + ''.join(text_output), finish_reason, len(text_output)

# set details: True as a runtime parameter within the input.
payload = {"inputs": prompt,  "parameters": {"max_new_tokens":256, "details": True}} 

finish_reason = "length"
# Print initial output 
print(f"Output: {payload['inputs']}", end='')  
total_tokens = 0
total_requests = 0
while finish_reason == 'length':
    # Call inference and get extracts
    output_text, finish_reason, out_token_len = inference(payload)
    # Update payload for next request
    payload['inputs'] = output_text 
    total_tokens += out_token_len
    total_requests += 1
# Print metrics
print(f"nntotal tokens generated: {total_tokens} ntotal requests sent: {total_requests}")

Як бачимо, незважаючи на те, що max_new_token для параметра встановлено значення 256, ми використовуємо атрибут деталі finish_reason як частину виводу для ланцюжка кількох запитів до кінцевої точки, доки не буде згенеровано весь вивід.

Так само, залежно від вашого випадку використання, ви можете використовувати stop_reason для виявлення недостатньої довжини вихідної послідовності, зазначеної для даного завдання, або ненавмисного завершення через послідовність зупинки, виконану людиною.

Висновок

У цій публікації ми ознайомилися з випуском v0.26.0 контейнера AWS LMI. Ми виділили ключові покращення продуктивності, підтримку нової моделі та нові функції зручності використання. Завдяки цим можливостям ви можете краще збалансувати вартість і продуктивність, забезпечуючи кращий досвід для кінцевих користувачів.

Щоб дізнатися більше про можливості LMI DLC, див Паралелізм моделі та висновок великої моделі. Ми раді бачити, як ви використовуєте ці нові можливості від SageMaker.

Про авторів

Жоао Моура є старшим архітектором рішень зі штучного інтелекту/ML в AWS. Жоао допомагає клієнтам AWS – від невеликих стартапів до великих підприємств – навчати та ефективно розгортати великі моделі, а також ширше створювати платформи машинного навчання на AWS.

Рахул Шарма є старшим архітектором рішень в AWS, який допомагає клієнтам AWS проектувати та створювати рішення AI/ML. До того, як приєднатися до AWS, Рахул кілька років працював у фінансовому та страховому секторі, допомагаючи клієнтам створювати дані та аналітичні платформи.

Цин Лан є інженером з розробки програмного забезпечення в AWS. Він працював над декількома складними продуктами в Amazon, включаючи високоефективні рішення ML inference та високоефективну систему журналювання. Команда Ціна успішно запустила першу модель із мільярдами параметрів у Amazon Advertising із дуже малою затримкою. Qing має глибокі знання щодо оптимізації інфраструктури та прискорення глибокого навчання.

Цзянь Шен є інженером із розробки програмного забезпечення в Amazon Web Services, який працював над кількома ключовими аспектами систем машинного навчання. Він був ключовим учасником служби SageMaker Neo, зосереджуючись на компіляції глибокого навчання та оптимізації середовища виконання. Нещодавно він спрямував свої зусилля та зробив внесок у оптимізацію системи машинного навчання для виведення великих моделей.

Тайлер Остерберг є інженером з розробки програмного забезпечення в AWS. Він спеціалізується на створенні високоефективного машинного навчання в SageMaker. Останнім часом він зосередився на оптимізації продуктивності контейнерів глибокого навчання Inferentia на платформі SageMaker. Тайлер чудово впроваджує ефективні рішення для хостингу для великих мовних моделей і покращує взаємодію з користувачами за допомогою передових технологій.

Рупіндер Гревал є старшим архітектором рішень зі штучного інтелекту/ML в AWS. Зараз він зосереджується на обслуговуванні моделей і MLO на Amazon SageMaker. До цієї посади він працював інженером машинного навчання, створюючи та розміщуючи моделі. Поза роботою він любить грати в теніс і їздити на велосипеді гірськими стежками.

Дхавал Патель є головним архітектором машинного навчання в AWS. Він працював з організаціями, починаючи від великих підприємств і закінчуючи стартапами середнього розміру, над проблемами, пов’язаними з розподіленими обчисленнями та штучним інтелектом. Він зосереджується на глибокому навчанні, включаючи домени НЛП та комп’ютерного зору. Він допомагає клієнтам досягти високопродуктивної моделі висновку на SageMaker.

Рагу Рамеша є старшим архітектором рішень ML у команді Amazon SageMaker Service. Він зосереджується на допомозі клієнтам створювати, розгортати та переносити робочі навантаження ML на SageMaker у великих масштабах. Він спеціалізується на машинному навчанні, штучному інтелекті та комп’ютерному зорі, а також має ступінь магістра комп’ютерних наук в UT Dallas. У вільний час захоплюється подорожами та фотографією.

• Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
• PlatoData.Network Vertical Generative Ai. Додайте собі сили. Доступ тут.
• PlatoAiStream. Web3 Intelligence. Розширення знань. Доступ тут.
• ПлатонЕСГ. вуглець, CleanTech, Енергія, Навколишнє середовище, Сонячна, Поводження з відходами. Доступ тут.
• PlatoHealth. Розвідка про біотехнології та клінічні випробування. Доступ тут.
• джерело: https://aws.amazon.com/blogs/machine-learning/boost-inference-performance-for-mixtral-and-llama-2-models-with-new-amazon-sagemaker-containers/