Когда модель быстрее API: новая проблема AI-разработчиков

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

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

Иными словами: модели стали настолько быстрыми, что узким местом оказалась уже не сама нейросеть, а инфраструктура вокруг неё.

ℹ Контекст
Responses API — это основной интерфейс OpenAI для построения агентных систем. Он позволяет моделям типа Codex итеративно решать задачи: читать файлы, запускать тесты, вносить правки в код.

От 65 до 1000 токенов в секунду: масштаб задачи

В Responses API предыдущие флагманские модели, такие как GPT-5 и GPT-5.2, работали со скоростью около 65 токенов в секунду (TPS). Для запуска GPT-5.3-Codex-Spark — быстрой модели для написания кода — цель была на порядок выше: свыше 1000 TPS, что стало возможным благодаря специализированному железу Cerebras, оптимизированному для LLM-инференса.

Чтобы пользователи могли ощутить истинную скорость новой модели, необходимо было снизить накладные расходы API.

Быстрые модели перестают ощущаться быстрыми, если оркестрационные издержки поглощают весь выигрыш в скорости.

Почему старый подход не работал

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

Задача на исправление ошибки в стиле Codex может потребовать десятков итераций: выбрать следующее действие, вызвать инструмент, вернуть его результат — и повторить.

Как работает агентный цикл: до и после


graph TD
    A[Запрос пользователя] --> B[HTTP-запрос к API]
    B --> C[Валидация и обработка]
    C --> D[Маршрутизация]
    D --> E[Инференс модели на GPU]
    E --> F[Вызов инструмента]
    F --> G{Ещё итерации?}
    G -- Да --> B
    G -- Нет --> H[Результат]

    style B fill:#ff9999
    style C fill:#ff9999
    style D fill:#ff9999

Красным выделены стадии, где каждый раз повторялась лишняя работа при стандартных HTTP-запросах.

После внедрения WebSockets картина меняется: соединение остаётся открытым, состояние кэшируется в памяти, и каждый следующий вызов инструмента не требует повторной обработки всей истории.


graph TD
    A[Запрос пользователя] --> B[WebSocket-соединение]
    B --> C[Кэш состояния в памяти]
    C --> E[Инференс модели на GPU]
    E --> F[Вызов инструмента]
    F --> G{Ещё итерации?}
    G -- Да --> C
    G -- Нет --> H[Результат]

    style C fill:#99ff99
    style B fill:#99ff99

Почему WebSockets, а не gRPC

OpenAI рассматривала несколько подходов, включая WebSockets и двунаправленную потоковую передачу gRPC. В итоге выбор пал на WebSockets: будучи простым протоколом передачи сообщений, он не требовал от пользователей изменения форматов входных и выходных данных Responses API. Он был удобен для разработчиков и вписывался в существующую архитектуру с минимальными изменениями.

💡 Для разработчиков
WebSockets не потребовали полного переписывания клиентского кода. Чтобы разработчики могли принять WebSocket-режим без существенных переработок, OpenAI сохранила привычную форму API. Разработчики продолжают использовать response.create с тем же телом запроса, добавляя previous_response_id для ссылки на кэшированное состояние.

Как устроено кэширование на уровне соединения

OpenAI добавила WebSocket-режим, чтобы клиенты могли поддерживать постоянное соединение с Responses API, пока сервер хранит привязанный к соединению in-memory кэш предыдущего состояния ответа.

Последующие вызовы по-прежнему используют привычный паттерн response.create, но когда клиент передаёт previous_response_id, сервер может переиспользовать предыдущий объект ответа, входные и выходные элементы, определения инструментов, пространства имён и даже артефакты отрендеренных токенов — вместо того чтобы заново восстанавливать полную историю с нуля.

# Пример использования WebSocket-режима в Responses API
import openai

client = openai.OpenAI()

# Первый вызов — создаём начальный контекст
response = client.responses.create(
    model="gpt-5.3-codex-spark",
    input="Проанализируй структуру проекта и найди баги",
    tools=[{"type": "shell"}],
    stream=True,  # WebSocket-режим
)

