DeepSeek 弹性计算（DSec）

原文 ↗ Hacker News 讨论 ↗

DeepSeek 的 Elastic Compute（DSec）平台展示了一套大规模基础设施：在共享 CPU 资源上运行数十万级、轻量且隔离的“agent”沙箱，并将其与 AWS Lambda、Google 的 Ax 这类无服务器系统进行比较，但它更贴合 AI agent 工作负载突发且生命周期较长的特性。评论者一方面强调这一技术成就——在 30,000 核心上实现最多 380,000 个并发沙箱——另一方面也讨论其战略含义：一家精打细算、效率驱动的中国实验室，尽管受制于硬件约束，仍在推动前沿创新，并表明 AI agent 正迅速成为云计算资源的大用户。关于异常长的作者名单也存在争议：有人认为这在大型实验项目中很正常，也有人质疑这种共享署名方式对署名归属和人才挖角意味着什么。

DeepSeek 的创新与约束

  • 一些评论者认为 DeepSeek 异常具有创新性，认为算力约束会推动创造力。
  • 也有人指出这并不是普遍规律，并举出一些资金充足、同样非常有创造力的实验室。
  • 还有人认为 DeepSeek 目前的“弱势竞争者”状态只是暂时的；如果监管和能源约束更宽松，在芯片问题解决后，他们可能会超越美国实验室。

芯片、算力与数据中心政治

  • 一个反复出现的观点是：中国的主要瓶颈是缺乏高端芯片；这被视为难以轻易解决的硬件问题，不过也有人预计国产芯片大约一年左右就会追上。
  • 讨论还将美国和中国建设数据中心的能力进行对比：
    • 中国被描述为中央权力更统一、地方反对更少。
    • 在美国，审批、能源和地方阻力被视为严重摩擦，以至于有些公司开始探索基于太空的数据中心。
  • 也有人反驳说，在地球上、监管更宽松的国家建设，仍然比去太空容易得多。

DSec 是什么，以及它有多新颖

  • 许多人将 DSec 解读为一个面向 ML 工作负载和 agent 沙箱的专用无服务器风格平台 / 调度器。
  • 一开始有人把它轻描淡写为“只是一个跑在 Firecracker 之上的调度器”，或类似标准的 SLURM/Lambda 方案。
  • 也有人强调，agent 工作负载生命周期长且呈突发式增长，需要快速挂起/恢复、检查点以及高效隔离，这使得系统更复杂，也更具领域特定性。
  • 讨论中还将其与 Google 的 Ax 和“agent substrate”作比较，并争论它们到底有多相似。

规模、效率与基础设施问题

  • 文中披露的规模（约 160 个 CPU 节点、30k 核心、250 TB 内存、每天 300 万个沙箱实例、约 38 万并发、每秒超过 5 千次创建）被广泛认为令人印象深刻。
  • 有人觉得“每核 12 个沙箱”并不算多；也有人认为，考虑到异构工作负载和空闲时间，这个数字已经很可观。
  • 讨论还涉及每个沙箱的内存分配、交换到 SSD，以及在不重启容器的情况下实现弹性 CPU/内存分配的挑战。

作者构成与实验室文化

  • 那个非常长的作者名单引发了大量讨论。
  • 有人认为这对大规模实验性工作很正常（物理、生物、大型 AI 发布都是如此），因为许多贡献者各自只完成其中一小部分。
  • 也有人怀疑其中有策略动机（例如让挖人更困难），或者认为超长作者名单具有误导性，觉得列名者中许多人可能只做了很少的工作。
  • 参与者指出，在某些领域，几百人甚至上千人的论文并不罕见；从实际操作上看，联系第一作者或通讯作者是更可行的办法。

安全、agent 与潜在滥用

  • 评论者预计，随着模型能力增强，严格隔离的沙箱将对安全至关重要，尤其考虑到有报告称模型能够绕过较弱的沙箱。
  • 也有人推测，支撑大规模 agent 群体的同一套基础设施可能会被改作大规模进攻性活动（例如黑客攻击），不过另一些人指出，真正的瓶颈会是推理能力，而不是沙箱数量。