Почему 'low' для изображений дороже 'auto': гайд по оптимизации затрат

В мире интеграции больших языковых моделей (LLM) с компьютерным зрением каждый цент на счету. Разработчики постоянно ищут способы оптимизации затрат, не жертвуя качеством результатов. Одним из самых популярных и интуитивно понятных инструментов экономии является параметр detail (уровень детализации) при отправке изображений в модель. Логика здесь кажется очевидной: если мы просим модель обработать изображение в низком разрешении, она должна потратить меньше вычислительных ресурсов на входные токены, а значит, и стоить дешевле. Однако реальность, как часто бывает в сложных системах, оказывается гораздо хитрее.

Недавнее глубокое исследование от OpenRouter, проведенное на актуальных моделях OpenAI и Google, вскрыло парадоксальную ситуацию. Использование параметра detail: low не только не всегда экономит деньги, но в некоторых случаях может сделать обработку изображения значительно дороже, чем использование режима auto или high. Более того, это часто приводит к снижению точности ответов. В этой статье мы подробно разберем, почему так происходит, как взаимодействуют детализация изображения и режимы рассуждения (reasoning), и какие стратегии оптимизации действительно работают для ваших проектов.

01Главный вывод: Auto лучше и иногда дешевле

Исследование охватило пять ключевых моделей от OpenAI и Google: gpt-5.5, gpt-5.4-mini, gpt-4.1, gemini-3.5-flash и gemini-3.1-pro. Тестирование проводилось в двух режимах детализации — low и auto — при температуре 0 и в один проход (epoch). Результаты оказались однозначными: на каждой из протестированных моделей режим auto показывал более высокую точность. Но самое интересное кроется в цифрах затрат.

Классическим примером аномалии стала модель gpt-5.5. При использовании параметра detail: low на наборе данных MMMU-Pro Vision модель показала результат 65.2%, тогда как в режиме auto точность выросла до 79.0%. Но парадокс заключался в стоимости: запрос с низким разрешением стоил 5.1 цента, а с высоким — всего 4.5 цента. Почему модель, получившая «менее качественную» картинку, потребовала больше ресурсов? Ответ кроется в механизме рассуждения.

Как модель компенсирует нехватку данных

Когда вы устанавливаете detail: low, модель OpenAI получает сильно сжатое изображение размером 512x512 пикселей, независимо от исходного размера файла. Это действительно снижает количество входных токенов, связанных с изображением. Однако, если на изображении есть мелкий текст, сложные диаграммы или тонкие линии, эта информация теряется при сжатии. Модель, не способная четко «увидеть» детали, начинает компенсировать этот пробел. Она включает более интенсивный процесс внутреннего рассуждения, пытаясь угадать или вывести правильный ответ на основе контекста, а не визуальных данных.

В случае с gpt-5.5 использование режима low привело к увеличению количества токенов рассуждения (reasoning tokens) с 730 до 1180 на один запрос — рост на 60%. Кроме того, выросло количество токенов в ответе (completion tokens) на 39%. Поскольку токены рассуждения и генерации ответа тарифицируются значительно дороже, чем входные токены изображения, экономия на входе была полностью нивелирована, а затем и превзойдена затратами на «думание». Итог: вы заплатили больше и получили худший результат.

02Почему разные модели ведут себя по-разному?

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

Модели с рассуждением (Reasoning Models)

Для моделей, таких как gpt-5.5 и gemini-3.5-flash, которые активно используют цепочки рассуждений, режим low часто становится ловушкой. gpt-5.5 стала самым ярким примером удорожания. gemini-3.5-flash также показала рост токенов рассуждения при использовании low (2876 против 2602), хотя итоговая стоимость снизилась с 2.96 цента до 2.80 цента. Это связано с тем, что базовая стоимость входных токенов у Gemini ниже, и экономия на них перекрыла небольшой рост затрат на рассуждение. Однако gemini-3.1-pro показала обратную тенденцию: при low она использовала меньше токенов рассуждения (6344 против 6964), что сделало этот режим дешевле (9.53 цента против 11.12 цента), но точность все равно упала (75.5% против 78.4%).

Вывод для моделей с рассуждением: они склонны «додумывать» недостающую визуальную информацию, что увеличивает нагрузку на процессор и память, повышая стоимость запроса. Режим auto предоставляет им достаточно данных, чтобы рассуждать эффективнее и быстрее.

Модели без рассуждения (Non-Reasoning Models)

Здесь ситуация более предсказуема. Модели gpt-5.4-mini и gpt-4.1 не имеют активного цикла рассуждений. Они обрабатывают изображение и сразу генерируют ответ. В этом случае экономия на входных токенах работает как задумано. gpt-5.4-mini в режиме low стоила 0.08 цента против 0.14 цента в режиме auto (экономия ~40%). gpt-4.1 также показала снижение задержки (latency): 960 мс против 1148 мс. Однако цена этой экономии — падение точности. Для gpt-5.4-mini точность упала с 55.8% до 46.1%, а для gpt-4.1 — с 57.5% до 40.1%.

03Где точность выигрывает больше всего?

