Supermicro представила на OpenStorageSummit 2026 архітектуру зберігання даних, розраховану на обслуговування AI-інференсу з контекстними вікнами, що вимірюються сотнями тисяч і мільйонами токенів. Це вже не черговий анонс заліза для дата-центру — це визнання того, що інференс великих мовних моделей перестав вписуватися у звичну формулу «GPU плюс оперативна пам'ять».

Коли модель тримає в активному контексті мільйони токенів одночасно, обсяг проміжних даних, які потрібно зберігати між кроками генерації, зростає настільки, що GPU-пам'яті на це вже не вистачає. За даними SiliconANGLE AI, індустрія формує окремий інфраструктурний рівень саме для обслуговування довгого AI-інференсу — тобто виносить частину навантаження з дорогої й обмеженої пам'яті GPU у спеціалізоване швидке сховище.

Для команд, що будують продукти на LLM, це не абстрактна новина про залізо. Рішення, які ще два роки тому вважалися дрібними технічними деталями — де і як кешувати контекст користувача, — тепер напряму визначають вартість токена і швидкість відповіді застосунку.

Що саме змінилося в обробці довгого контексту?

Річ у механіці самого інференсу. Коли модель отримує запит, вона спершу обробляє весь вхідний контекст (фаза prefill), а потім генерує відповідь токен за токеном (фаза decode), звертаючись при цьому до проміжного стану — так званого KV-кешу, — який зберігає «пам'ять» моделі про вже оброблені токени.

Що довший контекст, то більший цей кеш. Вікно в кілька сотень тисяч токенів вимагає гігабайтів проміжних даних на кожен активний запит, а таких запитів у продакшн-системі — тисячі одночасно. GPU-пам'ять для цього не проєктувалася: вона швидка, але дорога й обмежена за обсягом, тож кеш або витісняється, або його доводиться перераховувати заново — а це вже пряма втрата швидкості й грошей.

Чому сховище стає окремим шаром інфраструктури?

Тому що тримати весь KV-кеш у GPU-пам'яті економічно і технічно нереалістично при мільйонних контекстах. Рішення, яке намітилося в індустрії, — виносити частину кешу на швидке зовнішнє сховище (NVMe, пам'ять класу CXL, спеціалізовані storage-кластери) і підвантажувати потрібні фрагменти лише тоді, коли вони справді знадобляться.

Це принципово інша задача, ніж класичне зберігання даних для тренування моделей: там головне — пропускна здатність для великих послідовних читань. Тут головне — низька затримка для точкового, непередбачуваного доступу під час обслуговування живого трафіка. Саме тому з'являється окремий шар — «inference storage», — а не просто швидший диск під ту саму архітектуру.

Що це означає для архітектури RAG і кешування?

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

• Кешування контексту між запитами одного користувача (prompt caching) стає не опцією, а вимогою — інакше кожен запит платить повну ціну prefill заново.
• Вибір між «більше контексту» і «розумніший retrieval» тепер залежить не лише від якості відповіді, а й від того, яка інфраструктура сховища стоїть за провайдером API.
• Провайдери, що будують власний inference storage layer — а саме такий напрямок демонструє Supermicro на OpenStorageSummit, — потенційно зможуть пропонувати довший контекст дешевше, і це варто моніторити при виборі постачальника.

Ми вже писали, як OpenAI будує власний стек від чипів до продуктів — поява окремого шару сховища для інференсу це той самий тренд: інфраструктура під LLM перестає бути готовим блоком постачальника і стає предметом окремої вертикальної оптимізації.

Висновок AiiN: що робити з цим зараз?

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

Що робити зараз: перевірте, чи ваш AI-провайдер підтримує prompt- або context-кешування і на яких умовах воно тарифікується; не переносьте автоматично весь RAG-пайплайн на «просто закинути все в контекст», поки не порахували вартість повторного prefill; і закладайте в архітектуру можливість швидко переключитися між постачальниками, коли з'являться пропозиції з дешевшим довгим контекстом завдяки новому шару сховища.

Що таке KV-кеш і чому він важливий для довгого контексту?

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

Чи стосується це лише великих постачальників хмарної інфраструктури?

Ні, напряму це впливає і на команди, що просто споживають API моделей: вартість токена і швидкість відповіді, які вони бачать у рахунку, залежать від того, наскільки ефективно провайдер кешує й зберігає контекст на своєму боці. За нашою оцінкою, у найближчий рік це стане помітним фактором конкуренції між провайдерами API.