Ken Claffey, CEO of VDURA – Interview Series: A Return Conversation

Ken Claffey, CEO і президент VDURA, є досвідченим лідером бізнесу та продукту, орієнтованим на клієнта, з глибокими знаннями в галузі хмарних та корпоративних інфраструктур, апаратного та програмного забезпечення, а також стратегічного зростання продукції, операцій та функцій виходу на ринок. Протягом своєї кар’єри він створив та очолював високопродуктивні глобальні команди, реалізовував корпоративну стратегію, забезпечував прибутковий рост продукції та інновацій, а також повертав підприємства, які працювали з збитками. До того, як очолити VDURA, Клаффей обіймав керівні посади в Seagate Technology, де він обіймав посаду старшого віце-президента та генерального менеджера з наглядом за корпоративними системами та P&L, а також посади керівництва в Xyratex, Adaptec та Eurologic, маючи десятирічний досвід у сфері корпоративного сховища даних та високопродуктивних обчислень.

VDURA є компанією, що спеціалізується на програмно-визначеній інфраструктурі даних, і будує сучасні рішення для сховищ даних, оптимізовані для штучного інтелекту та високопродуктивних обчислень під гаслом “швидкість зустрічає надійність”. Флагманська платформа VDURA Data Platform поєднує продуктивність паралельної файлової системи з надійністю об’єктного сховища в уніфікованій архітектурі, яка масштабується лінійно через тисячі клієнтів та вузлів, спрощуючи операції та знижуючи загальні витрати на володіння. Заснована спочатку як Panasas та ребрендирована у 2024 році, платформа VDURA підтримує локальні, хмарні та гібридні середовища з передовими автоматизаціями, прискоренням метаданих та масштабованою продуктивністю, призначеною для підтримки кластерів GPU та захисту даних для корпоративних, дослідницьких та критично важливих випадків штучного інтелекту та високопродуктивних обчислень.

Як ваша подорож через високопродуктивні обчислення та корпоративне сховище даних сформувала вашу думку про те, що сховище даних стає визначальною обмеженням у інфраструктурі штучного інтелекту?

Маюючи досвід будівництва систем сховищ даних для деяких з найважчих обчислювальних середовищ світу, ви розвиваєте інтуїцію щодо того, де насправді розташовані вузькі місця, а не там, де люди думають, що вони розташовані. У Xyratex та під час роботи над ClusterStor у Seagate ми вирішували проблеми сховищ даних для суперкомп’ютерів, де фізика була безжалісною. Ви або годуєте обчислення, або ні.

Тепер у інфраструктурі штучного інтелекту я бачу ту саму фундаментальну обмеження, тільки в іншій економіці. Захоплення GPU на ринку Neocloud було зрозумілим. NVIDIA створила дефіцитну та трансформаційну ресурс. Але припущення, що сховище даних просто масштабуватиметься разом з ним, дешево та легко, завжди було помилковим. Воно вже зруйнувалося. Сховище даних тепер складає 20-30 відсотків бюджету інфраструктури штучного інтелекту у всіх флеш-розгортуваннях, зростаючи швидше, ніж будь-який інший компонент. Коли ви провели кар’єру, спостерігаючи, як сховище даних стає обмежувальною ланкою у кожному великомасштабному обчислювальному середовищі, ви перестаєте дивуватися, коли решта ринку доходить до цієї реальності.

Чому планування сховищ даних було відкладено під час захоплення інфраструктури Neocloud?

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

По-друге, конкурентна динаміка віддавала перевагу кількості GPU над усім іншим. Ринок Neocloud оцінювався за кількістю чипів NVIDIA, які ви могли встановити. Сховище даних було приблизно 10-відсотковим пунктом, легким для затвердження без глибокого аналізу. По-третє, рішення про використання флеш-накопичувачів здавалося безпечним, оскільки воно усунуло складність. Однієї шару, одного типу носіїв, простого у закупівлі та експлуатації. Проблема полягає в тому, що “простий” і “економічно сталий” перестали бути одним і тим же, коли постачання NAND звузилося і ціни зросли. До того часу, як інфраструктурні рішення були вже закріплені.

