Рынок AI-инфраструктуры со стороны выглядит как гонка за GPU: больше чипов, мощнее кластер, быстрее модель. В презентациях это выглядит почти линейно. Но когда AI-систему нужно не просто показать на демо, а стабильно запускать, масштабировать и обслуживать, главные проблемы лежат не только в модели и даже не только в GPU. Об этом в подкасте Stack Overflow рассказал Peter Salanki, технический директор и сооснователь CoreWeave — компании, специализирующейся на облачной инфраструктуре для AI-нагрузок. Разговор получился не про «будущее ИИ», а про приземлённую сторону индустрии: сети, память, планировщики, электропитание и разработчиков, которые иногда слишком рано строят архитектуру космического масштаба.

AI-нагрузки — это не обычный хостинг

Классические облака выросли вокруг модели «чёрного ящика»: разработчик получает виртуальную машину или managed-сервис и не думает о внутренностях. Для веб-приложений и API это работает. AI-нагрузки ведут себя иначе. Обучение больших моделей и сложный inference больше похожи на суперкомпьютерную задачу: тысячи ускорителей должны работать синхронно, обмениваться данными и двигаться в одном темпе. Если ломается один компонент, страдает вся задача.

«Стек для запуска AI-нагрузок — и обучения, и инференса — выглядит совсем иначе, чем традиционная архитектура гиперскейлеров».

AI-инфраструктура не обещает, что ничего никогда не сломается. Она должна быстро понять, что именно сломалось, изолировать проблемный компонент, сохранить прогресс и продолжить работу без полного отката назад. Это другой инженерный стиль.

Сеть — самое нервное место AI-кластера

Salanki подчёркивает: сеть в AI-инфраструктуре — один из самых сложных и болезненных элементов. В больших кластерах каждый ускоритель постоянно обменивается данными с другими. Чем быстрее становятся чипы, тем сильнее растёт потребность в синхронизации. Вычисления ускоряются, но данные всё равно нужно передавать, согласовывать и собирать обратно.

«Сеть всегда будет главным бутылочным горлышком. Как только компьютер становится быстрее, все сразу хотят, чтобы синхронизация занимала как можно меньше времени».

В архитектурах уровня NVIDIA Grace Blackwell речь идёт о множестве высокоскоростных линков и сотнях тысяч кабелей. На коротких расстояниях можно использовать электрические соединения (медь) — это быстро и надёжно. Но как только расстояния растут, приходится переходить к оптике: лазерам, модулям, волокну. А оптика греется, усложняет обслуживание и добавляет новые точки отказа. Отсюда разделение на scale-up (быстрые соединения внутри стойки) и scale-out (расширение за пределы стойки с оптикой и маршрутизацией). Любое ускорение вычислений снова упирается в сеть. AI-кластер — это система, где сеть становится частью вычислительного процесса.

Память: гонка не за гигабайтами, а за скоростью

Про AI часто говорят так, будто главное — найти достаточно памяти, чтобы влезла модель. Это правда только наполовину. В production важен не только объём, но и пропускная способность. Если модель большая, а данные двигаются медленно, GPU простаивает. Особенно это заметно в inference.

«Пропускная способность памяти — больший тормоз, чем размер памяти».

Выручают архитектурные подходы вроде Mixture of Experts: модель большая, но на каждый запрос активируется лишь часть параметров. Это снижает давление на память. Но бесплатных решений не бывает: если меньше давить на память, сложность может переехать в сеть или планировщик. Узкое место редко исчезает — чаще оно просто меняет адрес.

Кластер на 100 000 GPU: зачем и почему это не для всех

Технически кластеры на 100 000 GPU уже возможны. Но большой кластер создаёт не только мощность, но и ворох проблем: жизненный цикл оборудования, отказы, утилизация, сетевые сбои, распределение задач. Если у команды есть доступ к огромному числу GPU, это не значит, что она умеет эффективно их использовать. Всё чаще встаёт вопрос: «что именно команда делает с теми GPU, которые уже получила?».

Отсюда растёт значение observability — наблюдаемости. Нужно понимать, где реально работает вычисление, где простаивает память, где всё упирается в сеть и какие задачи конфликтуют. Без этого AI-инфраструктура превращается в чёрную дыру бюджета.

Планировщик — невидимый дирижёр

Когда ресурсов много и каждый час стоит дорого, планировщик становится критически важен. Исследователь хочет получить все GPU сразу, бизнес — чтобы ничего не простаивало, inference-сервису нужно масштабироваться под нагрузку. Все эти интересы сталкиваются в scheduling. Исторически использовали Slurm, но AI-инфраструктура всё чаще смотрит в сторону Kubernetes-экосистемы. Нужно решать, какие задачи приоритетны, что можно прервать, а что нет, и как не держать кластер пустым «на всякий случай». Это скучная инженерия, но именно она отличает промышленный AI от демонстрационного стенда.

