如何实现真正的无服务器GPU

我们正处于推理时代。数十亿到万亿参数的神经网络在专用加速器上以每秒千万亿次运算的速度运行，用于生成媒体、编写软件和折叠蛋白质。

推理工作负载比之前占主导地位的训练工作负载更具可变性和不可预测性。这使得它们天然适合_无服务器计算_，在这种模式下，应用程序在（虚拟）机器之上的层级定义，从而可以更灵活地扩缩容以应对可变负载。

但无服务器计算只有在新的副本能够快速启动——与需求变化的速度相匹配（通常以秒为单位）——时才有效。例如，在B200上为SGLang启动一个服务于数十亿参数LLM的新实例，如果处理不当，可能需要数十分钟，甚至因GPU不可用而停滞数小时。

在Modal，我们过去五年进行了深入的工程工作来解决这个问题。在这篇博文中，我们将详细介绍我们的做法。

有四个关键要素：

• 云缓冲池：维护一个健康、空闲GPU的小型缓冲池，以承接新负载
• 自定义文件系统：从内容寻址的多层云原生缓存中延迟加载容器镜像
• 检查点/恢复：通过直接将进程恢复到内存，跳过CPU端初始化
• CUDA检查点/恢复：通过直接将CUDA上下文恢复到内存，跳过GPU端初始化

它们共同将AI推理服务器副本的扩展时间从数千秒缩短到仅数十秒。

我们在此过程中分享了这项工作的部分内容，因为我们相信保密不是好的护城河。而且，如果更多人学会如何高效使用GPU，市场上就会有更多GPU可供我们使用！

但这篇博文是我们首次将所有内容整合在一起。我们希望它能说服您，我们的系统值得采用——或者加入我们一起构建它。

为什么要在乎无服务器GPU？为了最大化推理工作负载的GPU_分配_利用率。

首先，让我们清晰地定义问题。GPU昂贵且稀缺，因此我们希望最大化其利用率，这里的“利用率”是一个无量纲量：

利用率 := 实现的输出 ÷ 付费的容量

衡量利用率（即定义输出和容量）的方法有很多种。其中最复杂、最严格的大概是“模型FLOP/s利用率”，它将原始算法操作需求除以聚合算术带宽。

这对工程师来说很有吸引力。对于大规模训练的“英雄运行”也尤其关键，因此吸引了大量投资和关注，例如最近大家都在批评xAI约10%的MFU。

但在堆栈的另一端，有一种更基本的利用率形式会破坏推理工作负载的实现输出与分配容量之间的关系，即GPU_分配_利用率：

GPU分配利用率 := 运行应用程序代码的GPU秒数 ÷ 付费的GPU秒数

关于“GPU利用率”术语的说明

nvidia-smi 和类似工具报告的“GPU利用率”介于这两个极端之间。它报告的是_内核代码_在GPU上运行的时间比例——字面意思是CUDA流在GPU上运行的时间比例。了解更多

。

推理应用程序的规模变化很大。与训练不同，容量需求不受工程组织的直接控制和管理。相反，它由外部用户行为驱动——由市场、社交媒体算法或产品团队驱动。

以下是我们用于建模推理应用程序的时变泊松过程的每分钟请求示例轨迹。请注意，不仅有季节性变化（每日周期），还有随着平均需求增加而需求可变性增加的长期趋势。

尖峰需求带来了严重的工程问题。借用AWS的Marc Brooker的话：“系统的成本与其（短期）峰值流量成正比，但对于大多数应用程序，系统产生的价值与其（长期）平均流量成正比。”尖峰需求意味着高峰均比，这对系统经济性构成了挑战。

具体来说，想象一下此类应用程序的容量规划。您的需求（以在延迟目标内服务请求所需的GPU数量衡量）可能如下所示：

使用固定的、过度配置的GPU分配，利用率很低

为了妥善服务预期的负载，您分配了140个GPU（机架堆叠、从超大规模云提供商处租赁）。但大多数GPU在大部分时间都处于空闲状态——GPU分配利用率很低。

您可能会指责我们在这里自卖自夸。但指出这一点的并非只有我们！请参阅Hebbia的精彩博文。我们有数据，而不仅仅是感觉：根据2024年大规模AI基础设施状况报告，大多数组织在_峰值需求运行时_的GPU分配利用率低于70%。实际的GPU分配利用率通常更接近10-20%。

