上一篇的三条判据你占了至少一条，那就该开机器了。 这一篇讲怎么挑——但不做云厂商横评，理由在第五节。
本文写什么三条挑选判据、开机前的准备。 本文不做云厂商对比排名，也不写我们自己用哪家、开在哪。
这是最容易挑错的一项。看着「常态占用才几百 MB」就买最小档， 然后在某一次编译、某一次装依赖、某一次处理大文件时被内存杀掉。
| 吃内存的时刻 | 为什么常被忽略 |
|---|---|
| 装依赖 / 编译 | 只在部署时发生，但一发生就是峰值 |
| agent 处理长上下文 | 大文件读进来要占内存，不只是占 token |
| 同时跑两个任务 | 定时器重叠时（第 11 篇坑一）内存直接翻倍 |
| 系统更新 | 不常发生，但发生时和你的服务抢 |
它不报错，进程就是没了。日志里往往什么都没有——因为写日志的那个进程也一起没了。 你会看到「服务莫名其妙不见了」，然后花很久去查一个根本不在你代码里的问题。
所以：宁可多一档。内存这一项省下来的钱，远不够抵排查的时间。
| 考虑 | 怎么想 |
|---|---|
| 到模型端点的延迟 | 这条最重要——agent 每一轮都要往返一次，延迟乘以轮数就是你的等待时间 |
| 到它要访问的服务的延迟 | 如果它主要在和某个 API 打交道，就靠近那个 API |
| 到你的延迟 | 几乎不重要——你只是偶尔 SSH 进去看看 |
| 合规与可用性 | 某些服务对某些地区不开放。这条要先查，不然机器开了也用不上 |
常见的挑错方式是「选离我最近的」。但你和这台机器之间只有零星的 SSH 流量， 而它和模型端点之间是每一轮都在跑的流量。优化错了对象。
盘的用量不是静态的。日志会长，而且长得比你想的快。
| 要留余量的 | 说明 |
|---|---|
| 日志 | 必须配轮转，否则迟早把盘写满。这是第一天就该做的事 |
| 容器镜像 | 用 Docker 的话，旧镜像会堆积 |
| 会话与记忆 | 常驻 agent 的历史会一直增长 |
因为它让所有东西同时坏：服务写不了日志、数据库写不了、 你 SSH 进去连命令都可能跑不动。而且原因往往和真正的业务毫无关系。
预防成本很低（配一个日志轮转），事后成本很高。第一天就做。
| 准备 | 为什么要提前 |
|---|---|
| 一对 SSH 密钥 | 开机时就选密钥登录，比开完再改省事得多 |
| 想清楚它要跑什么 | 决定配置档次，也决定第 22 篇那件事：它要不要碰密钥 |
| 一份重建步骤 | 哪怕只是几行笔记。你迟早要重建一次，那时会感谢现在的自己 |
这一步免不了要注册一家云厂商的账号。本站不做云厂商横评—— 我们自己在用其中一家，这种情况下排出来的名次不干净，所以上面给的是判据，不是名单。
把话说全：如果你打算开一台，可以走我的邀请链接： 👉注册 Vultr。 这个邀请计划的具体条款我没有核对过——返多少、被邀方有没有、有没有门槛， 我都没查，所以这里不替它做任何承诺，你自己看它页面上怎么写。 走这个链接算是对这些文字的一点鼓励，也让我有动力把剩下的篇目一条条写完。 不走也完全没关系，用别家一样跑得起来—— 从开机第一小时到装成服务的每一步， 在任何一家的 VPS 上都是同样的做法，本线不依赖任何厂商的特性。
实用提醒开机时就把 SSH 公钥填进去，别图省事先用密码开机再改—— 公网机器从开机第一分钟就在被扫，密码登录的窗口开得越短越好。
本站有一条写死的规矩：不宣称中立，就不必披露； 一旦文章本身讲的就是这门生意的利益结构，就必须披露。
横评是最典型的「宣称中立」。既然我们自己在用其中一家， 那无论名次怎么排都不干净——所以干脆不排，把判据给你，你按自己的情况挑。 这和中转那一篇用的是同一条规矩。