Суверенные GPU-платформы: как компании строят безопасную инфраструктуру для ИИ

Компании переходят от экспериментов к промышленному ИИ: создают модели, внедряют их в рабочие процессы, защищают контуры. Но обучение моделей требует дорогой GPU-инфраструктуры, поэтому растёт спрос на суверенные облака и облачные платформы с разделёнными GPU-ресурсами.

 

 

 

 

 

 

1. 1. Введение
2. 2. Что такое корпоративная GPU‑инфраструктура
3. 3. Что такое суверенное облако
4. 4. Как работают вместе GPU‑инфраструктура и суверенные облака
5. 5. Как разделяют GPU-ресурсы
6. 6. Какие угрозы появляются внутри GPU-облака
   
   1. 6.1. Побочные каналы (side channels)
   2. 6.2. Атаки на модели и данные
   3. 6.3. Риски цепочки поставок
   4. 6.4. Межтенантные атаки
7. 7. Как компании строят защищённые контуры для ИИ
8. 8. Какие метрики показывают зрелость GPU‑платформы
9. 9. Российские GPU-платформы: что происходит на рынке
   
   1. 9.1. Импортозамещение и дефицит оборудования
10. 10. Выводы

Введение

Бизнес внедряет генеративный ИИ в аналитику, поддержку, документооборот и производственные процессы. Для таких задач чаще всего нужны модели, адаптированные под отраслевую специфику и внутренние данные. Для их обучения и дообучения нужны вычислительные кластеры на базе графических ускорителей (GPU).

Одна видеокарта уровня H100 или H200 на российском рынке стоит 2,7–5,1 млн рублей. Для обучения серьёзной модели нужен не один GPU, а кластер из десятков или сотен таких карт. Сервер с восемью H100 обходится в 15–44 млн рублей, к этому добавляются затраты на хранилища, сетевую инфраструктуру, охлаждение и инженерную поддержку.

По данным ИТ-холдинга «Т1», только 9 % российских организаций полностью обеспечены вычислительной инфраструктурой для ИИ. Ещё 40 % обеспечены частично, а 51 % нуждаются в таких ресурсах. Поэтому компании переходят к аренде GPU в облаках.

Рынок выделенных GPU-серверов в России в 2025 году достиг 17 млрд рублей, в 2026-м ожидается рост до 34 млрд. В «Рег.облаке» спрос на GPU-услуги вырос в шесть раз, в M1Cloud — удвоился.

Однако не любое облако подходит для задач, связанных с персональными данными, гостайной или объектами КИИ. Публичные облака западных гиперскейлеров не гарантируют локализацию данных и соответствие российским регуляторным требованиям. Здесь на помощь приходят суверенные облака — платформы, где данные остаются внутри страны, а инфраструктура контролируется в соответствии с национальными нормами.

На этом фоне формируется сегмент облачных платформ с разделяемыми GPU-ресурсами и суверенных облаков, где можно обучать и дообучать модели внутри защищённых контуров, не выводя данные за пределы страны и не покупая собственное железо.

Что такое корпоративная GPU‑инфраструктура

Корпоративная GPU-инфраструктура — это вычислительная среда для обучения, дообучения и запуска нейросетевых моделей. GPU стали стандартом для ИИ благодаря массовому параллелизму и программной платформе CUDA от NVIDIA, которая позволяет фреймворкам вроде PyTorch и TensorFlow эффективно использовать ресурсы видеокарты.

CUDA — основной стек для ускорителей NVIDIA. Альтернативой для AMD служит стек ROCm с компиляторами, рантаймом и библиотеками для запуска ИИ-нагрузок.

В основе GPU-кластеров — ускорители от разных вендоров:

• NVIDIA H100 и H200 для обучения, L40S и A100 для инференса и дообучения;
• AMD Instinct MI300X и MI325X;
• Intel Gaudi 2 и Gaudi 3;
• китайские Huawei Ascend и Moore Threads;
• российские LinQ HPS, NM Card от НТЦ «Модуль» и процессоры «Фишт».

