Cloud-native или edge-агенты: где запускать логику ИИ

Автономный агент, который ходит по API, вызывает функции и принимает решения, физически исполняется где-то. Либо в облаке — на GPU-инстансе или в serverless-функции, либо на краю сети (edge): на роутере, в браузере, на телефоне, в промышленном контроллере. Место запуска определяет три вещи, которые видит пользователь: задержку отклика, приватность данных и итоговый счёт. И четвёртую, которую видит разработчик: как это отлаживать в проде.

Что именно спорят между собой

Cloud-native агент — это процесс, который запускается в вашей инфраструктуре: контейнер в Kubernetes, функция в AWS Lambda или Cloud Run, отдельный сервис за балансировщиком нагрузки. У него доступ к большим моделям, к общей базе состояний, к секретам через vault. Он масштабируется горизонтально и логируется централизованно.

Edge-агент исполняется как можно ближе к источнику данных или к пользователю. Это может быть WASM-модуль в CDN (Cloudflare Workers, Fastly Compute), локальная модель на телефоне через Core ML или ONNX Runtime, агент внутри IoT-шлюза. Данные не покидают периметр, отклик приходит за единицы миллисекунд, но ресурсы жёстко ограничены.

Спор не в том, что «лучше». Спор в том, какую часть графа выполнения агента вы отдаёте наружу, а какую держите у себя.

Агент — это не одна кнопка «запустить в облаке или на краю». Это конвейер шагов, и каждый шаг можно разместить отдельно. Классификация намерения — на устройстве, тяжёлое рассуждение — в облаке, кэш результатов — снова на краю.

Задержка: откуда она берётся

У cloud-native агента задержка складывается из сетевого RTT¹ до дата-центра, времени постановки в очередь и времени инференса модели. Для пользователя в Москве и инстанса во Франкфурте один только сетевой круг — это десятки миллисекунд, и это ещё до того, как модель начала думать. Edge-агент этот сетевой участок почти обнуляет: код исполняется в точке присутствия рядом с пользователем или прямо на устройстве.

Но у edge своя расплата. Модель, которая влезает в 8 ГБ памяти телефона, слабее той, что крутится на облачном GPU. Если задача требует крупной модели, локальный инференс либо невозможен, либо медленнее облачного даже с учётом сетевого пинга.

Сравнение по параметрам

Стоимость: где спрятан счёт

Cloud-native платит за каждый вызов: инстанс-часы GPU, исходящий трафик, вызовы внешних API моделей. При десятках тысяч агентских сессий в сутки этот счёт линеен и заметен. Edge переносит вычисление на железо, за которое уже заплатил пользователь, — но добавляет расходы на доставку модели (её вес в мегабайтах на скачивание) и на инфраструктуру edge-исполнения, если это не устройство, а CDN-воркеры с оплатой за миллион запросов.

Точные цифры тарифов у Cloudflare Workers, Fastly, AWS Lambda@Edge и облачных GPU-провайдеров меняются регулярно и зависят от региона — сверяйте их на актуальных страницах прайсинга, а не по чужим статьям полугодовой давности.

Гибрид: разрезаем граф агента

На практике продакшн почти всегда гибридный. Типичный раскрой шагов:

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

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

Как выглядит маршрутизация в коде

Простейший роутер решает, справится ли локальная модель, и только при неуверенности эскалирует в облако. Схематично на TypeScript для edge-воркера:

// edge-воркер: пробуем локально, эскалируем при низкой уверенности
async function handleRequest(input: string): Promise<string> {
  const local = await localModel.classify(input);

  // порог уверенности подбирается под задачу и метрики качества
  if (local.confidence >= 0.85) {
    return local.answer; // отвечаем на краю, облако не трогаем
  }

  // PII вырезаем до отправки наружу
  const sanitized = stripPII(input);

  const cloud = await fetch("https://api.internal/agent", {
    method: "POST",
    body: JSON.stringify({ prompt: sanitized }),
    headers: { "content-type": "application/json" },
  });

  return (await cloud.json()).answer;
}

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

Что ломается в проде

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

Вторая боль — обновление промптов и логики. В cloud-native вы меняете промпт на сервере, и это действует мгновенно для всех. На edge изменение поведения агента может требовать выката новой версии приложения через сторы с их модерацией и лагом в дни.

Когда какой вариант выбирать

1. Строго edge — если данные нельзя выпускать наружу по требованиям приватности или регламента, либо агент обязан работать офлайн (промышленный контроль, полевые устройства).
2. Строго cloud-native — если задача требует крупной модели, свежих обновлений логики каждый день и полной наблюдаемости, а приватность закрывается договором обработки данных.
3. Гибрид — во всех остальных случаях, а это большинство. Начинайте с облака ради скорости разработки, выносите на edge то, что бьёт по задержке или счёту за трафик.

¹ RTT (round-trip time) — время, за которое сетевой пакет доходит до сервера и возвращается обратно. Складывается из физической задержки канала и обработки на узлах; для трансграничного трафика легко достигает десятков миллисекунд ещё до начала вычислений.