Как считать стоимость vision-запроса с изображениями и текстом

Vision-функция редко разоряет продукт ценой одной картинки. Деньги уходят иначе: команда берёт фото в исходном разрешении, посылает его в каждом ходе диалога, добавляет все кадры ролика «на всякий случай», а затем пытается объяснить финансовому отделу счёт средним значением цены запроса.

Стоимость vision-запроса надо считать как составной расход, а не как цену файла. Изображение становится токенами или отдельной биллинговой единицей, текст рядом с ним остаётся текстом, ответ модели имеет свою цену, а OCR, поиск, генерация изображений и повторные попытки могут жить в счёте отдельными строками. Хорошая модель бюджета показывает, что именно изменится, если фотография станет вдвое больше, ролик даст больше кадров или пользователь попросит «прочитать всё мелким шрифтом».

Цена файла и цена понимания изображения не совпадают

Размер JPEG в мегабайтах почти ничего не говорит о цене анализа. Он влияет на передачу по сети, лимиты тела запроса, время загрузки и объём технических журналов. Провайдер же обычно декодирует картинку, может уменьшить её, разбить на участки или перевести во внутреннее представление, после чего выставляет счёт за токены, изображения, мегапиксели либо фиксированные уровни качества.

Это различие часто пропускают при проектировании. Команда уменьшает качество JPEG с 90 до 60, видит падение размера файла на диске и ожидает такой же экономии на API. Если ширина и высота остались прежними, внутренняя схема тарификации может вообще не измениться. И наоборот, уменьшение длинной стороны с 4000 до 1600 пикселей обычно меняет расход заметнее, даже если файл сжат неидеально.

Есть четыре величины, которые надо хранить для каждого изображения:

• ширина и высота после всех преобразований;
• формат и размер передаваемого файла;
• выбранный режим детализации или качества;
• фактическое usage из ответа провайдера.

Первые три нужны, чтобы объяснить расход до отправки. Четвёртая величина нужна, чтобы не жить на догадках после запуска.

Документация Google Gemini прямо относит изображения к токенизируемому входу вместе с текстом и другими модальностями. Документация Anthropic Vision даёт приближение для изображений, которые не требуют масштабирования: число токенов примерно равно ширине, умноженной на высоту, делённым на 750. Это полезная инженерная оценка, но не универсальная формула для всех моделей. Нельзя переносить её на другой API и подписывать как точный счёт.

Сначала разделите расходы на пять корзин

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

Общая оценка на один вызов выглядит так:

C = C_text_in + C_image + C_text_out + C_tools + C_transport + C_retry

Здесь C_text_in включает системную инструкцию, пользовательский текст, историю и результаты инструментов, если вы возвращаете их модели. C_image покрывает картинки, страницы и кадры. C_text_out включает ответ, в том числе JSON, объяснения и рассуждения, если выбранная модель их тарифицирует как выход. C_tools нужен для платного OCR, веб-поиска, генерации изображений или иных серверных действий. C_transport обычно не входит в счёт LLM, но входит в ваш бюджет на хранение, исходящий трафик и журналы. C_retry отражает повторы из-за тайм-аутов, ошибок валидации, ограничений скорости и неуверенных результатов.

Для месячного прогноза не умножайте одну среднюю цену на число вызовов. Используйте распределение классов запросов:

C_month = Σ (N_class × C_class) + C_fixed

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

C_fixed включает очередь, хранилище, мониторинг, прокси, подготовку изображений и работу команды по разбору ошибок. На малом объёме эти расходы могут быть больше платы за токены. На большом объёме они обычно уступают API, но не исчезают.

Разрешение надо выбирать по мелкому объекту, а не по исходнику

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

Плохая практика выглядит знакомо: мобильное приложение загружает фотографию 4032×3024, потому что так сняла камера. Затем сервер пересылает её как есть, хотя модель должна определить только тип товара. Число пикселей здесь примерно в десять раз выше, чем у 1280×960. При токенизации, близкой к пропорциональной площади, счёт растёт почти в той же пропорции, а точность классификации меняется слабо.

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

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