Яке найбільше здивування операторів, коли вони бачать, як сховище даних впливає на використання GPU?

Відношення є більш прямим, ніж більшість операторів розуміють, поки вони не дивляться на простійні GPU. Тренувальні запуски з частим створення контрольних точок створюють сплескові вимоги запису, які можуть зупинити обчислення, якщо шар сховищ даних не може поглинути їх досить швидко. Дані трубопроводи для попередньої обробки та інгестії створюють тривалі вимоги читання, які, якщо не задовольняються, позбавляють GPU роботи.

Власна документація NVIDIA щодо DGX кваліфікує це: тренування текстових моделей LLM вимагає приблизно 0,5 ГБ/с швидкості читання на GPU, тоді як фізичні завдання штучного інтелекту та візуалізації вимагають приблизно 4 ГБ/с читання та 2 ГБ/с запису на GPU. Якщо ваша архітектура сховищ даних не може доставити це, ви не працюєте на повну потужність своїх GPU. Ви працюєте на тієї частці, яку дозволяє ваше сховище даних.

Архітектура має величезне значення у масштабі кластера. Система сховищ даних, яка впроваджує посередника між приводом та клієнтом, може показувати порівнянну продуктивність на одному диску, але у масштабі ви можете закінчитися тим, що вам потрібно в три рази більше дисків, щоб насичити той самий флот GPU. У три рази більше SSD, у три рази більше потужності, у три рази більше стійки. Математика використання швидко зростає.

Які вартісні відмінності можуть виникнути лише через вибір SSD та архітектурний дизайн, навіть якщо заголовні показники продуктивності здаються подібними?

Це місце, де оператори потрапляють у серйозні проблеми, оскільки заголовні числа можуть бути справді оманливими. Візьміть представницький приклад. 122,88 ТБ QLC NVMe SSD коштує приблизно 27 000 доларів. 7,68 ТБ привід з того самого покоління забезпечує порівнянну послідовну продуктивність за приблизно 1 800 доларів. Для кластера з 4 096 GPU на вдосконаленому специфікації NVIDIA це одне рішення щодо вибору ємності виробляє рахунок за флеш-накопичувачі від 600 000 до 9,6 мільйона доларів. Продуктивність є фактично ідентичною. Єдина змінна – це те, скільки холодних даних ви обираєте для розміщення на преміум-носіях, які не забезпечують додаткової переваги продуктивності.

Крім того, архітектурний дизайн визначає кількість дисків у масштабі кластера. Архітектура, яка забезпечує приблизно 5,8 ГБ/с виміряної швидкості читання на SSD, потребує близько 353 дисків, щоб насичити кластер з 4 096 GPU. Архітектура, яка забезпечує приблизно 1,9 ГБ/с на SSD через посередницьку витрату, потребує понад 1 000. При ціні 12 000 доларів за 30 ТБ диск ця різниця не є округленням – це питання бізнес-моделі.

Як оператори повинні переосмислити використання флеш-накопичувачів проти шарового сховищ даних, коли ціни на флеш-накопичувачі зростають та постачання NAND залишається обмеженим?

Початковою точкою є визнання того, що економічна передумова за інфраструктурою штучного інтелекту з використанням флеш-накопичувачів завжди була умовною, а не фундаментальною. Генеральний директор Phison описав виробничу потужність NAND як ефективно розподілену до 2026 року. Goldman Sachs прогнозує зростання цін на DRAM на двозначні відсотки квартал до кварталу протягом того самого періоду. Варіант флеш-накопичувачів за замовчуванням мав сенс, коли флеш-накопичувачі були дешевими та численними. Тепер цього немає.

Правильна база полягає в тому, щоб запитати, для чого насправді потрібен флеш-накопичувач. Флеш-накопичувач є засобом забезпечення продуктивності. Він повинен бути розмічений для забезпечення продуктивності GPU, не більше. Все інше, включаючи холодні дані, контрольні точки, які не читаються активно, та архівовані навчальні набори, належить на високогустинний HDD, який залишається на порядку величини дешевшим за терабайт.