Ускорители объединяют в узлы, а узлы — в кластеры. В системах NVIDIA карты внутри узла соединяют через NVLink. У AMD аналогичную роль выполняет Infinity Fabric. У Intel Gaudi RDMA-порты встроены в чип.

Между узлами работает высокоскоростная сеть, чаще InfiniBand или RoCE, иногда Ethernet 100/200/400 GbE. Если пропускной способности недостаточно, при масштабировании растёт время передачи градиентов и синхронизации.

Рядом с вычислительными узлами размещают быстрые NVMe-массивы и S3-совместимые объектные хранилища. Датасеты и промежуточные артефакты должны считываться без задержек, иначе GPU простаивают в ожидании данных.

Поверх аппаратной платформы работает слой оркестрации. В контейнерных средах используют Kubernetes, в HPC-кластерах — Slurm.

Для мониторинга применяют связки вроде Prometheus и Grafana. Они показывают загрузку GPU, ошибки и стабильность пайплайнов.

 

Рисунок 1. Сервер (узел) с восемью графическими процессорами (Источник: APNIC)

 

Где брать GPU‑ресурсы:

1. Выделенные серверы (bare metal) — физический сервер с GPU полностью в распоряжении компании. Производительность выше, чем при виртуализации, но затраты и сроки ввода в эксплуатацию больше.
2. Виртуальные машины с GPU — быстрый запуск, гибкая конфигурация и изоляция, при небольшой потере производительности.
3. GPU as a Service (GPUaaS) — аренда GPU‑мощностей по времени с управлением через API, оплата за фактическое использование. Удобна для нерегулярных задач и экспериментов.
4. Облачные GPU-кластеры — готовая среда с оркестрацией и распределённым обучением на десятках и сотнях GPU без развёртывания собственной инфраструктуры.

Варианты использования:

Обучение с нуля (pre-training) — самый ресурсоёмкий сценарий. Модель обучают на больших массивах данных с нуля, для этого нужны крупные кластеры из сотен и тысяч GPU, высокоскоростная сеть и большие объёмы видеопамяти. Такой сценарий по силам корпорациям и государственным исследовательским центрам.

Дообучение (fine-tuning) — адаптация готовой модели под данные и задачи компании. Вместо обучения всей модели целиком применяют методы вроде LoRA и QLoRA: основная модель остаётся фиксированной, обучаются небольшие адаптеры. LoRA снижает потребность в видеопамяти в 4–8 раз, QLoRA — до 10–20 раз. Дообучение становится реальным для среднего бизнеса.

Инференс — запуск уже обученной модели в работу: чат-боты, генерация отчётов, анализ документов. Здесь важны стабильные задержки и предсказуемая стоимость. Для оптимизации используют аппаратное разделение GPU (MIG), квантование весов (INT8/INT4) и специализированные рантаймы вроде vLLM.

Инференс делят на пакетный (обработка больших объёмов данных за раз) и реального времени (ответы на запросы пользователей). В первом случае критична пропускная способность, во втором — задержка ответа. Выбор сценария и способа получения ресурсов определяет, сколько GPU потребуется и как будет устроена инфраструктура.

Что такое суверенное облако

Термин «суверенное облако» часто упрощают до формулы «серверы стоят в России». На деле речь идёт не о географии железа, а о комплексе технических и юридических мер, которые обеспечивают цифровой суверенитет.

В таком облаке:

1. Данные локализованы. Они хранятся и обрабатываются внутри страны, и от сбора до обучения и использования моделей не покидают суверенный контур.
2. Соблюдается закон 152-ФЗ о персональных данных, приказы ФСТЭК №21 и №117, требования к объектам КИИ по 187-ФЗ и №239, отраслевые стандарты.
3. Технически это реализуется через сегментацию сетей, сертифицированные средства криптозащиты, разграничение прав доступа, аудит и реагирование на инциденты. Для КИИ добавляется интеграция с ГосСОПКА и НКЦКИ.
4. Провайдер подтверждает уровень защищённости и категорию значимости объектов документально, а в договоре чётко прописывается, кто за что отвечает в части защиты данных.

