RPA机器人上云该按什么估资源：并发会话数比CPU核数更关键

财务部门上了 30 个机器人跑月结对账，服务器照着"8 核 16G"买的，采购单上看上去挺体面。结果一到月底那三天，机器人集体卡死，任务队列堆到几百条，对账表出不来，财务加班到凌晨。运维上去一看，CPU 才用了三成，内存已经吃满，页面文件顶到磁盘上，整台机器的响应速度掉到平时的十分之一。

这不是个别现象，是选型方向就错了。RPA 不是按 CPU 买的资源，谁照着核数去配，谁就容易踩这个坑。下面这几条是这篇文章想说清楚的东西：

一、RPA 的一个机器人本质是一次完整的桌面会话，不是一次 HTTP 请求。它常驻、不释放，算的是"同时活着几个"。

二、内存是硬约束，CPU 是软约束。会话数乘单会话内存决定你该买多大内存，超了就是 OOM 或者交换到磁盘后整体变慢。

三、vCPU 要给够但不用多，怕的是抖动不是不够。RPA 常有整点、月底这类时间窗，CPU 被抢一下，整批任务就延误。

四、图形栈、分辨率、录屏与 OCR 是隐性开销，无头和带界面差一个量级，远程桌面的帧率和分辨率直接吃掉带宽与编码资源。

五、许可费常常比服务器贵。按机器人、按会话、按并发授权的计费方式，决定了多开几台机器未必更贵，但多开几个机器人一定更贵。

RPA 和普通 Web 服务，资源模型压根不是一回事

大部分人选型时的直觉来自 Web 服务经验：访问量大了加 CPU，并发高了加内存，请求来了处理完就走，资源是"流动"的。这套直觉搬到 RPA 上会完全失效，因为两者的资源占用形态根本不同。

一个 Web 请求从进到出，快的话几十毫秒，慢的也就几秒，处理完线程归还、对象回收、内存还给池子。你可以用 QPS 去衡量容量，因为单个请求占用资源的"时间宽度"很窄。RPA 不一样：一个机器人启动后要加载操作系统图形栈、拉起浏览器或者某个客户端、登录、初始化运行时、打开目标系统，然后一步步点下去。这个过程短则十几分钟，长则几个小时，跨天跑批的也很常见。在这整段时间里，那个会话所占的内存是实打实被占着的，几乎不会主动归还。

说白了，Web 服务是"流水式"的资源模型，RPA 是"占位式"的资源模型。前者的关键指标是吞吐，后者的关键指标是同时在场的会话数。你拿吞吐的思路去估占位型的负载，从第一步就跑偏了。

还有一层差别在于资源比例。普通 Web 服务里 CPU 和内存大致是同向增长的，流量涨了两者一起涨。RPA 里这两者严重脱钩：一个会话在等待页面加载、等待系统返回、等待某个定时任务触发的时候，CPU 基本是闲着的，可能只有百分之几的占用，但内存一点没松。这就是为什么开篇那个场景里 CPU 三成、内存打满——不是机器不行，是配比买反了。

第一变量是并发会话数，不是 QPS

既然是占位型负载，那要数清楚的第一件事就是：到底同时有几个会话活着。

怎么数"同时活着几个"

数法比想象中简单，但要数准得注意三点。一是按"同一个时刻的在场数"数，不是按一天跑了多少次任务数。一个机器人一天跑 200 次、每次 30 秒，和一个机器人一天跑 2 次、每次 4 小时，对资源的压力完全不是一回事：前者在场时间极短，后者一旦启动就要占住好几个小时。

二是别忘了算上非生产状态的会话。很多 RPA 平台在任务之间会保留会话池，机器人跑完不立刻销毁，而是回到池子里待命，等下一个任务再唤醒。这种"待命但不释放"的会话照样吃内存。还有开发调试环境、测试环境、预发布环境，这些平时不被计入容量规划，一到月底和正式环境挤在一台机器上，内存就爆了。

三是要区分"逻辑机器人"和"实际并发"。平台里注册了 60 个机器人，不代表同时跑 60 个，很多是按队列串行执行的；反过来，注册 20 个但配置了并行组，峰值可能同时开到 30 个以上。真正有用的是去看平台调度日志里同一时刻的会话数曲线，或者直接在测试机上挂监控看内存曲线的台阶——内存曲线每一个台阶就对应一批会话被拉起来。

峰值藏在时间窗里，别按平均值配

