GPT-Image-2.6 против GPT-Image-2.5: замена — это одна строка, а счёт — нет

Переход с GPT-Image-2.5 на GPT-Image-2.6 на уровне API — самое незначительное обновление, которое OpenAI выпустила за весь год. Те же два эндпоинта, та же тарифная сетка, то же разделение на Flare и Sunburst. Меняется строка модели, и больше ничего не обязано меняться. В этом же и ловушка. GPT-Image-2.6 добавляет один параметр, которого никогда не было в GPT-Image-2.5, — регулятор сложности, — и если его не указать, это не значит, что он отключён. По умолчанию он установлен на высокий уровень. Пайплайн, который просто меняет строку и выпускает его, покупает не тот же объём работы за те же деньги; он покупает больше работы, поэтому первый отчёт о затратах после миграции может измениться, даже если опубликованные тарифы не менялись.

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

Поверхность API действительно полностью заменяема — с одной прорехой.

OpenAI выпустила GPT-Image-2.6 4 ноября 2026 года в виде двух моделей API, а не одной, унаследовав структуру, заложенную в версии 2.5. Уровень, ориентированный на детализацию и согласованность, — это GPT-Image-2.6 Sunburst; скоростной уровень — GPT-Image-2.6 Flare. Их предшественники, GPT-Image-2.5 Sunburst и GPT-Image-2.5 Flare, сохраняют те же названия и те же соотношения друг с другом.

• Строки моделей — gpt-image-2.6-flare и gpt-image-2.6-sunburst заменяют gpt-image-2.5-flare и gpt-image-2.5-sunburst, та же логика именования: одна для задержки, другая для детализации.

• Эндпоинты — /v1/images/generations и /v1/images/edits, без изменений. Новых эндпоинтов для интеграции нет.

• Тарифы — $5 за миллион входных текстовых токенов, $8 за миллион входных токенов изображений, $30 за миллион выходных токенов изображений, при этом кэшированный ввод — $1.25 и $2.00. Побайтно идентично версии 2.5.

• Уровни качества — low, medium, high, xhigh, max и auto. Та же шкала.

• Рекомендуемые размеры — 1024×1024, 1536×1024 и 1024×1536 — по-прежнему остаются основными в документации; пользовательские размеры принимаются кратными 16, а соотношения сторон — от 1:3 до 3:1.

• Пробел — 2.6 недоступна через Batch API. Если ваши расходы на изображения строятся на ночной задаче за полцены, эта задача пока не сдвинется.

Последняя строка — та, что действительно что-то ломает. Всё выше неё — это замена строки и прогон регрессионных тестов. Разрыв в пакетной обработке — архитектурный блокер именно для таких нагрузок — массовых каталогов, ночных бэкфиллов, масштабной генерации A/B, — где скидка 50% и есть причина, по которой этот сценарий вообще существует.

Настоящая фишка — это регулятор сложности, а сюрприз — его значение по умолчанию.

Сложность — это новая ось, которая находится рядом с качеством, а не внутри него, и это различие важнее, чем кажется. Качество управляет рендерингом: сколько выходных токенов уходит на изображение. Сложность управляет планированием: сколько рассуждений модель выполняет перед началом рендеринга. Можно запросить низкокачественное изображение сложной сцены или высококачественное изображение простой, и в 2.6 это действительно разные запросы.

Документация прямо указывает: если параметр опущен, он по умолчанию принимает значение high. Поэтому вызывающая сторона, которая переносит запрос для 2.5, изменив только имя модели и ничего больше, незаметно для себя выбирает максимальный бюджет планирования при каждом вызове. Это не ошибка — это разумное значение по умолчанию для модели, главное преимущество которой в том, что она больше размышляет, — но это означает, что первый месяц трафика на 2.6 не является сопоставимым сравнением с последним месяцем трафика на 2.5.

Есть по крайней мере одна публичная точка данных, указывающая в том же направлении. Опубликованный 4 ноября практический тест на трёх изображениях сообщал {{1}}о $0.1245 за вывод в 2.6 против $0.0446 за те же кадры в 2.5{{/1}} — примерно втрое, при тарифной сетке, которая не менялась. Три изображения — это не бенчмарк, и их не следует приводить в качестве такового; выборка слишком мала, чтобы установить множитель. Что он действительно делает — демонстрирует механизм, а механизм задокументирован: {{2}}больше токенов планирования на запрос, включено по умолчанию, оплачивается по $30 за миллион{{/2}}.

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

К чему на самом деле приводит заявленное 50%-ное ускорение

OpenAI описывает GPT-Image-2.6 как примерно на 50% более быструю в целом, но цифры по отдельным уровням гораздо интереснее, чем заголовочный показатель, и это собственные данные поставщика, а не независимые замеры. Для Flare сообщается примерно 2,6× по сравнению с предшественником, причём рендеры низкого качества завершаются всего за шесть секунд. Для Sunburst сообщается примерно 1,15×.

