Всем привет! Меня зовут Дмитрий Крупенин, я создаю внутренние и B2B ИТ-решения. Специализируюсь на цифровых продуктах для внутреннего использования в корпорациях. 

Сейчас очень активно развиваются продукты и решения с использованием ИИ, однако не всегда удается легко посчитать экономику таких проектов, если мы говорим о необходимости развертывания этих решений внутри. Это может быть необходимо для крупных компаний (особенно банков и биг.теха), где законодательно нельзя отдавать персональные и корпоративные данные в облачные модели ЛЛМ. Хочется разобраться, как посчитать совокупную стоимость владения таким проектом, с учетом инфраструктуры, модели, данных для обучения и т.д. Так как это потребовало довольно объемного изучения предметной области — пришлось разбить материал на несколько статей:

• Статья 1: «Специализированное оборудование». Исследовательская статья, как эволюционировали решения для ИИ и почему. LLM-1. Специализированные решения для ИИ-кластеров

• Статья 2: «Архитектура ИИ-инфраструктуры: от GPU-кластеров до облачных решений» Комплексный обзор современных подходов к построению инфраструктуры для ИИ. LLM-2. Архитектура ИИ-инфраструктуры: от GPU-кластеров до облачных решений

• Статья 3: «Total Cost of Ownership (TCO) для ИИ-проектов: полная методология расчета». Комплексная методология оценки совокупной стоимости владения ИИ-решениями. LLM-3. Total Cost of Ownership (TCO) для ИИ-проектов: полная методология расчета

• Статья 4: «Аллокация затрат на ИИ: модели распределения и тарификации» Разработка справедливых моделей распределения затрат на ИИ-ресурсы. LLM-4. Аллокация затрат на ИИ-кластер: методология расчета [Вы здесь]

• Статья 5: «Управление ИТ-активами в эпоху ИИ: эволюция ITAM». Адаптация практик управления ИТ-активами под специфику ИИ-решений.LLM-5. Управление ИТ-активами в эпоху ИИ: эволюция ITAM. Адаптация практик управления ИТ-активами под специфику ИИ-решений

Давайте разбираться вместе.

Введение: что такое аллокация затрат на ИТ-активы и зачем она нужна

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

Современные организации, особенно крупные холдинги и компании с развитыми ИТ-экосистемами, сталкиваются с проблемой «черного ящика» IT: общий бюджет на информационные технологии известен, но непонятно, какой именно процент уходит на обслуживание конкретного продукта, подразделения или проекта. Аллокация затрат решает эту проблему путем внедрения прозрачной системы калькуляции, которая распределяет каждый рубль, потраченный на IT, до его конечного потребителя.​

Основные бизнес-задачи, которые решает аллокация затрат:

1. Повышение ответственности и осведомленности — когда каждое подразделение видит в своей смете реальную стоимость IT-услуг, оно становится более бережным к использованию ресурсов и менее склонно к необоснованным запросам на расширение инфраструктуры. Отсутствие видимых затрат часто приводит к расточительству.​

2. Справедливое распределение расходов — без аллокации одни подразделения могут непропорционально субсидировать другие. Например, если отдел продаж активно использует облако и GPU-ресурсы, а бухгалтерия почти не использует, то без аллокации оба платят, например, поровну, что несправедливо.​

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

4. Обоснованные решения по инвестициям — при планировании новых проектов или оптимизации инфраструктуры руководство может точно оценить, во сколько обойдет тот или иной IT-сервис, и сравнить варианты (собственное оборудование vs. облако, лизинг vs. покупка).​

5. Контроль над облачными расходами — в эпоху облачных вычислений и подписочных моделей аллокация особенно критична, так как расходы могут быстро расти незаметно. Система аллокации позволяет оперативно выявить «утечки» и чрезмерное использование ресурсов.​

