# Чому сховище даних стає головним вузьким місцем AI-інфраструктури

> MIT Technology Review 4 вересня 2026 року пояснює, чому RAG і довгий контекст ламають звичну ієрархію памʼяті та сховища в дата-центрах.

- Опубліковано: 6 вересня 2026 р. (2026-09-06T17:14:54.785976+00:00)
- Розділ: Практика
- На основі публікації: [MIT Tech Review](https://www.technologyreview.com/2026/09/04/1140872/architecting-memory-and-storage-in-the-ai-era/)
- Видання: AiiN (https://aiin.news)
- URL: https://aiin.news/article?slug=%D1%87%D0%BE%D0%BC%D1%83-%D1%81%D1%85%D0%BE%D0%B2%D0%B8%D1%89%D0%B5-%D0%B4%D0%B0%D0%BD%D0%B8%D1%85-%D1%81%D1%82%D0%B0%D1%94-%D0%B3%D0%BE%D0%BB%D0%BE%D0%B2%D0%BD%D0%B8%D0%BC-%D0%B2%D1%83%D0%B7%D1%8C%D0%BA%D0%B8%D0%BC-%D0%BC%D1%96%D1%81%D1%86%D0%B5%D0%BC-ai-%D1%96%D0%BD%D1%84%D1%80%D0%B0%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D0%B8

---

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](https://www.technologyreview.com/2026/09/04/1140872/architecting-memory-and-storage-in-the-ai-era/), саме памʼять і сховище — а не сирі обчислення 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) відповідно до частоти звернень, а не просто нарощувати дешеве сховище знизу піраміди.

---

Теги: AI, RAG, памʼять, AIінфраструктура, storage

Джерело: AiiN — https://aiin.news/article?slug=%D1%87%D0%BE%D0%BC%D1%83-%D1%81%D1%85%D0%BE%D0%B2%D0%B8%D1%89%D0%B5-%D0%B4%D0%B0%D0%BD%D0%B8%D1%85-%D1%81%D1%82%D0%B0%D1%94-%D0%B3%D0%BE%D0%BB%D0%BE%D0%B2%D0%BD%D0%B8%D0%BC-%D0%B2%D1%83%D0%B7%D1%8C%D0%BA%D0%B8%D0%BC-%D0%BC%D1%96%D1%81%D1%86%D0%B5%D0%BC-ai-%D1%96%D0%BD%D1%84%D1%80%D0%B0%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D0%B8. Цитуючи, посилайтесь на канонічний URL.