В марте 2026 года TechCrunch рассказал историю, которая для инженера звучит почти как анекдот: крупная AI-компания предложила семье из Кентукки $26 млн за фермерскую землю — под строительство дата-центра, и получила отказ. Для выпускника ИТ-специальности здесь спрятан совсем не сентиментальный сюжет. Он про то, что вычислительная инфраструктура упирается не в серверы, а в площадку: землю, электроэнергию, охлаждение и отношения с местным сообществом. Именно эти факторы всё чаще определяют архитектуру и стоимость системы, которую вы проектируете в дипломе.
Если ваша тема связана с облаками, распределёнными системами, ML-инференсом или корпоративной инфраструктурой — этот кейс даёт готовую рамку для обоснований. Ниже разберём, какие разделы ВКР он усиливает и чем наполнить расчётную часть.
Актуальность: предложение в $26 млн и отказ от него — наглядная демонстрация того, что цена земли перестала быть главным критерием. В расчёт входят доступная мощность, тариф, климат, требования к охлаждению и регуляторика.
Цель: разработать многокритериальную модель оценки площадок и программный прототип для расчёта интегрального рейтинга.
Структура: Глава 1 — анализ рынка ЦОД и факторов размещения; Глава 2 — проектирование модели и архитектуры прототипа; Глава 3 — реализация, тестирование, оценка экономического эффекта.
Актуальность: спрос на инфраструктуру под ИИ толкает компании искать площадки за пределами традиционных хабов — ровно то, что описывает статья.
Цель: спроектировать архитектуру площадки, обеспечивающую заданный уровень производительности при контролируемых PUE и TCO.
Структура: Глава 1 — теория: ЦОД как система, метрики эффективности; Глава 2 — архитектура, схемы, модели расчёта; Глава 3 — расчёты, сценарии, выводы об экономике.
Актуальность: если инфраструктура «размазана» по нескольким площадкам, вопрос наблюдаемости и автоматического масштабирования становится критическим.
Цель: разработать подсистему мониторинга и автомасштабирования для кластера с GPU-нагрузкой.
Структура: Глава 1 — обзор средств наблюдаемости; Глава 2 — архитектура подсистемы, схемы взаимодействия; Глава 3 — эксперименты, метрики, выводы.
| Тема ВКР | Что можно измерить | Артефакт для защиты |
|---|---|---|
| Выбор площадки | Интегральный рейтинг, чувствительность к весам | Модель + прототип + таблица сценариев |
| Гибридный ЦОД | PUE, TCO, срок окупаемости | Схема развёртывания, расчётная модель |
| Мониторинг | Задержка p95, утилизация GPU, RTO/RPO | Дашборды, отчёты нагрузочных тестов |
Не пересказывайте новость — используйте её как иллюстрацию тренда «инфраструктура идёт за ресурсами». Рабочая схема абзаца: тезис о росте энергоёмкости ИИ-нагрузок → пример из статьи как крайняя форма конфликта «выгода против площадки» → вывод, что критериев оценки площадки стало больше.
Дальше сравните 3–4 варианта размещения (например, аренда стойки в коммерческом ЦОД, colocation, собственная модульная площадка, edge-узел) по критериям: капитальные затраты, срок ввода, масштабируемость, соответствие требованиям ИБ, зависимость от внешних факторов. Сравнительную таблицу удобно строить сразу с весами — тогда в третьей главе вы просто подставите реальные числа.
Не забудьте зафиксировать, чем вы обосновываете выбор стека: оркестрация — Kubernetes, телеметрия — OpenTelemetry, метрики качества — ISO/IEC 25010, состав документации — ГОСТ 34.602-89. Ссылка на стандарт в аналитической главе почти всегда снимает вопрос комиссии «а почему именно так».
Минимальный набор графики для темы, связанной с ЦОД:
Пример политики автомасштабирования, который уместно привести в тексте как листинг конфигурации:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: inference-worker
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: inference-worker
minReplicas: 3
maxReplicas: 24
metrics:
- type: Pods
pods:
metric:
name: gpu_utilization
target:
type: AverageValue
averageValue: "70"
Обратите внимание: листинг без пояснения, почему порог 70% и минимум 3 реплики, на защите работает против вас. Одно предложение обоснования — и вопрос снят.
Кейс с площадкой подсказывает сценарии отказов — их удобно превратить в тест-план.
| Категория | Метрика | Как получить |
|---|---|---|
| Производительность | p50/p95/p99 задержки, RPS | Нагрузочный прогон, например k6 или Locust |
| Эффективность | PUE, потребление на 1k запросов | Расчёт по данным телеметрии узлов |
| Надёжность | RTO, RPO, доля успешных запросов | Учения по отказу зоны доступности |
| Наблюдаемость | Полнота трассировок, MTTR | OpenTelemetry + дашборды |
Если реального кластера нет, честный путь — эмуляция: поднимите одноузловой Kubernetes, сгенерируйте синтетическую нагрузку и явно опишите допущения моделирования в начале главы. Это принимается лучше, чем «мы предполагаем» без границ применимости.
Типичные ошибки студентов
Нет. Для большинства тем достаточно воспроизводимого эксперимента: один узел, эмулятор отказов, синтетическая нагрузка. Важно описать границы применимости модели — это и есть научная честность работы.
Три источника: публичные тарифы провайдеров, технические характеристики оборудования от производителей, собственные замеры на прототипе. Всё, что не измерено лично, оформляйте как допущение с указанием источника и даты.
Опирайтесь на ГОСТ 19.701-90 для схем алгоритмов и на нотацию UML для диаграмм развёртывания и компонентов. Главное — единообразие по всей работе и подписи с расшифровкой обозначений под рисунком.
Объём кода — не критерий. Комиссия смотрит на связку «требование → решение → проверка». Листинг без трассировки требований весит меньше, чем таблица соответствия на полстраницы.
Что проверить перед сдачей
Если тема уже выбрана, но не хватает расчётной части или экспериментов — это решаемо. У нас есть 120 часов ресурса кураторов, первая консультация бесплатна, и мы берём темы любого профиля: от проектирования ЦОД до мониторинга и экономики инфраструктуры. Если нужна помощь с дипломом на этапе, где всё встало — напишите, разберём, что именно тормозит.
Источник: Kentucky woman rejects $26M offer to turn her farm into a data center (опубликовано 2026-03-24)