Совет разработчикам: не переусложняйте раньше времени

Salanki предостерегает от типичной ошибки: команда ещё не набрала пользователей, но уже проектирует собственный inference stack, обсуждает сложную схему disaggregated serving, строит архитектуру на пять лет вперёд. Модель меняется каждую неделю, а инфраструктуру пытаются сделать монументальной.

«Моя главная рекомендация разработчикам в этой области — не переусложняйте».

Это знакомая история: когда-то так же начинали маленький сервис с огромной микросервисной архитектурой. В AI это опаснее, потому что область меняется слишком быстро. Новые модели, методы inference, GPU, ограничения — всё может поменять исходные предположения за несколько месяцев. Начните проще. Используйте готовые инструменты. Сфокусируйтесь на модели, продукте и пользовательской ценности. Инфраструктурную сложность лучше наращивать, когда она действительно стала ограничением.

Архитектура с коротким сроком жизни

В CoreWeave, по словам Salanki, проектируют системы так, будто многие верхние слои проживут всего несколько месяцев. Базовые примитивы должны быть крепкими и наблюдаемыми, но всё, что выше, — достаточно гибким для быстрой замены. «Мы должны построить что-то хорошее, надёжное и понятное для анализа, но ожидать, что это не проживёт дольше шести месяцев». В AI сейчас опасно строить слишком жёсткие конструкции: то, что сегодня выглядит правильным, через полгода может оказаться неудобным. Гибкость важнее идеальности.

Электричество и дата-центры: узкое место внизу

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

«Сырая электроэнергия — не главный узкий участок. Узкое место — превратить её в пригодную форму».

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

Цепочки поставок: сегодня GPU, завтра память

AI-бум создаёт постоянное давление на supply chain. Один дефицит сменяет другой: GPU, блоки питания, NAND, DRAM, сетевая оптика. В небольших масштабах можно было импровизировать, но на уровне современных кластеров это не работает. Масштаб слишком большой, требования к надёжности слишком высокие.

«Каждую неделю я теряю сон из-за новой проблемы в цепочке поставок».

Для пользователей это не всегда видно напрямую, но задержки поставок памяти или сетевого оборудования могут отражаться даже на потребительских сервисах. Основное давление создают дата-центры, которым нужны огромные объёмы компонентов.

AI-код: ускоритель, но не замена понимания

Команда Salanki использует AI-инструменты для написания кода, но с жёстким условием: «Я ожидаю, что каждый инженер понимает каждую строку, которую он построил с помощью AI-инструментов». AI-кодинг ускоряет работу, помогает с рутиной, но если команда перестаёт понимать архитектуру и принимает сгенерированный код как магию, скорость превращается в техдолг. Инциденты всё равно расследовать людям, ошибки в безопасности — их ответственность. Система, которую никто полностью не понимает, плохо сочетается с надёжной эксплуатацией.

Как выбирать провайдера

На рынке AI сейчас много новых игроков, потому что спрос огромный. Не каждый, кто продаёт доступ к GPU, одинаково хорошо понимает безопасность и надёжность. Если компания загружает к провайдеру свои данные, модели, веса, вопрос доверия критичен. Нужно знать, где данные хранятся, кто имеет доступ, как устроена изоляция, что происходит при сбоях. «Убедитесь, что вы знаете, кто ваш провайдер, что он делает с точки зрения безопасности и надёжности, особенно если вы загружаете свои данные». В AI это ещё чувствительнее, потому что данные — главный актив.

Production AI — это инженерная дисциплина

Разговор с Salanki складывается в трезвую картину: запуск моделей в production — не гонка за самым большим кластером и не покупка «волшебного» облака. Это набор сложных компромиссов. Нужна быстрая сеть, но она дорогая и физически сложная. Нужна память, но важна не только ёмкость, а пропускная способность. Нужны GPU, но без утилизации они превращаются в дорогой простой. Нужны планировщики, мониторинг, эксплуатация и команда, которая не теряет контроль над системой. Начинать стоит не с максимального масштаба, а с ясной задачи: что мы запускаем, для кого, с какой задержкой, что будет при падении части системы и где видно, что деньги на инфраструктуру работают. AI в production — это не магия вокруг модели, а инженерная дисциплина, где успех часто зависит от скучных вещей: сети, памяти, очередей, логов, электропитания и умения вовремя не усложнять.

Stack Overflow Blog