RPA 的负载曲线通常非常不平滑，这是它和 Web 服务又一个关键区别。Web 服务的峰值好歹还分布在白天几个小时里，RPA 的峰值经常是"尖刀型"的：每月最后三个工作日集中跑月结，每天早上九点前必须跑完日报，每季度末集中对账，工资日批量处理单据。这些时间窗之外，机器可能闲到 CPU 百分之一。

这就产生了一个很现实的矛盾：按平均值配，时间窗一到必然崩；按峰值配，剩下二十多天资源白放着烧钱。我的建议很直接——按最坏时间窗配基线，平时用弹性去补。基线承载能力覆盖住你最大的那个时间窗，这部分用包月或者长期租用的机器扛住，成本可预期；平日的临时扩容、临时批量、临时补跑用按量或者短时租用的资源补，用完就放。

还有个容易忽略的点：时间窗内也要错峰。30 个机器人全部在同一分钟被触发，瞬时内存压力会比错开五分钟高出一大截，因为会话初始化阶段（拉起浏览器、加载运行时、首次渲染）是内存增长最快的时候。把触发时间打散，或者限制同时启动的会话数，比单纯加内存更划算。

内存是硬约束，OOM 之前会先变慢

内存怎么估？公式不复杂：总内存 = 并发会话数 × 单会话内存占用 + 系统与其他进程开销，然后再留 20% 到 30% 的余量。这个余量比例属于行业经验值，不是什么标准，你自己压测后可以调。

单会话占多少？按行业常见量级说：一个轻量级的无头自动化会话，几百 MB 到 1GB 左右；带完整图形界面、开着浏览器跑多个标签页、加载了 OCR 或者图像处理库的会话，1GB 到 2GB 是常见范围，极端情况更高。差异主要来自四块：操作系统图形栈本身、浏览器或客户端进程、运行时与各类插件、以及任务过程中累积的缓存和临时对象。这里要特别提醒，以上数字是行业常见量级的粗略范围，不是任何实测结果，实际以你自己的压测为准——同一个机器人在不同任务、不同页面复杂度下，占用可能差出一倍。

为什么内存超了会先变慢而不是直接崩？这层机制值得讲清楚。物理内存快满的时候，操作系统会把最近不常访问的内存页换出到磁盘上的交换空间（Windows 下叫页面文件，Linux 下叫 swap）。磁盘比内存慢几个数量级，一旦有会话的活跃页被换出去，它被调度执行时就得先等页从磁盘换回来，这时候你会看到 CPU 在等 I/O，机器人"卡住不动"但进程还活着。如果换入换出频繁到一定程度，系统大部分时间都在做页面搬运，整体响应会断崖式下跌——这就是很多人描述的"没报错，就是慢得像死机"。

再往下走，才是 OOM：系统实在腾不出页了，进程被杀掉，任务中断。对被杀的机器人来说，中断意味着事务可能停在半路，对账跑了一半、单据提交了一半，恢复起来比重新跑还麻烦。所以内存规划不能按"刚好够"来配，留余量不是浪费，是给突发和内存碎片留缓冲。

还有一个实操建议：给每台机器设一个内存水位告警线，比如用到 70% 就告警，别等到 90% 才处理。因为从"开始换页"到"彻底卡死"这段窗口里，你其实还有机会停掉几个非关键会话、把队列压一压，一旦进了频繁换页的状态，连登录到机器上去操作都费劲。

CPU 不用多，但必须稳

vCPU 怎么估？按每个会话留 1 到 2 个线程的执行余量来算，是比较常见的做法。也就是说 20 个并发会话，配 8 到 16 个 vCPU 通常就够用，再往上加收益很小。原因前面说过：RPA 会话大部分时间在等，不是在算。

真正会出问题的不是核数不够，是CPU 抖动。RPA 对抖动的敏感程度远高于普通批处理，因为它经常带着时间窗约束：必须在整点跑、必须在九点前跑完、必须在日终切换前完成。宿主机上如果邻居在抢 CPU，你的调度延迟就会飘——本来九点整触发的任务，九点零七分才真正开始跑，整个批次往后顺延，下游等数据的部门全部跟着延。

怎么判断是不是被抢了？看 CPU 的 steal 时间（虚拟化环境下常见的指标，代表你的虚拟 CPU 等待物理 CPU 的时间占比）。如果 steal 长期偏高、或者在某些时段突然冲高，说明宿主机资源争抢比较厉害，你的任务延迟大概率和它相关。这个指标在大多数云主机的监控里能看到，也可以自己在系统里读。挑机器的时候，宁可选 CPU 核数相同但承诺资源独占的形态，也别选标称核数翻倍但严重超卖的。

