Oxide залучає $445 млн у раунді Series D для масштабування корпоративної хмарної інфраструктури

Хмарний досвід стає тим, що підприємства можуть придбати та експлуатувати у власних приміщеннях. Oxide Computer Company залучила $445 млн у раунді Series D, щоб розширити цю пропозицію: інтегрована обчислювальна система, що поєднує апаратне забезпечення та програмне забезпечення з відкритим кодом у інфраструктуру, якою володіють їхні клієнти.

Оголошення від 9 жовтня визначає Eclipse головним інвестором, з участю існуючих інвесторів, серед яких US Innovative Technology Fund, Riot Ventures та Jane Street. Новими інвесторами стали Atreides Management і AMD Ventures. Oxide повідомляє, що вона досягла прибутковості на початку цього року і використає капітал для забезпечення компонентів та розширення виробництва, оскільки попит перевищує виробничі можливості. Генеральний директор Стів Так стверджує, що виробнича потужність збільшилася в двадцять разів за останні дванадцять місяців — це показник потужності, зазначений компанією, а не метрика зростання доходу. Оголошення про фінансування розкладає інвестиції навколо масштабування поставок.

Чому прибутковій апаратній компанії потрібен додатковий капітал

Прибутковість і готівка, доступна для розширення, — різні речі, коли бізнес змушений будувати фізичні системи. У їхньому супровідному пості компанії співзасновники Брайан Кантрілл та Стів Так пояснюють, що прибутковість Oxide походила від звичайних комп’ютерних операцій після урахування вартості компонентів, виробництва, зарплат і інших витрат.

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

Це робить історію фінансування надзвичайно конкретною. Наступним випробуванням є те, чи додаткова купівельна спроможність і виробнича потужність перетворяться у своєчасні установки, надійну підтримку та стабільне прийняття клієнтами. Великий раунд забезпечує ресурси для цієї роботи; виконання визначає результат.

Що насправді означає корпоративна хмара, що належить підприємству

Одиниця придбання Oxide — це повний стійка, а не набір окремо обраних серверів, сховищних пристроїв, мережевого обладнання та ліцензій на віртуалізацію. Її документація продукту описує інтегрований контрольний рівень з API, веб‑порталом та SDK для розгортання віртуальних машин, блочного сховища та віртуальної мережі.

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

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

Внутрішня архітектура: віртуалізація, сховище та мережа

Архітектура Oxide більш конкретна, ніж натякає мітка «приватна хмара». Її посібник з гіпервізора та сховища описує Helios — хостову операційну систему на базі illumos, та Propolis — гіпервізор у користувацькому просторі на Rust, побудований навколо відкритого монітора віртуальних машин bhyve. Гостьові операційні системи використовують знайомі інтерфейси віртуального обладнання.

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

Мережева архітектура розділяє управлінський трафік від мережі застосунків. Packet Transformation Engine від Oxide виконує функції, включаючи маршрутизацію, брандмауер та трансляцію адрес між віртуальними машинами та фізичними інтерфейсами. Резервні з’єднання комутаторів забезпечують доступність, а конструкції віртуальної приватної хмари створюють логічні мережеві межі для навантажень.

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

Процесори AMD та навантаження ШІ навколо GPU

Участь AMD має прямий технічний зв’язок. Поточні специфікації Oxide перераховують друге покоління обчислювальних блоків на процесорах AMD EPYC 9005, з конфігураціями до 192 фізичних ядер і 1,5 ТіБ пам’яті на блок, а також двома 100‑GbE мережевими з’єднаннями. Потужність залежить від обраної конфігурації; загальна кількість фізичного обладнання також відрізняється від ресурсів, доступних гостьовим навантаженням.

Для команд, що працюють із ШІ, ці ресурси охоплюють значну частину інфраструктури, що оточує виконання моделей. На сторінці інфраструктури ШІ Oxide підкреслює інженерію даних, класичне машинне навчання, пошук та пошук за схожістю, а також окремі навантаження інференції на процесорах CPU. Вона виділяє сумісність із інструментами, такими як Spark, Airflow, Ray і XGBoost, разом із автоматизацією, керованою API.

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

Це не доводить, що стійка процесорів CPU може замінити інфраструктуру GPU для кожного завдання ШІ. Команди мають тестувати свої реальні моделі, навантаження пошуку, цільові показники затримки та паралельність. Оптимальне розподілення між CPU, прискорювачами та зовнішніми сервісами залежить від конкретного застосування.

Підтримка Kubernetes заслуговує ретельного розгляду

Знання хмари також залежить від навколишніх інструментів. У посту інженерії від 13 серпня Oxide описав інтеграції з Rancher, Talos Linux через Omni та Cluster API, а також менеджер контролера хмари, який з’єднує інформацію про вузли Kubernetes з інстанціями Oxide.

У цьому пості також розрізняли вже реалізовані можливості та поточну розробку. Підключення дисків «на гарячу» та вбудований плагін Container Storage Interface ще розроблялися на момент публікації, тоді як обговорення мережевих сервісів пояснювало доступний підхід до балансування навантаження. Це застарілі деталі реалізації, тому покупцям слід перевіряти актуальний статус випуску, а не припускати постійні обмеження чи повну відповідність керованому публічному хмарному сервісу.

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

Рішення про власність все ще зводиться до навантажень

Unite.AI також розглянув приватний ШІ та репатріацію хмари через хостовану інфраструктуру. Oxide пропонує інший шлях у цьому обговоренні: придбання самого інтегрованого рішення.

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

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