RunPod 上手全流程：注册、充值、开出第一个 GPU Pod

第一次在 RunPod 上开机器，翻车的地方往往不在技术上。最常见的三种：注册完了直奔那张最猛的卡，点 Deploy 发现开不出来，因为余额不够覆盖这个配置的最小门槛；开出来了，pip install 装了半小时环境，第二天停机再启动发现全没了；或者更糟，忙完一阵忘了这台机器还在，余额慢慢见底，平台把 Pod 自动收走，盘上的东西一起没了。

这三件事都不是”熟练了就不会犯”，而是平台的机制决定的——预付费、容器盘停机即清、余额归零触发自动停机。所以这篇按真实的操作顺序走一遍：账号和付款、API Key、选机表单、连上去、上量之前该验证什么。

下面的内容全部依据 RunPod 官方文档的口径整理，我没有拿账号逐项对着控制台核过，凡是文档没写清楚的地方我会直说。涉及具体金额、显存容量、并发上限这类会变的数字，本文一律只讲机制——这些值以控制台当时显示的为准。如果你还没决定要不要用 Pod 这种形态，先看RunPod 是什么那篇把 Pod 和 Serverless 的差别搞清楚再回来。

一、账号与付款：先把”开不出机器”的几种原因排掉

注册本身没什么可说的：注册、验证邮箱、按官方建议开双因素认证。真正需要提前理解的是付款模型。

RunPod 走的是预付费额度制：你先往账户里充钱，用资源的过程中从余额里实时扣。文档明确说算力和存储都按秒计费、数据传输不收费。有意思的是这里官方文档自己的口径不太一致——部署页的费用摘要写的是按毫秒计费，计费总览页写的是按秒。对实际账单影响不大，但这说明这类细节值得以控制台的实际结算为准，别当成合同条款。

能不能开出机器，先看余额门槛。 文档的机制是：部署一个新 Pod，账户余额必须至少够覆盖所选配置的一个最小时长（官方按小时口径给这个门槛，具体数值以文档和控制台提示为准）。不够就两条路——继续充，或者换一张便宜点的卡。第一次上手没搞清这条的人，会以为是自己哪里配错了。

付款方式文档列了三类：信用卡（走 Stripe 支持的卡种，预付卡有单笔最低入金要求）、加密货币（通过集成的支付处理商，首次支付前要先完成 KYC）、以及面向较大额交易的对公开票结算（支持 ACH、电汇、信用卡，需要联系官方销售开通）。

这里有一条我认为必须提前知道的规则：充进去的额度不可退款、不可提现，只能用于平台服务。 这跟大部分国内云厂商”按月结算、随时停”的心理模型完全不同。它的直接推论是：第一次用，充一个够跑通流程的小额就行，别为了拿什么长期优惠一次性砸进去——你还没验证过这个平台适不适合你的活。

余额归零的行为是全文最该先记住的一段。 文档写得很清楚：余额到零，平台会自动停掉你所有运行中的 Pod，然后分两种情况——挂了 network volume 的 Pod 只是被停，数据保留在卷上；没挂 network volume 的 Pod 会被直接终止，数据无法恢复。而且更麻烦的是，Pod 停着的时候 network volume 的存储费还在继续累积，如果余额一直是零、这笔存储费始终没人覆盖，那个卷最终也可能被终止，数据同样不可恢复。

也就是说，“忘了关机”的真实代价不是多烧了一点钱，是可能连数据一起丢。官方给了两道防线，第一次用就该开起来：

• 低余额提醒：在计费页的通知区打开低余额告警，自己设一个阈值，余额跌破就发邮件。
• 自动充值：绑卡之后配置触发阈值和每次补充的额度，余额接近阈值时自动扣默认卡。文档提到自动充值的尝试有频率上限，防止出现连环扣款。

两者是独立的，可以只开一个也可以都开。我的建议是都开——提醒负责让你知道，自动充值负责在你看不到邮件的时候兜住。

