ИИ стремительно повышает цены на память
Десятилетиями память со временем дешевела. В конце 2025 года эта тенденция изменилась на противоположную, и виной тому ИИ. Производители памяти переориентировали свои заводы на память с высокой пропускной способностью, которая необходима для ИИ-ускорителей, оставив меньше мощностей для обычной серверной DRAM, от которой зависят все остальные, в то время как крупнейшие облачные провайдеры забронировали оставшееся по долгосрочным контрактам.
Результатом стал самый быстрый скачок цен на память за всю историю наблюдений. Цены на серверную память примерно удвоились в начале 2026 года и продолжили расти, а новые заводы не принесут облегчения как минимум до 2027 года.
Если вы используете базу данных in-memory, это бьет по вам напрямую. Оперативная память, которой вы уже владеете, не дорожает, но добавление емкости, ее дублирование для надежности или резервирование под рост в следующем году теперь обходятся дороже. И большая часть этой памяти хранит данные, к которым обращаются редко. Почти в каждом приложении небольшая часть данных обрабатывает большую часть трафика. Когда все находится в памяти, вы платите высшую цену за то, чтобы неактивное большинство соседствовало с активным меньшинством.
Хранить меньше — не выход
Чтобы вписаться в бюджет RAM, команды сокращают историю, уменьшают кэш или переносят данные в другие системы. У каждого решения есть своя цена. Более короткое хранение делает полезную историю недоступной. Меньший кэш отправляет больше трафика в основную базу данных, что работает медленнее и обходится дороже в расчете на один запрос. Распределение данных по системам добавляет операции поиска и усложняет обслуживание.
Системы мошенничества и рекомендаций ощущают это сильнее всего. Они принимают сотни тысяч решений в секунду, уделяя каждому по несколько миллисекунд, и каждое решение ровно настолько толково, насколько хороши признаки (features), которые вы можете себе позволить обработать. Что нужно командам, так это способ хранить больше данных на скоростях реального времени, не оплачивая цены RAM для всех этих данных.
Не все многоуровневые системы созданы равными
Естественное решение — объединить RAM с SSD: «горячие» данные в памяти, а остальные — на SSD за малую долю стоимости гигабайта. Но то, как система это реализует, определяет, сколько вы в итоге сэкономите.
Некоторые системы, включая раннюю функцию автоматического многоуровневого хранения в Redis, перемещают значения на SSD, но оставляют каждый ключ в RAM. Это исчерпывает память еще до того, как вы сохранили какие-либо горячие данные, и ситуация ухудшается по мере роста количества записей. Другие начинают использовать SSD только тогда, когда память заполнена, поэтому небольшой тест выглядит невероятно быстрым, а замедления вы обнаруживаете уже в продакшене.
Система, которая перемещает на SSD как ключи, так и значения, оставляет RAM для данных, к которым ваше приложение обращается постоянно. Когда поступает запрос, сначала проверяется RAM. Если данные находятся на SSD, они подгружаются в RAM, обслуживаются и остаются там, пока к ним есть активный интерес. Ваше приложение видит одну базу данных и один API, а более старые данные доступны тогда, когда они вам нужны.
Правильное соотношение зависит от рабочей нагрузки. Огромный набор данных с небольшой горячей частью может работать при небольшой доле RAM; набор, в котором задействована большая часть данных, требует большего. Если каждый запрос должен возвращаться быстрее чем за миллисекунду, вариант «только RAM» по-прежнему остается правильным выбором. Суть в том, что емкость становится рычагом управления, а не счетом, который приходится оплачивать.
Примените это на практике
Настройте соотношение RAM и SSD так, чтобы вы могли работать с терабайтными наборами данных, не удерживая все в памяти.
Освободите место для более богатых функций и более длинной истории
Имея «горячие» данные в RAM, а остальные на SSD, вы перестаете сокращать историю, уменьшать кэши или разделять данные по системам. Вы просто сохраняете их.
Системы мошенничества и рекомендаций, которые ощущают давление сильнее всего, получают наибольшую отдачу: более длинную историю клиентов, больше сигналов на одно решение и отсутствие потерянных миллисекунд на их извлечение. Кэш может обслуживать больше запросов без обращения к первичной базе данных. А ИИ-агент может опираться на предыдущие взаимодействия и активность аккаунта, не собирая этот контекст по кусочкам из разрозненных систем.
Примените это на практике с Redis Flex
Redis Flex объединяет RAM и SSD, позволяя запускать терабайтные наборы данных без необходимости держать все в оперативной памяти. Она хранит горячие данные в RAM, а менее часто используемые ключи и значения переносит на SSD. Вы выбираете соотношение RAM от 10% до 50% для каждой рабочей нагрузки и изменяете его по мере изменения ваших потребностей или цен на память. В конфигурации с упором на SSD Flex стоит до 80% дешевле за гигабайт по сравнению с чистой RAM, предлагая тот же Redis, которым вы уже пользуетесь, без каких-либо изменений в коде. Теперь Flex также поддерживает Redis Search, позволяя хранить большие индексы на SSD (в режиме превью в Redis Cloud Pro).
Если вы развиваете хранилище признаков (feature store), расширяете кэш или даете вашим ИИ-агентам больше возможностей для запоминания, Flex позволяет сохранять больше полезных данных, покупая при этом меньше самого дорогого ресурса в дата-центре.
Поговорите с архитектором решений о том, как использовать Redis Flex для достижения ваших целей в области роста данных, производительности и стоимости.