使用固定分配时，在意外尖峰期间需求也可能超过供应。试图预测它们只会进一步增加成本——超过其带来的收入增长。

无服务器GPU难在哪里？启动延迟。

直接的解决方案是配置自动扩缩容能力：当需求增加时，增加供应。

如果处理不当，这实际上会加剧问题：

如果分配缓慢，利用率和QoS都会受损

未经优化，从超大规模云提供商的API请求到运行的服务副本可能需要数十分钟。

您需要执行以下操作：

• 启动新实例并进行健康检查（数分钟到数十分钟）
• 加载应用程序程序和文件系统状态（数分钟）
• 在主机上启动应用程序程序，使其准备好服务请求（数十秒）
• 在设备上启动应用程序程序，使其准备好服务请求（数分钟到数十分钟）

在这整个过程中，负载超过容量，QoS通常会下降（表现为更高的并发或队列，从而导致尾部延迟膨胀，或者更糟，出现503错误）。这意味着用户不满。如果容量上线时间过长，甚至可能错过瞬时的尖峰。但由于需求的不可预测性和分配的困难，这些容量通常会长时间存在，利用率低下。

在Modal，我们将GPU上推理应用程序的启动时间从数十分钟优化到了几秒或几十秒。通过这些优化，各种GPU推理应用程序都可以“真正无服务器地”运行：供应的容量与系统需求紧密匹配。

通过快速、自动的分配，利用率和QoS都可以很高

在本文的其余部分，我们将解释我们采取的工程方法以及我们为上述四个步骤实现的性能优化，这些步骤涵盖了从云存储系统和机器管理到本地磁盘、CPU，当然还有GPU的整个堆栈。

这些优化共同使Modal上的推理启动速度提高了40倍：从2000秒缩短到50秒。

在基线系统中启动需要超过2000秒的推理服务器，在Modal上只需约50秒。实现这种加速的关键架构优化已标明，并通过颜色编码指示其针对的关键系统组件——GPU和GPU RAM、CPU和CPU RAM、本地固态硬盘（SSD），或机器/实例管理。我们在整篇文章中使用这种配色方案和示意图。

通过将实例分配和健康检查移出热路径，可以消除数十分钟的延迟。

考虑副本启动的第一步：

• 启动新实例并进行健康检查（数分钟到数十分钟）

我们可以通过提前完成此步骤来将其移出热路径：运行一个由许多应用程序共享的空闲、健康GPU缓冲池，将新副本调度到这些单元上，并异步地将新设备启动到缓冲池中。当缓冲池过大时，我们也可以在副本缩减时取消分配单元。管理这个缓冲池是一个有趣的线性规划问题，正如我们在别处所写。

在已分配的机器之上维护一个小的、准备好使用但未使用的机器缓冲池，可以快速将新副本调度到空闲机器上（用亮色表示）。

从缓冲池服务请求消除了副本启动中数十分钟的延迟。

关于系统和应用程序级缓冲池的说明

如果您运行的是单一工作负载，而不是多工作负载系统，您可能会问为什么我们只将实例分配移出“热路径”并移入缓冲池。我们不能将更多的设置工作移入缓冲池吗？当然可以！Modal用户可以通过维护一个准备好服务请求的应用程序层副本缓冲池

buffer_containers 。但即便如此，吸收给定幅度尖峰所需的缓冲池大小与创建新副本的速度成正比，因此下面描述的优化对于单一工作负载系统仍然很重要。

运行缓冲池会将峰值分配利用率限制在100%以下。这是一个合理的权衡，因为100%的利用率通常是一种幻觉。考虑到常见做法是，当其他资源（如CPU或IOPS）利用率过高时，启动新副本甚至通知工程师！

这对于稳健性很重要。一个100%利用率的系统没有容错余地，因此故障通常会变成失败。我们个人建议您在生活中增加更多缓冲——在浴室里多放一把牙刷；在家里、办公室和随身携带关键设备的充电器。

这个缓冲池对于在单个系统上容纳更广泛的工作负载尤其有用。在Modal，我们倾向于支持各种“开发”工作负载，而不仅仅是生产服务，因为我们可以快速创建新的开发环境。另一个额外的好处是，这些环境默认是可重现的，并且运行在生产就绪的基础设施上。缩小与生产基础设施的差距也提高了开发速度。

