← Блог

GPT-5.4 vs GPT-5.3: Что может измениться на самом деле

Утечки о GPT-5.4 указывают на более быстрый инференс и улучшения в области зрения. Вот чем он может отличаться от GPT-5.3 для разработчиков.

By Dora 9 min read
GPT-5.4 vs GPT-5.3: Что может измениться на самом деле

Привет, я Дора. Я поймала себя на том, что «нянчусь» с долго работающим агентным циклом. Ничего драматичного — просто то медленное, дёрганое ощущение, когда модель продолжает запрашивать ещё один вызов инструмента, потом ещё один. Это напомнило мне, как много моего рабочего дня живёт на краях: паузы, повторные попытки, моменты «а она вообще прочитала документ?».

Поэтому я провела день за пересмотром своих заметок о GPT-5.3, а затем просматривала ранние разговоры о GPT-5.4. Некоторые из ранних обсуждений об архитектуре модели и намёках на задержку обобщены в этом разборе утечки GPT-5.4. Не ради погони за следующей большой вещью, а чтобы ответить на более простой вопрос: снизит ли что-нибудь из этого нервозные части моего рабочего процесса? Это мой текущий журнал GPT 5.4 против GPT 5.3 — с тем, что я измерила, что кажется достоверным и в чём я до сих пор не убеждена.

Возможности GPT-5.3: текущий базовый уровень

Рассуждение и производительность при использовании инструментов

Я использую GPT-5.3 с середины января 2026 года для трёх постоянных задач: суммирование исследований продукта, сортировка тикетов поддержки и создание каркасов небольших скриптов. Короче говоря: он хорошо справляется с многошаговыми рассуждениями, если я задаю ему чёткую структуру. Когда я явно указываю роли, состояние и условия завершения, он выполняет задачу без блужданий.

Для использования инструментов вызов функций был стабильным. Я опираюсь на паттерны вызова функций OpenAI и стандартные схемы инструментов — никаких сюрпризов. С хорошо определёнными инструментами (поиск, извлечение, простой векторный поиск) 5.3 держит вызовы аккуратными. В прогоне сортировки 20 писем он в среднем делал 1,7 вызова инструментов на тред, что ниже 2,4 в моей старой настройке. Это сократило небольшие паузы «что дальше?». Загвоздка: если мои описания инструментов становятся расплывчатыми, он пытается компенсировать это большим количеством вызовов.

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

Поддержка программирования и агентных рабочих процессов

Для кода 5.3 стабилен при небольших и средних рефакторингах. Он хорошо генерирует диффы с чёткими объяснениями и может придерживаться согласованного стиля, если я предоставлю краткое руководство по стилю. Там, где он замедляется — это межфайловые изменения, требующие глубокой осведомлённости о зависимостях. Обычно я перехожу к двухпроходному паттерну: первый проход просит его наметить правки, второй применяет их файл за файлом. Это не даёт ему самоуверенно трогать то, чего не следует.

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

Известные ограничения

  • Он может дублировать обработку инструкций, когда я смешиваю системные правила с длинными пользовательскими задачами: я научилась перефразировать ключевые ограничения ближе к концу промта.
  • Иногда он настаивает на повторном суммировании входных данных, которые я уже суммировала, что раздувает количество токенов и время.
  • В задачах с визуальным контентом (скриншоты, макеты UI) он неплохо справляется с подписями и описаниями, но пропускает мелкий текст и тонкую логику раскладки. Не раз случалось, что он путал переключатели с кнопками.
  • Под давлением (ограниченное количество токенов) он предпочитает безопасные общие фразы точным деталям. Я вижу это при анализе журналов ошибок: он называет вероятные причины, но без дополнительного контекста не решается делать выводы.

Вот моя рабочая картина 5.3: надёжен, когда я конкретна, слегка тревожится, когда нет.

Что сигналы об GPT-5.4 говорят об изменениях

У меня не было прямого доступа к 5.4 по состоянию на 5 марта 2026 года. Дальнейшее основано на ранних ветках об утечках, нескольких достоверных заметках разработчиков в приватных форумах и паттернах, которые я научилась отслеживать, когда семейство моделей делает небольшой шаг вперёд. Каждый пункт я отмечу как наблюдательный, основанный на утечках или спекулятивный.

Скорость вывода, последствия быстрого режима

На основе утечек: несколько источников упоминают «быстрый режим» или низкозадержечный уровень для краткосрочных рассуждений. Если это правда, это важно не столько для сырой пропускной способности, сколько для темпа агента. Снижение задержки первого токена на 20–30% меняет ощущение цикла с неуклюжего на отзывчивое. Бенчмарки, сравнивающие GPT-5 с такими моделями, как DeepSeek и GLM, показывают, насколько задержка и стоимость могут влиять на рабочие процессы разработчиков на практике. В моей настройке 5.3 задержка первого токена колеблется около 600–900 мс на средних промтах: даже снижение на 150–200 мс сделает инструментальные цепочки менее прерывистыми. Я ожидаю, что этот быстрый режим пожертвует некоторой глубиной — полезно для маршрутизации, классификации или быстрой проверки перед более тяжёлым проходом.

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

