OpenAI Codex переезжает on-premises: что партнёрство с Dell значит для маршрутизации корпоративного AI

Главный вопрос, с которым сталкивается большинство инженерных команд при внедрении Codex, — это не «стоит ли его использовать», а «где запускается агент и как направить к нему трафик». Партнёрство OpenAI и Dell Technologies, объявленное 18 мая, ставит этот вопрос ребром для тех компаний, которые не могут отправлять самый чувствительный код во внешний cloud API.

Codex переходит из чисто облачного продукта в гибридный. Сотрудничество с Dell интегрирует Codex с Dell AI Data Platform (on-premises governance корпоративных данных) и Dell AI Factory (on-premises инфраструктура inference). Практический результат: компании впервые смогут запускать агентов на базе Codex рядом с кодовыми базами, документацией и бизнес-системами, которые живут внутри их собственных дата-центров, — без вывода этих данных в облако OpenAI.

Это серьёзно меняет логику маршрутизации. Вот что инженерным командам стоит продумать до того, как этот путь развёртывания станет общедоступным.

Что изменилось

OpenAI и Dell работают над двумя точками интеграции:

Интеграция с Dell AI Data Platform. Codex будет подключаться к локальной data-платформе Dell — слою хранения, организации и governance, который компании уже используют для доступа к кодовым базам, документации и бизнес-записям. Это закрывает разрыв, из-за которого Codex был малопригоден для регулируемых отраслей: агент может рассуждать на основе внутреннего контекста, при этом сам контекст не покидает периметр предприятия.

Интеграция с Dell AI Factory (на стадии исследования). OpenAI изучает, как Codex (и ChatGPT Enterprise) могут взаимодействовать с on-prem инфраструктурой inference от Dell — то есть on-premises может уехать не только интеграция данных, но и сам слой model serving. Это пока предварительное направление, но оно указывает путь к полностью air-gapped развёртыванию Codex.

Фоном для всего этого служит Gartner 2026 Magic Quadrant for Enterprise AI Coding Agents, вышедший на той же неделе: OpenAI назван Лидером, и в числе сильных сторон прямо отмечены корпоративный governance, sandboxing, RBAC, approval gates и аудируемое управление рабочими пространствами. Партнёрство с Dell — это инфраструктурный ответ на эти требования: coding agent, который квалифицируется как enterprise-grade в облаке, теперь получает реалистичный путь к on-prem развёртыванию.

Codex используют более 4 миллионов разработчиков еженедельно, а такие компании, как Cisco, Datadog, Dell и NVIDIA, уже встраивают его во весь жизненный цикл разработки — от code review и покрытия тестами до incident response и навигации по крупным репозиториям.

Почему это важно для AI-инженерных команд

Локальность данных меняет применимость агента. Ключевое преимущество Codex — рассуждение по большим кодовым базам. Для компаний с жёсткими требованиями к data residency — финансы, здравоохранение, оборонка, госсектор — отправка внутренних репозиториев во внешний API была стоп-фактором. Интеграция с Dell этот стоп-фактор снимает. Команды, отвергшие Codex по compliance-причинам, получают реальный путь для on-prem оценки.

Гибридная маршрутизация означает расщеплённый трафик. В мире, где часть Codex-нагрузок идёт on-prem, а часть — в cloud OpenAI, ваш router должен понимать, по какому пути идёт каждый запрос. Code completion в публичном репозитории? Облако вполне подойдёт. Code review внутренней зарплатной системы? Только on-prem. Большинство текущих конфигураций router'а такого различия не предусматривают — это требует политик маршрутизации на уровне проекта или команды, а не единого унифицированного endpoint.

Учёт расходов становится сложнее. Cloud Codex тарифицируется по API-токенам. On-prem Codex работает на инфраструктуре Dell со своим CapEx или OpEx. Единая cost-модель, которая сводит и то, и другое, требует от вашего billing-инструментария объединять источники, изначально не предназначенные для сравнения. Команды, которые сегодня выгружают token-based стоимость через OpenAI billing API, должны будут поверх этого наложить атрибуцию инфраструктурных расходов.

