SageMaker HyperPod Data Capture записывает входы и выходы живого инференса в Amazon S3 на трёх независимых уровнях: SageMaker endpoint, load balancer и model pod. Любую комбинацию уровней включают в одном блоке dataCapture, задержка ответа при этом растёт минимально, а доступность модели не страдает. Продакшен-трафик перестаёт быть одноразовым: его разбирают, размечают и возвращают в модель как обучающий набор, не выходя за пределы кластера (разбор AWS).
Боль, которую закрывает возможность, выглядит буднично. Модель в продакшене видит запросы, которых не было в её обучающей выборке: новые продукты, новые формулировки, новые опечатки. Эти запросы никуда не сохраняются. Через месяц после запуска новой линейки кондиционеров роутер поддержки продолжает сваливать половину обращений в категорию Other, и узнают об этом из жалоб, а не из метрик.
Сквозной пример в публикации AWS строят вокруг такого роутера: захват трафика на Tier 3, запросы Athena, SQL-политика разметки и LoRA-дообучение на другом узле того же кластера. Точность на отложенной выборке растёт с 83,9% до 100%. Оговорка сразу: данные в примере синтетические, а скрипты, манифесты, SQL и датасеты лежат в сопровождающем GitHub-репозитории. Это демонстрация механики, а не отчёт о продакшен-внедрении.
Что такое SageMaker HyperPod Data Capture и зачем он нужен
Определение короткое: Data Capture пишет запросы и ответы инференса в Amazon S3, не требуя менять код модели. Дальше начинается инженерия. S3 становится источником для Athena, Athena даёт SQL для разметки, размеченные записи уходят в обучение. Цикл «захват → анализ → разметка → дообучение» замыкается внутри HyperPod, без отдельного data lake и без ручной выгрузки логов.
Практическая ценность в том, что данные для дообучения не придумывают, а берут из реального распределения запросов. Синтетика хорошо покрывает известные сценарии и плохо описывает то, что придумали пользователи. Захваченный трафик содержит именно эти новые формулировки, причём в том виде, в каком они приходят в поддержку.
Где Data Capture стоит в общем стеке HyperPod
Кластер HyperPod обычно держит два оператора: inference operator обслуживает модель на одном узле, training operator запускает дообучение на другом. Оба живут в одном кластере Kubernetes под управлением Amazon EKS. Data Capture встроен в inference-путь, а на уровне model pod им управляет тот же inference operator через сайдкары NGINX, OTel collector и S3 uploader. Дообучение читает готовые записи из S3, поэтому перегонять данные между аккаунтами и сервисами не нужно.
Tier 1 устроен иначе: его ведёт нативный data capture SageMaker, а не HyperPod-оператор. Путать эти механизмы не стоит, у них разные точки захвата, наборы полей и сценарии. Для аудита и интеграции с Model Monitor смотрят на Tier 1, для обучающего набора из payload'ов на Tier 3.
Совмещение инференса и обучения на одном кластере вообще снимает часть логистики. Как это выглядит в другом сценарии, где на HyperPod крутят мультимодальное RL-обучение с колокацией vLLM и FSDP и синхронизацией весов через FSx for Lustre, разобрано в материале про SkyRL на Amazon SageMaker HyperPod.
Три уровня захвата: endpoint, load balancer и model pod
Уровни сидят в разных точках пути запроса, поэтому и данные дают разные. Включать их можно в любой комбинации, но каждая комбинация по-своему бьёт по объёму хранения.
Tier 1: SageMaker endpoint, полные payload'ы для аудита
Tier 1 пишет полные payload'ы запроса и ответа на уровне SageMaker endpoint. Управляет им нативный data capture SageMaker. Сценарии: требования compliance к хранению обращений, интеграция с Model Monitor, разбор инцидента по конкретному запросу. Минус существенный: если рядом включён Tier 3, каждый запрос записывается дважды вместе с двойным расходом на хранение.
Tier 2: load balancer, дешёвые метаданные трафика
Tier 2 берёт данные из access-логов Application Load Balancer: request line, статус-коды, тайминги, client IP, user agent. Тел запросов здесь нет, поэтому для сборки обучающего набора уровень не годится. Зато это самый дешёвый способ увидеть объём трафика, долю ошибок и хвосты задержек. Когда задача сводится к мониторингу, останавливаются на нём.
Tier 3: model pod, payload'ы плюс метаданные для обучения
Tier 3 пишет полные payload'ы запроса и ответа плюс метаданные событий. Управляет уровнем HyperPod inference operator: рядом с контейнером модели поднимаются сайдкары NGINX, OTel collector и S3 uploader. Сценарии: отладка, аналитика, сбор обучающих данных. В разборе AWS используют только Tier 3, и это логично: payload'ы планируют превращать в датасет, а не хранить ради аудита.
| Уровень | Точка пути запроса | Что попадает в S3 | Кто управляет | Для чего подходит |
|---|---|---|---|---|
| Tier 1 | SageMaker endpoint | Полные payload'ы запроса и ответа | Нативный data capture SageMaker | Compliance, Model Monitor, аудит |
| Tier 2 | Load balancer | Поля access-логов ALB: request line, статус-коды, тайминги, client IP, user agent | Access-логи Application Load Balancer | Мониторинг трафика и частоты ошибок при низкой стоимости |
| Tier 3 | Model pod | Полные payload'ы плюс метаданные событий | HyperPod inference operator: NGINX, OTel collector, S3 uploader | Отладка, аналитика, сбор обучающих данных |
Рекомендация из публикации: Tier 1 для compliance и Model Monitor, Tier 2 когда нужны только метаданные трафика, Tier 3 когда payload'ы действительно пойдут в дело. Одновременно включать Tier 1 и Tier 3 имеет смысл при явном требовании хранить копию для аудита, и тогда двойной объём записи стоит посчитать заранее (описание уровней).
Задержка, доступность и стоимость: чего ждать на практике
Задержка. В разборе AWS влияние на время ответа описано как минимальное: разница между прямым путём и путём через прокси-сайдкар укладывается в погрешность измерений. Абсолютные миллисекунды зависят от размера payload'а, скорости записи в S3 и настроек батчинга OTel collector, поэтому на своём профиле трафика эти цифры придётся снимать заново.
Доступность. Захват не влияет на доступность модели: если сайдкар не успел записать событие, ответ пользователю от этого не ломается.
Стоимость. Тарифов в долларах публикация не приводит, зато понятна структура расходов. Считать нужно три составляющие: объём записанных данных в S3 (полный payload весит куда больше строки access-лога), запросы Athena по этим данным и хранение с учётом срока давности. Два уровня с payload'ами дают двойной объём и двойной счёт.
Как не утонуть в счетах за S3
Почти весь риск закрывают три настройки. Сэмплирование: писать не 100% запросов, а долю, достаточную для статистики по редким категориям. S3 lifecycle rules: переводить старые записи в дешёвый класс хранения или удалять после того, как они попали в обучающий набор. Отказ от лишних уровней: Tier 2 вместо Tier 3, если payload'ы не нужны, и никакого дублирования Tier 1 с Tier 3 без аудиторского требования.
Безопасность данных: IAM-роли, шифрование и PII
Tier 3 пишет полные payload'ы, а в поддержке бытовой техники это имена, адреса, номера заказов. До того как записи станут обучающими данными, их защищают: сэмплирование, шифрование AWS KMS через параметр kmsKeyId, S3 lifecycle rules и редактирование PII, например через Amazon Comprehend.
IAM. Inference operator пишет в S3 от имени роли, у которой есть права на конкретный префикс бакета и на использование ключа KMS, а не на весь аккаунт. Рабочая схема: отдельный префикс на каждый уровень захвата, отдельная роль на оператор, права только на запись и чтение нужных путей. Если запросов много и нужны квоты и учёт расходов по командам, похожая логика разграничения доступа к моделям разобрана в статье про self-service LLM-шлюз на Amazon Bedrock и LiteLLM.
Редактирование PII до разметки
Порядок шагов важен: сначала чистка, потом разметка. Если SQL-политика увидит сырые персональные данные, они попадут и в разметку, и в обучающий набор, и в чекпоинт модели. На практике PII отфильтровывают или маскируют на этапе подготовки таблицы в Athena, и только после этого применяют правила разметки.
Сквозной кейс: роутер поддержки бытовой техники от трафика до дообучения
Один кластер HyperPod, два оператора. Inference operator обслуживает модель на одном узле, training operator запускает дообучение на другом. Данные передаются через S3, промежуточные сервисы не нужны.
Шаг 1: захват трафика на Tier 3
Нужен кластер SageMaker HyperPod под управлением Amazon EKS с установленным inference operator. В блоке dataCapture включают Tier 3, и дальше каждый запрос к роутеру оставляет в S3 пару «запрос-ответ» вместе с метаданными события.
Шаг 2: Athena находит слепую зону в категории Other
Athena читает накопленные записи прямо из S3. Запрос по категориям показывает всплеск обращений про новую линейку кондиционеров, которую роутер относит к Other. Это и есть слепая зона: данные, которых физически не могло существовать до развёртывания модели. Предобучающая выборка такого не покажет.
Шаг 3: SQL-политика разметки превращает записи в обучающий набор
Разметка идёт правилами на SQL: записи с упоминанием конкретной серии кондиционеров получают метку новой категории. Ручной труд не нужен, правила воспроизводимы и версионируются вместе с запросами. Результат, таблица с парами «текст запроса → правильная категория», и есть обучающий набор. Как похожий цикл выглядит на другой задаче разметки каталога, с SFT на схеме из девяти категорий и RLVR с детерминированной reward-функцией, показано в материале про кастомизацию Qwen3-8B в Amazon SageMaker.
Шаг 4: LoRA-дообучение через HyperPod training operator
Дообучение запускают на том же кластере через HyperPod training operator. LoRA-адаптер на таком объёме данных обучается примерно за минуту. Метрика до и после: точность на отложенной выборке 83,9% → 100%, регрессии на существующих категориях нет. Оценка идёт на данных, которых не могло существовать до развёртывания модели, и в этом главная разница с обычным офлайн-бенчмарком (сквозной сценарий AWS).
Сто процентов стоит читать буквально: это результат на конкретном синтетическом наборе, где новых формулировок ограниченное число. Выбор между SFT и RL-надстройкой поверх чекпоинта зависит от задачи, разница в подходах и типичный прирост разобраны на кейсе SFT или GRPO для GPT-OSS-20B.
Ограничения подхода: shortcuts и некалиброванный confidence
Shortcuts. Модель после дообучения цепляется за поверхностные признаки: упоминание серии в тексте запроса, характерное слово, шаблон формулировки. На размеченном наборе это даёт идеальную точность, на живом трафике может развалиться, потому что пользователь напишет иначе и без названия модели.
Confidence. Поле confidence в ответе модели не откалибровано: значение 0,9 не значит «в 90% случаев ответ верный». Ставить на нём пороги автоэскалации без отдельной калибровки на живых данных рискованно.
Единичный прогон. 100% на одной отложенной выборке ничего не гарантируют в продакшене: набор небольшой, синтетический и собран по тем же правилам, что и обучающие данные. Если правила разметки и правила генерации тестов совпадают, метрика измеряет согласованность правил, а не качество модели.
Что делать с shortcuts на практике
Проверять на отложенной выборке, собранной иначе: другие формулировки, другие длины запросов, запросы без названия серии и без кодов товара. Смотреть не только на итоговую точность, но и на распределение ошибок по категориям, отдельно по новым и по старым. Один удачный прогон не повод выкатывать модель без теневого режима и сравнения с текущей версией на живом трафике.
Кому подходит и как начать: требования и чек-лист
Требования минимальные на вид: кластер SageMaker HyperPod, оркестрируемый Amazon EKS, с установленным inference operator. Дальше всё упирается в готовность команды заниматься PII, ролями и стоимостью хранения.
Кому подходит: командам, которые уже гоняют LLM в продакшене на AWS и хотят собирать данные системно, а не выпрашивать логи у поддержки. Кому нет: тем, кому нужен только мониторинг ошибок и объёма трафика, хватит Tier 2. Тем, у кого в запросах много персональных данных и нет процесса их очистки, начинать с полного захвата payload'ов рано.
Чек-лист внедрения
- Проверить кластер HyperPod и наличие inference operator.
- Выбрать комбинацию уровней в блоке dataCapture, для обучающих данных это Tier 3.
- Настроить IAM-роль inference operator с доступом к нужному префиксу S3 и ключу KMS.
- Включить шифрование через kmsKeyId.
- Задать сэмплирование и S3 lifecycle rules.
- Настроить редактирование PII, например через Amazon Comprehend.
- Построить запросы Athena к захваченным данным и найти аномалии по категориям.
- Написать SQL-политику разметки и собрать обучающий набор.
- Запустить LoRA-дообучение через HyperPod training operator.
- Сравнить точность на отложенной выборке до и после, проверить отсутствие регрессии на существующих категориях.
Первый шаг занимает пару часов: включить Tier 3 с сэмплированием на одном префиксе S3, прогнать Athena по свежим записям и посмотреть, какие категории проваливаются в Other. Если провал виден уже на недельном объёме трафика, дальше имеет смысл писать SQL-политику разметки и запускать LoRA-дообучение на том же кластере.