Опубликовано: 23.09.2026 | Источник: CNews (новости)

ИТ-инфраструктура для ИИ в ВКР: от опроса Selectel до защищаемой архитектуры

Поддомен: Cloud/DevOps · AI-инфраструктура. Роль эксперта: DevOps/SRE-инженер.

Selectel опубликовал результаты опроса: 35% российских компаний за последний год нарастили потребление ИТ-инфраструктуры под задачи искусственного интеллекта. Это не абстрактная новость, а конкретный сигнал рынка: спрос на инженеров, умеющих считать, разворачивать и оптимизировать GPU-нагрузки, растёт. Если вы пишете ВКР по облакам, MLOps или системному администрированию — эти цифры дают вам готовое обоснование актуальности, заземлённое на реальной аналитике провайдера. Разберём, как превратить тренд в защищаемый проект: от постановки задач до метрик эффективности и оформления схем по ГОСТ 34.

Частые вопросы выпускников

Обязательно ли арендовать GPU-кластер, чтобы защитить такую ВКР?

Нет. Комиссия оценивает инженерное мышление, а не наличие бюджета. Достаточно эмуляции: используйте Kubernetes с нодами на CPU, подменяя GPU-аппаратуру через fake-device-plugin, либо локальный кластер в minikube + Terraform-модуль для облака. В главе 3 честно укажите: «измерения проведены на CPU-стенде, экстраполяция на GPU-конфигурации сделана по метрикам производительности из документации». Это защищаемо.

Где брать статистику потребления, если у меня нет доступа к продовым системам?

Три источника: 1) публичные отчёты провайдеров (Selectel, Yandex Cloud, VK Cloud); 2) открытые датасеты (Google Cluster Trace, Alibaba Cluster Trace) для моделирования нагрузки; 3) собственная синтетика — нагрузочный генератор на Locust или k6, развёрнутый в вашем стенде. Комбинация «отраслевой отчёт + собственная симуляция» обычно даёт самые сильные выводы.

Как считать экономическую эффективность ИИ-инфраструктуры?

Через TCO и юнит-экономику: стоимость часа GPU, коэффициент загрузки, стоимость инференса одной задачи (cost per inference). Формула простая: TCO = CAPEX + OPEX + стоимость простоя. В главе 3 сведите сценарии on-premise и облака — комиссия любит конкретику в рублях и процентах.

Можно ли ссылаться на исследование провайдера в дипломе?

Можно и нужно, но с оговоркой — как на вторичный источник. В главе 1 сослайтесь в формате: «Согласно опросу Selectel (март 2026), 35% компаний увеличили потребление инфраструктуры под ИИ», затем добавьте независимое подтверждение (Gartner, IDC, отраслевыехаб-хабы). Один источник — это мнение, три — это тренд.

Темы ВКР, которые вырастают из этой статьи

1. Проектирование масштабируемого GPU-кластера в облаке для ML-инференса.
Актуальность: рост потребления инфраструктуры под ИИ на 35% (Selectel, 2026) прямо указывает на дефицит инженерных решений по эластичному масштабированию.
Цель: разработать референсную архитектуру кластера, устойчивого к пиковым нагрузкам инференса.
Задачи: анализ паттернов GPU-нагрузок; выбор модели автоскейлинга; проектирование сети и хранилища; расчёт TCO.
Структура: Глава 1 — анализ рынка ИИ-инфраструктуры и работ по Kubernetes/MLOps; Глава 2 — проектирование (C4, диаграммы развёртывания); Глава 3 — стенд, нагрузочные тесты, метрики.
2. Оптимизация потребления ресурсов ИИ-нагрузок через автоскейлинг и наблюдаемость.
Актуальность: компании растят потребление, но не всегда эффективно — простаивающие GPU стоят миллионы.
Цель: снизить стоимость часа инференса на N% за счёт динамического управления ресурсами.
Задачи: обзор OpenTelemetry, Prometheus, KEDA; построение метрик; внедрение HPA/VPA; A/B-сравнение сценариев.
Структура: Глава 1 — теория наблюдаемости и auto-scaling; Глава 2 — реализация пайплайна метрик и политик; Глава 3 — эксперименты и расчёт экономии.
3. Сравнительный анализ on-premise и облачной ИИ-инфраструктуры: TCO и производительность.
Актуальность: 35% компаний увеличили облачное потребление, но вопрос «арендовать или строить» для ИИ до сих пор открыт.
Цель: построить модель выбора инфраструктурной стратегии для компании среднего размера.
Задачи: собрать бенчмарки; построить модель TCO по 3 годам; учесть амортизацию GPU; проверить сценарии чувствительности.
Структура: Глава 1 — анализ практик; Глава 2 — методика расчёта и модель; Глава 3 — апробация на 3 сценариях нагрузки.

Куда встроить цифры Selectel в структуру работы

Хорошая ВКР отличается не тем, что в ней есть отраслевая статистика, а тем, что каждое число работает на гипотезу. Разберём по главам.

Глава 1: от факта к проблеме

