结论：500 人并发和日转 2 万份是两个量，必须分开估、分开买。并发是“同一时刻有多少人在改稿”，决定编辑侧的授权与资源；日转是“一天有多少份要转换归档”，决定转换队列、失败重试与值班。把两者合成一个“系统够不够强”的问题，报价一定对不上。四家加我们的公开口径差别也在这两处：谁能承接转换，谁在做版式件签批。
下文先拆双负载，再同口径对照五方，最后给公文侧三件事与什么情况选对方。官网没写的，一律标“需确认”。
一、双负载：并发看同时，日转看总量
并发侧要回答“峰值那一刻多少人在编辑同一批稿子”；日转侧要回答“两万份在多长窗口内转完、失败多少、谁重跑”。两者的单位、样本与扩容方式都不同。
| 负载 | 怎么量 | 换算要点 | 验收动作 |
|---|---|---|---|
| 并发侧（500 人在线编辑） | 取发文高峰时段，数真正在编辑的人与同一份稿上的协作人数 | 并发是同时使用数，员工总数对应席位，不能互相替代 | 用真实公文跑一次多科室同时改，记保存失败与冲突 |
| 日转侧（日 2 万份归档转换） | 取近三个月日峰值份数与到达分布，标出集中在哪几个时段 | 先折成峰时每小时份数，再看单份耗时与重试，最后乘冗余 | 用真实公文批量跑一轮，留失败清单与重跑记录 |
| 叠加与冗余 | 看两万份的日子是否撞上发文高峰 | 转换与编辑抢同一批 CPU 时，峰值不是相加而是互相拖慢 | 在叠加时段做联合压测，分别记两条曲线 |
第三行最容易被忽略：月末既集中发文又集中归档，两个峰值叠在同一天。要么把转换排到夜间窗口，要么把转换节点与编辑节点分开部署，这条要在方案里写死。
二、五方公开口径对照：转换与签章不在同一格
| 方案 | 并发与授权 | 转换与 OFD | 公文与留痕 | 签章与盖章 |
|---|---|---|---|---|
| 石墨办公文档中台私有部署 + 石墨办公单机版 | 按并发授权，30 并发起售，含 5 个应用接入 | 业务系统里的 OFD 转换与在线预览由文档中台负责；终端编辑与双向转换由单机版负责（官网标注即将推出） | 提供公文模板，支持在线起草、多人会签批注、全程留痕 | 公开能力范围不含 OFD 签章、批量盖章、骑缝章与套打 |
| WPS 系（政务方案与在线编辑开放平台） | 以官方报价与授权说明为准 | 政务方案写流版一体，基于 OFD 与 PDF 组件提供版式能力 | 政务方案写公文排版与公文套红 | 官网未见签章与批量盖章的公开表述，需以其文档为准 |
| 永中 | 以项目授权为主，需确认 | 官方写版式与格式兼容度高、支持历史版本；UOF 与 OFD 是否支持需以其官方文档为准 | 其官方公开页未逐项展开修订跟踪、批注与留痕，需以其官方文档为准 | 需以其官方文档为准 |
| ONLYOFFICE Docs | 自托管，计量方式以其定价页为准 | 以其文档为准 | 以其文档为准 | 以其文档为准 |
| 数科 OFD | 以项目授权为主，需确认 | 官网写电子公文在生成、加工、阅读、签批、盖章、管控、归档、发布各环节提供支撑 | 其网页轻阅读系统写在线协同签批 | 其文件转换迁移系统页列出数字签名、批量盖章 |
读表顺序：先看“签章与盖章”一列谁有公开口径，再看“公文与留痕”一列谁写到会签批注。格里留白不代表没有，只代表公开材料没到这一层。单机版的获取方式与版本以官网发布说明为准：官网当前标注即将推出，开放下载时间以官网页面为准，不要把它当成已可交付的现货组件写进方案。
三、公文侧的三件事：模板、会签、归档格式
- 模板：红头、版心、字号固定在受控母版里，起草人只填内容；母版只留一个维护入口。
- 会签与留痕：会签阶段用评论与修订留意见，定稿前清痕；清稿后导出 PDF 或 OFD 作正式件，过程稿单独留存。
- 归档格式：归档库只收 OFD 原件，PDF 作阅读副本单列；两份不要混在同一层。
这三件事与“能不能盖章”是两条线：模板与会签解决“稿子怎么定”，签章解决“件怎么生效”。后者边界要提前讲清——我们公开写的是公文模板、在线起草、多人会签批注与全程留痕，OFD 签章、批量盖章、骑缝章、套打不在其中；流程要求盖章时，需把签章环节单独评估，与文档系统通过文件交换衔接。
四、什么情况选对方
- 核心是 OFD 版式件的签批、盖章与归档管控 → 数科 OFD 这类版式产品线的公开口径更对口。
- 已在 WPS 办公体系内，要政务门户、公文套红与流版一体 → WPS 系方案更顺。
- 有开源运维能力，编辑以 OOXML 为主、转换需求不重 → ONLYOFFICE Docs 可自托管。
- 公文以嵌入方式跑在既有 OA 里，预算与人力有限 → 永中这类嵌入型组件更省事。
- 要公文模板、在线起草、会签留痕，同时要业务系统里的 OFD 转换与预览 → 按文档中台私有部署产品页评估，终端侧看单机版产品页，整体链路见公共服务行业方案。
两万份的日子还要问一句：转换是同步返回还是排队异步？同步接口在两万份时最容易把业务系统拖住；异步队列则要问状态回传、失败重试与幂等。这一条比“支持多少格式”更影响值班强度。
常见问题
并发和日转量怎么分开估？
并发按峰值时段人数与同一份稿上的协作人数估；日转按日峰值份数、到达分布与单份耗时估；最后看两个峰值是否撞在同一天。前者定编辑侧授权，后者定转换队列与值班。
痕迹和套红谁管？
痕迹与会签由协作侧承担：会签留评论与修订、定稿前清痕，过程稿与正式件分开存。套红由受控模板承担：红头固定在母版，正文定稿后并入。两者都不依赖签章，菜单位置以部署版本为准。
OFD 归档怎么落？
归档库只收 OFD 原件，PDF 作阅读副本单列；业务系统里的 OFD 转换与预览由石墨办公文档中台私有部署负责，终端上的编辑与双向转换由石墨办公单机版负责。批量任务要留失败清单与重跑记录。
签章要不要另买？
公开能力范围不含 OFD 签章、批量盖章、骑缝章与套打，因此这部分不能算在文档系统里。若业务要求盖章，需把签章产品或服务作为独立环节评估，再约定文件交换与回传方式，具体按项目确认。
把近三个月的发文高峰、日归档份数与二十份真实公文准备好，让各家按同一份双负载口径回答，比对着功能表打勾快。要按你们的峰值核一遍，可以预约演示。也可以先看私有化部署方案，了解部署形态与交付范围。