Model Profiler от AWS: сравнение моделей Bedrock — гайд 2026 | AiManual
AiManual Logo Ai / Manual.
01 Июл 2026 • Гайд

Model Profiler от AWS: хватит гадать, пора профилировать модели в Bedrock

Open-source инструмент Model Profiler от AWS для объективного выбора модели в Amazon Bedrock. Установка, запуск, разбор метрик и реальные ошибки при профилирова

Реклама
cliv2

Добро пожаловать в зоопарк моделей

Amazon Bedrock к середине 2026 года превратился в настоящий заповедник фундаментальных моделей. Anthropic Claude 4, Meta Llama 4, Amazon Nova (все модификации), Mistral Large, Cohere Command R+ — список тянется бесконечно. И каждый день появляются новые релизы: вот-вот выйдет Claude 4 Opus, а Nova уже обновилась до версии 2.1. Как в этом многообразии выбрать ту самую модель, которая не разорит бюджет и не будет тормозить на проде?

Раньше инженеры собирали информацию по крупицам: тестили одну модель в консоли, потом другую, сравнивали latency в логах CloudWatch, цену считали в калькуляторе. Фрагментированная информация порождала субъективные решения. И тут AWS выпустила Model Profiler — open-source утилиту, которая переворачивает этот процесс. Вжух — и у вас на руках объективные цифры по всем моделям сразу.

💡
Model Profiler — не панацея, а прицел. Он не говорит, какая модель лучше в вакууме. Он показывает, какая модель лучше для вашего датасета, вашего промпта, вашего SLA.

Бенчмаркинг без боли: что внутри коробки?

Model Profiler — это CLI-утилита на Python, которая гоняет одну и ту же задачу (или пайплайн) через разные модели Bedrock и собирает четыре критически важных параметра:

  • Total latency — полное время ответа (сеть + инференс).
  • Time to first token (TTFT) — задержка до первого токена. Критично для чатов.
  • Tokens per second (throughput) — скорость генерации.
  • Cost per 1000 tokens — реальный расход $$$.

Плюс он автоматически суммирует затраты за прогон и выводит таблицу в формате CSV. Можно прогонять как простой текст, так и структурированные промпты (JSON schema). А если у вас есть конкретные требования к выходу — это тоже можно замерить.

Разворачиваем и стреляем: пошаговая настройка

Установка тривиальна, но есть нюанс. Инструмент свежий, поэтому лучше ставить из сорцов, а не через pip (версия в PyPI может отставать).

1Клонируем репозиторий

git clone https://github.com/aws-samples/amazon-bedrock-model-profiler.git
cd amazon-bedrock-model-profiler

2Создаём виртуальное окружение и ставим зависимости

python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt

Не используй boto3 последней версии из PyPI — бери из requirements.txt. Там прописан фикс для новой поддержки потоковой передачи в Bedrock, без него TTFT будет считаться неверно.

3Настройка AWS credentials

Утилита использует ту же цепочку, что и любая AWS SDK. Убедись, что у роли есть права bedrock:InvokeModel на нужные модели. Если планируешь тестировать Anthropic Claude 4 — доступ должен быть отдельно активирован через консоль Bedrock.

4Готовим конфиг

В корне проекта лежит config.yaml. Вот минимальный пример для сравнения Claude 3.5 Haiku и Nova Pro:

models:
  - id: anthropic.claude-3-5-haiku-20241022-v1:0
    region: us-east-1
  - id: amazon.nova-pro-v1:0
    region: us-west-2

prompts:
  - "Explain quantum computing in one paragraph"
  - "Write a Python function to calculate fibonacci numbers"

parameters:
  max_tokens: 512
  temperature: 0.7
  num_iterations: 10  # количество повторений для сглаживания

Параметр num_iterations — твой друг. Ставь не меньше 5, чтобы выкинуть выбросы (сеть могла лагнуть, модель — попасть в throttle).

Запуск: и понеслись

python profiler.py --config config.yaml --output results.csv

Профилирование займёт от пары минут до получаса — зависит от числа моделей и повторов. Результат — CSV с колонками: model_id, prompt_hash, latency_ms, ttft_ms, tokens_per_second, cost_per_1k_tokens.

💡
Совет от практика: сохраняй сырой CSV, а для анализа используй pandas + matplotlib. Инструмент не встроенная визуализация, но можно быстро нарисовать boxplot по latency.