当然，细节决定成败。一个关键点是：健康检查对于GPU至关重要，GPU的故障率远高于其他硬件，包括像机械硬盘这样出了名挑剔的组件。我们在此处详细介绍了我们的GPU健康检查系统这里。简而言之，根据我们的经验，您需要在启动时运行一次简短的活动健康检查，并监控稍后出现的健康问题，但可以将更密集的检查（如dcgmi diag）推迟到较慢的频率（对我们来说是每周一次）。

按（匿名化）云提供商分组的每GPU每小时的关键级别Xid错误。故障率远非可以忽略不计！

通过从内容寻址缓存中延迟提供文件，可以将容器启动时间从几分钟缩短到几秒。

现在让我们考虑下一步：

• 加载应用程序程序和文件系统状态（数分钟）

在当代实践中，这通常意味着启动一个或多个容器或虚拟机。

粗略地说，容器是一个根文件系统，支持具有有限权限的进程。对于许多容器的分布式部署，性能瓶颈在于在工作实例上构建根文件系统。

操作系统发行版的根文件系统非常庞大——包含数万个文件，大小达数GB。天真地使用像docker run这样的命令，你需要加载整个文件系统，通常以云以太网支持的几GB/s速度进行。更糟糕的是，容器镜像被分成多个层，必须顺序应用。

解决方案是将容器_启动器_（Docker的runc，gVisor的runsc）与容器_镜像交付_分离。我们使用一个名为ImageFS的自定义文件系统，它基于libfuse构建，结合了延迟加载和专为匹配云提供商能力而设计的多层、内容寻址缓存。

我们在自定义文件系统中实现的快速容器启动的关键“技巧”是明智地懒惰（正如所有优秀工程师所做的那样）。容器镜像包含许多文件，例如整个世界的时区和区域设置信息，大多数应用程序永远不会读取这些文件。你可以在容器启动前跳过加载整个文件系统，而只需在启动时阻塞以加载元数据（一个索引）。元数据只有几兆字节，因此可以在100毫秒或更短的时间内加载，连同启动容器所需的其他一切。

其余部分可以与其他工作并发加载——或者根本不加载！大多数文件不会被读取，如USENIX FAST '16的_Slacker_论文中的图5所示，如下所示。

我们目前使用libfuse实现这个文件系统。它是一个用于在用户空间编写Linux文件系统的库。内核在一个使用标准系统调用操作文件的用户空间程序和另一个实现新文件系统的程序之间进行中介（最终，通过其自己的系统调用，其中一个最终通过内核返回到原始程序）。这比在内核模块中构建自定义文件系统要简单得多，也更容易分发。

这是有代价的：用户空间和内核空间之间的上下文切换次数翻倍。这对于延迟敏感的工作负载（如从终端字符设备读取）来说可能很痛苦，但对吞吐量敏感的工作负载（我们使用它的地方）影响较小。有关性能影响的详细分析，请参阅USENIX FAST '17的To FUSE or Not to FUSE。

但天下没有免费的午餐：容器访问的所有数据仍然需要加载。如果你天真地从对象存储中获取典型容器访问的数千个文件，那么从“容器启动”到torch.cuda.is_available将需要数小时。因此，另一个关键组件是一个分层、内容寻址的缓存，我们主动（但异步地）填充它。

我们使用_内容寻址_缓存，因为跨容器的镜像内容重叠很大。许多推理应用程序使用相同的软件（例如Python、PyTorch、CUDA堆栈）。

但基于路径的缓存和Docker的层式缓存会留下性能空间。例如，共享字节不能保证位于完全相同的容器镜像层中。

缓存是_分层_的，就像CPU和GPU内部的缓存一样，以映射到云提供商可用的存储层次结构。下面的图表列出了关键组件及其吞吐量、延迟和成本。

系统	读取延迟 (us)	读取吞吐量 (GiB/s)
页面缓存	0.001 - 0.1	10-40
SSD	100	4
可用区缓存服务器	1000	10
区域CDN	100,000	3-10
对象存储	200,000	3-10

关键的断点在于：

