Intel предлагает смотреть на агентный ИИ без привычной магии вокруг моделей: в корпоративной среде узкое место чаще находится не в качестве ответа LLM, а в пропускной способности всей платформы. После тысяч экспериментов с агентными нагрузками компания пришла к приземленному выводу: если бизнесу нужна не красивая демонстрация, а рабочая автоматизация, придется считать агентов на vCPU, следить за P95-задержкой и по умолчанию масштабироваться горизонтально.
Об этом пишет MIT Technology Review в партнерском материале, подготовленном совместно с Intel. Главная мысль простая: агентный ИИ для крупных компаний — это не «чат-бот получше», а программные агенты, которые доводят задачу до конца через людей, бизнес-процессы, данные и корпоративные системы. Поэтому слабое место может оказаться где угодно: в доступе к данным, оркестрации, инструментах, памяти, наблюдаемости или в том, как платформа переживает пиковую нагрузку.
Пять выводов Intel для корпоративных команд
Intel выделяет пять практических выводов. Первый: агентные системы нужно воспринимать как большую системную задачу, а не как еще один сценарий инференса. Второй: многие нынешние инструменты тестирования плохо измеряют поведение всей системы целиком. Третий: емкость стоит планировать не по числу агентов, а по плотности агентов на виртуальное ядро. Четвертый: главная эксплуатационная метрика — не средняя загрузка CPU, а задержка выполнения задач. Пятый: для платформ с агентами базовый вариант масштабирования — горизонтальный, а не вертикальный.
В качестве основы для испытаний Intel расширила Terminal-Bench — open source-набор для тестирования ИИ-агентов с профилированием, телеметрией и возможностью повторного прогона. Важная деталь: компания использовала детерминированное воспроизведение ответов LLM. Проще говоря, ответы модели один раз записывали, а затем одинаково воспроизводили во всех следующих тестах. Это позволило убрать шум от вариативности модели и посмотреть, где именно агент теряет время уже на уровне инфраструктуры и исполнения задач.
Для крупного бизнеса это полезнее очередного сравнения в духе «какая модель умнее на бенчмарке». В промышленной среде систему обычно ломает не качество демонстрации, а очередь из воркеров, которые одновременно дергают базы данных, файловые системы, компиляторы и внутренние API.
Какие метрики Intel советует считать
Вместо фокуса только на модели Intel предлагает шесть рабочих метрик для платформенной команды: долю успешно завершенных задач, стоимость одной задачи, время выполнения, пропускную способность, плотность агентов на vCPU и задержку. Такой набор показывает не только качество самого агента, но и то, сколько таких агентов инфраструктура вообще выдержит и во что это обойдется при росте нагрузки.
Особый акцент Intel делает на плотности агентов — количестве агентов на виртуальное ядро. Логика здесь простая: 10 агентов на машине с 8 vCPU и 20 агентов на машине с 16 vCPU будут вести себя сопоставимо, если плотность одинакова. Это дает архитекторам переносимый способ сравнивать инстансы разного размера и поколения процессоров.
Но целевая плотность зависит от сценария. Пользовательские ассистенты и интерактивные помощники требуют меньшей плотности, потому что там критична отзывчивость. А пакетные ИТ-процессы, где никто не ждет ответ с секундомером, можно уплотнять заметно сильнее. Иными словами, один и тот же агентный ИИ для службы поддержки и для ночной обработки тикетов нужно планировать по-разному, даже если модель под капотом одна и та же.
Не менее показателен тезис про наблюдаемость. Средняя загрузка CPU, на которую любят опираться в классическом мониторинге, для агентных систем оказывается слабым сигналом. Причина понятна: агент работает рывками. Сначала ждет ответ модели, потом недолго, но интенсивно считает, вызывает инструмент, читает результат, снова ждет и снова считает. На графике это легко выглядит как «в среднем все нормально», хотя в реальности именно короткие всплески уже создают очереди, раздувают задержки на длинном хвосте и портят пользовательский опыт.
Поэтому Intel рекомендует смотреть прежде всего на P95 task latency, а уже потом подтверждать проблему по росту общей длительности задач. Для SRE-команд и платформенных инженеров это звучит знакомо: средняя температура по серверной редко объясняет, почему конкретный пользователь ждет в три раза дольше.
Почему это важно для рынка
Набор задач в тестах Intel был намеренно широким: компиляция, тестирование, операции с базами данных, булева логика, интерпретация, трассировка лучей, сжатие, линейная алгебра, перекодирование видео и обучение ML-моделей. Такой набор нужен, чтобы не свести разговор к одному частному сценарию вроде генерации кода. Это полезный сигнал для рынка: корпоративный агентный ИИ будет жить не в вакууме, а среди очень разных нагрузок, где часть шагов упирается в CPU, часть — в ввод-вывод, часть — в сеть и внешние сервисы, а часть — в правила доступа и аудит действий.
Отсюда и рекомендация по масштабированию: по умолчанию выбирать горизонтальный рост. Добавление новых узлов чаще лучше совпадает с природой полу-независимых агентов, помогает держать нужное соотношение агентов на vCPU, повышает отказоустойчивость и нередко обходится дешевле. Вертикальное масштабирование Intel оставляет для более тяжелых вычислительных всплесков, ограничений на разделение состояния, требований к локальности памяти или лицензионных ограничений.
Для бизнеса вывод трезвый: первые успешные внедрения агентного ИИ будут не там, где компания хочет «что-нибудь инновационное с агентами», а там, где процесс уже формализован и измерим. Intel прямо перечисляет такие зоны: создание кода, фермы регрессионного тестирования, разбор тикетов, рыночная аналитика и проверки безопасности. Общий знаменатель один: есть правила, есть SLA, есть понятная цена ошибки и есть способ измерить, стало ли быстрее или дешевле.
Для российских команд, которые строят внутренние ИИ-платформы, логика тоже знакомая: если агент должен пройти через корпоративные данные, инструменты, очереди задач и контроль доступа, то слабым местом почти наверняка станет не только модель. Вопрос уже не в том, может ли LLM спланировать многошаговую задачу, а в том, можно ли заставить десятки или сотни таких агентов выполнять ее предсказуемо, с понятной себестоимостью и без сюрпризов для продакшена.
Следующий практический шаг для рынка очевиден: агентные платформы будут оценивать не по качеству демонстраций, а по тому, как они держат нагрузку и считают экономику в реальной эксплуатации. Подробности исходного материала — в .