# Bedrock, Vertex Model Garden и Foundry: сравнение облачных подходов

Как сравнить Amazon Bedrock, Google Model Garden и Microsoft Foundry по конкретной модели, режиму выполнения, региону, правам и полной стоимости задачи.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/bedrock-vs-vertex-vs-foundry/
Language: ru

Amazon Bedrock, Model Garden в Google Cloud и Microsoft Foundry помогают работать с моделями, но не являются тремя идентичными продуктами. Для выбора нужно установить конкретную модель, способ выполнения и условия окружения. Только после этого имеет смысл сравнивать расходы и работу команды.

Проверка источников выполнена 1 ноября 2026 года. Прежняя ссылка Vertex AI Model Garden ведёт к документации Gemini Enterprise Agent Platform, а Microsoft использует название Foundry Models. Сохраняем знакомые термины для поиска, не выводя из названий одинаковую миграцию всех существующих систем.

## Выберите сравнимую единицу

Начните с прикладной задачи и требований к качеству. Затем найдите подходящую модель в каждом варианте. Если точной общей модели нет, сравнение должно прямо описывать различия и не представлять их как свойства только инфраструктуры.

Сохраните формат входа, длину контекста, инструменты и пределы ответа. Подготовьте одинаковый набор синтетических запросов. Такой подход позволяет увидеть, что реально подтверждено тестом и какую часть результата ещё нельзя переносить на будущую нагрузку.

## Проверьте модель и режим выполнения

[Каталог Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/model-cards.html) служит отправной точкой для сведений о модели. [Google Model Garden](https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/model-garden/explore-models) объединяет поиск и разные пути работы. [Foundry Deployment Overview](https://learn.microsoft.com/en-us/azure/foundry/concepts/deployments-overview) разделяет варианты развёртывания.

Для каждой строки сравнения укажите конкретный режим. Управляемый API, собственное развёртывание весов и выделенный вычислительный ресурс могут различаться по оплате и обязанностям. Не используйте цену одного режима для обоснования бюджета другого.

## Уравняйте окружение и доступ

Проверьте регион, роли приложения, сетевые требования и доступность нужных функций. Карточка каталога и разрешение на рабочий вызов — разные вещи. Тестировать лучше из условий будущего приложения, а не только из административной консоли.

Условный пример: модель подходит по качеству, но нужный способ выполнения недоступен в выбранном окружении. Это не обязательно исключает платформу целиком, но требует нового сценария и оценки. В итоговой таблице ограничение должно быть видно рядом со стоимостью.

## Сравните полный период работы

Для одного варианта значимы использованные единицы API, для другого — время выделенного ресурса и подготовка. Приведите их к одинаковому горизонту и задаче. Добавьте работу по интеграции, наблюдению и смене модели, если она требуется.

Не объявляйте победителя по одному удачному запуску. Сохраните разброс задержек, ошибки и пригодность ответов. Отдельно оцените операционные действия: изменение доступа, разбор проблемы и возврат к прежней конфигурации. Для организации эти процессы могут иметь самостоятельную ценность.

В итоговой таблице оставьте отдельную колонку неизвестных условий. Она позволит не превращать предварительную оценку в утверждение о готовом доступе и покажет, какие действия нужны до производственного использования.

## Где место собственного GPU-пула

Облачные предложения помогают понять альтернативы пользователя и требования к сервису. Они не подтверждают приём любых физических GPU стороннего владельца.

Подготовиться помогут [полная стоимость роутера](/ru/journal/token-router-total-cost/) и [оценка экономики инференса](/ru/journal/inference-unit-economics/).