6. Успешный процесс M&A и реструктуризации — когда холдинг выделяет или интегрирует подразделение, аллокация позволяет точно рассчитать, какие IT-затраты «уходят» с выделяемым подразделением и какие остаются в оставшейся компании.​

На практике компании используют две основные модели аллокации: Chargeback (когда бизнес-подразделения получают реальные счета и платят за использованные IT-ресурсы) и Showback (когда показываются расчетные затраты в информационных целях, без фактических платежей). Выбор модели зависит от культуры организации и готовности руководства внедрить «внутренние рыночные отношения» между IT и бизнесом.​

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

Модель аллокации ежемесячных затрат на ИИ-решение по слоям архитектуры

Разработка комплексной системы учета и распределения затрат на искусственный интеллект и облачные вычисления является критической задачей для финансового управления корпоративными ИИ-решениями. В этой статье попробуем собрать специализированную модель аллокации затрат, которая распределяет ежемесячные расходы (для простоты выберем 1 месяц как минимальную единицу времени для аллокации затрат, в т.ч. потому что амортизация начисляется помесячно) по шести архитектурным слоям ИИ-инфраструктуры. Это обеспечивает полную видимость совокупной стоимости владения (TCO) и позволяет точно отнести затраты к соответствующим бизнес-подразделениям и проектам. Модель учитывает более 20 основных компонентов затрат, от физического электроснабжения до лицензирования программного обеспечения, и предоставляет четкие драйверы аллокации, методики расчетов и инструменты мониторинга для каждого слоя. 

Обзор архитектуры ИИ-решений и структуры затрат

Хоть мы и обсуждали это детально в прошлых статьях, давайте кратко вспомним. Современные ИИ-решения представляют собой сложную многоуровневую архитектуру, где каждый слой играет критическую роль в работе системы и привносит свои специфические затраты. Понимание этой структуры является основой для построения корректной модели аллокации. 

1. Первый слой — физический (Infrastructure) — обеспечивает фундаментальную инфраструктуру: системы электроснабжения с резервированием, передовые технологии охлаждения, специализированные корпуса и стойки, а также кабельную инфраструктуру. Исследования показывают, что энергопотребление и охлаждение составляют 40-54% от общих расходов на содержание дата-центра, что делает этот слой одним из наиболее значимых в финансовом плане.​

2. Сетевой слой (Network) обеспечивает высокоскоростную, низколатентную коммуникацию между вычислительными узлами и внешними системами. Для современных ИИ-приложений с требованиями к распределенному обучению требуется пропускная способность 10-100 Гбит/с, а стоимость пропускной способности может быстро накапливаться при работе с большими объемами данных. 

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

4. Вычислительный слой (Hardware) содержит основные процессорные ресурсы — GPU-кластеры (H100, A100, B200 и др.) с поддержкой параллельных вычислений, CPU-серверы для управления и предобработки данных, а также специализированные межсоединители (NVLink) для высокоскоростного обмена. 

5. Слой виртуализации и оркестрации (Virtualization) абстрагирует базовое оборудование, обеспечивая контейнеризацию (Docker), оркестрацию (Kubernetes) и автоматическое управление ресурсами. 

6. Наконец, верхний слой — управления и мониторинга (Software) — обеспечивает непрерывный мониторинг, управление экспериментами, оптимизацию производительности и соответствие требованиям безопасности и комплайанса.

Для дальнейших расчетов возьмем типичное среднемасштабное ИИ-решение, которое будет использовать: 10 GPU H100, ~500 ТБ хранилища, 40 Гбит/с внутрикластерной пропускной способности. Цены на все возьмем предложенные ИИ в долларах (а куда же без ИИ при написании материала). Тогда ежемесячные затраты могут распределяться следующим образом:

1. Физический слой — Infrastructure ($9 000/месяц, 5%)

Слой Infrastructure покрывает физическую инфраструктуру дата-центра. Электроснабжение и системы резервного электропитания (ИБП, ДГУ) являются основным драйвером затрат в этом слое. 

