Один национальный HPC-кластер в Великобритании за месяц потерял $8,5 млн вычислительной мощности. Не из-за поломок, не из-за кибератак, а потому что исследователи заказывали вдвое-втрое больше GPU, чем им было нужно. Это не жадность — это рациональная перестраховка. Потерять трёхдневный эксперимент из-за нехватки памяти гораздо болезненнее, чем оставить кластер недогруженным. YC-стартап Expanse из когорты P26 предлагает способ сломать этот порочный круг без принуждения пользователей.

Что такое Expanse

Expanse — это программный слой, который устанавливается на каждую ноду кластера и встраивается в планировщики SLURM или Kubernetes. Он читает исходный код нагрузки, скрипт запуска и аппаратную топологию кластера, чтобы до запуска предсказать, сколько ресурсов задача реально потребует. Также система флагает потенциальные сбои — например, исчерпание видеопамяти — и предлагает оптимизации вплоть до конкретных строк кода.

Ключевое отличие от обычных рекомендательных систем: Expanse использует не LLM, а кастомную архитектуру машинного обучения, построенную с нуля для мультимодальных входных данных. Модель одновременно обрабатывает исходный код, скрипты сабмита, телеметрию железа и метаданные кластера — и выдаёт прогноз потребления GPU VRAM, утилизации, CPU-памяти и walltime с доверительным интервалом.

Почему дата-центры работают на треть мощности

Асимметрия риска делает перерасход неизбежным. Перезаказ ресурсов вреден коллективно — кластер простаивает, другие задачи стоят в очереди. Но недозаказ убивает индивидуально: задача падает на 71-м часе трёхдневного прогона, и весь результат уходит в мусор. Никто не хочет быть тем, чей эксперимент оборвался из-за экономии на гигабайтах. Поэтому все заказывают с двух-трёхкратным запасом.

Команда Expanse измерила один национальный кластер в течение месяца: из 122 тысяч задач 59% вычислительной мощности было потрачено впустую. При облачных on-demand тарифах это $8,5 млн в месяц на одном кластере. И эта картина типична не только для академических суперкомпьютеров, но и для квантовых фондов, AI-лабораторий и промышленных симуляций.

Проблема усугубляется тем, что традиционные инструменты планирования опираются на исторические средние значения из accounting-баз вроде sacct. Как только появляется новый тип нагрузки или меняется код — эти модели теряют точность. Исследователи знают это и ещё сильнее завышают запросы, чтобы перестраховаться от ошибок устаревшей статистики.

Почему LLM не справляются с этой задачей

Основатель Expanse Исмаил Башир провёл бенчмарк против передовых моделей: Gemini 3.5 Pro, Claude Opus 4.8, GPT 5.5 и Codex 5.3. Результат — кастомная модель Expanse превзошла их в восемь раз. При этом размер модели не коррелировал с точностью: Claude Haiku часто показывала лучшие результаты, чем Opus, а Codex 5.3 уступал даже GPT 5.5.

Причина в том, что LLM рассуждают в вакууме. Они видят код и скрипт запуска, но не чувствуют, как конкретная топология кластера влияет на производительность. Они не знают, что на этих конкретных узлах с этой конкретной сетевой картой распределённое обучение ведёт себя иначе, чем в учебном примере. Expanse, напротив, создаёт кастомное эмбеддинг железа кластера и дообучается на реальных задачах, которые на нём выполняются.

Интересно, что даже специализированные кодинг-модели не справились. LLM хороши в написании кода и подборе гиперпараметров, но для замкнутого цикла автоматических исследований им нужен внешний инструмент, который понимает инфраструктуру. Expanse позиционирует себя именно как такой инструмент — и предоставляет CLI-интерфейс, дружелюбный к агентам.

Три способности платформы

Предсказание ресурсов при сабмите. Перед запуском задачи Expanse выдаёт прогноз по GPU VRAM, утилизации GPU, CPU-памяти и walltime — с доверительным интервалом. На основе этого прогнозируются OOM-ошибки и другие проблемы с памятью, а также предлагаются оптимизации кода для повышения утилизации железа. Модель настроена на перестраховку: лучше дать чуть больше, чем рисковать падением задачи.

Живая обсервабельность. Во время выполнения задачи система собирает телеметрию через DCGM, CUPTI, cgroups и мониторинг сети/ввода-вывода. Дашборд показывает, что происходит с железом в данный момент и где задача проводит время в стеке вызовов. Профайлер работает с накладными расходами в однозначные проценты и коррелирует фреймы стека с метриками железа — пока только для Python, другие языки в разработке.

Диагностика отказов. Если задача падает, Expanse коррелирует профилирование стека с телеметрией железа и выдаёт лаконичные логи в одну-две строки. Не просто «CUDA out of memory», а «задача упала на строке 147 из-за непропорционального роста активаций при batch_size=64; попробуйте gradient checkpointing или снизьте до 48».

Архитектура и безопасность

Expanse устанавливается на каждую ноду и интегрируется в жизненный цикл задач SLURM или Kubernetes без изменения workflow пользователей. Демон пассивен: если он падает, задачи продолжают запускаться и выполняться как обычно. Система не заменяет планировщик, а работает рядом как слой предсказаний и рекомендаций.

Критически важный момент для enterprise и государственных заказчиков: развёртывание air-gapped. Телеметрия не покидает среду заказчика, нет центрального SaaS-бэкенда для хранения данных. Для on-prem и изолированных кластеров — нулевой egress и полный аудит логов. Это ответ на главное возражение, которое звучало в треде HN: финансовые, биотехнологические и национальные заказчики не допустят сторонний SaaS в критическом пути своих вычислений.