Потом привяжите размер к классу задачи:

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

Текст рядом с картинкой часто дороже, чем кажется

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

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

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

Пример внутреннего объекта после первого анализа:

{
  "asset_id": "receipt_8f2c",
  "transform_version": "resize-1600-v3",
  "vision_result": {
    "merchant": "...",
    "date": "...",
    "total": "...",
    "currency": "...",
    "uncertain_fields": ["merchant"]
  },
  "needs_original_image": false
}

Этот объект не заменяет исходное изображение навсегда. Он предотвращает его автоматическую повторную отправку. Если пользователь спрашивает о плохо читаемой строке, система может открыть исходник, вырезать область с этой строкой и провести отдельный дорогой запрос. Это честнее, чем оплачивать весь кадр на каждом ходе «на всякий случай».

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

OCR и vision решают разные части задачи

Рекомендация «всегда используйте LLM для OCR» популярна, потому что один вызов кажется проще: картинка вошла, JSON вышел. Для демо это удобно. Для потока счетов, анкет, накладных и медицинских бланков такой выбор часто создаёт лишние расходы и ухудшает управляемость.

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

Практичная схема для документов выглядит так:

1. Подготовить страницу: повернуть, убрать пустые поля, ограничить максимальный размер, сохранить версию преобразования.
2. Пропустить специализированный OCR или встроенный документный разбор, если он нужен для массового извлечения текста.
3. Передать в LLM извлечённый текст, геометрию полей и только те вырезки, где OCR неуверен или где нужен визуальный контекст.
4. Отправить на ручную проверку записи, которые нарушают правила или имеют низкую уверенность.

Такой конвейер даёт два преимущества. Во-первых, вы измеряете ошибку распознавания отдельно от ошибки интерпретации. Во-вторых, большая часть страниц не требует дорогого multimodal-вызова на полном изображении.

Есть случаи, когда полная страница нужна сразу. Печати, подписи, нестандартная верстка, таблицы со сложными связями, рукописные пометки, подмена документа и проверка визуального соответствия товара требуют именно изображения. Но даже здесь не путайте «нужна страница» с «нужно исходное разрешение с камеры».

Отдельно учитывайте PDF. Текстовый PDF может дать извлекаемый текст без визуального рендеринга каждой страницы. Сканированный PDF чаще превращается в набор изображений и может задействовать OCR. Некоторые платформы тарифицируют страницы документа по правилам, близким к изображениям. В документации Gemini, например, токены модальности DOCUMENT для PDF считаются по ставке image tokens. Это причина вести PDF отдельным классом расходов, а не прятать его среди обычных картинок.

Видео надо считать кадрами, а не длительностью файла

Vision-модель не получает «видео» как магическое целое. В зависимости от API она видит выборку кадров, внутреннее представление ролика или последовательность изображений. Поэтому длительность в секундах сама по себе не даёт цену. Для бюджета нужны частота выборки, разрешение каждого кадра, число повторных проходов и условие, при котором обработка заканчивается.

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

Сначала запишите событие, которое ищете. Затем задайте стратегию выборки:

• редкая равномерная выборка для поиска участка интереса;
• более частые кадры только в найденном временном окне;
• остановка после уверенного обнаружения события;
• отдельный путь для роликов, где модель не уверена.

Допустим, камера снимает десятиминутный ролик. Первый проход берёт кадр раз в пять секунд. Если модель находит вероятный участок, второй проход анализирует только минуту вокруг него с более высокой частотой. Это не «двухэтапная оптимизация» ради красивого названия. Это способ не платить за подробный анализ девяти минут, где ничего не происходит.

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

Тарифную единицу провайдера нельзя угадывать по названию модели

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

Документация OpenRouter для image generation хорошо показывает, почему нужен нормализатор: в данных endpoint могут присутствовать поля billable, unit, cost_usd и вариант тарифа для уровня разрешения. Единицей может быть image, megapixel или token. Для понимания изображений ситуация тоже зависит от конкретной модели и провайдера. Нельзя хранить только поле price_per_1m_tokens и считать, что этим покрыты все маршруты.