Когда суверенное облако — необходимость? Когда компания работает с персональными данными российских граждан, гостайной или информацией ограниченного доступа. Это госсектор и оборона, финансы, здравоохранение, критическая инфраструктура (энергетика, транспорт, связь) и промышленность, где есть технологические секреты. В этих сферах ИИ-модели обучаются на данных, которые нельзя выводить за рубеж.

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

В 2026 году в законопроекте об искусственном интеллекте появились понятия «суверенная» и «национальная» модель ИИ. Все этапы разработки, обучения и использования суверенной нейросети должны проходить только на территории РФ и только российскими гражданами. Для обучения используют датасеты, созданные в стране.

Для присвоения статуса нужна сертификация ФСТЭК и ФСБ, а обучение на государственных данных возможно только с разрешения регуляторов.

Эти требования объединяют суверенные облака и проекты в области ИИ в единый технологический контур.

Как работают вместе GPU‑инфраструктура и суверенные облака

Компания арендует кластеры GPU не в любом публичном облаке, а в суверенном. Данные, журналы, модели и сервисы остаются внутри защищённой инфраструктуры, а провайдер выполняет требования 152‑ФЗ, приказов ФСТЭК, норм для КИИ и отраслевых стандартов.

Архитектура часто строится как гибридная. Критичные данные и задачи остаются в суверенном контуре. Менее чувствительные операции, тестирование гипотез или масштабирование нагрузки выносятся в другие среды через защищённые шлюзы и сегментированные VPN.

Так GPU‑инфраструктура и суверенное облако работают вместе: первое даёт вычислительную мощность для ИИ, второе — условия и гарантии, в которых эта мощность используется.

 

Рисунок 2. Схема сетевой архитектуры GPU-кластера (Источник: APNIC)

 

Как разделяют GPU-ресурсы

В крупных компаниях GPU объединяют в общий пул, к которому обращаются разные команды. Доступ регулируют очередями, квотами и приоритетами, иначе одна задача может занять все ускорители и остановить работу остальных.

Поверх пула используют механизмы разделения одной физической карты.

У NVIDIA это MIG (Multi-Instance GPU) — аппаратное разбиение одной видеокарты до семи изолированных инстансов с фиксированными профилями по ядрам и памяти. У каждого свои пути к памяти и контроллерам, поэтому задачи не мешают друг другу. Есть и MPS (Multi-Process Service) — шаринг без аппаратной изоляции памяти, в отличие от MIG.

У AMD работает виртуализация и разделение очередей (SR-IOV, Multi-Queue), которые позволяют запускать несколько задач параллельно на одном ускорителе.

Дополнительно применяется виртуализация GPU (vGPU, time-slicing), когда ресурсы делятся программно между несколькими виртуальными машинами или контейнерами. При time-slicing память у процессов общая, поэтому сбой одного процесса может повлиять на другие.

Разделение ресурсов хорошо работает для прототипирования, экспериментов, дообучения небольших моделей и инференса. В этих случаях один физический GPU обслуживает сразу несколько команд, а общая утилизация растёт.

Но для сложного распределённого обучения одной большой модели, где важна максимальная пропускная способность сети и памяти, выгоднее брать выделенные карты или целые узлы. Любые ограничения профиля MIG или конкуренция за ресурсы будут мешать.

Какие угрозы появляются внутри GPU-облака

GPU-облако добавляет к классическим рискам облачной инфраструктуры собственный набор угроз, связанных с особенностями графических ускорителей и ИИ-моделями. В многоарендной среде, где несколько клиентов используют одни и те же GPU, эти риски многократно возрастают.

Побочные каналы (side channels)

Один из самых коварных классов атак — те, что не взламывают систему напрямую, а используют наблюдение за её работой. Атаки через побочные каналы опираются на физические характеристики GPU: кэш, память, время вычислений, температуру, колебания потребляемой мощности. Они эксплуатируют косвенные признаки. Злоумышленник не преодолевает защиту, а анализирует поведение ускорителя в процессе работы и на основе этих данных извлекает сведения о модели или обрабатываемых данных.

