Total Cost of Ownership (TCO) для ИИ-проектов: мой кейс расчета

1. Слоистая архитектура AI-инфраструктуры

Инфраструктура AI-решений оптимально описывается через модель из шести взаимосвязанных слоев, каждый из которых выполняет специфические функции и строится на возможностях нижележащих уровней. Такая архитектура обеспечивает модульность, масштабируемость и упрощает управление сложными системами. Нижние слои отвечают за физическую инфраструктуру и базовые ресурсы, средние — за вычисления и хранение данных, а верхние — за оркестрацию, виртуализацию и мониторинг рабочих нагрузок.​

Важное примечание: на самом деле ниже физического слоя еще лежит слой, который можно представить зданием, в котором расположен ЦОД. В здании ЦОД обычно еще есть система пожаротушения, резервные источники питания, каналы связи с внешним миром и другие, влияющие на инфраструктуру модули, но мы ими сейчас умышленно пренебрегаем. Так как для компании уровня “кровавый энтерпрайз” это скорее всего размажется ровным слоем по всем сервисам или будет вообще идти по отдельным статьям затрат. Так что для нашей задачи “рассчитать стоимость инфраструктуры для ИИ-инициативы” — мы этим можем пренебречь.

1.1 Физический слой (ЦОД): Фундамент AI-инфраструктуры

Физический слой представляет собой базис всей инфраструктуры, обеспечивающий надежное электропитание, эффективное охлаждение и физическую защиту оборудования. Этот слой включает в себя:

• системы электроснабжения с резервированием; 

• передовые технологии охлаждения для высокоплотных стоек;

• специализированные корпуса и стойки; 

• а также кабельную инфраструктуру для передачи данных и энергии.​

Система электропитания является критически важным компонентом, обеспечивающим непрерывную работу AI-систем. Современные AI дата-центры требуют подключения к электросетям высокого напряжения от 13.2 кВ для небольших установок, и до 115-230 кВ для гиперскейл-объектов мощностью свыше 100 МВт. Электричество проходит через высоковольтные коммутаторы, понижается трехфазными трансформаторами до операционных уровней 208-480В, затем распределяется через главные распределительные щиты и блоки распределения питания (PDU) к стойкам серверов и системам охлаждения.​

Источники бесперебойного питания (ИБП/UPS) с конфигурацией резервирования N+1, 2N или 2N+1 обеспечивают защиту от сбоев электросети и перепадов напряжения. В схеме N+1 предусматривается один дополнительный модуль UPS сверх необходимого минимума, что позволяет выдерживать отказ одного модуля без потери питания критичных нагрузок. Для AI-инфраструктуры типичное время автономной работы от батарей UPS составляет 15+ минут при полной нагрузке, после чего включаются дизель-генераторы для долгосрочного электроснабжения. Продвинутые системы используют микросети с локальной генерацией и хранилищами энергии, способные работать независимо от основной электросети.​

Система охлаждения решает одну из главных проблем AI-инфраструктуры — отвод огромного количества тепла, генерируемого GPU кластерами (графический процессор (англ. graphics processing unit, GPU)). Откуда вообще взялись и при чем здесь графические процессоры — это отдельная история. Она раскрыта внизу этого материала в приложениях 1 и 2. Традиционное воздушное охлаждение достигает предела эффективности при плотности 20-40 кВт на стойку, в то время как современные AI-стойки потребляют 50-100 кВт, а системы следующего поколения, такие как NVIDIA GB200 NVL72, требуют 140-250 кВт. При таких плотностях физика становится непреклонной: для охлаждения стойки 50 кВт воздухом требуется 220+ кубометров воздуха в минуту при температурном перепаде 20°С, что создает ураганные потоки и делает воздушное охлаждение экономически и практически невозможным.​

Жидкостное охлаждение стало стандартом для AI-инфраструктуры, поскольку вода отводит тепло примерно в 1,000 раз эффективнее воздуха. Существует несколько технологий жидкостного охлаждения: direct-to-chip (прямое охлаждение чипов) подводит хладагент непосредственно к GPU через холодные пластины, обеспечивая охлаждение 30-60 кВт на стойку; rear-door heat exchangers (теплообменники задней двери) устанавливаются на задней панели стойки и обрабатывают до 50 кВт; иммерсионное охлаждение погружает серверы в диэлектрическую жидкость и справляется с плотностью 50-100 кВт и выше. Жидкостное охлаждение не только решает проблему отвода тепла, но и повышает энергоэффективность: показатель PUE (Power Usage Effectiveness) снижается с 1.4-1.8 для воздушных систем до 1.02-1.3 для жидкостных, что означает экономию 10-21% электроэнергии и снижение затрат на охлаждение на 40%.​