Не переписывайте статью целиком. Достаточно абзаца с цифрой и одним абзацем анализа: «Если 35% компаний увеличили потребление, значит, для оставшихся 65% вопрос выбора архитектуры ещё открыт. Значит, рынку нужны методики, снижающие порог входа». Так вы превращаете новость в исследовательскую нишу. Обязательно добавьте сравнение с ISO/IEC 25010 по атрибутам качества — производительность, масштабируемость, надёжность. Это придаст работе системный вид и облегчит её защиту.

Глава 2: проектирование, а не картинки

Комиссия не любит «архитектуру ради архитектуры». Каждая диаграмма должна отвечать на один вопрос:

C4-уровень 1 (Context): кто пользователи ИИ-сервиса, какие внешние системы (модельный реестр, хранилище данных).
C4-уровень 2 (Container): инференс-сервис, векторная БД, шлюз, очередь задач.
UML Deployment: ноды GPU, storage, сетевые зоны.
Схема по ГОСТ 34: если тема ближе к корпоративным системам, чем к продуктовой разработке.

Не смешивайте нотации в одном разделе. Один тип диаграммы — один вывод.

Глава 3: метрики, которые не стыдно показать

Минимальный набор для темы об ИИ-инфраструктуре: CPU/GPU utilization, latency p50/p95/p99, throughput запросов в секунду, cost per inference, cache hit ratio. Источники — Prometheus + Grafana, трейсинг через OpenTelemetry. Если есть возможность — приложите дашборд в приложениях работы.

Пример: политика автоскейлинга ML-инференса

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: ml-inference-hpa
  namespace: ai-prod
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: ml-inference
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Pods
      pods:
        metric:
          name: inference_queue_depth
        target:
          type: AverageValue
          averageValue: "5"
    - type: Resource
      resource:
        name: nvidia.com/gpu
        target:
          type: Utilization
          averageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 20
          periodSeconds: 60

Такой фрагмент стоит показать в главе 2 как «проектное решение», а в главе 3 — обосновать число averageUtilization: 70 результатами экспериментов. Именно связка «конфиг → эксперимент → вывод» делает раздел защищаемым.

Схема потока метрик (ASCII)

[Inference Pod] --OTLP--> [OpenTelemetry Collector]
        |                        |
        v                        v
   [Prometheus]  <-----  [Tempo / Loki]
        |
        v
   [Grafana Dashboards] --> [Alerts]

Чек-лист «Что проверить перед сдачей»

Задачи в введении дословно совпадают с выводами в заключении.
Все диаграммы имеют подписи, источники и ссылку на раздел текста.
Метрики в таблицах приведены с единицами измерения и контекстом нагрузки.
Оформление приложений с кодом и JSON/YAML — по ГОСТ 19.106 или внутренним требованиям вуза.
Ссылки на источники оформлены по ГОСТ Р 7.0.5-2008, все даты актуальны на момент сдачи.
Уникальность текста — не ниже нормы вуза, все заимствования корректно процитированы.
В приложениях есть как минимум один воспроизводимый эксперимент (скрипт + данные).

Типичные ошибки студентов на таких темах

Ошибка 1. Ссылка на отраслевой отчёт без пересчёта под свою задачу. Цифра «35%» сама по себе ничего не доказывает в вашей работе. Исправление: переформулируйте её в гипотезу («если потребление растёт, то X-решение снизит стоимость Y на Z%») и проверьте на стенде.

Ошибка 2. Смешение уровней абстракции в архитектуре. На одной диаграмме — и бизнес-контекст, и YAML-ноды. Исправление: разделяйте C4-уровни и держите каждую схему в одной нотации. Комиссия это замечает моментально.

Ошибка 3. Метрики без baseline. «Ускорили инференс в 2 раза» без указания, относительно чего. Исправление: всегда давайте базовый сценарий, условия теста, количество параллельных клиентов. Без этого результат — просто число.

Практические выводы: чему вы научитесь

Обосновывать актуальность темы через отраслевую аналитику, а не общие слова.
Проектировать отказоустойчивые ИИ-платформы в облаке и на собственном железе.
Строить наблюдаемость через OpenTelemetry + Prometheus и превращать метрики в выводы.
Считать TCO и юнит-экономику инференса, защищать решения в цифрах.
Оформлять техническую документацию и схемы по ГОСТ 34 и внутренним регламентам кафедры.

Если до защиты осталось меньше месяца, а структура темы ещё «плывёт» — начните с бесплатной консультации. Мы поможем разложить работу по главам, подберём источники и подскажем, как считать метрики под конкретную тему. Средний объём доработки — около 120 часов, но у большинства студентов за счёт готового каркаса получается быстрее.

Материал подготовлен экспертами компании «Диплом-ИТ». Мы помогаем студентам с 2010 года: от выбора темы до защиты и нормоконтроля. Если вам нужна помощь с дипломом — от постановки задач до оформления графиков и приложений, наши специалисты готовы подсказать по вашей конкретной теме и предложить формат сопровождения ВКР на заказ.

Последнее обновление: 2026-09-23

Источник: Исследование Selectel: 35% компаний нарастили потребление ИТ-инфраструктуры для ИИ за последний год (опубликовано 2026-03-25)