• 内存：Linux页面缓存。这是主要的在内存目标。它是实现微秒级延迟的唯一选择，吞吐量高，但容量有限（RAM昂贵，且越来越贵）。
• 磁盘：本地固态硬盘。与机械硬盘相比，SSD从内存降级时的性能下降要温和得多，但仍然明显。我们使用大容量驱动器，并迅速用最常用的内容填充它们。
• 网络：对象存储。这具有几乎无限的容量——在超大规模云提供商耗尽资金存储字节之前，你早就因为推送字节而耗尽资金了。但它的延迟要高得多。这种延迟惩罚是严重的，但请注意，在许多云配置中，峰值带宽可能高于磁盘！

要真正实现这一点，你可能需要在SSD和对象存储之间构建更多层，例如RDMA层或可用区内点对点共享。两者在数字上都很有吸引力，但会增加大量工程复杂性，因此我们尚未添加它们——目前还没有。

总的来说，我们将容器启动时间缩短了一分钟。对于启动只需几秒钟的简单应用程序来说，这绝对是游戏规则的改变者。对于像LLM推理服务器这样更重的应用程序，它从几分钟的启动时间中减少了一分钟左右。

带来整体加速倍数的大架构改动之后，是百分比点的精雕细琢。我们在这篇博文中详细介绍了这些细节。以下是一些亮点。

首先，libfuse暴露了一些性能调节旋钮。我们发现调整read_ahead_kb效果最显著，它指示内核在每个请求之前读取那么多千字节（如下所示）。我们将该值从默认的128增加到32 * 1024。较大的值对于容器镜像加载的大读取密集型特性很有利。过高的值（千兆字节级别）会导致严重的抖动。

其次，我们跳过了容器镜像层的gzip解/压缩。DEFLATE本质上是单线程的（LZ77，Huffman），这将其限制在约100 MB/s，远低于任何缓存层的吞吐量。如果你完全控制容器镜像的创建，你可能会选择使用zstd，并在镜像压缩时支付前期成本，以节省传输期间的带宽，并避免在解压缩期间网络成为瓶颈。但我们也努力保持镜像创建速度，特别是为了更好地支持动态代理工作负载。

通过CPU内存快照，可以跳过应用程序主机端启动的数十秒时间。

现在，让我们考虑第三步：

• 在主机上启动应用程序程序，使其准备好服务请求（数十秒）

这涵盖了从应用程序的容器进程启动到第一个“有用”工作开始（处理第一个请求）之间需要完成的所有工作。

例如，考虑执行Python语句import torch。这会触发数千行Python代码，其中包括执行数万个系统调用来加载各种文件并与驱动程序交互。对典型推理应用程序中使用的所有库重复此过程，从“进程启动”到“请求处理中”之间就有许多秒的工作要做。

这里的关键洞察是，任何正在运行的进程都是一个堆、一些线程和一个文件描述符表。大致如下：

如果你能重新创建这个状态（“创建检查点”），你就能重新创建正在运行的进程（“从检查点恢复”）。正确地打包这个状态，你就可以比通过执行一个全新的副本来重新创建进程更快地从存储中恢复它。

这就是透明检查点/恢复接口背后的核心思想——_透明_是因为用户程序不需要知道它们正在被检查点和恢复。Linux中透明检查点/恢复的实现称为Checkpoint/Restore In Userspace (CRIU)。透明C/R对于将正在运行的程序迁移到不同的机器等场景很有用。由于我们的主要目标是减少冷启动时间，透明检查点/恢复在我们的系统中不是必需的。

因此，我们通过容器生命周期管理接口向用户暴露C/R接口。它看起来像这样：

我们目前不使用Linux C/R。我们使用gVisor的runsc运行用户容器，它实际上在用户空间中模拟了（一个子集的）Linux内核。这个受限的接口提供了自动保护，防止像最近发现的CVE-2026-31431，又名“CopyFail”这样的漏洞。我们特别感兴趣（并且贡献代码！）的是nvproxy子组件，它与GPU的内核模式驱动程序通信。

由于应用程序只与这个模拟内核交互，它们可以被它检查点和恢复，而无需主机内核的配合。检查点/恢复对于runsc来说实际上特别容易。runsc运行时中的容器直接就是一个状态机。也就是说，运行时（用Go编写）被构建为一组具有协作式抢占的任务，就像大多数其他具有async/await风格并发的系统一样。系统已经在每个await点被中断然后继续，因此“只是”将那个状态序列化到检查点的问题。