Схема физической инфраструктуры AI дата-центра с отображением систем питания, охлаждения и сетевой связности

Стойки и корпуса для AI-инфраструктуры должны выдерживать значительно более высокие нагрузки по мощности и весу, чем традиционное оборудование. Стандартные стойки высотой 42-48 единиц (Units, U) проектируются для поддержки высокоплотных конфигураций с интегрированными системами распределения питания и охлаждения. Типичная AI-стойка содержит 2-4 вычислительных узла, каждый из которых может быть оснащен 8-16 GPU, что суммарно дает 16-64 GPU на стойку в зависимости от конфигурации.​

Кабельная инфраструктура включает структурированные кабельные системы для передачи данных и электропитания. Для межсоединения GPU внутри и между стойками используются медные кабели DAC (Direct Attach Copper) на скоростях 400-800 Гбит/с для коротких расстояний благодаря их энергоэффективности и низкой стоимости. Для магистральных соединений между коммутаторами применяются оптоволоконные кабели, обеспечивающие высокую пропускную способность на больших расстояниях.​

1.2 Сетевой слой: Кровеносная система AI-кластера

Сетевой слой обеспечивает высокоскоростную, низколатентную коммуникацию между вычислительными узлами, системами хранения и внешними сетями. Для AI-инфраструктуры критически важны максимальная пропускная способность для передачи больших объемов данных и минимальная задержка для синхронизации параллельных операций.​

Высокоскоростная сеть для AI-кластеров реализуется с использованием технологий InfiniBand или Ethernet высоких скоростей (400-800 Гбит/с). InfiniBand доминирует в AI-инфраструктуре, занимая около 90% развертываний для обучения моделей благодаря ультранизким задержкам (1-2 микросекунды) и архитектуре без потери пакетов. InfiniBand поддерживает скорости до 800 Гбит/с на порт и агрегированную пропускную способность до 51.2 Тбит/с на коммутатор. Технология RDMA (Remote Direct Memory Access), интегрированная в InfiniBand, позволяет прямую передачу данных память-к-памяти между узлами без вмешательства CPU, что критично для распределенного обучения с частой синхронизацией градиентов.​

Ethernet с протоколом RDMA over Converged Ethernet (RoCE) становится конкурентоспособной альтернативой для AI-кластеров. Ethernet 400-800 Гбит/с с RoCE обеспечивает задержки на уровне sub-микросекунд, приближаясь к InfiniBand. Преимущества Ethernet включают открытые стандарты, широкую экспертизу инженеров, более быстрый темп развития благодаря массовому внедрению, и улучшенную отказоустойчивость за счет распределенной архитектуры, где каждый коммутатор принимает локальные решения. Тесты показывают, что в сложных задачах обучения AI Ethernet может обеспечить до 10% улучшение времени завершения заданий по сравнению с InfiniBand. Прогнозы указывают, что к 2028 году 45% генеративных AI-нагрузок будут работать на Ethernet.​

Топология Leaf-Spine (листовые и магистральные коммутаторы) является стандартом для сетевой архитектуры AI дата-центров. В этой 2-3 уровневой топологии Fat-Tree каждый leaf (листовой) коммутатор подключает 16-32 GPU узла внутри одной или нескольких стоек, обеспечивая внутристоечную и межстоечную связность на скоростях 400-800 Гбит/с. Spine (магистральные) коммутаторы располагаются в отдельных стойках и создают высокоскоростную магистраль, соединяя все leaf коммутаторы между собой. Каждый leaf коммутатор подключается к каждому spine коммутатору одним или несколькими каналами, создавая несколько равноценных путей между любыми двумя GPU узлами в кластере.​

Для кластера из 8,000 GPU (например, NVIDIA DGX SuperPOD) может использоваться конфигурация из 40 leaf коммутаторов (каждый обслуживает 200 GPU) и 20 spine коммутаторов, обеспечивающих полносвязную топологию без блокировок. GPU внутри одного узла связываются через NVLink (900 ГБ/с), GPU между узлами одной стойки — через ConnectX NIC и leaf коммутатор, а GPU между разными стойками — через путь: NIC → Leaf → Spine → Leaf → NIC.​