Пастка, в яку потрапляють оператори, полягає в тому, що вони розглядають шарування як щось, що можна прикріпити: купити флеш-накопичувачі за замовчуванням, додати окреме об’єктне сховище для холодних даних та підключити їх за допомогою зовнішніх засобів переміщення даних. Це вводить другий програмний стек, другий план даних, складність мережі та операційну витрату. Підхід гіперсเกลерів, який працює з SSD та HDD у тому самому програмному стеку з вбудованим високопродуктивним шаруванням та без зовнішніх засобів переміщення даних, тримає сховище даних ближче до 10 відсотків бюджету інфраструктури, одночасно насичуючи кожен GPU.

Які уроки може вивчити рівень Neocloud з вибору дизайну сховищ даних гіперсเกลерів?

Найважливішим уроком є те, що Google, Meta та Microsoft не використовують флеш-накопичувачі, і вони мають більше досвіду з робочими завантаженнями штучного інтелекту, ніж будь-хто інший. Вони розгортають архітектури змішаного шарування з розумним шаруванням: достатньо флеш-накопичувачів, щоб насичити продуктивність GPU, а потім швидке спускання на високогустинні HDD. Це не філософська перевага. Це економічна необхідність, викликана ясним розумінням фізики робочих завантажень штучного інтелекту.

Другим уроком є архітектурна інтеграція. Гіперсเกลери не розв’язують шарування, з’єднуючи окремі системи. Вони працюють з SSD та HDD на тому самому програмному стеку, тому самому плані даних, з шаруванням як першокласною операцією всередині системи сховищ даних, а не пакетною роботою, керованою окремим інструментом. Ця інтеграція дозволяє їм тримати сховище даних економічно ефективним у величезному масштабі, одночасно забезпечуючи гарантії продуктивності, необхідні їхнім флотам GPU.

Третім уроком є підтримка надійності. Сховище даних AWS S3 забезпечує 11 дев’ять надійності. Сховище даних Azure Blob забезпечує 12 або більше. Традиційна архітектура HPC, побудована на локальному RAID, може впасти нижче 5 дев’ять на рівні масштабу, залежно від швидкості відмови дисків та вікон відновлення, потенційно тисячі втрачених файлів на рік через мільярд файлів. Сучасне мережеве кодування видалення з багаторівневим захистом може перевищити 11 дев’ять. Пропуск між цими двома реальностями – це різниця між системою сховищ даних, яку ви можете фактично забезпечити угодою про рівень обслуговування, та тією, яку не можете.

Як інфраструктурні команди повинні кількісно оцінити економічний вплив доступності сховищ даних на флоти GPU?

Математика засмучує, коли ви проводите її чесно. Використання спільного сховищ даних не створює пропорційного порушення угоди про рівень обслуговування. Воно створює одночасне порушення на кожному флоті GPU, підключеному до цього сховищ даних. Кластер з 5 000 GPU з доступністю сховищ даних 98 відсотків не забезпечує пропуск продуктивності 2 відсотка. Воно створює 876 000 годин втраченої продукції GPU на рік. При представницьких витратах на годину GPU це перекладується на мільйони доларів втраченої продукції щорічно, плюс кредити угоди про рівень обслуговування, що прикріплюються до кожного рівня доступності.

Інфраструктурні команди повинні явно моделювати це: яка є річна вартість втраченої продукції при вашому поточному рівні доступності сховищ даних, які є зобов’язаннями кредитів угоди про рівень обслуговування, що прикріплюються до кожного рівня доступності, та яке є ризик виходу клієнтів з порушеннями угоди про рівень обслуговування? Операційна складність сховищ даних – це невидима вартість, яка зростає у масштабі. CoreWeave та Oracle вже пропонують 99-відсоткову доступність на рівні стійки. Постачальники, які не можуть відповідати цьому, втрачають угоди сьогодні, а угоди, які вони втрачають, все частіше є високоцінними корпоративними контрактами, які ринок Neocloud потребує для доведення своєї довгострокової економіки.

Як різні архітектури сховищ даних порівнюються за продуктивністю на ват у середовищах з обмеженням потужності?

