Технічний контекст
Я уважно переглянув статтю Unconventional AI, і теза там не декоративна, а дуже приземлена: досить шукати одну ідеальну пам'ять для всього. Для реального AI implementation це звучить сильно, тому що інференс і тренування давно вперлися не лише в математику, а в ціну переміщення даних.
Автори пропонують «згладити трикутник» швидкості, щільності та утримання даних. Не доводити кожну комірку до майже безпомилкового стану, як у класичній обчислювальній школі, а прийняти, що AI-навантаження терплять гнучкіші компроміси.
Я б розклав їхню думку на дві різні пам'яті. Перша, для ваг моделі: тут важливі щільність та утримання, тому що ваги при інференсі майже не перезаписуються. Друга, для робочого стану та KV cache: тут потрібна дуже швидка пам'ять поруч із обчисленням, навіть якщо утримання коротше й архітектурі доведеться це компенсувати.
Ось де починається найцікавіше. Як кандидати вони рухають gain cells, eDRAM, PCM та 3D-стек HBM поверх логіки. Не як «переможе хтось один», а як набір технологій в одному стеку, де кожна закриває свій клас даних.
Мені особливо сподобався акцент на локальності. Якщо читання із зовнішньої пам'яті справді з'їдає помітну частку енергії прискорювача, то розмова вже не про гарну схемотехніку, а про вартість токена. І так, ідея тримати максимум моделі та стану на кристалі або максимально близько до нього виглядає не як фантазія, а як наступний обов'язковий крок.
Стаття свіжа, липень 2026, тож це не ретроспектива, а цілком актуальний сигнал у бік наступного покоління AI-інфраструктури.
Що це змінює для бізнесу та автоматизації
Я бачу тут три прямі наслідки. Перше: виграють ті, хто будує inference-first залізо та сервіси, де важлива ціна відповіді, а не лише піковий benchmark. Друге: HBM перестає бути єдиною священною відповіддю, а отже відкриється ринок для дешевших і вузькоспеціалізованих конфігурацій.
Програють ті, хто продовжить проєктувати AI architecture за старою логікою «все універсально, все максимально надійно, потім розберемося з енергією». З таким підходом automation with AI швидко впреться в economics, особливо на довгому контексті та великих обсягах запитів.
Я в клієнтів постійно бачу одну й ту саму проблему: всі обговорюють модель, але недооцінюють пам'ять, мережу та вартість кожного кроку пайплайну. А саме там часто вирішується, чи злетить AI automation у проді, чи залишиться дорогою демкою.
Якщо ви вже рахуєте, як здешевити інференс, запакувати приватний контур або спроєктувати AI integration без зайвого залізного оверхеду, це саме той момент, коли варто перезібрати архітектуру з нуля. У Nahornyi AI Lab ми з цим і допомагаємо: не малюємо гарні схеми заради схем, а збираємо робочі AI solutions for business під реальні обмеження за ціною, швидкістю та масштабом.