Out-of-Band (OOB) управление представляет собой отдельную выделенную сеть для удаленного доступа, мониторинга и управления оборудованием. Через интерфейсы IPMI (Intelligent Platform Management Interface) администраторы могут контролировать серверы, коммутаторы и другое оборудование независимо от основной операционной системы, даже при ее отказе. OOB сеть обычно работает на скоростях 1-10 Гбит/с, что достаточно для задач управления.​

RDMA и RoCE протоколы критически важны для производительности AI-кластеров. RDMA (Remote Direct Memory Access) позволяет одному компьютеру напрямую обращаться к памяти другого без участия CPU, операционной системы или контекстных переключений. Это снижает задержку до 1-2 микросекунд и освобождает CPU для вычислительных задач вместо обработки сетевого трафика. В распределенном обучении AI, где каждая итерация требует синхронизации градиентов между тысячами GPU, RDMA обеспечивает почти мгновенную коммуникацию, необходимую для эффективного масштабирования. RoCE (RDMA over Converged Ethernet) реализует RDMA поверх Ethernet, объединяя преимущества RDMA с экономической эффективностью и универсальностью Ethernet.​

NVLink и NVSwitch формируют основу высокоскоростных внутрисерверных и внутристоечных коммуникаций. NVLink представляет собой масштабируемое соединение для крупных мульти-GPU систем, позволяя GPU разделять память и вычисления для обучения, инференса и ризонинга (reasoning, рассуждения ЛЛМ). NVSwitch работает совместно с NVLink для построения высокоскоростного взаимодействия.​

NVLink и NVSwitch — это технологии NVIDIA, предназначенные для высокоскоростного соединения нескольких GPU (графических процессоров) в вычислительных системах, особенно для искусственного интеллекта (ИИ) и высокопроизводительных вычислений (HPC).

Что такое NVLink

• NVLink — это высокоскоростной интерфейс связи между GPU, обеспечивающий передачу данных с пропускной способностью, существенно превосходящей стандартный PCIe (например, до 300 ГБ/с на Tesla V100 и до 900 ГБ/с на NVIDIA H100).​

• NVLink позволяет напрямую соединять несколько GPU, создавая быструю шину передачи данных без посредничества CPU, что увеличивает скорость обмена и уменьшает задержки.

• Пример: NVLink Bridge — физический мост, соединяющий две видеокарты для повышения совместной производительности и увеличения объема доступной памяти.​

• Технология поддерживает до 8 GPU в одной виртуальной машине, улучшая масштабируемость и эффективность в задачах глубокого обучения.​

Что такое NVSwitch

• NVSwitch — это коммутатор (switch) следующего поколения, который расширяет возможности NVLink, позволяя связать многие GPU (до 256 у NVIDIA H100) в единую высокопроизводительную сеть с архитектурой «каждый с каждым».​

• NVSwitch создает неблокирующую сеть с очень низкой задержкой и высокой пропускной способностью, при этом любой GPU может напрямую обмениваться данными с любым другим GPU в системе на максимальной скорости.

• Технология используется в высокопроизводительных серверных платформах NVIDIA DGX и HGX, которые применяются для сложных вычислительных задач в ИИ и HPC.​

• NVSwitch значительно увеличивает масштабируемость систем и упрощает построение суперкомпьютеров для ИИ. 

1.3 Слой хранения данных: Фундамент для больших данных

Успешное развертывание высокопроизводительной инфраструктуры для искусственного интеллекта определяется не только вычислительной мощностью GPU, но и способностью эффективно доставлять данные к графическим процессорам и обеспечивать бесшовную коммуникацию между компонентами системы. Сетевая инфраструктура и системы хранения данных представляют критические компоненты, часто становящиеся узким местом в производительности AI-кластеров. Современные языковые модели требуют обработки петабайтных датасетов и непрерывного обмена градиентами между тысячами GPU, что предъявляет беспрецедентные требования к пропускной способности, латентности (времени отклика) и надежности сетевых систем и систем хранения данных. Данная глава представляет комплексный анализ архитектурных требований к сетевым компонентам (networking) и компонентам хранения данных (storage) для AI-кластеров.

Слой хранения обеспечивает масштабируемое, высокопроизводительное хранилище для огромных объемов данных, необходимых для обучения и инференса AI-моделей. AI-проекты требуют доступа к петабайтам тренировочных данных, включая неструктурированные файлы (изображения, видео, текст) и структурированные данные из баз данных.​

