DSec: Sandkassene bak DeepSeeks agenttrening

Når en KI-agent skal lære å løse oppgaver, holder det ikke alltid å produsere tekst. Den kan også måtte kalle et verktøy, kjøre kode eller arbeide i et operativsystem. Under forsterkningslæring gjentas slike oppgaveforløp i stort antall. DeepSeek Elastic Compute (DSec) er plattformen DeepSeek bruker til å opprette og styre kjøremiljøene – kalt sandkasser – som agentene trenger under trening og evaluering. 1

Ulike oppgaver krever ulike sandkasser

En kort funksjonskalloppgave trenger ikke samme miljø som en oppgave som krever en hel virtuell maskin. DSec tilbyr derfor fire kjøremåter gjennom én felles Python-SDK: FnCall for lette, funksjonslignende kall, containere for mer generelle arbeidsmiljøer, mikro-VM-er med en virtuell maskin som isolasjonsgrense og fullverdige VM-er når oppgaven krever det. Plattformen håndterer plassering og livsløp på tvers av maskinene som kjører sandkassene. 13

Isolasjon er også et sikkerhetstiltak. Koden og handlingene en agent utfører, kan ikke uten videre regnes som trygge. Omtaler av DSec-rapporten beskriver blant annet risiko for at agenter opptrer uønsket eller forsøker å manipulere miljøet eller resultatene. De fire kjøremåtene gir ulike former for isolasjon, men ingen enkelt sandkassemekanisme er en fullstendig sikkerhetsgaranti. 1910

Miljøene settes sammen ved oppstart

For å slippe å bygge et nytt, komplett systemavtrykk for hver kombinasjon av oppgave og verktøy, deler DSec miljøet i tre skrivebeskyttede EROFS-lag: et basisavtrykk, et arbeidsområde og en verktøypakke. Lagene versjoneres hver for seg og settes sammen med et skrivbart overlegg når sandkassen starter. Endres bare verktøypakken, trenger ikke alle komplette miljøkombinasjoner bygges på nytt. 111

Avtrykkene ligger i 3FS, DeepSeeks distribuerte filsystem. DSec kan klargjøre metadata lokalt og hente fildata først når sandkassen faktisk leser dem, i stedet for å kopiere hele avtrykket før oppstart. Løsningen er laget for å begrense overføringstid og behovet for lokal lagring når mange sandkasser starter samtidig. Rapporten beskriver også minnehåndtering og CPU-planlegging for å kjøre mange instanser tett. 111

Hva betyr skalaen i praksis?

DeepSeek beskriver én produksjonsenhet med rundt 160 CPU-noder, 30 000 kjerner og 250 TB arbeidsminne, samt lagring av systemavtrykk i petabyteklassen. For denne enheten oppgir selskapet omtrent 3 millioner sandkasseinstanser per dag, mer enn 380 000 samtidig på topp og en opprettingsrate på over 5 000 sandkasser i sekundet. Dette er tre ulike mål: Toppraten er ikke et uttrykk for hvor mange sandkasser som opprettes hvert sekund gjennom hele døgnet, og tallene for én enhet er ikke totaler for alle DSec-installasjoner. 1312

Flere omtaler av rapporten viser også til en enkelt treningsoppgave som ba om eller startet 32 000 sandkasser samtidig. Det illustrerer hvor brått etterspørselen fra én jobb kan øke, men dokumenterer ikke en fast øvre grense per jobb. 811

Fra V3.2 til V4.1 – også når GPU-treningen avbrytes

DeepSeek oppgir at DSec har håndtert sandkassearbeidet i selskapets forsterkningslæring og evaluering fra V3.2 til V4.1. I V4.1 beskrives langvarige agentforløp som kjører på DSec utenfor gruppen av GPU-maskiner som trener modellen og kan bli avbrutt for å frigjøre kapasitet. Hvis treningen på en slik maskin avbrytes, kan agentforløpet stanses midlertidig og flyttes bort med tilstanden bevart, slik at arbeidet senere kan fortsette. 13

DSec handler dermed ikke bare om å starte mange isolerte prosesser. Plattformen skal også kunne gi hver oppgave et passende miljø, levere det uten unødvendig kopiering og bevare fremdriften i langvarige agentforløp. Kapasitetstallene og driftsfordelene er DeepSeeks rapporterte resultater, ikke uavhengig dokumenterte garantier for andre installasjoner. 13