Пять шагов, чтобы превратить память из самого большого ограничения ИИ в конкурентное преимущество

В течение последних нескольких лет инфраструктура ИИ фокусировалась на вычислительной мощности выше всех других метрик. Больше ускорителей, более крупные кластеры и более высокие FLOPS двигали разговор о том, чтобы сделать максимум из GPU. Этот подход имел смысл, когда прогресс модели зависел в основном от масштаба обучения. Теперь, когда приоритетом являются производственные развертывания ИИ, есть новое ограничение, на которое следует обратить внимание: память.

Сегодня многие из самых сложных ограничений для ИИ проявляются в емкости памяти, пропускной способности, задержке и времени и энергетической стоимости перемещения данных через систему. Окна контекста продолжают расширяться, и компании, такие как Anthropic, теперь предлагают окна с миллионом токенов в своей стандартной ценовой категории. Нагрузки вывода увеличиваются. Рост многоагентных систем означает, что системы ИИ передают более крупные объемы данных из одной стадии в другую. Операторы могут продолжать пытаться добавлять больше GPU, но они все равно не могут достичь желаемой производительности, потому что эти системы испытывают нехватку RAM, чтобы эффективно питать ускорители, когда каждый сервер работает самостоятельно, ограниченный памятью внутри системы.

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

Вот пять шагов, которые лидеры инфраструктуры могут предпринять сейчас, чтобы подготовиться к постоянно растущим требованиям к памяти.

1. Начните с измерения реального ограничения

Многие организации все еще оценивают производительность ИИ через линзу вычислений. Они отслеживают использование кластеров, количество ускорителей и общую пропускную способность, а затем предполагают, что улучшения будут достигнуты за счет добавления больше ускорителей GPU. Этот взгляд часто упускает из виду реальную проблему.

Давление на память часто проявляется в виде остановки ускорителей, более высокой задержки на токен и неравномерной пропускной способности под нагрузкой. Ускоритель GPU может выглядеть неиспользуемым, если он ждет прибытия данных из другого уровня памяти, другого сервера или другой стадии приложения. Вывод делает эту проблему более заметной, поскольку размер кэша KV увеличивается и больше одновременных сессий конкурируют за пропускную способность.

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

2. Сократите перемещение данных перед добавлением емкости

В крупных системах ИИ перемещение данных может создать столько же накладных расходов, сколько и обработка данных.

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

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

Прежде чем инвестировать в больше ускорителей, командам следует определить, где в системе данные перемещаются более чем необходимо. Переносы GPU-to-GPU, копирование сервер-to-сервер и повторное перемещение промежуточных состояний через агентские конвейеры – хорошие места для начала. Во многих средах сокращение ненужного перемещения обеспечивает больше полезной производительности, чем добавление еще одного сервера.

3. Постройте уровни памяти вокруг поведения рабочей нагрузки

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

Самые горячие данные должны оставаться ближе всего к ускорителю. Это включает в себя рабочие наборы, которые требуют самой низкой задержки и самой высокой пропускной способности. Другие активные буферы и часто используемые состояния могут находиться в ОЗУ. Более крупные структуры, которым требуется масштабирование больше, чем абсолютная скорость, могут быть перемещены в пулед памяти. Холодные данные и менее активные модели принадлежат дальше вниз по стеку.

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

Стратегия иерархической памяти дает операторам больше контроля над производительностью и экономикой. В производственном ИИ этот баланс становится основным требованием к проектированию.

4. Рассматривайте общую память как часть архитектуры для агентского ИИ

Многоагентный ИИ увеличивает стоимость фрагментированного дизайна памяти.

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

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

Для гиперскалеров это уже не является краевым случаем. По мере созревания агентского ИИ общая память становится практическим требованием для эффективного развертывания.

5. Примите CXL для производственной инфраструктуры

В течение последних нескольких лет отрасль рассматривала CXL как перспективный стандарт, который нуждается в большем времени для созревания, поскольку CXL быстро перешел от версии 1 к 2. Теперь, когда аппаратура версии 3.x скоро станет доступна, CXL достигает точки, когда он становится функционально полным, обратно совместимым и готовым к работе с производственными нагрузками.

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

Это не означает, что каждая рабочая нагрузка должна перейти на память на основе CXL. Местная память останется необходимой для самых горячих и наиболее чувствительных к задержке данных. Но операторы больше не должны ждать какой-то будущей версии стандарта, прежде чем действовать. Более полезный вопрос заключается в том, где CXL может решить реальные производственные проблемы сегодня.

Самые очевидные возможности заключаются в расширении памяти, пуле памяти и дизайнах общей памяти, которые сокращают ненужные копии через рабочие нагрузки ИИ. Эти случаи использования напрямую соответствуют текущим точкам давления: растущим требованиям к кэшу KV, растущему агент-агентскому переносу данных и необходимости улучшить использование GPU без увеличения общей стоимости владения.

Операторам все равно необходимо тщательно проектировать. Задержка, предсказуемость и поддержка программного обеспечения все еще имеют значение. Политики управления памятью должны размещать данные в правильном уровне в правильное время. Но это вопросы реализации, а не причины откладывать планирование.

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

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