RunPod 是什么：GPU 云租用的 Pod 与 Serverless 两种形态怎么选

团队决定不再只调 API、要自己把模型跑起来的那一刻，第一个绕不过去的问题往往不是”用哪个推理框架”，而是”卡从哪来”。买机器的账没那么好算，于是大部分人第一步都是去租。搜一圈下来 RunPod 这个名字出现频率很高，但点进官网会发现它不是”一个产品一个价目表”那么简单——同一家平台上，你既能租到一台开机就归你、SSH 进去随便折腾的机器，也能部署一个没人调用就不产生计算费用的推理端点。这两种东西的运维方式、失败模式、花钱方式完全不同，选错了后面全是返工。

下面的内容全部基于 RunPod 官方文档的口径整理，没有账号实测的部分我会直说。凡是涉及具体单价、显存容量、并发上限这类会变的数字，本文一律只讲机制不抄数字——这类值以控制台当时显示的为准，抄进文章里过两个月就成了错误信息。

一、Pod 与 Serverless：不是档位高低，是两种交付方式

Pod 按文档的说法，是给你一个专属的 GPU 或 CPU 实例，跑容器化的负载：训练、微调、渲染、以及各种吃算力的任务。关键词是”完全控制”——软件、存储、网络你自己配。部署方式有三条路：用官方模板（预配置好的 Docker 镜像，比如官方的 PyTorch 模板，省掉自己装框架、配 JupyterLab 的过程）；用自己的容器镜像，从 Docker Hub、GitHub Container Registry、Amazon ECR 这类兼容的镜像仓库拉；或者把 RunPod Hub 里那些兼容 Serverless 的仓库直接当 Pod 部署起来。开起来之后连接方式有 SSH、给暴露的 Web 服务走 Web 代理、JupyterLab，以及把 VS Code / Cursor 接上去当远程开发机。

Serverless 是另一套心智模型。文档的定位是”不用管服务器地把模型跑成推理服务”，你只为实际发生的计算时间付费，应用没在处理请求时不产生空闲成本。它由三部分构成：

• Endpoint（端点）：对外的访问入口，给你一个 URL，请求打进来触发你的代码。每个端点可以单独配算力、配伸缩策略。
• Worker（工作者）：请求到达时真正执行代码的容器实例，跑的是你自己的镜像。生命周期由 RunPod 托管——需要时启动，空闲时关掉。
• Handler（处理函数）：定义一个 Worker 怎么处理请求、返回什么。文档里给的骨架很短：

import runpod  # Required

def handler(event):
    # Extract input data from the request
    input_data = event["input"]

    # Process the input (replace this with your own code)
    result = process_data(input_data)

    # Return the result
    return result

runpod.serverless.start({"handler": handler})  # Required

注意文档专门标了一句：Handler 只用于队列型端点（也就是传统端点）。如果你用的是负载均衡型端点，请求结构完全取决于你自己怎么定义 HTTP 服务——这类端点把流量直接路由到可用的 Worker，不提供请求排队机制，好处是不用写 Handler，可以直接用 FastAPI、Flask 之类你熟悉的框架定义自己的 API 路径。这个区别很实际：有排队意味着突发流量会堆在队列里慢慢消化，没有排队意味着突发流量直接压到 Worker 上，两种失败姿势完全不一样。

请求的流转顺序文档写得比较清楚：请求先进队列；如果没有就绪的 Worker，就在不超过 max_workers 的前提下启一个新的（这就是冷启动）；Worker 用你的 Handler 处理；结果要么在你调 /status 时取回，要么用 /runsync 直接同步返回；处理完 Worker 会保持活跃一段时间接后续请求，一直没有新请求才关掉。提交任务用 POST，查状态、取结果、查端点健康用 GET。

