MIT Technology Review 4 вересня 2026 року опублікувало огляд «Architecting memory and storage in the AI era», де йдеться про те, як навантаження великих мовних моделей ламають звичну ієрархію памʼяті дата-центрів. Матеріал зʼявився саме тоді, коли компанії масово впроваджують RAG-системи (retrieval-augmented generation) і моделі з контекстним вікном у сотні тисяч і навіть мільйони токенів — а це два сценарії, що найбільше навантажують памʼять і сховище.

Для команд, що будують AI-продукти, це не абстрактна тема датацентрового заліза. Кожна затримка при читанні ембеддингів з диска чи промах кешу конвертується в секунди очікування відповіді для користувача, а на масштабі мільйонів запитів на день різниця між локальним NVMe-накопичувачем і мережевим сховищем визначає собівартість одного інференсу. Такі рішення також безпосередньо впливають на юніт-економіку продукту: помилка в дизайні кешу здатна помножити витрати на інференс у кілька разів.

Ринок вже реагує: хмарні провайдери додають окремі тарифні рівні сховища для векторних баз даних, а виробники памʼяті нарощують випуск high-bandwidth memory (HBM) саме під навантаження інференсу. За даними MIT Tech Review, саме памʼять і сховище — а не сирі обчислення GPU — стають наступним вузьким місцем AI-інфраструктури.

Чому стара ієрархія памʼяті не витримує RAG і довгий контекст?

Класична ієрархія «оперативна памʼять → SSD → мережеве сховище» проєктувалася під транзакційні навантаження баз даних, де читання дрібне і випадкове. AI-інференс ламає цю модель двома способами. По-перше, RAG-системи на кожен запит користувача піднімають із векторної бази десятки чи сотні документів-кандидатів, і кожен промах кешу означає похід у повільніше сховище. По-друге, моделі з довгим контекстом тримають у памʼяті KV-cache — проміжний стан уваги для кожного токена вхідного запиту, — і цей кеш зростає лінійно з довжиною контексту.

KV-cache (key-value cache) — це структура даних, яку трансформерна модель зберігає під час генерації, щоб не перераховувати увагу для вже оброблених токенів заново. Для контексту в мільйон токенів такий кеш може важити десятки гігабайтів на один запит, і якщо він не вміщується в HBM GPU, система змушена вивантажувати його в повільнішу памʼять — що й зʼїдає затримку відповіді.

Що це означає для тих, хто проєктує AI-інфраструктуру?

Практичний наслідок — межа між «памʼяттю» і «сховищем» розмивається. Раніше памʼять означала швидкий, дорогий і летючий ресурс GPU чи CPU, а сховище — повільний, дешевий і постійний диск. AI-навантаження вимагають проміжного шару: швидкого, але ємного і не обовʼязково летючого, куди можна вивантажувати KV-cache і векторні індекси без катастрофічного падіння швидкості. Це також змінює критерії найму: команди дедалі частіше шукають інженерів зі сторедж-бекграундом, а не тільки ML-фахівців.

• Векторні бази даних потребують не лише швидкого пошуку, а й передбачуваної затримки під навантаженням — черга з десяти паралельних запитів не повинна ламати p99-latency.
• Довгий контекст вимагає ярусного кешування KV-cache: гаряча частина зберігається в HBM, тепла — в оперативній памʼяті хоста, а холодна — на NVMe-накопичувачі.
• Вартість зберігання ембеддингів зростає разом з розміром індексу, тому компанії дедалі частіше стискають вектори (quantization) замість того, щоб просто докуповувати сховище.

Висновок AiiN: до чого готуватися AI-білдерам

Наша теза проста: команди, що досі проєктують AI-продукт як «модель плюс база даних», найближчим часом отримають рахунок за інфраструктуру памʼяті, який переважить рахунок за GPU-обчислення. Якщо сьогодні оптимізація інференсу зводиться до вибору моделі й батчингу запитів, то за рік-два ключовим важелем економії стане архітектура кешування і ярусного зберігання — раніше суто DevOps-деталь, а тепер продуктове рішення. Ймовірно, це також підштовхне менші команди орендувати керовані векторні сховища замість власних, бо ціна помилки в архітектурі памʼяті висока, а компетенція для її проєктування — рідкісна. Для команд, які будують RAG-продукти вже сьогодні, це означає одне: тестувати архітектуру памʼяті під реалістичним навантаженням варто ще на етапі MVP, а не після першого рахунку від хмарного провайдера.

Що таке RAG і чому він так навантажує сховище?

RAG (retrieval-augmented generation) — це підхід, коли модель перед відповіддю шукає релевантні документи в зовнішній базі й додає їх у запит. Кожен такий пошук — це операція читання з векторної бази даних, і при мільйонах запитів на день навантаження на сховище зростає пропорційно кількості звернень, а не лише розміру моделі.

Чи достатньо просто докупити SSD, щоб вирішити проблему?

Ні: проблема не в обʼємі, а в структурі доступу до даних. Найшвидша памʼять GPU — HBM — обмежена і дорога, тому головне завдання архітектора — правильно розподілити дані між ярусами (HBM, DRAM, NVMe) відповідно до частоти звернень, а не просто нарощувати дешеве сховище знизу піраміди.