Распределенные файловые системы (Lustre, Ceph, HDFS) являются стандартом для хранения тренировочных датасетов в AI-инфраструктуре. Эти системы распределяют данные по множеству серверов хранения, обеспечивая параллельный доступ от тысяч GPU узлов одновременно. Lustre широко используется в HPC и AI-кластерах благодаря высокой пропускной способности (сотни ГБ/с) и масштабируемости до 100+ петабайт. Ceph обеспечивает объектное, блочное и файловое хранение в единой системе с самовосстановлением и репликацией данных. Эти файловые системы подключаются через высокоскоростные сети InfiniBand или RDMA-enabled Ethernet для минимизации задержек доступа.​

SAN (Storage Area Network) предоставляет блочное хранилище с высокими IOPS (операций ввода-вывода в секунду) и низкими задержками (<1 мс), что необходимо для производственных баз данных и приложений, требующих быстрого случайного доступа. SAN традиционно использует протокол Fibre Channel, но современные системы переходят на NVMe over Fabrics (NVMe-oF), который передает команды NVMe через сетевые фабрики с задержками в несколько микросекунд. Для AI-задач SAN подходит для хранения векторизированных данных и метаданных моделей, где критична скорость доступа.​

NAS (Network Attached Storage) обеспечивает файловое хранилище через протоколы NFS (Network File System) и SMB/CIFS, идеально для неструктурированных данных — документов, изображений, аудио, видео. NAS более экономичен и проще в масштабировании по сравнению с SAN, поэтому часто используется для хранения больших объемов тренировочных данных, к которым не требуется экстремально низкая задержка. Для AI-проектов с документами или медиафайлами NAS является оптимальным выбором.​

Выбор между SAN, NAS и распределенными системами зависит от типа данных и рабочей нагрузки. Неструктурированные данные (документы, изображения) хорошо подходят для NAS или распределенных ФС, структурированные данные из БД — для SAN, а большие тренировочные датасеты для распределенного обучения — для Lustre/Ceph с параллельным доступом.​

1.4 Вычислительный слой: Сердце AI-системы

Вычислительный слой содержит основные процессорные ресурсы для обучения и инференса AI-моделей. Этот слой строится вокруг GPU кластеров как центральных элементов для параллельных вычислений, дополненных CPU серверами для управления и предобработки данных, а также специализированными межсоединениями для высокоскоростного обмена данными между ускорителями.​

Примечание 1: Обучение ИИ-моделей — это процесс настройки параметров модели (например, весов нейронной сети) на основе обучающих данных с целью минимизации ошибки между предсказаниями модели и правильными ответами. В ходе обучения модель учится распознавать закономерности, решать задачи и обобщать на новых данных.​ Для нейронной сети обучение означает поиск оптимальных значений весов, при которых модель способна выдавать правильные результаты для входных данных.

Примечание 2: Инференс ИИ-моделей — это процесс применения уже обученной модели искусственного интеллекта к новым (еще не виденным) данным для получения предсказаний или решений. Во время инференса модель использует свои фиксированные веса и структуру, чтобы анализировать входные данные и выдавать результат, не меняя параметров.​ Т.е. инференс — это этап, когда модель отвечает на реальные запросы, например, распознает объекты на изображениях, понимает речь, переводит текст или генерирует ответы в чат-боте

GPU кластеры представляют собой распределенные вычислительные системы, где множество графических процессоров объединены через высокоскоростные сетевые соединения. Типичный GPU узел содержит 8-16 графических ускорителей NVIDIA A100, H100, H200 или AMD MI300X, каждый из которых обладает десятками тысяч вычислительных ядер для параллельной обработки. Размер кластера варьируется от нескольких десятков GPU для небольших проектов до 8,000-100,000 GPU для обучения крупных языковых моделей в гиперскейл-инфраструктуре.​

Архитектура GPU кластеров следует распределенной вычислительной модели с несколькими типами узлов. Вычислительные узлы (GPU nodes) являются основными рабочими элементами, выполняющими AI-задачи; каждый узел содержит 8-16 GPU плюс CPU ядра для задач, не ускоряемых GPU. Управляющие узлы (head/management nodes) координируют работу кластера, управляют распределением заданий, мониторингом и оркестрацией. Общие узлы (shared nodes) обеспечивают доступ к разделяемым ресурсам, таким как системы хранения и сетевые сервисы. Система управления кластером обеспечивает балансировку нагрузки, планирование заданий и отказоустойчивость, распределяя рабочую нагрузку равномерно между GPU и обрабатывая сбои с минимальным влиянием на производительность.​