冷启动是 Serverless 形态的核心代价。 文档的定义是：从一个没有运行中 Worker 的端点收到请求，到 Worker 完全”热”起来能接活，这之间的时间。这段时间里要启容器、把模型权重加载进显存、初始化运行时——模型越大加载越慢，冷启动越长，端到端响应时间也跟着长。文档给的缓解手段有三个方向：用缓存好的模型、开 FlashBoot、把 active（最小）Worker 数设成大于零。第三条的言外之意很直白：想让它永远不冷启动，就得一直养着 Worker，那部分算力是持续占着的。关于这套形态的通用取舍，可以对照看Serverless 推理那篇。

文档还提到一个容易被忽略的能力：fitness checks（也叫 preflight checks），在 Worker 开始接单之前按顺序跑你注册的检查项，用来在请求进来之前就抓出”GPU 没挂上""模型没加载""配置不对”这类问题。自建推理服务最怕的就是 Worker 看起来起来了、实际每个请求都返回错误，这个机制值得一开始就用上。

除了这两种，RunPod 还有 Public Endpoints（官方托管好的模型 API，按生成量付费，不用自己部署）和 Instant Clusters（多节点、节点间高速网络，用于分布式训练）。文档明确说这些可以混着用：Pod 做开发和实验，Serverless 跑生产推理，Instant Clusters 做大规模训练。这个组合方式我觉得是最该抄的一条——很多人纠结”到底选哪个”，其实答案是两个阶段用两个东西。

选型上更前一步的问题是”到底该不该自建”，那是另一篇的事：自建推理还是直接调 API。

二、Secure Cloud 与 Community Cloud：这个选项比看起来重要

文档把 Pod 分成两类云：

• Secure Cloud：跑在 T3/T4 等级的数据中心里，高冗余，面向企业和生产负载。
• Community Cloud：把个体算力提供者通过一套经过审核的点对点体系接给用户，价格上更有竞争力，但可靠性文档直接写的是”可变（Variable）”。

“可变”这个词得当真。它意味着你租到的那台机器背后是某个第三方提供者的硬件，冗余程度、网络质量、什么时候下线都不在 RunPod 的统一控制下。跑一次可中断的实验、调个参、做个 demo，这种场景省钟点费很合理；把生产推理压在上面，就是在赌运气。另外文档里有一条关键的时效信息：RunPod 已经不再接收新的 Community Cloud 主机了，现存的 Community Cloud 资源仍然可用。也就是说这部分供给是只减不增的，做长期规划时别把它当作稳定的容量来源。

还有一个跟机型有关的细节：文档提到 RTX PRO 6000 的 MIG 切片（带独立显存和算力的 GPU 分区实例）只在 Secure Cloud 提供，并且这些切片都是 Blackwell 架构，部署前要先确认你的 CUDA 版本和框架版本支持 Blackwell。这是个很容易在半夜踩到的坑——机器开起来了，框架起不来。

至于选哪张卡，官方的口径是”显存是最常见的瓶颈”，文档给了一套按参数量估显存的经验换算法，并推荐了 Hugging Face 的 Model Memory Calculator、Can it run LLM、VRAM Estimator 这几个在线工具。具体的换算和实际部署时该留多少余量，见显存估算。另外文档提到，数据中心的选择会影响延迟、可用的 GPU 型号和价格——国内团队还要额外算上跨境链路这一层，这部分官方文档不会替你考虑。

三、三种存储：Container Disk 停机即丢，这是最容易踩的坑

这一节是我认为整份文档里最值钱的部分。Pod 有三种存储，持久化行为完全不同：

存储	停机/重启后	删除 Pod 后	挂载位置	能跨 Pod 共享	扩缩容
Container disk	丢失	丢失	系统托管	否	可调
Volume disk	保留	丢失	默认 /workspace	否	只能增不能减
Network volume	保留	保留	/workspace（顶替 volume disk）	可以	可调

翻译成人话，有几条纪律：

第一，凡是你不想重做的东西，别放在 /workspace 外面。 Container disk 是 Pod 启动时创建、停机时清空的临时空间，文档的定位是操作系统、会话数据、缓存和临时文件。你 pip install 装的那一堆依赖、从 Hugging Face 拉下来的权重，如果落在默认的 home 目录而不是 /workspace，停一次机就得重新来一遍。性能上 container disk 是最快的（本地盘），所以它适合放中间产物和缓存，不适合放你的成果。

