DeepSeek Elastic Compute (DSec)

DeepSeek Elastic Compute (DSec)arxiv.org

322 points•shenli3514•4 days ago•115 comments•

#compute #deepseek #elastic #dsec #deepseek elastic #elastic compute #deepseek elastic compute

115 comments

It seems every DeepSeek paper/patent has a huge number of authors, and this one is no exception. They couldn't even fit everyone on the page, there are 31 others not shown. This could be an asset protection strategy (i.e., human assets). Imagine if there were only 3 authors. Those authors may get hired away by competitors. If you list every employee on every paper then competitors don't know who to lure away.

sva_4 days ago

Compare to https://arxiv.org/abs/2407.21783

h8hawk4 days ago

and this: https://arxiv.org/abs/2503.19786

phytax4 days ago

Why is this the top comment? Many of the comments, as well as this one, have no relation to content and only mention a triviality

thatsabadlook4 days ago

Because if they get you to dismiss or not care about what nonAmerican AI companies are doing maybe people won't see that they are innovating in public. So they can continue smear campaigns that China is simply stealing everything and that's all they do. So the average person will be relieved when the govt moves to regulate away competition from us AI companies and labs. Horray

locknitpicker4 days ago

> Why is this the top comment? Many of the comments, as well as this one, have no relation to content and only mention a triviality

This is hardly a triviality. If you are interested in a topic and you find a paper interesting, more often than not you are interested in reaching out to the author.

If a paper features a list of authors that outnumber the paper's pages 10-to-1, it's a major red flag, and it's quite plausible and expectable that 99%of the names in that list had zero input and might even have zero contribution to give to the topic. I'd even argue it's a kin to academic fraud.

By the way, the same goes for those researchers who work on paper mills, and manage to rake in production metrics that go well beyond an article per day.

antonvs4 days ago

It’s top comment because it’s anti-Chinese.

altmanaltman4 days ago

Yeah what possible company can try to lure 100 people... Just for reference, Linkedin has 17,000+ full time employees.

ahurmazda4 days ago

Just look for the “corresponding author”

eru4 days ago

The unfortunate intern who had to upload to arxiv?

anvuong4 days ago

Lmao with the conspiracy. Large scale experimental research is always like this, many papers in experimental physics have pages of authors.

samayashar4 days ago

As models get better, safe-and-secure sandboxes/environments are going to be the way forward. With the recent rise in cases where models can somehow gain access to the internet and blast past the sandbox, it's very important to have all the resources contained within the sandbox with no access to the outside world.

DSec is a good step in this direction!

vblanco4 days ago

380.000 concurrent sandboxes on 160 Epyc based server nodes. Crazy stuff

dangoodmanUT4 days ago

that's only 12 sandboxes per core

aabhay4 days ago

Um, how is that not impressive

peter_d_sherman4 days ago

>"Within one scale unit, the platform spans nearly 160 CPU nodes with 30K cores and ∼250 TB of DRAM. It manages petabytes of layers and images. On a typical day, a single scale unit serves about 3 M sandbox instances, with peak concurrency reaching ∼380K and a creation rate exceeding 5,000 instances per second."

Impressive numbers!

Whoever would have thought (in prior years) that in 2026 AI Agents (not people or corporations, at least not directly) seem to be (or seem to be rapidly becoming) the biggest consumers of cloud computing resources...

Anyway, a very interesting paper and environment!

piterrro4 days ago

12 sandboxes per code is insane, I wonder how many of these sandboxes are idle at a time. Depending on the tasks assigned the resource requirements are different. Compare an agent doing pdf conversion and one responding to a simple question. One is cpu bound the other is mostly network wait.

This is an interesting problem from infra perspective since you cannot predict the workload. On a bigger scale you may get away with forecasts.

Im waiting for tech that elastically allocates cpu/mem without restarting a container.

Read the full thread on Hacker News →

115 comments

Related stories