Межсоединение GPU (NVLink и NVSwitch) — это проприетарная технология NVIDIA для высокоскоростного соединения GPU между собой и с CPU. В отличие от стандартного PCIe, NVLink использует множественные последовательные каналы для прямой передачи данных между процессорами без использования медленных системных шин. Каждое NVLink-соединение состоит из нескольких линий (например, 8 линий в NVLink 3.0), каждая из которых обеспечивает до 50 ГБ/с двунаправленной пропускной способности. В конфигурации с 8 GPU NVIDIA H100 суммарная пропускная способность GPU-to-GPU достигает 900 ГБ/с, что в 7 раз превышает скорость PCIe Gen 5 и в 28 раз — PCIe Gen 3.​

NVLink поддерживает кэш-когерентность и общую память через технологию NVIDIA NVSHMEM, позволяя GPU напрямую обращаться к памяти друг друга без копирования данных и вмешательства CPU. Для масштабирования до десятков и сотен GPU используется NVSwitch — коммутатор, создающий полносвязную топологию «все-ко-всем», где каждый GPU может напрямо общаться с любым другим GPU в системе с равной полосой пропускания. Такая архитектура критична для распределенного обучения больших моделей, где частая синхронизация градиентов между GPU является узким местом производительности.​

CPU серверы выполняют задачи, не требующие массового параллелизма GPU: управление кластером, предобработку данных, оркестрацию рабочих процессов. Типичный управляющий узел содержит 2 CPU с 64-128 ядрами и 256-512 ГБ оперативной памяти DDR5. Некоторые системы используют гетерогенную архитектуру с CPU POWER или ARM, оптимизированными для совместной работы с GPU через NVLink.​

Память и локальное хранилище на уровне вычислительных узлов включает высокоскоростную память GPU и локальные накопители для кэширования данных. Современные GPU используют память HBM3 (High Bandwidth Memory) с пропускной способностью до 3+ ТБ/с и объемом 80-192 ГБ на GPU. Для временного хранения данных тренировки и чекпоинтов моделей узлы оснащаются 8-16 ТБ NVMe SSD накопителей, обеспечивающих скорости чтения/записи 7+ ГБ/с.​

1.5 Слой виртуализации и оркестрации: Управление ресурсами

Слой виртуализации и оркестрации абстрагирует базовое оборудование и автоматизирует развертывание, масштабирование и управление AI-приложениями. Этот слой включает контейнеризацию для изоляции рабочих нагрузок, оркестрацию для автоматического управления ресурсами и виртуализацию для запуска legacy-приложений.​

Контейнеризация (Docker) упаковывает AI-модели с их зависимостями в единый портативный контейнер, обеспечивая согласованность между средами разработки, тестирования и продакшена. Контейнеры являются легковесными по сравнению с виртуальными машинами, поскольку используют общее ядро операционной системы хоста и запускаются за секунды. Для запуска GPU-приложений в контейнерах используется NVIDIA Container Toolkit, который пробрасывает GPU устройства в контейнер и обеспечивает доступ к драйверам. Контейнеры стали стандартом де-факто для развертывания ML-моделей благодаря портативности и изоляции.​​

Оркестрация (Kubernetes) автоматизирует развертывание, масштабирование и управление контейнеризированными приложениями в распределенных средах. Kubernetes абстрагирует базовое оборудование, позволяя описывать желаемое состояние системы декларативно, а затем автоматически поддерживать это состояние. Для AI-задач Kubernetes предоставляет критически важные возможности: динамическое масштабирование GPU-ресурсов в зависимости от нагрузки через Kubernetes autoscaler и GPU device plugin; планирование GPU распределяет задачи по доступным GPU с учетом требований к ресурсам; управление жизненным циклом моделей через интеграцию с MLOps инструментами; multi-tenancy позволяет множеству команд разделять один кластер с изоляцией ресурсов.​​

Специализированные расширения, такие как Kubeflow, дополняют Kubernetes инструментами для end-to-end ML-пайплайнов, включая подготовку данных, обучение моделей, гиперпараметрическую оптимизацию и развертывание. Kubernetes GPU Operator автоматизирует установку NVIDIA драйверов, CUDA toolkit и GPU device plugin на всех узлах кластера.​​

Виртуализация (KubeVirt) позволяет запускать традиционные виртуальные машины внутри Kubernetes как обычные pods. KubeVirt использует контейнер как sandbox для запуска процесса виртуальной машины (QEMU), что позволяет управлять VM через стандартный Kubernetes API. Для AI-инфраструктуры это критично для запуска legacy-приложений, которые не могут быть легко контейнеризованы, позволяя организациям модернизировать инфраструктуру постепенно, без необходимости немедленной переработки всех приложений. Унификация VM и контейнеров на единой платформе упрощает операционные процессы и снижает сложность стека.​