更准确地说，runsc checkpoint命令会停止一个容器，并在磁盘上生成可用于通过runsc restore重新启动容器的状态（文档在此）。默认情况下，它是一个压缩归档，但我们生成时不进行压缩（记住gzip瓶颈！）。关键文件是pages.img，它包含原始页面数据。它至少100 MB，但可能达到数GB（尽管通常不会超过系统内存）。

还有很多其他活动部件，但检查点恢复性能的成败取决于如何快速将其带入主机页面缓存。我们使用上面描述的相同自定义文件系统机制来交付检查点文件。

结果是将新副本的主机端组件加载时间减少了约10倍。您可以在这篇博文中阅读更多关于我们的内存快照系统的信息。

import torch

Stable Diffusion

这里有一些限制。检查点对主机环境的细节非常敏感。例如，AWS g6.12xlarge实例类型不支持pclmulqdq执行四字无进位乘法指令，因此它不能接受任何在支持该指令的主机上创建的快照——该指令可能被硬编码到代码区域页面中，发出它会导致非法指令错误（或更糟）。因此，在像Modal这样的异构云平台上，我们从多个提供商聚合容量以确保低成本和可用性，单个推理服务器部署需要多个快照。

其次，这个系统只考虑程序的主机端状态。但在进程状态的文件描述符中，可能包含通过驱动程序对GPU的句柄，并且程序状态正确地包括设备上的任何状态。在启动推理服务器时，大部分时间都花在这里，因此纯主机端检查点/恢复的收益是有限的。但它们解锁了设备快照，这是我们接下来要转向的。

通过GPU内存快照，可以跳过应用程序设备启动的数分钟时间。

现在，让我们考虑创建新推理服务器副本的最后一步：

• 在设备上启动应用程序程序，使其准备好服务请求（数分钟到数十分钟）

对于当代推理工作负载，有两个不同的工作部分都可能需要数分钟。首先，神经网络权重需要从存储加载到GPU内存中。其次，神经网络周围的代码（“推理引擎”）需要进行一些设置工作。

前沿LLM权重现在从数十亿到数万亿字节（即GB到TB）不等。我们使用与自定义文件系统相同的基本存储能力来加载模型权重，因此模型权重以每秒几GB的速度加载。总延迟在几秒到几百秒之间。检查点/恢复在这里帮不上忙，因为瓶颈在于大读取的吞吐量，而不是可以通过快照轻松跳过的工作。

关于权重加载的说明 当像我们这样跨云或跨云区域加载时，很难提升这个瓶颈。通过在可用区内运行权重服务器，你可以将速度提升>3倍，或者通过RoCE/InfiniBand运行RDMA权重服务器，速度提升>10倍。这是可行的，但昂贵且棘手，尤其是在扩展到许多模型和动态工作池时。我们正在努力！

但权重加载并不是唯一依赖设备的慢速步骤。推理引擎设置涉及多个计算密集、依赖设备的步骤，这些步骤会产生难以缓存的小型内存制品。例如，vLLM推理服务器捕获CUDA图并运行Torch编译器。这些步骤每个都需要数十秒到数分钟。CUDA图由指向张量和内核的指针组成，没有原生的序列化选项。Torch编译器_可以_生成可序列化的制品。但根据我们的经验，验证这些制品的缓存命中通常很慢（几秒到几十秒），限制了缓存的好处。

这些难以生成的小型内存运行时制品使得推理设置成为检查点/恢复的理想候选。然而，基于runsc或CRIU的检查点只操作主机内存，而不是设备内存。尽管大多数推理引擎制品是主机端的，但设置过程会创建设备资源，这些资源必须被检查点和恢复。

Nvidia最近的驱动程序版本包含一个优雅的解决方案来解决这个问题。简而言之，驱动程序在主机内存中检查点设备内存，以便主机端检查点系统可以将其检查点到磁盘。然后，一旦主机端系统恢复了主机内存（包括设备检查点），驱动程序就会恢复设备内存。

设备检查点/恢复建立在主机检查点/恢复之上，而主机检查点/恢复又建立在底层文件系统之上。基础设施是复合的。

结果令人瞩目：典型的加速比在4-10倍之间，将容器启动时间从几分钟减少到几十秒。

这里有一些注意事项，我们在此处记录。首先，多GPU程序的快照很棘手，因为nccl程序不是为暂停而设计的，并且当一个对等点静默时经常死锁。其次，虽然我们的经验是几乎任何应用程序都可以被快照，但大多数应用程序首先需要一些小的调整。例如，快照vLLM或SGLang最好配合权重卸载——在检查点之前将权重移回主机。此外，引擎通常会急切地创建一个（空的）KV缓存，这可以比从检查点恢复快得多地重新创建。

