Введение
За последние пару лет центры обработки данных вошли в гонку ИИ-нагрузок: модели растут, наборы данных пухнут, а окна обслуживания сжимаются. В этой новой реальности уже недостаточно просто «добавить оперативки» или «поставить SSD побольше». Ключ меняется: теперь эффективность измеряют не только в гигабайтах и гигагерцах, но в том, сколько операций и терабайтов вы получаете на каждый потраченный доллар и ватт. Иными словами, метрики IOPS/W/$ и TB/$ становятся новой валютой эффективности.
Хорошая новость в том, что сами технологии памяти и хранения перестраиваются под эту парадигму. Появляются MRDIMM для повышения пропускной способности модулей, CXL-память для пула и шаринга между серверами, более энергоэффективные SSD корпоративного класса и аппаратное шифрование, уменьшающее накладные расходы и риски. Вендоры прямо заявляют: цель — улучшить TCO (total cost of ownership) за счет плотности, эффективности и лучшей утилизации ресурсов.
В этой статье разберём одну главную идею: как переосмысление архитектуры памяти и хранения под ИИ-нагрузки помогает радикально снизить TCO дата-центра. Разберём, как считать эффективность «на пальцах», зачем нужны MRDIMM и CXL, почему SSD-накопители и аппаратное шифрование — это не просто про скорость и безопасность, а про экономику, и какую «слойку» памяти и хранилища имеет смысл собирать прямо сейчас.
IOPS/W/$ и TB/$: новая «валюта» эффективности для ИИ
Традиционные метрики — частота CPU, «сколько ОЗУ в сервере», «сколько терабайтов в массиве» — больше не отражают сути. При ИИ-нагрузках узким местом чаще становится пропускная способность и латентность доступа к данным и параметрам модели. Как отмечают лидеры рынка, стоимость владения сегодня измеряется сочетанием IOPS/W/$ и TB/$:
- IOPS/W/$ — сколько операций ввода-вывода вы получаете на каждый ватт и доллар. Это сразу связывает производительность со счетом за электричество и CapEx.
- TB/$ — сколько терабайтов реальной полезной ёмкости вы получаете на доллар. Это про экономику плотности и рациональное хранение больших датасетов.
Звучит абстрактно, но посчитаем на примере. Допустим, у вас два варианта массива для фичестора под ИИ:
- Вариант А: 24 SSD с более высоким энергопотреблением и меньшей плотностью.
- Вариант Б: 24 SSD корпоративного класса с более высокой плотностью и пониженным энергопотреблением.
Если каждый «более холодный» SSD экономит хотя бы 5 Вт под нагрузкой, то стойка экономит около 120 Вт (24 × 5 Вт). Добавьте сюда кондиционирование (PUE) — грубо, ещё плюс 20–50% к энергетической экономии. На горизонте трёх лет даже такая «мелочь» превращается в ощутимые тысячи долларов Opex, не говоря о том, что современные высокоплотные диски дают больше TB/$ (меньше слотов, та же ёмкость или больше). Речь не про рекорды в бенчмарках — речь про счёт на электроэнергию и свободные юниты в стойке.
Та же логика и в памяти. Если процессор упирается в память, вы не добираете IOPS/W/$ на уровне всего узла: CPU «ждёт», тратит ватт-часы, а полезная работа не растёт. Поэтому в эпоху ИИ инженеры смотрят не «сколько ГБ поставить», а «как поднять эффективную пропускную способность и утилизацию памяти на доллар и ватт».
Коротко: TCO сегодня — это не просто «цена за терабайт» или «цена за гигабайт ОЗУ». Это баланс ёмкости, пропускной способности и энергопотребления под конкретные ИИ-профили. Как любят говорить архитекторы, «бизнес считает ватт и байт, а не наклейки на коробке».
Память для ИИ: MRDIMM и CXL как «турбонаддув» TCO
MRDIMM: раскрыть потенциал процессоров и плотность на стойку
Multiplexed Rank DIMM (MRDIMM) — это модуль оперативной памяти, задуманный для повышения общей эффективности сервера. Его задача — оптимизировать TCO дата-центра, в частности позволяя ставить процессоры с большим числом ядер в каждый сервер и эффективнее их «кормить» данными. По сути, MRDIMM помогает улучшить связку «CPU ↔ память», уменьшая вероятность того, что высокоплотные процессоры будут простаивать в ожидании данных.
Если представить сервер как бригаду строителей, то CPU — это рабочие, а память — поставка кирпичей. MRDIMM — это более широкая линия снабжения, под которую вы можете нанять больше рабочих в ту же бригаду. Без неё лишние руки просто стоят и ждут материалы. Отсюда и влияние на TCO: за те же юниты в стойке вы получаете больше полезных вычислений на ватт и доллар, а значит — выше IOPS/W/$ на узел и на стойку.
Практический вывод: если вы планируете переход на CPU/GPU с высокой ядерностью или большим количеством ускорителей на узел, проверьте совместимость платформы с MRDIMM. Это один из прямых путей повысить плотность вычислений на стойку без пропорционального роста потребления и стоимости инфраструктуры.
CXL: пул и шаринг памяти для снижения CapEx и повышения утилизации
Следующая большая вещь — CXL-память и модули расширения памяти. Суть проста: вместо того чтобы держать «островки» недогруженной ОЗУ в каждом сервере, вы можете пулить и делить большие объёмы памяти между серверами и задачами. Это повышает утилизацию и снижает CapEx и OpEx. Производители памяти прямо указывают на TCO-выгоды пула/шаринга больших объёмов, а также на то, что зрелость экосистемы растёт — появляются продукты линейки CXL и сертификации с поставщиками уровня Red Hat, что критично для корпоративного развёртывания.
На пальцах: в традиционной схеме у вас 8 серверов с по 1 ТБ ОЗУ. Загрузка нерівномерна: часть задач «съедает» почти весь терабайт, часть — только половину. В сумме простаивает, скажем, 3–4 ТБ, которые вы уже оплатили и питаете. С пулом CXL эти «лишние» гигабайты становятся общим ресурсом: ИИ-тренировка на сервере А может взять память, физически стоящую на модуле расширения или в соседнем узле. В итоге вы платите за реально используемые терабайты, а не за «воздух».
Влияние на IOPS/W/$ тоже позитивное: при лучшей утилизации узлов вы реже держите «горячее железо» в полубезделье. А это напрямую про ватт на полезную операцию и доллар на производительность. Отдельный бонус — уменьшение числа закупаемых серверов под пиковые хвосты, что сокращает CapEx и нагрузку на стойки и энергетику.
Гипотетический кейс (иллюстрация подхода): интегратор развернул пилот CXL-пула для пула ИИ-сервисов из 12 серверов. До пилота у каждого было по 1 ТБ, средняя загрузка — около 60%. После ввода пула часть локальной памяти заменили на общее CXL-расширение. В результате «эффективная» загрузка памяти выросла до ~80% без деградации SLA: дорогая память перестала простаивать. Это не магия — просто шаринг там, где раньше были «островки». Финансовый эффект: меньше модулей DIMM на узел, меньше серверов «про запас», ниже счёт за энергетику и кондиционирование. Числа будут индивидуальными, но арифметика понятна.
Важно, что экосистема вокруг CXL-памяти стремительно взрослеет: появляются конкретные продукты и совместимости с корпоративными платформами. Для ИТ-директора это сигнал «зелёный» — технология не только перспективная, но и подкреплена интеграцией с ОС и корпоративными стеками.
Инженерный реализм: электроника, тепло и поддержка
Когда речь о больших объёмах и новых модулях, избежать вопросов электрических режимов и тепла невозможно. Здесь играет роль инженерная программа поддержки от вендоров: ранний доступ к документации, электрическим и тепловым рекомендациям, референсным дизайнам. Такие программы упрощают жизнь интеграторам и ускоряют «боевое» внедрение: меньше сюрпризов в стойке, выше надёжность и предсказуемость TCO.
SSD — тихий двигатель TCO: плотность, энергоэффективность и шифрование
Высокоплотные и «холодные» SSD под ИИ-данные
В ИИ-сценариях SSD часто работают как «подающие» диски: отдают выборки, чекпоинты, артефакты обучения/инференса. Здесь выстреливают накопители корпоративного класса с высокой плотностью и низким энергопотреблением. Производители прямо заявляют: такие решения повышают эффективность и улучшают TCO за счёт плотности на слот и меньшей «аппетитности» по ваттам.
Почему это важно? Представьте поезда на сортировочной станции: если составы (выборки) подаются без задержек, локомотивы (GPU/CPU) не стоят в простое. Это снижает стоимость минуты ускорителя и повышает реальную производительность кВт⋅ч. Плюс, высокая плотность SSD позволяет держать терабайты ближе к вычислениям, не раздувая количество полок и портов — это и про TB/$, и про IOPS/W/$.
Гипотетический расчёт: если на узел вы добавляете 2 SSD высокой плотности вместо 4 менее плотных, а суммарная ёмкость и IOPS под вашу нагрузку сохраняются, вы экономите 2 слота, кабели, порты, часть ватт и снижаете риски отказов (меньше компонентов — меньше точек сбоя). На масштабе стойки и выше такие «мелочи» копятся в заметную разницу TCO.
Аппаратное шифрование: безопасность без «налога на CPU»
Отдельно стоит сказать про аппаратное шифрование SSD. Оно обычно менее затратно во внедрении и сопровождении, чем программное, и соответствует отраслевым и государственным требованиям по безопасности данных. Главное — это снижает нагрузку на CPU/GPU: шифрование «живёт» на контроллере диска, а не в ваших ядрах. Итог: вы не теряете IOPS и не тратите ватты на то, что может сделать сам накопитель.
Для дата-центра это означает двойную выгоду: меньше накладных расходов на вычисление и проще соответствие требованиям комплаенса. В ИИ-проектах, где артефакты и датасеты могут быть чувствительны, аппаратное шифрование — способ «встроить безопасность в железо», не ломая экономику. Это напрямую отражается на TCO: меньше софта и ресурсов — меньше CapEx и OpEx, выше предсказуемость.
3D NAND: скорость, ёмкость и зрелость технологии
Переход к 3D NAND стал важной вехой: SSD получили и скорость, и ёмкость, и приемлемую «тепловую модель» для дата-центров. Для вас это означает более высокий TB/$ без экзотики и компромиссов. Современные корпоративные линейки как раз строятся вокруг высокоплотной 3D NAND, что позволяет собирать хранилища под ИИ без раздувания количества устройств и блоков питания.
Правильная «слойка»: как сочетать DRAM, CXL и SSD под ИИ-нагрузки
Почему важна многоуровневая архитектура
ИИ-стек — это не монолит. Есть оперативные данные и параметры модели, есть кэш фичей, есть артефакты и снэпшоты, есть архивы. Единый уровень «на все случаи» всегда либо дорог, либо медленен. Поэтому индустрия предлагает многоуровневую архитектуру: быстрые DRAM-модули (включая MRDIMM) там, где нужна минимальная латентность; CXL-память там, где важна объёмность и шаринг; и SSD-слои разной плотности и выносливости для фичесторов, снэпшотов и архивов. Такой подход прямо упоминается в инженерных материалах: под конкретную роль — свой класс памяти/накопителя. Результат — лучшая производительность и лучший TCO.
Роль DRAM и MRDIMM
DRAM остаётся «золотым» уровнем с минимальной задержкой. MRDIMM здесь про то, чтобы дать процессорам больше «кислорода» на тех же юнитах и в тех же энергетических рамках. В задачах инференса на CPU или классическом in-memory кэше (фичи, результаты препроцессинга) MRDIMM помогает держать линейность производительности при росте ядров и плотности узла. Это меньше узлов на стойку для того же SLA — экономия на слотах, питании, лицензиях.
Роль CXL-памяти
CXL-память полезна там, где набегает «длинный хвост» потребностей и перераспределение объёмов даёт наибольший дивиденд. Например, в периодах активной тренировки вы временно добавляете десятки-сотни гигабайт узлам, которым «узко»; в часы затишья — перераспределяете в сторону аналитики и препроцессинга. Это ровно про «больше TB/$ из той же стойки» и «больше IOPS/W/$ из существующего пула».
Роль SSD-слоёв
Для фичестора, чекпоинтов, датасетов — SSD корпоративного класса с высокой плотностью и низким энергопотреблением. Для более горячих путей (журналирование, метаданные) — модели, оптимизированные под высокие IOPS и низкую задержку. И, конечно, везде, где это оправдано, — аппаратное шифрование, чтобы безопасность не «ела» CPU и не ломала экономику.
Гипотетический сценарий развёртывания
Вообразим кластер для инференса LLM в реальном времени:
- Узел инференса: CPU с высокой ядерностью, MRDIMM для масштабирования пропускной способности памяти; быстрый локальный SSD для модели и токенов.
- Пул CXL: общий объём для задач со «всплесками» памяти: пики нагрузки, дополнительные буферы, шаринг между несколькими сервисами.
- Фичестор: массив SSD высокой плотности с аппаратным шифрованием; политика энергосбережения, оптимальная развёртка по стойкам для экономии на охлаждении.
Такой дизайн позволяет удерживать SLA при умеренном количестве узлов, а значит — меньше лицензий, меньше железа «про запас», меньше ватт в стойках. Ваш TCO улыбается.
Что это меняет в процессе закупки и эксплуатации
Считать не «сверху вниз», а «снизу вверх»
Прежний подход «давайте накинем ещё 20% ёмкости» плохо работает при ИИ-нагрузках. Гораздо лучше — моделировать профили доступа (IOPS, последовательные/случайные паттерны, латентность) и тепловой бюджет (ватты на узел/стойку) и уже под них выбирать память и SSD. Критерии — IOPS/W/$ и TB/$. Пусть этот расчёт станет формальным: иначе легко переплатить за «лишний» уровень быстроты или «съесть» весь электрический бюджет стойки.
Внедрять MRDIMM и CXL пошагово
Рекомендуемый путь — пилоты. Начните с 1–2 стоек, валидируйте ваши профили нагрузки, посмотрите, как меняется утилизация CPU, память, IOPS. На уровне процесса важно подключить вендорские программы технической поддержки: ранняя инженерная экспертиза по электрическим и тепловым вопросам часто экономит месяцы и десятки тысяч долларов на доработках и простойных рисках.
Безопасность как часть железа
Аппаратное шифрование SSD — самый безболезненный способ встроить безопасность в инфраструктуру, не «наложив» новый слой нагрузки на CPU и не раздув парк софта для комплаенса. Это упрощает соответствие отраслевым и правительственным нормам и чаще всего обходится дешевле в эксплуатации, чем программные альтернативы.
Документировать «уровни» и SLO
Пропишите «уровневую карту» кластера: какой слой — для чего, какие SLO по латентности и пропускной способности, какой бюджет ватт на узел/стойку, как распределяется память (включая CXL), какие правила миграции данных между уровнями. Это уменьшает риск «стихийных» апгрейдов, когда каждый новый сервис требует новый класс железа. Чем больше предсказуемости — тем меньше хаотичных CapEx и выше стабильность TCO.
Заключение: практические шаги к низкому TCO в эпоху ИИ
ИИ не отменяет законов физики и бухгалтерии. Он лишь обнажает, где именно вы теряете деньги: в простоях CPU из-за «узкой» памяти, в недоиспользуемых терабайтах, в энергозатратных SSD, в программном шифровании, пожирающем ядра. Ответ — не «больше железа», а более умное железо и правильная архитектура.
- Сделайте TCO-метрики первыми гражданами: заведите расчёт IOPS/W/$ и TB/$ для ключевых ИИ-сервисов. Откажитесь от закупок «на глаз».
- Рассмотрите MRDIMM для узлов с высокой ядерностью и чувствительных к латентности рабочих нагрузок. Это путь к большим вычислениям на стойку без удушья по памяти.
- Спланируйте пилот CXL-памяти: пул и шаринг памяти снижают CapEx и повышают утилизацию. Экосистема зрелая: есть продукты и сертификации с корпоративными стеками.
- Выберите SSD корпоративного класса с высокой плотностью и низкой «прожорливостью» по ваттам — это двойной выигрыш в TB/$ и IOPS/W/$.
- Включите аппаратное шифрование как стандарт: безопасность без «налога на CPU» и лишнего софта.
- Стройте многоуровневую архитектуру: DRAM/MRDIMM для самого горячего слоя, CXL — для объёмов и гибкости, SSD — для данных ИИ с учётом профилей доступа.
- Используйте инженерные программы вендоров: ранний доступ к техинформации, электрическим и тепловым профилям сокращает риски и ускоряет ввод в эксплуатацию.
В финале вспомним простую мысль: ИИ — это марафон, а не спринт. Выигрывает не тот, кто поставит самую дорогую стойку, а тот, кто на каждый ватт и доллар выжмет максимум полезной работы. Переосмысление памяти и хранилища под ИИ — это не «ещё одна модернизация», а сдвиг мышления. И он уже здесь.