ИИ-агенту, который редактирует репозиторий, нужно место для выполнения команд и сохранения результатов между шагами. При обучении одновременно могут запускаться тысячи таких сред, а затем ждать, пока модель решит, что делать дальше. В техническом отчете от 19 сентября о DeepSeek Elastic Compute (DSec) описана система песочниц, которая, по словам авторов, обслуживает такую нагрузку.

Авторы описывают путь обработки запросов, хранение образов и то, что происходит при прерывании задания обучения. Показатели производительности и развертывания основаны на собственных измерениях авторов. Расширенная версия отчета размещена на arXiv; в аннотации сказано, что более ранний двухстраничный расширенный тезис прошел первый этап рассмотрения конференцией.

Главное изменение

  • Что изменилось: DeepSeek описала DSec как общую платформу для обучения и оценки ИИ-агентов: через одну внутреннюю клиентскую библиотеку доступны вызовы функций, контейнеры, микро-ВМ и полноценные виртуальные машины.
  • Почему это важно: В отчете обучение ИИ-агентов связывается с инфраструктурой, которая одновременно поддерживает работу множества сред для задач. Запросы проходят авторизацию, выбор узла и локальную проверку доступности; слои объединяются при создании среды, а данные образа загружаются по мере необходимости. Если задания на графических процессорах вытесняются, обучение может приостановить песочницы с сохранением состояния.
  • За чем следить: Вызывающая сторона по-прежнему выбирает серверную среду. Измерения рабочей нагрузки в промышленной эксплуатации охватывают контейнеры и микро-ВМ, у которых разные пути хранения и разные ресурсные издержки. Показатели масштаба относятся к одному узлу DSec.

Один запрос — четыре вида песочниц

Согласно отчету, обучающие и оценочные фреймворки DeepSeek и конвейеры обработки данных обращаются к Python-библиотеке под названием libdsec. Типичный запрос на создание среды выбирает серверную среду и артефакт окружения, задает ограничения на процессор и память, срок жизни и сетевые правила, а также передает начальный пользовательский контекст. Когда песочница готова, вызывающая сторона может запускать команды или вызовы инструментов, собирать вывод и возвращать статус, а затем завершить сеанс. В примере из отчета используется контейнер, лимит памяти, тайм-аут бездействия и сетевые правила, разрешающие PyPI и запрещающие NPM. Описан интерфейс, используемый внутри платформы DeepSeek, а не внешний способ доступа.

Четыре серверные среды предназначены для разных задач. FnCall выполняет короткие задания без сохранения состояния в повторно используемых предварительно созданных контейнерах, не запуская новую песочницу для каждого вызова. Контейнеры подходят для работы с репозиториями и общих инструментов: они быстро стартуют и позволяют плотно размещать задачи, но совместно используют ядро с другими контейнерами в виртуальной машине хоста. Микро-ВМ Firecracker обеспечивают границу виртуальной машины для задач, которым нужна более строгая изоляция, но требуют больше времени на запуск и памяти. Полноценные виртуальные машины подходят для операционных систем и графических задач, которым недоступны возможности более легких сред. Авторы сообщают, что на контейнеры и микро-ВМ приходится большая часть рабочих экземпляров и используемых ресурсов. Это описанные в отчете проектные решения, а не результаты сравнительного измерения безопасности.

За клиентской библиотекой DSec проверяет подлинность управляющего запроса, выбирает узел по периодически обновляемым сведениям о его состоянии и нагрузке и отправляет запрос службе edge службы контролируют локальную доступность ресурсов перед созданием песочницы; служба может отклонить размещение, выбранное на основе устаревших данных кластера. Работающие песочницы в контейнерах и виртуальных машинах используют прокси под названием aether и процессы сеанса командной оболочки под названием chronus служат для команд, файловых операций и потоковой передачи вывода. FnCall использует отдельный путь через предварительно созданный контейнер. Это различие важно: единая точка входа для клиента не устраняет различий в выполнении задач и обработке сбоев.

Среда без копирования целиком

В отчете выделены три части типичной среды для ИИ-агента: базовый образ, рабочая область задачи и инструментарий, которые могут меняться независимо друг от друга. Если включить каждую комбинацию в один образ, обновление инструментария потребует пересобирать множество образов. Вместо этого DSec объединяет слои только для чтения с верхним слоем для записи. В контейнерах измененная среда выполнения Docker объединяет эти слои с помощью overlayfs. В микро-ВМ используются слои EROFS только для чтения и диски для записи; если этого требует совместимость файловой системы, применяется другой путь блочного хранения.