Одна из таких атак — GhostWriter, нацелена на кэш GPU. Атакующий анализирует задержки в работе кэша, восстанавливает токены запроса (промпта) соседнего арендатора и может подменить ответ модели. В экспериментах на модели GPT-Neo-125M точность восстановления токенов достигала 84 %. Иными словами, злоумышленник способен подслушать запрос другого пользователя и изменить выдаваемый моделью ответ.

GPUHammer задействует уязвимость Rowhammer, применяя её к дискретным GPU с памятью GDDR6. Атакующий многократно обращается к определённым строкам памяти, провоцируя инверсию битов. В эксперименте на видеокарте NVIDIA A6000 атака приводила к появлению до 8 битовых ошибок в 4 банках памяти — этого достаточно, чтобы точность работы модели упала с 80 % до менее чем 1 %.

Атака Energon работает иначе: она использует колебания мощности и температуры GPU как канал утечки информации. Злоумышленник с правами обычного пользователя определяет архитектуру модели: сколько в ней слоёв, сколько голов внимания и другие характеристики. Точность идентификации архитектуры модели превышает 89 %, а классификация гиперпараметров достигает 100 %. Получив такие данные, атакующий подбирает состязательные запросы, которые искажают ответы модели.

Атаки на модели и данные

Эти угрозы известны в ИИ-среде, но в GPU-облаке они усиливаются тем, что все клиенты делят общий вычислительный слой. Один уязвимый запрос или заражённый артефакт способен затронуть сразу несколько арендаторов.

Model extraction (кража модели) позволяет злоумышленнику по ответам API восстановить архитектуру и веса модели. Атакующий массово отправляет запросы, собирает отклики и с помощью статистического анализа воспроизводит внутреннее устройство нейросети. В итоге он получает аналог дорогостоящей модели, потратив лишь бюджет на API-вызовы. В мультитенантной среде атаковать можно не только публичную модель, но и проприетарную модель соседнего арендатора, если она доступна через общий шлюз.

Membership inference (определение принадлежности) раскрывает, входила ли конкретная запись в обучающий набор. Например, можно выяснить, обучалась ли модель на медицинских данных конкретного пациента. Для злоумышленника это способ проверить гипотезы о составе датасета. Для компании — риск нарушения конфиденциальности и регуляторных норм.

При атаке model inversion (восстановление данных) по поведению модели реконструируют сами обучающие данные. Например, из модели распознавания лиц можно извлечь характерные черты лиц, на которых она училась. В GPU-среде высокая производительность ускоряет перебор и подбор запросов, а общий доступ к ресурсам упрощает сбор статистики. Атаки здесь эффективнее.

Ещё одно коварное направление — prompt leakage (утечка промптов). Злоумышленник извлекает системные инструкции, которые задают поведение модели. В промпте могут храниться правила модерации, логика маршрутизации запросов, ключи доступа или внутренние ограничения. 

Data poisoning (отравление данных) действует на этапе обучения. Атакующий внедряет в датасет специально искажённые примеры. Модель усваивает их как норму и в нужный момент начинает выдавать ошибочные или вредоносные ответы. Исследование Anthropic и UK AI Security Institute показало, что достаточно всего 250 вредоносных документов, чтобы системно скомпрометировать LLM любого масштаба — от 600 млн до 13 млрд параметров. Если датасет загружается из общего репозитория или через единый пайплайн, заражение быстро распространяется на все проекты, использующие этот набор.

Риски цепочки поставок

Угрозы приходят не только извне, но и вместе с привычными артефактами: моделями, контейнерами, библиотеками и драйверами. GPU-облако по своей природе — это сложная экосистема, где каждый компонент может стать точкой входа.

Особенно опасен формат pickle в Python: при загрузке такого файла выполняется произвольный код. В изолированной среде это риск для одной машины; в общей GPU-инфраструктуре — угроза всей платформы. Исследователи неоднократно фиксировали атаки, когда вредоносные модели выкладывали в публичные репозитории вроде Hugging Face. Rapid7 Labs документировала случаи, когда через .pth-файлы злоумышленники развёртывали RAT-трояны прямо в среде исполнения ML-задач.