第二，Volume disk 保到 Pod 被删为止，不是永久。 它是本地持久盘，默认挂 /workspace，停机重启数据还在，但 Pod 一旦被终止就没了。模型、数据集、训练 checkpoint 放这里是文档推荐的用法。

第三，Network volume 是唯一独立于 Pod 存在的那一层，可以挂给多个 Pod、在机器之间搬、删了 Pod 数据还在，适合共享数据集和需要带着走的存储。但有两个硬约束：必须在创建 Pod 的时候挂，事后不能挂也不能卸；挂上之后它会在 /workspace 顶替掉 volume disk。代价是性能——文档标的是”可变（网络）“，不如本地盘稳定。它分标准档和高性能档，高性能档的吞吐和 IOPS 按文档说法有成倍提升（具体倍数以官方页面为准）。

第四，加密只覆盖 volume disk。 文档写得很明确：创建 Pod 时勾选 Encrypt volume 可以让卷在宿主机上静态加密，只有你的 Pod 能访问数据；但密钥不可取回，也不支持自带密钥（BYOK），RunPod 替你保管并在运行时传给容器镜像。而且 container disk 和 network volume 都不能加密。如果你的合规要求是”所有落盘数据必须加密”，那 network volume 这条路直接就被排除了，这在方案阶段就得定下来。

第五，改容量会重置正在运行的 Pod。 文档的操作路径是 Pods 页面 → Pod 旁边的三个点 → Edit Pod → 调整 container/volume disk 大小 → Save，其中 volume disk 只能加不能减。但紧跟着有一条加粗的警告：编辑一个运行中的 Pod 会把它完全重置，抹掉所有不在 /workspace 里的数据。 也就是说”我只是想加点盘”这个动作，会顺手清掉你装在别处的环境。这条我建议直接写进团队的操作规范里。

最后还有一句官方自己的免责：RunPod 不是为长期云存储设计的，建议把关键数据备份到本地或专门的云存储服务。数据搬运方面文档列了四种方式——预装在 Pod 上的 runpodctl（用一次性口令码传，适合零星小文件）、SCP、rsync（大数据集和增量同步的首选，需要 Linux 或 WSL 环境），以及 Cloud Sync（在 Pod 页面点 Cloud Sync，往 AWS S3、Google Cloud Storage、Azure、Backblaze B2、Dropbox 这些地方同步）。用 SCP/rsync 的前提是 Pod 配置里暴露了 22 端口，这是文档排障章节里点名的常见原因。

四、计费机制：什么时候开始扣、什么时候还在扣

具体单价不写（会变），只说机制，这几条是决定账单形状的：

• Pod 的计费粒度，官方文档跨页面给了三种说法，这点值得单独提醒：Pods 概览页与产品总览页都写 Pods are billed by the minute（按分钟），Pod 定价页写 Pods are billed by the second for compute and storage（算力与存储按秒），而快速上手页在费用摘要那里写的是 Total cost per hour (billed per millisecond)（按毫秒）。三处都是官方文档。我没有账号去核实实际账单按哪个粒度结算，所以这里不替它选一个——要精确到粒度的场景，以控制台和实际账单为准，最可靠的办法是跑一个短任务用真账单反推。三处一致的部分是：入口和出口流量不收费。真正影响决策的也不是毫秒还是分钟，而是下一条。
• 机器开着就在计费，跟你有没有在跑任务无关——这是和 Serverless 最本质的差别。
• Serverless 按实际计算时间计费，文档的措辞是 pay-per-second，没有请求处理时不产生空闲成本。但请注意：如果你为了压冷启动把最小 Worker 数设成大于零，那部分 Worker 就是常驻的。
• 存储是独立计费项，而且停机不等于不花钱。 文档对 volume disk 的运行中和停机两种状态分别列了单价，network volume 也是按容量单独计费的。换句话说，“把 Pod 停掉省钱”这个动作只省掉了算力那部分，盘还在，还在计费。真要彻底停止计费，得把 Pod 删掉——而删掉 volume disk 上的数据就一起没了。这就是为什么前面那张持久化表格得先看明白再决定怎么省钱。
• 长期用有 savings plans（长期用量的节省计划），文档把它和”先按最小可行配置起步，按实际用量再加”并列为两条省钱建议。
• Public Endpoints 按生成量付费，这是第三种计费形状，跟自己部署的两种不是一回事。

