云桌面报容量，别只报一个并发数

结论先行：云桌面的容量有三个口径：并发数、账号数、实际可用的算力。三者在共享架构里可以互相折算，在独占算力的架构里不能——因为每个用户拿到的是一块独立的硬件资源，没有超分空间。报价用哪个口径、验收用哪个口径、扩容按哪个口径，必须一致。

本文只谈容量口径，不谈该选哪种架构。

先说清三种架构的容量含义

共享型虚拟化。多个用户共用同一批服务器的 CPU 与内存，通过超分配把物理资源放大。此时「一千并发」指的是同时在线的人数，背后可能是两百人份的物理资源。

独占算力型。每个用户对应一块独立的计算资源，资源不共享、不超分，性能接近本地设备。此时「一千并发」约等于一千份硬件资源，容量与投资几乎是线性关系。

混合型。普通办公用共享资源，设计与仿真岗位用独占或带显卡加速的资源。容量要分开算，不能合并成一个总数。

一个单位有一千名员工，不等于要准备一千个并发。实际同时在线的比例取决于工作方式：坐班为主、班次统一的单位，重叠率高，可能接近八成；轮班、外勤比例高的单位，重叠率可能只有四到五成。

重叠率估高的代价是资源闲置，估低的代价是早上九点集体登录时卡住。可行的做法是取最近一个月的登录系统实测数据，看每天的峰值在线曲线与持续时长，按峰值加一定余量来定，而不是按人头数。

容量谈判里常被忽略的是每用户规格：几核、多大内存、要不要独立显卡、需不需要本地 USB 与外设重定向。这些参数直接决定单用户占用的资源，也直接决定总数。

一个常见的偏差是以办公用途的规格估算全单位，然后发现设计部门跑不动渲染、研发部门编译慢。规格要按岗位分组报，报的时候把「多少人 × 什么规格」列成表，而不是给一个总数。

报价阶段。写明是并发数还是账号数、每用户规格、以及超出部分怎么加。含不含终端与网络，也要写清。

验收阶段。用真实业务做加载验证：在约定并发下同时打开办公、业务系统和外设，看响应时间是否达标。只看能不能登录，不构成验收。

扩容阶段。写清扩容的最小单位与周期。独占架构下扩容是按整机或刀片加的，采购周期与共享架构不同，这一点要在方案里提前说明。

三点说明。其一，重叠率与规格的实测方法依单位的工作方式不同而不同，本文所述区间仅为示意，须以本项目实测数据为准。其二，性能表现还受网络、存储与终端设备影响，容量达标不等于体验达标，验收应包含端到端体验项。其三，文中所述架构分类为常见形态，实际产品可能有混合实现，具体以方案与实测为准。

深圳市奇摩计算机有限公司在云桌面项目里，习惯把容量拆成「岗位分组 × 每用户规格 × 重叠率」三张表来报，并在验收环节加入真实业务加载验证。预约咨询，可以先按你的人员与岗位分布，把这三个口径对一遍。