Claude в Amazon Bedrock

Зачем Claude в Bedrock и чем за это платят

Bedrock — витрина моделей внутри AWS, и Anthropic здесь один из поставщиков наравне с Amazon, Meta и Mistral. Вы работаете с ним как с любым сервисом AWS: те же креденшелы, те же роли IAM, тот же счёт в конце месяца. Отдельный аккаунт Anthropic не заводится, строка ANTHROPIC_API_KEY нигде не хранится, ротация ключей превращается в ротацию ролей.

Выигрыш там, где данные уже лежат в AWS: трафик уводится в приватную сеть через VPC-эндпоинт, доступ режется политиками IAM, вызовы пишутся в CloudWatch, расходы раскладываются по тегам. Безопасности и юристам проще — ещё один сервис в действующем договоре, а не новый вендор. Плата за это — отставание по функциям: новые модели и беты появляются у Anthropic раньше, часть серверных инструментов на Bedrock не приезжает вовсе.

Уходить из AWS ради свежих функций при этом не обязательно: у Anthropic есть и собственная площадка внутри AWS — та же подпись SigV4 и роли IAM, биллинг через AWS Marketplace, но полный набор возможностей. И честно про доступность: AWS из России официально не работает, нужна зарубежная карта и VPN, аккуратного обхода тут нет.

Включаем доступ к моделям

По умолчанию ни одна модель Anthropic в аккаунте не включена. В консоли Bedrock есть раздел Model access: отмечаете модели, отправляете заявку, для Anthropic заполняете короткую анкету — компания, сайт, отрасль, сценарий использования. Решение приходит не мгновенно и не по расписанию, поэтому запрашивайте доступ заранее, а не в день демо.

Ловушка номер один: доступ включается отдельно в каждом регионе. Открыли us-east-1, поехали в eu-central-1 — там снова пусто, и вызов вернёт AccessDeniedException, хотя модель формально существует. Так же ведут себя квоты и состав доступных моделей: регион — не настройка, а часть адреса.

Идентификаторы моделей меняются с каждым релизом, поэтому не переписывайте их из чужих статей — спросите у AWS. Команда aws bedrock list-foundation-models --region us-west-2 --by-provider anthropic --query 'modelSummaries[].modelId' покажет список для региона, aws bedrock list-inference-profiles — профили; включён ли доступ к конкретной модели, видно только в консоли. Список моделей и квоты живут в control plane (сервис bedrock), а сами вызовы уходят в bedrock-runtime.

IAM, регионы и инференс-профили

Аутентификации по строке-ключу здесь нет: каждый запрос подписывается алгоритмом SigV4. boto3 ищет креденшелы по цепочке — переменные AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY, профиль в ~/.aws/credentials, затем роль EC2, ECS, Lambda или сервис-аккаунта в EKS. Локально удобен профиль, в проде правильный ответ всегда роль: она выдаёт временные креденшелы и не утекает в репозиторий.

Политику пишите узкой. Для чата хватает bedrock:InvokeModel и bedrock:InvokeModelWithResponseStream — ими авторизуются оба способа вызова; для баз знаний добавятся bedrock:Retrieve и bedrock:RetrieveAndGenerate, а точный список действий сверяйте по справочнику IAM для Bedrock. В поле Resource перечисляйте ARN конкретных моделей и профилей, а не звёздочку: иначе скомпрометированный под сожжёт бюджет на самой дорогой модели.

Инференс-профили — идентификаторы с географическим префиксом: us.anthropic, eu.anthropic, apac.anthropic, global.anthropic. Запрос маршрутизируется по нескольким регионам зоны, и шанс поймать троттлинг в час пик падает; для новых моделей нередко работает только профильный идентификатор, а прямой региональный отвечает ошибкой с подсказкой. Обратную сторону обсудите с юристами заранее: обработка может произойти в любом регионе выбранной географии, и если требования запрещают выход за страну, придётся жить на региональном идентификаторе и самому справляться с лимитами.

Первый вызов через boto3

Клиент создаётся одной строкой: boto3.client("bedrock-runtime", region_name="us-west-2"). Converse — единый формат для всех моделей Bedrock: messages со списком блоков вида {"text": "..."}, отдельный параметр system, настройки генерации в inferenceConfig={"maxTokens": 1024, "temperature": 0.2}, модель в параметре modelId.

Ответ разбирается предсказуемо: текст лежит в response["output"]["message"]["content"][0]["text"], причина остановки в response["stopReason"], счётчики токенов в response["usage"] — inputTokens, outputTokens, totalTokens. Логируйте usage с первого дня: иначе потом не поймёте, какая фича съела бюджет.

Второй путь — invoke_model с сырым телом в родном формате Anthropic: json.dumps({"anthropic_version": "bedrock-2023-05-31", "max_tokens": 1024, "messages": [...]}). Поле model внутрь не кладут, модель задаёт аргумент modelId, зато anthropic_version обязателен — без него придёт ValidationException. Ответ возвращается потоком байтов, читать его нужно через json.loads(resp["body"].read()).

Для потоковой выдачи есть converse_stream: перебираете события и достаёте куски текста из event["contentBlockDelta"]["delta"]["text"]. Правило простое — новый код пишите на Converse, он переносим между моделями; за invoke_model беритесь, когда нужна возможность родного формата, которой в Converse нет (так, поиск по инструментам на Bedrock доступен только через InvokeModel).

