25 марта 2026 года сенатор Берни Сандерс и конгрессвумен Александры Окасио-Кортес внесли парный законопроект, который останавливает строительство новых дата-центров до тех пор, пока Конгресс не примет комплексное регулирование ИИ. Это не абстрактная политика: для выпускника ИТ-направления такое событие — готовый каркас актуальности диплома. Ограничение ввода новых мощностей напрямую бьёт по трём инженерным допущениям, на которых построено большинство студенческих проектов: «мощности бесконечны», «горизонтальное масштабирование всегда дешевле», «энергия — не наша зона ответственности». Если строить нельзя, приходится выжимать PUE, перераспределять нагрузку между существующими площадками, считать киловатт-часы на инференс и проектировать периферийные вычисления. Именно эти сюжеты и превращают курсовую заготовку в защищаемую работу.
Законопроект — это мораторий на строительство, а не на работу. То есть эксплуатируемые площадки продолжают работать, но рост вычислительных потребностей упирается в потолок уже введённых мощностей. Для инженера это задача оптимизации с жёсткими ограничениями: нужно уложить растущую нагрузку в неизменный бюджет энергии, охлаждения и площади.
Обратите внимание: в тексте законопроекта нет ни слова про конкретные технологии. Это значит, что всю техническую интерпретацию придётся делать вам — а значит, у вас появляется простор для собственного вклада, а не для пересказа чужого пресс-релиза.
Актуальность. Мораторий превращает PUE из отчётного показателя в проектный ограничитель: улучшение PUE с 1,6 до 1,3 высвобождает больше полезной мощности, чем дало бы новое строительство.
Цель. Разработать модель оценки энергоэффективности вычислительной площадки и предложить меры по высвобождению ИТ-мощности без строительства.
Задачи. Проанализировать нормативную и стандартную базу (в том числе требования к оформлению — ГОСТ 34.602-89); построить расчётную модель PUE/CUE/WUE; смоделировать 3–4 сценария модернизации охлаждения и распределения нагрузки; оценить экономический эффект и риск недоступности сервиса.
Структура. Глава 1 — анализ стандартов и практик отрасли; Глава 2 — модель и инструмент расчёта; Глава 3 — сценарный эксперимент, метрики, экономика.
Актуальность. Когда новых стоек не будет, различать «важную» и «фоновую» нагрузку придётся на уровне планировщика. Штатный планировщик Kubernetes о ваттах не знает — нишу нужно заполнить.
Цель. Спроектировать механизм размещения подов, учитывающий не только CPU/RAM, но и энергетический бюджет узла.
Задачи. Изучить точки расширения Kubernetes (scheduler framework, device plugins, custom metrics API); реализовать сбор энергопоказателей; описать алгоритм принятия решения о размещении; провести нагрузочные испытания и сравнить с базовым планировщиком.
Структура. Глава 1 — оркестрация и метрики ресурсов; Глава 2 — архитектура расширения и схемы взаимодействия компонентов; Глава 3 — тестирование, сравнение сценариев, выводы.
Актуальность. Ограничения по строительству почти всегда сопровождаются требованиями раскрывать потребление. Значит, нужна наблюдаемость: сколько энергии ушло на конкретный сервис, а не на площадку в целом.
Цель. Построить контур сбора и визуализации энергетических и эксплуатационных метрик с разбивкой по сервисам.
Задачи. Спроектировать модель метрик и телеметрии на базе OpenTelemetry; настроить хранение и агрегацию; построить дашборды и правила оповещения; описать регламент формирования отчётности.
Структура. Глава 1 — обзор подходов к наблюдаемости и отраслевых стандартов; Глава 2 — архитектура контура сбора данных; Глава 3 — внедрение, проверка на тестовом стенде, оценка накладных расходов.
Актуальность. Если централизованное расширение заблокировано, распределение нагрузки между периферийными площадками становится не модой, а вынужденной мерой.
Цель. Обосновать архитектуру гибридного размещения сервисов и оценить выигрыш по задержке и энергозатратам на передачу данных.
Задачи. Классифицировать нагрузки по допустимости переноса; спроектировать схему синхронизации данных; реализовать прототип развёртывания; сравнить сценарии по метрикам ISO/IEC 25010.
Структура. Глава 1 — анализ моделей размещения (гиперскейл, колокейшн, edge, гибрид); Глава 2 — проектирование гибридной схемы; Глава 3 — эксперимент и оценка компромиссов.
Первая глава у большинства студентов получается самой слабой, потому что превращается в пересказ источников. Здесь этого можно избежать: сравнение вариантов размещения — это уже аналитика, а не компиляция.
| Вариант размещения | Зависимость от нового строительства | Типичный PUE | Задержка | Регуляторный риск | Оценка для ВКР |
|---|---|---|---|---|---|
| Собственный гиперскейл-ЦОД | Критическая | 1,1–1,3 | Средняя | Высокий | Реализуемо только как модель, не как стенд |
| Колокейшн у оператора | Средняя | 1,4–1,7 | Средняя | Средний | Реалистичная база для расчётов |
| Периферийные площадки | Низкая | 1,3–2,0 | Низкая | Низкий | Хорошо для измеряемого прототипа |
| Гибрид (ядро + периферия) | Низкая | 1,3–1,6 | Зависит от сервиса | Низкий | Оптимально для исследовательской части |
Такая таблица закрывает сразу два требования комиссии: показывает сравнительный анализ и даёт обоснование выбора. Рядом обязательно поставьте абзац-пояснение, почему из всех строк вы выбрали именно вашу — иначе таблица выглядит как украшение.
Вторая глава должна отвечать на вопрос «что и как вы построили». Формулировка «как» здесь буквальная: нужны диаграммы компонентов, последовательностей и развёртывания. Если работа про планировщик с учётом энергии, центральная схема — цикл принятия решения: сбор телеметрии → оценка энергобюджета → фильтрация узлов → выбор узла → фиксация результата.
Пример фрагмента конфигурации ограничений для узла Kubernetes — он пригодится в главе, где вы описываете правила размещения:
apiVersion: v1
kind: LimitRange
metadata:
name: node-energy-budget
namespace: inference
spec:
limits:
- type: Container
defaultRequest:
cpu: "500m"
memory: "1Gi"
max:
cpu: "8"
memory: "32Gi"
# энергетический бюджет узла передаётся через node labels
# node.kubernetes.io/power-budget-watts=4500Обратите внимание на комментарий в конце: сам Kubernetes о ваттах не знает, поэтому бюджет удобно передавать как метку узла и читать её в фильтре планировщика. Такой приём показывает комиссии, что вы понимаете границы инструмента, а не просто повторяете документацию.
Третья глава проваливается по одной причине — студент пишет «система протестирована», не приводя чисел. Соберите метрики заранее, до начала экспериментов.
| Метрика | Что показывает | Как получить | Куда вставить в ВКР |
|---|---|---|---|
| PUE | Долю энергии на охлаждение и потери | Отношение общего потребления к потреблению ИТ-оборудования | Глава 1 (теория) и глава 3 (факт) |
| кВт·ч на 1000 инференсов | Удельную стоимость вычисления | Замер потребления за интервал, делённый на число запросов | Глава 3, сравнение конфигураций |
| p95 и p99 задержки | Качество обслуживания под нагрузкой | Нагрузочный генератор + гистограммы | Глава 3, до и после оптимизации |
| RTO / RPO | Восстанавливаемость при отказе площадки | Учебный эксперимент по отключению узла | Проектная часть и тестирование |
| Накладные расходы телеметрии | Цену наблюдаемости | Сравнение потребления с агентом и без него | Глава 3, раздел про компромиссы |
Полезный практический ход: вынесите правило расчёта PUE в виде запроса к системе мониторинга. Это делает главу воспроизводимой — комиссия видит, что метрика не выдумана.
# суточный PUE: вся мощность площадки к мощности ИТ-оборудования
sum(rate(dc_power_watts_total[24h]))
/
sum(rate(it_power_watts_total[24h]))Три ошибки, которые встречаются чаще всего
Полноценный ЦОД не нужен. Достаточно одного-двух узлов и программы-эмулятора потребления: вы подменяете физический замер значением из модели, но сохраняете всю логику сбора и принятия решений. Защищается методика и архитектура, а не количество стоек.
Зависит от требований кафедры. Минимально достаточный вариант — прототип, покрывающий ключевой сценарий: сбор метрик, принятие решения, результат. Если код не предусмотрен, замените его подробными алгоритмами и расчётами, но тогда особенно тщательно оформите расчётную часть — она станет основным доказательством.
Единый нотации по всей работе: если начали с диаграмм компонентов, не переходите произвольно к блок-схемам. Каждая диаграмма должна быть упомянута в тексте до её появления и сопровождаться пояснением, а не подписью «схема системы». Это одно из типовых требований при проверке оформления.
Комбинируйте три источника: открытые отчёты операторов, паспортные данные оборудования и собственные замеры на учебном стенде. Если используете расчётную модель, обязательно укажите допущения и оцените чувствительность результата к ним — это сильный ход, который часто спасает работу без реального оборудования.
Чек-лист перед сдачей
Если времени на эксперименты уже не осталось — это не повод упрощать работу до пересказа. Мы помогаем разобрать тему по частям: сформулировать задачи под ваши реальные возможности, собрать расчётную модель и выстроить защиту. Первая консультация бесплатная, объём помощи — от 120 часов работы над проектом. Подскажем и по формулировкам, и по оформлению, если вы решите заказать диплом или отдельные его главы.
Материал подготовлен экспертами компании. Мы помогаем студентам с 2010 года. Если вам нужна помощь в разработке темы или оформлении работы, наши специалисты готовы подсказать, как выстроить структуру, какие метрики взять за основу и как связать отраслевой тренд с вашей специальностью. Иногда достаточно одной консультации, чтобы понять, как написать ВКР без переписывания с нуля.
Последнее обновление: 2026-09-20
Источник: Bernie Sanders and AOC propose a ban on data center construction (опубликовано 2026-03-25)
```