Це виникає майже у кожному серйозному інфраструктурному розговорі зараз, а різниця не є маржINALною. Це мультиплікативне. На основі опублікованих специфікацій та порівнянних конфігурацій, забезпечуючи приблизно 1 340 ГБ/с швидкості читання, одна архітектура витрачає 55 кВт, тоді як інша досягає подібного виходу при приблизно 16 кВт. Це різниця у 3,4 раза у продуктивності на ват. У центрі даних, де завдання штучного інтелекту споживають 40-250 кіловат на стійку проти фіксованого з’єднання з мережею, марні вати сховищ даних – це GPU, які ви не можете розгорнути. Власна документація NVIDIA щодо BlueField-4 заявляє явно, що доступність потужності є основним обмеженням для масштабування фабрик штучного інтелекту.

Є також другий ефект, який оператори рідко беруть до уваги. Деякі архітектури сховищ даних вимагають 5 ГБ оперативної пам’яті та одного до чотирьох присвячених ядер CPU постійно заблокованих на кожному вузлі GPU лише для досягнення пікової продуктивності сховищ даних. У масштабі кластера з 500 вузлів це 2,5 ТБ оперативної пам’яті та до 2 000 ядер CPU, які постійно недоступні для завдань штучного інтелекту. Коли ви платите 30 000 доларів або більше за GPU, кожне вкрадене ядро та кожний заблокований гігабайт – це прямий податок на інвестиції у обчислення, які є суттю інфраструктури.

Як архітектура сховищ даних безпосередньо впливає на конкурентоспроможність угоди про рівень обслуговування, коли гарантії часу безперервної роботи наближаються до 99 відсотків?

Сховище даних є найбільшим радіусом у будь-якому кластері GPU, що робить його найважливішим змінним у будь-якій чесній зобов’язанні угоди про рівень обслуговування. Система рейтингу ClusterMAX 2.0 від SemiAnalysis, яка стає впливовим бенчмарком у закупівлях Neocloud, робить угоди про рівень обслуговування явним фактором у цінових переговорах. Постачальники без конкурентоспроможних угод про рівень обслуговування втрачають угоди зараз.

Вимір надійності є рівнозначно важливим і менш обговорюваним. Корпоративні клієнти були звиклі до того, що очікували 11-12 дев’ять надійності від AWS S3 та Azure Blob. Традиційна архітектура HPC, побудована на локальному RAID, може впасти нижче 5 дев’ять на рівні масштабу, залежно від швидкості відмови дисків та вікон відновлення, потенційно тисячі втрачених файлів на рік через мільярд файлів. Сучасне мережеве кодування видалення з багаторівневим захистом може перевищити 11 дев’ять. Пропуск між цими двома реальностями – це різниця між системою сховищ даних, яку ви можете фактично забезпечити угодою про рівень обслуговування, та тією, яку не можете.

Які можливості сховищ даних найімовірніше визначать довгострокове виживання Neocloud через консолідацію?

Оператори, які виживуть, будуть тими, хто розв’язав рівняння загальної вартості володіння по всьому інфраструктурному стеку, а не лише рівняння закупівлі GPU. Це означає кілька конкретних можливостей.

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

Ширше кажучи, хвиля консолідації відокремлює інфраструктуру, побудовану для бенчмарків дня першого, від інфраструктури, побудованої для економіки третього року. Орендна плата за H100 впала більш ніж на 60 відсотків від піку. Ринок більше не винагородує накопичення GPU. Він вимагає доведення повернення інвестованого капіталу. Архітектура сховищ даних – це місце, де живе це доведення, оскільки це місце, де продуктивність GPU, зобов’язання угоди про рівень обслуговування, ефективність потужності та довгострокова структура витрат усіх сходяться.

Яке ваше послання операторам Neocloud, які оцінюють свою стратегію сховищ даних сьогодні?

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

Вікно, щоб зробити це правильно, звужується. Консолідація вже відбувається, а економіка безжалісна. Але для операторів, які готові переосмислити шар сховищ даних з тією ж ретельністю, яку вони застосували до вибору GPU, можливість значна. Сховище даних, зроблене правильно, не тільки знижує вартість. Воно розблокує повну вартість кожного GPU у стійці.