SeaVerse скоротив витрати на інфраструктуру на 60%
SeaVerse (стартап від SeaArt) будує платформу playable AI — ігри й чат-персонажі, що генеруються з одного промпту. Кожна генерація виконується в окремому sandbox. Перехід на GKE Agent Sandbox з ізоляцією на рівні ядра (gVisor, Kata Containers) дав до 300 sandbox-ів за секунду на кластер і 90% запусків за 200 мс — при меті дійти до мільйона sandbox-ів.
Раніше жорстка ізоляція прив'язувала до конкретних типів серверів. Тепер workload-и йдуть на VM потрібного розміру, з'явилося постійне сховище для проєктів — звідси й економія до 60%.
Що відбувається всередині одного sandbox
Кожна генерація на SeaVerse — це не одна дія, а ланцюжок кроків. Спочатку промпт перетворюється на гру, чат-персонажа чи інтерактивний застосунок, а далі середовище проводить його через кілька стадій, перш ніж показати користувачу.
- generate — створення досвіду з промпту
- run, test, integration, verification — запуск, тестування, інтеграція і перевірка
- preview, refine, publish — перегляд, доопрацювання, публікація
GKE Agent Sandbox відповідає за весь цей ланцюжок, а не лише за момент генерації. До переходу інженери SeaVerse описували роботу з sandbox-ами як «чорну скриньку»: коли workload падав, команда бачила, що щось пішло не так, але не мала runtime-статусів, метрик чи сигналів про причину — проблему доводилось вручну відстежувати через кілька ланок виконання. Після переходу логінг і моніторинг Google Cloud дістають дані прямо зсередини sandbox-ів, і команда швидше знаходить причину збою. Користувач цього не бачить: він не має доступу до логів чи кластера, лише відчуває, чи швидко відкривається досвід і чи відповідає він на клік, малюнок чи повідомлення.
Ізоляція теж не задана жорстко в один спосіб: SeaVerse запускає sandbox-и на Kata Containers у зв'язці з Cloud Hypervisor (microVM), з можливістю перемикати isolation runtime між microVM і gVisor залежно від workload. Це і дає поєднання гнучкості між хмарами та потрібного рівня захисту.
Друга економія: сховище, яке переживає одну сесію
Не всі проєкти на платформі створюються за один прохід. Частина користувачів повертається доопрацювати ідею, розвинути раніший варіант або запросити інших зробити ремікс. Попередня архітектура SeaVerse не підтримувала постійну файлову систему для таких сценаріїв — сандбокс втрачав стан після сесії.
Це друге, окреме від VM-гнучкості джерело економії до 60%: GKE Agent Sandbox дозволив підключати постійне сховище саме там, де воно потрібне, зберігаючи при цьому межі ізоляції між користувачами. Для творця це означає проєкт, який швидко відкривається і який можна доопрацьовувати чи переглядати з часом, а не запускати заново.
Чому обрали керовану платформу, а не власний кластер
SeaVerse свідомо обрала GKE замість самостійного адміністрування Kubernetes: команда не хотіла перетворювати інженерів продукту на команду підтримки кластера. Для керівника, який оцінює подібний кейс для своєї компанії, це окреме питання від технічної ізоляції — скільки людських ресурсів піде на підтримку інфраструктури замість продукту.
Перш ніж переносити цифри цього кейсу на власні розрахунки, варто розрізняти досягнуте і заплановане.
- 300 sandbox-ів за секунду і 90% запусків за 200 мс — це параметри загальної доступності (GA) самого продукту GKE Agent Sandbox, а не унікальний результат SeaVerse
- мільйон sandbox-ів — довгострокова ціль компанії, ще не досягнутий показник
- Gemini для аналітики досвідів, BigQuery AI/ML для прогнозу відтоку, LTV, ROI та сегментації, Imagen і Veo для генерації контенту — це інструменти, які SeaVerse лише досліджує, а не впровадила
Дати запуску платформи та вартості самого переходу на нову інфраструктуру в матеріалі немає.