Эти два числа описывают два совершенно разных обновления. Если ваш пайплайн использует Flare для итераций — исследования миниатюр, настройки промптов, всего, где человек ждёт результата, — 2.6 — это качественный скачок, и одна только экономия внимания окупает миграцию. Если ваш пайплайн использует Sunburst для качества финального результата, улучшение задержки на 15% укладывается в разброс между запусками на большинстве вариантов хостинга, и скорость вовсе не является причиной мигрировать.

Стоит честно отметить: тот же небольшой практический тест, который сообщил о раздувании токенов, также сообщил, что 2.6 медленнее 2.5 на его трёх изображениях, что противоречит утверждению вендора. При n=3 это шум, а не опровержение. Но это напоминание о том, что «на 50% быстрее» — это агрегированный показатель из презентации к запуску по разным уровням качества, а реальный пайплайн видит один уровень при одной настройке качества.

Пока никто не набрал 2,6, а 2,5 всё ещё лидирует.

Это та часть сравнения, которую большинство обзоров обходит молчанием. Artificial Analysis, ведущая свои рейтинги AA-Image-T2I v2.1 и рейтинги редактирования, на 5 ноября 2026 года вообще не имела строки для GPT-Image-2.6. Не низкий балл — а просто отсутствие строки.

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

• Текст-в-изображение — GPT-Image-2.5 Sunburst (max): 1 224 Эло по итогам 13 153 голосов, первое место. GPT-Image-2.5 Flare (max): 1 207 по итогам 12 498 голосов, второе место. GPT Image 2 (high): 1 188, третье место.

• Редактирование изображений — GPT-Image-2.5 Sunburst (max): 1 200 из 18 370 голосов, первое место. GPT-Image-2.5 Flare (max): 1 183 из 19 259, третье место после MAI-Image-2.7-Preview с 1 197.

В материалах запуска OpenAI для 2.6 Sunburst приводится Design Arena как обоснование первого места. Это реальное заявление в реальном рейтинге, но это другой пул оценщиков в другой шкале, и выбор вендором рейтинга, который льстит его релизу, не является доказательством чего-либо, что может использовать покупатель. Сопоставимой сторонней оценки по голосам для 2.6 пока не существует. Пока её нет, защитимая позиция такова: 2.5 — модель изображений с наивысшей независимой оценкой в обоих основных рейтингах, а 2.6 не доказана — лучше в тех конкретных аспектах, в которых OpenAI утверждает, что она лучше, и не измерена во всём остальном.

Миграция, которая укладывается в полдня

Замена достаточно дешева, поэтому разумный подход — не одномоментная миграция «большим взрывом», а постепенная, выполняемая на ваших собственных промптах, а не на чьём-либо наборе эталонных промптов.

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

Сохраняйте резервный путь на 2.5 для пакетной обработки, поскольку 2.6 пока не может её обслуживать. И рассматривайте любой трафик Sunburst как вопрос качества, а не скорости — если доля принятия не изменится, вы получили 15%-ное улучшение задержки и более крупный счёт за планирование.

Когда оставаться на 2.5 — правильный ответ

Три случая достаточно очевидны, чтобы их назвать. Пакетные нагрузки следует оставить, потому что 2.6 отсутствует в Batch API, а 2.5 присутствует. Конвейеры обеспечения качества Sunburst следует оставить, если только тест на показатель принятия не говорит об обратном, потому что ускорение в 1,15× не окупает изменения модели затрат. А всем, у кого текущий показатель принятия уже приемлем, следует остаться, потому что новые возможности — экспорт в SVG, анимированный GIF, редактирование под управлением разметки — это дополнительные функции, а не улучшения качества, и они нужны вам только в том случае, если у вас есть готовый результат, который их требует.

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

Доступность и неуклюжая форма разделённой миграции

OrcaRouter предоставляет GPT-Image-2.5 Flare и GPT-Image-2.5 Sunburst сегодня по каталожной цене с наценкой 0%, поэтому тариф провайдера — это тариф, который вы платите, без дополнительной маржи. По состоянию на 5 ноября 2026 года — через день после запуска — GPT-Image-2.6 отсутствует в каталоге, из-за чего непосредственная практическая проблема заключается в маршрутизации, а не в моделировании: в ходе сравнительного тестирования трафик 2.5 идёт через один ключ с автоматическим переключением при сбое, тогда как трафик 2.6 направляется напрямую в OpenAI по второму договору и второму счёту.

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

Это ещё один аргумент в пользу миграции, рассчитанной на день, а не на выходные. Пропустите 2.5 через маршрутизатор, сохраните базовый уровень затрат стабильным и добавьте 2.6 под флагом, как только измерите, как значение сложности по умолчанию влияет на количество ваших токенов. Модель никуда не денется, а batch-эндпоинт появится раньше, чем наступит ваш следующий квартальный цикл планирования.