还有一个方向相反的保护：账户默认有每小时总消费上限，覆盖所有资源，用来防止配置写错或者进程失控把余额烧空。这个上限会随账户使用历史自动提高；如果你确实需要立刻放宽，文档说要联系官方并说明用途。这条对第一次上手的人是好事——它意味着你手抖多勾了几张卡，损失是有天花板的。

花销想事后复盘，计费页有账单浏览器可以看近期消费和支付记录；要按团队或项目做成本归集，文档指向的是成本中心那套东西，那是另一篇的范围。

二、API Key：作用域是在创建那一刻定的

只在控制台点点鼠标的话可以先跳过这一节，但只要你打算用 CLI、SDK 或者 REST API 管机器，第一步就是建 key。

路径是控制台的设置页，展开 API Keys 区域，选择创建，给 key 起个名字，然后设权限。文档给的三档是 All、Restricted、Read Only。选 Restricted 的话可以按每个 Serverless 端点单独配访问级别，可选项是 None（无访问）、Restricted（逐个端点定制，默认就是 None）、Read/Write（完整访问）、Read Only（只读不能写）。

创建之后只有那一次机会拿到明文。 文档写得很直白：RunPod 不保存你的 API key，所以你得自己存好（它建议放密码管理器或者 GitHub secret），并且像对待密码一样别外传。这条的实际含义是：如果你没存住，只能吊销重建，没有”再看一次”的入口。

后续管理有三个动作：点铅笔图标改权限、点开关禁用或启用、点垃圾桶并确认吊销。

文档里还有一条历史遗留值得留意：2024 年 11 月 11 日之前生成的旧 key，对 GraphQL 的访问级别取决于当时的设置（Read/Write 或 Read Only），而所有旧 key 都拥有 AI API 的完整访问权限。官方直接建议重新生成一个 Restricted 权限的新 key，只勾你真正需要的那部分。如果你的项目里躺着一个两年前建的 key，这就是该换的理由。

实操上我会按这个原则分：本地开发和一次性脚本可以用权限宽一点的 key，但要进 CI、进镜像、进任何会被多人看到的地方，就用 Restricted 并且只给用得到的那个端点的最小权限。另外文档提到每个 Pod 都预装了 runpodctl 命令，并且自带一个 Pod 作用域的 API key——在 Pod 内部做管理操作不需要你把账号级的 key 传进去，这点能省掉一类泄露风险。

三、选机表单：哪几个字段真的影响后面的决定

控制台里从右上角的 + New 选 Pod，或者从左侧栏进 Pods 页面。这里要提醒一句：RunPod 正在通过早期访问推一套新的部署流程，新旧两套流程的字段不完全一样，以你控制台实际看到的为准——文档里两套都有描述。

按新流程的顺序，这几个字段是真正带后果的：

Template 要最先定，因为它决定后面能不能 SSH。 模板就是 Pod 要跑的容器镜像。搜索框找或者浏览全部，选中后镜像名会显示在下面。真正的关键是：只有选官方模板时，才会多出两个开关——启动 Jupyter notebook（默认开）和 SSH 终端访问（开了要贴你的 SSH 公钥）；社区模板不显示这两个选项。这条直接决定了你后面能不能把 VS Code 接上去，第一次选模板时很容易忽略。如果既想用自定义镜像又想要完整 SSH，得自己在镜像里处理 sshd，后面第四节会说。

想改环境变量、暴露端口、容器启动命令，不用去改模板本体，用 Set overrides 覆盖就行。

Region 默认是任意区域。文档提到数据中心的选择会影响延迟和可用的 GPU 型号。国内团队还要额外算上跨境链路这一层，这部分官方文档不会替你考虑。

选卡的四个页签含义不同，别只看默认那个。 Available 只列当下真有余量的卡；Recommended 是平台和模板维护者共同推荐的；All 列全部，包括没余量的和被模板标为不兼容的；Recent 列你近期部署过的卡（有部署历史才出现这个页签）。列表可以用搜索框、网络卷筛选、筛选按钮和排序下拉来收窄，还能选中几张卡让平台助手做对比。

