Vast.ai 是什么：去中心化 GPU 市场的机制与适用边界

第一次在 Vast.ai 的搜索页往下翻的人，多半会先被同一张卡的价格差晃一下：同样的 GPU 型号，不同行的报价能差出一截，而且旁边还挂着一列看不太懂的百分比。这时候如果按「找最便宜那行点下去」的习惯操作，大概率会在几天后遇到一个很陌生的状态——实例显示 Offline，任务断在半路，控制台上也没有任何「已自动迁移到新机器」的提示。

这不是平台出故障，而是它的供给结构决定的结果。想用好这个平台，得先接受一件事：你打交道的对象不是一家云厂商。

一、它是一个市场，不是一家云厂商

官方文档给自己的定义很直白：Vast.ai 是一个把主机方（有 GPU 想出租的人和机房）和租用方（需要算力跑任务的人）连起来的市场。主机方的范围跨度极大，文档里的原话是从「个人的一台游戏 PC」一直到「Tier-4 数据中心」。价格由每个主机自己定，可靠性预期和验证等级也各自不同。

这句话是理解后面一切取舍的钥匙。平台侧的结构是：一台注册进来的物理机叫 machine，一台 machine 可以按 GPU、存储、带宽的不同切分，对外发布一条或多条 offer（报价）；搜索页上的每一行就是一条 offer，里面包含 GPU 型号与数量、总显存、CPU / 内存 / 磁盘 / 带宽、价格、最长租用时长、地理位置，以及两个平台自算的分数：DLPerf 和可靠性评分。你点下 RENT，就和这个主机之间生成一份租约合同。

所以「价格为什么差这么多」这个问题，在文档里的答案也是结构性的：供需、主机自己的运营成本、机器规格和可靠性、同区域其他主机的竞争。没有统一定价表，也就没有统一的服务水平。关于这类按小时租 GPU 的平台整体是怎么一回事，可以先看GPU 云租用的整体格局打个底，再回来看 Vast.ai 这种市场型供给的特殊之处。

offer 卡上还有一个很多人忽略的分类，叫机器层级，文档分三档：

• Unverified：新机器，没经过 Vast 团队测试，默认会被搜索结果过滤掉；
• Verified：通过了平台内部测试；
• Secure Cloud（数据中心）：在验证之外，还确认机器位于符合平台机房标准的数据中心，文档写的核验口径是 TIER 2/3 评级或 ISO 27001，卡片上是蓝色标签，官方明确推荐用于生产。

顺着这条往下还有一句在文档「注意事项」里、但对企业用户分量很重的话：主机方在技术上是可以访问自己机器上的文件的；涉及敏感数据时，文档建议用经过验证的数据中心并自己做加密。这条不是危言耸听，而是「供给来自第三方」的必然推论。

二、你租到的东西：独占 GPU 的 Docker 容器

Vast.ai 的实例几乎都是 Linux Docker 容器（文档说明有很小一部分是虚拟机）。这决定了三件事。

GPU 是独占的。 文档反复强调 GPU 从不在多用户间共享，运行中的实例对分到的 GPU 有排他访问权；实例停止后就不再持有 GPU 预留。CPU 和内存则按你占这台机器 GPU 的比例分配，空闲时可以超出基线突发使用，但内存超用有代价——文档直接警告，当系统空闲内存变紧时，超出基线的进程可能被 OOM killer 杀掉。这是个很容易误判的现场：你的推理进程半夜无声无息地没了，日志里只有一条 killed，而你以为自己租的是整机内存。

启动方式有三种：Entrypoint、SSH、Jupyter。这里有个文档写得很清楚但踩的人不少的机制：SSH 和 Jupyter 这两种模式会把初始化脚本注入进你的镜像，你镜像原本的 entrypoint 会被替换掉。如果你的镜像是靠 entrypoint 起服务的，文档的建议是把那条命令抄进 onstart 脚本里。同理，你在 docker 选项里用 -e 设的环境变量，默认在 SSH / tmux / Jupyter 会话里是看不到的，需要在 onstart 里把它们导出到 /etc/environment。

网络是共享的。 实例有完整外网访问，但通常没有独立公网 IP：每个开放的内部端口会被映射到这台机器共享公网 IP 上的一个随机外部端口，实例加载完之后从面板的 IP Port Info 里查映射关系。有些机器的 IP 还是动态的，会变；如果你要固定 IP，搜索时得用「Static IP Address」这个筛选项。另外文档里两条一句话的事实可以省掉你半天：实例本身就是容器，不支持 Docker-in-Docker；实例处于 Loading（拉镜像）状态时不计费。

三、三种租用类型，本质是优先级排序

文档给的三种类型不是三档套餐，而是三个优先级位置。

On-demand：固定价、高优先级，在合同的最长时长内资源是保证的，停止后数据保留。租之前必须看 offer 卡上的最长时长；合同到期时，主机可能续租，也可能直接把实例停掉。文档还有一条硬警告：到期的实例在一段时间之后（原文给的是小时级的窗口）可能被删除，而且到期状态下无法重启，数据要在那之前取走。

