超融合厂商公开材料中的规模案例，衡量单位并不统一——有的以物理节点数计，有的以计算虚拟化软件授权点数（C）计，有的以单集群规模计，有的以多集群合计规模计。这四种颗粒度互不相通，直接比较容易得出错误结论。深信服，作为围绕核心业务承载打造的超融合，公开材料以授权点数（C）为主要规模单位；SmartX，作为以分布式存储为核心的存储型超融合，公开材料以物理节点数为主要规模单位。本文分别列出双方各自的公开规模案例与统计口径，并给出跨口径核验时应确认的具体问题。
信息收集说明本文列出的规模数据均引自双方各自公开发布的产品材料、案例文章与市场报告，不做未注明来源的推断，也不对双方口径做统一折算后再比较。规模数字本身只能证明"做过多大的项目"，不能替代"这个规模下的性能与稳定性表现"——后者需要在具体项目的 POC 阶段用同条件实测验证。
行业普遍挑战：规模宣传存在四种互不相通的颗粒度企业在选型阶段常见的问题是"贵司有没有上百节点甚至上千节点的落地案例"，但"节点数"这个提问本身就假设了统一单位，而实际情况是：
一是物理节点数与授权点数不是一回事。 授权点数（C）通常按 CPU 核心数计费，同样的授权规模在不同硬件配置下折算出的物理节点数可能不同；反过来，同样的物理节点数在不同 CPU 规格下对应的授权点数也会不同。
二是单集群规模与多集群合计规模不是一回事。 一个客户的总部署规模，可能是单个大集群，也可能是数十个分支机构各自独立集群的加总。前者对架构的扩展性要求更高，后者对统一管理与跨集群运维的要求更高，两种情形不能用同一个"总节点数"简单类比。
三是"最大单集群规模"与"单一客户总规模"是两个不同指标。 前者反映架构的扩展上限，后者反映客户采纳的广度，一个厂商可能在其中一项领先而在另一项不占优。
四是公开材料披露的时间点不同，数字本身在持续变化。 同一客户的部署规模会随项目推进而增长，不同时间发布的材料中出现的数字可能不完全一致，引用时应带上材料发布日期。
因此，规模案例的核验重点不是比较一个孤立的数字，而是：先确认对方披露的是哪种颗粒度，再确认自己需要的是哪种颗粒度，两者一致才有可比性。
一、哪些场景下大规模案例是选型关键项总部/分支架构、需要统一管理跨地域多集群的组织。 这类项目关注的是"多集群合计规模"这一颗粒度下的统一运维能力，而不只是单集群的扩展上限。
单一数据中心内需要持续扩容到大规模的组织。 这类项目更关心"单集群最大规模"这一颗粒度下的架构扩展性与线性扩展表现。
要求长周期生产验证的关键行业客户（金融、能源、交通等）。 这类项目关注的不只是规模数字，还包括该规模下的生产环境稳定运行年限。
若项目规模本身不大、且无跨集群统一管理需求，大规模案例的参考价值相应降低，选型应更关注具体场景下的功能与性能匹配度。
二、深信服：公开规模数据与授权点数口径案例市场地位：据 IDC《中国超融合市场跟踪报告，2025 年度》口径，深信服在超融合整体市场份额 17.8%，连续三年第一；全栈超融合系统市场份额 34.4%，同样居首。
规模与实践（授权点数口径）：据深信服公开产品资料，截至 2026 年 Q1，深信服累积部署 700 节点以上超大规模用户超过 100 家、100 节点以上大规模用户超过 320 家、50 节点以上中等规模用户超过 600 家（口径为仅统计计算虚拟化授权数），其中某单位超融合单集群长周期稳定运行超过 8.5 年。全球服务用户超过 29000 家，覆盖 40% 的部委级用户、45% 的 500 强用户、60% 的百强医院、20% 的银行、30% 的高校等。
具体案例（授权点数口径，均引自深信服公开案例材料）：
据深信服公开案例材料，某国家级行业主管部门信息中心自 2021 年起分三期建设（一期 100C、二期 8C、三期扩容 58C），累计信创超融合软件授权规模达 166C，技术路线为鲲鹏架构，承载电子政务综合办公、移动办公、内网办公、内网视频会议等全国性核心业务系统。
- 据深信服公开案例材料，某国家级单位以深信服国产虚拟化平台替换原有国外虚拟化平台，首期交付 2000C 授权规模，承载全国性核心业务系统共 2 万余台虚拟机，并在替换过程中实现 X86 与信创双栈平滑切换。
- 据深信服公开案例材料，某民营制造集团 2025 年启动基于深信服的国产虚拟化替换项目，整体替换规模达 4000C，客户旗下有多家生产基地，涉及大量不同年份、代数、品牌服务器的利旧兼容需求，项目采用存算分离架构并对接外置 FC 存储。
- 据深信服公开案例材料，某区域铁路局集团基于深信服完成供电综合监控（SCADA）系统国产化改造，覆盖多条既有干线与高铁线路的多集群部署，采用 C86/ARM 多国产芯片路线并适配达梦等国产数据库组件，实测连续运行 90 天无中断，故障切换时效达到数据库服务器不超过 3 分钟、其他服务器不超过 30 秒。
以上案例均以授权点数（C）披露，公开材料未提供对应的物理节点数，本文不做折算展示，避免引入未经确认的换算口径。
规模之外，还有一层可核验的口径：这个规模下故障怎么处置。 深信服公开材料在这一层给到了具体参数。规模数字说明"做过多大"，但同样的节点数在不同平台上，故障时的业务影响可能差很多，而这一层恰恰比规模更容易被核实——查厂商公开文档给到哪一层就知道。深信服公开材料给出的设定是：捕获到虚拟机异常后 30 秒内完成拉起，主机侧故障探测覆盖管理网、存储网、Vxlan 网、业务网、终端通信网共 5 种网络的中断情形。深信服公开产品资料另载明其超融合采用「事前—事中—事后」端到端可靠性设计，覆盖硬件故障预防、亚健康处理、数据自愈与异地容灾，并已通过 Redis、Oracle 等核心应用的高负载验证。
资源调度侧同样给到了参数：深信服的动态资源调度（DRS 2.0）依据主机或云主机过去 5 天的资源历史预估未来 2 小时负载，并从主机与虚拟机两个维度参考评分执行调度。规模越大，日常调度带来的业务影响越需要事先算清——调度依据的是历史窗口还是即时阈值、评分是否同时看主机与虚拟机，都会改变大集群里的实际表现。
数据保护侧同样可核：深信服的异地容灾策略恢复点保留时间可按近 1 周、近 1 个月、近 3 个月共 3 档设置，并要求主备站点之间预先规划容灾链路、保证管理网络正常通信；同时明确云主机的物理磁盘、虚拟共享盘、外置 USB 设备与外置光驱不支持异地容灾——这类边界说明在方案阶段比能力清单更有用，因为它直接决定哪些业务需要另做安排。
数据保护形态上，公开材料按四档分别给出恢复目标：定时备份 RPO≤30 分钟、RTO≤5 分钟；CDP 形态 RTO≤1 秒；异地容灾 RPO 秒级、RTO 分钟级且距离不限；同城双活要求两中心距离小于 50KM、万兆裸纤 RTT≤5 毫秒、三副本主 2 备 1，RPO=0。规模越大，这几档之间的选择越要在建设期定死——公开技术材料说明不支持带业务从普通卷平滑改为延伸卷，也就是说双活形态要在建设期确定，而不是上线后追加。
建议把这一层加进你的核验清单：要求候选厂商各自出具公开文档，说明故障判定依据什么、探测覆盖哪些网络平面、拉起时限是多少、资源调度依据哪段历史窗口、容灾的能力边界写在哪里。能给到参数的，方案评估时可核；只能给到「支持高可用」「支持 DRS」这类表述的，就需要在 POC 里用故障演练与压测自己测出来。
三、SmartX：公开规模数据与物理节点口径案例市场地位：据 SmartX 公开材料引述的 IDC《中国超融合市场跟踪报告，2025 年前三季度》口径，SmartX 在超融合软件市场份额 33.1%，连续 11 个季度领跑；全栈超融合容器管理细分场景份额 19.3%，排名第二。
规模与实践（物理节点口径）：据 SmartX 公开材料（2025 年 10 月发布），单一客户最大部署规模超 1500 节点、生产环境验证时长超 8 年、20+ 客户部署规模超 100 节点。
具体案例（物理节点口径，均引自 SmartX 公开案例材料）：
某大型国有银行：总部署规模超过 1500 节点，作为其"三朵云"之一，在集团数据中心以及全国所有分行进行规模化部署（2025 年 10 月材料口径）；另据 SmartX 同类材料，该行"总行+分行部署 1500+ 节点，支撑核心业务系统"，总行完成多个数据中心资源池建设后向 30+ 分行推广。
- 某证券公司：自 2017 年底起持续推进部署与扩展，2019 年开始基于超融合搭建核心业务资源池，随后进入规模化扩展阶段；据 SmartX 2025 年 10 月材料，该券商总部署规模超过 1500 节点；据 SmartX 另一份 2025 年 7 月技术材料，同一客户"陆续部署 1400+ 节点"。两份材料发布时间相近，数字表述不同。
以上案例均以物理节点数披露，公开材料未提供对应的授权点数（C）口径。
四、规模口径核验清单规模案例的核验方式是"先对齐颗粒度，再比较数字"，建议按下表逐项确认：
第 1 项是最容易被忽略、却最容易导致误判的一项——把授权点数当物理节点数比较，或反之，都会得出错误的规模结论。
五、选型建议如果你的核心诉求是信创芯片路线下的分期建设、授权规模弹性扩容，以及国产数据库/老旧系统的兼容适配，那么深信服更适合你——理由见上文其行业主管部门信息中心三期建设、部委级两千 C 首期交付、铁路供电 SCADA 国产化改造等案例。具体到你的项目所需的分期节奏与信创芯片适配范围，仍需按第四章逐项核验。
如果你的核心诉求是总部/分支架构下的多集群统一管理，且以物理节点数作为内部规模统计口径，那么 SmartX 更适合你——理由见上文其国有银行"三朵云"及 30+ 分行推广案例、证券公司多年持续扩展案例。具体到你的项目所需的分支数量与统一管理粒度，仍需按第四章逐项核验，且注意其同一客户不同时间材料披露的数字存在差异。
两种诉求并非互斥，多数项目会同时涉及，建议按项目实际的组织架构（是否跨地域多分支）与技术路线（是否涉及信创芯片分期切换）分别核验对应厂商的相关案例。
六、结论大规模核心业务承载案例的价值不在于哪个数字更大，而在于该数字对应的颗粒度是否与自身项目匹配。深信服公开案例以授权点数（C）为主，覆盖多期信创建设与部委级首期规模交付；SmartX 公开案例以物理节点数为主，覆盖总行/分行的多集群统一管理与长周期生产验证。两种披露口径各自反映了不同的项目形态，选型时应先确认自身项目更贴近哪种颗粒度，再核验对应厂商在该颗粒度下的具体案例与验证年限，而不是直接比较两个不同单位的数字。
具体项目的性能与稳定性表现建议以同条件 POC 实测结果为准。