• Электроэнергия: расчет проводится по формуле: ХХХ кВт за месяц × тариф на электроэнергию;

• Резервирование питания (UPS) — ХХ систем × затраты на амортизацию/содержание в месяц;

• Стойки и кабельная инфраструктура — ХХ систем × затраты на амортизацию/содержание в месяц;

• Facilities (помещения, освещение, безопасность) — затраты на амортизацию/содержание в месяц.

Первичный драйвер аллокации для Infrastructure: Мощность (кВт) IT-оборудования. Т.е. все затраты (сумма всех трат за месяц выше) распределяются на оборудование слоя 4 (вычислительный слой) пропорционально мощности этого оборудования. Это простая формула.

Сложная формула: Можно уточнять распределение затрат на электричество и инфраструктурные элементы ЦОД также через дополнительные драйверы аллокации (как доп. коэффициенты): 

• Реальное потребление энергии каждым вычислительным юнитом (каждым сервером, СХД, сетевым устройством и тп).

• Коэффициент PUE оборудования дата-центра (Power Usage Effectiveness,  обычно составляет 1.15-1.25, означая, что на каждый киловатт IT-нагрузки требуется дополнительно 0.15-0.25 кВт на охлаждение).

• Количество стоек и плотность размещения.

• Требуемый SLA/уровень отказоустойчивости.

Пример: 

• Например расходы на электроэнергию 10 GPU составляют $3,000;

• Системы охлаждения добавляют еще $450 в месяц (PUE 1.15);

• Резервирование питания (UPS) — 2 системы × $400/мес = $800/месяц; 

• Стойки и кабельная инфраструктура — 15 стоек × $150 = $2,250/месяц;. 

• Facilities (помещения, освещение, безопасность) — $2,500/месяц;

• Итого: $9000/месяц

2. Сетевой слой — Network ($7 680/месяц, 4%)

Сетевой слой включает все компоненты, необходимые для высокоскоростной связи. Первичный драйвер аллокации для Network: объем данных, передаваемых между узлами (Гб/месяц). При отсутствии таких данных можно аллоцировать затраты на сетевую инфраструктур через количество и тип сетевых портов.

Методика расчета:  распределение стоимости затрат на сетевое оборудование (амортизация и обслуживание ежемесячно) пропорционально использованию полос пропускания.​

Пример:

• Высокоскоростные межсоединители (NVLink) между GPU — для 10 GPU требуется примерно 4 NVLink порта × $45/месяц = $180;

• Сетевые коммутаторы и маршрутизаторы — 3 высокопроизводительных коммутатора × $2,500 = $7,500/месяц;

• Итого: $7680/месяц.

3. Слой хранения данных — Storage ($88 750/месяц, 52%)

Слой Storage часто является самым дорогостоящим компонентом ИИ-инфраструктуры из-за огромных объемов данных, необходимых для обучения моделей. Это драматическое увеличение затрат на хранение отражает реальность ИИ-проектов, где объемы данных экспоненциально растут. Для сравнения: в облачных решениях стоимость хранения составляет $0.02-0.05/ГБ/месяц для холодного хранилища и $0.10-0.20/ГБ/месяц для горячего.​

Первичный драйвер аллокации для Storage: общий объем используемого хранилища (ТБ)

Более сложные формулы могут учитывать;

• Распределение между hot (быстрое) и cold (архивное) уровнями хранения;

• Коэффициент избыточности (RAID уровень);

• Требуемые SLA и RPO/RTO для бизнеса.

