В корпоративных сервисах загрузка скриншотов в нейросеть перестаёт быть безобидной мелочью: каждый снимок экрана занимает контекстное окно и увеличивает расходы компании, особенно если сотрудники массово отправляют документы и изображения в API. Для тестового скриншота разрешением 1920×1080 мы рассчитали объём визуального входа по открытым правилам разработчиков для GPT-5.5, Claude Opus 4.8 и Gemini 3.1 Pro Preview — все три модели доступны на платформе BotHub. Формулы взяты из официальной документации, цены — из тарифов BotHub на момент публикации, а сам анализ не претендует на рейтинг экономичности, поскольку у моделей разные цены и ограничения.

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

Для скриншота 1920×1080 GPT-5.5 в режиме high делит изображение на квадраты 32×32 пикселя, что даёт 2040 визуальных токенов: ceil(1920/32) × ceil(1080/32) = 60 × 34. Ограничения режима допускают до 2500 патчей и до 2048 пикселей по длинной стороне, поэтому наш скриншот помещается в лимиты. В режиме low модель получила бы версию 512×512, что сократило бы токены, но потеряло бы мелкие подписи — для OCR и точного определения координат OpenAI рекомендует режим original. Claude Opus 4.8 использует патчи 28×28 пикселей, что даёт 2691 визуальный токен: ceil(1920/28) × ceil(1080/28) = 69 × 39; на моделях стандартного разрешения Anthropic уменьшил бы скриншот до 1456×819, что заняло бы около 1560 токенов. Gemini 3.1 Pro Preview не имеет ручной сетки: параметр media_resolution задаёт бюджет токенов — low до 280, medium до 560, high до 1120, ultra_high до 2240; для большинства задач рекомендуется high, а ultra_high оправдан для ИИ-агентов, управляющих компьютером по скриншотам. Для нашего сравнения мы выбрали high, что даёт до 1120 токенов, но фактический объём запроса можно проверить через метод countTokens.

Разница в подсчёте токенов заметна: GPT-5.5 и Claude делят ширину и высоту на размер патча и перемножают, а Gemini просто выделяет бюджет. Однако это не означает, что Claude прочитает больше деталей, а Gemini меньше — каждая модель имеет свои алгоритмы обработки изображений, и сравнивать их напрямую по количеству токенов некорректно. Внутри одной модели режим действительно влияет на качество: в low картинка уменьшается, и мелкие подписи читаются хуже, в high или original сохраняется больше деталей. При этом если исходный скриншот плохого качества, даже самый дорогой режим не исправит размытый текст или низкое разрешение. Разработчики рекомендуют готовить скриншоты для нейросетей так же, как для коллеги: убрать панель задач, лишние вкладки и пустые поля, оставить название раздела для контекста, не склеивать несколько экранов в одну длинную картинку и для мелкого текста выбирать подробный режим.

Для российского рынка этот вопрос особенно актуален: компании всё чаще внедряют ИИ-инструменты для работы с документами, и стоимость визуального входа напрямую влияет на бюджет. На BotHub, где доступны все три модели, пользователи могут выбирать тарифы в зависимости от объёма токенов, но без понимания правил подсчёта легко переплатить. Например, если команда регулярно загружает скриншоты интерфейсов или PDF-файлы, разница между GPT-5.5 (2040 токенов на скриншот) и Gemini 3.1 в режиме high (1120 токенов) может составить почти вдвое при одинаковой задаче. Однако не стоит гнаться за экономией: в режиме low Gemini может не справиться с распознаванием мелкого текста, что приведёт к ошибкам и дополнительным затратам на повторные запросы. Оптимальная стратегия — тестировать разные режимы на типовых задачах и учитывать не только токены, но и качество ответа.

Сравнение с альтернативами показывает, что у каждой модели есть свои сильные стороны: GPT-5.5 хорош для OCR благодаря режиму original, Claude предлагает больше токенов для детального анализа, а Gemini гибко настраивается под задачи с помощью media_resolution. Для увеличения эффективности можно отправлять два изображения: весь экран и увеличенный фрагмент — модель увидит контекст и разберёт текст. В перспективе разработчики моделей могут унифицировать правила подсчёта токенов, но пока это вряд ли произойдёт, так как каждая компания стремится сохранить свою архитектуру. Открытым остаётся вопрос, как именно модели обрабатывают изображения внутри «чёрного ящика»: полной схемы слоёв нет в открытом доступе, и это ограничивает возможности точной оптимизации. Тем не менее, для практических задач важно помнить: скриншот для нейросети стоит готовить так же, как для коллеги — аккуратно, с контекстом и без лишних деталей, и тогда токены будут потрачены с пользой.