结论先说：石墨办公文档中台私有部署（Shimo Office SDK，以下简称文档中台）按并发计费，而并发不是“公司有多少人”，是“同一时刻在使用文档的会话数”——打开预览、只读翻阅与协同编辑都占位，编辑只是占比最大的一类。估法三步：从入口清单找出会打开文档的页面，用日志把峰值时段收敛成一个区间，再用试用环境和 PoC 按这个区间加压校准。
单位错一次，后面全错：8,000 人的集团，月末真正同时打开采购合同的可能只有几十个会话；反过来，一个人开三个页签看三份附件，就占住三个会话。把员工总数直接当并发，是最常见的买多原因。一人多端是否各算一个、预览与编辑是否同一口径，这两条要写进方案与合同附件，不靠猜。
一、三个数不能互相替代
采购会上常混着说三个数：账号数（有权进系统的人）、同时在线会话（挂着登录态，含只在翻列表的人）、打开的文档会话（真正占住并发的那一层）。前两个只能当分母，第三个才是要买的数。
第三层还要按动作再分：同一份额度下，纯协同编辑、日常只读查看、批量导入、导出归档的单场景上限并不相同。官网并发计算器把这四类分开给上限，说明“能撑多少人”取决于动作配比。
二、四种接入方式：谁真的占住一个并发
接入方式决定会话从哪里产生，也决定你从哪儿取数。下面四行不是功能对比，是“会不会产生会话”的差异：
| 接入方式 | 会不会占住会话 | 计数上的差异 | 从哪取数 |
|---|---|---|---|
| JSSDK 前端嵌入（编辑器） | 会，是主要来源 | 一次打开通常对应一个会话，编辑动作叠加协同负载；具体计数以开发文档为准 | 文档侧会话记录、回调日志 |
| JSSDK 前端嵌入（只读预览） | 会，但单场景上限更宽 | 停留短、并发高；是否与编辑同一口径需确认 | 预览打开记录 |
| JSAPI 与服务端 API | 不一定 | 创建、导入导出、格式转换走服务端；是否并入编辑口径以开发文档为准 | 接口调用日志、任务队列 |
| 事件回调 | 不产生会话 | 本身不打开编辑器，却是统计会话最靠谱的数据源 | 回调日志 |
入口列全，并发才有分母：一个 OA 里可能有三处能打开文档，漏一处，峰值就低估一截。
三、三步算出峰值并发
- 先划峰值窗口，不看日均。月末、季末、审批截止前的一到两小时才是要买的数。把打开记录按 5 分钟聚合找最高点。
- 数会话，不数人。同一时刻开着的会话＝累计打开数 − 已关闭数。一人多端、多页签算一个还是多个，先与方案团队写进附件，否则 PoC 做完仍对不上。
- 乘人均份数，再留增长。峰值并发 ≈ 峰值时段打开文档的人数 × 人均同时打开的份数 × 多端系数。十二个人改同一张汇总表就是十二个会话，这点最常被漏掉。
没有日志时可用公开比例做数量级校验，但别当答案：永中 DCS 评估方法给“日活≈用户数×10–20%、并发≈日活×10–20%”，其并发指文件转换并发，与本篇会话口径不同；ONLYOFFICE 的说明提醒一人可能同开多份文档、连接数不足时用户退化为只读。比例强依赖业务节奏，只用来查数量级错误。
官网计算器的输入是硬件配置、业务场景、操作行为配比（导入、导出、阅读、编辑）与文件类型配比；输出是预计席位规模、综合并发与四类单场景上限。它最有用的不是给一个数，而是把“综合”与“单场景”分开：月末截止和批量归档撞在同一小时，按单一场景的余量买就会不够。
四、PoC 怎么验这份账
算出来的数只是假设，要用真实文件、真实权限校准。分工先写清：文档中台提供可嵌入的编辑器、协作、转换与事件回调；接入方仍负责身份权限映射、业务入口、事件消费与异常处理，并发与复杂文件表现以技术文档和 PoC 为准。
别只测“能打开”，四类场景各跑一轮，记录口径统一：
| 场景 | 怎么造负载 | 通过条件（示例写法） | 与计费核对相关的记录 |
|---|---|---|---|
| 单文件多人协同 | 真实汇总表，10–12 人分区同时改 30 分钟 | 不丢修改，冲突提示符合预期 | 实际会话数、失败次数、保存耗时 |
| 峰值批量打开 | 从区间下限逐档加到上限，每档 10 分钟 | 目标负载下成功率与耗时在约定范围 | 每档会话数、耗时分布、失败率 |
| 大文件与复杂版式 | 脱敏样本按大小与复杂度分组 | 版式还原符合约定，打印导出无错位 | 文件清单、分组结果、差异截图 |
| 转换与导出队列 | 编辑中同时提交批量 PDF 或 OFD 转换 | 编辑不受明显挤压，队列能排空 | 队列长度、排空时长、完成率 |
第三列的数值必须由双方测前填好，否则只剩一条“看起来还行”的曲线；第四列是与计费核对相关的最小集——没有实际会话数与失败数，续约时解释不清当初为什么买这么多。
五、余量怎么留，降级怎么写进方案
并发按年买，余量要说得清来源，不是按心情加两三成：
- 先用试用版校核小场景。30 天试用、30 并发可先验单文件协作、权限与格式；区间上限高于 30 时，加压放到商业版环境做。
- 按系统分批接。商业版 30 并发起售、含 5 个应用接入，新增应用另计；先接一个高频系统跑一季度，再定第二批。
- 把降级写进方案。会话用满时排队、只读还是报错，由接入方实现并给明确提示；这部分策略不在并发额度里，需求方要签字确认。
- 按周期复核。峰值并发、失败率、单文件协作人数每季度看一次；下一个采购周期按实测定档，中途扩容或降档属商务条款，需与方案团队确认。
边界讲明：并发不等于员工数，不能用员工总数替代并发；档位与计费以文档中台定价页和合同为准。完全离线部署、表格行级权限不在本文范围，需与方案团队确认。
常见问题
并发和在线用户数是同一个吗？
不是。在线用户数只说明有人挂着登录态，可能只在翻列表；并发数的是同一时刻使用文档的会话，打开预览与协同编辑同样占位，只是单场景上限不同。
峰值怎么算？
取业务最密集的那段时间，把打开记录按 5 分钟聚合找最高点，再乘人均份数与多端系数。别用日均乘固定倍数，倍数因业务而异。
估多了浪费怎么办？
先小后大。用 30 天 30 并发的试用版验完功能与小场景，商业版从 30 并发起售档进入，先接一个系统；每季度用日志复核峰值与失败率，下一个采购周期再按数据定档，中途调整需与商务确认。
只做预览、不做编辑，也要按编辑并发买吗？
预览同样占用额度，只是单场景上限比协同编辑更宽，官网计算器把“阅读为主”与“纯协同编辑”分开给上限。最终按哪种口径计量需与方案团队确认，别自己按编辑档位折算。
要算出写进预算的数，建议备三样材料：接入入口清单、一段峰值时段的打开记录、三五份真实脱敏文件。文档中台私有部署的能力与边界可先看产品页，接入方式参考系统集成方案；备齐后预约演示，让方案团队按你们的动作配比复核这笔账。也可以先看私有化部署方案，了解部署形态与交付范围。