Драйверы и системные компоненты тоже несут риски. В январе 2025 года NVIDIA раскрыла серию уязвимостей в драйверах, затронувших миллионы систем. К маю 2026 года число обнаруженных проблем достигло 15, включая сценарии, дающие доступ к GPU-ресурсам на уровне ядра ОС.

Межтенантные атаки

Когда несколько клиентов делят один GPU, они неизбежно делят и часть низкоуровневых ресурсов: память, кэш, шины и даже физические банки видеопамяти. Это создаёт почву для межтенантных атак, где сосед становится источником угрозы.

Одна из недооценённых проблем — остаточные данные (data remanence). Память GPU не всегда полностью очищается после завершения задачи. Фрагменты датасетов, эмбеддинги, веса моделей или промежуточные тензоры могут оставаться в видеопамяти и быть считаны следующей задачей. В многопользовательской среде данные одного арендатора могут просочиться к другому.

Ещё опаснее уязвимости, нарушающие изоляцию на уровне контейнеров. В 2025 году исследователи из Wiz обнаружили NVIDIAScape (CVE-2025-23266) — критическую уязвимость в NVIDIA Container Toolkit с оценкой 9,0 по шкале CVSS. Проблема крылась в некорректной обработке OCI-хуков — механизмов, управляющих жизненным циклом контейнера. Для эксплуатации хватало трёх строк в Dockerfile, чтобы контейнер вышел за пределы изоляции и получил root-доступ к хосту.

FROM busybox

ENV LD_PRELOAD=/proc/self/cwd/poc.so

ADD poc.so /

Проблема затронула Azure, DigitalOcean и других крупных провайдеров, а также все управляемые ИИ-сервисы, использующие этот инструментарий.

 

Рисунок 3. Процент облачных сред, затронутых CVE-2025-23266 (Источник: Wiz)

 

Как компании строят защищённые контуры для ИИ

Защита GPU-платформ строится вокруг трёх принципов.

Изоляция и контроль доступа

Критичные компоненты работают в сегментированных сетях без прямого выхода в интернет. Доступ к данным, моделям и артефактам регулируется через ролевые модели (RBAC) с принципом наименьших привилегий. Каждый запрос проверяется через Zero Trust: доверия по умолчанию нет ни к кому, даже к внутренним пользователям и сервисам. Привилегированные действия (PAM) требуют отдельного подтверждения и логируются.

Шифрование и управление ключами

Данные шифруются в покое и в движении. Ключи хранятся в аппаратных модулях безопасности (HSM) или управляются через KMS. Это защищает от утечек при компрометации хранилищ или перехвате трафика. Без шифрования злоумышленник, получивший доступ к дискам или сетевым потокам, может извлечь датасеты, веса моделей и промежуточные результаты вычислений.

Мониторинг и аудит

Все операции — от загрузки датасета до вызова модели — фиксируются в журналах. Контроль API и мониторинг запросов позволяют отслеживать подозрительную активность. Таким образом атаки можно обнаруживать на ранних стадиях и расследовать, кто, когда и с каким запросом обращался к модели.

Дополнительно используются:

• Изоляция GPU — через MIG или виртуализацию. Не даёт одному арендатору подглядывать за вычислениями соседа через общую память или кэш.
• LLM- и prompt-firewall — защита от промпт-инъекций и джейлбрейков. Блокирует попытки обойти системные ограничения модели.
• AI Gateway — единая точка управления доступом к моделям. Позволяет централизованно применять политики безопасности ко всем ИИ-сервисам.
• DLP для ИИ — предотвращает утечки через ответы моделей. Контролирует попадание чувствительных данных в промпты (input) и блокирует вывод конфиденциальной информации в ответах модели (output).
• Контроль цепочки поставок — проверка библиотек, контейнеров и моделей из внешних репозиториев. Защищает от внедрения вредоносного кода через заражённые артефакты.

В защищённом контуре MLOps превращается в MLSecOps, безопасность становится частью пайплайна:

