结论先行：云桌面做完上线，第二年常被拿出来讨论的一个动作是「开不开空闲休眠」。多数人算的是电费，但电费通常不是主要那笔——真正影响预算的是需要采购多少刀片、要买多少并发授权。定策略之前要先量三个数：一天里的在线人数曲线、真实的并发峰值、从休眠到可用的恢复时长。前两个决定能省多少，第三个决定能不能省。
本文只谈云桌面空闲休眠与算力回收的策略判断，不谈终端替换该怎么做，也不谈故障应急处置的具体流程。
休眠省的电费，通常不是主要那笔
一台虚拟桌面在闲置时如果不休眠，仍然占着内存与一部分 CPU 时间片。这个开销是真实的，但摊到单台机器上，一年的电费差额往往在几百元量级。一个几百人的环境，全部加起来可能还不够一次扩容的零头。
真正大的一笔在另一边：因为要按峰值配置算力，所以刀片与许可都得按最高水位买。一个五百人的单位，上午九点半可能有四百八十人在线，下午两点可能只剩一百八十人。如果所有桌面必须常开，算力就得按四百八十人配；如果非工作时段与闲置时段能回收，配置基线可以往下压一大截。
三笔账要分开算
| 账目 | 省的是什么 | 量级判断 |
|---|---|---|
| 能耗账 | 空闲桌面对应的 CPU、内存与机房制冷 | 单台看很小，是长期的小额节省 |
| 算力账 | 所需刀片数量、机柜空间、后续扩容节奏 | 通常是影响预算的主要一项 |
| 许可账 | 并发授权数量、按用户授权与按并发授权的取舍 | 取决于授权模式，按并发计价的场景影响明显 |
把三笔账混在一起谈，最容易得出的错误结论是「休眠省不了多少钱」。单看头一行确实如此，三行一起看结论会反过来。
定策略前要先量三个数
- 一天里的在线人数曲线。不是平均值。要看的是高峰出现在几点、高峰持续多久、低谷有多低。这条曲线决定回收窗口能开多长。
- 真实的并发峰值。注意区分「在线人数」和「同时在用的人数」。有人开着桌面不动，也占着资源；有人频繁登录退出，反而对回收更友好。这两个数往往差三成以上。
- 从休眠到可用的恢复时长。这个数最容易被忽略，也最直接决定策略能不能落地。恢复要两分钟，用户会抱怨；恢复要二十秒，基本无感。
三个数都有了，回收窗口和休眠触发时间才有依据。没有这三个数就定策略，结果通常是「设了 30 分钟休眠，一个月后因为投诉太多又改回常开」。
五种不该被休眠的机器
| 类型 | 原因 |
|---|---|
| 跑长时间批处理的设计与仿真终端 | 休眠会中断任务，重跑成本远高于省下的资源 |
| 承担值守与监控大屏的终端 | 需要常在线，休眠等于让监控失效 |
| 财务、结算等有长事务的岗位终端 | 事务中断后的数据一致性处理很麻烦 |
| 需要保持长连接的终端 | 连接断了要重建，重建过程本身可能触发异常 |
| 作为跳板或中转使用的终端 | 它不在用的时候，往往正是别人需要它的时候 |
这张表要落成具体的排除名单，而不是写在策略文档里的一句话。名单之外再按空闲时长分级：短空闲只关显示器，中等空闲挂起会话，长空闲才释放算力。
恢复时长是那笔隐藏成本
唤醒路径不同，体验差别很大。常见三种：会话级挂起后恢复，通常几秒；虚拟桌面重新开机，取决于系统启动项与镜像大小，几十秒到两分钟；算力已释放、需要重新调度到空闲刀片，还要多一层排队。
所以策略设计上有一条经验：回收算力和挂起会话要分开。上班前半小时把算力预先拉起，白天只做会话挂起，夜间和周末才真正释放算力。这样既拿到了算力账上的收益，又不把恢复时长压到用户白天的工作时间里。另外，批量唤醒要错峰——几百台同时拉起，存储和网络的瞬时压力会变成一次自造的小故障。
怎么写进验收
休眠策略属于可观测的东西，验收时不要只写「已开启空闲休眠」，写三个能核的指标：
- 回收命中率。符合条件且实际被回收的桌面占比。设了规则但没生效的情况很多，常见原因是某类终端被排除名单误伤或漏放。
- 唤醒时长分布。不写平均值，写分布：多少比例在二十秒内、多少超过一分钟。平均值会把长尾盖掉。
- 被中断的任务数。因休眠导致批处理中断的次数，这个数应该趋近于零。它是排除名单准不准的直接反映。
边界与前提
三点说明。其一，文中提到的时长、比例、量级均为描述常见情形的参考值，实际收益与恢复耗时须以本项目的环境实测与 PoC 结果为准。其二，休眠与回收的具体能力（定时休眠、空闲休眠、分级挂起、预拉起等）取决于所采用的桌面云方案版本与配置项，落地前应逐项确认。其三，算力与许可的节省幅度与授权模式强相关，采购前应与商务条款一并核算。
深圳市奇摩计算机有限公司在做桌面云项目时，会把这三个数在试运行阶段先量出来，再和客户一起定回收窗口——先定策略再上线，通常要返工一次。
如果你正在纠结休眠开了会不会挨投诉，预约咨询，可以先从这三个数开始量。