DeepSeek Наймає 150 Бекенд-інженерів для Порятунку Своєї Інфраструктури

Кожен, хто хоч раз спостерігав, як дашборд Grafana вкривається червоним у неділю вдень, розуміє, що насправді означає план найму 150 інженерів. Це означає, що черговий ротації більше не справляється. Це означає, що хтось старший нарешті визнав: переписування не можна відкладати ще на квартал. Остання рекрутингова хвиля DeepSeek — саме таке визнання, загорнуте у прес-реліз.

Що сталося

Китайська AI-компанія DeepSeek оголосила те, що її власне керівництво називає «безпрецедентною» кампанією найму: вони шукають 150 старших бекенд-інженерів для модернізації основної інфраструктури. Як повідомляє TechGig, план оголосив Куй Тяньї, який очолює команду Harness у компанії.

Куй висловився прямо. «У комп'ютерних системах, коли будь-що масштабується за кількістю, це призводить до масового зростання складності», — сказав він. Компанія одночасно бореться на чотирьох фронтах: стрімке зростання обсягів даних, збільшення кількості машин, зростання навчальних навантажень та зростання кількості активних користувачів. Інакше кажучи, кожна вісь розподіленої системи перебуває під тиском одночасно. Це не проблема потужності, яку можна вирішити додаванням вузлів. Це архітектурна проблема.

За повідомленнями, поточний бекенд DeepSeek досягає своїх меж. 150 нових ролей зосередяться передусім на серверній розробці: платформи для досліджень великих мовних моделей, фреймворки AI-агентів, внутрішня інфраструктура, публічні API-сервіси та інженерія даних. Другий напрям — еластична обчислювальна інфраструктура, включно з обслуговуванням платформ агентів та оптимізацією низькорівневих систем.

Важливий контекст. DeepSeek раніше заявляв про плани подвоїти розмір кожного відділу, а нещодавно скоригував ціни на API. Жоден із цих кроків не відбувається у вакуумі. Коригування цін означає, що одинична економіка переглядається відповідно до реальних витрат на інфраструктуру. Подвоєння відділів означає, що крива зростання швидша, ніж організаційна структура може засвоїти. Кампанія з 150 інженерів знаходиться на перетині обох тенденцій.

Моя думка: це компанія, яка тихо повідомляє ринку, що з рівнем моделі все гаразд, а з «сантехнікою» — ні.

Технічна анатомія

Найцікавіша частина цієї історії захована в одному реченні з джерела: AI-агенти можуть здійснювати повторні виклики моделі та використовувати власні обчислювальні середовища для виконання завдань, що суттєво збільшує навантаження на бекенд-системи порівняно зі звичайними чат-ботами. Це одне речення пояснює весь план найму.

Запит до чат-бота є приблизно stateless з точки зору платформи. Користувач надсилає запит, модель повертає токени, з'єднання закривається. Бюджети затримки передбачувані. Політики автомасштабування працюють. Коефіцієнти влучень у кеш мають сенс. Бекенд-інженери, з якими я працював на системах із високим QPS, люблять такий трафік, бо він відповідає будь-якому плейбуку, написаному за останнє десятиліття.

Агенти руйнують усе це. Робочий процес агента може розгалужуватися на десятки викликів моделі на одне завдання користувача, кожен із власними викликами інструментів, ізольованими обчисленнями, файловим введенням-виведенням та циклами повторних спроб. Хвостова затримка одного завдання тепер залежить від хвостової затримки кожного підвиклику. Сесії тривають хвилини або години замість секунд. Стан потрібно зберігати, відновлювати та збирати як сміття. Планування перестає нагадувати веб-сервер і починає нагадувати пакетну систему з накладеними реального часу обмеженнями.

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

Референсні архітектури для такого роду навантажень не є секретними. Примітиви Kubernetes вирішують чимало з них, а патерни в Google Cloud Architecture Framework охоплюють надійність та еластичність у масштабі. Але патерни гіперскейлерів припускають, що у вас є роки на їх впровадження. DeepSeek намагається адаптувати їх під навантаженням. Це завжди складніше, ніж greenfield-розробка, а виробничі інциденти, які я спостерігав під час саме такого роду міграцій, як правило, концентруються навколо стану сесій та виконання квот.

Хто постраждає

Почнемо з клієнтів API DeepSeek. Компанія вже скоригувала ціни на API, і переписування бекенду такого масштабу означає одне з двох: або ціни відображають реальну вартість обслуговування трафіку агентів, або ціни субсидіюють перебудову, за яку клієнти зрештою заплатять. Так чи інакше, команди, що побудували продукти на ендпоінтах DeepSeek, повинні розуміти: поверхня ціноутворення та SLA не є усталеною. Будь-хто, хто запускає фінтех або iGaming-бекенд поверх єдиного постачальника моделей, знає правила гри: ризик постачальника реальний, а переписування з 150 інженерами — провісник змін у API-контрактах.

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

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

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

Плейбук для інженерних команд

Конкретні дії для лідів платформ та CTO, які це читають:

По-перше, проведіть аудит припущень щодо навантаження агентів. Виміряйте реальну кількість викликів моделі на завдання користувача, а не демонстраційну цифру. Якщо ваше середнє завдання розгалужується до 20 викликів, ваша модель витрат на бекенд, ймовірно, помилкова на порядок величини. Переробіть планування потужностей відповідно до реального розгалуження.

По-друге, відв'яжіть свій продукт від семантики сесій єдиного постачальника. Якщо DeepSeek або будь-який інший постачальник змінить спосіб тарифікації або планування довготривалих сесій агентів під час переписування, ваш рівень абстракції повинен поглинути це без клієнтського інциденту. Тонкий, незалежний від постачальника клієнт не є гламурним, але це найдешевша страховка, яку ви коли-небудь напишете.

По-третє, поставтеся серйозно до ідемпотентності. Агенти повторюють спроби. Бекенди перезапускаються. Якщо ваші інтеграції з інструментами не є ідемпотентними, ви це виявите під час вікна переписування у когось іншого, о 3 ранку, коли буде зафіксований дублікат платежу або дублікат ставки. Виправте це до того, як постачальник зробить щось цікаве зі своєю політикою повторних спроб.

По-четверте, домовляйтеся зараз. Постачальники, що переписують основну інфраструктуру, найбільш сприйнятливі до корпоративних контрактів із реальними SLA саме в цей момент. Очікування, поки переписування завершиться, означає переговори з більш слабкої позиції проти більш впевненого постачальника.

По-п'яте, наймайте для вирішення тієї самої проблеми локально. Якщо ви запускаєте будь-яке значуще навантаження агентів власними силами, ті самі проблеми планувальника, стану та еластичності прийдуть і до вас. Найміть одного старшого інженера розподілених систем до того, як вам знадобляться три.

Ключові висновки

• Кампанія найму 150 інженерів у DeepSeek — це публічне визнання того, що навантаження агентів руйнує бекенди, розроблені для трафіку чат-ботів.
• Розгалуження агентів змінює форму навантаження зі stateless-запитів/відповідей на довготривалі, багатовикличні, stateful-сесії. Плейбуки автомасштабування веб-епохи цього не покривають.
• Нещодавнє коригування цін на API плюс масштабне переписування бекенду означає, що ціноутворення API та умови SLA слід вважати неусталеними для downstream-клієнтів.
• Кожна AI-лабораторія, що випускає агентів, стикається з тією самою фізикою. Мовчання конкурентів — це не запевнення.
• Команди платформ повинні провести аудит реального розгалуження агентів, забезпечити ідемпотентність та узгодити контракти з постачальниками до завершення переписування, а не після.