# Последующие вызовы — переиспользуем кэш
response2 = client.responses.create(
    model="gpt-5.3-codex-spark",
    input="Исправь найденные баги и запусти тесты",
    previous_response_id=response.id,  # ключевой параметр
    stream=True,
)

Дополнительно API вводит возможность предварительного прогрева. Разработчики могут отправить запрос с generate: false, чтобы заранее загрузить инструменты, инструкции или пользовательские сообщения. Это «подготавливает» соединение, гарантируя, что при поступлении реального пользовательского ввода модель сможет сгенерировать ответ почти мгновенно.

Оптимизации до WebSockets: Sprint по производительности

В конце 2025 года — примерно в ноябре — OpenAI запустила спринт производительности, сосредоточенный на критически важной задержке Responses API, то есть времени от получения запроса до момента, когда может быть получен первый полезный вывод. В рамках этого спринта OpenAI реализовала несколько оптимизаций для улучшения времени до первого токена (TTFT — Time To First Token). По её данным, улучшение составило около 45%.

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

Сравнение подходов: HTTP vs WebSockets

ПараметрСтандартные HTTP-запросыWebSocket-режим
СоединениеНовое на каждый запросПостоянное (persistent)
Передача историиПолная при каждом вызовеТолько дельта (изменения)
Кэш состоянияНетIn-memory, на уровне соединения
ВалидацияПолная при каждом запросеТолько новые данные
Скорость агентного циклаБазоваяДо +40% быстрее
Изменения в коде клиента—Минимальные

Результаты: цифры из реального мира

Это позволило сделать агентные циклы, использующие API, на 40% быстрее в сквозном режиме, дав пользователям возможность ощутить скачок скорости инференса — с 65 до почти 1000 токенов в секунду.

После выхода WebSocket-режима система достигла всплесков до 4000 токенов в секунду на продуктовом трафике.

Выигрыш быстро почувствовали и сторонние разработчики:

OpenAI сообщает, что Codex перевёл большинство своего трафика Responses API на WebSocket-режим, Vercel зафиксировал снижение задержки до 40% после интеграции в AI SDK, многофайловые воркфлоу Cline ускорились на 39%, а модели OpenAI в Cursor стали работать до 30% быстрее.

📝 Реальный кейс
Vercel AI SDK: команда интегрировала WebSocket-режим и немедленно получила снижение задержки до 40%. Cline: многофайловые рабочие процессы ускорились на 39%. Cursor: агентные задачи с моделями OpenAI выполняются до 30% быстрее.

Прототип: от идеи до продакшена за несколько недель

Первый WebSocket-прототип изменил представления о том, чего можно достичь в плане задержки Responses API. Инженер из команды Codex с глубокой экспертизой по всему стеку API собрал прототип, запустив агента Codex на ночь. В этом прототипе агентные прогоны моделировались как единый долгоживущий Response.

WebSocket-режим — одна из наиболее значимых новых возможностей Responses API со времени его запуска в марте 2025 года. От идеи до запуска в продакшен прошло всего несколько недель — благодаря тесному взаимодействию команд API и Codex внутри OpenAI.

Что это значит для разработчиков агентных систем

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

Это важный сигнал для разработчиков: скорость агента становится системной проблемой.

⚠ Важно учитывать
WebSocket-режим наиболее эффективен при 20 и более вызовах инструментов в рамках одного агентного прогона. При коротких задачах с 2–3 итерациями выигрыш будет менее заметен. Учитывайте это при оценке целесообразности миграции.

Практические рекомендации по миграции

  1. Используйте previous_response_id — ключевой параметр для активации кэша состояния на сервере.
  2. Предварительно прогревайте соединение — отправьте запрос с generate: false для загрузки инструментов и системных инструкций заранее.
  3. Убедитесь, что ваш клиент поддерживает постоянные WebSocket-соединения — большинство современных SDK это умеют.
  4. Протестируйте граничные случаи — обрывы соединения, повторное подключение, обработка ошибок при потере кэша.

Итог

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

Внедрение WebSockets в Responses API — это напоминание о том, что в эпоху сверхбыстрых AI-моделей архитектурные решения вокруг модели становятся не менее важными, чем сама модель. Узким местом больше не является GPU — теперь это сеть, протокол и способ управления состоянием.