这里有一个很多人想不到的联动：网络卷筛选器实际是在按机房过滤卡。 它会把列表收窄到跟你选的那个 network volume 处于同一数据中心的卡，不兼容的会被挪到 All 页签的不兼容区。反过来说，一旦你决定用某个网络卷，可选的机型就被锁在那个机房里了。而且那些跟任何网络卷都不兼容的卡会自动选上 volume disk，你没法给它们选网络卷。存储方案和机型选择是耦合的，这件事在方案阶段就该定下来。

没余量的卡也能选。 选中一张显示 Out of capacity 的卡，最后一步的按钮会从”部署”变成”有货时部署”：摘要面板显示实例不可用，你点进订阅弹窗，设好通知方式（邮件或控制台内提醒，默认都开）和一个监控时间窗，平台在窗口内盯着可用性，一有货就自动帮你开。窗口还能勾高级调度器，只在指定的时段内尝试部署，而不是全窗口连续监控。两条边界要记住：窗口内没等到货，订阅就过期作废；货来了但你余额不够，订阅直接失败、不会开出 Pod，两种情况都得重新订阅。

存储这一步只能二选一。 容器盘是容器的主存储，Pod 一停就被清空。持久化存储默认挂在 /workspace（可以用模板覆盖改，模板本身也可能设成别的路径），分两种且只能挂其中一种：volume disk 是直接挂在 Pod 上的盘，停机重启数据还在，但 Pod 被终止就没了；network volume 是独立于任何 Pod 存在的永久存储，可以在不同时期挂给不同的 Pod。如果你在选卡那一步已经选了网络卷，这一步的持久化存储就锁定成那个卷了。

部署之前把摘要面板的分项看一遍。 它会列出所选的模板和卡，以及总的每小时费用，并且把 GPU、容器盘、持久化存储、停机状态这四项的成本分开列。具体金额本文不抄（会变），但”停机状态也有一项成本”这个事实本身就值得你在点部署前多看一眼——它意味着停机不等于不花钱。

旧流程的字段略有不同：顶部一排开关里有 Secure Cloud、网络卷、区域、全局网络和额外筛选，还有一个显存下限滑块；配置面板里能选挂几张卡（上限以控制台显示为准）、选按需还是预留实例（预留要联系销售）、以及一个新流程里没直接露出的加密卷开关。Secure Cloud 和 Community Cloud 的可靠性差别、以及加密只覆盖哪一层存储，我在RunPod 是什么那篇里拆得比较细，这里不重复。

卡怎么挑，官方的口径是显存最常见地成为瓶颈。 文档给了一套按模型参数量折算显存的经验方法，还推荐了几个在线计算器（Hugging Face 的模型显存计算器、Can it run LLM、VRAM Estimator）。具体怎么折算、实际部署该留多少余量，见显存估算；卡型之间怎么取舍见GPU 选型。

最后一个容易在深夜踩到的坑：宿主机的 CUDA 版本要跟模板的要求对得上。 文档说如果你看到 OCI runtime create failed 这类报错，处置方式是用额外筛选里的 CUDA 版本条件重新挑机器。机器开起来了但框架起不来，多半是这里。

四、连上去：四种方式各自的边界

文档把连接方式分成四类，差别不只是顺不顺手：

方式	适合	持久性	需要准备
Web 终端	临时命令、调试	会话级	无
SSH	长任务、可靠访问	持久	SSH 客户端
JupyterLab	数据科学、notebook	会话级	取决于模板
VS Code / Cursor	完整开发环境	持久	扩展

Web 终端 零配置，进 Pods 页面展开 Pod 点连接，终端停了先点启动再打开。文档明说不建议用它跑长任务，长任务走 SSH。有个小提示：启动按钮没反应就刷新页面。

SSH 有两种，能力差一截。 所有 Pod 都提供一条基础 SSH，走平台代理，命令形如连到 ssh.runpod.io——但它不支持 SCP 和 SFTP。想要完整 SSH 能力（包括传文件），需要租到支持公网 IP 的实例，并且 Pod 内确实跑着 sshd、暴露了 TCP 22 端口，连接命令走的是连接页里那条”SSH over exposed TCP”。官方 PyTorch、Stable Diffusion 这类模板已经配好了；自定义模板得自己在启动命令里装 openssh-server、把公钥写进 authorized_keys、起 ssh 服务，文档给了现成的一段 Docker 启动命令可以抄。