• Версионирование артефактов позволяет откатиться к безопасной версии модели в случае компрометации.
• Криптографическое подписание моделей гарантирует, что модель не была подменена (защита от supply chain-атак).
• Мониторинг аномалий в запросах позволяет выявить атаки на ранних этапах, например попытки извлечь системные инструкции.

Без этих мер компания рискует потерять контроль над тем, какая модель и на каких данных обучалась, не заметить подмену модели или датасета, пропустить атаку до того, как она нанесёт ущерб.

Какие метрики показывают зрелость GPU‑платформы

Когда компании только внедряют GPU-инфраструктуру, они нередко сталкиваются с парадоксом: ускорители показывают 100 % загрузки, а модель обучается в разы дольше, чем ожидалось. Причина в том, что стандартная загрузка GPU не отражает реальную вычислительную эффективность.

Ключевой показатель здесь — Model FLOPs Utilization (MFU), отношение фактически достигнутого количества операций с плавающей точкой к теоретическому максимуму GPU. В отличие от обычной загрузки, MFU точнее показывает, насколько полно используются возможности архитектуры.

По данным Cast AI, в ряде корпоративных сред средняя утилизация GPU в кластерах достигает лишь 5 %, то есть большая часть мощности простаивает. Gartner оценивает расходы на ИИ-инфраструктуру в 2026 году в 401 млрд долларов, и большая часть этих средств используется неэффективно.

Зрелая GPU-инфраструктура — это среда, где ресурсы реально работают на результат. Её зрелость определяется набором метрик, по которым можно объективно оценить готовность к промышленным ИИ-нагрузкам.

 

Таблица 1. Показатели зрелой GPU-платформы

 

Российские GPU-платформы: что происходит на рынке

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

Cloud.ru выделил ИИ-направление в отдельный продукт — NeoCloud, объединяющий инфраструктуру, данные и инструменты для полного цикла работы с моделями. Платформа поддерживает гибридные сценарии и включает технологию распределённого обучения Evolution Distributed Training.

В 2025 году выручка от облачных серверов Selectel выросла в 3 раза. Провайдер предлагает облачные серверы с видеокартами с оплатой по факту использования.

«Рег.облако» в 2026 году запустило GPU-инстансы на архитектуре NVIDIA Blackwell в регионе Москва-3. Доступны конфигурации от A4000 до двух A100. По данным компании, средняя стоимость GPU-конфигураций в 2025 году выросла в 2 раза и ещё в 2 раза — в начале 2026 года.

Импортозамещение и дефицит оборудования

Главная сложность для российской GPU-инфраструктуры — дефицит оборудования. Санкционные ограничения и проблемы с импортом называют основным барьером 26,1 % поставщиков GPU-услуг. В 2024 году в Россию ввезли тысячи серверов класса H100 через параллельный импорт, но к 2026 году поставки упали до десятков.

Компании ищут альтернативы, переходят на китайское оборудование (Biren, Moore Threads) и отечественные разработки (НТЦ «Модуль», Baikal). Однако не все альтернативные GPU совместимы с CUDA-экосистемой — часть кода придётся адаптировать, что создаёт дополнительные риски для безопасности.

Последствия для бизнеса:

1. Рост стоимости разработки. Адаптация под альтернативные GPU требует переписывания кода, тестирования и доработки пайплайнов.
2. Риски несовместимости. Некоторые модели и фреймворки не работают на альтернативных ускорителях — часть проектов приходится пересобирать.
3. Зависимость от поставщиков. Если один вендор перестаёт поставлять оборудование, компания рискует остановить обучение моделей.
4. Рост операционных рисков. Разные GPU, разные драйверы → разные уязвимости → больше работы для ИБ.

Как выход — гибридные модели (частная инфраструктура + облако) и программные решения, которые уменьшают зависимость от конкретного вендора и позволяют гибко управлять затратами на ИИ-инфраструктуру.

Выводы

GPU-инфраструктура в суверенном облаке — это не о максимальной мощности любой ценой, а о балансе между стоимостью, производительностью и контролем над данными.

Компании переходят к гибридным схемам, используют механизмы разделения GPU и усиливают требования к прозрачности и безопасности.

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