扩规模最常见的三个翻车形态
超卖。厂商报”一台机开五十个实例”，按上限摆满，没有留给宿主机系统和网络的余量。账面机器数省了，每个实例都在卡顿里运行，一线把时间全花在等加载上。
混池。长期经营账号和测试号、临时号挤在同一台机上，共用出口和参数模板。测试组今天压测把出口刷爆，明天经营号的登录环境就跟着异常；出问题时根本说不清谁影响了谁。
克隆到底。为省搭建时间，一台参考机批量克隆到底层标识全部相同——前面讲过，几十个实例共用一套设备特征，在平台眼里就是一台机器的多块屏幕，账号独立无从谈起。要克隆可以，克隆后逐台重置参数、各绑唯一线路，一个都不能省。
单机承载怎么定：先做压力口径，再打七折
规划从两个问题开始：单个实例的常态资源占用多少（内存、处理器、显存各算），宿主机要留多少余量给系统、代理通道和突发。余量不是浪费，是稳定性的定价。一个可执行的做法：先以”画面流畅、操作跟手、语音不卡”为通过标准，把单实例逐台加到临界，记录临界值；生产配置打七折——临界二十个实例的机器，日常只开十五到十六个。账面少开两成，换来的是晚高峰不掉线、实例之间不互相挤。
实体机与云手机的分工
实体机性能可控、长期成本摊薄，适合常年稳定经营的主力号池；云手机按实例租用、弹性扩缩、自带独立出口，适合项目制和波动大的量级。两者混用时，台账里同等对待——一个经营账号只归属一个环境，规则不因载体不同而放宽。选云手机重点看网络模式是否为独立出口、批量操作接口能否与自家台账对接、实例参数能否逐台自定义。
扩张五步
号池从五十扩到两百，按这个顺序，不要并行抢进度：
- 需求定型：长期号与短期任务分开算，长期号按”一号一线”预留，短期任务按并发量买动态池；
- 线路先行：新线路先全量验收——连通、抖动、丢包、会话保持、归属一致，空跑一周；
- 环境后建：新机或云实例上线，逐台重置参数、绑定线路、跑验证清单；
- 小批进号：先放边缘号跑一个完整周，全天正常再扩下一批；
- 留观察期：每批复核台账一致性与晚高峰数据，无异常再动下一批。
五步里最容易被压缩的是第二步和第五步，而出事后返工最多的也正是这两步。
成本怎么排
设备是一次性投入，线路是持续成本——超卖省的是前者，省错了则把成本转嫁给后者：实例卡顿导致动作超时、会话频繁重连，消耗的是账号状态和人力，这些都不在任何一张采购单上，却最贵。合理顺序是：长期号的承载宁松勿紧，短期任务的承载可以压满；两者混在同一条线上，长期号会先出问题——任务型实例的高并发把出口刷满，长期号的会话保持和延迟双双失稳，环境一致性也随之被破坏。
规模带来的从来不只是产能：环境越密，一次错误影响的半径越大。设备规划的每个留余量的决定，都是在给未来的排查省事。