ARM AGI CPU для ЦОД в дипломе: темы ВКР, метрики и защита

25 марта 2026 года британская ARM впервые за 35 лет показала собственный физический процессор — AGI CPU. До этого компания десятилетиями жила на лицензировании архитектур, а теперь идёт напрямую в серверный сегмент, где позиции Intel Xeon и AMD EPYC казались незыблемыми. Первым крупным клиентом стала Meta* (компания признана экстремистской организацией на территории РФ). Для выпускника ИТ-направления это не просто новость из мира железа. Это готовый полигон для ВКР: сравнение aarch64 и x86-64, пересчёт TCO дата-центра, мультиархитектурные сборки, энергоэффективность. Разберём, как превратить этот кейс в защищаемую работу — с бенчмарками, диаграммами развёртывания и оформлением по ГОСТ.

Три темы ВКР, которые буквально лежат на поверхности

Тема 1. Сравнительный анализ ARM AGI CPU и x86-64 в типовых серверных нагрузках

Актуальность. Статья фиксирует сдвиг рынка: ARM выходит за пределы мобильного и встроенного сегментов прямо в стойку ЦОД. Сравнивать архитектуры «в общем» бессмысленно — нужен измеримый стенд под конкретный профиль (веб-API, база данных, ML-инференс).

Цель. Получить воспроизводимую оценку производительности ARM-серверов и x86-64 на выбранном наборе нагрузок.

Задачи. (1) Классифицировать нагрузочные профили и метрики; (2) спроектировать тестовый стенд и методику замеров; (3) провести серию экспериментов с повторами; (4) интерпретировать различия через ISO/IEC 25010 (performance efficiency, reliability).

Структура. Глава 1 — архитектуры и история ARM/x86-64. Глава 2 — стенд, конфигурация, инструменты замеров. Глава 3 — результаты, доверительные интервалы, выводы.

Тема 2. Оценка TCO и энергоэффективности миграции ЦОД на ARM

Актуальность. ARM позиционирует AGI CPU именно как решение для дата-центров, а значит TCO и ватт/операция становятся главным аргументом в пользу или против миграции.

Цель. Построить модель TCO для трёхлетнего жизненного цикла в двух сценариях: остаётся x86-парк vs переход на ARM.

Задачи. (1) Собрать CAPEX/OPEX-модель с учётом питания и охлаждения; (2) посчитать энергопотребление на нагрузку; (3) смоделировать стоимость миграции ПО; (4) выполнить sensitivity-анализ по трём ключевым параметрам.

Структура. Глава 1 — рынок серверных CPU и TCO как метрика. Глава 2 — финансовая модель и её реализация в Python/Excel. Глава 3 — сценарии, графики, рекомендации.

Тема 3. Мультиархитектурный CI/CD-пайплайн для ARM-нод Kubernetes

Актуальность. Если ARM реально приходит в ЦОД, то пайплайны должны собирать один и тот же образ под linux/amd64 и linux/arm64 без ручных правок.

Цель. Спроектировать и проверить конвейер сборки/деплоя с артефактами под обе архитектуры.

Задачи. (1) Разобрать buildx и multi-arch-манифесты; (2) настроить сборку в GitHub Actions/GitLab CI; (3) развернуть сервис в K8s с nodeSelector; (4) измерить время сборки, размер образа и стабильность.

Структура. Глава 1 — контейнеризация и мультиархитектурные сборки. Глава 2 — архитектура пайплайна (C4 Container). Глава 3 — тесты, метрики, интеграция с OpenTelemetry.

Как встроить кейс ARM в главы без «воды» и реферата

Глава 1: не пересказ новости, а аналитическая рамка

Не начинайте с фразы «ARM выпустила процессор». Начинайте с вопроса: почему лицензионная модель ARM 35 лет не предполагала собственного кремния и что изменилось в экономике ЦОД. Стройте контекстную C4-диаграмму (ARM, Meta*, гиперскейлеры, Intel, AMD, OEM-вендоры) и временную шкалу архитектурных вех. Ссылку на новость дайте как первоисточник — так у экспертной комиссии не будет вопросов «откуда цифры».

Глава 2: измеримый стенд и мультиархитектурная сборка

Здесь самое ценное — конкретика. Если тема про CI/CD, приведите рабочие команды, а не слова «была настроена автоматизированная сборка». Пример минимального скрипта под обе архитектуры:

# Мультиархитектурная сборка одного образа
docker buildx create --name multiarch --use
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t registry.example.com/backend:1.0 \
  --push .

А вот так сервис фиксируется на ARM-пуле в Kubernetes — это уже артефакт для приложения к ВКР:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
spec:
  replicas: 4
  template:
    spec:
      nodeSelector:
        kubernetes.io/arch: arm64
      containers:
        - name: backend
          image: registry.example.com/backend:1.0
          resources:
            requests: { cpu: "500m", memory: "512Mi" }

Глава 3: метрики, которые можно защитить

Комиссия любит цифры, но не любит одну строку «стало в 1,4 раза лучше». Нужна таблица метрик с единицами измерения, инструментом получения и погрешностью. Опорный набор для этой темы:

Нормоконтроль: где чаще всего снимают баллы

Схемы должны быть выполнены в нотации, которую вы объявили в введении. Если пишете «UML deployment», не подсовывайте рисунок из Paint. Для К8s-стенда удобны C4 Container и UML Deployment. Текстовые описания процессов — по ГОСТ 34.601-90 и ГОСТ 19.402-78 (руководство пользователя и описание программы). Листинги — в приложения, нумерация по ГОСТ 19.401.

Чему вы реально научитесь на этой теме

• Строить нагрузочные сценарии и повторяемые бенчмарки, а не «замерял один раз».
• Считать TCO и энергоэффективность как инженерную метрику, а не как маркетинговый лозунг.
• Настраивать мультиархитектурные сборки и деплой в Kubernetes на разнородном парке нод.
• Оформлять архитектурные схемы по C4/UML и приводить их в соответствие с ГОСТ 34/19.
• Защищать решения цифрами: p95-задержка, J/op, ₽ за 1000 rps.

Вопросы, которые задают чаще всего

Источник: Британский разработчик ARM представил первый за 35 лет собственный процессор — «убийцу» Intel и AMD (опубликовано 2026-03-25)

* Meta признана экстремистской организацией на территории РФ.