公钥的注入有时序，这是真坑。 生成 key 用 ssh-keygen -t ed25519，然后把公钥内容贴进账户设置的 SSH 公钥字段（多个 key 必须每个一行，否则只有第一个生效），也可以用 runpodctl ssh add-key --key-file 加、用 runpodctl ssh list-keys 核。关键在于：公钥必须在 Pod 启动之前就上传，系统才会在启动时自动注入到 Pod 的 authorized_keys 里；如果 Pod 已经在跑了再上传，系统不会补做这次注入。 这时候只有两条路——终止重建，或者开 web 终端手工把公钥追加进 authorized_keys。想给某个 Pod 用一把不同的公钥，可以用 SSH_PUBLIC_KEY 环境变量覆盖账户默认的。

如果连接时被要密码，文档的判断很干脆：RunPod 的 SSH 不需要密码，被问密码就说明哪里配错了。 它列的常见原因里，我见过最多的两类是贴错东西——把以 SHA256: 开头的指纹当公钥贴进去了，或者粘的时候漏掉了开头的 ssh-ed25519 类型标识。剩下几类是路径和权限问题：-i 指的私钥路径不对（报找不到文件）、私钥文件权限对其他用户开放（SSH 会拒绝使用）、以及 ~/.ssh/config 里的 IdentityFile 指向了另一把私钥。

JupyterLab 在预置了它的模板上可用（官方 PyTorch 模板都配好了），路径是连接页的 HTTP 服务区点 Jupyter Lab 链接。通过 CLI 创建时要自己把端口以 http 形式暴露出来，起来之后访问地址的形状是 https://[POD_ID]-8888.proxy.runpod.net。认证可以用 JUPYTER_PASSWORD 环境变量设，不设的话有些模板会用一个默认密码、打印在 Pod 日志里——这条顺便说明一件事：Pod 日志是你排查启动问题的第一站。还有个经验值得记：Jupyter 页面白屏超过一两分钟，文档的建议就是重启 Pod 再开，别在那儿干等。

VS Code / Cursor 走 Remote-SSH 扩展（VS Code 装 ms-vscode-remote 的 Remote - SSH，Cursor 装 Anysphere 的 Remote-SSH），前提是模板支持 SSH over exposed TCP。怎么判断？文档给了一个特别实用的识别方法：去连接页看 SSH 那一栏，如果只有一条 SSH 命令，说明你选的模板不支持，这条路走不通，只能用基础 SSH 在终端里干活。Cursor 侧看的是有没有直连 TCP 端口那一段。配好之后用命令面板的连接到主机、添加新主机，连上选 Linux 平台，然后打开文件夹到 /workspace。

这里有个会反复咬人的细节：Pod 停机再启动，端口号可能变，变了就得回去把 SSH 配置文件里的端口改掉才能重连。

顺手记住三个目录的行为差异：/workspace 是默认的持久化目录，/tmp 里的东西停机就清，/root 是 root 用户的家目录。这个差异正是下一节第一条要验证的东西。

五、第一台机器上量之前，先验证这几件事

开出来能跑通 print("Hello, world!") 只说明机器活着。按文档暴露出来的那些边界，我会在扩大投入之前把下面这几条逐个走一遍：