По данным авторов, за одну неделю промышленной эксплуатации использовались 11 266 базовых образов контейнеров и 102 171 рабочая область контейнеров. Такое разнообразие снижает пользу от хранения полных образов на каждом узле. DSec хранит данные образов только для чтения в распределенной файловой системе DeepSeek 3FS, сохраняет записи локально и получает содержимое образа при обращении песочницы к нему. Метаданные образа контейнера копируются локально, чтобы обычный поиск по путям не требовал удаленных чтений. В пути для микро-ВМ применяются OverlayBD, ublk и локальный кэш для чтения блоков и инкрементных снимков.

В отдельной оценке на 10 узлах авторы запустили 8 192 контейнера в нагрузке оценки ИИ-агентов. Путь EROFS с загрузкой по запросу завершил задачи примерно за 35 минут против более чем 60 минут при предварительной загрузке всех образов из пустого кэша; вариант с полностью прогретым кэшем тоже завершил работу примерно за 35 минут. По отчету, при загрузке по запросу запись на диск составила около 700 ГБ на узел, а при предварительной загрузке — более 1 600 ГБ. Эти цифры сопоставляют конфигурации в тесте авторов. Они не доказывают, что такой же выигрыш будет с другой коллекцией образов или системой хранения.

Как поддерживать простаивающие сеансы и прерванные запуски

Песочница ИИ-агента может ждать между командами, сохраняя файлы, процессы и память. В недельной выборке авторов около 90% песочниц-контейнеров и микро-ВМ в среднем использовали не более 5% запрошенной ими мощности процессора. Поэтому DSec размещает множество активных сеансов на узлах, стараясь контролировать потери памяти и конкуренцию за ресурсы. Для микро-ВМ в отчете описано совместное использование кэша файлов только для чтения через virtio-pmem с DAX, а также освобождение неиспользуемых страниц гостевой системы с помощью DAMON и передачи сведений о свободных страницах через balloon. Кроме того, Linux позволяет отделять задачи, чувствительные к задержке, от задач с негарантированным приоритетом с помощью планировщика. В собственной оценке авторы отмечают пользу этих механизмов, а также компромиссы, например временный рост нагрузки на процессор при использовании virtio-pmem.

Прерывание обучения создает еще одну проблему: после вытеснения задания на GPU в запуске ИИ-агента может оставаться полезное состояние. По словам авторов, начиная с DeepSeek-V4.1 система DSec запускает цикл агента вне пула графических процессоров, задания с которых могут вытеснять: в контейнере рабочего процесса и песочнице агента. Задание обучения может повторно подключиться к этому состоянию. При паузе обучения фреймворк может запросить у DSec приостановить связанные песочницы и освободить память. Контейнеры замораживаются, а память возвращается; микро-ВМ сохраняют состояние выполнения в снимке, после чего завершается процесс Firecracker. Позднее песочницу можно возобновить. Это описание интеграции обучения в DeepSeek со слов авторов, а не общая гарантия восстановления после сбоев.

Что показывают — и чего не показывают — заявленные масштабы

По словам DeepSeek, один узел масштаба DSec включает почти 160 вычислительных узлов, около 30 000 ядер и примерно 250 ТБ оперативной памяти. Для этого узла компания сообщает примерно о трех миллионах экземпляров песочниц в обычный день, пиковом одновременном числе около 380 000 и скорости создания свыше 5 000 экземпляров в секунду. Это заявленные авторами производственные показатели одного узла масштаба, а не независимо проверенные итоги работы всего парка DeepSeek. Эксперименты по оценке из отчета проводились на отдельном кластере из 10 узлов.

В отчете также описаны границы отказоустойчивости. Авторы рассказывают, как агенты пытались искать ответы обходными путями, а обычные команды приводили к сбою ядра или заполняли хранилище выводом. В качестве мер снижения риска они описывают ограничения AppArmor для файлов и сокетов и сетевые правила для каждой песочницы, прямо отмечая, что эти средства не предотвращают все опасные действия. В отчете не указаны публичный адрес сервиса DSec, распространение внешнего SDK, условия доступа или цена. Он описывает устройство системы и условия авторских тестов, но не предоставляет внешнего доступа для запуска примеров кода.

Источники и дополнительная литература