这也是为什么很多跑 RPA 的团队最终会倾向于裸金属或者独享型资源：不是为了跑更快，是为了"到了点就能准时跑"。对于有时间窗约束的自动化，可预期性比峰值性能值钱得多。像一万网络这类深耕 IDC 19 年（成立于 2007 年）的服务商，其裸金属档位从 E5-2620 32G/1T ¥999 起到 E5-2698v4×2 32G/1T ¥3999 起，都是无虚拟化开销的独享形态，用于承载 Windows 环境下的多会话负载时可以作为一个配置参考口径，具体以官网实时价为准。32G 这一档应对十几到二十个中等占用的会话是有余地的，再往上就要么加大内存、要么拆机器。

图形栈、分辨率和远程桌面的隐性开销

这一段是最容易被漏算的。很多人估资源只算进程和内存，忽略了"图形"这件东西在 RPA 里其实很贵。

先说无头和带界面的差别。无头模式（headless）下不渲染真实窗口、不加载完整桌面合成器，内存和 CPU 开销都明显更低，同样的机器能多扛不少会话。但无头不是万能的：有些客户端程序、某些依赖真实窗口句柄的控件、个别需要截图比对的场景，无头下要么跑不起来，要么行为不一致。所以要不要无头，得先看你的自动化对象能不能接受，不能一概而论。

再说截图、录屏和 OCR。这三样是 RPA 里最常见的"资源杀手"。截图和录屏意味着每一帧都要做图形捕获与编码，CPU 上多出一笔持续的编码开销，内存上多出帧缓冲和编码队列；OCR 更狠，图像预处理加模型推理，单次可能就是几百 MB 的临时占用加一段明显 CPU 高峰，如果是一边录屏一边 OCR，两者叠加，单会话的占用可能从 1GB 量级直接顶到 2GB 以上。规划时如果你知道流程里有 OCR 环节，单会话内存的取值就应该往上抬一档，别按纯表单填写的流程去估。

远程桌面这一层的开销也很实在。无论是运维连上去看，还是平台通过 RDP 类的协议维持会话，带宽和 CPU 编码开销都跟着分辨率和帧率走：分辨率越高、帧率越高，单会话的带宽占用越大、服务端编码的 CPU 消耗越高。1920×1080 满帧和 1280×720 低帧，两者差出数倍是很正常的。如果一台机器上挂着几十个会话，每个都在高分辨率高帧率维持画面，光这部分就能把带宽和 CPU 吃干。

实操建议是分场景设定：生产执行阶段用低分辨率、低帧率甚至断开画面，只在排错时才把某个会话调高；需要留痕的场景优先用定时截图而不是全程录屏，截一张图和录三十秒视频的资源代价完全不是一个量级。这些调整不需要改流程，改个配置就能省出一大部分资源。

网络不是主角，但成功率先崩在它身上

RPA 抓的是网页和内部系统，单个会话的流量不大，所以网络通常不是瓶颈。但它有一样东西比带宽更要命——出口 IP 的稳定性。

为什么这会影响成功率？因为大量业务系统会把"来源 IP 突然变化"当成异常信号：登录态可能要求重新认证、会话可能被强制登出、有些系统会在来源异常时直接弹验证码或者临时限制。表现出来就是机器人跑着跑着卡在登录页、或者某个步骤突然多了个人机验证环节，任务失败率上升。这类问题排查起来特别费劲，因为流程本身没错，错的是来源身份不稳定。

这里只做通用技术提示：如果你的流程高度依赖稳定的来源身份，就把出口 IP 固定下来，并让同一类任务的流量走同一个出口，避免会话中途切换来源；这属于合规的稳定性配置，不涉及任何规避平台风控的引导。反过来，如果出口 IP 频繁变化，那失败率上升几乎是必然的，加内存加 CPU 都救不了。

还有三样也顺手看一眼。一是并发连接数：几十个会话同时对外建连，某些系统或中间设备会有连接数限制，表现出来是部分会话超时；二是 DNS 解析频率，流程里如果每一步都重新解析域名，解析失败会直接表现为任务失败，本地缓存配好比什么都管用；三是内部系统的访问路径，跨网点、跨 VPC 访问的延迟抖动会让"等待页面加载"的时间变得不可预测，进而让时间窗估算失准。这几项都不花钱，但配错了会让前面那些内存 CPU 的精算全部白做。