Что означают эти цифры? Интерпретируем правильно

Вот типичная картина после прогона:

МодельLatency (ms)TTFT (ms)Tokens/s$/1M tokens
Claude 3.5 Haiku120030085$2.00
Nova Pro180045055$1.80

На первый взгляд, Haiku выигрывает по скорости. Но если ваш юзкейс — генерация длинных отчётов (1500+ токенов), разница в throughput становится важнее, а стоимость на единицу объёма может оказаться выше у Nova из-за входного контекста. Тут и помогает фреймворк миграции LLM: сначала профилируем, потом принимаем решение, а не наоборот.

Ещё один подвох: Model Profiler считает cost по on-demand цене. Если вы используете Provisioned Throughput — цифры будут другими. Инструмент не знает про ваши скидки и резервы. Это стоит помнить.

Грабли, на которые я наступил (и вы наступите тоже)

За несколько месяцев использования я собрал коллекцию ошибок, которые вылезают у всех.

  • Throttling на стороне Bedrock. Если гнать 10 моделей с 20 итерациями каждая — вы упрётесь в лимит. Решение: разносить по регионам (указывайте разные region для моделей, как в примере выше) или добавить time.sleep(1) между вызовами. Инструмент пока не имеет встроенной backoff-логики.
  • Региональная недоступность. Некоторые модели (например, Llama 4) есть не во всех регионах. Если модель не отвечает — профилировщик падает с AccessDeniedException. Добавьте try-except в код или предварительно проверьте через aws bedrock list-foundation-models.
  • Перекос из-за температуры. Если ставить temperature=0.0 — модель генерирует детерминированно, но latency может быть выше из-за beam search? Не факт. Для сравнения производительности лучите ставить temperature=0.0 и одинаковые параметры. Иначе сравниваете яблоки с апельсинами.
  • Игнорирование network latency. Вы запускаете профилировщик на своей машине, а модель — в us-east-1. Если ваш VPN или интернет нестабилен — latency будет завышен. Лучше запускать на EC2 в том же регионе, что и Bedrock. Или хотя бы рядом.
  • Забыли про structured outputs. Если ваш продакшен использует Structured Outputs, прогоняйте промпты с JSON schema. Model Profiler поддерживает это через поле response_structure в конфиге. Иначе вы профилируете просто текст, а в реале модель может тратить время на форматирование JSON.

Когда Model Profiler НЕ поможет

Давайте честно: этот инструмент — не серебряная пуля. Он бесполезен, если нужно сравнить модели по качеству ответов (accuracy). Для этого существуют eval sets, человеческая оценка и метрики вроде ROUGE, BLEU, MMLU. Model Profiler — про производительность, не про интеллект.

Также он не учитывает вариативность latency в зависимости от размера контекста. Если ваш средний запрос — 2000 токенов, а профилируете на 100 — цифры будут оптимистичнее реальности. Лучше подсовывать репрезентативные промпты из прода.

И ещё: инструмент не поддерживает агентные пайплайны, мультимодальные запросы (изображения + текст) или цепочки вызовов. Для этого придётся писать кастомный скрипт. AWS это обещает в следующих релизах, но на первое июля 2026 — только простые инференсы.

Совет под занавес: не верьте бенчмаркам на слово

Допустим, вы прогнали профилировщик, получили таблицу. На бумаге Claude 3.5 Haiku кажется идеалом: дёшево и быстро. Но ставите его на прод — и через неделю половина ответов не удовлетворяет юзеров. Приходится регрейдить на более дорогую модель. Профилировщик не заменяет A/B-тестирование на реальном трафике.

Поэтому мой workflow такой:

  1. Model Profiler сужает круг до 2-3 кандидатов по стоимости и скорости.
  2. Для каждого кандидата запускаю Reinforcement Fine-Tuning или хотя бы кастомный eval pipeline.
  3. Прокатываю на 10% трафика, собираю метрики качества (user feedback, automated scoring).
  4. Только после этого принимаю окончательное решение.

Model Profiler — отличный первый фильтр, но не последняя инстанция. В 2026 году, когда модели становятся всё более специализированными, подход «trust but verify» актуален как никогда. Пользуйтесь инструментом, но держите руку на пульсе реального продакшена.

Подписаться на канал

←
На главную