• Методика расчета: мониторинг через API хранилища (например, NetApp ONTAP, Pure Storage, EMC PowerMax) с ежедневным обновлением, затем агрегация по месяцу. Для каждого проекта/команды отслеживается используемый объем, умножается на средний тариф tier’а, к которому отнесены данные. Для горячих данных используется более высокий тариф, для архивных — более низкий. 

  Пример:

  • Первичное хранилище (NVMe 500 ТБ) — 500 ТБ × $120/ТБ/месяц = $60,000. 

  • Резервное копирование и избыточность (RAID) — 250 ТБ × $35/ТБ/месяц = $8,750. 

  • Управление хранилищем с разделением на hot/cold tiers — политики и инструменты для автоматического перемещения данных между быстрым NVMe и более дешевым хранилищем — 100 политик × $200 = $20,000. 

  • Итого: $88,750/месяц.​

  4. Вычислительный слой — Hardware ($56 520/месяц, 33%)

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

  Первичный драйвер аллокации для Hardware: количество GPU-часов использования (часов/месяц) + Тип GPU (H100 vs A100 vs V100 — разные цены)

  Более сложные формулы включают:

  • Резерв мощности (provisioning overhead);

  • Требуемые CPU+Memory для управления и предобработки.

  Методика расчета: в реальном времени через nvidia-smi и Kubernetes metrics (при облачном развертывании). Каждый GPU отслеживается по идентификатору, записывается время использования для каждого job/model. Ежемесячно: Σ(GPU часы по типу × цена за тип). Для CPU — отслеживание vCPU-hours через cloud billing API. 

  Далее затраты распределяются на проекты/системы пропорционально использованным часам

  Пример:

  • GPU H100 instances (10x) — это основная статья: 10 × $4,500/месяц амортизации = $45,000/мес. 

  • Поддерживающие узлы — 64 ядра CPU × $180/месяц = $11,520. 

  • Итого: $56,520/месяц.

  5. Слой виртуализации и оркестрации — Virtualization ($3216/месяц, 2%)

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

  Первичный драйвер аллокации для Virtualization: Количество Kubernetes кластеров (обычно dev/staging/prod) 

  Сложные формулы могут в себя включать:

  • Количество контейнеров и pod’ов;

  • Количество узлов в кластере;

  • Требуемые инструменты управления и добавки (Istio, Prometheus, etc.).

  Методика расчета: ежедневное считывание для определения масштаба инфраструктуры, ежемесячная агрегация. Фиксированный сбор за кластер ($72), затем переменная стоимость на pod/node. Распределение между командами пропорционально используемому CPU/Memory. 

  Пример:

  • Kubernetes control planes (3 кластера) — 3 × $72/месяц = $216. (AWS EKS управляет control plane за $0.10/час = $72/месяц). 

  • Container runtime и orchestration — автоматизация развертывания, масштабирования и управления контейнерами — 150 контейнеров × $20 = $3,000.

  •  Итого: $3,216/месяц.​

  6. Слой управления и мониторинга — Software ($6700/месяц, 4%)

  Верхний слой Software покрывает программное обеспечение, мониторинг, управление и комплаенс. Расходы на Software часто недооцениваются, но они критичны для безопасности и соответствия требованиям. Например, SOC2 compliance в год может стоить $30,000-150,000, что составляет $2,500-12,500/месяц.​

  Первичный драйвер аллокации для Software: Количество моделей в production

  Сложные формулы могут включать в себя:

  • Количество активных пользователей платформы;

  • Требуемый уровень комплайанса (SOC2, HIPAA, GDPR, etc.);

  • Требуемая частота мониторинга и retention metrics.

  Методика расчета: ежемесячный расчет на основе MLflow events API (количество зарегистрированных моделей), счетчика пользователей из LDAP/Active Directory, требуемых compliance audit часов. 

  Пример: 

  • MLOps платформа (Databricks/SageMaker) — 8 моделей × $400/месяц = $3,200. 

  • Мониторинг и observability — инструменты для отслеживания производительности моделей, metrics хранение, alerting — 5,000 datapoints × $0.25 = $1,250. 

  • Support и SLA — профессиональная поддержка для 15 пользователей × $150 = $2,250.

  • Итого: $6,700/месяц.​

  Драйверы аллокации и методология распределения затрат

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

  Для слоя 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: Отчетность и оптимизация

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

  Сценарии применения модели

  Сценарий 1: Распределение затрат между проектами

  Компания разрабатывает 3 ИИ-проекта на одной инфраструктуре: 

  • проект A использует 4 GPU (40% от мощности); 

  • проект B — 3 GPU (30%);

  • проект C — 3 GPU (30%). 

  Допустим СХД, сеть, виртуализацию и ПО все проекты используют одинаково (по трети от общих затрат). Электричество и инфраструктурные затраты распределяются пропорционально кол-ву мощности. 

  Напомню, что выше вы по каждому слою насчитали следующую картину:

  • Инфра $9 000 5%;

  • Сеть $7 680 4%;

  • СХД $88 750 52%;

  • GPU $56 520 33%;

  • Вирт. $3 216 2%;

  • Софт $6 700 4%;

  • Итого $171 866 100%.

  Тогда по нашей модели аллокации:

  	Проект А (4GPU)	Проект В(3 GPU)	Проект C(3 GPU)
  Инфра	$ 3 600	$ 2 700	$ 2 700
  Сеть	$ 2 560	$ 2 560	$ 2 560
  СХД	$ 29 583	$ 29 583	$ 29 583
  Хард	$ 22 608	$ 16 956	$ 16 956
  Вирт	$         1 072	$ 1 072	$ 1 072
  Софт	$         2 233	$ 2 233	$ 2 233
  Итого	$       61 657 / мес	$ 55 105 / мес	$ 55 105 / мес

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

  При этом текущий расчет — это аллокация ежемесячных затрат. Мы можем тут учесть (как в ТСО в прошлой статье) затраты на обслуживание, и другие ОРЕХ затраты, но аллокация не включает в себя затраты на приобретение моделей/датасетов и ПО без подписки (разовые траты), будущие затраты на утилизацию, а также мы не учли зарплаты персонала. Как видите управленческий учет сложен и многогранен, если мы хотим знать абсолютно все траты. Для этого нам понадобится учет затрат во всех разрезах + аллокация затрат + выставление счетов (если мы хотим делать chargeback) на использующие модель подразделения / команды).

  Сценарий 2: Chargeback модель для внутренних клиентов

  ИИ-команда работает как Cost Center, и расходы распределяются между деловыми подразделениями (Sales AI, HR AI, Operations AI). Каждый месяц подразделениям выставляется счет на основе их использования GPU, storage, и количества моделей в production.

  Сценарий 3: CapEx vs OpEx планирование

  На основе месячных затрат рассчитывается, окупится ли покупка собственного оборудования или стоит остаться на облачном решении по подписке. Скорее всего собственные GPU-серверы смогут окупиться через 18-24 месяцев при стабильной утилизации (постоянном высоком использовании).​

  Заключение

  Предложенная модель аллокации затрат на ИИ-решение обеспечивает полную прозрачность совокупной стоимости владения по всем шести архитектурным слоям. Путем применения адекватных драйверов аллокации для каждого слоя (GPU-часы для Hardware, Гб-месяцы для Storage, кВт-часы для Infrastructure и т.д.) организация может справедливо распределить затраты между проектами, командами и внутренними клиентами.​

  Для типичного среднемасштабного развертывания (10 GPU H100) общие месячные затраты составляют примерно $86,000-176,000, причем электричество (включая охлаждение), Hardware и Storage представляют 80%+ от общих расходов. Регулярный мониторинг через DCIM, NetFlow, Kubernetes metrics и MLOps платформы, в сочетании с ежемесячной оптимизацией, позволяет снизить расходы на 20-30%.​

  Успешная реализация требует интеграции инструментов мониторинга, системы финансового учета и процессов регулярной оптимизации. Рекомендуется начать с внедрения мониторинга для Hardware (GPU-часы) и Storage (ТБ), затем постепенно расширять охват на остальные слои.