DeepSeek нанимает 150 бэкенд-инженеров для спасения инфраструктуры

Любой, кто хоть раз наблюдал, как дашборд Grafana краснеет в воскресенье после обеда, понимает, что означает план найма 150 инженеров на самом деле. Это значит, что дежурная ротация проигрывает. Это значит, что кто-то старший наконец признал: рефакторинг больше нельзя откладывать на следующий квартал. Последняя рекрутинговая кампания DeepSeek — именно такое признание, облачённое в пресс-релиз.

Что произошло

Китайская AI-компания DeepSeek запустила то, что её собственное руководство называет «беспрецедентной» кампанией найма: 150 старших бэкенд-инженеров для переработки базовой инфраструктуры. Как сообщил TechGig, о плане объявил Цуй Тяньи, руководитель команды Harness в компании.

Формулировки Цуя были прямолинейными. «В вычислениях, как только что-либо масштабируется количественно, это приводит к колоссальному росту сложности», — сказал он. Компания одновременно испытывает давление по четырём направлениям: быстрый рост объёмов данных, увеличение числа машин, рост обучающих нагрузок и рост числа активных пользователей. Иными словами, каждая ось распределённой системы находится под давлением одновременно. Это не проблема мощности, которую решают добавлением узлов. Это проблема архитектуры.

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

Контекст важен. Ранее DeepSeek уже сигнализировал о планах удвоить размер каждого департамента, а недавно скорректировал цены на API. Ни одно из этих решений не принимается в изоляции. Корректировка цен означает, что юнит-экономика пересматривается с учётом реальных затрат на инфраструктуру. Удвоение департаментов означает, что кривая роста опережает возможности оргструктуры. Кампания найма 150 инженеров находится на пересечении обоих факторов.

Моя оценка: компания тихо сообщает рынку, что слой модели в порядке, а вот «сантехника» — нет.

Техническая анатомия

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

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

Агенты ломают всё это. Рабочий процесс агента может разветвляться в десятки обращений к модели на одну пользовательскую задачу, каждое со своими вызовами инструментов, изолированными вычислениями, файловым I/O и циклами повторных попыток. Хвостовая задержка одной задачи теперь зависит от хвостовой задержки каждого подзапроса. Сессии живут минуты или часы вместо секунд. Состояние нужно сохранять, восстанавливать и освобождать. Планирование перестаёт напоминать веб-сервер и начинает напоминать пакетную систему с прикрученными поверх требованиями реального времени.

Именно поэтому список приоритетных направлений DeepSeek читается как лист системно-инженерного триажа. Эластичная вычислительная инфраструктура — это код для «нам нужно динамически перераспределять пулы GPU и CPU по мере непредсказуемых всплесков нагрузки агентов». Оптимизация низкоуровневых систем означает, что планировщик, RPC-слой и уровень хранения — все под подозрением. Фреймворки агентов и внутренняя инфраструктура стоят рядом с публичными API-сервисами в списке приоритетов, что говорит о том, что внутренние и внешние поверхности конкурируют за один и тот же ограниченный бэкенд.

Референсные архитектуры для такого рода нагрузок не являются секретом. Примитивы Kubernetes решают многое, а паттерны в Google Cloud Architecture Framework охватывают надёжность и эластичность в масштабе. Но паттерны гиперскейлеров предполагают, что у вас есть годы на их внедрение. DeepSeek пытается встроить их под нагрузкой. Это всегда сложнее, чем разработка с нуля, а производственные инциденты, которые я наблюдал именно в ходе такого рода миграций, как правило, группируются вокруг состояния сессий и применения квот.

Кто пострадает

Начнём с API-клиентов DeepSeek. Компания уже скорректировала цены на API, а переработка бэкенда такого масштаба означает одно из двух: либо цены отражают реальную стоимость обслуживания трафика агентов, либо цены субсидируют перестройку, за которую клиенты в итоге заплатят. В любом случае, командам, создавшим продукты на эндпоинтах DeepSeek, следует исходить из того, что ценообразование и условия SLA не устоялись. Любой, кто запускает fintech- или iGaming-бэкенд поверх одного провайдера моделей, знает правило: риск вендора реален, а переработка силами 150 инженеров — ведущий индикатор изменений в API-контрактах.

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

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

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

Сценарий для инженерных команд

Конкретные действия для руководителей платформ и CTO:

Первое: проверьте допущения по нагрузке агентов. Измерьте реальное количество обращений к модели на одну пользовательскую задачу, а не цифру с демо-дня. Если средняя задача разветвляется в 20 вызовов, ваша модель затрат на бэкенд, вероятно, ошибается на порядок. Пересчитайте планирование мощности с учётом реального fan-out.

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

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

Четвёртое: переговаривайтесь сейчас. Провайдеры, переписывающие базовую инфраструктуру, как никогда восприимчивы к корпоративным контрактам с реальными SLA. Ждать, пока переработка завершится, значит вести переговоры с более слабой позиции против более уверенного вендора.

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

Ключевые выводы

• Кампания найма 150 инженеров в DeepSeek — публичное признание того, что нагрузки агентов ломают бэкенды, спроектированные под трафик чатботов.
• Fan-out агентов меняет профиль нагрузки: от stateless запрос/ответ — к долгоживущим, многовызовным, stateful-сессиям. Сценарии автомасштабирования эпохи web это не покрывают.
• Недавняя корректировка цен на API плюс масштабная переработка бэкенда означают, что цены на API и условия SLA следует считать неустоявшимися для downstream-клиентов.
• Каждая AI-лаборатория, выпускающая агентов, сталкивается с той же физикой. Молчание конкурентов — не повод успокоиться.
• Платформенным командам следует проверить реальный fan-out агентов, обеспечить идемпотентность и согласовать контракты с провайдерами до завершения переработки, а не после.