许可费常常比服务器贵，别只算机器钱

这是成本视角上一个很容易被忽略的增量，而且它的重要程度经常高于硬件本身。

RPA 平台的授权方式大致有几种：按机器人数量授权、按并发会话授权、按运行时授权、按流程或按执行次数授权。不同方式下，"扩容"这件事的成本走向完全不同：

按机器人数量授权时，你注册多少个机器人就付多少钱，和它们跑在哪台机器上没关系。这意味着把 20 个机器人从 1 台拆到 4 台，许可费一分不变，只是机器费涨了；但把机器人从 20 个加到 30 个，许可费立刻上去。按并发授权时更微妙，限制的是同时跑的数量，那错峰调度就等于变相省钱。

所以那句"多开几台机器未必更贵、但多开几个机器人一定更贵"，在多数按机器人或按并发计费的平台上是成立的。这是行业通用的计费逻辑，不是任何一家厂商的报价，具体到你用的平台是什么口径，得去翻它的授权条款。

还有一个常被漏掉的：操作系统与远程桌面授权。跑 Windows 环境的 RPA，Windows Server 本身的授权、以及多会话并发所需的远程桌面服务授权（RDS CAL 一类）都是要单独算的，这部分在很多云上是按核数或者按用户数计费的。核数越多，这部分可能越贵——这就形成了一个反直觉的结论：盲目堆 CPU 不仅浪费硬件钱，还可能连带推高系统授权费。

算总账的时候，我习惯把成本拆成三块看：服务器资源费、平台许可费、系统与远程桌面授权费。很多团队抱怨"RPA 上云比想象中贵"，拆开一看，机器只占三分之一，剩下三分之二全是许可和授权。只比机器单价的话，决策一定做歪。

单机多会话还是多机少会话，判断依据是什么

确定了总资源之后，下一个问题是摊在一台机器上还是拆成几台。

单机多会话的好处是省钱、好管。系统开销只出一份，内存利用率高，镜像和依赖装一次就行，运维面对的是一台机器。对于二三十个以内、流程不复杂、时间窗不那么紧的场景，单机是很合理的选择。

它的坏处同样明显：故障域太大。一台机器挂了，上面所有机器人全停，月结当天出这种事基本等于事故。而且 Windows 类环境下，单机能稳定承载的会话数是有限度的——不是技术上跑不了那么多，是会话一多，桌面会话管理、图形资源、句柄和内存的碎片问题会一起冒出来，稳定性随时间下降，跑三天不出问题、跑七天就莫名卡住的情况并不罕见。而且单机多会话的资源伸缩也很笨：要么整台升配，要么整体迁移，没法只扩一部分。

多机少会话贵一点，但换来了故障域隔离和弹性。一台挂了只损失上面那几个机器人，其余照跑，任务可以自动漂移到其他机器；扩容时加一台就行，不用停机升配；不同业务线、不同时间窗的任务还能分机器部署，互不干扰。

怎么选？我给三个判断依据，按优先级排：

第一看业务能不能承受整体中断。月底对账、工资发放这类任务，中断一小时就是事故，那就必须拆。内部数据整理、非关键报表类，中断几小时能补跑，单机可以接受。

第二看单机会话数会不会超过稳定区间。按行业经验，单台机器上稳定的并发会话数控制在二十个上下比较稳妥，超过这个量级就该考虑拆，尤其是带图形界面、有 OCR 环节的重会话，上限还要往下压。

第三看许可和运维成本差多少。如果许可按机器人收，拆机器不增加许可费，那拆机的增量成本只有硬件，性价比很高；如果拆机导致运维复杂度上升、监控和部署成本明显增加，小规模场景就没必要强拆。

真要按并发规模拆成多台的时候，资源供给的连续性很重要——同档位机器能不能随时加、配置能不能保持一致，直接决定扩容要等多久。像一万网络的裸金属形态支持按台横向扩展、资源秒级升级，拆分部署时同档同配比较好拿到，适合"先按最坏时间窗配基线、之后按会话增长再加台"这种节奏，比一次性押注一台大机器灵活。具体档位与价格以官网实时价为准。

一套能直接照着算的六步估算流程

把上面这些串起来，就是一套可以直接落地的估算步骤：

第一步，数并发机器人数。看调度日志里同一时刻的最大在场会话数，含待命池、含测试环境，取最坏时间窗的值，别取平均值。