Бизнес-модель и рынок

Стартап работает по модели paid pilots. Двухнедельное окно измерений: установка, инжестия данных, отчёт о восстановляемой мощности. Затем платовый пилот в одном департаменте по фиксированной месячной ставке. Ценообразование — per cluster, а не per GPU или per job.

Целевой сегмент — кластеры от 100+ GPU под SLURM или Kubernetes. Это академические суперкомпьютерные центры, AI-лаборатории, квантовые фонды и промышленные симуляторы. Команда сама пришла из этих сред: Исмаил исследовал параллельные вычисления в EPCC — национальном суперкомпьютерном центре Великобритании, — а остальные трое запускали HPC и GPU-тренировки в крупнейших квантовых фондах.

Почему это важно прямо сейчас

GPU остаются дефицитным ресурсом. NVIDIA H100 стоит десятки тысяч долларов за штуку, а очереди на поставки растянуты на месяцы. Крупные AI-лаборатории тратят миллиарды на кластеры, а университеты конкурируют за грантовое время на национальных суперкомпьютерах. В этих условиях 30-50% простоя — это не «оптимизация», а прямая потеря конкурентоспособности.

Существующие подходы к оптимизации кластеров делятся на две категории: пассивный мониторинг и агрессивный oversubscription. Пассивный мониторинг показывает, что произошло, но не предотвращает потери. Oversubscription повышает утилизацию, но рискует стабильностью задач. Expanse занимает промежуточную позицию: активное предсказание без принуждения, информированный выбор вместо слепой перестраховки.

Ещё один важный аспект — рост agentic workflows в научных вычислениях. LLM-агенты всё чаще запускают эксперименты автономно: подбирают гиперпараметры, перезапускают задачи, анализируют результаты. Но эти агенты не понимают инфраструктуру. Они могут сгенерировать код, который теоретически работает, но не учитывает топологию конкретного кластера. Expanse предоставляет API и CLI, которые позволяют агентам получать инфраструктурный контекст — замыкая цикл от генерации кода до его эффективного выполнения.

Как Expanse сравнивается с другими подходами

Традиционные HPC-системы используют три подхода к планированию ресурсов. Первый — статические лимиты и очереди, где администратор вручную назначает приоритеты и квоты. Это надёжно, но не адаптируется к изменяющимся нагрузкам и не даёт обратной связи исследователям. Второй — исторические средние из accounting-баз, которые работают, пока код не меняется. Третий — эвристические правила, написанные администраторами кластера на основе опыта.

Expanse представляет четвёртый подход: предиктивная аналитика на основе мультимодальных данных. Вместо того чтобы полагаться на прошлое поведение или общие правила, система анализирует конкретную задачу в контексте конкретного железа. Это позволяет адаптироваться к новым типам нагрузок, новому коду и новому оборудованию без ручной настройки.

Сравнение с LLM-бейзлайнами особенно показательно. Gemini 3.5 Pro, Claude Opus 4.8, GPT 5.5 и Codex 5.3 — все они получили полный доступ к коду, скриптам запуска и документации кластера. Но без нативной поддержки мультимодальных входных данных и без дообучения на конкретном железе они не могли точно предсказать потребление ресурсов. Разрыв в 8x говорит о том, что доменная специализация важнее масштаба модели.

Часто задаваемые вопросы

Почему облачные провайдеры сами не делают так?

AWS и другие гиперскейлеры уже используют оверсабскрипцию и интеллектуальное размещение нагрузок. Но их оптимизации работают на уровне инфраструктуры, а не индивидуальной задачи. Expanse атакует проблему с другой стороны: предсказывает потребности конкретного сабмита и даёт исследователю обратную связь до запуска. Это дополняет, а не заменяет облачную оптимизацию.

Не убьёт ли это продажи железа?

Скорее наоборот. Большинство крупных пользователей вычислений ограничены по мощности и растут быстрее, чем успевают закупать GPU. Высвобождение 30-50% существующей мощности позволяет обслужить больше пользователей и отложить расширение, но не отменяет его. Для облачных провайдеров более плотная утилизация — это положительная единица экономики.

Что если модель ошибается и задача падает?

Expanse обучена на перестраховку: лучше дать чуть больше ресурсов, чем рисковать падением. Система выдаёт p90-оценки и позволяет пользователю выбрать свой уровень риска. Кроме того, модель дообучается на каждом кластере индивидуально и становится точнее с каждой новой задачей.

Работает ли это только для GPU-кластеров?

Хотя фокус на GPU и HPC, архитектура Expanse не привязана к конкретному типу железа. Система создаёт эмбеддинг производительности кластера на основе телеметрии, поэтому может адаптироваться к CPU-кластерам, гибридным конфигурациям и специализированным ускорителям вроде TPU или IPU. Главное требование — достаточный объём задач для дообучения модели.

Итог

Expanse решает проблему, которую многие предпочитают не замечать: GPU-кластеры — один из самых дорогих активов в современной науке и индустрии, и они работают вдвое-втрое ниже своей реальной мощности. Причина не в технической незрелости, а в рациональном поведении пользователей, которые перестраховываются из-за асимметрии рисков.

Подход Expanse интересен тем, что он не пытается переучить исследователей или насильно сократить их allocation. Вместо этого он даёт точные предсказания, обратную связь на уровне строк кода и диагностику отказов — превращая перестраховку из слепой привычки в информированный выбор. При цене облачных GPU в тысячи долларов в месяц за один узел, экономия в 30-50% быстро окупает внедрение. Если вы управляете кластером от сотни GPU — стоит присмотреться.