Fly.io 现在有 GPU 了

原文 ↗ Hacker News 讨论 ↗

Fly.io 现在推出了支持 GPU 的虚拟机，并采用缩放到零计费，旨在让按需 AI 工作负载更容易运行，同时与现有的 Fly 托管应用并存。评论者讨论其定价和冷启动成本（模型加载、大镜像、卷）是否能与 DigitalOcean、Runpod、Vast.ai 等替代方案竞争，并争论“边缘”GPU 推理对典型的 LLM 和图像工作负载到底有多大实际价值。一个反复出现的担忧是 Fly.io 在生产环境中的可靠性与支持成熟度，不过也有用户报告了顺畅的使用体验，并提到一些配套功能，例如正在出现的 S3 兼容存储和灵活的 VM 生命周期控制。

定价与竞争

  • 许多人认为，与一些竞争对手（DigitalOcean、AWS、各种“军备竞赛式降价”GPU 初创公司）相比，Fly 的 GPU 价格偏高，尤其是在没有长期承诺的情况下。
  • 也有人指出，按需 GPU 的供给在各处都很紧张；看起来“更便宜”的标价通常需要多年承诺，或者在实际中根本买不到。
  • 有些人把成本与 Modal 和 Replicate 等平台相比，认为托管推理领域需要更多竞争，这一点值得欢迎。

性能、冷启动与模型加载

  • 启动时间与其说受 VM 启动影响，不如说更多取决于 GPU 镜像和模型权重。
  • 较大的基础镜像（1–3+ GB）以及下载模型文件可能会增加 30–120 秒；将多 GB 模型加载到 VRAM 也是一个主要因素。
  • 存储在本地 NVMe 卷上的权重可以复用，从而减少重复下载；一些评论者认为，把模型放在远程/网络式存储上是个坏主意。

缩放到零与“保活”行为

  • 计费从机器启动时开始，到它停止时结束，没有强制最低时长。
  • 在合适的重启策略下，机器可以通过以代码 0 退出来缩减到零；“保活”由用户代码通过延迟退出或自定义逻辑来实现。
  • 像 kill 信号和超时这样的运行时选项，为关机行为提供了一些控制。

目标用例与市场

  • 目标用户包括已有的、需要 GPU 的 Fly 应用，构建托管/AI 平台的人，以及那些偶尔需要 GPU 突发负载并受益于缩放到零经济性的工作负载。
  • 有些人质疑“既需要 GPU 又需要缩放到零”的市场到底有多大，以及边缘 GPU 推理是否真的不同于标准的数据中心推理。

基础设施与虚拟化

  • GPU VM 使用的是 Cloud Hypervisor（不是 Firecracker），并通过 PCI 直通，而不是 vGPU。
  • 从 Fly 的角度看，运营上 Cloud Hypervisor 和 Firecracker 被描述为类似。

可靠性与支持方面的担忧

  • 讨论串中存在尖锐分歧：有人报告称已平稳使用数月甚至一年；也有人把 Fly 描述为“尚未准备好投入生产”，提到宕机、不稳定的部署、机器无法启动，以及薄弱或仅限论坛的支持。
  • Fly 自己的表述强调，他们的 Postgres 产品并不是完全托管的；一些用户对此感到意外，并认为这是一个缺点。

存储 / S3 替代品

  • 缺乏一项一等公民的 S3 兼容服务，成为一些人的阻碍。
  • 多条评论提到一个处于 beta 阶段、与 Fly 集成的 S3 替代品（Tigris / 区域对象存储）。
  • 由于公司政策反对 AGPL，所推荐的基于 AGPL 的 S3 替代方案的许可证问题颇具争议。