1.6 Слой управления и мониторинга: Наблюдаемость и оптимизация

Верхний слой обеспечивает непрерывный мониторинг, управление экспериментами и оптимизацию производительности AI-инфраструктуры. Этот слой критичен для поддержания надежности, выявления проблем производительности и обеспечения эффективного использования дорогостоящих ресурсов.​

Системы мониторинга (Prometheus, Grafana, Datadog) собирают и визуализируют метрики в реальном времени со всех уровней инфраструктуры. Prometheus собирает метрики использования GPU (утилизация, температура, память), CPU, памяти, сети и хранилища с помощью exporters, развернутых на каждом узле. Grafana создает интерактивные дашборды для визуализации метрик и трендов, позволяя инженерам быстро идентифицировать узкие места и аномалии. Datadog и Dynatrace предоставляют AI-powered observability с автоматическим обнаружением аномалий, корреляцией метрик и предиктивной аналитикой. Алертинг уведомляет команды о критических событиях, таких как падение производительности модели, дрейф данных или отказы оборудования.​

MLOps инструменты (MLflow, Neptune.ai, Weights & Biases) управляют полным жизненным циклом ML-моделей от экспериментов до продакшена. Эти платформы обеспечивают: версионирование моделей и кода для отслеживания изменений и воспроизводимости экспериментов; tracking экспериментов записывает гиперпараметры, метрики и артефакты каждого запуска тренировки; мониторинг моделей в продакшене отслеживает производительность, дрейф данных и качество предсказаний; feature store управляет признаками для обучения и инференса; model registry централизованно хранит версии моделей с метаданными.​

Интеграция MLOps инструментов с Kubernetes и системами мониторинга создает единую платформу для управления ML-операциями. Автоматизированные пайплайны CI/CD для ML (Continuous Integration / Continuous Deployment) обеспечивают автоматическое тестирование, валидацию и развертывание моделей.​

Планировщики заданий (SLURM, Kubernetes Job Scheduler) управляют очередями задач и распределяют GPU ресурсы между множественными пользователями и проектами. SLURM (Simple Linux Utility for Resource Management) является стандартом для HPC и AI-кластеров, обеспечивая справедливое распределение ресурсов, приоритезацию задач и эффективную утилизацию GPU. Kubernetes Job Scheduler управляет краткосрочными задачами (Jobs) и долгоживущими сервисами (Deployments), автоматически перезапуская failed задачи и масштабируя ресурсы.​

Итого про слои

Инфраструктура для AI и LLM представляет собой сложную многослойную экосистему, где каждый компонент играет критическую роль в обеспечении производительности, надежности и масштабируемости. От физического слоя с системами электропитания мощностью десятки мегаватт и передовым жидкостным охлаждением, через вычислительные GPU кластеры с тысячами ускорителей и высокоскоростными межсоединениями NVLink, до верхних слоев виртуализации, оркестрации и мониторинга — все элементы должны работать согласованно для достижения целей AI-проектов.​

Ключевые отличия AI-инфраструктуры от традиционных дата-центров включают экстремальные требования к мощности (50-250 кВт на стойку против 5-15 кВт обычно), необходимость жидкостного охлаждения вместо воздушного, критичность ультранизких задержек в сети (1-2 микросекунды), и специализированные GPU-ориентированные системы оркестрации. Организации, планирующие развертывание AI-инфраструктуры, должны тщательно оценить требования к мощности и охлаждению, выбрать подходящий уровень Tier для надежности, спланировать масштабируемость, и инвестировать в MLOps практики и инструменты для эффективного управления жизненным циклом моделей.​

Что такое CapEx (капитальные затраты) для ТСО?

Определение CapEx простыми словами (от англ. Capital Expenditure — капитальные затраты) — это крупные деньги, которые компания тратит один раз на покупку оборудования.​ Если ТСО-это вся стоимость на весь период, то CapEx — это первый, большой платеж.​

Ключевые характеристики CapEx:

• Когда платим? Один раз (или несколько больших платежей). Нужно выделить крупный бюджет заранее;

• Размер платежа: Большие суммы ($500K — $2M+) Требует одобрения от финдиректора;

• Что это? Покупка активов (оборудование, здания, лицензии) Компания чем-то владеет после покупки;

• Бухгалтерский учет: Попадает в баланс как актив. Амортизируется (списывается) в течение 3-6 лет;

• Налоги: Не влияет прямо на прибыль текущего года. Амортизация потом будет вычитаться из прибыли ежегодно, пока не закончится срок использования;

