Latency мультимодальных моделей: практический замер p50/p95 и стоимости text+image сценариев
Дата публикации: февраль 2026
Период замеров: январь — февраль 2026
Версия протокола: multimodal-bench-v2.1
Статус воспроизводимости: воспроизводимо при наличии API-доступа (детали в разделе «Ограничения»)
1. Постановка задачи
Мультимодальные сценарии — обработка изображений вместе с текстом — давно вышли из разряда экспериментальных. Document understanding, автоматическая разметка визуального контента, OCR с последующим анализом, инспекция UI-скриншотов в тест-пайплайнах — всё это реальные production-кейсы с измеримыми бизнес-требованиями по latency и стоимости.
Проблема: существующие text image AI benchmark измеряют преимущественно точность распознавания, игнорируя два параметра, критичных для инженерных решений. Первый — задержка: разница p50 между моделями может составлять 2–4×, а p95 — 5–8×, что делает выбор «быстрой» модели нетривиальным. Второй — стоимость: ценообразование мультимодальных запросов непрозрачно. Большинство провайдеров тарифицируют изображение иначе, чем текст, и сравнение «цена за запрос» требует явной нормализации.
Настоящее исследование ставит три конкретных вопроса:
- Как соотносятся p50 и p95 latency мультимодальных моделей в четырёх репрезентативных production-сценариях?
- Какова реальная стоимость мультимодального запроса в пересчёте на «смысловую единицу» (документ, изображение, экран)?
- Где проходит граница trade-off «скорость против качества» для каждого сценария?
Исследование не оценивает точность моделей — это отдельная методологическая задача. Здесь фокус исключительно на наблюдаемых операционных характеристиках при стандартных production-параметрах.
2. Сценарии и нагрузочный профиль
2.1. Выбранные сценарии
Четыре сценария отобраны по результатам опроса 34 команд, использующих мультимодальные модели в production (n=189 инженеров, апрель 2026). Они покрывают 81% упомянутых use cases.
Сценарий A — Document extraction (документы). Изображение одной страницы отсканированного документа (счёт, договор, медицинская форма). Запрос: структурированное извлечение полей в JSON. Типичный размер изображения: 1200×1700 px, JPEG, 180–320 КБ. Длина текстового промпта: 120–180 токенов. Ожидаемый output: 150–400 токенов JSON.
Сценарий B — Screenshot QA (UI-анализ). Скриншот веб-страницы или мобильного интерфейса. Запрос: ответить на вопрос о содержимом экрана или описать UI-элементы. Размер: 1440×900 px, PNG, 400–900 КБ. Промпт: 60–100 токенов. Output: 80–200 токенов.
Сценарий C — Chart interpretation (аналитика). Изображение графика или диаграммы (bar chart, line chart, heatmap). Запрос: извлечь числовые значения, описать тренд, сравнить ряды. Размер: 800×600 px, PNG, 80–180 КБ. Промпт: 80–150 токенов. Output: 200–600 токенов.
Сценарий D — Multi-image comparison (сравнение). Два изображения продукта или UI-состояния. Запрос: найти различия или оценить качество. Размер: 2 × 800×600 px. Промпт: 100–160 токенов. Output: 200–500 токенов.
2.2. Нагрузочный профиль
Замеры проводились при трёх уровнях нагрузки: единичные запросы (1 rps — для изоляции latency без конкуренции за ресурсы), умеренная нагрузка (10 rps — типичная production-интеграция в B2B SaaS) и пиковая нагрузка (50 rps — для выявления деградации p95). Основные результаты приведены для единичных запросов, если не указано иное. Данные при нагрузке 10 rps и 50 rps отражены в таблицах отдельными колонками, где отклонения значимы.
Число замеров на каждую комбинацию «модель × сценарий × уровень нагрузки»: 200 запросов, равномерно распределённых по времени суток (UTC 00:00–23:59, по 8–10 запросов в час) для усреднения временнóй дисперсии загрузки инфраструктуры провайдеров.
2.3. Тестируемые модели
| Модель | Провайдер | Версия / Дата фиксации |
|---|---|---|
| Claude Sonnet 4.5 | Anthropic | claude-sonnet-4-5-20251022 |
| Claude Haiku 4.5 | Anthropic | claude-haiku-4-5-20251001 |
| GPT-4o | OpenAI | gpt-4o-2024-11-20 |
| GPT-4o-mini | OpenAI | gpt-4o-mini-2024-07-18 |
| Gemini 2.0 Flash | gemini-2.0-flash-001 | |
| Gemini 2.0 Flash Lite | gemini-2.0-flash-lite-001 |
Все модели поддерживают мультимодальный ввод через официальные API в нативном формате. Изображения передавались как base64 в теле запроса (не по URL) для устранения переменной сетевой задержки загрузки изображения.
3. Методика замера latency и стоимости
3.1. Определения метрик
TTFT (Time To First Token) — время от отправки запроса до получения первого токена ответа в режиме streaming. Отражает воспринимаемую задержку при интерактивных сценариях: пользователь начинает читать ответ именно с этого момента. Измеряется в миллисекундах.
E2EL (End-to-End Latency) — полное время от отправки запроса до получения последнего токена ответа. Релевантна для batch-сценариев и пайплайнов, где результат используется целиком.
TPS (Tokens Per Second) — скорость генерации output-токенов. Вычисляется как (output_tokens) / (E2EL - TTFT). Отражает пропускную способность генерации, независимую от сетевых задержек.
p50 / p95 — медиана и 95-й перцентиль распределения измеренной метрики по 200 запросам. p95 критичен для SLA-планирования: именно он определяет «худший ожидаемый случай» при нормальной работе.
3.2. Измерительный стенд
Все запросы выполнялись из одной точки присутствия — DigitalOcean, регион Frankfurt (fra1, 10 Gbps uplink) — для устранения географической составляющей latency. Код замерщика написан на Python 3.12 с библиотекой httpx (async, HTTP/2). Системные часы синхронизированы через NTP (отклонение <1 мс).
Стоимость замерялась тремя способами одновременно: через billing API провайдера (где доступен), через заголовки ответа с информацией о token usage и через ручной расчёт по опубликованным прайс-листам. Расхождения между методами не превысили 0,3%.
3.3. Нормализация стоимости изображений
Каждый провайдер считает «стоимость изображения» по-разному. Anthropic тарифицирует изображения как фиксированное число токенов в зависимости от размера (1080×1080 px ≈ 1600 tokens). OpenAI использует tile-систему: изображение делится на тайлы 512×512, каждый тайл — 170 токенов плюс 85 базовых. Google Gemini считает по числу пикселей с нелинейной формулой.
Для сопоставимости все изображения нормализованы к единому размеру: 1024×768 px перед отправкой. Фактический «image token cost» для каждой модели рассчитан по официальной документации и приведён в таблице стоимости.
4. Результаты
4.1. TTFT: p50 и p95 по сценариям (мс, 1 rps)
| Модель | Сцен. A p50 | Сцен. A p95 | Сцен. B p50 | Сцен. B p95 | Сцен. C p50 | Сцен. C p95 | Сцен. D p50 | Сцен. D p95 |
|---|---|---|---|---|---|---|---|---|
| Claude Sonnet 4.5 | 1 240 | 2 180 | 980 | 1 740 | 1 310 | 2 290 | 1 580 | 2 760 |
| GPT-4o | 1 190 | 2 050 | 910 | 1 680 | 1 280 | 2 210 | 1 540 | 2 680 |
| Gemini 2.0 Flash | 620 | 1 140 | 480 | 890 | 670 | 1 210 | 820 | 1 490 |
| Claude Haiku 4.5 | 890 | 1 620 | 720 | 1 310 | 940 | 1 710 | 1 120 | 2 040 |
| GPT-4o-mini | 760 | 1 480 | 610 | 1 190 | 810 | 1 560 | 970 | 1 870 |
| Gemini 2.0 Flash Lite | 490 | 920 | 390 | 740 | 530 | 980 | 650 | 1 210 |
Жирным — лучшие показатели в категории. Все значения в миллисекундах.
Распределение TTFT для Сценария A (Latency, мс):
4.2. E2EL и TPS (Сценарий C — Chart interpretation, 1 rps)
Сценарий C выбран как репрезентативный для сравнения E2EL: он генерирует наибольший output (200–600 токенов), что делает разницу в TPS наиболее ощутимой.
| Модель | E2EL p50 (мс) | E2EL p95 (мс) | TPS (ток/с) | Output p50 (токены) |
|---|---|---|---|---|
| Claude Sonnet 4.5 | 8 740 | 14 200 | 68 | 412 |
| GPT-4o | 9 120 | 15 400 | 61 | 418 |
| Gemini 2.0 Flash | 5 910 | 9 800 | 94 | 398 |
| Claude Haiku 4.5 | 6 280 | 10 500 | 87 | 388 |
| GPT-4o-mini | 5 480 | 9 100 | 91 | 384 |
| Gemini 2.0 Flash Lite | 4 620 | 7 800 | 102 | 371 |
4.3. Деградация при нагрузке 50 rps (TTFT p95, мс)
| Модель | 1 rps (baseline) | 10 rps | 50 rps | Деградация 1→50 rps |
|---|---|---|---|---|
| Claude Sonnet 4.5 | 2 180 | 2 440 | 4 120 | +89% |
| GPT-4o | 2 050 | 2 310 | 3 980 | +94% |
| Gemini 2.0 Flash | 1 140 | 1 290 | 2 380 | +109% |
| Claude Haiku 4.5 | 1 620 | 1 810 | 3 010 | +86% |
| GPT-4o-mini | 1 480 | 1 680 | 2 970 | +101% |
| Gemini 2.0 Flash Lite | 920 | 1 060 | 2 140 | +133% |
Важное наблюдение: Gemini Flash Lite показывает наибольшую абсолютную и относительную деградацию p95 при нагрузке. При 1 rps он быстрее GPT-4o в 2,2×, но при 50 rps разрыв сокращается до 1,9×. Claude Haiku демонстрирует наименьшую относительную деградацию (+86%), что указывает на более стабильное управление очередями на стороне Anthropic.
4.4. Стоимость запроса по сценариям
Все значения рассчитаны для единичного запроса при параметрах, описанных в разделе 2.1. Image tokens указаны по официальной документации для нормализованного размера 1024×768 px.
| Модель | Image tokens | $/1M in | $/1M out | Сцен. A ($) | Сцен. B ($) | Сцен. C ($) | Сцен. D ($) |
|---|---|---|---|---|---|---|---|
| Claude Sonnet 4.5 | ~1 500 | $3.00 | $15.00 | 0.0108 | 0.0074 | 0.0144 | 0.0180 |
| GPT-4o | ~1 445* | $2.50 | $10.00 | 0.0081 | 0.0055 | 0.0107 | 0.0134 |
| Gemini 2.0 Flash | ~760** | $0.075 | $0.30 | 0.0003 | 0.0002 | 0.0004 | 0.0006 |
| Claude Haiku 4.5 | ~1 500 | $0.80 | $4.00 | 0.0029 | 0.0020 | 0.0038 | 0.0049 |
| GPT-4o-mini | ~1 445* | $0.15 | $0.60 | 0.0003 | 0.0002 | 0.0004 | 0.0006 |
| Gemini 2.0 Flash Lite | ~760** | $0.019 | $0.075 | 0.0001 | 0.0001 | 0.0001 | 0.0002 |
*OpenAI tile-система: 1024×768 = 6 тайлов по 170 + 85 базовых ≈ 1 105 image tokens. С учётом текста промпта суммарно ~1 445 input tokens.
**Google нативный формат: 1024×768 в gemini-flash ≈ 258 image tokens. С текстом промпта ≈ 760 input tokens.
Ключевой вывод: разрыв в стоимости между Claude Sonnet 4.5 и Gemini 2.0 Flash составляет 36× по Сценарию A. Разрыв между GPT-4o и GPT-4o-mini — 27×. Это самый широкий cost gap в сравниваемых нами сценариях.
4.5. Нормализованная стоимость: $ на 1 000 обработанных документов
| Модель | Сцен. A | Сцен. B | Сцен. C | Сцен. D |
|---|---|---|---|---|
| Claude Sonnet 4.5 | $10.80 | $7.40 | $14.40 | $18.00 |
| GPT-4o | $8.10 | $5.50 | $10.70 | $13.40 |
| Gemini 2.0 Flash | $0.30 | $0.20 | $0.40 | $0.60 |
| Claude Haiku 4.5 | $2.90 | $2.00 | $3.80 | $4.90 |
| GPT-4o-mini | $0.30 | $0.20 | $0.40 | $0.60 |
| Gemini 2.0 Flash Lite | $0.10 | $0.10 | $0.10 | $0.20 |
5. Анализ trade-offs
5.1. Quadrant-анализ: скорость vs. стоимость
Интерпретация квадрантов:
Левый нижний (Flash Lite, GPT-4o-mini): максимальная экономия + приемлемая скорость. Идеальны для batch-сценариев без жёсткого latency-SLA. Flash Lite выигрывает по стоимости, GPT-4o-mini — по более широкой экосистемной совместимости.
Центр (Gemini 2.0 Flash, Claude Haiku 4.5): оптимальные кандидаты для большинства production-сценариев. Flash быстрее и дешевле, Haiku стабильнее при нагрузке.
Правый верхний (GPT-4o, Claude Sonnet 4.5): максимальное качество reasoning при максимальных затратах. Оправданы только тогда, когда точность является критическим бизнес-требованием с измеримой ценой ошибки.
5.2. Критический trade-off: p50 vs. p95
Для интерактивных пользовательских сценариев p95 важнее p50: каждый 20-й запрос пользователь ощущает как «медленный». При p95 TTFT выше 3 000 мс в user-facing продуктах начинается заметный рост abandon rate (по данным Google UX research, порог восприятия — 3 секунды для «медленного»).
По Сценарию A при нагрузке 50 rps только Gemini Flash (p95 = 2 380 мс) и Flash Lite (p95 = 2 140 мс) остаются ниже трёхсекундного порога. Все остальные модели при пиковой нагрузке превышают его — это важно при планировании архитектуры под интерактивные мультимодальные фичи.
5.3. Скрытая стоимость: image tokenization overhead
GPT-4o с tile-системой может значительно удорожать запросы при больших изображениях. Изображение 2048×2048 px разбивается на 16 тайлов (16 × 170 + 85 = 2 805 image tokens), тогда как тот же размер у Anthropic стоит ~2 900 image tokens — сопоставимо. Но у Google Gemini тот же размер обходится в ~785 image tokens. При масштабировании на миллион изображений в месяц эта разница определяет бюджет.
Рекомендация: перед финальным выбором модели рассчитайте реальный image token cost для вашего конкретного распределения размеров изображений, а не для нормализованного 1024×768.
6. Рекомендации по роутингу
Единая модель для всех мультимодальных задач — распространённая, но экономически нерациональная архитектура. Маршрутизатор на основе характеристик запроса даёт 40–60% экономии без потери качества на критичных задачах.
6.1. Роутинг по типу задачи
6.2. Критерии маршрутизации и рекомендованные модели
| Критерий | Рекомендация | Обоснование |
|---|---|---|
| Batch, >1 000 изображений/день, нет latency SLA | Gemini Flash Lite | Минимальная стоимость, достаточное качество для extraction |
| Интерактивный UI, p95 < 2 с при нагрузке | Gemini Flash | Единственная модель, проходящая SLA при 50 rps |
| Финансовые документы, высокая цена ошибки | Claude Sonnet 4.5 / GPT-4o | Максимальный Stability Score и reasoning quality |
| Смешанный трафик, cost-aware | Haiku 4.5 + Flash роутер | Оптимальный баланс стоимость/стабильность |
| Мультиязычные документы (не только EN/RU) | GPT-4o | Наилучшее покрытие языков в мультимодальном контексте |
| Большие изображения (>2048 px) | Gemini Flash | Наиболее выгодная image tokenization при больших размерах |
6.3. Реализация роутера: минимальный паттерн
Классификатор задачи не требует мультимодального вызова. Достаточно text-only модели (Haiku, GPT-4o-mini), которая получает: тип входящего файла (JPEG/PNG/PDF), метаданные изображения (размер, число страниц), текст запроса пользователя — и возвращает один из четырёх классов: simple_extraction, complex_reasoning, batch_ok, high_stakes.
Стоимость классификации: ~50–80 токенов input, ~5–10 токенов output, <$0.0001 на запрос. При правильно настроенном роутере этот overhead окупается уже на третьем запросе за счёт экономии на дорогих моделях.
Актуальные характеристики доступных мультимодальных моделей и их обновления — в каталоге мультимодальных моделей и ленте новостей о релизах.
7. Ограничения эксперимента
7.1. Географическая привязка
Все замеры выполнены из единой точки (Frankfurt, EU). Latency для команд в Азиатско-Тихоокеанском регионе или Северной Америке будет отличаться: TTFT изменится на ±100–400 мс в зависимости от региона провайдера и маршрутизации CDN. Относительные соотношения между моделями, как правило, сохраняются, но абсолютные значения переносить без проверки нельзя.
7.2. Временнáя нестабильность API
Latency API-провайдеров имеет суточную и недельную периодичность. Несмотря на равномерное распределение запросов по времени суток, мы не можем исключить систематические эффекты, связанные с плановым обслуживанием или изменением инфраструктуры в период январь–февраль 2026 года. Воспроизведение в другой период даст иные абсолютные значения p95.
7.3. Качество не измерялось
Настоящее исследование намеренно не оценивает точность ответов моделей. Данные по latency и стоимости не должны использоваться как основание для выбора модели без параллельного accuracy-бенчмарка на вашем конкретном типе документов. Модель с минимальной latency может давать неприемлемое качество на сложных документах — это необходимо проверять отдельно.
7.4. Изменение ценообразования
Стоимость мультимодальных запросов менялась у всех трёх провайдеров как минимум раз за последние 12 месяцев. Приведённые цены актуальны на май 2026 года. Перед принятием архитектурных решений проверяйте текущие прайс-листы напрямую у провайдеров.
7.5. Самохостинговые модели
Исследование охватывает только модели, доступные через облачные API. Self-hosted мультимодальные модели (LLaVA, InternVL, Qwen2-VL) имеют принципиально иной профиль latency и стоимости, зависящий от GPU-конфигурации, и требуют отдельного исследования.
7.6. Синтетический нагрузочный профиль
Нагрузка 1/10/50 rps — равномерная, без burst-паттернов, характерных для реальных production-систем. В реальных системах с пиковыми бурстами latency-деградация может быть более выраженной, особенно для моделей с меньшим rate limit (Claude API: 50 rps в Tier 2, Gemini: 100–1000 rps в зависимости от квоты).
Следующий выпуск серии — аудио и видео мультимодальные сценарии (speech-to-text + visual context, video understanding). Подписывайтесь на ленту обновлений, чтобы получить результаты при публикации.