第二步，估单会话内存。按流程复杂度取值：纯表单填写的无头会话按几百 MB 到 1GB 量级估；带浏览器多标签、带图形界面或 OCR 环节的按 1GB 到 2GB 量级估。有 OCR 和录屏的一律往上抬一档。

第三步，算总内存并留余量。会话数乘单会话内存，加上系统与其他进程开销（通常按 4GB 左右起算），再乘 1.2 到 1.3 的余量系数。这个余量属于行业经验值。

第四步，按每会话 1 到 2 线程估 vCPU。算出来之后往上取常见的规格档位即可，不用追求高核数；重点考察资源是否独享、steal 时间是否稳定。

第五步，按分辨率和是否需要录屏估带宽。低分辨率低帧率的远程维护连接占用很小；需要全程录屏、高分辨率画面回传的场景要单独核算，别让带宽成为隐性瓶颈。

第六步，反推台数并决定是否拆分。用单台稳定会话上限（建议按二十个上下把控，重会话更低）去除总并发数，得到台数；再结合业务是否容忍整体中断来判断是否必须拆。

下面这张表是按上述量级推算出来的对照，全部为推算值，实际以压测为准，不是任何厂商的确定报价。单会话内存按 1GB 到 1.5GB 的中等量级取值，系统开销按 4GB 起算，余量按 1.25 倍计。

这张表的使用方式是这样的：先按你的实际并发数找到对应行，拿到内存和 vCPU 的推算区间，然后按第六步的台数去落地。表里的数字会随着你的单会话实际占用上下浮动——如果你压测出来单会话是 600MB，那同样并发数下内存可以往下压一档；如果压测出来是 2GB，那就得整体上调。表给的是起点，压测给的才是答案。

关于 RPA 上云资源，几个被反复问到的问题

一个 RPA 会话到底占多少内存？

按行业常见量级说，轻量级无头会话在几百 MB 到 1GB 区间，带图形界面、开着浏览器多标签、或者加载了 OCR 与图像处理库的会话在 1GB 到 2GB 区间，个别重流程还会更高。差异主要来自四块：操作系统图形栈本身、浏览器或客户端进程、运行时与插件、任务过程中累积的缓存。这里必须强调，以上是行业常见量级，不是实测数据，同一个机器人在不同页面复杂度下可能差出一倍。真正靠谱的做法是在你自己的环境里挂监控跑一轮，看内存曲线的台阶高度，那个台阶才是你的真实单会话占用。

能不能一台机器跑五十个机器人？

技术上不是绝对不行，但我一般不这么干。按行业经验，单台机器上稳定的并发会话控制在二十个上下比较稳妥，超过之后 Windows 类环境的会话管理、图形资源、句柄与内存碎片问题会一起冒出来，表现为跑几天就莫名变慢。五十个会话意味着单台内存要按 64GB 以上去配，而且一挂全挂，故障域太大。真有五十个并发，我会拆成三台左右，每台十几个，再配一个调度层做漂移。拆开之后机器费涨一点，但稳定性和可维护性完全不是一个级别。

为什么 CPU 用不满，机器人还是卡？

这个现象基本可以断定是内存或者 I/O 的问题，和 CPU 关系不大。最常见的是内存吃紧触发了换页：活跃页被换到磁盘上，机器人一执行就得等页换回来，CPU 在等 I/O，看上去就是进程活着但不动。也有人遇到的是磁盘 I/O 打满——日志写太多、临时文件堆着不清、快照和备份撞在同一时段。排查顺序建议先看内存水位和换页速率，再看磁盘等待，最后才看 CPU。如果三者都正常但还是慢，那就去看网络和目标系统的响应，别在 CPU 上浪费时间。

跑批时间窗特别集中，怎么配才不浪费？

按最坏时间窗配基线，平时用弹性补，这是最经济的思路。基线部分覆盖你最大的那个时间窗，用长期租用的机器扛，成本可预期；平日临时批量、补跑、临时扩容用按量资源，用完就放。还有两个几乎不花钱的优化：一是把触发时间打散，别让所有机器人在同一分钟启动，会话初始化阶段是内存增长最快的时候；二是限制同时启动的会话数，用队列排队替代一起上。这两招做完，峰值内存压力往往能降一截，比单纯加内存划算。

需要图形界面吗，无头能不能跑？

