RunPod 与 Salad GPU 方案选型

选择 RunPod 与 Salad GPU 方案时，需要根据实例形态、优先级、数据持久性和费用构成做出判断。RunPod 的 Pod 按秒计算计算与存储费用，且不收取数据传入或传出费用；Vast.ai 则是由各主机自行定价的市场，总费用包含 GPU 计算、存储和按字节计费的带宽。这一成本结构和实例获取方式构成了评估的核心，但仅凭费用项目不足以直接确定最终方案。

RunPod 的计费与实例形态

RunPod 使用预付 credits，部署时扣款；计算和存储按秒计费，数据传输不收费，账单任务每 5 分钟运行一次。RunPod 的 Billing overview说明，账户余额降至 $0 时，运行中的 Pod 会自动停止，其中没有挂载 network volume 的 Pod 会被终止且数据无法恢复；已停止 Pod 的 network volume 仍会继续产生存储费用。创建 on-demand Pod 前，账户必须先充值足以覆盖所选配置 1 小时费用的 credits。RunPod 的 Pods 计费说明则进一步解释了停止 Pod 释放 GPU 但仍绑定原物理机器的情况，因此重启时可能找不到可用 GPU。

在实例形态上，RunPod 提供 Secure Cloud 与 Community Cloud两类环境，前者运行在 T3/T4 数据中心并面向企业和生产工作负载，后者通过经审核的点对点系统连接个人算力提供者，目前虽然不再接纳新的 Community Cloud 主机，但现有资源继续可用。按需实例遵循即用即付原则且资源专属于该 Pod，不受其他用户抢占；若 API 创建 Pod 时使用 "interruptible": true，则实例为可中断的 spot 类型，成本较低但可能随时被停止以释放资源。使用 on-demand Pods 的具体流程要求先选择 GPU 类型并命名 Pod，再按需选择模板和设置 GPU 数量，最后点击 Deploy On-Demand 按钮。若部署时出现 OCI runtime create failed 错误，需要在 Additional filters → CUDA Versions 中筛选 CUDA 版本以匹配兼容的机器。在存储机制上，RunPod 区分了 container disk、volume disk 与 network volume 的数据保留范围。RunPod 的 Storage options文档指出，container disk 会在 Pod 停止时清空，/workspace 中的 volume disk 能跨越停止和重启但在 Pod 终止时会被删除，而 network volume 独立于 Pod 存在，即使删除 Pod 也能保留数据；network volume 必须在创建 Pod 时挂载，且挂载后会替换 /workspace 处的 volume disk。如果业务要求 Pod 终止后数据仍然保留，应依赖 network volume 并另外执行备份，因为 RunPod 并不将其作为长期云存储，且 container disk 和 network volume 均无法进行加密，仅 volume disk 支持加密。

Vast.ai 的定价、实例类型与主机筛选机制

Vast.ai 的 marketplace 模式允许主机自行设定价格，涵盖了从单台游戏 PC 到 Tier-4 数据中心的主机。Vast.ai 的 Pricing (Instances)指出，总费用由 GPU 计算、存储和带宽构成，其中带宽按传输字节收费，且上传和下载均适用；实例的存储费用在停止运行后仍会继续累积，只有完全删除实例才能停止存储计费。平台同时提供 on-demand、reserved 和 interruptible 三种实例：on-demand 具有固定价格和最高优先级，reserved 需要预付以换取折扣，interruptible 则提供最低成本但具有低优先级并可能被暂停。Vast.ai 的 Instance Types文档说明，对于 interruptible 实例，用户需要设置出价，出价更高时可以获得运行优先权，当出价失去竞争力时实例会停止并结束正在运行的进程；虽然暂停期间能保留数据，但实例不可用，待优先级恢复后会自动继续运行。实例类型在租用后通常不能更改，仅允许将 on-demand 转换为 reserved，且 on-demand 设定了最长租用时间，过期实例可能在到期 48 小时后被删除，因此需要在期限到达前转移数据。

为控制风险，平台提供了不同的主机状态标识。Vast.ai 的 Concepts规定，可靠性评分衡量机器的历史在线时间和健康状况，新机器从 60% 起步并随可用性表现逐步提升。Vast.ai 的 Find and rent筛选指南指出，未验证的机器通常因为未经测试而在默认情况下被隐藏，只有 Verified 机器通过了平台内部测试；此外，标为 Secure Cloud (Datacenter) 的机器表示已经确认处于具备 Tier 2/3 评级或具备 ISO 27001 认证的数据中心内。尽管筛选条件涵盖了这些验证标准，业务方仍需结合特定的部署架构和预算限制进行选择。

如何根据部署需求做决策

在具体场景中，决策的重点通常围绕数据安全、服务连续性和成本结构展开。针对优先考虑确定性资源获取且不需要计入出入流量费的业务，可以优先考察 RunPod。如果模型权重、缓存或运行日志必须跨越 Pod 的停止与终止周期，RunPod 的 network volume 提供了独立于 Pod 的持久化机制，但同时也意味着需要建立额外的外部备份并承担持续存在的存储开销。当业务面临价格波动并能够容忍实例暂停或进程中断时，Vast.ai 的 interruptible 实例提供了一种基于竞价优先级的按需方式；平台也提供了关于竞价中断的具体说明，详情可参考 Vast.ai 的 Rental Types FAQ。

当核心业务绝对无法容忍因竞争导致的停机时，Vast.ai 的 on-demand 实例所具备的固定价格和最高优先级设定构成了相应的资源保障；不过，这类服务通常需要账户在开通前具备相应的预付条件。评估这些选项时，应当结合实际的显存需求确认系统运行资源，例如在评估 LLM 时，可以按 RunPod 官方指南中关于每十亿参数约需 2 GB VRAM 的经验标准进行估算。

以上步骤依据文中链接的官方文档整理而成，未进行实际运行或测量；在正式使用前，请对照相应版本的最新文档进行核对。