Улучшения обработки визуального ввода

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

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

Потенциальное расширение контекстного окна

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

Я поверю в это, когда увижу меньше «переинтерпретаций» в конце прогонов. До тех пор я осторожна.

Таблица сравнения бок о бок

Я предпочитаю разделять то, что измерила сама, и то, что только слышала. Три быстрые таблицы, одна и та же призма каждый раз.

Подтверждённые возможности

ОбластьGPT-5.3GPT-5.4
Использование инструментов / вызов функцийСтабилен с чёткими схемами: 1–3 вызова на задачу типично в моих прогонахНе подтверждено
Рассуждение под давлением токеновДеградирует до обобщений: выигрывает от перефразированных ограниченийНе подтверждено
Визуальный контент (скриншоты UI)Пропускает мелкий текст: путает некоторые элементы управленияНе подтверждено
Поведение агентного циклаЛучше всего работает с циклами из 2–3 шагов и явными условиями остановкиНе подтверждено
Программирование в нескольких файлахТребует двухпроходной стратегии для безопасности: хорошие объяснения диффовНе подтверждено

Ссылки: я следую паттернам в документации по вызову функций OpenAI и определениям инструментов в справочнике API. Если вам интересно, официальная документация — хорошая точка опоры: OpenAI API: вызов функций и использование инструментов.

Сигналы на основе утечек

ОбластьGPT-5.3GPT-5.4 (на основе утечек)
Скоростной уровень выводаТолько стандартные режимыДобавляет более быстрый, поверхностный уровень для низкозадержечных ответов
OCR визуального контентаДостаточный, затрудняется с мелким/низкоконтрастным текстомУлучшенная точность мелкого текста и обработки раскладки
Стоимость за токенТекущие опубликованные тарифыНебольшое снижение в быстром уровне (неподтверждено)

Качество источников: смешанное. Некоторые детали совпадают с паттернами из предыдущих релизов: ни одна не подтверждена.

ОбластьGPT-5.3GPT-5.4 (спекулятивно)
Сохранение контекстаТребует частых напоминаний об ограниченияхУдерживает ограничения дольше с меньшим количеством повторений
Эффективность использования инструментовИногда делает лишние вызовы при расплывчатой схемеЛучшая экономия вызовов при аналогичных промтах
Долгосрочное планированиеКолеблется в обязательствах дальше 3–4 шаговНемного более стабильное многошаговое планирование

Спекулятивные улучшения

Почему эти изменения важны для разработчиков

Влияние на проектирование агентных циклов

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

Лучшая обработка визуального контента упростила бы мой конвейер анализа UI. Сейчас я использую трёхшаговую цепочку для макетов: базовая подпись → проход OCR → проверка раскладки. Если 5.4 объединит первые два, я уберу шаг OCR и оставлю только валидатор раскладки. Это один инструмент меньше для поддержки и меньше мест для ошибок.

Если сохранение контекста улучшится, я сокращу барабанный бой напоминаний в промтах. Я бы сохранила небольшой, неизменяемый блок правил и доверила бы модели нести его дальше в прогоне. Меньше каркасов, меньше токенов, те же результаты.

Компромиссы стоимость-производительность

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

  • маршрутизации и лёгкой проверки (мы распарсили дату? да/нет?),
  • ранних выходов (это известный FAQ?),
  • проверки работоспособности извлечённого контекста (этот фрагмент вообще упоминает сущность?).

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

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

Соображения по миграции

  • Начните с теневых тестов. Запустите одни и те же промты через 5.3 и 5.4 (когда будет доступно) и сравните результаты. Не переключайте живой путь, пока не увидите несколько десятков граничных случаев.
  • Держите схемы инструментов строгими. Расплывчатые описания раздувают количество вызовов в 5.3: они, вероятно, сделают то же самое в 5.4, быстром или нет.
  • Записывайте токенное давление. Многие «регрессии» — это просто более жёсткие промты. Отслеживайте использование окна и удаляйте шаблонный текст.
  • Версионируйте промты. Я веду небольшой журнал изменений в системных сообщениях. Если 5.4 ведёт себя лучше с более лаконичными напоминаниями, вам понадобится бумажный след того, что вы убрали.
  • Тихо наблюдайте за визуальным контентом. Если вы полагаетесь на скриншоты, тестируйте с низкоконтрастным текстом, тесным UI и нестандартными шрифтами. Один хороший тестовый набор лучше дюжины анекдотов.

Если вы небольшая команда, самый безопасный шаг — поэтапный: пилотируйте узкий рабочий процесс (маршрутизация, сортировка), затем расширяйте.

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

Важная оговорка (сравнение основано на сигналах утечек)

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

Последняя мысль: даже небольшое ускорение может расслабить рабочий процесс. Если это всё, что принесёт 5.4, — я всё равно возьму это.

Поделиться