От ИИ-агентов для кодирования к платформам ИИ-инференса

Меня зовут Дора. Весь этот месяц я разговаривала с основателями стартапов об их технологических стеках для AI-приложений. Снова и снова прослеживается одна и та же закономерность. Бэкенд они завершают за три недели с помощью Codex, запуская параллельные потоки агентов. Эндпоинты выходят быстрее, чем пишутся тесты. Потом они пытаются добавить генерацию изображений или видео — и всё замирает. Агент для написания кода может написать API-клиент. Но заставить работающий инференс масштабироваться — это уже не в его силах.

Вот в чём разрыв. Слой агентов для написания кода в 2026 году созрел быстро. Слой AI-платформы инференса под ним — то, что фактически запускает модели, — получает меньше внимания, хотя именно там живёт большинство проблем в продакшене. Эта статья о том, как на самом деле выглядит стек приложений на генеративном AI в 2026 году, и где заканчиваются агенты для написания кода и начинается инфраструктура инференса.

Почему агенты для написания кода — это лишь один слой стека генеративного AI-приложения

Что Codex меняет в скорости разработки

Приложение Codex от OpenAI для управления несколькими агентами написания кода к марту 2026 года преодолело отметку в два миллиона еженедельных активных пользователей. Причина — не новизна. Дело в том, что трение от написания CRUD-эндпоинтов, API-клиентов и интеграционного клея действительно исчезло. Разработчик-одиночка может запустить несколько потоков агентов параллельно, каждый из которых работает над разными частями кодовой базы. Превращение спецификации в код больше не является узким местом.

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

Что это не решает для инференса в продакшене

Codex пишет вызов. Он не запускает модель. Когда приложение начинает получать реальных пользователей — особенно когда они начинают генерировать изображения или видео — узкое место смещается. Холодные старты. Ограничения скорости у каждого провайдера модели. Глубина очереди. Стоимость запроса, которая не вписывается в вашу модель выставления счетов. Агент для написания кода не исправит ни одну из этих проблем. Он просто написал клиент, который теперь с ними сталкивается.

Именно здесь стеку генеративного AI-приложения нужен другой слой под кодом.

Стек генеративного AI-приложения в 2026 году

В работающих приложениях сегодня я вижу стек, который обычно состоит из четырёх слоёв. Названия варьируются. Форма — нет.

Слой UI и оркестрации

Фронтенд, оркестрация промптов, состояние диалога, пользовательская логика. Именно здесь Codex и аналогичные AI-инструменты для разработчиков показывают себя лучше всего. Большинство создателей начинают здесь и задерживаются дольше, чем следует.

Слой модели и инференса

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

Хранение, мониторинг и автоматизация рабочих процессов

Объектное хранилище для сгенерированных ресурсов. Наблюдаемость для отслеживания стоимости и времени каждого вызова. Инструменты для рабочих процессов (n8n, Temporal, кастомные оркестраторы) для связывания шагов генерации. Этот слой появляется позже. Но он всегда появляется.

Что делает AI-платформа инференса

AI-платформа инференса — это слой, который превращает «я хочу вызвать модель X» в «вызов возвращается вовремя, по известной стоимости, с обработанными повторными попытками». Она не заменяет провайдеров моделей. Она стоит перед ними.

Доступ к моделям и маршрутизация

Документация Hugging Face по провайдерам инференса хорошо описывает общий паттерн — унифицированный прокси-слой, который стоит между вашим приложением и несколькими AI-провайдерами, обрабатывая аутентификацию, маршрутизацию и переключение при отказах в одном месте. Вы переключаете модели с помощью параметра, а не повторной интеграции. Это важнее, чем кажется. Модель, которую вы выбираете на первой неделе, редко оказывается той моделью, с которой вы выпускаете продукт. Если переключение означает переписывание клиента, вы будете оставаться на неправильной модели дольше, чем нужно.

Пропускная способность, повторные попытки и масштабирование

То, что вам действительно нужно от платформы инференса, — это не скорость в маркетинговом смысле. Это предсказуемость. Никаких холодных стартов при скачках трафика. Идемпотентные повторные попытки при сбое генерации. Ограничения параллелизма, которые поддаются рассуждению. Инженеры Stripe написали один из более чистых публичных материалов об идемпотентности для распределённых систем — запись в блоге Stripe Engineering о проектировании надёжных API с ключами идемпотентности стоит прочитать перед созданием собственного слоя повторных попыток.

Унифицированное выставление счетов и операционный контроль

Когда вы вызываете четырёх провайдеров моделей, вы платите четыре счёта, каждый в разных единицах. Токены для одного. Генерации для другого. Вычислительные секунды для третьего. Единая поверхность выставления счетов выравнивает это. Одна цифра в месяц, разбитая по моделям. Это одно изменение меняет то, как команды принимают решения о выборе моделей, потому что сравнение стоимости перестаёт требовать таблицы и совещания.