• Срок полезного использования: обычно 3-5 лет (для ИИ-оборудования). GPU теряют эффективность через 2-3 года (в т.ч. потому что выходят новые поколения оборудования гораздо большей производительности).

Пример (упрощенный, дальше по ходу статьи мы рассмотрим более сложную формулу): компания решила купить GPU-кластер. Они тратят деньги в первый же месяц  (капитальная инвестиция, цены предложил ИИ, они абстрактные и приведены для понимания расчетов, дальше по ходу статьи мы возьмем реальный пример):

• Покупка 8x H100 GPU: $260,000;

• Серверы и материнские платы: $40,000;

• Система охлаждения: $60,000;

• Сетевое оборудование: $30,000;

• Монтаж и установка: $10,000.

ИТОГО: CapEx: $400,000 (тратят один раз в начале) Эта сумма $400,000 попадает в баланс компании как актив. Затем каждый год амортизируется: 5-летняя амортизация: $400,000 ÷ 5 = $80,000/год списывается как расход.

Компания платит один раз, но расходы распределяются на 5 лет через амортизацию.

Что такое OpEx (операционные затраты) для ТСО?

Определение OpEx простыми словами (от англ. Operating Expenditure — операционные затраты) — это регулярные платежи каждый месяц или год на содержание и работу оборудования.​ Если CapEx-это покупка один раз, то OpEx-это содержание каждый день.​ Примеры OpEx для ИИ:

• Ежемесячный счет за электроэнергию для GPU-кластера: $10,000 — $30,000​;

• Зарплата инженера (обслуживает инфраструктуру): $5,000 — $15,000 в месяц​;

• Аренда помещения для дата-центра: $5,000 — $20,000 в месяц​;

• Облачные услуги (backup, дополнительные вычисления): $3,000 — $10,000 в месяц​;

• Техническое обслуживание и запасные части: $500 — $2,000 в месяц​.

Итого OpEx в месяц для базовой ИИ-системы: $25,000 — $60,000.​

Ключевые характеристики OpEx

• Когда платим? Каждый месяц, каждый год (регулярно). Постоянные расходы — нужны деньги из выручки.

• Размер платежа: обычно меньше, чем CapEx, но часто большой за весь период. За 5 лет OpEx может превысить CapEx в 5-10 раз.

• Что это? Содержание и работа активов. Без OpEx оборудование не работает.

• Бухгалтерский учет: Вычитается из прибыли сразу в текущем году. Снижает налог на прибыль текущего года.

• Налоги: 100% вычитается из налоговой базы. В текущем налоговом периоде.

• Предсказуемость: Обычно стабильны (или растут на 5-10%/год). Можно планировать в годовой бюджет.

Пример OpEx для ИИ-проекта

У компании уже есть GPU-кластер (купили за $400K в прошлом году). Теперь каждый месяц они платят ежемесячные расходы (операционные затраты):

• Электроэнергия (GPU потребляют 40 кВт × 720 часов): $2,880;

• Охлаждение (обычно 40-50% от электроэнергии): $1,440;

• Зарплата 1 инженера (обслуживает систему): $10,000;

• CUDA лицензии и ПО: $500;

• Техническое обслуживание (запасные части): $600;

• Облачные backup-сервисы: $1,000.

ИТОГО OpEx в месяц: $16,420 (или ~$197,000 в год)

Эти расходы вычитаются из прибыли компании прямо сейчас. Они не попадают в баланс как активы — они просто списываются как расходы ежемесячно.

ТСО = Capex + Opex

Формула простыми словами ТСО = CapEx (один раз) + (OpEx каждый месяц × количество лет полезного использования × 12). 

Конкретный пример за 5 лет, используя наш пример выше:

• CapEx (один раз в начале): Всё оборудование: $400,000

• OpEx (каждый месяц): 

  • В месяц: $16,420; 

  • В год: $197,000;

  • За 5 лет: $197,000 × 5 = $985,000

ИТОГО ТСО за 5 лет = $ 400,000 + $985,000 = $1,385,000

Компания потратит $1.385 млн за 5 лет на эту ИИ-систему. Из них:

• 29% ($400K) платили один раз в начале (CapEx);

• 71% ($985K) платили регулярно каждый месяц (OpEx);

Если бы компания использовала облако вместо собственной инфраструктуры, то:

• CapEx: $0;

• OpEx в облаке: $30,000-$50,000/месяц (только за GPU);

ТСО облака за 5 лет: $0 + ($40,000 × 12 × 5) = $2,400,000

