# Гибридная CPU/GPU-архитектура: как разделить AI-сервис по задачам

Как распределить приём запросов, поиск, подготовку данных и генерацию между CPU и GPU, сохранив понятные интерфейсы и измеряемые расходы.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/cpu-gpu-hybrid-architecture/
Language: ru

Для AI-приложения необязательно размещать все процессы на одной дорогой машине. CPU может обслуживать приложение и готовить данные, а GPU — выполнять поддерживаемую модель. Но такое разделение добавляет интерфейсы, сеть и способы отказа. Прежде чем финансировать несколько узлов, нужно понять, какую проблему решает схема.

## Начните с карты функций

Выпишите приём запросов, проверку доступа, поиск, подготовку входа, выполнение модели и сохранение результата. Для каждой функции укажите измеренный ресурс и ответственного компонента.

[NVIDIA CUDA Best Practices](https://docs.nvidia.com/cuda/cuda-c-best-practices-guide/index.html) предлагает начинать оптимизацию с анализа приложения и обмена данными. [CPU-бэкенд vLLM](https://docs.vllm.ai/en/stable/getting_started/installation/cpu/) — отдельный пример поддерживаемого выполнения на центральном процессоре. Эти возможности не означают, что любой этап можно произвольно переместить без изменения результата.

Для пилота выберите одну понятную цепочку вместо универсального конструктора на все будущие задачи.

## Разделяйте процессы и память

CPU-сервис с увеличенной RAM может держать поисковый индекс. GPU-сервис использует собственную VRAM и ресурсы хоста. Их нельзя сложить в единую память модели только потому, что они соединены API.

Уточните, какие данные передаются между компонентами: текст, файлы, векторы или внутреннее состояние. Передача по сети и локальная работа внутри GPU имеют разные свойства.

Если обсуждается перенос части модели на CPU, это другая архитектурная задача. Её нужно проверять выбранным движком, отдельно от обычного разделения приложения и модельного endpoint.

## Сравните единый и разделённый запуск

Возьмём условный поиск по документам с генерацией ответа. Сохраните одинаковые данные, вопросы и проверки корректности. Сначала измерьте совместный запуск на доступной машине, затем разделённый вариант.

Запишите задержки этапов, сетевое ожидание, пиковую память и общую готовность. Выигрыш внутри одного процесса полезен только вместе с пригодным полным ответом.

Добавьте случай недоступности GPU-сервиса. CPU-часть должна выдавать понятное состояние или выполнять согласованный сценарий, а не бесконечно накапливать обращения без ограничения очереди.

## Проверьте расписание и обновления

Разделение может позволить независимо обновлять индекс и модель, но эту возможность нужно организовать. Согласуйте версии интерфейса, порядок выпуска и путь возврата.

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

Сохраните карту обслуживания: какой компонент останавливается, что продолжает работать и как подтверждается восстановление. Это уменьшает неопределённость при передаче ресурса оператору.

Для каждой сетевой границы сохраните размер сообщения и допустимое время ожидания. Если компонент получает больше данных, чем требуется результату, сначала проверьте возможность сократить передачу. Это даёт отдельную альтернативу покупке нового ускорителя или более крупного CPU-узла.

## Сопоставьте полный бюджет

Учитывайте CPU-узлы, GPU, хранение, сетевую передачу и сопровождение связей. Нельзя сравнивать только цену ускорителя в единой схеме с ценой всей распределённой системы.

Финансовому партнёру покажите, какая часть ресурса масштабируется независимо и какой эксперимент подтверждает необходимость. Дополнительная сложность оправдывается конкретной задачей, а не красивой архитектурной диаграммой.

Подготовиться помогут [CPU и GPU-хостинг](/ru/journal/cpu-vs-gpu-hosting/), [RAM и VRAM](/ru/journal/ram-vs-vram/) и [сеть для инференса](/ru/journal/network-and-uptime/).