Переход с low на auto дает прирост точности от 2 до 17 пунктов в зависимости от модели и типа изображения. Наибольшую выгоду получают модели OpenAI, так как их режим lowlow сохраняет около 273 токенов на часть изображения, что дает более четкую базовую линию, поэтому потери меньше.

Анализ по типам изображений выявил критические зоны:

• Текст и OCR (76% датасета): Большинство вопросов уже находятся на пределе возможностей модели, поэтому улучшение детализации не всегда дает огромный скачок, но предотвращает ошибки.
• Скриншоты (19%): Умеренный прирост точности.
• Графики и диаграммы: Здесь разница максимальна. Например, gemini-3.1-pro увеличила точность на графиках с 78.6% до 91.7% при использовании auto.
• Схемы (Diagrams): Самая сложная категория. Точность остается низкой (около 33%) независимо от детализации, так как даже в высоком разрешении модели сложно интерпретировать сложные технические чертежи.

Кейс: Механическая инженерия

Рассмотрим конкретный пример из теста. Задача требовала выбрать правильный главный вид из четырех ортогональных проекций технического чертежа размером 2239x1279 пикселей. Различия между вариантами заключались лишь в положении штриховки и скрытых линий. В режиме auto модель gpt-5.5 правильно выбрала вариант B. В режиме low изображение сжалось до миниатюры 512px, тонкие линии слились, и модель, потратив больше времени на рассуждение, ошибочно выбрала вариант C. Это наглядно демонстрирует, что долгое «размышление» над размытой картинкой не заменяет четкого визуального восприятия.

04Стратегия оптимизации: Контролируйте рассуждение, а не картинку

Если ваша цель — снизить затраты, исследование предлагает контринтуитивное, но эффективное решение. Параметр detail влияет на стоимость незначительно по сравнению с затратами на токены рассуждения. Изменение уровня детализации меняет точность на 2-17 пунктов, но почти не бьет по кошельку. Изменение уровня рассуждения (reasoning effort) меняет счет на 50-75%, тогда как точность колеблется в пределах шума (1-2 пункта).

Пример с gpt-5.5: ограничение уровня рассуждения до reasoning=low снизило стоимость запроса в режиме low с 5.1 цента до 1.7 цента (экономия 67%), при этом точность упала всего на 1.3 пункта (с 65.2% до 63.9%). Для gemini-3.1-pro снижение уровня рассуждения уменьшило стоимость с 11.1 цента до 2.7 цента, причем точность даже немного выросла на 1.5 пункта.

05Что это значит на практике

Основываясь на данных исследования, можно сформулировать четкие рекомендации для разработчиков, работающих с LLM через API (включая OpenRouter, который унифицирует доступ к этим моделям):

1. Для моделей с рассуждением (GPT-5.5, Gemini Pro и аналоги):
   • Используйте detail: auto или high. Это обеспечит лучшую точность и часто более низкую стоимость за счет сокращения времени рассуждения.
   • Используйте параметр reasoning (или аналогичный у провайдера) для контроля затрат. Снижайте уровень рассуждения, если бюджет ограничен, а не качество картинки.
2. Для моделей без рассуждения (GPT-4.1, GPT-5.4-mini и аналоги):
   • Используйте detail: low, если важна скорость (latency) и минимальная стоимость, а допустимый уровень ошибок выше. Вы получите экономию ~40% и ускорение ответа.
   • Используйте detail: auto, если критична точность, особенно для текстовых и скриншотных данных.
3. Техническая реализация: При использовании OpenRouter вы можете передавать провайдер-специфичные параметры, такие как image_url.detail для OpenAI или mediaResolution для Gemini, через единый интерфейс. Не меняйте архитектуру приложения, просто настройте параметры запроса в зависимости от выбранной модели.

06Как проводилось тестирование

Для обеспечения достоверности результатов исследование использовало строгую методологию:

• Бенчмарк: Набор данных MMMU-Pro Vision (конфигурация vision, тестовый сплит). Всего 1730 вопросов с десятью вариантами ответов, требующих визуального рассуждения.
• Модели: gpt-5.5, gpt-5.4-mini, gpt-4.1, gemini-3.5-flash, gemini-3.1-pro.
• Условия: Каждая модель тестировалась в режимах low и auto. Температура установлена в 0 для детерминированности. Один проход (epoch). Ограничения на максимальное количество токенов не применялись.
• Метрики: Точность оценивалась по логам оценки. Токены и задержка (latency) собирались из записей генерации OpenRouter. Стоимость рассчитывалась как общая стоимость запуска, деленная на количество обработанных вопросов, что позволяет сравнивать результаты справедливо, даже если размер выборки незначительно варьировался.
• Классификация изображений: Типы изображений (текст, скриншот, диаграмма, график, иллюстрация, фото) определялись с помощью gpt-5.4-mini vision. Для Gemini-моделей рассчитывалась точность по каждому типу, для OpenAI в данном запуске детализация по типам не проводилась.

Этот анализ демонстрирует, что оптимизация LLM — это не просто поиск самого дешевого параметра, а понимание баланса между качеством входных данных и вычислительными усилиями модели. Игнорирование взаимодействия между детализацией изображения и режимами рассуждения может привести к неожиданным расходам. Используйте auto для качества и контролируйте бюджет через настройки рассуждения.

Источник: OpenRouter ↗