Reserved：本质就是预付换折扣的 on-demand，优先级和 on-demand 一样。机制上有几点要注意：它不是单独下单的类型，得先租 on-demand 再用实例卡上的折扣标记转换；预付的额度锁定在这个具体实例上；提前取消可以部分退款；并且不能跨主机迁移。也就是说，你为折扣付的钱是押在「这一台机器 + 这一个主机」上的，这件事和第四节要讲的可靠性评分是直接挂钩的。

Interruptible：竞价制，出价高的优先。它可能被暂停——被别人出价超过时会暂停，有 on-demand 需求进来时也会暂停。暂停期间数据保留，但实例不可用；当优先级恢复时自动继续。文档给的优先级规则是三段：on-demand / reserved 永远最高，其次是高出价的竞价实例，最低是低出价的竞价实例，后者会一直等到高价任务结束。

类型在租下之后不能改，唯一的例外是 on-demand 转 reserved；on-demand 与 interruptible 之间互转只能重开实例。文档对竞价实例的使用建议写得很实在：频繁存盘、重要产物写到云存储、代码里自己实现检查点、并且「预期会被打断」。这几句话的重量在下面第六节会体现出来。

四、可靠性评分：这个平台最该盯的那一列

如果只让我留一条筛选维度，我会留可靠性评分（reliability score），不是价格，也不是 DLPerf。

文档对它的定义很短：衡量一台机器历史上的在线时长与健康状况；所有机器都从同一个初始分起步，在它证明自己的可用性之后往上爬。后面还跟了一句判断性的话，我认为是整份文档里最值钱的一句：租期越长，可靠性的权重越大。

为什么它比价格更重要？因为在一个市场型供给里，「可用性」不是平台给你的承诺，而是每台机器各自的统计量。传统云厂商把所有机器的差异藏在一个 SLA 后面，你不需要关心某台物理机健康不健康；Vast.ai 把这层差异直接摊在你面前，让你自己定价。文档里另外两条正好印证了这种关系：定价页说可靠性分越高的机器通常价格越高；而在「怎么找到最便宜的 GPU」那一节，给出的手段之一就是接受较低的可靠性分。也就是说，你在搜索页上省下的那部分钱，相当一部分买的就是「这台机器可能掉线」的风险。

实际筛选时，我会把它和另外三列一起看，因为单看任何一个都会误判：

1. 可靠性分 × 你的任务时长。跑几十分钟的批处理和跑两周的训练，对同一个分数的容忍度完全不同。短任务可以用低分机器换便宜；长任务、尤其是要转 reserved 押预付款的长任务，低分机器是在赌。
2. 机器层级。可靠性分是历史统计，Verified / Secure Cloud 是机房条件的核验。文档推荐生产用 Secure Cloud，走的是另一条证据链，两者互补而不是替代。
3. 最长租用时长。分数再高也没用，如果合同长度本身短于你的任务。文档专门提醒长任务（按天、按周）要核对主机的可靠性分，同时确认最长时长。
4. DLPerf。它是平台自定义的深度学习吞吐近似分，文档给它的定位很明确：用来在不同 GPU 的 offer 之间做同口径对比，而不是只看裸参数。选型阶段该怎么把卡型和任务对上，在GPU 选型的判据里展开过，这里只强调一点——DLPerf 帮你比的是「算得多快」，可靠性分回答的是「能不能算完」，后者被忽略的代价大得多。

五、存储：最容易莫名其妙扣钱的地方

存储是这个平台上翻车率最高的一块，因为它的计费口径和直觉不一样。

容器存储是每个实例默认带的那块盘。文档列的特征有四条要记：大小在创建时确定、创建后不能改、实例停止时数据保留、实例被销毁时数据永久丢失。创建界面上的磁盘滑块既是筛选条件也是分配参数，文档提醒得很直接——务必在创建前估准，并且要考虑到「即使实例停止，主机方仍然按分配量收费」。所以估容量这一步值得认真做，权重、缓存、数据集、中间产物加起来经常比预期大一截，可以参考显存与存储用量的估算方法先把量算出来再拉滑块。

真正的坑在这句话上：存储是按实例「存在」的时长连续计费的，跟它有没有在跑无关。文档的原文口径是，停止状态的存储费率往往比运行状态还高；要让存储停止计费，唯一办法是把实例彻底销毁。很多人第一个月的账单看不懂，就是因为把「停止」当成了「关机不花钱」——GPU 那部分是按秒停了，盘还在那儿按小时躺着收钱。