На on-premise дешевле на $1,015,000 (43% экономия!) за 5 лет.​ Но только если компания постоянно использует оборудование на 70%+. Если нагрузка переменная (30-50%), облако может быть дешевле (без учета того, что его вообще можно использовать из-за NDA данных, законодательных и регуляторных ограничений и тд.).​

Примечание: цифры взяты абстрактные для, которые мы в обнимку с ИИ нарыли в открытых данных. Поэтому доллары. Для точных расчетов необходимо учитывать конкретные суммы по бухгалтерии конкретной компании. Потому что даже тарифы на электроэнергию разных ЦОДов могут отличаться, что уж говорить о закупочных ценах, которые подвержены изменениям и не учитывают скидки/наценки от поставщиков и партнеров. Да, в реальной жизни все сложно и без специализированной системы учета будет туго. Тут обычно используются ITAM решения, например (по одной из первых ссылок в поиске — http://itam2.ru).

Эффективная система аллокации затрат требует четкого определения драйверов, то есть метрик, на основе которых распределяются расходы между проектами и командами. Каждый слой архитектуры имеет свой оптимальный драйвер аллокации.

Для слоя Infrastructure рекомендуется комбинированный подход: Direct Cost Allocation для фиксированных расходов (facilities) и Usage-Based для переменных расходов (электроэнергия). Первичный драйвер — мощность в кВт, вторичный — коэффициент PUE. Для справки: типичная система из 30,000 GPU H100 требует ~35.2 МВт мощности при 80% использовании, стоимость ~$25.35 млн в год только на электроэнергию.​

Для слоя Network применяется Usage-Based метод с первичным драйвером — объем данных, переданных между узлами (Гб). Сбор данных происходит в реальном времени через NetFlow, с почасовым обновлением. Организации должны планировать 10-100 Гбит/с для ИИ-workloads.​

Для слоя Storage оптимален Capacity-Based метод аллокации: первичный драйвер — объем используемого хранилища (ТБ). Однако рекомендуется дифференцирование между hot и cold storage (архивы и бекапы) с разными тарифами.​ Данные агрегируются за месяц

Для слоя Hardware используется GPU-Hour Consumption — самый точный и справедливый метод. Первичный драйвер — GPU-часы использования, вторичный — тип GPU (H100 дороже, чем A100). Данные собираются в реальном времени через nvidia-smi и Kubernetes metrics и агрегируются за месяц.​

Для слоя Virtualization применяется Node/Container Count метод: первичный драйвер — количество узлов и контейнеров. Ежедневное обновление через Kubecost и агрегация за месяц.​

Для слоя Software используется гибридный Per-Model + Per-User метод: первичный драйвер — количество моделей, вторичный — количество пользователей.Ежемесячное обновление через MLOps платформы.​

Все это удобнее всего делать в специализированных решениях ITAM (например A-Tracker от http://itam2.ru), т.к. система аллокации может быть очень сложной. Для примера приведу кусочек такой модели (только 3-х слоев из 8).

Практическая реализация системы аллокации для ИИ-решений

Внедрение модели аллокации требует нескольких критических компонентов: инструментов мониторинга, системы бухгалтерского учета, процессов валидации и регулярной оптимизации.

Этап 1: Инструменты сбора данных

Для каждого слоя требуются специализированные инструменты для сбора реальных данных по драйверам аллокации:

• Infrastructure: DCIM-система (Schneider Electric EcoStruxure, Nlyte Software), мониторинг PDU;

• Network: NetFlow collector, cloud billing API (AWS CUR, Azure Cost Management);

• Storage: API поставщика хранилища (NetApp, Pure, EMC), cloud object storage API;

• Hardware: NVIDIA DCGM, Kubernetes metrics (Prometheus + kubelet), cloud compute billing;

• Virtualization: Kubecost, kubectl, cloud Kubernetes monitoring;

• Software: MLOps платформа API (MLflow, W&B, Neptune), LDAP/AD для пользователей.

Этап 2: Интеграция с системой финансового учета

Все данные должны ежедневно/ежемесячно загружаться в систему управления ИТ-активами.​

Этап 3: Валидация и согласование

Ежемесячно проводится сверка с фактическими счетами поставщиков (облачных провайдеров, дата-центра), корректировка коэффициентов аллокации при необходимости.

Этап 4: Отчетность и оптимизация

На основе данных аллокации готовятся ежемесячные отчеты по слоям и проектам, выявляются области переплаты, разрабатываются рекомендации по оптимизации.​