这套机制放到”自建到底比调 API 便宜不便宜”的账里怎么算，见自建平衡点。这里只提醒一件事：算账时最容易漏掉的不是卡钱，是那些你忘了删的盘。

五、官方明确列出的不支持项

这几条文档写在 Limitations 里，是硬约束，不是配置问题：

• 不支持 Docker Compose。 文档的解释是 RunPod 已经在替你跑 Docker 了，所以你没法在 Pod 里再起自己的 Docker 实例或用 Compose 编排。如果你本地的开发环境是一个 docker-compose.yml 拉起五个服务，那套东西不能原样搬上去——要么把它们塞进一个镜像，要么拆成多个 Pod。
• 不支持 UDP。 Pod 只支持 TCP 和 HTTP 连接。用到 UDP 的场景（某些实时音视频传输、某些分布式通信方式）需要另找方案。
• 不支持 Windows。

除此之外还有几条”不是限制但同样约束你”的点：network volume 不能事后挂载、volume disk 只能扩不能缩、container disk 和 network volume 不能加密、MIG 切片只在 Secure Cloud 有。这些合起来的意思是：RunPod 上的很多决定是在”创建 Pod”那个表单里一次性定死的，事后改的代价要么是重置要么是重建。所以第一次开机之前，把存储布局、是否加密、用哪类云这三件事想清楚，比开起来再折腾划算得多。

六、什么时候别用它

写到这里该说反面了。按文档暴露出来的能力边界，下面这些情况我不建议往 RunPod（或者说这一类国外 GPU 云）上走：

合规要求把数据锁死在境内的时候。 这是国内团队最先撞到的墙，跟平台好不好没关系。数据出境、机房位置、审计要求——这几条只要有一条卡住，后面的技术细节都不用看了。

你的负载是稳定长跑的时候。 按时间计费的租用方式对”开一阵、关一阵”的实验非常友好，但如果你的服务是 7×24 满负荷，长期租用的成本会压过自建，这时候该重新算一遍买卡的账。

落盘数据全都要求加密的时候。 前面说了，只有 volume disk 能加密，而 volume disk 又跟着 Pod 生死。这两个约束叠在一起，“加密 + 独立持久 + 跨 Pod 共享”这个组合在文档给出的能力里是凑不出来的。

你只是想要一个能调的模型接口的时候。 如果你需要的只是”发个请求拿个结果”，自己维护镜像、Handler、冷启动、Worker 伸缩这一整套是纯成本。这种情况下要么用平台托管好的模型 API，要么直接调第三方接口，自己维护一套推理服务的意义不大。

你的编排逻辑重度依赖 Docker Compose 或 UDP 的时候。 这是明确不支持项，别指望绕过去。

生产服务想省钱挂 Community Cloud 的时候。 可靠性标的是”可变”，而且官方已经不再接新主机了。把生产压在一个只减不增、冗余不确定的供给上，省下来的钱大概率会以另一种形式还回去。

反过来说，它适合的场景也很清晰：需要一台开机就能上手的 GPU 机器做实验和微调，或者需要一个流量忽高忽低、没人调用时不烧钱的推理端点。真要动手，Pod 开起来之后第一件事一般是把服务拉起来——这部分可以接着看 vLLM 起 OpenAI 兼容服务。

最后补一句诚实的话：本文所有事实都来自 RunPod 的官方文档，我没有拿账号逐项验证过控制台的实际行为。文档里没讲到的地方（比如具体的排队时长、不同数据中心的实际网络表现、停机后存储计费的确切结算周期）官方文档没有明确说明，以控制台实际显示和账单为准。看文档定方案，开一台最小配置的机器验证你最担心的那两三条，再上量——这个顺序能省掉大部分返工。