Перейти к содержимому

Инфраструктура и цены с точки зрения операций

Всё, что мы опубликовали по теме «Инфраструктура и цены», с точки зрения операционного отдела: что это меняет для B2B-компании на 10-200 человек.

  1. Главное

    AWS Batch добавил квоты на общие GPU для SageMaker

    В AWS Batch появился механизм планирования quota management. Администратор делит мощность GPU на квоты по командам или проектам, а простаивающие ресурсы автоматически уходят другим квотам. Вытеснение возвращает одолженное и сначала запускает приоритетные задачи SageMaker Training, так что вручную договариваться не нужно.

    Что меняется для операций — Это важно, только если ваша компания обучает или дообучает модели на GPU, которыми пользуются несколько человек или проектов. Если в команде на 10-200 человек так и есть, квоты заменят переписки в Slack о том, кто занял видеокарты: выдайте каждому проекту квоту, отметьте, какие могут одалживать и занимать, а возврат мощности оставьте планировщику. Если вы лишь обращаетесь к размещённым моделям через API, менять ничего не нужно. В источнике нет ни цен, ни сведений о доступности по регионам, поэтому перед планированием загляните в руководство пользователя AWS Batch.

  1. Claude в Amazon Bedrock теперь обрабатывает запросы внутри Индии

    Для B2B-компании на 10-200 человек, обслуживающей индийских клиентов или связанной контрактами с требованием обработки данных внутри страны, это убирает реальное препятствие для использования Claude в поддержке или продажах: раньше маршрутизация через Bedrock могла означать, что промпты и ответы покидали Индию. Теперь в консоли или через API можно выбрать профиль IN и получить те же модели с инференсом, ограниченным ap-south-1 и ap-south-2. Биллинг, квоты и логи CloudWatch/CloudTrail остаются привязаны к исходному региону - мониторинг и учёт затрат не распадаются по географиям. Команды, строящие бот поддержки или ассистента продаж на Claude для индийского юрлица, теперь могут делать это без отдельного комплаенс-обхода или смены поставщика моделей.

  1. Grok 4.6 вышел в Amazon Bedrock

    Для компании на 10-200 человек, которая держит агентов продаж или поддержки на AWS Bedrock, это реальное архитектурное решение, а не просто новая модель на пробу. Guardrails, логирование вызовов и кеширование промптов теперь работают на эндпоинте bedrock-runtime - именно его нужно выбирать, если требуется политический периметр вокруг автономного агента и журнал того, что он реально сделал. Но структурированный JSON-вывод и серверный вызов инструментов остаются только на bedrock-mantle, поэтому workflow, зависящий от строгой схемы вывода, придётся строить на другом эндпоинте. Ценообразование добавляет ещё один рычаг: маршрутизация через более дешёвый глобальный кросс-региональный профиль вместо гео-профиля только для США, или переход на уровень обслуживания Flex за половину стандартной ставки для несрочных пакетных задач меняет юнит-экономику агента сильнее, чем сам выбор модели.

  1. AWS удешевила простой в Bedrock AgentCore

    Если ваши агенты поддержки или продаж работают на Bedrock AgentCore, меняются два показателя, которые вы реально отслеживаете: счёт от AWS и время ожидания клиента при пробуждении простаивающего агента. Раньше долго работающий или неравномерно нагруженный агент платил за пиковую память всю сессию, а холодный старт ухудшался по мере роста образа контейнера или конкурентности - серьёзная проблема для агентов, которые большую часть дня молчат и резко активизируются в рабочие часы. Новый runtime тарифицирует ближе к фактическому использованию и держит холодный старт на уровне примерно 2 секунд независимо от размера образа, поэтому команды, запускающие несколько агентов (триаж заявок в поддержке, квалификация лидов, внутренний ассистент для операций), могут спокойно масштабировать их до нуля между запросами без прежнего штрафа по задержке, когда клиент или сотрудник обращается к холодному агенту. Это изменение инфраструктуры, а не новая возможность, но оно снижает стоимость эксплуатации именно того паттерна, который используют большинство компаний на 10-200 человек: несколько узкоспециализированных агентов, которые большую часть времени простаивают.

  1. Bedrock научился кэшировать промпты

    Если ваш чат-бот поддержки, внутренний ассистент по базе знаний или помощник продаж работает на Bedrock и при каждом запросе отправляет один и тот же системный промпт или документацию по продукту — а именно так устроено большинство инструментов на основе retrieval-augmented generation, — это снижает стоимость каждого запроса и ускоряет ответы без изменения самой модели. Командам, автоматизирующим поддержку в большом объёме (сотни или тысячи обращений в день), стоит убедиться, что кэширование применяется автоматически, либо настроить его вручную: AWS отмечает, что эффект максимален, когда значительная часть промпта — например, фрагмент базы знаний или описание инструментов — остаётся неизменной от вызова к вызову. Для компании из 10-200 человек, уже оплачивающей ИИ-поддержку или продажи на Bedrock по токенам, это конкретный рычаг снижения затрат, который стоит проверить в этом квартале, а не откладывать на потом.

  1. SageMaker научился маршрутизировать запросы по кэшу

    Большинство B2B-компаний с 10-200 сотрудниками работают через хостед-API вроде OpenAI или Anthropic, и это обновление их напрямую не касается. Но если ваша поддержка или операционная автоматизация использует самостоятельно размещённую или дообученную модель за SageMaker — что типично при работе с чувствительными данными клиентов, историями тикетов или проприетарными сценариями продаж, которые должны оставаться в вашем VPC — эта маршрутизация даёт бесплатное снижение латентности и затрат. Support-боты и инструменты agent-assist, переиспользующие один и тот же системный промпт для тысяч тикетов в день, получат более быстрый первый токен ответа и меньший расход GPU просто за счёт перехода на новую стратегию маршрутизации, без изменения самих промптов или логики приложения.

  1. AWS научил RAG на Bedrock тратить меньше токенов

    Если бот поддержки, ассистент продаж или внутренний поиск по базе знаний работает через retrieval-augmented конвейер на Bedrock (или аналогичной архитектуре), счёт за токены растёт пропорционально объёму нерелевантного контекста, который попадает в каждый промпт — длинные документы, шаблонный текст и почти дублирующиеся фрагменты, извлечённые «на всякий случай». Query-aware compression решает эту проблему, фильтруя найденные фрагменты по фактическому вопросу перед тем, как они попадут в модель — именно этот рычаг определяет, будет ли AI-ассистент команды поддержки из 20 человек стоить $200 или $2000 в месяц при масштабировании. Команды, уже эксплуатирующие RAG в продакшене, должны воспринимать это как конкретный пункт чек-листа по снижению расходов, а не как задачу на будущее — метод не требует замены модели, только добавления шага сжатия в существующий конвейер от извлечения данных до генерации ответа.

  1. AWS запустил маршрутизацию GPT-5.6 между регионами в Bedrock

    Если ваш чат-бот поддержки, агент квалификации лидов или автоматизация операций вызывает GPT-5.6 через Amazon Bedrock, это снимает реальную операционную головную боль: нехватку мощности в одном регионе, из-за которой ответы теряются или задерживаются в часы пик. Вместо того чтобы писать и поддерживать собственную логику повторных попыток и переключения между регионами, теперь этим занимается сам Bedrock — а значит, меньше ночных звонков дежурному инженеру, когда клиентский AI-сценарий начинает упираться в лимиты. У команд с небольшим штатом (10–200 человек) почти никогда нет свободных инженерных часов на построение собственной инфраструктуры отказоустойчивости, так что перекладывание этой сложности на облачного провайдера — прямой, пусть и скромный, выигрыш в доступности любого AI-конвейера продаж или поддержки, построенного на Bedrock.

  1. Nemotron 3.5 Lightning от NVIDIA стал доступен прямо в SageMaker

    Если ваша команда эксплуатации или инженеры уже работают на AWS, это событие важно не как «вышла новая модель», а как история про закупки и задержки: развёртывание в один клик внутри SageMaker JumpStart снижает издержки на интеграцию быстрой и недорогой модели в чат-боты продаж, сортировку обращений в поддержке или внутреннюю автоматизацию процессов. Для компании из 10-200 человек это разница между двухнедельным инженерным спринтом и работой на полдня, чтобы проверить, справится ли облегчённая модель с маршрутизацией тикетов или квалификацией лидов достаточно хорошо, чтобы заменить более дорогую. Оговорка: это удобство, специфичное именно для AWS, а не универсальный сдвиг возможностей — если вы не на AWS или у вас пока нет инфраструктуры для безопасного A/B-тестирования замены моделей, действовать здесь сегодня особо нечего, кроме как взять на заметку саму опцию.

Следующий шаг

Самодиагностика за 15 минут

Пятнадцать минут, почта не нужна. На выходе - карта того, на что уходит время, и порядок, в котором процессы стоит автоматизировать.

Пройти самодиагностику за 15 минут

Начинается сразу в браузере.

Стоимость
Бесплатно
Срок
15 минут

Список кандидатов по порядку остаётся у вас в любом случае.