ЖУРНАЛ СТА №4/2026

О Б З О Р Ы www.cta.ru СТА 4/2026 нарии работы нейросетей и дообучения , с которыми сталкиваются реальные сек - торы промышленного производства . Платформа как дирижёр для архитектуры и управления ИИ - нагрузкой С инженерной точки зрения стек , объединяющий аппаратные ускорите - ли , системное ПО и платформу управ - ления , необходимо рассматривать как многоуровневую конструкцию . На ниж - нем уровне – серверы с GPU, объединён - ные высокоскоростной сетью ; они могут быть сосредоточены как в центральном дата - центре предприятия , так и распре - делены по мини - ЦОД на периферии . Над ними – слой драйверов и библиотек , оптимизированных под конкретные архитектуры ускорителей . Далее идёт платформа управления , берущая на себя оркестрацию моделей , распределение задач , контроль версий , квотирование ресурсов и мониторинг . И наконец , при - кладной уровень , где живут конкретные сервисы – от чат - ботов до систем видео - аналитики , вызываемые через API. На рис . 2 более наглядно представле - ны ориентиры по классам нагрузок , что важно при выборе архитектуры плат - формы . Это не результаты конкретной лабора - торной работы , а классовое соответствие , собранное из открытых источников и типичных сценариев . Таблица на рис . 2 – хорошая отправ - ная точка при проектировании класте - ра : она задаёт ожидания по тому , какой класс GPU архитектуры нужен под конкретный тип нагрузки . Далее уже реальные пилоты и профилирование позволяют уточнить конфигурацию . Ценность такого разделения не в архи - тектурной стройности как таковой , а в том , что платформа становится единой точкой контроля . Вместо того чтобы размазывать логику маршрутизации и балансировки по десятку минисервисов , инженер получает панель , где видны все очереди задач , загрузка GPU- узлов , метрики по задержкам и события дегра - дации . Влияние платформенного слоя на производительность проявляется в трёх плоскостях : выравнивание утилизации ресурсов ( минимизация простоев ), под - держание стабильности времени откли - ка за счёт управления приоритетами и существенное ускорение поиска « буты - лочных горлышек ». Для систем , работа - ющих круглосуточно в режиме реаль - ного времени , это не опция , а условие выживания . Отраслевые сценарии : три портрета применения Чтобы не ограничиваться общими словами , приведём три характерных портрета использования локального ИИ - контура , которые сегодня всё чаще встречаются в российской практике . Финансовый сектор Здесь ИИ обслуживает кредитный ско - ринг , антифрод , клиентские чат - боты и поиск по внутренним регламентам . Архитектура вынуждена быть много - слойной и строго соответствовать требо - ваниям 152- ФЗ и нормативам ЦБ . Платформа « Арка » разворачивается в защищённом сегменте дата - центра банка и стыкуется с внутренней сервис - ной шиной , получая запросы от мобиль - ного приложения , контакт - центра и CRM не напрямую , а через прикладной слой . LLM- сервисы и RAG- компонен - ты работают на GPU- кластере , построен - ном на серверах с китайскими ускори - телями . Все персональные данные физиче - ски остаются в российском периметре , а модели скоринга и антифрода логиру - ются для последующего аудита . Таблица 2. Оценка вычислительной мощности для решения определённого класса задач Класс ускорителя Примеры восточных аналогов Типовые задачи Ожидаемая производительность ( относительно A100) Высокий (High-End) Флагманские модели нового поколения Тренировка больших LLM, сложный инференс 80–100% в оптимизированных сценариях Средний (Mid-Range) Ускорители предыдущего поколения Инференс CV- моделей , предиктивная аналитика , дообучение 50–70% Базовый (Entry) Бюджетные линейки Лёгкий инференс , видеоаналитика ограниченного числа потоков 30–50% Рис . 2. Распределение по классам нагрузок вычислительной платформы 31