有了这些调整，LLM推理服务器副本的启动速度可以比使用快照快近一个数量级。下面，我们报告了为vLLM或SGLang服务约1 GiB语言模型（Qwen 3 0.6B 使用 bf16）的新副本的延迟累积分布函数。这包括在Modal上创建新副本的_所有_延迟——任何机器排队、容器启动、主机端和设备端准备。在超过一万次冷启动中，我们观察到快照部署在每个百分位上都具有更优的延迟。

在vLLM中启动1 GiB模型

在SGLang中启动1 GiB模型

平均值也有所改善。

	快照关闭	快照开启
vLLM启动延迟（平均值）	95,679 ms	13,797 ms
SGLang启动延迟（平均值）	83,713 ms	17,486 ms

您可以在这篇博文中阅读更多关于GPU快照的信息，包括额外的基准测试结果。

我们已在数百万个副本的规模上，跨多个用例运行了这个堆栈。

过去三个月（2026年2月至4月）的使用数据如下所示。

	恢复的副本数	执行小时数	创建的独特快照数
CPU快照	~35,000,000	>5,000,000	~1,000,000
CPU+GPU快照	~15,000,000	>2,000,000	~700,000

CPU和GPU快照被数百个不同的组织用于各种用例。

CPU快照最常用于数据管道或作业队列系统，但也经常用于各种用例以加速初始化，特别是Python导入。

GPU快照也用于多个领域。由于目前限制为单个GPU，它们最常用于大小为几GB到几十GB的模型。这包括较小端的大型语言/视觉语言模型，用于结构化数据提取或认知复杂度较低的任务。我们发现GPU快照在音频/语音用例中也很受欢迎，无论是用于语音转文本/自动语音识别还是文本转语音/语音生成。

重点用例：Reducto无缝地将文档处理扩展到数千个GPU。

Reducto 是一个文档处理平台，使用视觉语言基础模型从非结构化文档中提取结构化数据。您可能读到过他们对JMail项目的贡献，他们为该项目索引了国际罪犯Jeffrey Epstein的通信。

Reducto文档处理系统的主要约束之一是高波峰比。客户可能随时出现，要求处理，例如，整个企业的Notion文档集合。这些作业有数十分钟的截止期限，只有通过跨数百或数千个GPU进行水平扩展才能满足。

快速的容器启动使Reducto能够在不维护空闲容量的情况下满足这些截止期限——以“真正无服务器”的方式运行千GPU级别的推理工作负载。

特别是，GPU内存快照的加入将冷启动时间降低了约六倍，从约70秒降至约12秒。

您可以在我们的博客上阅读更多关于Reducto使用无服务器GPU进行推理的信息。

尾声

现有的容器堆栈及其构建的云服务是为上一代工作负载设计的，例如托管网站和与数据库交互。它们并非为训练或推理而设计，这种阻抗不匹配对构建推理应用程序的团队来说是一种成本、效率和性能上的负担。

我们构建Modal是为了让云基础设施跟上人工智能的需求（字面意义上的速度）。我们分享我们的做法有几个原因。

首先，我们希望您像我们的客户一样，对在此基础设施上构建应用程序感到兴奋，例如Physical Intelligence、Runway、Ramp、Zencastr、Lovable、Substack和Suno。您可以立即开始使用，包括每月30美元的免费使用额度。

其次，我们基于并参考了许多优秀的开源或文档完善的系统构建了这个系统，从Linux CRIU到AWS Lambda。我们希望将这种精神传递下去。如果您从我们的工作中获得灵感，我们很乐意听到。

最后，我们还有很多工作要做——那些RDMA网络不会自己配置！我们希望分享这些工作的样貌，能吸引更多最优秀的工程师有兴趣与我们一同完成它。“造船不是编织帆布、锻造钉子或观测天象。而是分享对大海的共同热爱。” 造船者和向往大海的人们，请加入我们，分享您最喜欢的、为了节省一毫秒而工作数小时、重复万亿次的故事。

作者感谢Vikram Mailthody、Steven Gurfinkel、Stephen Jones、Radostin Stoyanov、Rodrigo Bruno和Jordan Sassoon的贡献。