에이전트형 LLM을 대규모로 학습·평가하려면 모델이 저장소를 들여다보고, 도구를 호출하고, 명령을 실행하고, 과제별 서비스와 상호작용할 수 있는 격리된 실행 환경이 필요하다. 문제는 이 워크로드의 성격이 일반적인 서버 애플리케이션과 다르다는 점이다. 샌드박스는 한꺼번에 폭발적으로 생성되고, 요구되는 기능과 격리 수준이 제각각이며, 긴 상호작용 동안 상태를 유지해야 하고, 방대한 이미지 저장소에서 데이터를 끌어오지만 정작 재사용률은 낮다. 딥시크는 이런 특성 때문에 단일 샌드박스 런타임 하나로는 감당할 수 없고 탄력적인 실행 플랫폼이 필요하다고 보고, 그 결과물로 DeepSeek Elastic Compute(DSec)를 기술 보고서 형태로 공개했다.
하나의 SDK, 네 가지 격리 백엔드
DSec의 핵심 설계는 격리 강도가 다른 여러 실행 백엔드를 하나의 통합 SDK 아래로 묶은 것이다. 가장 가벼운 함수 호출(FnCall) 방식부터 컨테이너, microVM, 그리고 완전한 가상머신(full-VM)까지 네 가지 형태를 같은 인터페이스로 다룰 수 있다. 이는 실무적으로 의미가 크다. 단순한 코드 실행에는 오버헤드가 낮은 백엔드를, 커널 수준 격리가 필요한 위험한 작업에는 microVM이나 full-VM을 붙이는 식으로, 과제의 신뢰 수준과 성능 요구에 맞춰 격리 비용을 조절할 수 있기 때문이다. 환경 자체도 독립적으로 버전이 매겨진 레이어들을 조합해 구성하도록 해서, 공통 기반 위에 과제별 차이만 얹는 방식으로 중복을 줄인다.
밀도를 끌어올리는 자원 관리
대량의 샌드박스를 한정된 노드에 욱여넣으려면 자원을 얼마나 촘촘하게 나눠 쓰느냐가 관건이다. DSec는 메모리 공유와 회수, CPU 스케줄링을 결합해 고밀도 실행을 노린다. 특히 이미지 데이터를 노드마다 미리 복제해 두는 대신, 클러스터 전역 분산 파일시스템인 3FS(Fire-Flyer File System)에서 필요할 때 온디맨드로 로드한다. 앞서 언급한 '낮은 재사용률·거대한 이미지 저장소'라는 조건에서, 이미지 배포 오버헤드는 곧 실행 지연으로 직결되는데 이를 분산 파일시스템으로 흡수하겠다는 접근이다. 딥시크는 이러한 기법들이 환경 설정과 이미지 배포 비용을 줄이고 메모리 효율을 높이면서, 고밀도 오버커밋 상황에서도 지연에 민감한 성능을 유지했다고 밝혔다.
강화학습 프레임워크와의 공동 설계
DSec가 단순 샌드박스 서비스와 구분되는 지점은 강화학습(RL) 프레임워크와 함께 설계됐다는 데 있다. 에이전트가 환경과 상호작용하며 데이터를 만들어내는 롤아웃(rollout)은 상태를 유지해야 하는 반면, GPU 학습 자원은 선점(preempt)될 수 있다. DSec는 상태를 가진 롤아웃 실행을 선점 가능한 GPU 학습과 분리하고, 샌드박스 수명주기를 학습과 맞물려 조율한다. 덕분에 유휴 자원은 회수하면서도 진행 중인 롤아웃의 상태는 보존할 수 있다. 여기에 더해 보상 해킹(reward hacking)처럼 에이전트가 과제의 허점을 파고드는 오작동을 완화하는 장치도 포함했다고 설명한다. 실행 인프라 층위에서 에이전트의 부정행위를 억제하려 했다는 점은 눈여겨볼 만하다.
운영 규모를 보면 이 플랫폼이 실험적 프로토타입이 아니라는 점이 드러난다. 프로덕션 기준 단일 유닛은 약 160개 노드로 구성되며 하루 약 300만 개의 샌드박스를 처리한다. 동시에 38만 개 이상의 샌드박스가 살아 있고, 초당 5,000개 이상의 생성 요청을 지속적으로 소화한다. 이 숫자들은 격리·상태 유지·폭발적 생성이라는 상충하는 요구를 실제 규모에서 동시에 만족시켜야 했음을 보여준다.
다만 공개된 것은 상세 논문이 아니라 기술 보고서 수준의 설명이라는 한계가 있다. 백엔드 선택 기준, 오버커밋 시의 성능 저하 임계점, 3FS 온디맨드 로딩의 콜드 스타트 특성 같은 세부 수치는 드러나 있지 않다. 또한 DSec는 3FS와 자체 RL 프레임워크에 깊이 결합돼 있어, 이 스택 없이 아이디어만 떼어 재현하기는 쉽지 않다. 그럼에도 한국의 IT 실무자에게 주는 시사점은 분명하다. 에이전트 학습·평가 인프라를 설계할 때 '샌드박스 런타임 하나'가 아니라 격리 수준을 선택 가능한 실행 플랫폼, 학습 자원과 분리된 상태 관리, 그리고 이미지 배포를 위한 분산 스토리지가 함께 고려돼야 한다는 점이다. 에이전트 워크로드가 커질수록 모델 자체보다 이런 실행 인프라가 병목이 될 수 있다는 신호이기도 하다.