1. 持久化边界自己验一次。 在 /workspace 和 /root 各放一个文件，然后停机、再启动，看哪个还在。这一步能一次性回答”依赖该装在哪""权重该下到哪”这两个后面反复纠缠的问题。文档的口径是停机会释放 GPU、保留持久盘（/workspace）、清空容器盘——但你自己看一眼比记住这句话牢。
2. 确认连接页到底有几条 SSH 命令。 一条还是两条，决定了你能不能 SCP 传文件、能不能接 IDE。这件事越早知道越好，不然等你攒了一堆结果要往下拉的时候才发现传不出来。
3. 要暴露的服务端口在模板里配了没有。 传文件依赖 TCP 22 暴露，你自己的服务端口同理。这类配置在旧流程里是创建时定的，事后改要走编辑 Pod。
4. 两类日志都看一遍。 文档分得很清楚：容器日志是应用的标准输出，系统日志是 Pod 的生命周期事件（启动、关闭、报错）。出问题先看这两处，比在终端里瞎猜快。文档还提到一个具体症状：Pod 卡在初始化，要去日志里找命令错误，另外如果你是靠 SSH 进去干活，容器里得有一个常驻的空转任务（比如 sleep infinity），否则容器跑完就退了。
5. 把停机和终止的区别演练一次。 停机（控制台的停止图标，或 runpodctl pod stop）保留 /workspace 但持久盘仍在计费；终止（垃圾桶图标，或 runpodctl pod delete）会永久删除所有不在 network volume 里的数据。文档在这里用的是最高级别的警告框，不是随口一提。挂了网络卷的话，停机还是终止 /workspace 的数据都在。
6. 给自己上一道定时关机。 文档里有个很实用的写法：sleep 2h; runpodctl pod stop $RUNPOD_POD_ID &，先排好一个到点自动停的动作。对”跑个训练就去睡觉”这种场景，这一条比任何提醒都管用。
7. 余额那两道防线开起来。 低余额告警加自动充值，理由前面说过了——它保护的不只是钱。

这些都过了，再把你真正要跑的服务拉起来。如果是推理服务，多数人的下一步是起一个 OpenAI 兼容端点，那部分见vLLM 起 OpenAI 兼容服务。

六、第一次用怎么控制风险

写到这儿该说反面了。第一次上手 RunPod，我认为风险不在”会不会用”，在下面这几处，而且它们都是机制性的、不会因为你操作熟练而消失。

最大的风险是数据没了，不是钱花多了。 钱这一头有天花板——账户有每小时消费上限，你还能开低余额告警。数据那一头没有天花板：余额归零会触发自动停机，没挂 network volume 的 Pod 直接被终止且不可恢复；容器盘停机即清；volume disk 活不过 Pod 的终止。三条叠在一起的意思是，“我只是忘了充钱”这个动作，完全可能等价于”我的环境和结果全没了”。官方自己也在文档里写了免责：平台不是为长期数据存储设计的，关键数据要定期备份到外部存储。这句话该当真。

先小额，因为额度不可退也不可提现。 这是预付费模型的硬约束。在你验证完这个平台适合你的活之前，充的每一笔都是单向的。

有些决定是在”创建 Pod”那个表单里一次性定死的。 持久化存储选哪种、要不要加密卷、用不用 network volume（它跟机型和机房是绑定的），这几件事事后改要么重置要么重建。表单上多花十分钟，比开起来再折腾划算得多。

别在第一台机器上追最猛的卡。 官方自己给的省钱建议就是从最小可行配置起步、按实际用量再加。第一台机器的任务是验证流程和边界，不是跑出成绩。

然后是几种”这条路本身不适合你”的情况。合规要求把数据锁在境内的，先看这一条再看技术细节，这跟平台好不好没关系。只是想要一个能调的模型接口的，自己维护镜像、环境、连接方式这一整套是纯成本，直接用现成的接口更划算。负载是 7×24 稳定满载的，按时租用的长期账要重新算，这时候该对比的不是别的云而是自建，这部分见GPU 云租用。

最后交代清楚本文的边界：所有事实都来自 RunPod 官方文档，我没有拿账号逐项核对控制台的实际行为。有几处官方文档确实没有明确说明——比如停机后存储费的确切结算周期、余额归零到卷被真正回收之间有多长的宽限、不同数据中心从国内访问的实际网络表现——这些以控制台显示和你自己的账单为准。另外控制台正在推早期访问的新部署流程，新旧两套的字段名和步骤顺序不完全一致，看文档时先确认你在看的是哪一套。按文档定方案，开一台最小配置的机器把你最担心的那两三条验掉，再上量——这个顺序能省掉大部分返工。