ИИ в облаке: где хранить данные и на чём считать модели

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

Облако убирает капекс: кластер разворачивается на время обучения и снимается сразу после, а не живёт в дата-центре между экспериментами. Нагрузка масштабируется под пик — под запуск обучения большой модели или под всплеск инференса, — а не под воображаемый максимум, на который закупали железо заранее.

Часть инженерной работы вокруг обучения закрывают управляемые ML-сервисы (MLaaS): оркестрацию задач, версионирование моделей и мониторинг метрик команда получает готовыми, а не собирает из отдельных open-source-компонентов и не поддерживает их своими силами.

Где хранить данные для обучения: формат решает больше, чем кажется

Прежде чем запускать обучение, команда обычно решает один вопрос, который потом сложно переиграть: в каком формате будут лежать данные. От этого выбора зависят скорость обучения и стоимость всего пайплайна — формат определяет, как быстро данные читаются, как они впишутся в governance-политики компании и в существующий стек ML-инструментов.

Три открытых табличных формата решают эту задачу по-разному:

Открытость формата — не абстрактное преимущество. Она определяет, сможет ли команда подключить к одним и тем же данным разные движки под разные задачи, вместо того чтобы держать копии под каждый инструмент. В VK Data Platform, например, данные приводятся к Parquet и организуются в таблицы Apache Iceberg, а сверху к ним подключаются Managed Trino — для ad-hoc-аналитики и BI, Managed Spark — для ETL и Data Science, и Managed ClickHouse — там, где нужна максимальная скорость простых запросов. Один формат хранения — разные движки под разные профили нагрузки, без дублирования данных под каждый из них.

На чём считать: аренда GPU вместо закупки

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

В VK Cloud под ML/AI-нагрузки доступно несколько форматов потребления GPU:

• GPU в облаке — виртуальные машины с GPU (до NVIDIA H200 объёмом 141 ГБ видеопамяти) для быстрого запуска обучения и инференса.
• Bare Metal с GPU — выделенные серверы с Infiniband 400 Гбит/с для тяжёлого обучения и рендера, где нужна полная производительность и контроль над железом.
• vGPU as a Service — разделение одной физической карты между несколькими задачами с выделением 2–16 ГБ видеопамяти под каждую. Подходит для инференса, обучения на небольших датасетах и сервисных ML-задач, где полная карта — избыточный ресурс.
• GPU в Managed Kubernetes — GPU-ноды для контейнерных ML-сервисов с автоматическим масштабированием под нагрузку.

Сверху на этой инфраструктуре работает Cloud ML Platform — управляемая связка JupyterHub и MLflow: рабочая среда для обучения моделей и инструмент для управления их жизненным циклом получены готовыми, а не собраны из отдельных сервисов вручную.

Когда обучать не нужно — только считать

Для части задач собственное обучение вообще не требуется: команда получает результат инференса без затрат на подготовку датасета и вычислительные ресурсы на тренировку. В VK Cloud это закрывают готовые ML-сервисы:

• Cloud Vision — API компьютерного зрения и распознавания текста для задач, где не нужна собственная CV-модель.
• Cloud Voice — распознавание и синтез речи для колл-центров и голосовых интерфейсов.
• Predict AutoML — no-code платформа для построения ML-моделей и прогнозов без написания кода, рассчитанная на аналитиков без ML-бэкграунда.
• Feature Store — среда для повышения точности моделей на общих данных, когда нескольким командам нужно работать с одним набором признаков, не дублируя пайплайны подготовки данных. Управляемые сервисы в целом добавляют то, что иначе пришлось бы собирать из отдельных open-source-компонентов и поддерживать своими силами: AutoML, MLOps-инструменты, версионирование экспериментов.

Регуляторика не снимается тем, что вычисления в облаке

Если облачный ИИ-сервис обрабатывает персональные данные, эта обработка обязана соответствовать 152-ФЗ и остальному локальному законодательству — требование не исчезает от того, что вычисления происходят в облаке, а не в собственном дата-центре.

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

Считать TCO раньше, чем выбирать модель развёртывания

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

Модель pay-as-you-go снижает порог входа для экспериментов: команда платит за фактически использованные вычисления, а не резервирует бюджет под кластер, который простаивает между итерациями обучения.