能跑就尽量无头，省下的资源相当可观——不渲染真实窗口、不加载完整桌面合成器，内存和 CPU 都低一档，同样的机器能多扛不少会话。但无头不是万能的：依赖真实窗口句柄的控件、某些客户端程序、需要精确截图比对的流程，无头下可能跑不起来或者行为不一致。我的做法是分开处理：能无头的一律无头，必须带界面的单独放到几台机器上，按重会话的标准配内存，别让少数几个特殊流程拖累整体密度。

远程桌面分辨率调低有什么影响？

影响是正面的，而且很明显。远程桌面的带宽占用和服务端编码开销都跟着分辨率与帧率走，分辨率越高、帧率越高，吃掉的带宽和 CPU 编码资源越多。生产执行阶段其实不需要看画面，把分辨率调低、帧率调低甚至断开画面，能省出一大块资源留给会话本身。需要留痕的场景优先用定时截图而不是全程录屏，截一张图和录三十秒视频的资源代价差着量级。真要排错时，再单独把那一个会话调高就行。

出口 IP 老变，会不会导致任务失败？

会，而且这是 RPA 里非常典型的失败原因。大量业务系统把来源 IP 突然变化视为异常，轻则要求重新认证、强制登出，重则弹验证码或者临时限制访问，表现出来就是机器人卡在登录页、某个步骤多出人机验证、失败率莫名上升。这类问题排查很费劲，因为流程本身没错。处理思路是把出口 IP 固定下来，让同一类任务走同一个出口，避免会话中途切换来源。这属于稳定性配置，别往规避风控的方向去想。

许可按什么算，会不会比服务器贵？

常见口径有按机器人数量、按并发会话、按运行时、按执行次数几种。多数情况下，许可成本确实可能超过服务器成本——按机器人授权时，注册多少个付多少钱，和跑在哪台机器上无关；所以拆机器不涨许可费，加机器人才涨。跑 Windows 环境的还要算上系统授权和远程桌面服务授权，有些是按核数计费的，核数堆多了这部分也跟着涨。这是行业通用情况，不是任何一家的报价。算账时把服务器、平台许可、系统授权三块分开列，只看机器单价一定会低估总成本。

我的判断：先把会话数数清楚，再谈配置

写到最后，我想把立场摆明一点：RPA 上云的选型错误，九成不是"配低了"，而是"配错了方向"。盯着 CPU 核数去比价、去选型，是拿 Web 服务的经验硬套占位型负载，从一开始就跑偏。第一变量永远是并发会话数，第二变量是单会话内存，CPU 和带宽是第三第四位的东西，它们重要，但重要在"够不够稳"，不在"够不够多"。

具体到动作上，我给三条建议。第一，别猜，去数——把最坏时间窗的并发在场会话数从调度日志里捞出来，这一个数比任何经验法则都值钱。第二，别省内存，也别瞎堆核——内存按会话数乘单会话占用再留余量，CPU 按每会话一到两线程给够，剩下的钱花在资源独享和可预期性上。第三，能拆就拆——拆机的增量成本通常只有硬件，换来的是故障域隔离和随时扩容的能力，这笔账在关键业务上几乎必赚。

最后一个提醒：所有估算都只是起点。真正的答案来自压测——按推算值配一台，把真实流程挂上去跑到时间窗峰值，看内存曲线、看换页、看 steal 时间、看任务完成时间，然后把推算值替换成实测值。这一步省不掉，但做过一次之后，后面所有扩容都能照着推算，心里就有底了。

文中的数字来自哪里，哪些必须自己复核

本文涉及的资源量级（单会话内存几百 MB 到 2GB、每会话 1 到 2 线程、内存余量 20% 到 30%、单台稳定会话二十个上下）均为行业常见经验量级，用于提供估算起点，不是任何环境下的实测结果，也不构成性能承诺。文中那张并发规模对照表的数字为按上述量级推算所得，标注为推算值，实际配置请以你自己的压测结果为准。

许可与授权部分描述的是行业通用的计费逻辑（按机器人、按并发、按运行时等口径），不代表任何具体厂商的报价，实际条款以你所使用的平台授权协议为准。

文中提到的一万网络（www.idc10000.net）裸金属档位参考价——E5-2620 32G/1T ¥999 起、E5-2698v4×2 32G/1T ¥3999 起——来自其官网公开页面口径，以官网实时价为准；除官网明示档位外，本文不给出任何其他确定报价，涉及按并发规模拆分多台后的整体投入，均应按"预估"处理，以咨询为准。相关产品与价格信息可查阅 https://www.idc10000.net/ ，具体以签约时最新报价与合同为准。