Почему API изображений и видео создают другие потребности для бэкенда

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

Асинхронные задачи и долгосрочные медиазадачи

Вызов генерации видео может занять 30 секунд. Или три минуты. Вы не можете держать HTTP-соединение открытым так долго, и не должны. Каждый серьёзный API для изображений и видео работает асинхронно — вы отправляете задание, получаете идентификатор задания, затем получаете вебхук или опрашиваете результат.

Если ваш агент для написания кода по умолчанию генерировал синхронный код API-клиента, вы обнаружите это на собственном горьком опыте.

Обработка ресурсов и хранение вывода

Текстовые выводы небольшие. Шестисекундное видео занимает 5–15 МБ. Где оно будет храниться после генерации? Как долго? Кто платит за хранение? Провайдер модели сохраняет его, вы сохраняете, оба? Это решения, которые должны быть приняты до запуска, а не после. Большинство платформ по умолчанию хранят сгенерированные выводы около 7 дней — проверьте политику той, которую вы выберете, прежде чем строить на этом предположение.

Ограничения, специфичные для моделей, и проектирование откатов

У разных моделей разные ограничения параллелизма, разные фильтры контента, разные форматы вывода. Когда модель A возвращает ошибку или достигает ограничения скорости, платформа должна уметь переключиться на модель B. Построить это самостоятельно — четверть инженеро-года. Купить — это поле в конфиге. Вот где и было узкое место.

Как создателям выбирать свой стек

Правильный стек зависит от того, на каком этапе вы находитесь. Три приблизительных стадии.

Небольшой прототип vs продакшен-приложение

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

Прямые API vs агрегационный слой

Когда вы вышли за рамки прототипа, возникает вопрос: сколько моделей вы вызываете и как часто вы их меняете? Одна модель, низкая частота — прямой API. Три или более моделей, частое A/B-тестирование — агрегационный слой окупается быстро. Даже на уровне SDK тот же паттерн прослеживается — документация реестра провайдеров Vercel AI SDK описывает, как команды управляют несколькими провайдерами через единый интерфейс, чтобы не рассыпать интеграционный код по всему приложению. На уровне инференса агрегационная платформа вроде WaveSpeedAI расширяет эту идею — сотни моделей за одним эндпоинтом, одной аутентификацией, одной поверхностью выставления счетов. Суть не в количестве моделей. Суть в том, чтобы не приходилось проводить повторную интеграцию каждый раз, когда появляется что-то лучше.

Когда добавлять оркестрацию и наблюдаемость

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

Добавляйте и то, и другое до того, как вы столкнётесь с этими моментами, а не после. Я снова и снова учусь этому на собственном горьком опыте.

FAQ

Что такое AI-платформа инференса?

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

Чем платформа инференса отличается от агента для написания кода?

Агент для написания кода пишет код, который вызывает модель. Платформа инференса запускает вызов модели и управляет всем вокруг него — очередями, повторными попытками, откатами, выставлением счетов. Codex и аналогичные AI-инструменты для разработчиков находятся выше слоя инференса, а не заменяют его. Они создают клиент. Платформа обрабатывает то, что происходит после того, как клиент отправляет запрос.

Как AI-приложения соединяют агентов для написания кода с API моделей?

Обычно через сгенерированный клиент. Агент для написания кода пишет API-клиент (часто указывающий на одного провайдера), приложение вызывает этот клиент, а клиент обращается к модели. Когда вы добавляете между ними платформу инференса, клиент указывает на платформу, а платформа разворачивается к реальным провайдерам моделей. Передача управления проста — меняется всё то, что платформа обрабатывает и что исходный клиент не делал.

Когда команде нужна платформа инференса?

При вызове более одной модели, когда задействованы изображения или видео (асинхронные паттерны делают это почти обязательным), или когда надёжность в продакшене начинает иметь большее значение, чем скорость первой версии. Ниже этого порога прямые вызовы API работают. Выше него математика быстро меняется. Более сложный вопрос — точно когда конкретная команда пересекает этот порог — зависит от частоты использования и требований к параллелизму, и стоит проверять актуальную документацию провайдеров, а не строить предположения.

Заключение

Стек генеративного AI-приложения в 2026 году разделился на два чётко различимых слоя. Агенты для написания кода сверху — эта часть в основном решена. AI-платформы инференса снизу — здесь по-прежнему живёт большинство трений в продакшене. Для создателей, выпускающих мультимодальные приложения, AI-платформа инференса больше не является роскошью. Это разница между MVP, который хорошо демонстрируется, и приложением, которое справляется с реальным трафиком, не ломаясь под ним.

Запустите сами. Это расскажет вам больше, чем всё, что я говорю.

Предыдущие публикации: