DeepSeek弹性计算（DSec）：面向大规模高效智能体训练的沙箱基础设施（中文机翻）

、唐洪轩、陈景昌、、陈、、、周、、、王佳瑞、林圣凯、张楚琦、李远哲、郭炼、傅哲夫、高文军、王一松、梁昭、王泽浩、谢子伟、郭永强、裴新聪、高子义、俞水平、徐汉伟、吴作凡、智、邱、、沙、、钟、吴永通、、、徐、、杜秋实、黄玉珍、马世荣、王耀辉、陈明淑、熊同瑞、阎永春、罗浩文、梁浩芬、张晓康、曾伟浩、徐润新、王培义、朱金华、张若愚、杨文凯、唐琦、余继平、田烨、潘瑞哲、丁洪辉、刘晓东、罗凌霄、邵志红、吴玉涵、吕继白、刘文童建安、吴恒旭、、、白玉卓、、徐、、王永智、、、魏海阳、沈海阳、张成源、赵进、张子立、杨瑞红、徐新波、周建东、朱瑞东、郭宇哲、潘泽伦、聂绍恒、李二航、林书瀚、刘政、陈安硕、吕子龙、曹思诺、芮宇、王楚昊、郭俊义、宋俊晓、陈凯锋、叶梦浩、李俊贤刘世春、使用大型语言模型(LLM)的大规模代理培训和评估依赖于隔离的、有状态的执行环境，在该环境中，模型检查存储库、调用工具、执行命令并与特定于任务的服务进行交互。这些工作负载在大规模突发中创建沙箱，跨越异构功能和隔离要求，在长时间交互中保持状态，并从大型图像库中提取有限的重用。因此，支持它们需要一个弹该报告介绍了DeepSeek弹性计算(DSec)，这是一个生产沙盒平台，通过统一的SDK公开FnCall、container、microVM和全虚拟机沙盒后端。DSec协调整个集群的放置和生命周期管理，由独立版本层组成环境，结合内存共享、回收和CPU调度以实现高密度执行，并根据需要从Fire-Flyer文件系统(3FS)加载映像数据，这是一个集群范围的分布式文件系统。DSec与强化学习(RL)框架共同设计，将有状态部署执行与可抢占的GPU训练分离，协调沙盒生命周期与训练，以保留部署状态，同时回收闲置资源，并减轻代理的DSec的单个生产规模单位跨越大约160个节点，每天服务大约300万个砂箱；在生产中，它支持超过380，000个并发沙盒，每秒钟支持超过5，000个沙盒创建。我们的评估和部署经验表明，这些机制减少了环境设置和映像分发开销，提高了内存效率，并在高密度过量使用的情况下保持了延迟敏感的性能。黄家良是张明星指导的博士生。他在张的指导下在Dee2前沿LLM的最新进展使得代理工作流变得实用并被广泛采用(Guoetal.,2025；Jimenezetal.,2024；OpenAIetal.,2024).代理模型不是产生单个文本答案，而是与执行环境交互:它可以导航代码库、调用工具、执行命令、检查故障和修改文件，或者通过计算机使用任务中的图形界面来操作浏览器和桌面应用程序(Xieetal.,2024；Zhouetal.,2024).在这些工作负载中，模型根据反馈进行迭代，直到任务得到解决。这种执行模型导致了代理工具和编排工具的生态系统的增长，例如DeepSeek工具(DSH)(Shietal.,2以及多代理培训装具。训练可靠的代理需要大规模的强化学习(RL),其中模型通过与真实、隔离的执行环境的交互来学习，而不仅仅是从静代理培训渠道包括环境和数据构建、RL推广、奖励计算、政策更新和定期评估。在这些阶段中，RL展示和评估对沙盒平台施加了最高的压力，因为它们是大规模的、并发的，并且与训练循环紧密耦合。在RL(Guoetal.,2025；Ouyangetal.,2022)，培训是一个反馈循环，分为三个阶段。首先，在部署期间，当前模型与沙盒环境交互:它读取文件、发出工具调用、执行命令、观察输出，并为每个任务生成轨迹。第二，在奖励计算期间，框架使用本机执行信号(如退出代码、标准输出、测试通过率或特定任务验证器)对轨迹进行评分。第三，在策略更新期间，RL算法根据收集的轨迹和奖励更新模型参数。定期评估遵循类似的执行路径，除了产生的轨迹用于测量模型能力而不是更新参数。最近的系统通过异步推出进一步进行流水线生成和策略优化，连续补充完成的样本以保持高并发性并减轻长尾落后者(DeepSeek-AI,2026).对于代理工作负载，这种设计使许多有状态沙盒会话保持运行，并可能在策略更新或调度程序抢占时中断和恢复它们的相关部署，从而进一步增加平台的并发性、生命周期管理和状态一致性要对于每个部署或评估任务，平台必须具体化一个独立的特定于任务的环境，包括它的存储库、依赖项、服务、评估脚本和编码工具。环境必须足够接近真实的机器，以运行未修改的软件栈、包管理器、构建工具、浏览器、仿真器和特定于任务的服务。因此，健壮、高吞吐量的代理沙盒工作负载有几个影响平台设计的属性:(1)展示和评估作业以突发方式创建沙盒。单个作业可能会请求多达32K个沙箱实例，因此平台必须同时接受和放置许多沙箱。这种激增使得水平可伸缩性成为系统范围的要求，并需(2)沙盒必须以高密度运行。在代理交互期间，沙箱通常会等待LLM生成下一个动作，因此CPU使用率很低，自然适合过量使用。卷或3，200个容器，但前提是平台可以安全地过量使用资源，并在节点规模上管理生命周期3(3)代理沙箱是有状态的，并且是长期存在的。该模型可以修改文件、安装依赖项和启动服务，并且以后的工具调用依赖于这种累积的状态。由于沙箱可以在许多LLM交互回合中保持活动状态，所以内存占用、访客页面缓存、主机页面缓存和可写状态可能会在CPU空闲很长时间后保持固定。在高密度过量使用的情况下，这些驻留成本直接限制了集群容量，因此内存共(4)代理工作负载是高度异构的。该平台必须涵盖类似OJ的脚本执行、完整存储库上的软件工程任务、安全任务、计算机使用工作负载、移动开发环境(例如Android)和其他全系统环境。这些工作负载在CPU和内存需求、依赖性、所需的系统功能和隔离强度方面有很大不同。单一的沙盒抽象无法有效地涵盖所有这些。例如，轻量级函数调用更适合简短的无状态任务，而虚拟机(VM)更适合需要完整的商业现成操作系统的工作负载。(5)即使在相同的工作负载类别中，环境差异也很大。训练和评估语料库包含许多任务，并且每个任务可能需要其自己的储存库、依赖版本、服务、工具包、评估脚本或VM快照。因此，该平台必须为大量不同的图像和环境工件提供服务，其中许多图像和环境工件的重用是有限的。在突发启动的情况下，从注册表获取这些不同的任务映像会将负载集中在分发路径上，增加启动延迟，并引入干扰已经运行的沙箱的额外I/O。在我们的消融中，热切的图像拉扯延伸完成时间缩短1.7倍，而按需加载将累积磁盘写入减少57%。或者干扰系统组件，潜在地破坏部署或其他协同定位的工作负载。因此，该平台需要细粒度的访问(7)代理执行是可中断的。当长期运行的部署仍这些属性定义了代理沙盒平台的角色。DSec提供了弹性服务扩展、高密度资源管理、内存共享和回收、针对不同工作负载类别的多种隔离机制、可扩展的映像分布，以及与针对抢占式本报告的其余部分介绍了从平台抽象到实施和评估的DSec。§2从用户角度介绍DSec，包了与RL框架的协同设计，用于环境构建、2.DSec概述本章介绍面向用户的DSec视图。从平台的角度来看，用户是培训框架、评估框架和数据构建管道4代表研究人员的软件开发工具包(SDK);在整个报告中，我们将他们统称为用户。它涵盖了SDK入口点、平台公开的沙盒后端及其服务的工作负载类别、沙盒会话的生命周期以及生产部署的运营规模。用户通过libdsec访问DSec，libdsec是沙盒服务的Python客户端库。libdsec为用户提供了一个统一的SDK入口点来创建和操作沙箱，同时仍然要求他们选择适合该任务的沙箱后端。典型的请求指定沙箱类型、映像或环境标识符、CPU和内存限制、生存期设置、网络规则和初始用户上下文。创建后，用户可以执行shell命令或工具调用，并收集命令输出和返回状态。List.1展示了一个最小的容器会话:客户机连接到服务端点，请求一个带有所需资源和网络策略的沙箱，运行一个命令，然后释放它。清单1|通过libdsec的最小沙盒会话。client=DSecClient()awaitclient.open()args=DSecContainerRunArgs(container_image="registry.../sphinx-9658:官方”，memory_limit_mb=4096，cpu_cores_limit=4，ttl_running_stop=300，#空闲超时network_rules={"npm":False，"pypi":True}，init_user="root"，)sandbox=awaitclient.run_container(args，timeout=120)result=awaitsandbox.run_shell("echohelloworld")awaitsandbox.stop()在本例中，网络规则允许访问PyPI(pypi=True)，但拒绝访问NPM(npm=False)。中详细讨论了这种细粒度的网络控制§6。这个接口不是所有后端的完整语义抽象。函数调用、容器、微虚拟机和完整虚拟机具有不同的启动成本、隔离边界、文件系统语义和操作系统功能。libdsec提供了统一的访问路径和类似的操作模型，但是调用者仍然负责选择与工作负载相匹配的后端。沙箱运行时面临一个基本的压力:更强的隔离和更完整的系统功能通常伴随着更高的启动延迟和资源开销。因为没有一个沙盒抽象适合所有的代理任务，所以DSec支持跨越这个权衡空间的多个后端。Tab.1总结了它们的典型适合度。FnCall的目标是简短的无状态任务，如OJ工作负载、代码编译和实用程序代码。FnCall任务在可重用的预先创建的CPU或GPU容器中运行，避免了每次调用的配置开销。对于GPU工作负载，FnCall支持(I)共享模式，其中多个容器共享一个GPU实例，最大限度地提高轻量级工作负载的利用率，以及期中为性能敏感的任务保留一个GPU实例(例如，操作员评估)。容器是软件工程和一般工具使用工作负载的主要后端。它们提供快速启动和高封装密度，并且运行大多数存储库级任务使用5FnCall微真空完整虚拟机运行时性能●0•0●00依赖性足迹000000完整的操作系统功能000●00000●00类似OJ的任务GPU内核执行瑞典工具使用电脑使用COTS操作系统制图法更多●=更高的需求。始终适用于安全敏感的任务。鞭炮微卷(Agacheetal.,2020)提供更强的隔离边界，同时保持Linux兼容性。它们对于安全性敏感的任务、更强的租户隔离以及需要具有Linux兼容性的虚拟机边界的工作负载非常有用。这带来了比容器更高的内存开销和更慢的启动速度。完整的虚拟机后端涵盖需要完整的商业现成操作系统环境的工作负载，例如通过QEMU(Bellard,2005)，以及那些需要GUI或图形渲染的应用程序。这些后端具有最高的资源开销，但是对于依赖于特定于操作系统的API、移动运行时行为或全系统执行的任务来说，它们是必需的。在生产中，容器和微卷控制着实例数量和资源消耗。FnCall通过一小组驻留环境为大量轻尽管内部支持的后端各不相同，但用户看到的是一个统一的高级生命周期。首先，调用者通过选择后端并指定环境工件、资源限制、生命周期策略和网络策略来创建沙箱。环境工件因后端和工作负载而异。对于容器和微卷，它是一个基础映像，以及特定于任务的工作区和工具包层，平台将它们组成运行环境。对于完整的虚拟机工作负载，它是一个准备好的虚拟机映像或快照。对于FnCall，它是一个任务规范，包含任务类型、依赖文件以及要运行的代码或脚本。这些工件成为本报告后面讨论的环境组成和图像分布机制的基础。第二，平台准备环境，使之为交互做好准备。第三，用户发布命令或工具调用，观察输出，并运行特定于任务的检查或测试。沙箱在其整个生命周期中都是有状态的:文件编辑、已安装的依赖项和已启动的服务在调用之间保持不变，因此后面的命令会观察前面命令的效果。由于沙盒在许多交互回合中保持活动状态，而其CPU通常在这些回合之间处于空闲状态，因此它的驻留状态在最后一个命令后很久仍保持固定，这是一个高密度挑战，其特征在于§4。最后，一旦沙盒的生存时间结束，沙DSec部署在共享3FS(DeepSeek-AI)用于基础映像和工作区存储的分布式文件系统部署。在一个规模单位内，该平台跨越近160个CPU节点，具有30K个内核和250TBDRAM。它管理数Pb的6图层和图像。在一个典型的日子里，单个规模单元服务大约300万个沙盒实例，峰值并发达到这些数字对于理解报告的其余部分很重要。DSec不是一个单一的沙盒运行时，也不是一个容器的包装器。它是一个生产执行平台，必须结合面向用户的沙盒抽象、后端特定的运行时、可扩展的映像存储、高密度资源管理和培训框架集成。storage,台，并描述一个请求如何从SDK传递到一个正在运行的沙箱，以及它通过哪些组件。我们从集群级服务和沙箱运行时的角度来描述这个架构。集群级服务提供请求入口、身份和访问管理、沙箱放置以及集群健康和负载视图。沙盒运行时处理节点本地准入、沙盒创建、执行和资源回用于沙盒的统一PythonSDK际机械师协会图1|DSec架构。每个代理协调容器或VM沙箱与平台其余部分之间的通信。FnCall遵循单独的执行路径，并且不使用此代理。在高层次上，沙箱创建请求首先被发送到IAM进行身份验证和授权。一旦获得授权，请求将被发送到放置引擎，放置引擎将使用观察器收集的健康和负载信息来选择目标节点。放置之后，apiserver将请求转发到该节点上的边缘。然后，edge检查本地容量，如果容量允许，使用请求的后端创建沙箱，并拒绝请求7取。Container、microVM和fullVM沙箱运行每个沙箱的代理(aether)和一个或多个用于命令执行、文件系统访问和其他运行时操作的chronus实例。其中一个沙箱运行后，它的操作通过apiserver、edge、aether和chronus进行路由。相比之下，FnCall既不使用aether也不使用chronus，而是遵循一个单独的请求路径:提交的任务直接在预先创建的容器中执行，然后尽最大努力清理任务状态。集群级服务管理对平台的访问，并跨计算节点协调沙盒请求。它们包括IAM、apiserver、布局引擎和观察器。我是。身份和访问管理(IAM)对调用者进行身份验证，并将所有管理请求授权给DSec。例如，创建或删除沙箱或更改用户的资源或并发限制的请求必须在执行前通过IAM检查。主体是与管理请求相关联的用户或服务身份。IAM使用项目来定义资源管理和访问控制的范围。在一个项目中，访问策略指定哪些主体可以对其资源执行哪些管理操作，而资我们支持多级项目嵌套，而不是云平台中常见的平面或两级层次结构。包括代理和线束在内的授权主体可以创建子项目，委托父配额的一部分，并在其中授予管理权限。委托受父级的约束:主体不能授予它不拥有的权限，子项目策略和配额不能超出父级的访问控制或资源限libdsec，而沙箱执行不受信任的模型生成的代码，并可能访问外部网络。因此，两端是网络通过这个入口。apiserver不维护每个沙箱的状态。它定期刷新来自观察器的边节点集，同时放置引擎。放置引擎为每个新沙箱选择一个主节点。布局分两个阶段进行:过滤和排序。过滤阶段仅保留提供请求所需的后端和硬件功能的健康节点。例如，对支持GPU的沙箱的请求仅限观察者。布局引擎的决定只取决于观察者提供的舰队视图。观察器定期探测每个边缘和主机的健康状况，并收集与调度相关的状态，例如跨后端类型运行的沙箱数量，按边缘、用户和任务8在通过再次轮询边缘重新启动之后。这使得放置引擎和观察器实例易于添加或替换，而无需昂沙箱运行时创建和操作单个沙箱，并管理它们的资源。它包括edge、aether和chronus，并依边缘。每个节点运行一个edge，这是一个基于机器的组件，处理来自apiserver的容器、microVM、基于QEMU的完整VM和FnCall后端的创建请求。在接受创建请求之前，边缘检查节点的当前容量，如果容量不足，则拒绝该请求。这种节点本地准入检查补充了放置引擎的放置决策，其基于周期性刷新的集群状态。在创建过程中，edge提供存储，应用基于eBPF的FnCall和容器在QEMU/libvirt虚拟机内部运行，而不是直接在主机上运行。VM提供了一个独立的内核和网络堆栈，并作为不受信任的容器和裸机之间的附加安全边界。为了更好地支持图形密集型工作负载，如计算机使用的GUI应用程序、浏览器、视频游戏和3D渲染，我们利用了主机虚拟机管理程序的准虚拟化GPU接口(例如virtio-gpu)。在完整的虚拟机中，我们既支持图形API与主机操作系统本机兼容的工作负载，也支持渲染堆栈可以通过兼容层(如DXVK(DXVK,2018).除了跟踪沙盒的生命周期，edge还会协调磁盘和内存快照，并在沙盒停止或TTL到期时释乙醚。容器和虚拟机沙箱运行aether，这是一个跨平台的代理，它与edge建立通信通道。这个edge-to-aether通道使用特定于平台的传输，例如用于Linux容器的Unix域套接字或用于VM后端的vsock。edge通过通道监控沙箱健康，如果通道关闭，则将沙箱标记为失败。对于每个操作，aether使用操作的终端会话标识符来创建或定位相应的chronus实例，然后通过本地通道转发操作。当会话结束时，aether终止相应的chronus进程树。克洛诺斯。chronus在沙箱中提供了一个shell-session抽象，每个实例代表一个独立的shell会话。它为命令执行、文件系统操作、HTTP请求和流I/O提供了跨平台接口。多个容器图像从OCI离线转换到EROFS，EROFS将元数据与数据分开，以便元数据保留在本地，而图像数据保留在3FS。微磁盘映像使用覆盖磁盘(Lietal.,2020)在同一存储器上格式化。总之，这些图像格式支持按需加载和共享基础上的增量快照，允许edge启动沙盒，而无需首先§5.3描述相应的按需加载机制。9DSec使用云虚拟机来吸收沙盒需求中的瞬时峰值，同时在内部提供稳态工作负载。当本地利用率超过80%时，放置引擎会将一部分符合条件的传入沙箱创建请求卸载到云虚拟机。我们没有将托管容器服务与对象存储相结合，而是在云虚拟机上重用本地容器运行时和基于EROFS的映像加载路径。EROFS映像驻留在云托管的分布式文件系统中，由云虚拟机装载。生产文件访问跟踪显示，一个总容量为30TB的经过重复数据消除的紧凑EROFS映像集涵盖了70%的容器任务所访问的映像文件。我们将这个共享映像集离线同步到云文件系统。其映像依赖关系完全包含在该集合中的容器任务被分类为符合云的。其他任务保留在内部。在生产中，一个规模单位中的200个云虚拟机吸收了30%的峰值溢出，从而在不过度调配本地集群的情况下增加了容量。without本章描述了DSec服务的生产工作负载以及随之而来的平台挑战。我们只报告了容器和微卷的度量，它们共同构成了生产中大多数沙盒实例和资源消耗。测量结果显示了一个对于传统执行服务来说不同寻常的组合:请求以大规模爆发的方式到达，每个沙箱在扩展的交互中保留状态，即使许多沙箱都是活动的，CPU需求也很少，并且环境工作集对于节点本地图像缓存来说太多样化了。我们在这里将每个工作负载属性与它的系统结果联系起来，并将相应的机制推迟展示和评估任务成批创建沙盒，而不是以稳定的速度创建。Fig.2显示一个典型的容器任务已经创建了几千个沙箱，尾部达到几万个。最大的生产作业可以请请求会在很短的时间内到达，因为在实例的环境准备好之前，训练或评估批不能使用实例。因此，布局、沙盒创建和环境设置必须吸收急剧的爆发，而任何阶段的落后者都会延迟有用的模用试验图3|具有设置、工具调用和测试阶段的代表性沙盒执行。设置后CPU需求是间歇性的，而内存占用和累积状态持续存在。创建后，沙盒将经历三个主要阶段，如Fig.3。设置阶段准备任务依赖关系、工具和初始化状态。在工具调用阶段，模型在输出生成和沙盒操作之间交替，产生由沙盒等待下一个动作的时间段分隔的短暂CPU突发。测试阶段验证结果，并可以再次短暂增加资源需求。这些阶段没有固定的持续时间，但它们不同的资源配置文件很重要:设置成本乘以突发大小，而后面的阶段保留沙盒状态，尽管CPU活动时断时续。第一个挑战是由独立发展的软件组件组成每个沙箱所驱动的昂贵的设置阶段。沙箱的内容可以分解为三个部分:提供操作系统级依赖关系的基础映像(例如，Ubuntu、Python3.10或Java8环境)、承载任务的代码库及其特定于任务的依赖关系的工作空间，以及一个或多个频繁更新的工具包(例如，DeepSeek工具)。在一个生产周中，容器后端服务了11，266个基本映像和102，171个工作区，而microVM后端使用了两个共享基本映像和53，590个特定于任务的工作区。该平台还支持103个工具包，67.8%的沙箱除了基本映像之外还需要至少一个工作区或工容器–微真空2ContainerInitiative,2026)镜像造成了组合维护负担。如果平台维护M基本映像、N工作区和k工具包，升级m基本映像可能需要重建其工作区组合，费用为),而当工具包与工作区组合时，升级k工具包的费用为)。Fig.4a给出一个具体的例子:升级ToolkitT1会强制降低o(m相应的维护成本)工作空间W1工作空间W2…WX工作区工具包T1工具包T1工具包T1(a)单片图像。B1B2…BMW1W2…WN工作空间W1工具包T1被重建，即使其基础图像和工作空间不变。(b)对于独立版本化的可组合层，只有T1层被更和o(k)通过独立地对这三个组件进行版本控制和分发。一个简单的替代方法是将工作区和工具包作为压缩的归档文每个沙箱中。然而，集中在一个突发上，这种重复的工作会驱动大量的CPU和I/O开销，并可能导致沙盒启动超时。另一种方法是将每个工作空间或工具包作为只读目录保存在主机上，并合并到沙箱的现有目录树中，而不隐藏下面的内容。严格的只读挂载也会与写入自己的安装树如所示Fig.5，大约90%的容器和microVM沙盒平均使用不超过5%的请求CPU容量，这使得过量使用成为一种自然的选择。2026年初的一天样本Fig.6显示了每节点1，048个容硬性限制。在这样的密度下，内存低效和CPU干扰变得越来越重要。钟)图7|从30K容器和10K微卷中取样的沙盒寿命分布。中值寿命分别为17.4和15.5分钟，p99的两个后端寿命都超过3小时。数据是在2026年初的一周内采样的。对于内存来说，微型内存会导致两种浪费。首先，通过虚拟块设备读取的图像数据可以由主机缓存一次，由每个来宾缓存一次，导致相同的数据在来宾-主机边界上被冗余缓存。第二，在没有明确报告的情况下，访客内部的空闲页面不会返回给主机。因为请求的内存容量经常超过实际需求，所以来宾操作系统几乎不会感受到回收非活动页面的内部压力。Fig.7显示命周期都超过3小时。这些长寿命放大了保留记忆的成本。总的来说，这些影响会限制微卷的对于CPU来说，有些任务对每一步的延迟预算有严格的要求，比如玩游戏的代理每次移动都有固定的时间限制。当尽力而为和延迟敏感的任务在同级同步多线程上下文上运行并且仍然共享核心执行资源时，仅给予尽力而为工作较低的调度器优先级是不够的。平台必须在不干扰延迟敏感任务的情况下，通过过量使用来提高CPU利用率。沙盒图像的庞大数量带来了第三个挑战。如所示Tab.2，在一个生产周内活动的工件总共占用超过130TB，远远超出了单个work的扇出中值为3，p90扇出为28，而microVM图像的扇出中值为1，p90扇出为3。这种低扇出导致本地图像缓存利用率很低，因为工作集太多样化，单个节点无法有效吸收。因此，当大量沙箱创建请求到来时，映像拉取变得不可避免，并给映像分发基础p90=3C++去访问的数据图像尺寸因为过量使用使群集保持接近完全利用，所以提取和具体化完整映像会消耗CPU和I/O资源，否则这些资源将用于运行沙箱。预热只是提前转移了这种开销，而没有消除它:相同的数据仍然必须被传输和具体化，完整的映像仍然占用本地存储。此外，沙箱通常只访问一小部分图像数据。中不同编程语言的采样容器映像Tab.3，运行时访问仅覆盖4.2%到13.3%的映像数据，这使得完整映像拉入尤其浪费。这些观察激发了按需图像加载。motivate§4确定三个相互关联的基础架构挑战。首先，突发创建和独立发展的环境组件需要一个设置路径，其成本不随重复的每个沙箱提取而成比例。其次，稀疏的CPU需求使得高密度执行变得有价值，但是长生命周期、保留内存和混合延迟需求使得无限制的过量使用变得不安全。第三，具有低扇出和低运行时访问比率的大型图像语料库使得急切的完整图像分发既昂贵又具有存工具包工作空间工本章介绍了环境合成、高密度资源管理和可伸缩图像分发的相应机制，如densityFig.我们的观点是，基础操作系统环境、每个工作区和每个工具包都是逻辑上独立的层，有自己的生命周期，而不是必须融合到单个整体映像中的组件。如所示Fig.4b因此，工具包可以独立更新，并与现有的基本映像和工作区层重新组合。Overlayfs原生提供了我们需要的合并语义:当多个只读下级目录堆叠时，内核呈现一个统一的目录树，所有层的文件共存，按优先级顺序解决冲突。一个可写的上层目录位于栈顶，透明地吸收任何运行时写入，而不修改下面的只读层。我们修改容器运行时(即dockerd)以在沙箱创建时动态组成ov基础映像位于底部，请求的工作区作为只读层插入到它上面，每个请求的工具包堆叠在顶部。这将工作空间和工具包文件合并到基本映像树中，而不是替换路径，将运行时写入定向到可写的上层，并允许任意的层组合，而不会耦合它们的生命周期。因此，升级m基础映像现在只需了O(mN和O(KN对O(m和O(K).的整体图像方案的成本由于发布的环境层是不可变的，我们将它们存储在EROFS(Gaoetal.,2019)，这是一个专门为只读数据设计的文件系统。与ext4或XFS等可写文件系统相比，EROFS避免了与写相关的簿记，并使用更简单、更紧凑的磁盘布局。EROFS还支持数据压缩，同时保留对文件内容的对于微卷，基础映像和工具包打包为独立版本的EROFS映像，并作为只读块设备向来宾公开。在guest虚拟机内部，根文件系统使用overlayfs，装载的EROFS文件系统作为下层，ext4格式的可写磁盘上的目录作为上层。这给了microVMs与容器相同的可组合层模型。model记忆效率。带DAX的虚拟pmem(QEMUProject,2026)通过将文件访问直接映射到主机支持的页面而不将其复制到客户RAM中，消除了页面缓存复制，允许协同定位的微卷共享一个主机页面缓存副本(§8.4).但是，virtio-pmem并不适用于每种磁盘。首先，通过带有DAX的virtio-pmem进行冷访问可能需要同步故障处理来建立映射并使后备数据可用。缓冲的virtio-blk路径反而可以受益于客户机端预读和批处理块I/O。其次，客户机必须为整个pmem支持的地址范围分配结构页元数据。对于4个KiB页面和一个64字节的结构页面，该元数据需要等于pmem设备容量1/64的客户RAM。例如，128GB的pmem设备需要2GB的客户RAM来存储这些元数据。对于不使用virtio-pmem的磁盘，冷文件数据可能会在来宾页缓存中累积，必须单独回收。因此，我们将DAMON(数据访问监视器)(Parketal.,2019)与虚拟气球自由页报告。虚拟气球驱动器(Waldspurger,2002)支管理程序报告自由页面，主机管理程序通过madvise(MADV_东尼)释放相应的主机内存。默认被触及的冷文件页面，并通过内核的回收路径驱逐它们。这种回收将分散的文件页释放回伙伴在我们的评估中§8.4，DAMON使用气球自由页报告将内存消耗减少了21.2%，而没有显著的CPU开销。在生产中，我们为只读EROFS基础映像和工具包层启用了virtio-pmem和DAX，同时使用DAMON和气球自由页报告来回收更大的可写磁盘的内存。支持QoS的CPU调度。为了消除SMT级别的CPU干扰，DSec将沙盒分为延迟敏感(LS为(BE)两类。BE沙箱放在SCHED_IDLE下，这样每当LS任务可运行时，它们就会产生CPU。因为调度器优先级本身不能防止兄弟硬件线程之间的干扰，所以我们还启用了Linux核心调度(Zijlstraetal.,2021)对于LS沙箱，防止不相关的BE工作在同一物理内核的同级线程上运行。这种双层策略保留了LS每步延迟预算，同时仍允许BE任务使用空闲周期，从而将SMT导关键的观察是沙盒通常只访问一小部分图像数据，如中的示例所示Tab.3。因此，按需拉动不仅解决了时间问题，还解决了容量问题:总I/O与实际使用的部分成比例缩小，而不仅仅是转现有的按需图像分发系统通常将容器注册表与对等传送相结合，以防止注册表成为瓶颈载。这种选择可以重用现有的存储基础架构，并避免部署单独的映像分发层。然而，3FS表现不对称决定了我们的设计:2.读取是按需和批量的。只读映像数据仅在被访问时从3FS获取，I/O是批量执行的，以利用3FS的高吞吐量来处理大型I/O请求。3.元数据最好保存在本地。文件系统元数据通常是通过小型读取来访问的。当图像格式允许对于容器，EROFS有助于实现这些设计原则。首先，由于EROFS是严格只读的，所有运行时写入都位于本地存储的overlayfs上层目录中。其次，EROFS通过按需缓冲I/O提供文件内容，而内核预读将相邻数据块合并成更大的请求。第三，EROFS提供多设备模式，将文件系统元数据与文件数据分开。纽约时报(DragonflyCommunity,2020)采用了相关的设端(例如，fscache/FUSE)按需从注册表或对象存储中获取文件数据。相反，我们将EROFS元数据下载到工作人员的本地磁盘，而将文件数据留在3FS上，因此元数据遍历和路径名查找不会导致远程I/O。这将写入路径(本地和小型I/O友好)与读取路径(远程、按需和批量)分开，符尽管这种设计避免了全映像拉取，但是安装大量的EROFS层仍然会增加容器创建的开销。因此，我们将大小阈值(例如，3GB)内的连续层离线折叠成一对元数据和数据的EROFS映像，同时保留overlayfs空白语义以正确表示文件删除。这减少了最终的装载数量，避免了过多的文件重复，并保持了共享公共层的映像之间的页面缓存重用。我们还使用EROFS文件备份装载模式来消除环路设备块映射层及其开销。容器风格的EROFS/overlayfs堆栈不能满足所有的microVM文件系统兼容性要求。例如，Docker的overlay2驱动程序不能使用overlayfs支持的数据目录。另一种方法是通过virtio-fs将主机挂载的文件系统导出到客户机，但是我们的鞭炮后端不支持这个接口(Agacheetal.,2020).因此，微型真空存储器的设计不同于容器的设计。只读的基本映像和工具包层仍然使用EROFS，而OverlayBD提供可写的ext4磁盘，包括一个直接安装在Docker的数据根的独立磁盘，用于Docker-in-microVM工作负载。我们通过ublk(一个用户空间块设备框架)来暴露重叠的备份磁盘。这种数据块级路径提供按需读取和本地写入，并支持增量磁盘快照，而无需将修改过的文件重新打包到EROFS中。与多设备EROFS路径不同，ext4元数据仍然嵌入在块映像中，因此元数据读取可以触发远程I/O。我们的ublk实施通过提取256个KiB区块中的重叠数据并将其存储在二级本地文件系统缓存中来减轻这些小读取。即使从页面缓存中逐出一个块，它在本地缓存中仍然可用，不需要再次从3FS中获取。两条路径都将写入保持在本地，并将对3FS的小I/O请求降至最低。again.DSec服务于DeepSeekV3.2版RL培训和评估中使用的所有沙盒工作负载(DeepSeek-AI,2025)到4.1版(DeepSeek-AI,2026).除循环容器如何将首次展示执行从GPU培训作业中分离出来(§6.2)以及暂停/恢复如何协调资源回收与训练抢占(§6.3).最后，它研究了危及任务完整性或破坏执行环境的代理行为础设施上交互式地构建环境。DSec通过pack_diff支持这种工作流:在任何时候，代理都可以通过拍摄增量磁盘快照来检查沙箱，该快照稍后可以恢复为新的沙箱。这种检查点和恢复界面将交互式会话直接转变为可重用的环境，允许在同一基础架构上构建、验证和使用环境，而无我们维护一组打包环境必须遵守的内部规则，以限制它们对共享基础设施的运行时性能影响。这些约束作为指令提供给构建环境的代理。为了跟踪所有环境并与不断发展的基础设施保持同步，我们的研究人员还构建了一个内部平台，对代理构建的环境进行质量检查，并以标准化格式导出它们，供RL和评估任务使用。因为环境是在相同的沙盒基础设施上构建和使用的，所以防止两个阶段之间的信息泄漏非常重要。构建器和运行时代理使用单独的帐户，并且在打包之前从可写层中删除构建时剩余数我们的GPU集群中的培训作业通常会被抢占，以提高利用率。对于长时间运行的代理部署，将部署执行与训练作业相结合会使抢占成本特别高:代理循环可能会在实质性进展后终止，即使在早期版本的训练管道中，代理循环在可抢占的GPU内部运行培训单元以及模型服务和RL框架。当GPU作业被抢占时，代理循环丢失，而沙箱持续存在。因此，恢复依赖于命令日志来协调由训练框架恢复的展示状态和沙箱的执行状态。在重放期从DeepSeek-V4.1开始(DeepSeek-AI,2026)，而是将首次展示执行转移到DSec上，并将其分成两个组件:代理沙箱，它托管脚手架(例如，DeepSeekHarness)及其工具，以及工作容器，它管理沙箱并为首次展示提供与脚手架无关的控制层。这两个组件都在可抢占的GPU池之外运行。这种设计将首次展示生命周期与教练生命周期分离。工作容器和代理沙箱共同保留完整的部署状态，并作为其唯一的事实来源，允许被抢占的GPU作业重新连接并继续，而无需通简化了故障处理。framework,因为GPU-job抢占不可避免(§6.2)，沙盒状态必须保持在DSec上，直到首次展示完成。然而，当训练暂停时，这会使许多空闲的沙箱消耗内存。因此，RL框关联的所有沙箱发送暂停请求，允许DSec回收内存，同时保留它们的执行状态。对于容器和微卷，任何对暂停的沙箱的后续请求都会在执行所请求的操memory.swap.max设置启用交换，并通过memory.reclaim触发主动内存回收。这将从匿名和文件备份页面回收内存，同时保留容器的执行状态。为了恢复容器，edge于其进程的内存映射，以启动异步预取，然后发出docke微短信。为了暂停一个microVM，DSec将其内存和执行状态保存在一个快照中，然后终止正在运行的鞭炮进程以释放microVM的运行时内存。在恢复时，DSec我们的生产经验揭示了代理执行中的两大风险。即使代理通过非预期的渠道获得答案，任务也可能看似通过，从而破坏训练和评估结果的有效性。代理动作还会破坏执行环境，危及共享基通过意想不到的渠道获得答案。在沙箱中，代理搜索平台管理的文件和通信信道，寻找残留答案。例如，他们试图通过将精心编制的RPC消息直接发送到chronus套接字(§3.3)并检查了chronus日志中泄露的答案。因为chronus为某些操作调用bash，所以代理还试图覆盖/bin/bash来绕过检查或将命令注入后续的shell会话。在我们介绍了文件读/写和套接字访问控制通过另一个文件描述符。这种尝试破坏了XFS元数据，并迫使文件系统关闭，说明了寻找答案在沙箱之外，代理搜索任务预期信息源之外的参考实现。例如，他们扫描端口和服务来发现可到达的镜像。他们还使用Go模块代理来检索GitHub托管的代码，并安装更新的包版本，寻找所需功能的现有实现。单独的最终输出检查不能可靠地确定代理是否如预期的那样解决了篡改执行环境。基础设施故障也是由普通的命令和执行错误引起的，而不是蓄意破坏系统。在一种情况下，代理从根目录递归地运行grep，遍历/proc并读取/proc/kpagecgroup，触发内核bug，在一个漏洞利用任务中:原本要转发到一个单独的目标虚拟机的攻击命令却在代理容器本身内一个代理调用了yes，它的连续输出被chronus记录下来，这样用户就可以没有一个单一的机制可以防止所有的代理不当行为和系统故障。因此，我们加强了可观察性，以识别新出现的问题，并随着模型的发展不断强化DSec。在这里，我们描述了访问控制，它限制了代理通过非预期渠道获得答案的能力，从而减少了奖励黑客(Amodeietal.,2016；Skalseetal.,2022).这些控制只解决了问题的一部分，并没有提供对破坏性行为(如触发内核错误)的全面防御。文件和套接字访问控制。我们使用AppArmor配置文件来控制文件读/写权限和套接字访问，包细粒度网络控制(eBPF)。培训框架指定由域或镜像服务组织的特定于任务的网络权限。举个例子，List.1允许访问PyPI，同时拒绝访问NPM。DSec通过每个沙箱的eBPF程序强制执行相应的允许列表，这些程序按IP地址、端口和协议过滤流量，拒绝允许列表之外的流量。当任务在具有不同连接需求的阶段之间移动时，策略可以动态更新。con放置引擎策略数千个沙盒在几秒钟内的极端峰值和严重的超额预订需要通过弹性而非固定的资源预留来均匀分布增量负载。我们从以下几个方面着手解决这个问题。1k-choices算法(Mitzenmacher,2001):调度器随机对k节点进行采样，并选择负载最小的节点，从而避免聚集并减少设置和工具调用期间突发RL环境之间的干扰。2)每个放置引擎实例覆盖其尚未反映在定期观察器快照中的最近放置，在没有跨实例协调的情况下考虑进行中的负载。3)每个边缘保留最终许可权:临界资源压力触发拒绝和选择替代节点，保持快速路径轻量级，同时防止陈旧估计超过本地资源限制。用户隔离以节点级密度为代价，进一步限制了资源可靠的服务。辅助服务和集群级服务都必须保持可靠，因为中断会导致代理无法完成任务，破坏奖励信号或评估结果。对于辅助服务，如API网关和数据包镜像以及控制平面入口，我们应用基于BGP的负载平衡:每个服务的实例宣布一个共享的虚拟IP，上游交换机在它们之间执行ECMP路由。当一个实例的BGP会话中断时，交换机会撤销其路由，并在几秒钟内将流量重定向到其余实例。包括放置引擎、观察器和IAM在内的集群级服务运行多个独立的可用性实例，定期的集群重置验证了我们的基础设施即代码配置可以从头开始重建所有集群级服务，并从故障dockerd中的动态下层插入。我们修改了开源的Docker守护进程(基于莫比项目(MobyProject,2026))在容器创建时动态插入EROFS支持的下层。具体来说，我们传递预装载的EROFS层的路径，并在装载前将其插入overlayfs堆栈，将其作为最顶层的较低层，以便它可基于Rust的OverlayBD和ublk库。我们使用OverlayBD的Rust端口(我们为此做出了贡献)和我们的ublkRust用户空间库来形成鞭炮微管理器的按需块存储路径，如§5.3。存统作为二级缓存，允许从页面缓存中清除的数据在本地得到服务，而无需另一次远程读取。这些存储组件已经在/kvcache-ai/AgentENV/tree/main/storage/overlaybd。内存和CPUQoS配置。所有机制都利用了现有的Linux内核特性。带有DAX的Virtio-pmem通过鞭炮设备配置和来宾内核挂载选项来启用。基于DAMON的回收通过客户内核参数和sysfs调prctl(PR_SCHED_CORE)启用核心调度，以便按QoS类别对任务进行分组。不需要内核修改；实GPUFnCallforoperatorbenchmarking。我们为FnCall配备了GPU，用于无状态运营商基准测试。由于GPU容量有限，GPUFnCall使用三种机制来提高并发性，同时保持性能隔离。首先，NVIDIA多实例GPU(MIG)将每个GPU划分为独立的实例，允许基准同时运行，并对指定的实例进行独占访问。第二，CPUFnCall处理编译，并将结果工件传递给GPUFnCall，避免不必要的GPU占用。最后，Python进程的热池预先初始化运行时和导入库，允许请求直接开始操作符执行。总之，这些机制减少了执行路径上的非GPU开销，从而提高了GPU利用率和基准吞吐量。对于对性能不敏感的任务，我们还提供了共享GPU模式，通过允许多个工作负载共享一个GPU实例来提高并发性。和2×400GbpsRDMA网卡。CPU节点通过其基于FUSE在本地，文件数据按需从3FS提供。数十台存储服务器支持具有数十万个CPU内我们的评估衡量了以下四个核心机制的有效性和开销§5:按需映像加载、可组合的环存优化和支持QoS的CPU调度。实验集中在这些基础设施性能机制上；中的框架集成§6不在我们在本章中的实验是在一个专用的10节点CPU测试集群上进行的，与我们的生产部署是分硬件。为了避免嵌套虚拟化，我们的microVMs直接在裸机硬件上执行。每个microVM节点都配备了AMDEPYC9655处理器，跨2个插槽×96个内核×2个SMT线程、1.5TBDRAM和3.4TB本地存储。相比之下，基于容器的实验在QEMU虚拟机中运行，该虚拟机的配置包括AMDEPYC9655处理器、1个插槽×96个内核×内核版本。所有主机运行Linux7.0，所有microVM来宾运行Linux6.1。工作量。我们的工作负载来自真实的RL培训和评估场景。任务套件包括内部软件工程基准、SWE-bench(Jimenezetal.,2024)、端子台(Merrilletal.,2026)、安全利用任务以及我们评估了按需EROFS图像拉取与来自远程注册表的即时完整图像拉取(Docker拉取(cold))以及所有图像层都在节点上预先缓存的完全本地基线(Docker拉取(缓存))。该实验在一个真实的RL评估工作负载下发出了一个8，192个容器的突发，这些容器分布在10个节点的集群中，在启动时需要不同的、数千兆字节的映像。我们测量一段时间内并发运行的容器数量、瞬时磁盘写入IOPS和累积磁盘写入量。CPU和内存利用率显示配置之间的差异可以忽略不如所示Fig.10，按需EROFS拉动几乎与完全本地基准一样快地达到峰值并发，因为映像层是直接装载的，并且数据是在沙盒访问其工作集时从3FS获取的。急切的Dockerpulling必须在容器启动之前下载并提取每一层，从而在最初的20分钟内延迟了容器的创建。按需拉取在35分钟内完成所有任务，符合完全本地基线，而急切拉取需要超过60分钟，速度降低1.71急切拉入还达到了按需路径峰值磁盘写入IOPS的近两倍，并且每个节点累积超过1，600GB的磁盘写入。按需拉取仅产生短暂的初始猝发，并在700GB时达到平稳状态，比紧急拉取低约57%,接近600GB的完全本地基线。这些结果验证了的设计§5.3:按需获取每个沙盒工作集的图像数据，避免了完整图像下载和提取，同时接近完全本地性能。000实线:IOPS/虚线:总计对于代码库和开发环境，我们比较了提供相同评估工作空间和工具包的两种方法，包括任务库、脚手架二进制文件和命令行工具。传统方法将这些文件打包为压缩的tar.gz归档文件，分发并提取到每个沙箱中，而EROFS方法将相同的文件打包为压缩的只读文件系统映像，该映像可以作为可组合层直接挂载。我们用预先录制的、确定性的工具调用序列来代替LLM生成，这样运行的不同之处仅在于它们的工作空间和工具包是如何配置的。0磁盘写入磁盘写入(MB/秒)因为tar.gz是一种顺序流格式，所以在工具调用开始之前，每个沙箱都必须解压缩归档文件，并将所有工作空间和工具包文件写入其本地可写层。这将端到端任务完成时间延长至79分钟。EROFS直接装载共享层，无需提取，允许沙盒更早地进入工具调用阶段，并将完成时间减少到45分钟，加速1.76倍。如所示Fig.11，基于tar的资源调配产生大约5.5倍的总磁盘写入流量和3.4倍的EROFS路径峰值磁盘写入吞吐量。EROFS的峰值CPU利用率更高，因为更多的沙盒进入工具调用阶段提前，并发执行操作。这并不意味着更高的设置开销，因为EROFS避免了重复解0基线pme0我们在测试集群上运行了一个真实的agentic-RL工作负载，并比较了四种鞭炮配置:未优化的基线、仅使用DAX的virtio-pmem、仅通过virtio-b报告(FPR)以及两种机制的组合。带有DAX的Virtio-pmem将冗余的每个来宾页面缓存合并到一个共享的主机映射中，与基线相比，减少了40.2%的峰值主机内存使用。仅达蒙+气球FPR使峰值使用量基本保持不变，但减少了21.2%的时间积分主机内存消耗。结合这两种机制会产生最低的整体内存消耗。如同Fig.12如图所示，virtio-pmem将瞬时峰值CPU利用率从26.5%提高到41.4%。这种增加可能部分反映了冷访问路径的差异。采用DAX的Virtio-pmem可能需要同步故障处理来建立映射并使后备数据可用，而缓冲的v块I/O。在CPU受限的部署中，运营商可能更喜欢单独启用FPR并保留virtio-blk。总之，这些结果验证了中互补的内存优化§5.2:virtio-pmem减少页面缓存复制，而DAMON和气球FPR回收空闲的客户内存。guest8.5.过量使用下的CPU服务质量尽力而为(BE)负载，测量我们的机制在高密度部署下保持每个沙箱性能的情况。我们比较了未如所示Fig.13，我们使用对延迟敏感的chess应用程序作为测试工作负载。在50%BE负载时，其每步延迟比没有QoS控制的非协同定位基线增加了45.2%。仅SCHED_IDLE一项就将延迟提高了至多3.4%，因为LS线程仍然可以与运行在其SMT兄弟上的BEwork竞争。添加核心调度可以在低负载时将延迟保持在非协同定位基线附近，并在50%负载时将膨胀限制在图13|增加协同定位尽力而为CPU负载下的延迟敏感代理时间，比较无保护基线、单独隔离开来。剩余性能下降主要是由于在高多核负载、内存带宽和共享末级高速缓存(LLC)争用的情况下CPU睿频降低造成的，而核心调度并没有解决这一问题。由于这种剩余干扰已经可以al.,2021)，TrEnv(Huangetal.,2024)，以及RunD(Lietal.,2022)为短命、无状态的功能优化冷启动延迟和资源共享。这些工作负载通常以高扇出重用有限的一组映像，并且许多系统假设所需的映像已经在本地可用。代理培训使用从图像语料库中提取的长期有状态沙箱，该图LLM代码执行平台。最近的系统在训练和推理中为LLM工作流提供沙盒代码执行。面向推理的Swarm(KimiTeam,2026).诸如MiMo-V2-Flash(XiaomiLLM-CoComputerRL(Laietal.,2025)提及他们的执行环境，但主要关注模型和培训设计。DSec专注于底层沙盒基础设施，在一个平台内集成了环境组合、资源过量使用、映像服务和抢占式安全恢容器图像和文件系统格式。DADI(Lietal.,2020)和CoFS(Wangetal.,2026)支持按需容器图像加载，而FaaSNet(Wangetal.,2021)使用对等传输来加速图像分发。EROFS(Gaoetal.,2019)提供了一个可随机访问的压缩只读文件系统。DSec利用这些技术进行RL培训和评轻量级隔离。为了运行不同的工作负载，已经提出了几种隔离范例，包括微卷管理器(Agacheetal.,2020)或虚拟机支持的kata容器(KataContainers,2017)、库操作系统(cheTsaietetal.,2015；Zhangetal.,2025)，以及嵌套虚拟化(Huangetal.,2023).它们在隔离、兼容性和性能之间提供了不同的权衡。DSec没有提出另一种隔离机制，而是al.,2025)，OpenRLHF(Hu,2026；Huetal.,2025)，而Seer(Qinetal.,2026)专注于通过高效的GPU调度、通信和样本吞吐量来扩展RL训练。他们将执行环境视为一个黑盒，假设沙箱可用并且配置正确。DSec在补充的基础设施层运行，管理沙盒供应和生命周期，同时通过培训框架协调执行状态和安全策略。我们介绍了DSec，一个用于大规模LLM代理培训、一个统一的接口公开多个沙盒后端，允许用户为不同的功能、兼容性和隔离需求选择合适的执行环境。支持可组合EROFS的层可避免重复的环境重建和提取，互补的内存共享和回收机制支持高密度部署，支持QoS的CPU调度可在超额订阅的情况下保护延迟敏感型任务，支持3FS的按需映像加载可降低映像分发开销。DSec还与RL框架集成，实现抢占式安全恢复和特定于任A.阿加切、布鲁克、约尔达切、利古里、纽格鲍尔、皮旺卡和波帕。鞭炮:无服务器应用的轻量级虚拟化。第17届USENIX网络系统设计和实施研讨会(NSDI20)，第419-434页，加利福尼亚州圣克拉拉，2020年2月。USENIX协会。国际标准书号978-1-939133-13-7。统一资源定位器/conference/nsdi20/presentation/agache。即阿库斯、陈、里马克、斯坦、萨茨克、贝克、阿迪蒂亚和希尔特。SAND:迈向高性能无服务器计算。2018年USENIX年度技术会议(USENIXATC18)，第923–935页，马萨诸塞州波士顿，2018年7月。USENIX协会。ISBN978-1-939133-01-4.统一资源定位器/conference/atc18/presentation/akkus。D.Amodei、C.Olah、J.Steinhar具体问题，2016。统一资源定位器/abs/1606.06565。W.安，谢碧霞，陈，陈，邓，丁，董，杜，高，关，郭，Y.郭，傅志军，何耀辉，黄平，李军，梁伟，刘，刘，刘耀辉，刘耀辉，陆，陆，聂， T.裴，邱俊杰，瞿，任，沙，苏，孙，谭，唐，王，Z.谢，熊，徐，叶，俞，查，张，张，张，C.赵，赵，周，周，邹。Fire-flyerai-hpc:一种经济高效的深度学习软硬件协同设计。高性能计算、网络、存储和分析国际会议论文集，SC'24。IEEE出版社，2024年。ISBN9798350352917。doi:10.1109/sc41406.2024.00089.URL/10.1109/SC41406.2024.00089。异常点。开放代码，2025。统一资源定位器https://opencoF.贝拉德。QEMU，一个快速便携的动态翻译器。2005年USENIX年度技术会议(USENIXATC05)，加利福尼亚州阿纳海姆，2005年4月。USENIX///conference/2005-usenix-annual-technical-conference/qe。mu-fast-and-portable-dynamic-translator.J.Cadden、T.Unger、Y.Awad、H.Dong、O.Krieger和J.Appavoo。Seuss:跳过冗余路径，让无服务器变得更快。《第十五届欧洲计算机系统会议论文集》,EuroSysdoi:10.1145/3342195.3392698.URL/10.1145/3342195.3392698。C.蔡澈，波特和维吉。石墨烯-SGX:SGX上未修改应用的实用库操作系统。2017年USENIX年度技术会议(USENIXATC17)，第645–658页，加利福尼亚州圣克拉拉，2017年7月。USENIX协会。国际标准书号978-1-931971-38-6。统一资源定位器/conference/atc17/technical-sessions/presentati。on/tsai.名词（noun的缩写）道滕哈恩、t.卡桑帕利斯、w.迪茨、j.克里斯威尔和v.阿德韦。嵌套内核:内核内部特权分离的操作系统架构。《第二十届编程语言和操作系统架构支持国际会议论文集》,ASPlos’15，纽约，纽约州，美国，2015年。计算机协会。ISBN9781450328357.doi:10.1145/2694344.2694386.URLhttps：///10.1145/2694344.2694386。DeepSeek-AI。萤火虫档案系统。统一资源定位器/deepDeepSeek-AI。Deepseek-v3.2:推进开放大型语言模型的前沿，2025年。统一资源定位器/abs/2512.02556。DeepSeek-AI。Deepseek-v4.1-flash:推动kv缓存压缩的极限，2026。统一资源定位器/abs/2609.19969。蜻蜓社区。蜻蜓集装箱影像服务，2020年。统一资源定位器/dragonflyoss/nydus。DXVK。DXVK:direct3d8/9/10/11的基于vulkan的实现。/doitsujin/dxvk,2018.E2B。E2B:人工智能代码执行的开源安全沙箱，2024年。统一资源定位器https://github.com/e2b-dev/E2B。页（page的缩写）K.Gadepalli、S.McBride、G.Peach、L.Cherkasova和G.Parmer。Sledge:一个面向edge的无服务器优先的轻量级wasm运行时。《第21届国际中间件会议论文集，中间件20》,第265–279页，纽约，纽约州，美国，2020年。计算机协会。ISBN9781450381536。doi:10.1145/342311.3425680。统一资源定位器/10.1145/3423211.3425680。X.高、董明、苗小霞、杜伟、余春华、陈海涛。EROFS:用于资源稀缺设备的压缩友好的只读文件系统。2019年USENIX年度技术会议(USENIXATC19)，第149-162页，华盛顿州伦顿，2019年7月。USENIX协会。ISBN978-1-D.郭，杨，张，宋，王，朱，徐，张，马，毕，张，X.俞，吴，吴振峰，苟，邵，李，高，刘，薛，王，吴，冯，C.陆、赵、邓、阮、戴、陈、季、李、林、戴、罗、郝、G.陈，李，张，徐，丁，高，曲，李，郭军，李军，陈，袁军，J.涂，邱继军，李继军，蔡继林，倪继军，梁继军，陈继军，董继军，胡继军，游继军，高继军，关，K.黄，于，王，张，赵，王，张，徐，夏，张，米（meter的缩写））张，唐，周，李，王，李，田，黄，张，王，陈，杜，葛，张，潘，王，陈，金，陆，周，南陈、叶、王、俞、周、潘、李、周、吴、云、裴、孙、T.王，曾文伟，刘文伟，梁文伟，高，俞文伟，张文伟，肖文林，安文伟，刘，X.王、陈、聂、程、刘、谢、刘、杨、李、苏、林、李、X.金，沈晓翔，陈晓翔，孙晓翔，王晓翔，宋晓翔，周晓翔，王晓翔，单晓翔，李彦宏，杨强。王，魏耀星，张耀辉，徐耀辉，李耀辉，赵耀辉，孙耀辉，王耀Y.何，杨飘，王，谭，马，刘，郭，尤，王，龚，邹，何，Y.熊，罗，尤，刘，周，朱，黄，李，郑，朱，马，Y.唐，查，严，任，沙，傅，徐，谢，张，郝，马，Z.颜、吴、顾、朱、刘、李、谢、宋、潘、黄、徐、张、张。Deepseek-r1通过强化学习激励LLM中的推理。《自然》，645(8081):633–638，2025年9月。国际刊号1476-4687。doi:10.1038/s41586-025-09422-z.URL/10.1038/s41586-025-09422-z。arXiv:2501.03262，2026。J.胡、吴晓东、沈文伟、刘继国、朱、王、江、王、陈、陈、方、先玉、曹、徐、刘。Openrlhf:一个易用、可扩展、高性能的rlhf框架，2025。统一资源定位器/abs/2405.11143。H.黄，赖军，饶军，陆，侯伟，苏，徐青，钟军，曾军，王，何志军，W.韩，刘俊杰，马廷骅，吴。Pvm:在云原生环境中部署安全容器的高效影子分页。《第29届操作系统原理研讨会论文集》,SOSP23年，第515-530页，美国纽约州，2023年。计算机协会。ISBN9798400702297。doi:10.1145/3600006.3613158。统一资源定///10.1145/3600006.3613158。J.黄，张，马，刘，林，陈，江，廖，山，张，陆，T.马、龚海红和吴彦祖。Trenv:跨不同的功能和节点透明地共享无服务器执行环境。《ACMSIGOPS第30届操作系统原理研讨会论文集》,SOSP24年，第421-437页，美国10.1145/3694715.3695967。统一资源定位器/10.1145/3694715.3695967。C.希门尼斯、杨、韦蒂格、姚、贝聿铭、普雷斯和纳拉辛汉。Swe-bench:语言模型能解决现实世界中的github问题吗？2024年5月7日至11日在ICLR举行的第十二届学习代表国际会议。OpenR，2024年。统一资源定位器/forum?id=VTF8yNQM66。形容器。Kata容器:带有轻量级虚拟机的安全容器。https://katacontainers.io/,2017.H.赖，刘，赵，徐，张，景，任，姚，董，唐。ComputerRL:为计算机使用代理扩展端到端在线强化学习，2025年。H.李，袁，杜，马，刘，徐。DADI:块级映像服务，用于敏捷和弹性的应用程序部会，2020年7月。国际标准书号978-1-939133-14-4。统一资源定位器/conference/atc20/presentation/li-huiba。Z.李，郑俊杰，陈，关，卞，陶，查，王，韩，郭。RunD:一个轻量级安全容器运行时，用于无服务器计算中的高密度部署和高并发启动。2022年USENIX年度技术会议(USENIXATC22)，第53–68页，加利福尼亚州卡尔斯巴德，2022年7月。USENIX协会。ISBN978-1-939133-29-27.统一资源定位器/conference/atc22/presentation/li-zijun-rund。LiteBox。Litebox:一个支持内核和用户模式执行的安全库操作系统。/microsoft/litebox,2025.米（meter的缩写））A.Merrill，A.G.Shaw，N.Carlini，B.Li，H.Raj，I.Bercovich，L.Shi，J.Y.Shin，T.Walshe，E.k.布坎南、j.沈、g.叶、h.林、j.普洛斯、m.王、m.内朱里纳、j.吉采夫、d.卢、O.Mastromichalakis，Xuz，Chenz，Liuy，Zhangr，L.L.Chen，A.Kashyap，J.-L.，J.李、吴俊杰、严介南、卞绍勇、夏尔马、孙国炯、迪尔曼、阿南德、兰普塔孔、B.Koopah，C.Hu，E.Guha，G.H.S.Dreiman，J.Zhu，K.Krauth，L.Zhong，N.Muennighoff，R.Amanfu，S.Tan，S.Pimpalgaonkar，T.Aggarwal，X.Lin，X.Lan，X.Zhao，Y.Liang，Y.Wang，Z.王，周，d.海涅曼，h.刘，h.特里维迪，j.杨，j.林，m.谢蒂，m.杨，n.奥米，名词（noun的缩写）Raoof，S.Li，T.Y.Zhuo，W.Lin，Y.Dai，Y.Wang，W.Chai，S.Zhou，D.Wahdany，Z.She，J.胡振东，朱，崔，塞耶德，科尔宾松，胡，吕廷群，马腾，Y.王、a.迪马基斯、a.孔温斯基和l.施密特。终端工作台:在命令行界面中的困难、现实任务上对代理进行基准测试，2026。统一资源定位器https://arxi2601.11868。米（meter的缩写））米森马赫。随机负载平衡中两种选择的力量。IEEE并行和分布式系统汇莫比项目。2026年莫比项目。统一资源定位器/moby/moby。开放集装箱倡议。开放集装箱倡议图像格式规范，2026。统一资源定位器/opencontainers/image-spec。OpenAI。代码解释器:代码执行的代理工具和沙箱，2025。统一资源定位器https:///docs/guides/code-interpreter。奥潘艾、j.阿奇阿姆、s.阿德勒、s.阿加瓦尔、l.艾哈迈德、I.阿克卡亚、F.L.埃勒曼、d.阿尔梅达、J.阿滕施米特、s.奥尔特曼、s.阿纳阿德卡特、r.阿维拉、I.巴布什金、s.巴拉吉、v.巴尔科姆、p.巴尔-特斯库、h.鲍、m.巴伐利亚、j.贝尔古姆、I.贝洛、j.贝尔丁、g.贝尔纳黛特-夏皮罗、c.伯纳尔、长度Bogdonoff，O.Boiko，M.Boyd，A.-L.Brakman，G.BrockmaBrundage，K.But-ton，T.Cai，R.Campbell，A.Cann，B.Carey，C.CarlsCarmichael，B.Chan，CF.Chantzis，D.Chen，S.Chen，R.Chen，J.Chen，M.Chen，B.Chess，C.Cho，C.Chu，H.W.Chung，D.Cummings，J.Currier，Y.Dai，C.Decareaux，T.Degry，N.Deutsch，D.Devill