Agentic RAG, или агентный RAG, объединяет большую языковую модель, корпоративную базу знаний и набор инструментов, которыми ИИ-агент может пользоваться для выполнения многошаговых задач. В отличие от обычного RAG, здесь система не ограничивается однократным поиском фрагментов перед ответом: агент может уточнять запрос, повторно обращаться к данным, выбирать источник, вызывать сервисы и проверять результат. Для такого контура важна не только производительность модели, но и работа всей инфраструктуры — от векторной базы и сети до GPU, очереди запросов и KV-кэша.
В официальной демонстрации Supermicro и AMD показан Agentic RAG на сервере с ускорителями AMD Instinct MI350X и живым мониторингом. Разберем, из каких компонентов состоит решение, какие показатели действительно важны в эксплуатации и как подбирать GPU-сервер Supermicro под корпоративный RAG, инференс больших языковых моделей и другие задачи искусственного интеллекта.
Коротко: что показывает эта архитектура
Смысл решения можно сформулировать так: пользователь задает вопрос, агент определяет план действий, получает нужный контекст через MCP-сервер знаний, обращается к языковой модели и формирует ответ с опорой на найденные материалы. Одновременно администратор контролирует состояние вычислительного узла и качество инференса.
В контуре есть два разных уровня, которые нельзя смешивать:
- Прикладной уровень: интерфейс пользователя, агентная логика, MCP-инструменты, поиск, эмбеддинги, векторная база и LLM.
- Инфраструктурный уровень: Kubernetes, сервисы инференса, GPU, CPU, оперативная память, NVMe-хранилище, сеть, охлаждение и питание.
Если следить только за загрузкой ускорителей, можно пропустить очередь запросов или задержку поиска. Если смотреть только на время ответа приложения, легко не заметить перегрев, нехватку VRAM, узкое место в сети или неравномерное распределение нагрузки между GPU. Поэтому live monitoring в таком проекте — не декоративная панель, а часть эксплуатационной архитектуры.
Чем Agentic RAG отличается от обычного RAG
Обычный RAG обычно выполняет предсказуемую последовательность: получает вопрос, ищет близкие фрагменты в базе, добавляет их к промпту и вызывает модель. Такой подход хорошо работает для справочных ответов, когда нужные данные находятся в одном источнике и задачу не требуется разбивать на шаги.
Agentic RAG добавляет управляющий слой. Агент оценивает задачу, решает, достаточно ли найденного контекста, выбирает инструмент и при необходимости делает несколько итераций. Например, сначала он может найти техническое руководство, затем проверить совместимость модели сервера с ускорителем, после этого сопоставить требования проекта и только потом сформировать рекомендацию.
| Критерий | Обычный RAG | Agentic RAG |
|---|---|---|
| Поиск | Как правило, один запрос к базе | Один или несколько запросов по плану агента |
| Инструменты | Обычно только retriever | Поиск, базы данных, API, расчеты и другие сервисы |
| Сценарий | Линейный | Многошаговый и условный |
| Контроль | Фиксированный pipeline | Агент выбирает следующий шаг |
| Основной риск | Нерелевантный контекст | Ошибка плана, лишние вызовы или небезопасный инструмент |
| Наблюдаемость | Качество поиска и ответ модели | Дополнительно трассировка шагов, вызовов и затрат ресурсов |
Agentic RAG нужен не для каждого чат-бота. Если пользователю достаточно найти один пункт инструкции, агентный цикл может только увеличить задержку и стоимость вычислений. Он оправдан там, где вопросы требуют сопоставления нескольких документов, проверки условий, обращения к различным системам или выполнения действий по строгим правилам.
Как устроен AMD Solution Blueprint для Agentic RAG
AMD описывает Solution Blueprints как эталонные приложения на базе AMD Inference Microservices, подготовленные в виде Helm-чартов для Kubernetes. Это не готовая корпоративная система «без доработок», а рабочая отправная точка, которую можно адаптировать под собственные данные, модели, политики доступа и интерфейсы.
В каталоге AMD вариант Agentic RAG (MCP) состоит из двух логически разделенных частей: MCP Knowledge Server и Agentic UI Client. Такое разделение полезно для эксплуатации: интерфейс и агентная логика могут обновляться независимо от сервиса, который отвечает за доступ к корпоративным знаниям.
Типовой запрос проходит по следующей цепочке:
- Пользователь вводит вопрос в интерфейсе.
- Агент определяет цель и формирует план.
- Через Model Context Protocol он вызывает сервер знаний.
- Сервер знаний преобразует запрос в эмбеддинг и ищет релевантные фрагменты.
- Найденные документы и их метаданные возвращаются агенту.
- Агент решает, достаточно ли данных, или выполняет еще один поиск.
- LLM формирует ответ с учетом контекста и истории шагов.
- Пользователь получает результат, а система сохраняет технические метрики и трассировку.
MCP в этой схеме выполняет роль стандартного интерфейса между агентом и инструментом. Он не заменяет векторную базу и не делает ответы достоверными сам по себе. Качество все равно зависит от подготовки документов, разбиения на фрагменты, модели эмбеддингов, фильтрации по метаданным, правил доступа и проверки итогового ответа.
Почему для демонстрации выбрана платформа Supermicro с MI350X
Для Agentic RAG критичен не только объем параметров модели. Во время инференса память ускорителя занимает сама модель, служебные буферы и KV-кэш, объем которого растет вместе с длиной контекста и числом одновременных запросов. Дополнительную нагрузку создают модель эмбеддингов, повторные вызовы агента и параллельная работа нескольких пользователей.
AMD Instinct MI350X имеет 288 ГБ памяти HBM3E и пиковую пропускную способность памяти 8 ТБ/с на один ускоритель. В сервере Supermicro AS-8126GS-TNMR устанавливаются восемь MI325X или MI350X в форм-факторе OAM. В конфигурации с восемью MI350X суммарный объем HBM3E достигает 2,3 ТБ, однако это не означает, что любая модель автоматически использует всю память как единое адресное пространство: способ распределения зависит от движка инференса, параллелизма и программной конфигурации.
Официальная спецификация AS-8126GS-TNMR указывает форм-фактор 8U, два процессора AMD EPYC 9005/9004, до 24 модулей DDR5 RDIMM общей емкостью до 6 ТБ, восемь фронтальных NVMe-отсеков, два SATA-отсека и резервируемые блоки питания. Между ускорителями используется AMD Infinity Fabric Link, а CPU и GPU связаны через PCIe 5.0 x16.
| Компонент | Зачем он нужен в Agentic RAG |
|---|---|
| Большой объем HBM3E | Размещение весов модели, KV-кэша и рабочих буферов |
| Высокая пропускная способность памяти | Быстрый доступ к весам во время генерации токенов |
| Несколько GPU | Tensor/pipeline parallelism, несколько реплик или разделение сервисов |
| AMD EPYC | Подготовка данных, сетевой стек, оркестрация и вспомогательные сервисы |
| DDR5 ECC | Векторная база, кэш, контейнеры и системные процессы |
| NVMe | Модели, индексы, документы, журналы и временные данные |
| Быстрая сеть | Масштабирование между узлами и связь с хранилищем/сервисами |
Подбирая сервер для RAG или LLM, стоит выбирать не «самую мощную систему вообще», а конфигурацию под измеряемую нагрузку. В каталоге собраны как готовые решения, так и серверные платформы Supermicro на AMD EPYC. Для пилота может быть достаточно меньшего числа GPU; восемь ускорителей нужны, когда это подтверждено размером модели, требуемой параллельностью и целевой пропускной способностью.
Как развернуть Agentic RAG
Ниже опишем практическую последовательность.1. Сначала определить сценарий и критерии качества
До выбора модели и оборудования нужно зафиксировать, что именно должен делать агент. «Отвечать по внутренним документам» — слишком широкая задача. Практичнее описать набор проверяемых сценариев: найти регламент, сравнить две спецификации, подготовить перечень совместимых компонентов, сформировать ответ со ссылками на источники.
Для каждого сценария задают:
- допустимые источники;
- роли пользователей и права доступа;
- максимальное время ответа;
- необходимую точность поиска;
- правила отказа, если данных недостаточно;
- формат ссылок на первоисточник;
- список действий, которые агент может выполнять автоматически.
2. Подготовить базу знаний
Документы нужно очистить от повторяющихся колонтитулов, устаревших версий и навигационного шума. Большие PDF или руководства разбивают не по случайному числу символов, а по смысловым разделам. Вместе с фрагментом сохраняют метаданные: тип документа, модель оборудования, версию, дату, язык, подразделение и уровень доступа.
Для технической базы особенно важно нормализовать обозначения моделей. AS-8126GS-TNMR, AS 8126GS TNMR и вариант с лишним пробелом должны находиться как одна сущность. Иначе поиск может возвращать неполный набор документов даже при корректном вопросе.
3. Выбрать модель и профиль инференса
Нужно сравнивать не только качество ответа на нескольких примерах, но и рабочие параметры: объем памяти, длину контекста, скорость генерации, поддержку нужной точности, устойчивость к русскоязычным техническим текстам и работу с инструментами.
Полезный расчет для первого приближения:
рабочая память GPU = веса модели + KV-кэш + служебные буферы + резерв на пики нагрузки.
KV-кэш нельзя считать постоянной величиной. Он зависит от модели, длины контекста, batch size и числа одновременно обслуживаемых последовательностей. Поэтому конфигурацию проверяют нагрузочным тестом на реальных запросах, а не только по размеру файла модели.
4. Развернуть blueprint в Kubernetes
AMD поставляет Solution Blueprints как Helm-чарты. В актуальной документации по развертыванию для корпоративного кластера рекомендуется сформировать манифесты через helm template и применить их командой kubectl apply, а не полагаться на стандартный helm install.
Упрощенная схема команды выглядит так:
name="agentic-rag"
namespace="ai-project"
helm template "$name" oci://docker.io/amdenterpriseai/aimsb-agentic-rag \
| kubectl apply -f - -n "$namespace"
Перед запуском необходимо убедиться, что Kubernetes видит ускорители как доступный ресурс, хранилище соответствует требованиям chart, а секреты для моделей и внешних сервисов заведены в нужном namespace. Если в компании уже есть совместимый сервис LLM, blueprint можно направить на существующий endpoint вместо развертывания еще одной копии модели.
5. Провести приемочное тестирование
Минимальный набор тестов должен включать вопросы с однозначным ответом, вопросы по нескольким документам, отсутствующие в базе сведения, конфликтующие версии документа, запросы пользователя без нужных прав и попытки заставить агента игнорировать инструкции. Отдельно тестируют отказ инструмента, тайм-аут базы, переполнение очереди и перезапуск pod.
Что контролировать в панели мониторинга
Мониторинг Agentic RAG лучше строить в трех слоях: оборудование, инференс и прикладная логика. Одна цифра GPU Utilization не объясняет, почему пользователь ждет ответ.
Метрики оборудования
- загрузка каждого GPU;
- занятая и свободная VRAM;
- температура GPU и памяти;
- энергопотребление и ограничения мощности;
- частоты и признаки throttling;
- PCIe/Infinity Fabric и сетевой обмен;
- загрузка CPU и оперативной памяти;
- задержка и пропускная способность NVMe;
- состояние вентиляторов и блоков питания.
Если один ускоритель постоянно загружен сильнее остальных, нужно проверять схему параллелизма и распределение реплик. Высокая загрузка GPU при небольшой очереди может быть нормальной. Низкая загрузка вместе с большой очередью чаще указывает на ожидание данных, сеть, неэффективный batching или ошибки планирования запросов.
Метрики инференса
AMD AI Workbench выделяет Time to First Token, задержку между токенами, полное время ответа, число выполняющихся и ожидающих запросов, максимальную конкурентность, количество обработанных токенов и использование KV-кэша.
| Метрика | Что показывает | На что обратить внимание |
|---|---|---|
| Time to First Token, TTFT | Сколько пользователь ждет начала ответа | Поиск, очередь, загрузка модели, prefill |
| Inter-Token Latency | Плавность генерации после первого токена | Нагрузка GPU, параллелизм, выбранная точность |
| End-to-End Latency | Полный путь от запроса до готового ответа | Все этапы, включая инструменты и RAG |
| Running / Waiting Requests | Текущая работа и очередь | Недостаток реплик или всплеск нагрузки |
| Max Concurrent Requests | Достигнутая конкурентность | Планирование емкости и нагрузочные тесты |
| KV Cache Utilization | Давление на память при длинном контексте | Лимиты контекста, batch, число реплик |
| Tokens | Реальный объем инференса | Нормирование нагрузки и планирование ресурсов |
Метрики агентного контура
Для Agentic RAG дополнительно нужны:
- число шагов агента на один пользовательский запрос;
- длительность каждого вызова инструмента;
- доля повторных поисков;
- число найденных и реально использованных фрагментов;
- доля ответов со ссылками на источники;
- ошибки MCP-сервера и внешних API;
- отказы из-за недостатка данных;
- успешность контрольного набора вопросов;
- стоимость одного завершенного сценария в GPU-секундах и токенах.
Именно этот слой позволяет увидеть «тихую» проблему: ответ может выглядеть приемлемо и укладываться в SLA, но агент делает пять поисков там, где достаточно одного. Без трассировки такая потеря ресурсов останется незаметной.
Где чаще всего возникают узкие места
Разберём самые популярные проблемные места ниже.Слишком длинный контекст
Попытка передать модели все найденные документы увеличивает prefill, расходует KV-кэш и может ухудшить ответ из-за информационного шума. Лучше повышать точность retrieval, применять фильтры и ранжирование, а не безгранично увеличивать число фрагментов.
Неподходящее разбиение документов
Если таблица совместимости разорвана на несколько несвязанных частей, модель увидит название сервера без условий или ускоритель без примечания. Для технических документов нужно сохранять заголовки, подписи таблиц, единицы измерения и ссылки между разделами.
Медленная векторная база или хранилище
Даже быстрый GPU простаивает, пока приложение ждет retrieval. Важно измерять p50, p95 и p99 отдельно для поиска, reranking, LLM и полного запроса. Среднее время скрывает редкие, но болезненные задержки.
Неравномерное распределение между GPU
Причиной могут быть разные размеры запросов, неподходящий batching, закрепление сессий за одной репликой или некорректная конфигурация параллелизма. Нужны метрики по каждому GPU и каждой реплике, а не только сумма по серверу.
Сеть между вычислением и данными
В распределенном RAG большие объемы данных проходят между объектным хранилищем, векторной базой, сервисом эмбеддингов и LLM. При масштабировании на несколько серверов сеть становится частью вычислительного контура. Ее проектируют одновременно с GPU-узлами, а не добавляют после запуска.
Для каких задач подходит Agentic RAG
Разберём примеры задач ниже.Техническая поддержка и сервис
Агент может найти руководство по конкретной модели, проверить версию документа, сопоставить симптомы с регламентом и подготовить ответ инженеру. Критически важно выводить ссылки на использованные источники и не разрешать автоматические действия без проверки.
Подбор серверной конфигурации
Система способна последовательно проверить форм-фактор, процессорную платформу, память, GPU, питание, охлаждение и сеть. Такой помощник не заменяет инженера, но сокращает время первичной обработки ТЗ и подсвечивает несовместимые требования.
Корпоративный ассистент по регламентам
Вместо поиска по папкам сотрудник задает вопрос в естественной форме. Агент определяет подразделение, выбирает актуальную версию положения и формирует ответ в пределах прав пользователя.
Аналитика по нескольким внутренним системам
Через MCP-инструменты агент может получить сведения из базы знаний, CMDB, системы заявок и инвентаризации. Здесь особенно важны аудит вызовов, минимальные права и запрет на произвольные операции записи.
Работа с научной и инженерной документацией
Agentic RAG полезен для многошагового поиска по отчетам, спецификациям и результатам экспериментов. Но численные выводы следует проверять отдельными инструментами расчета, а не доверять арифметике языковой модели.
Безопасность и качество ответа
Корпоративный RAG нельзя защищать только системным промптом. Ограничения должны действовать на уровне каждого сервиса.
- Проверять права до retrieval. Документ, который пользователь не имеет права видеть, не должен попадать в контекст модели.
- Ограничивать MCP-инструменты. Агенту выдают только необходимые функции и минимальные разрешения.
- Разделять чтение и изменение данных. Операции записи требуют дополнительной проверки или подтверждения человеком.
- Хранить происхождение фрагментов. Ответ должен ссылаться на документ, версию и раздел.
- Фильтровать инструкции внутри документов. Текст из базы знаний считается недоверенным контентом, а не командой для агента.
- Контролировать журналы. В логах могут оказаться персональные данные, коммерческая информация и содержимое запросов.
- Проводить регулярную оценку. Набор эталонных вопросов запускают после обновления модели, индекса или правил агента.
Какие серверы посмотреть для проекта на AMD Instinct
Система из демонстрации — Supermicro AS-8126GS-TNMR с восемью OAM-ускорителями MI350X. Если проекту нужна именно эта конфигурация, ее SKU, состав и условия поставки следует согласовать в рамках проектного подбора. В каталоге также представлены близкие по назначению, но не идентичные решения:
- Supermicro AS-5126GS-TNRT — 5U-система с поддержкой до восьми двухширинных PCIe GPU, включая AMD Instinct MI350P;
- Supermicro AS-5126GS-TNRT2 — 5U-вариант с поддержкой до десяти PCIe GPU, включая MI350P;
- Supermicro AS-A126GS-TNMR — многопроцессорная GPU-система, в текущей карточке заявлена поддержка AMD Instinct MI355X.
MI350X, MI350P и MI355X нельзя считать взаимозаменяемыми только потому, что они относятся к одному поколению ускорителей. Отличаются форм-фактор, энергопотребление, охлаждение, способ установки и поддерживаемая серверная платформа. Для PCIe-вариантов полезен отдельный обзор 5U GPU-серверов Supermicro с AMD Instinct MI350P.
Перед заказом нужно подтвердить у технического специалиста точный SKU сервера, тип ускорителей, число GPU, процессоры, объем памяти, сетевые адаптеры, схему питания и требования ЦОД. На странице категории можно сравнить другие серверы и серверные платформы Supermicro для ИИ, HPC и корпоративных нагрузок.
Частые вопросы
Ниже разберём самые популярные вопросы по применению.Что такое Agentic RAG простыми словами?
Это RAG-система, в которой языковая модель не только получает заранее найденный контекст, но и управляет последовательностью действий: выбирает источник, вызывает инструменты, повторяет поиск и проверяет, достаточно ли данных для ответа.
Обязательно ли использовать MCP?
Нет. Агентную систему можно построить на собственных API и функциях. MCP полезен как единый интерфейс для подключения инструментов и источников, но безопасность, права доступа и качество данных все равно проектируются отдельно.
Нужны ли восемь MI350X для любого корпоративного RAG?
Нет. Число GPU выбирают по размеру модели, длине контекста, количеству пользователей, целевой задержке и требуемой отказоустойчивости. Пилот следует начинать с нагрузочного профиля, а не с максимальной конфигурации.
Чем MI350X отличается от MI350P в контексте сервера?
MI350X выполнен как OAM-модуль и требует специализированной платформы. MI350P — PCIe-ускоритель для совместимых серверов со слотами расширения. Нельзя переносить список совместимости одной модели на другую без проверки спецификации производителя.
Какие метрики важнее всего для пользователя?
TTFT показывает время до появления первого токена, inter-token latency — плавность генерации, end-to-end latency — полное время ответа. Для диагностики к ним добавляют очередь, загрузку GPU, VRAM, KV-кэш и длительность retrieval/tool calls.
Почему GPU может быть загружен слабо при медленном ответе?
Система может ждать векторную базу, внешний API, сеть или подготовку промпта. Причиной также бывают маленький batch, ошибки балансировки и последовательное выполнение шагов агента.
Можно ли развернуть AMD Solution Blueprint без Kubernetes?
Blueprint рассчитан на Kubernetes и поставляется как Helm-чарт. Отдельные компоненты можно собрать иначе, но это уже будет самостоятельная архитектура, а не стандартное развертывание blueprint.
Что проверить перед промышленным запуском?
Права доступа к документам, защиту инструментов, качество retrieval, поведение при отсутствии ответа, нагрузочные показатели p95/p99, восстановление после отказов, журналы, резервное копирование индекса и процедуру обновления моделей.
Вывод
Демонстрация Agentic RAG на Supermicro с AMD Instinct MI350X показывает правильный фокус: для корпоративного ИИ важна не одна модель и не одна цифра производительности, а наблюдаемый программно-аппаратный контур. MCP-сервер знаний, агент, векторный поиск, сервис инференса, Kubernetes и GPU должны контролироваться как единая система.
При подборе инфраструктуры сначала фиксируют сценарии, качество и профиль нагрузки, затем рассчитывают память и параллельность, после чего выбирают сервер, сеть, хранилище и охлаждение. Такой порядок снижает риск купить мощную конфигурацию, которая простаивает из-за узкого места вне GPU, или, наоборот, недооценить KV-кэш и конкурентную нагрузку.
Для подбора Supermicro под Agentic RAG, корпоративный LLM, обучение или инференс можно направить техническое задание специалистам: они помогут сопоставить модель, ускорители, память, сеть и условия установки в ЦОД.
Официальные источники
- AMD: каталог Solution Blueprints
- AMD: обзор Solution Blueprints
- AMD: развертывание Solution Blueprints с Helm
- AMD AI Workbench: метрики инференса
- AMD Instinct MI350X: спецификация ускорителя
- Supermicro AS-8126GS-TNMR: datasheet
