DeepSeek expands elastic computing team, seeks senior engineers

DeepSeek's elastic compute team is hiring in large numbers, especially senior engineers. This time the recruitment did not publish job descriptions, but directly attached a technical share titled "DeepSeek Elastic Compute (DSec): Sandbox Infrastructure for Large-Scale Agent Training." According to reports, the team had just gone through a hiring round three weeks earlier.

The report did not give details such as the specific number of positions, job levels or salaries. Therefore, from public information one can only confirm the action itself—"hiring senior engineers in large numbers"—and cannot judge the specific scale of the gap.

Using a technical share as recruitment material itself conveys a signal: what the team needs are people who can understand and take over this infrastructure. And to understand this infrastructure, one must first understand how unusual the workload it faces is.

DSec is the sandbox infrastructure supporting all of DeepSeek-V4's training, evaluation and data preprocessing pipelines. According to reports, from DeepSeek-V3.2 all the way to V4.1, all sandbox workloads generated by Agent training, evaluation and data preprocessing have been running on DSec.

The workload it faces differs from ordinary cloud computing. During Agent training, the model needs to continuously enter real environments to execute tasks: read code, modify files, install dependencies, run tests, run services; each step changes the current environment, and the next round of interaction must continue from the previous state. Therefore sandboxes must be able to be created quickly and in large batches, yet cannot be destroyed and recreated at every single step.

DeepSeek summarized several obvious characteristics of this kind of workload: creation requests suddenly flood in; the CPU is idle most of the time, but to preserve files and processes, memory must be kept resident; different Agent tasks require very different execution environments, so the base image reuse rate is not high; and the training process may be interrupted because GPU resources are preempted.

DSec needs to simultaneously support four execution backends—FnCall, Container, MicroVM and Full VM—to cover different environment needs from short tasks to complete operating systems. FnCall suits short tasks such as online evaluation; Container mainly handles software engineering and tool calls; MicroVM provides stronger isolation; and Full VM provides a complete operating system, supporting GUI, graphics rendering and even Android applications.

According to the figures disclosed in the report, one DSec extended shard at DeepSeek has about 160 servers, 30,000 CPU cores and 250TB of memory, and must serve about 3 million sandboxes per day. At peak, more than 380,000 sandboxes are online simultaneously, and more than 5,000 can be created per second.

DeepSeek has already deployed multiple such shards in production, capable of supporting millions of sandboxes running simultaneously. Next, it wants to expand the number and variety of Agent runtime environments by hundreds to thousands of times.

These figures come from DeepSeek's own technical share and lack independent third-party verification. The specific timetable and implementation path for expanding by hundreds to thousands of times were also not disclosed in the report.

Scale pressure shows up directly in environment provisioning. Using production data from a certain week in 2026, DeepSeek found that the Container backend alone used 11,266 base images, 102,171 workspaces and hundreds of toolkits. Under the traditional approach, if every combination were made into a complete image, then a slight update to a code repository or toolkit could trigger the rebuild of a large batch of images.