AI И НЕЙРОСЕТИ

ИИ уперся не в GPU, а в память: почему растет новый слой хранения

Десятки и сотни вызовов модели в агентных системах превратили контекстный уровень в новый узкий участок AI-инфраструктуры.

✍️ Редакция iTech News | 23.06.2026 | ⏱ 4 мин | Источник: VentureBeat
🧠

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

Именно об этом пишет VentureBeat со ссылкой на представителей Solidigm. По их оценке, главный вопрос 2026 года в AI-инфраструктуре звучит уже не как «где взять больше ускорителей», а как «где и как хранить контекст». Джефф Харторн, который отвечает за applied research по ИИ в Solidigm, говорит прямо: вычисления дешевеют, inference-движки становятся эффективнее, а вот объем контекста растет быстрее и самих моделей, и экономии на FLOP.

Логика здесь неприятно практичная. Пока генеративные системы работали в режиме «вопрос — ответ», инфраструктура еще могла жить по старым правилам: HBM на GPU, быстрый NVMe внутри сервера и сетевое хранилище где-то дальше по стойке или дата-центру. Но агентные системы ломают эту схему. Во-первых, растут окна контекста, и каждый отдельный запрос начинает весить куда больше, чем раньше. Во-вторых, цепочки действий порождают состояние после каждого шага, и его нужно сохранять между вызовами модели. В-третьих, корпоративные заказчики хотят, чтобы это состояние жило между сессиями — ради аудита, управления, повторного использования и банальной воспроизводимости. В сумме получается, что inference становится не просто вычислительной, а stateful-задачей с очень жесткими требованиями к задержкам.

Отсюда и идея отдельного слоя между памятью ускорителя и обычным сетевым storage. Этот контекстный уровень должен хранить и быстро отдавать KV-cache и retrieval-данные, не загоняя все подряд в дорогую DRAM и не сваливая активное состояние в системы, которые проектировались под совсем другой профиль нагрузки. Nvidia уже описывает такую архитектуру через термин CMX, а производители накопителей, включая Solidigm, подстраивают SSD под новый сценарий. Для инфраструктурных команд это важный сдвиг: storage перестает быть скучной строкой в смете, где побеждает минимальная цена за гигабайт. Если накопители не успевают за inference-нагрузкой, проседает не только производительность, но и экономика сервиса.

Самый показательный симптом проблемы — повторный prefill. Прежде чем модель начнет выдавать токены, она должна обработать релевантный контекст текущей сессии. Если нужное состояние KV-cache не лежит в быстром и предсказуемом слое, система пересчитывает его заново. Формально GPU занят делом, фактически он тратит дорогие циклы на воспроизведение уже вычисленного состояния. Харторн называет это важным разворотом в мышлении: загрузка ускорителей оказывается отчасти проблемой хранения данных. Поэтому на первый план выходит не грубая метрика «токены на доллар», а более полезная для бизнеса логика goodput — сколько действительно полезных токенов система выдает за те же деньги, без лишней рекомпутации и простоев.

Для разработчиков и архитекторов здесь есть еще один неприятный нюанс: inference по своему I/O-профилю совсем не похож на training. Обучение в основном последовательно читает и пишет крупные блоки данных; под это исторически и строили storage-иерархию. Inference работает иначе: запросы мелкие, чувствительные к хвостовым задержкам и привязанные к состоянию. Поэтому SSD в таком контуре должны быть не просто «быстрыми в среднем». Гораздо важнее предсказуемость tail latency — худшего сценария, который ломает оркестрацию и оставляет GPU ждать ответа от хранилища. Если система планирует ресурсы, исходя из ожидаемого времени отклика storage, внезапные многосекундные провалы уже не выглядят как мелкая инженерная неприятность. Это прямой удар по SLA и по стоимости inference.

Есть и второй слой экономики, особенно заметный в крупных кластерах: ограничением становится не столько цена железа, сколько питание и тепловой бюджет. Поэтому производители начинают говорить не только о производительности, но и о плотности хранения в пересчете на ватты на петабайт. Solidigm, разумеется, продвигает здесь собственную экспертизу во flash и floating gate NAND, но даже если убрать vendor pitch, сама постановка вопроса никуда не денется. Чем дольше корпоративные AI-системы живут в режиме постоянной памяти, тем сложнее держать все полезное состояние в DRAM. А значит, контекстный уровень из красивой схемы на слайде довольно быстро становится обязательным элементом сборки.

Для русскоязычных команд, которые строят корпоративных ассистентов, copilot-интерфейсы и агентные процессы поверх LLM, вывод довольно простой. Планировать только GPU, сеть и объектное хранилище уже недостаточно. Нужно заранее считать, где будет жить KV-cache, как быстро он возвращается в inference-контур, сколько стоит повторный prefill, как измеряется полезная отдача кластера и что происходит с задержками в пиковых сценариях. Иначе можно получить дорогой AI-кластер, который выглядит внушительно на архитектурной диаграмме, но слишком часто заставляет ускорители заниматься не новой работой, а цифровой формой амнезии.

На ближайшие пару лет интрига смещается с гонки за еще большим числом GPU к более прозаичному вопросу: сможет ли индустрия выжать больше из уже купленных ускорителей за счет правильной работы с состоянием. Если да, контекстный уровень станет для inference тем же, чем объектное хранилище когда-то стало для облаков: не опцией для энтузиастов, а базовым слоем, без которого экономика перестает сходиться.

Поделиться: Telegram X LinkedIn