# Helion и разделение выполнения агента и инференса

Вариант Helion только с CPU выделяет отдельный уровень исполнения агентов. Расчёт мощности должен учитывать инструменты, вызовы моделей и зависимости между этапами.

Автор: Редакция Retrivium
Language: ru
Разбор опубликован: 2026-11-03
Дата события: 2026-10-12
Первоисточник новости: https://ir.amd.com/news-events/press-releases/detail/1301/introducing-amd-helion-agentic-ai-compute-at-rack-scale
Канонический URL: https://retrivium.ai/ru/retrospectives/retro-helion-cpu-agents-inference-split/

Helion делает заметным важное различие: агент потребляет ресурсы при выполнении инструментов, а также когда спрашивает модель о следующем действии. Поэтому ориентированный на CPU уровень исполнения может расти рядом с GPU-инференсом. Если считать оба этапа единой неразличимой AI-нагрузкой, становится непонятно, какой ресурс ограничивает завершение полезной задачи.

## Сначала появилось обязательство по GPU

[Объявление AMD и Meta](https://ir.amd.com/news-events/press-releases/detail/1279/amd-and-meta-announce-expanded-strategic-partnership-to-deploy-6-gigawatts-of-amd-gpus) от 24 февраля 2026 года документировало обязательство по развёртыванию нескольких поколений GPU. Оно создавало понятную историю предложения: более крупным AI-системам понадобится значительная мощность ускорителей. Это важная предпосылка, но она не описывает всё, что агент делает между обращениями к модели.

Представим помощника программиста: он получает предлагаемый патч, компилирует результат, запускает тесты и возвращает ошибки модели. Генерация токенов и компиляция связаны рабочим процессом, но используют разные среды исполнения. Учёт только серверов моделей оставляет второй этап за пределами расчёта мощности и затрудняет объяснение задержки всей задачи.

## Общая дорожная карта расширила рамку

[Объявление платформы AMD 23 июля](https://ir.amd.com/news-events/press-releases/detail/1294/aai-2026-amd-delivers-full-stack-compute-for-the-agentic-ai-era) рассматривало вычисления как задачу полного стека. Ретроспективная гипотеза состоит в том, что рост агентного исполнения делает такую рамку эксплуатационно полезной: ускоритель способен ожидать инструментов, а среда инструментов — ответа инференса.

Из этого не выводится определённое соотношение CPU и GPU. Рабочие процессы различаются частотой вызовов инструментов, объёмом их работы и возможностью перекрывать этапы. Схема стойки не может определить эти свойства по количеству параметров модели. Для измерения требуются данные самой последовательности действий приложения.

## Helion задаёт форм-фактор уровня исполнения

[Объявление Helion 12 октября](https://ir.amd.com/news-events/press-releases/detail/1301/introducing-amd-helion-agentic-ai-compute-at-rack-scale) включает конфигурацию только с CPU и вариант с CPU и GPU. Значение первого варианта архитектурное: спрос на AI может создавать крупный уровень исполнения без ускорителя модели в каждой его единице.

Это разделение помогает уточнить ответственность. Команда serving может управлять размещением модели и допуском запросов, а команда исполнения — изоляцией процессов, средами инструментов и состоянием рабочего пространства. Здесь приведены примерные эксплуатационные роли, а не предписанная AMD организационная структура. Их смысл — сделать зависимость между этапами явной.

## Проследим задачу по ресурсным этапам

Короткая карта процесса показывает то, чего нет в GPU-инвентаризации:

| Этап | Вопрос о ресурсе |
| --- | --- |
| Сгенерировать предлагаемое изменение | Какой маршрут модели его обслуживает? |
| Собрать проект | Какая среда запускает компилятор? |
| Проверить тесты и результат | Где живут процессы и временные файлы? |
| Запросить следующий шаг модели | Как возвращается и допускается вывод инструментов? |

Полезный результат такой карты — граф зависимостей. Медленная сборка удерживает сессию агента открытой, не занимая GPU непрерывно. Переполненная очередь модели оставляет подготовленные среды инструментов без работы. Ни одно состояние нельзя диагностировать только по общей загрузке ускорителей: нужен переход между конкретными этапами исполнения.

## Рассчитываем завершённую работу через границу

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

[Роли CPU и GPU](/ru/journal/what-is-inference/) объясняют границу исполнения модели, а [размещение NUMA](/ru/journal/numa-and-gpu-servers/) показывает топологические ограничения даже богатого CPU уровня. Октябрьская схема расширяет разговор о мощности, не предоставляя универсальной формулы расчёта.