AWS показала, как запустить llama.cpp на SageMaker и получать вероятности по вариантам

AWS Machine Learning Blog опубликовал пошаговое руководство по развёртыванию decision-моделей на Amazon SageMaker AI с движком llama.cpp. Схема двухслойная. Сначала поднимается эндпоинт на базе официального AWS Deep Learning Container для llama.cpp, который отдаёт OpenAI-совместимые chat completions. Затем рантайм расширяется библиотекой SemIf, и вместо сгенерированного текста модель возвращает вероятности по заранее объявленным вариантам. Всё это работает и на CPU, и на GPU.

Материал прикладной: это инструкция, а не анонс нового продукта. Но она показывает, как AWS предлагает закрывать один из самых частых корпоративных сценариев — классификацию и принятие решений на небольших моделях без тяжёлой GPU-инфраструктуры.

Из чего собран стек

llama.cpp — открытый движок инференса на C/C++, который умеет запускать квантизованные модели в формате GGUF и не требует GPU. Именно поэтому он популярен там, где нужны дешёвые и предсказуемые эндпоинты. AWS упаковала его в собственный Deep Learning Container, чтобы не собирать образ вручную и не разбираться с зависимостями.

Ключевые элементы решения по описанию AWS:

• Платформа: Amazon SageMaker AI, управляемые эндпоинты для инференса.
• Рантайм: AWS Deep Learning Container для llama.cpp.
• Интерфейс: OpenAI-совместимые chat completions, то есть существующие клиенты и SDK подключаются без переписывания.
• Расширение: SemIf, возвращающий вероятности по объявленным вариантам.
• Железо: CPU или GPU, выбор остаётся за разработчиком.

Совместимость с форматом OpenAI решает практическую проблему миграции. Если приложение уже ходит в чат-API, переключение на собственный эндпоинт сводится к смене адреса и ключа.

Зачем вероятности вместо текста

Decision-модель отвечает на вопрос с конечным набором исходов: одобрить или отклонить заявку, отправить тикет в биллинг или в техподдержку, пометить сообщение как нарушение или пропустить. Обычная LLM выдаёт строку, которую нужно разбирать. Формат ответа плавает, модель добавляет пояснения, иногда придумывает вариант, которого в списке нет.

SemIf, судя по описанию, закрывает эту проблему на уровне рантайма. Разработчик объявляет допустимые опции, а в ответ получает распределение вероятностей по ним. Выбрать можно максимум, но интереснее другое: появляется порог уверенности. Если лучший вариант набрал 0,92, действие выполняется автоматически. Если 0,48, кейс уходит человеку. Это превращает языковую модель в компонент с измеримой калибровкой, который можно встроить в обычный бизнес-процесс.

Для инженеров это ещё и вопрос тестирования. Вероятности можно логировать, сравнивать между версиями модели и строить по ним метрики, чего не сделать с произвольным текстом.

Что в анонсе не сказано

В короткой аннотации нет бенчмарков, цен, списка поддерживаемых моделей и деталей реализации SemIf. Неясно, как именно считаются вероятности: по логитам первых токенов вариантов или иначе. От этого зависит, насколько им можно доверять на длинных или составных опциях. Нет и сравнения CPU с GPU по задержке и стоимости за запрос. Эти данные придётся получать самостоятельно.

С чего начать

Практический порядок действий для команды, которая хочет проверить подход:

• Выберите одну узкую задачу с 3–10 исходами, например маршрутизацию обращений.
• Возьмите небольшую квантизованную модель в GGUF и поднимите её на CPU-инстансе. Это самый дешёвый старт.
• Соберите размеченную выборку и измерьте, насколько вероятности SemIf соотносятся с реальной точностью. Подберите пороги для автоматического решения и эскалации.
• Только после этого сравните с GPU-инстансом по задержке и цене за тысячу запросов.

Если калибровка окажется плохой, лучше узнать об этом до продакшена. Если хорошей, команда получит управляемый эндпоинт с привычным API и понятной экономикой.