Сервер для RAG и ИИ-агентов нельзя выбирать только по количеству и мощности GPU. Быстродействие зависит от всей цепочки: чтения документов, построения индекса, поиска, работы процессора и оперативной памяти, передачи данных по сети, обработки длинного контекста и размещения KV-кэша. Для пилотного проекта компоненты можно объединить на одном узле, но рабочую конфигурацию следует рассчитывать по размеру базы знаний, числу одновременных запросов и допустимой задержке.
RAG (Retrieval-Augmented Generation) — это генерация ответа с поиском по внешней для модели базе знаний, будь то внутренняя вики компании, источники в интернете или папка с документами. Перед обращением к большой языковой модели система находит подходящие фрагменты документов и добавляет их в запрос. ИИ-агент выполняет больше действий: уточняет задачу, обращается к базам и программным интерфейсам, запускает повторный поиск, проверяет промежуточный результат и затем формирует ответ.
Поэтому высокая скорость генерации токенов еще не означает, что пользователь быстро увидит результат. GPU может простаивать, пока сервер читает индекс с накопителя, фильтрует документы по правам доступа или ждет ответ внешней системы.
Из каких этапов состоит RAG-система
У RAG есть два режима работы: подготовка базы знаний и обработка запроса. Они нагружают оборудование по-разному.
Подготовка базы знаний
До запуска поиска система должна:
- Получить документы из файлов, порталов, почты или баз данных.
- Извлечь текст из PDF, офисных документов, HTML-страниц, изображений и таблиц.
- Распознать сканы, очистить данные и удалить дубли.
- Разделить материал на фрагменты.
- Создать для каждого фрагмента векторное представление.
- Сохранить текст, векторы, метаданные и права доступа.
- Построить поисковый индекс.
- Подготовить резервную копию исходных данных и конфигурации.
Здесь особенно важны процессор, оперативная память и скорость записи NVMe. Массовая загрузка способна занять все ядра, создать очередь операций ввода-вывода и вытеснить рабочий индекс из системного кэша.
Обработка запроса
После получения вопроса система:
- Проверяет пользователя и его права.
- Создает вектор вопроса.
- Ищет кандидатов в векторной базе.
- Фильтрует их по языку, дате, типу документа и уровню доступа.
- Повторно ранжирует найденные фрагменты.
- Собирает контекст для языковой модели.
- Генерирует ответ и сохраняет служебные данные.
В агентном сценарии эта последовательность повторяется. В документации NVIDIA по агентному RAG описана схема, где задача делится на этапы, а отдельные мини-агенты выполняют поиск, формируют частичный ответ и при нехватке данных запускают новый запрос. Один вопрос пользователя поэтому может породить десятки обращений к поиску, модели и внешним системам.
| Этап | Основная работа | Главные ресурсы | Возможное ограничение |
|---|---|---|---|
| Загрузка документов | Чтение, распознавание, очистка | Процессор, RAM, NVMe | Медленный разбор файлов |
| Создание векторов | Работа модели представлений | GPU или процессор, RAM | Низкая пакетная скорость |
| Построение индекса | Запись структуры поиска | RAM, NVMe, процессор | Нехватка памяти |
| Поиск | Чтение индекса и фильтрация | RAM, NVMe, процессор | Промахи системного кэша |
| Повторное ранжирование | Оценка найденных фрагментов | GPU или процессор | Очередь запросов |
| Обработка контекста | Чтение длинного входа моделью | GPU, KV-кэш | Долгое ожидание первого токена |
| Генерация | Последовательное создание ответа | GPU, KV-кэш | Низкая скорость вывода |
| Действия агента | Вызовы API и повторные циклы | Процессор, сеть | Суммирование задержек |
За что отвечает GPU
GPU выполняет вычисления языковой модели, модели создания векторов и модели повторного ранжирования. Эти задачи не обязательно должны работать на одном ускорителе.
Видеопамять расходуется не только на веса модели. В ней размещаются:
- рабочие буферы движка;
- KV-кэш активных запросов;
- временные данные обработки контекста;
- дополнительные модели;
- резерв под пики и фрагментацию.
Поэтому модель, которая помещается при одиночном запуске, может завершаться ошибкой при росте параллельности. Обратная ситуация тоже типична: GPU загружен слабо, но ответы медленные. Тогда ускоритель, вероятно, ждет поиск, токенизацию, чтение с диска или сетевой вызов. Покупка более мощной GPU не устранит задержку в другом слое.
Почему важен процессор
Процессор обслуживает операции вокруг языковой модели:
- извлечение и очистку текста;
- распознавание документов;
- разбиение на фрагменты и токенизацию;
- фильтрацию по метаданным;
- работу векторной базы;
- контейнеры, очереди и программные интерфейсы;
- шифрование трафика;
- инструменты ИИ-агента.
Для фоновой индексации важны ядра, но нужно учитывать и производительность отдельного ядра, число каналов памяти, доступные линии PCIe и схему подключения устройств.
Если GPU подключена к одному процессору, а накопитель или сетевой адаптер обслуживаются другим узлом NUMA, данные проходят между сокетами. При высокой нагрузке это увеличивает задержку и создает конкуренцию за межпроцессорное соединение.
Однопроцессорные серверы на AMD EPYC удобны там, где требуется много линий PCIe и каналов памяти без разделения ресурсов между сокетами, при корректной настройке NUMA и с учётом архитектуры процессора. Серверы на Intel Xeon доступны в широком наборе одно- и двухпроцессорных конфигураций. Выбирать платформу нужно по реальной топологии PCIe, числу ускорителей, объему памяти и доступным дисковым корзинам, а не только по семейству процессора.
Внутренняя компоновка многоускорительного AI-сервера: GPU, процессорная зона, питание и система охлаждения.
Источник изображения: Dell Technologies
Оперативная память: индекс и системный кэш
Размер исходных документов не показывает, сколько RAM потребуется системе. После разбиения один документ превращается во множество фрагментов. Для каждого хранятся вектор, текст, идентификатор, метаданные и часть поисковой структуры.
В оперативной памяти одновременно могут находиться:
- активные векторы и поисковый граф;
- индексы полей для фильтрации;
- часто используемые фрагменты;
- системный файловый кэш;
- процессы базы и очереди запросов;
- новая версия индекса при перестроении;
- выгруженная из видеопамяти часть модели или KV-кэша.
Векторная база может хранить часть данных на диске. Например, Qdrant предлагает отдельно рассчитывать векторы, метаданные, индексы, репликацию и способ хранения. При дисковом размещении скорость сильнее зависит от объема системного кэша и задержки накопителя.
Если рабочий набор не помещается в RAM, сервер чаще читает страницы с NVMe. Средняя задержка может выглядеть приемлемо, а отдельные запросы будут выполняться заметно дольше. Файл подкачки проблему не решает, поскольку находится на том же NVMe. Запас памяти также нужен для обновлений: некоторое время старая версия индекса обслуживает запросы, а новая уже занимает RAM и место на диске.
Почему для RAG нужен быстрый NVMe
На накопителях размещаются исходные документы, очищенный текст, фрагменты, векторы, индекс, журналы базы, файлы моделей, временные данные перестроения и резервные копии.
Нагрузка сочетает разные операции:
- последовательное чтение крупных файлов моделей;
- случайное чтение небольших блоков индекса;
- длительную запись при загрузке документов;
- синхронную запись журнала базы;
- чтение старой и запись новой версии индекса;
- фоновое резервное копирование.
Поэтому важна не только пиковая скорость из спецификации. Нужно оценивать задержку операции, число операций ввода-вывода, устойчивую скорость длительной записи, ресурс перезаписи и защиту данных при отключении питания. Потребительский SSD может быстро работать в коротком тесте, но замедляться после заполнения внутреннего буфера.
Базу, журналы, модели и резервные копии нежелательно без расчета размещать на одном массиве. Перестроение индекса или копирование снимка тогда конкурирует с пользовательским поиском. Также стоит учесть, что RAID помогает пережить отказ диска и\или получить дополнительную производительность, но не заменяет резервную копию.
Локальные NVMe обычно дают минимальную задержку. Общее хранилище упрощает работу нескольких узлов, но добавляет сетевой путь. В совместимой архитектуре NVIDIA GPUDirect Storage сокращает лишние копирования через системную память при передаче данных между хранилищем и GPU. Польза зависит от программного обеспечения, файловой системы, топологии PCIe и характера нагрузки.
Сеть: важна не только пропускная способность
На одном сервере с локальной базой большая часть обмена остается внутри системы. После разделения компонентов сеть становится частью каждого запроса.
Через нее проходят:
- запросы пользователей и ответы;
- обращения к векторной базе;
- найденные фрагменты и метаданные;
- вызовы корпоративных API;
- доступ к общему хранилищу;
- репликация индекса;
- журналы и резервные копии;
- обмен между узлами распределенного вывода.
На время ответа влияют задержка, ее колебания, потери пакетов и перегрузка очередей. Небольшой пакет с результатом поиска способен задержать генерацию, даже если средняя загрузка канала невысока.
Для одиночного сервера с локальными NVMe может быть достаточно даже гигабитной сети центра обработки данных, но лучше конечно ориентироваться на 10 гигабит. Каналы 25 или 100 Гбит/с и прямой доступ к памяти оправданы при удаленном хранилище, распределенной модели, репликации большого индекса или переносе KV-кэша между узлами. Резервное копирование и перестроение индекса не должны бесконтрольно занимать тот же канал, что и рабочие запросы.
KV-кэш: скрытый потребитель видеопамяти
Во время обработки текста модель сохраняет промежуточные данные механизма внимания для уже прочитанных токенов. Это позволяет не пересчитывать их при создании каждого следующего токена. Такие данные называют KV-кэшем.
KV-кэш не является векторной базой, копией документов или весами модели. Это рабочая память активных последовательностей. Чем длиннее контекст и больше параллельных запросов, тем больше места она занимает.
Упрощенная оценка выглядит так:
число слоев × 2 × число KV-голов × размер головы × число токенов × число последовательностей × размер одного элемента.
Множитель 2 учитывает ключи и значения. Размер элемента зависит от формата данных, а число KV-голов — от архитектуры модели.
Для условной модели с 80 слоями, 8 KV-головами, размером головы 128, двумя байтами на значение и контекстом 32 768 токенов кэш потребует около 10 ГБ на одну полностью заполненную последовательность. Восемь независимых последовательностей — около 80 ГБ, шестнадцать — около 160 ГБ. Расчет не учитывает служебные расходы, распределение по GPU и повторное использование общих префиксов, но показывает, почему модель помещается при одиночном запросе и перестает помещаться под нагрузкой.
Как уменьшить расход KV-кэша
Обычно сочетают несколько методов:
- ограничивают типичную и максимальную длину контекста;
- управляют числом активных последовательностей;
- размещают кэш блоками и освобождают неиспользуемые страницы;
- повторно используют общие системные инструкции;
- уменьшают точность хранения;
- переносят часть кэша в оперативную память;
- используют NVMe или внешнее хранилище для повторяемых префиксов;
- разделяют обработку входа и генерацию между узлами.
Согласно документации vLLM, хранение KV-кэша в FP8 сокращает его объем и позволяет разместить больше токенов. Такой режим нужно проверять на выбранной модели и ускорителе: экономия памяти может сопровождаться дополнительными вычислениями и требованиями к масштабированию значений.
Почему длинный контекст задерживает первый токен
Сначала модель должна прочитать инструкции, историю и найденные документы. Только после этого начинается генерация. Первый токен может задерживаться из-за слишком большого контекста, очереди на GPU, нехватки видеопамяти или невозможности повторно использовать ранее рассчитанный префикс.
Поэтому большое контекстное окно не следует считать бесплатным способом повысить качество. Сначала стоит улучшить поиск, удалить дубли и точнее ранжировать фрагменты, а не передавать модели все найденные документы.
Типичные узкие места
| Симптом | Вероятная причина | Что измерить | Что менять |
|---|---|---|---|
| GPU простаивает, ответы медленные | Поиск, процессор или сеть | Задержку этапов, загрузку ядер | Оптимизировать поиск и передачу |
| Первый токен появляется долго | Большой контекст или очередь | Длину входа, ожидание, обработку контекста | Сократить контекст, настроить кэш |
| Генерация идет медленно | Ограничение GPU или памяти | Токены в секунду, загрузку GPU | Настроить модель и параллелизм |
| Поиск замедляется при росте базы | Индекс не помещается в RAM | Чтение NVMe, промахи кэша | Добавить RAM или изменить хранение |
| Индексация ухудшает ответы | Конкуренция за процессор и NVMe | Очередь диска, загрузку ядер | Разнести процессы или задать лимиты |
| Заканчивается видеопамять | Растет KV-кэш | Число последовательностей и токенов | Снизить параллельность или выгрузить кэш |
| Фильтры работают медленно | Не подходят индексы метаданных | Поиск с фильтрами и без них | Создать индексы нужных полей |
| Копирование увеличивает задержку | Общий диск или канал | Дисковый и сетевой трафик | Выделить окно или отдельный путь |
Оптимизировать нужно полный путь запроса, а не отдельную цифру в тесте GPU. Ускорение поиска на доли секунды может дать больший эффект, чем рост скорости генерации, особенно если агент выполняет поиск несколько раз.
Какие показатели измерять
На уровне пользователя важны полное время ответа, время до первого токена, медиана, 95-й и 99-й процентили, число шагов агента и доля ошибок.
Для модели измеряют:
- число входных и выходных токенов;
- ожидание в очереди;
- время обработки контекста;
- скорость генерации;
- занятую видеопамять;
- число активных последовательностей;
- заполнение и повторное использование KV-кэша.
Для поиска и сервера нужны время векторизации, поиска, фильтрации и повторного ранжирования, загрузка отдельных ядер, использование RAM и системного кэша, задержка NVMe, сетевая задержка и повторные передачи.
Среднее значение скрывает редкие провалы. Если один из ста запросов длится 20 секунд, пользователи заметят проблему, даже когда среднее время остается приемлемым.
Один сервер или несколько узлов
Все компоненты можно разместить на одном сервере при небольшой базе, ограниченном числе пользователей и редких обновлениях. Такая схема проще, дешевле и создает меньше сетевых переходов.
По мере роста появляются ограничения:
- индексация конкурирует с выводом модели;
- векторной базе не хватает RAM;
- дисковые операции мешают поиску;
- поиск и генерацию нельзя масштабировать независимо;
- отказ узла останавливает всю систему.
Платформа наподобие Dell PowerEdge R760 может использоваться как вычислительный или поисковый узел, но конфигурацию нужно проверять по числу поддерживаемых GPU, райзерам, питанию, охлаждению и варианту дисковой корзины. Одинаковое название сервера не означает одинаковые возможности каждой сборки.
Разделение модели и векторной базы оправдано, когда индекс растет быстрее модельной нагрузки, документы обновляются постоянно или несколько сервисов используют одну базу знаний. Тогда поисковые узлы наращивают по RAM и NVMe, а узлы вывода — по GPU.
Для крупных систем полезен отдельный контур загрузки данных. Он разбирает документы, создает векторы, строит новую версию индекса и проверяет ее до публикации. Рабочая база продолжает обслуживать запросы без конкуренции с массовой индексацией.
Перенос KV-кэша в быстрое хранилище нужен не всем. Он может быть полезен при длинных повторяющихся префиксах и многошаговых диалогах, но повышает требования к сети и накопителям. В испытании Dell Technologies использовались vLLM, LMCache, внешнее хранилище и сеть с прямым доступом к памяти. Результаты относятся к конкретному стенду и не заменяют тестирование собственной нагрузки.
Как рассчитать конфигурацию
Расчет начинают с профиля нагрузки, а не с модели корпуса.
Модельная часть
Нужно определить основную модель, формат весов, число GPU, типичный и максимальный контекст, длину ответа, число параллельных запросов и допустимое время до первого токена. Дополнительно учитывают модели создания векторов и ранжирования.
Видеопамять
К весам добавляют рабочие буферы, KV-кэш, дополнительные модели и запас под пики. Расчет выполняют для реального числа одновременных последовательностей.
Поисковый слой
Учитывают число документов, среднее количество фрагментов, размерность векторов, тип чисел, структуру индекса, метаданные, реплики, частоту обновлений и рост базы.
Оперативная память
Суммируют активный индекс, векторы, индексы метаданных, системный кэш, процессы базы, память для перестроения и возможную выгрузку из GPU. Нужен запас, чтобы пиковая нагрузка не переводила систему в постоянное чтение с диска.
Накопители
На NVMe должны помещаться документы, фрагменты, векторы, индекс, журнал, временная копия при перестроении, модели, снимки и локальные копии. Проверяют ресурс записи и скорость при одновременном чтении и обновлении.
Топология сервера
Платформа должна поддерживать выбранные GPU, NVMe, сетевые адаптеры и контроллеры без критичного разделения линий. Также проверяют расположение устройств относительно процессоров, питание, охлаждение и возможность расширения. Для подобных нагрузок можно рассматривать серверы Dell для AI, но выбирать следует конкретную сборку, совместимую с нужными ускорителями и накопителями.
Сквозной тест
Проверка должна повторять рабочую цепочку:
вопрос → создание вектора → поиск → фильтрация → повторное ранжирование → сборка контекста → обработка моделью → действия агента → ответ.
Одновременно запускают фоновые обновления и журналирование. Тест одной языковой модели на заранее подготовленном запросе показывает только часть производительности.
Резервное копирование и восстановление
Для восстановления нужны не только веса модели и документы. Следует сохранять очищенные данные, правила разбиения, версию модели векторизации, параметры индекса, метаданные, права доступа, снимки базы, системные инструкции и конфигурацию инструментов агента. Секреты и ключи хранят отдельно.
Индекс можно построить заново, но для крупной базы процесс занимает много времени и повторно нагружает процессор, GPU и NVMe. Реплика защищает от отказа узла, но не от ошибочного удаления. Резервную копию поэтому размещают отдельно от рабочего массива и заранее определяют допустимую потерю данных и время восстановления.
Заключение
Производительность RAG и ИИ-агентов определяется балансом всей инфраструктуры. GPU отвечает за модели, оперативная память — за активный индекс и кэш, NVMe — за доступ к данным, процессор — за подготовку и поиск, а сеть связывает разнесенные сервисы. KV-кэш дополнительно связывает длину контекста и параллельность с расходом видеопамяти. Надежную конфигурацию выбирают после расчета полного пути данных и сквозного теста под нагрузкой, близкой к рабочей, включая возможные пиковые нагрузки.