**卷（Volume）**是另一种选择：它在实例被销毁后依然存在，可以重新挂到新实例上，独立计费，大小同样创建时定死。但它有一条硬限制必须记住——卷是本地的，绑定在创建它的那台物理机上，不能在不同物理机之间迁移，只能挂给同一台主机上的实例；而且删卷之前得先销毁挂着它的实例。这意味着卷解决的是「同机持久化」，不解决「主机没了怎么办」。真正跨机的备份手段，文档指向 Cloud Sync（同步到 Google Drive、S3 这类云存储）、实例间拷贝、以及 SCP / SFTP 下载到本地。顺带一条文档里的谨慎提示：Cloud Sync 只建议在带 Secure 标记的可信数据中心上用——毕竟你要往容器里放云存储的凭据。

计费机制还有一个前置条件容易漏：账户必须先充值才能开实例；余额降到零时实例会被自动停止、GPU 被释放、正在跑的任务被打断。如果绑了卡会自动扣款续上，实例和数据都还在；如果没有任何支付方式，实例和数据会被排进删除计划。这条对「跑完就忘」的人是真实风险。

六、主机掉线，平台不会替你搬家

这是 Vast.ai 和托管型云服务最实质的差别，也是最该提前设计的一环。

先看文档给的状态定义：Offline 意味着「机器与 Vast 服务器失去连接」，常见原因是网络或供电问题，平台会自动通知主机方，可能是维护，也可能是意外。注意这段描述里没有出现的东西——没有任何「自动把你的负载调度到另一台机器」的说明。整份文档里出现的操作路径都是手动的：停止的实例要靠你点重启按钮去尝试重新拿回 GPU。

而这个「尝试」本身也不保证成功。文档写的重启流程是：实例进入 SCHEDULING 状态，等待 GPU 可用；如果卡在这个状态超过半分钟左右，GPU 很可能已经被别人租走了；你可以再点一次停止取消排队，或者干脆新建实例。排障章节说得更直白：GPU 可能已被重新分配给其他用户、高优先级任务会挡住你的重启、可能无限期等下去，这时候的建议是「把数据拷到新实例」。

把这几条拼起来，结论就很清楚了：在这个平台上，检查点落到外部存储不是最佳实践，而是刚需。而且「外部」必须是真的外部——卷不算，因为它绑死在同一台物理机上，主机掉线时你既拿不到它，也不能把它挪到别的机器。真正扛得住主机消失的只有云存储同步或者你自己的机器。竞价实例那几条建议（频繁存盘、重要产物写云存储、代码里做检查点、预期被打断）其实对 on-demand 也成立，只是被打断的概率低一些而已。

同样值得提前想清楚的是恢复流程要不要人守着。如果你的任务是「跑一晚上出结果」，那掉线后等你早上发现再手动重开，损失的是一整晚；如果任务本身能从检查点续跑、并且你有脚本能自动换机重开，这个平台的价格优势才真的落到你口袋里。这类「便宜但要自己扛运维」的账该怎么算，自建推理的盈亏平衡点里的算法可以直接套。

另外几个文档里明写的真实报错，遇到时不用怀疑自己：点 RENT 时报「offer is no longer available」，是这个 GPU 槽位刚被别人抢走了，需求高峰时很常见；搜索报「0 is not a valid search op」，是当前模板的额外筛选项里有非法条目，重置筛选即可；租实例时报 server_error，文档给的首要排查方向是模板里的 Docker 镜像没带版本标签。

七、什么活我不会放在上面

说点结论性的判断，这些是从上面的机制推出来的，不是体验评价。

不适合的第一类：有可用性承诺要对外的线上服务。 供给来自第三方主机、掉线不自动迁移、重启可能拿不回 GPU、租约还有最长时长上限——这几条叠起来，意味着你没法把 SLA 建立在单个实例上。真要在这类平台上做生产推理，至少要自己做多机冗余和健康检查，那部分复杂度是你的，不是平台的。想省这份复杂度，就该去比托管型 GPU 云的做法，或者干脆回到 API。

第二类：合规敏感、数据不能出域的业务。 文档自己就写了主机方技术上可访问机器上的文件，建议敏感数据走验证过的数据中心并自行加密。如果你的数据连「理论上可被第三方运营者接触」都不能接受，那这个模型从根上不合适，别靠加密硬扛。

第三类：没有检查点能力的长任务。 一次跑几天、中断就得从零开始、代码又没法保存中间状态的任务，放在这里是在拿时间赌主机稳定性。要么先把检查点做出来，要么选 Secure Cloud 高可靠性的机器并接受更高的价格。

反过来，它真正划算的场景也很清楚：能容忍中断、能从检查点恢复、批量且不面向终端用户的活——超参搜索、数据预处理、离线批量推理、模型微调的实验阶段、临时的开发测试环境。文档给的类型推荐表基本就是这个意思。

最后一句得由你自己算：Vast.ai 省下来的是采购和固定成本，换回来的是可靠性差异和一部分运维工作量。这个交换划不划算，取决于你的任务被打断一次要付多少钱、以及你有没有人（或者脚本）在它掉线时把它捡起来。如果这两个问题你现在答不上来，建议先用短任务在低价机器上跑几轮，把中断频率变成自己的数据，再决定要不要把长期负载和预付折扣押进去。