Внутри биллинга заведите явную таблицу тарифных правил:

{
  "route": "vision-route-a",
  "billing_unit": "input_token",
  "input_rate": "provider tariff",
  "output_rate": "provider tariff",
  "image_policy": "reported_in_prompt_usage",
  "detail_modes": ["low", "high"],
  "effective_from": "provider price version"
}

Для маршрута с фиксированной ценой за картинку замените billing_unit на image и храните тариф по разрешению либо качеству. Для маршрута с мегапикселями сохраните правило округления. Округление важно: цена за 1,01 мегапикселя может считаться иначе, чем за 1,00, а ваша предварительная оценка обязана это отражать.

Не зашивайте ставки в код приложения. Цены, линейки моделей и правила тарификации меняются. Конфигурация тарифа должна иметь версию и дату вступления в силу, а расчёт в журнале должен ссылаться на эту версию. Тогда спустя квартал вы сможете объяснить, почему один и тот же сценарий в разные месяцы стоил по-разному.

Формула бюджета должна содержать верхнюю границу

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

Для каждого класса запроса задайте три режима.

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

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

images_per_request = 2
image_tokens_per_image = measured_p90
text_input_tokens = measured_p90
text_output_tokens = response_cap
retry_rate = observed_retry_rate

request_cost = (
  images_per_request * image_tokens_per_image * input_rate +
  text_input_tokens * input_rate +
  text_output_tokens * output_rate +
  tool_cost
) * (1 + retry_rate)

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

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

Usage из ответа важнее калькулятора в презентации

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

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

{
  "request_id": "req_01",
  "tenant_id": "tenant_42",
  "route": "vision-route-a",
  "model": "selected-model",
  "provider": "selected-provider",
  "input_text_tokens": 812,
  "input_image_tokens": 1540,
  "output_tokens": 247,
  "image_count": 2,
  "frames_sampled": 0,
  "source_pixels": 2419200,
  "transform_version": "resize-1600-v3",
  "attempt": 1,
  "status": "success",
  "tariff_version": "2026-07"
}

Поля зависят от API, поэтому часть значений иногда будет null. Это нормально. Не нормально смешивать неизвестные токены с нулевыми. Ноль означает, что расхода не было. null означает, что вы его не наблюдали.

Постройте отчёт по четырём срезам: класс задачи, маршрут, размер изображения и причина повтора. Через несколько дней станет видно, где расход меняется. Обычно виноват не «рост цен на AI», а один из простых дефектов: новая версия клиента перестала уменьшать фото, очередь повторяет успешные запросы после обрыва соединения, JSON-ответ разросся, либо команда включила дорогой режим для всех задач.

AI Router может быть точкой, где такие правила учёта живут независимо от SDK приложения: совместимый OpenAI API позволяет не переписывать клиент при смене маршрута, а аудит-логи и rate limits на уровне ключа помогают отделить расход разных команд и сценариев. Для бюджета это полезно только если вы всё равно записываете размеры, классы задач и фактическое usage, а не смотрите на один общий счёт.

Экономить надо после измерения качества, а не до него

Самая плохая экономия в vision-системах выглядит так: команда без проверки уменьшает все изображения, отрезает поля, ограничивает ответ десятком токенов и переключает поток на дешёвую модель. Счёт падает. Затем незаметно растёт доля неверно прочитанных сумм, пропущенных дефектов и ручных исправлений. Через месяц оказывается, что API был самой дешёвой частью процесса.

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

Стоимость и качество надо смотреть в одной таблице. Если уменьшение длинной стороны сократило расход на 45 процентов, а доля ошибок выросла лишь на допустимую величину, решение принято. Если экономия составляет несколько процентов, но операторов стало больше, решение плохое, даже если график API-расходов радует.

Начните не с выбора самой дешёвой модели. Возьмите один дорогой класс запросов, сохраните фактический usage, подготовьте набор сложных примеров и докажите, что уменьшение разрешения, кадры по событию или связка OCR с выборочным vision-анализом не ломают результат. После этого бюджет перестаёт быть предположением и становится инженерным ограничением, которым можно управлять.