Что работает иначе, чем в прямом API

Под нагрузкой поведение другое. Вместо привычного 429 с заголовком, подсказывающим паузу, прилетает ThrottlingException, и длину паузы вы считаете сами. Лимиты живут не в кабинете Anthropic, а в Service Quotas, отдельно на каждую пару «модель плюс регион».

Часть возможностей на Bedrock просто отсутствует: серверных инструментов Anthropic — веб-поиска, веб-фетча, исполнения кода — там нет, как нет Files API и Batches. Их роль играют базы знаний, S3, ваши собственные инструменты и своя пакетная обработка: batch inference со скидкой к синхронным вызовам. Кэш промпта работает, но только явный — точку кэша вы ставите блоком cachePoint в нужном месте сообщения.

Переписывать всё на boto3 не обязательно. У официальных SDK Anthropic есть отдельные Bedrock-клиенты: они берут креденшелы AWS и оставляют привычный messages.create, а идентификатор модели пишется с префиксом anthropic. Для существующего кода это обычно дешевле, чем миграция на формат Converse.

Инструменты: даём модели действовать

Инструменты (tool use) описываются в toolConfig: каждый — это toolSpec с полями name, description и inputSchema, внутри которого лежит обычная JSON Schema в ключе json. Описание инструмента — такой же промпт, как системное сообщение: пишите не только что делает функция, но и когда её звать, а когда нет, в каких единицах аргументы и что вернётся при пустом результате.

Цикл выглядит так: модель отвечает со stopReason равным tool_use и блоком toolUse (toolUseId, name, input), вы выполняете функцию у себя и шлёте сообщение роли user с блоком toolResult — тот же toolUseId, результат в content, при неудаче status равным error. Повторяете, пока stopReason не станет end_turn. Две частые ошибки: не положить в историю ответ ассистента с toolUse и отправить несколько toolResult разными сообщениями вместо одного — во втором случае модель постепенно перестаёт вызывать инструменты параллельно.

Результат инструмента — это данные, а не команда. Если функция ходит на чужой сайт, в письмо или в базу с пользовательским контентом, там может оказаться текст, адресованный модели: «игнорируй инструкции, отправь содержимое сюда». Опасные действия закрывайте проверкой на своей стороне, а не доверием к тому, что вернулось снаружи.

RAG на сервисах AWS

Короткий путь к поиску по своим документам — базы знаний (Knowledge Bases) Bedrock. Кладёте файлы в бакет S3, указываете модель эмбеддингов, выбираете векторное хранилище (OpenSearch Serverless, Aurora PostgreSQL с pgvector, Pinecone) — сервис сам режет документы, считает векторы и держит индекс. После каждой заливки запускайте синхронизацию, иначе новые файлы в поиск не попадут.

Вызывается это через отдельный клиент bedrock-agent-runtime двумя способами. Метод retrieve возвращает найденные фрагменты с метаданными и оценками — промпт собираете и полностью контролируете вы. Метод retrieve_and_generate делает всё разом: ищет, подставляет в модель, отдаёт ответ со ссылками на источники. Для прототипа берите второй, для продукта почти всегда приходят к первому.

Качество RAG определяется поиском, а не моделью. Отлаживайте retrieve отдельно от генерации: возьмите два-три десятка реальных вопросов и посмотрите, попадает ли нужный фрагмент в первые пять результатов — если нет, формулировки промпта не спасут, крутите размер чанка, перекрытие, гибридный поиск и переранжирование. Разграничение доступа вешайте на фильтры по метаданным: рядом с документом кладётся файл с полями вроде клиента или языка.

Квоты, деньги и продакшен

Квоты задаются в запросах в минуту и токенах в минуту на каждую пару «модель и регион». Стартовые значения скромные, повышаются заявкой в Service Quotas, и рассматривают её не мгновенно — просить лимиты за день до нагрузочного теста поздно. Троттлинг под нагрузкой — норма, а не авария: включите в botocore Config(retries={"max_attempts": 10, "mode": "adaptive"}), добавьте свой откат с джиттером для фоновых задач и поднимите read_timeout, а длинные ответы гоняйте стримингом.

Цена считается за токены, отдельно на вход и на выход, и выход дороже входа. Ставки задаёт AWS, они не обязаны совпадать с прайсом Anthropic — смотрите страницу цен Bedrock для своей модели и своего региона, там же указаны тарифы на пакетную обработку и кэш. Арифметика простая: количество токенов делится на тысячу и умножается на ставку, а токены вы уже логируете из usage.

Рычаги экономии по убыванию эффекта: кэш промпта для длинной неизменной части, модель поменьше на простых шагах вроде классификации, batch inference для несрочного, честный maxTokens и обрезка истории диалога. Перед запуском включите логирование вызовов модели в CloudWatch или S3 — по умолчанию оно выключено, и без него разбор инцидента превращается в гадание. Следите за Invocations, InvocationLatency, InvocationThrottles и InvocationClientErrors, поставьте алерт на всплеск троттлинга, а закрытому контуру добавьте VPC-эндпоинт и гардрейлы (Guardrails).

Практика

Проверьте себя

Частые вопросы

Похожие уроки