Если ты в последние несколько месяцев пробовал развернуть свежий вычислительный кластер в публичных облаках Amazon Web Services, Google Cloud или Microsoft Azure, то наверняка столкнулся с явлением, о котором еще пару лет назад никто и помыслить не мог. Вместо привычного мгновенного выделения виртуальных машин облачные провайдеры всё чаще выдают сухую ошибку InsufficientInstanceCapacity, заставляют неделями ждать одобрения заявок на увеличение базовых квот (quota requests) или вовсе уведомляют о дефиците целых семейств инстансов в популярных регионах.
Особенно сокрушительный удар пришелся по любителям так называемых спотовых инстансов (Spot / Preemptible Instances). Архитекторы годами приучали команды собирать stateless-воркеры, CI-раннеры и пакетные обработчики данных на бросовых спот-мощностях, получая скидку до 70–80% от базового тарифа On-Demand. Теперь эта халява стремительно сворачивается: спотовые виртуалки отзываются облаком с задержкой в две минуты, а новые инстансы на замену просто не поднимаются из-за физического отсутствия свободных чипов в дата-центрах.
В издании The Pragmatic Engineer вышел подробный аналитический отчет «The Pulse: a new trend of CPU shortages», раскрывающий скрытые шестеренки глобального инфраструктурного сдвига.
Бум искусственного интеллекта против классических x86-серверов
Давай разберем корень проблемы. Обывателю кажется: весь мир сошел с ума по графическим ускорителям (GPU) Nvidia H100 и B200, при чем же здесь обычные серверные процессоры общего назначения?
На деле взаимосвязь оказалась прямой и беспощадной. Чтобы заставить работать гигантский вычислительный кластер обучения и инференса больших языковых моделей, недостаточно просто закупить тысячи графических чипов. Каждый ИИ-сервер (такой как Nvidia DGX или суперкластеры гиперскейлеров) требует мощных головных x86/ARM-процессоров (хост-нод) для координации сетевого взаимодействия по протоколу InfiniBand, подготовки тензорных данных, управления распределенными файловыми хранилищами и маршрутизации контекста.
В результате кремниевые фабрики TSMC, Intel и Samsung столкнулись с жестким конфликтом за лимитированные мощности фотолитографии и продвинутой упаковки кристаллов (CoWoS). Производители чипов вынуждены отдавать приоритет высокомаржинальным кремниевым сборкам для ИИ, сокращая объемы выпуска стандартных серверных линеек AMD EPYC (Genoa, Bergamo) и Intel Xeon Scalable (Emerald Rapids, Granite Rapids).
В то же время сами гиперскейлеры (AWS, Azure, GCP) перенаправили львиную долю свободных серверных мощностей на обслуживание собственных ненасытных ИИ-сервисов — генеративных ассистентов, векторных баз данных и мультимодальных платформ. Резервный буфер оборудования, который раньше распродавался на спотовом аукционе по дешевке, попросту испарился.
Почему мультиоблачность и ARM не спасают от кассового разрыва
Многие команды надеялись спастись переходом на энергоэффективные серверные ARM-процессоры собственной разработки провайдеров — например, AWS Graviton4 или Google Cloud Axion. Действительно, соотношение производительности на ватт у них впечатляющее. Но и здесь возник бутылочный перешеек: спрос на инстансы Graviton со стороны инженерных команд вырос быстрее, чем провайдеры успевают заводить новые серверные стойки в эксплуатацию.
Кроме того, дефицит обнажил фундаментальный изъян концепции наивной мультиоблачности. Если у тебя за плечами распределенная инфраструктура, это не гарантирует защиту от сбоев поставок: фабрики по производству чипов у всех вендоров общие, и когда поставки серверных плат задерживаются на 6–9 месяцев, в очереди стоят и Microsoft, и Amazon, и небольшие региональные хостеры.
Ранее мы исследовали архитектуру изолированных сред в материале Cloudroom: архитектура изолированных облачных песочниц для одновременного запуска сотен ИИ-агентов, где подчеркивали: планирование плотности вычислений на одно ядро становится критическим навыком современного разработчика.
Как перестроить архитектуру в эпоху аппаратного дефицита
Для engineering-лидов и DevOps-команд наступают времена жесткой ревизии инфраструктурных привычек:
- Отказ от тотальной ставки на споты для критических сервисов: Спотовые виртуалки больше нельзя рассматривать как гарантированный вычислительный пул. Если сервис должен держать SLA 99.9%, базовый фундамент обязан опираться на зарезервированные мощности (Reserved Instances или Savings Plans) с гарантией предоставления емкости (Capacity Reservations).
- Агрессивная оптимизация компиляции и рантаймов: Эра бездумного масштабирования контейнеров в ширь (scale-out) уходит в прошлое. Переход сервисов с неоптимизированных интерпретируемых языков на Go, Rust или компилируемый Java-рантайм (GraalVM), оптимизация GC и аллокаций памяти позволяют выжать в 3–5 раз больше RPS из тех же самых процессорных ядер.
- Географическая диверсификация с холодным резервом: Вместо попыток выбить дефицитные квоты в центральных регионах (US-East или EU-Central) инфраструктуру приходится распределять по вторичным регионам и настраивать автоматический фейловер.
Эпоха дешевого неограниченного облачного кремния подошла к концу. В ближайшие годы побеждать будут те инженерные команды, которые умеют считать реальную стоимость процессорных циклов и писать эффективный, бережливый код.