Session affinity для состояния агента. Codex-агенты всё чаще держат состояние между ходами — локальную среду выполнения, запущенный тестовый набор, частично изменённое дерево файлов. Если ваш router балансирует нагрузку между несколькими инстансами Codex (cloud плюс on-prem), он обязан направлять возобновлённую сессию обратно на тот же инстанс, где хранится состояние агента, — иначе контекст потеряется в середине задачи. Это требование session affinity, давно знакомое по stateful веб-сервисам, теперь относится и к coding agents.

Governance-контроли должны охватывать оба контура. Approval gates, RBAC и аудируемое управление workspace работают только тогда, когда применяются одинаково и к cloud-, и к on-prem-трафику Codex. Если ваш governance-слой живёт в cloud-only proxy, on-prem вызовы Codex просто пройдут мимо.

Угол маршрутизации и эксплуатации

Партнёрство с Dell вводит двухуровневую архитектуру для корпоративного развёртывания Codex:

Запрос команды
  │
  ├─ Публичный / нечувствительный код → routing proxy → OpenAI cloud Codex
  │                                      (биллинг по токенам, cloud compliance)
  │
  └─ Чувствительный / регулируемый код → on-prem routing → Dell AI Factory Codex
                                          (данные остаются on-prem, CapEx, локальный RBAC)

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

1. Политика классификации данных. Определите, какие проекты, репозитории или категории данных могут покидать периметр. Это становится самим правилом маршрутизации, а не просто документом.
2. Маршрутизация на уровне проекта. Маршрутизируйте запросы по проекту или команде, а не только по пользователю. Разработчик, которому разрешено использовать cloud Codex для публичных репозиториев, должен быть заблокирован от отправки туда регулируемого кода.
3. Единая observability. Логи, метрики latency и счётчики токенов/сессий должны агрегироваться по обоим контурам. Cloud-only dashboard будет иметь слепые зоны для on-prem трафика.
4. Стратегия управления состоянием сессий. Решите заранее, являются ли stateful-сессии агента cloud-only, on-prem-only или допускают миграцию. Смешивание контуров в середине сессии порождает трудноуловимые баги — избегайте этого, пока не появятся специальные инструменты миграции.

Интеграция Dell AI Factory для model serving — более радикальный вариант. Если она дозреет до общедоступного продукта, предприятия смогут запускать полный стек Codex без единого исходящего AI API-вызова — фактически превращая Codex из cloud-сервиса в self-managed развёртывание модели. Маршрутизационные последствия здесь зеркально повторяют дилемму BYOK против provider-managed, но уже на уровне всего слоя исполнения агента.

Что стоит отслеживать или попробовать пользователям TheRouter

• Сформулируйте политику маршрутизации по уровням данных уже сейчас. Даже если on-prem Codex пока недоступен, архитектурное расщепление, которое он создаёт, уже на подходе. Зафиксировать, какие нагрузки eligible для облака, а какие должны оставаться on-prem, проще до появления самого пути, а не после того, как инженеры уже им пользуются.

• Проверьте, как у вас обрабатываются сессии Codex. Если вы сегодня проксируете Codex, протестируйте, стабильны ли многоходовые сессии агента при вашей текущей конфигурации маршрутизации. Проблемы session affinity, незаметные в одноходовых сценариях, становятся критичными по мере удлинения горизонта задач.

• Следите за анонсом доступности Dell AI Factory. Текущий анонс — исследовательский. Как только on-prem model serving будет подтверждён как общедоступный, procurement и infrastructure-командам понадобится время на запуск — Dell AI Factory это серверные стойки, а не SaaS-тумблер.

• Пересмотрите модели расчёта стоимости только по токенам. Если ваша текущая система выгружает только token-based стоимость через OpenAI API, она будет недоучитывать полные расходы на Codex в гибридном развёртывании. Спроектируйте cost-модель, способную учитывать инфраструктурную аллокацию, до того как on-prem путь поедет в прод.

TheRouter маршрутизирует OpenAI-совместимые запросы между сконфигурированными провайдерами. Когда Codex on-prem выставит локально доступный endpoint — через интеграцию с Dell AI Data Platform или через model serving в Dell AI Factory — этот endpoint можно добавить как provider в конфигурации маршрутизации. Описанное выше расщепление по проектам или уровням данных напрямую ложится на правила маршрутизации уровня провайдера: чувствительные нагрузки — к on-prem провайдеру, нечувствительные — к cloud-провайдеру, а fallback и observability обеспечиваются на уровне gateway.