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

Анализ масштабирования ИИ-инфраструктуры для ВКР: GPU-оркестрация, MLOps и TCO

В начале 2026 года «Крок» зафиксировал: масштабирование ИИ перестало быть экспериментом лабораторий и стало инженерной задачей для инфраструктурных команд. Государство анонсировало национальный план внедрения ИИ в ключевые отрасли — а значит, вырастет спрос на тех, кто умеет разворачивать и сопровождать такие системы, а не только обучать модели. Что это меняет для выпускника? Диплом уровня «модель обучилась в ноутбуке» уже не защищается: комиссия спрашивает про отказоустойчивость, стоимость одного запроса и наблюдаемость. Хорошая новость — эти три сдвига удобно превращаются в главы ВКР. Ниже разбираю, как тренд разложить по разделам, какие метрики посчитать и что положить в приложения, чтобы работа выглядела инженерной, а не реферативной.

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

Три сдвига 2026 года — и место каждого в главах работы

Сдвиг 1. GPU перестал быть «ресурсом на бумаге»

Пока GPU хватало, инженерные вопросы не поднимались. Как только ИИ уходит в прод, карта ускорителей становится узким горлом: очередь на планирование пода может занимать десятки минут, а утилизация карты при плохой батчевой политике — падать до 20%. В ВКР это разворачивается в Главу 2: архитектурная диаграмма C4 (Container + Deployment) и описание того, как вы распределяете нагрузку между картами.

Минимальный пример для приложения — манифест с явным резервированием ресурса. Такой фрагмент читается комиссией лучше, чем три страницы текста:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm-inference
spec:
  replicas: 2
  selector:
    matchLabels: { app: llm }
  template:
    metadata:
      labels: { app: llm }
    spec:
      nodeSelector:
        accelerator: nvidia-a100
      containers:
        - name: vllm
          image: vllm/vllm-openai:latest
          args: ["--model", "mistral-7b", "--max-num-seqs", "32"]
          resources:
            limits:
              nvidia.com/gpu: 1
            requests:
              cpu: "8"
              memory: "32Gi"
          ports:
            - containerPort: 8000
          readinessProbe:
            httpGet: { path: /health, port: 8000 }
            periodSeconds: 10

Обязательно проговорите в тексте, зачем здесь readinessProbe: без него трафик пойдёт на под, который ещё грузит веса. Этот абзац стоит один абзац работы, а показывает зрелость решения.

Сдвиг 2. Наблюдаемость стала частью архитектуры, а не «плюшкой»

Вторая ошибка — сводить наблюдаемость к Grafana-дашборду на скриншоте. В Главе 1 уместно сравнить ISO/IEC 25010 (характеристики performance efficiency и reliability) с вашими SLO и показать, что метрики выбраны не случайно. В Главе 3 — сценарии: «упал GPU-воркер», «деградировала модель», «очередь растёт». Для трассировки опишите конвейер OpenTelemetry: span на HTTP-вход, span на вызов инференса, span на батч.

Метрики, которые точно спросят на защите:

Сдвиг 3. TCO инференса выходит на первый план

Третий сдвиг — управление затратами. Считать «в облаке дешевле» на глазок уже неприлично. В Главе 3 покажите формулу: TCO = CAPEX + OPEX (электроэнергия, амортизация, лицензии, ФОТ дежурной смены). Дальше — сценарии: 1) чистый облачный инференс, 2) собственный узел с GPU, 3) гибрид с оффлоадом пиков. И честно ответьте, где точка окупаемости.

import numpy as np

lat = np.array(latencies_ms)
print(f"p50={np.percentile(lat, 50):.1f} ms")
print(f"p95={np.percentile(lat, 95):.1f} ms")
print(f"p99={np.percentile(lat, 99):.1f} ms")

tco_year = capex + opex_year
cost_per_1k = tco_year / (tokens_year / 1000)
print(f"TCO (год) = {tco_year:,.0f} ₽, 1k токенов = {cost_per_1k:.3f} ₽")

Эти 10 строк лучше, чем страница рассуждений: комиссия видит, что вы умеете считать и воспроизводить расчёт по данным из приложения.

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

• Проектировать отказоустойчивый контур инференса и обосновывать архитектурные решения диаграммами C4 и UML deployment.
• Писать Kubernetes-манифесты с корректным резервированием GPU и probes, не выдумывая «красивых» YAML из туториалов.
• Считать метрики эффективности (p95/p99, throughput, GPU utilization) и защищать их перед комиссией, а не просто вставлять скриншоты.
• Оформлять ТЗ и разделы по ГОСТ 34.601/34.602, а программную документацию — по ГОСТ 19.
• Обосновывать TCO и находить точку окупаемости — навык, который прямо монетизируется на рынке.

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

Где брать данные и метрики, если нет кластера с GPU?

Три рабочих пути. Первый — публичные бенчмарки (MLPerf, локальные прогоны vLLM на арендованном A100 на 2–3 часа). Второй — эмуляция: поднимите локальный Kubernetes + манифесты и моделируйте нагрузку через Locust, фиксируя задержки CPU-инференса как baseline. Третий — открытые датасеты трассировок. Главное — в Главе 3 указать источник и воспроизводимость, а не выдавать синтетику за реальный прод.

Что выбрать: managed-сервис или собственный Kubernetes?

Для диплома выгоднее K8s: он даёт материал для Главы 2 (архитектура, манифесты, probes) и для Главы 3 (сценарии отказа). Managed-сервис оставьте как сравнительный вариант — это честный раздел «анализ альтернатив», который любят в комиссиях.

Хватит ли 3 глав или нужен отдельный экономический раздел?

Для технических направлений достаточно включить экономику как подраздел Главы 3 («Оценка эффективности и TCO»). Отдельная глава оправдана, только если тема прямо про экономику ИИ. Зато в выводах обязательно свяжите технические метрики с деньгами — это то, что отличает ВКР от курсовой.

Как оформить схемы, чтобы прошёл нормоконтроль?

Диаграммы — в приложения, ссылки в тексте обязательны. C4 и UML подпишите по правилам нотации, BPMN — если описываете бизнес-процесс. Рамки, шрифты и подписи рисунков сверяйте с методичкой кафедры и ГОСТ 34.201; требования к ТЗ — 34.602. Спорные моменты согласуйте с нормоконтролёром заранее, а не за день до сдачи.

Источник: «Крок»: масштабирование ИИ меняет инфраструктуру – три ключевых сдвига 2026 года (опубликовано 2026-03-30)