决定背后的决定
Webhook 还是长轮询
决定您的机器人是否需要域名、证书和开放端口的是这一点，而不是套餐。
长轮询
您的机器人主动连接 Telegram 并等待更新。不需要域名、不需要 TLS 证书、不需要对互联网开放端口，可在 NAT 之后运行。这是最快让程序跑起来的方式，对大多数机器人而言也是完全可以长期使用的方案。
Webhook
由 Telegram 连接到您。需要公网地址、有效证书和开放端口（这里任何套餐都能满足），作为交换，没有轮询循环，在真实负载下扩展性更好。等负载或延迟提出要求时再切换，不要提前。
算一笔账
一个套餐实际可容纳多少机器人
机器人数量 = (RAM − 操作系统占用的 300 MB) ÷ 单个机器人占用的内存。两列分别对应无状态命令机器人，以及带有 ORM、调度器和缓存的机器人。
| 套餐 | RAM | 轻度机器人 | 重度机器人 | 流量 | 价格 | 部署 |
|---|---|---|---|---|---|---|
| U1-1一个机器人，用户规模不限 | 1 GB | 12 | 4 | 不计流量 | $6.90 | 部署 |
| C1-1-25一个机器人，计流量但便宜 | 1 GB | 12 | 4 | 1 TB | $9.90 | 部署 |
| GL2-4多个机器人，或带数据库的机器人 | 4 GB | 63 | 25 | 不计流量 | $11.90 | 部署 |
| BD-8自建 Bot API 服务器 | 8 GB | 131 | 52 | 32 TB | $12.90 | 部署 |
您的机器人有多少用户并不在这笔账里，因为它本就不是问题所在：Telegram 将更新逐条交给您的进程，而不是为每个用户打开一个连接。真正改变答案的是您自己持有的状态：大型缓存、进程内数据库、模型。
决定账单的数字
瓶颈是媒体，不是内存
平均文件大小 × 每天消息数 × 30。双向都计入：接收的文件同样算流量。
| 机器人传输的内容 | 100/天 | 5,000/天 | 50,000/天 |
|---|---|---|---|
| 纯文本一条命令和一条回复。几乎没有成本。 | < 1 GB | < 1 GB | 3 GB |
| 图片一张压缩图片，发送和接收各一次。 | < 1 GB | 44 GB | 439 GB |
| 语音消息和短视频社区机器人的常见负载。 | 9 GB | 439 GB | 4.3 TB |
| 文档和长视频Telegram 自身对普通机器人的下载上限。 | 59 GB | 2.9 TB | 28.6 TB |
唯一改变机器选择的因素
使用公共 Bot API 的机器人最多可下载 20 MB、上传 50 MB 的文件（这是 Telegram 的限制，不是我们的），且文件不会经过您的磁盘。自建 Bot API 服务器后，上限变为 2 GB，每个文件都会落到您的服务器上。到了这一步，磁盘和流量就不再是次要问题：BD-8 以 $12.90 提供 100 GB SSD 和 32 TB 流量，正是适合的配置。如果您不这样做，就无需为此付费。
常见问题
购买前大家常问的问题。
Telegram 机器人需要多少 RAM？
远低于通常的宣传。机器人是一个长期运行、几乎所有时间都在等待的进程：无状态命令机器人约占 60 MB，带有 ORM、调度器和缓存的机器人接近 150 MB。操作系统占用约 300 MB 后，一台 1 GB 的机器仍可容纳 4 个重度机器人或 12 个轻度机器人。用户数量几乎不影响结果，因为 Telegram 是将更新逐条推送给您的进程，而不是为每个用户建立一个连接。真正会改变结果的，是您自己保存在内存中的状态：大型缓存、进程内数据库或模型。
Webhook 还是长轮询？
先用长轮询，真正需要时再用 webhook。使用长轮询时，您的机器人主动向 Telegram 建立连接并等待：它不需要域名、不需要证书、也不需要开放端口，因此可以在 NAT 之后运行，是最快让程序跑起来的方式。webhook 则由 Telegram 连接到您，因此需要公网地址、有效的 TLS 证书以及一个对互联网开放的端口；作为交换，它完全省去了轮询循环，在机器人确实繁忙时扩展性更好。两种方式在这里最小的机器上都能正常运行。真正值得切换的理由是负载或延迟，而不是潮流。
文件大小限制是多少？
这是 Telegram 自身的限制，不是我们的：使用公共 Bot API 的机器人最多可下载 20 MB 的文件、上传 50 MB 的文件。自行运行 Bot API 服务器可将上限提高到 2 GB，更重要的是，文件会落在您服务器的磁盘上，而不是经由 Telegram 的服务器中转。这是唯一真正改变您所需机器的因素：磁盘和流量突然变得重要，这也是上表把 BD-8 放在这一行、而不是其他行的原因。
带宽会不会用完？
文本机器人，永远不会。媒体机器人则有可能，值得花三十秒算一算：平均文件大小 × 每日消息数 × 30。每天五万条 3 MB 的语音消息，每月约 4.3 TB，超出了大多数廉价套餐的流量额度，但远低于 BD-8 的 32 TB，更不用说不计流量产品线，在那里根本不存在这个问题。双向都计入：机器人接收的文件和发送的文件都算流量。
关闭终端后如何让机器人继续运行？
使用 systemd 单元，而不是 screen 会话。编写一个带 Restart=always 的小型服务文件并启用它，机器人在崩溃和重启后都会自动恢复，无需您守着。这是机器人在 VPS 上"挂掉"最常见的原因，而且并非主机问题：手动启动的进程会随启动它的 SSH 会话一同结束。如果您更想用容器打包，带重启策略的 Docker 也能起到同样的作用。
一台服务器上可以运行多个机器人吗？
可以，而且大多数人都应该这样做。每个机器人都是独立的进程，有各自的 systemd 单元和各自的 token；它们共享这台机器，如您愿意也可共享数据库，此外互不相干。表中的算账正是回答这个问题：一台 4 GB 的机器可容纳 25 个重负载机器人，之后内存才会成为瓶颈。如果它们分属不同的人，请使用不同的端口和不同的用户。
机器人应该运行在哪个区域？
任何您的用户能够访问、且到 Telegram 的延迟合理的地方都可以。机器人与 Telegram 的基础设施通信，而不是直接与您的用户通信，因此通常的“靠近受众”原则在这里不如网站那样重要。如果机器人还要为这些用户提供 Web 控制面板或 API，请改为按这一需求选择区域。如果拿不准，可以在两个区域按小时计费部署，实测后销毁表现较差的那台：每小时 $0.0113，这个试验成本很低。