9月24日，美国科技媒体The Information报道称，DeepSeek年度经常性收入（ARR）已经达到10亿美元（约合67亿元人民币），较几个月前不足5亿美元的水平翻了一倍以上。目前，该公司正推进第二轮融资，计划在10月底前完成，募资500亿元人民币，目标估值达5000亿元人民币。
而就在23日，DeepSeek在预印本平台arXiv发万字论文，详细介绍了一套专门服务于人工智能（AI）智能体训练、评估和环境构建的“基础设施”，有望让AI智能体“干活”更高效，同时降低其在执行任务过程中“钻空子”的风险。
论文题为《DeepSeek弹性计算（DSec）：面向大规模智能体训练的沙箱基础设施》，由包括DeepSeek创始人梁文锋在内的130名作者共同撰写，详细介绍了“DeepSeek弹性计算”（DeepSeek Elastic Compute，DSec）平台。
DeepSeek论文
随着大模型从“回答问题”逐渐转向自主执行任务，AI智能体需要的不再只是一个聊天窗口，而是一个能够让它读取代码、调用工具、运行命令、修改文件、启动服务甚至操作浏览器的真实运行环境。
DeepSeek表示，在强化学习（RL）训练中，模型会不断与这些隔离的运行环境互动：智能体执行任务后获得反馈，系统根据程序退出状态、运行结果、测试通过率等指标计算奖励，再利用这些数据更新模型。随后，新的模型继续进入环境执行任务，如此循环。
因此，大规模智能体训练实际上需要同时运行海量沙箱，而且这些沙箱还必须在长时间交互中保持状态。一次任务可能需要模型连续操作几十分钟甚至更长时间，期间安装的软件、修改的文件、启动的服务都不能因为模型暂时没有发出指令就消失。
论文称，单个任务最多可能需要3.2万个沙箱，因此运行平台必须能同时接受和部署大量沙箱，这种突发性使横向扩展成为系统级要求，并且需要共享服务来避免集中式瓶颈。
针对这一需求，DeepSeek设计了DSec。
据介绍，与传统计算方式相比，DSec能够更加灵活地调配计算资源：AI智能体处于活跃状态、实际执行任务时，系统才会向其分配更多算力；当智能体处于等待下一步指令的状态时，则不会持续占用大量计算资源。
按照DeepSeek的估算，约90%的沙箱实际使用的中央处理器（CPU）资源不超过其申请容量的5%。这意味着，通过动态调配算力，可以减少大量计算资源在智能体“等待”期间被闲置的情况。
论文表示，一个生产规模的DSec单元约由160个CPU节点组成，每天可以运行约300万个沙箱，最高同时运行约38万个沙箱，并能维持每秒超过5000个沙箱的创建速度。DeepSeek强调，DSec并非简单地在容器上套一层软件，而是一套完整的生产级执行平台。
DSec还与DeepSeek的强化学习训练框架进行了深度协同。
传统方式下，AI智能体的执行过程往往和GPU训练任务绑定在一起。但GPU集群为了提高利用率，会不断进行任务抢占。如果GPU训练任务被中断，智能体可能已经在沙箱中执行了很长时间，却因为训练进程消失而被迫重新恢复。
DeepSeek此前需要通过记录命令日志来恢复智能体状态，避免重新执行已经完成的操作。
从DeepSeek-V4.1开始，该公司将智能体运行过程迁移到DSec中，并把智能体沙箱与管理沙箱的工作容器放到不会被GPU训练任务抢占的环境里。
这样一来，即使GPU训练任务被中断，智能体自身的执行状态和沙箱状态仍然能够保留。训练任务恢复后，可以直接重新连接并继续执行，不必依靠命令日志重新“回放”之前的操作。
不过，相比于如何让AI“干得更快”，论文还提到了一个当下引发广泛关注的问题——如何让AI智能体在完成任务时更可靠？
近段时间以来，前沿AI智能体突破沙箱限制、攻击网站等异常行为不断被爆出，引发业界对于智能体安全性的担忧。
DeepSeek在实际训练和评估中也发现，AI智能体并不总是按照设计者预想的方式完成任务。例如，有智能体会搜索平台管理的文件和通信渠道，试图找到隐藏的标准答案；有智能体尝试直接向chronus通信套接字发送伪造请求，冒充用户获取信息；还有智能体查看chronus日志，从中寻找可能泄露的答案……
更棘手的是，一些问题甚至并非智能体有意“作恶”所致。论文举例称，有一次，本应发送给另一台目标虚拟机的攻击指令却被错误地执行在智能体自己的容器中，导致内核崩溃。
因此，DeepSeek在DSec中加入了更细致的访问控制机制，例如利用AppArmor限制智能体读取特定文件、日志以及通信套接字，并通过基于eBPF的网络规则，为不同任务设置不同的联网权限。
不过，DeepSeek强调，没有任何单一机制能够阻止所有智能体异常行为和系统故障。该公司认为，随着AI模型能力不断提升，平台需要持续加强可观测性，通过监测发现新的问题，再进一步强化安全机制。
成为付费用户可以阅读 深度求索 所有资料
了解更多 →