业务背景及痛点
作为一家综合性的证券金融集团，国泰海通证券在探索数据协同与隐私保护方面始终走在行业前列。
我们技术团队内部在集团推动部署 SecretFlow（以下简称“隐语”）平台，主要出于两个核心动因：一方面是加强集团内部各子公司之间的数据协同能力；另一方面则是希望借助前沿技术在行业中发挥示范与引领作用。
在内部数据协同方面，证券行业对数据的保密性与敏感性要求极高。
即使在同一集团内部，子公司之间若无相关监管机构（如中国证监会）的正式批复或法律法规支持，也无法直接实现客户明文数据的互联互通。
因此，要真正打通数据流通链条，需要一种技术手段，既能保障数据不出域的合规性，又能实现价值的融合与协同——这正是隐语平台所提供的关键能力之一。
例如，我们希望通过数据整合提升集团客户画像的精准度，从而增强业务推荐的个性化能力；又如，在风险控制层面，多维数据联动可以显著提升整体风控水平。这些诉求使我们必须寻求一种能够保障数据安全、合法合规流通的解决方案。
从外部视角来看，国家政策也在持续为数据要素流通与隐私计算提供制度基础。人民银行在《2022–2025 金融科技发展规划》中明确指出，鼓励使用隐私计算技术（如联邦学习）来推动金融数据的安全共享与价值释放，强调“原始数据不出域、数据可用不可见”的技术路径。
这一趋势虽然在证券行业暂未形成强制性规定，但我们预判其将在未来成为技术与监管共识。因此，国泰海通选择在集团层面率先开展隐语平台的应用探索，力求在政策尚未完全落地之前，先行建立起一套可复制、可推广的数据可信流通与隐私保护机制，树立行业实践标杆。
技术目标
在推进隐语平台建设的过程中，我们团队也对“数据可信流通”的理念进行了系统性思考，并设定了四个明确的小目标。这四个目标不仅是我们选型技术平台的核心评估维度，也代表了我们在安全性、拓展性、易用性与可持续性等方面的整体技术战略方向。
安全性
在证券行业，数据安全与隐私保护始终是不可触碰的红线。因此，我们强调平台必须实现“数据可用不可见”的隐私计算能力。这意味着平台在数据流通和协同计算过程中，不仅要保证数据不泄露、不被篡改，还要在全流程中确保其符合合规要求和行业监管标准。
拓展性
数据流通不仅局限于集团内部的子公司与母公司之间，未来必然还会面临跨行业、跨机构的联合协作场景。在这种背景下，平台必须具备良好的边界连接能力，降低接入与集成的技术成本，才能实现数据资源的广泛连接与高效共享。
操作性
我们不希望新平台的使用对业务人员提出过高的技术门槛。如果一项技术的引入需要大量培训、重塑原有的业务流程，往往会带来较大的推广阻力。因此，平台设计应当尽可能贴近现有的用户操作习惯，减少认知负担，实现“开箱即用”。
可维护性
技术的发展日新月异，特别是在大模型浪潮的推动下，数据要素的流通逻辑也在不断演变。在这种趋势下，我们期待建设的隐私计算平台本身能够具备组件化与模块化能力，不断引入新技术、新算子，以维持其在数据流通基础设施中的生命力和先进性。
总的来说，这四个目标既是我们选型隐语平台的内在逻辑，也贯穿了后续建设过程中每一项决策与实践的考量维度。
选择隐语
在明确集团内部存在强烈数据协同需求之后，我们首先启动了针对隐语平台的技术调研工作。在初期阶段，我们发现隐语作为国内领先的开源隐私计算平台，具备完备的技术能力，并且生态活跃，文档体系完善，值得进一步验证其可用性与适配性。
技术预研
第一阶段，我们选择在内部实验室环境中搭建测试平台，开展了一轮系统性的技术预研。我们重点验证了平台在 SCQL 安全联邦查询能力、联合计算 等方面的基础能力，并观察其在真实部署下的兼容性与性能表现。
整体测试结果基本符合预期，为下一步的业务对接打下了技术基础。
实际落地
在评估平台能力的基础上，我们面向业务部门开展了一轮需求调研与场景挖掘，发现了多个具备数据协同诉求的部门。基于这些具体业务场景，我们快速完成了多个原型验证，进一步验证了平台能力在真实任务下的可行性。
当前整个数据互联互通技术栈仍处于发展中的状态，不同平台尚未形成绝对统一。在集团内部的数据协同分析场景下，我们最终选择将隐语作为主要平台，其核心优势体现在两个方面：
- SCQL 的 SQL 兼容能力
该能力大大降低了平台的上手门槛，数据分析人员几乎不需要改变既有 SQL 编写习惯，就可以完成安全多方查询、联合分析的任务。
同时对于数据提供方而言，SCQL 能够很好地控制数据出域的粒度和范围，保护了本地数据资产，减少了对数据供给方的打扰与风险暴露。 - 灵活性与低成本优势
隐语的核心模块开源活跃，更新频繁，能够快速适应新技术的接入需求。同时开源也意味着部署成本和迁移成本相对较低，尤其对于集团内各子公司而言，降低了新平台的认知与接受门槛，提高了集团级的推广效率。
综上，技术能力的成熟度与平台选型的可控性，是我们最终决定并选择了隐语平台。未来我们也期待基于隐语持续拓展更多样化的业务应用与跨机构协作模型。
避坑Tips
在我们首次接触和部署隐语 SecretFlow 平台的过程中，确实遇到了一些挑战，这些经验也希望能为其他企业或团队提供一定的参考。
版本不兼容
一开始我们采用的是隐语提供的完整部署包，其中包含了所有的必要模块。我们选择使用 Docker 进行容器化部署，但过程中遇到了一个让人困惑的问题：容器在启动后没有抛出明确的错误信息，而是直接自动停止。由于没有显式的日志输出，排查过程一度陷入困境。
在深入检查后我们发现，错误信息竟然被打到了配置文件中，而不是标准的错误日志输出中。这一设计稍显反直觉，但最终定位到是由于 Docker 版本过旧，与镜像不兼容。在我们将 Docker 升级到较新的版本后，该问题顺利解决。
指令不支持
在推广过程中，我们也为子公司进行了部署测试。由于子公司普遍采用的是云化服务器环境，其中一部分机器使用了虚拟化 CPU，并指定为 X86 架构。但在部署过程中，平台再次报出错误提示。进一步分析发现，是由于该虚拟化 X86 架构的 CPU 指令集版本过低，无法支持某些涉及浮点数计算的高级指令。
对此，我们联系了云平台的服务提供商，通过调整虚拟机底层配置，启用了对所需高级指令集的支持。从根源来看，这并不是隐语自身的问题，也不是 Docker 的问题，而是由于其底层依赖的镜像操作系统对 CPU 指令集有更高要求。
这些问题虽然在短期内带来了不少调试压力，但也为我们今后更大规模推广平台积累了宝贵经验。平台本身的稳定性没有问题，关键在于部署环境的软硬件兼容性，需要提前评估并规划好架构选型。
解决办法
结合我们的实践经验，下面总结了几种推荐的排查路径，供大家参考使用：
1、官方 FAQ 与 GitHub Issue 是首选路径
通常情况下，如果遇到某个错误信息，可以优先通过以下两个官方渠道进行排查：
- 🔎 隐语官网的 FAQ 页面：涵盖了常见问题与标准解法，建议优先查阅。
- 🔍 GitHub Issue 区：
- 可以搜索是否已有用户遇到过类似问题；
- 如果搜索不到历史记录，可以按照 Issue 模板提一个新的 issue。
注：GitHub 社区活跃，有可能其他用户在看到你的 Issue 后可能会直接帮你解答，因此是一个非常有效的技术支持路径。
2、深入阅读官方文档与源码机制
除了直接排查错误，熟悉平台的设计原理与组件构成，也能更高效定位问题：
- 建议认真阅读官方技术文档，了解组件配置、协议支持、运行机制等；
- 对有一定技术基础的开发者，可以进一步阅读源码，了解隐语的内部工作原理。
3、善用大模型作为信息补充手段
在遇到不确定的问题场景下，使用人工智能也是一种可行的知识补全方式：
- 可以快速获取文档提示、排查思路、相关背景知识；
- 尤其在初次接触某个模块或概念时，大模型可以降低学习曲线。
此条仅供参考，避免大模型出现幻觉导致错误引导。
实践场景探索
在推进隐语平台集团级落地的过程中，我们也探索了母公司与子公司之间的数据协同模式，希望借助隐语平台的能力，实现数据不出域前提下的价值整合与联合分析。
场景探索：集团内客户统一风险识别
这个典型场景的业务目标，可以探索实现总部对客户在整个集团体系下资产规模的整体评估，用于业务场景的风险识别和控制。
通过部署隐语节点后，我们实现了以下流程：
- 数据本地加密入库： 各子公司将客户资产数据加密后写入本地隐语节点。
- 总部发起计算请求： 比如判断客户资产是否超千万，总部只需发起一条统计 SQL。
- 自动拆解分发执行： 隐语平台将 SQL 拆解为多个子任务，在各子公司本地节点执行。
- 结果加密汇总判断： 各子公司本地计算并返回加密中间结果，由总部汇总判断是否满足资产门槛（如是否为高净值客户）。输出仅为“满足/不满足”，不暴露具体资产数值。
通过以上机制，实现了跨子公司资产联合统计分析，同时又能保证每一方的数据隐私不泄露，做到“最小数据暴露”。
推广与试点
为帮助业务技术人员顺利试点落地，我们做了如下准备：
标准化模板支持
针对不同使用场景预设查询模板；
案例驱动
提供行业内类似场景的落地案例（如银行等），激发试点信心与使用灵感；
技术人员扶持
针对子公司技术团队提供指导和部署支持，降低试错成本；
通过这些实践，我们在实际业务中逐步建立了“数据不出域、价值可联动”的数据协同机制，未来也将探索更多实际场景落地，推动集团内外的数据可信流通。
技术延伸探讨
1、有没有计划提供可视化的工具，帮助用户直观理解计算过程与数据保护方式，从而降低上手门槛？
在我们向客户介绍隐语平台原理，或者自己作为从业者去深入学习隐语背后的隐私计算机制时，通常会借助几类工具来帮助理解和说明。
官网提供了 ECDH-PSI 和 逻辑回归（LR）协议的完整可视化演示，这些非常适合在向客户或非技术背景的同事做解释时使用。
从数据加密、加密后数据长什么样、协议执行步骤，再到最后的计算输出，整个过程都有 UI 展示，通俗易懂、直观可信。特别是 PSI，它本身就相对容易理解，在展示数据隐私保护时效果很好。
对于我们这样的开发者或从业者来说，如果要进一步深入研究协议的运行逻辑和执行路径，SPU 作为通用的 多方安全计算（MPC）执行引擎框架，它内置了完整的 Trace 能力。
通过启用 Trace，可以将底层执行的 SPU 算子等关键信息写入文件中，用于后续的调试分析。这对于开发者深入理解协议执行原理、性能瓶颈定位等非常有帮助。
开启 Trace 的方法如下：
在配置 SPU 时，通过如下enable_action_trace和 enable_pphlo_trace
两个参数打开。
具体见FAQ 文档：https://www.secretflow.org.cn/zh-CN/docs/spu/0.9.4/getting_started/faq
2、大模型部署时，如何通过隐语实现模型权重的密态存储与推理加速？SecretFlow-Serving 的 Trace 能力能否覆盖模型推理全链路的隐私保护验证？
所谓的密态存储，其实就是把模型的权重做分片处理。SPU 的底层 MPC 协议就是构建在 秘密数据分片（secret-sharing） 协议之上的，当把这些模型权重随机分片到多个计算参与方，就实现了模型的密态存储。
这种方式下，模型参数在多方之间分布存储，各方持有的是密态信息，不掌握全貌，也就避免了模型参数的泄露风险。
在 推理加速 这块，可以从两个方向思考：
1）系统层面优化
这部分主要是传统的性能优化手段，比如：
- 数据并行
- 指令并行
- 乱序执行
2）算法层面优化
这里分为线性与非线性两类思路：
- 线性优化：比如在同态加密场景下，对编码方式的优化可以提升运算效率；
- 非线性优化：我们尝试在 不损失模型精度的前提下，使用对密态计算更友好的拟合函数。
我们也注意到社区已经有了非常有参考价值的研究成果，基于 SPU 做了密态推理的加速：
Ditto（CIML 2024）和 Nimbus（NeurIPS 2024），有兴趣的可以深入阅读和来社区探讨。
顺带补充一点，前面我们提到 trace 能力，这里有个容易混淆的点，在 SecretFlow-Serving 中的 trace 机制，并不是隐私保护的机制本身，而是一个重要的 系统可观测性工具，故障出现时，帮助定位问题出现在哪一步的。
3、SPU 现在使用 XLA 编译计算图，未来有没有计划使用其他编译器支持国内的框架生态如 MindSpore、PaddlePaddle ？现在社区有支持昇腾NPU 的计划吗？
SPU 当前采用的是 XLA 主要原因有两点：
XLA 的稳定性与社区接受度高 。相比一些定制化的 IR，XLA 已经被广泛应用于 主流框架，其结构成熟、文档完善、调试工具丰富，是我们首选的安全计算编译中间层。
避免从各类 AI 框架前端直接对接的高工作量 。如果要从 MindSpore、PaddlePaddle 等不同 AI 框架的前端直接接入，会面临极高的对接和维护成本。目前我们策略是只对接到中间层 IR，这样可以保证对多个前端的通用兼容性。
因此，像 MindSpore、PaddlePaddle 等框架目前没有计划直接对接 SPU，主要是基于资源投入与回报的综合评估。目前 SPU 的主要瓶颈在通信开销上，后续若遇到计算瓶颈，会考虑 采用 NPU 加速。
4、将密态设备拆分为SPU和HEU背后的设计思路是什么？有哪些优势？
理想情况下，只需要一种 Secure device，MPC或者FHE这些加密协议对上层是不感知的；当前拆分为SPU和HEU主要是因为 HE 对上层 IR 的支持力度有限，长期来看，随着 HE表达能力完备，它们可能会合成一个设备。
另外，Secret Sharing 和 HE 这两个技术有各自的特点。比如说，Secret Sharing 的计算开销不会很大，但是对通信次数很敏感，而加密之后密文特别大，一次传输的通信量比较大，但是它可以减少通信次数。
所以有些情况下会结合起来，大家也可以看到很多算法，比如说SGBoost等，可能会同时用 Secret Sharing和 HE两种技术，对于底层的开发者来说，可以去灵活的组合，但是对于从应用层接入，比如说直接 SecretFlow 接入或者 SCQL 接入，它会根据不同的协议选择底层最佳的计算语言。
所以我觉得优势来说是各个协议之间本身的特点决定的，而底层的协议、算法协议对开发者来说，可以提供灵活的选择。
所以我觉得优势来说是各个协议之间本身的特点决定的，而底层的协议、算法协议对开发者来说，可以提供灵活的选择。
5、 SCQL对x86架构和arm架构上的支持和实现上有区别吗？实现两方SCQL操作和三方SCQL操作底层使用的算子有区别吗？SecretFlow/SCQL 镜像支持 x86 和 ARM 双架构，目前 SCQL 对这两种架构的支持是一样的，没有功能层面的差异。
从使用能力上来说，两者是一致的，但性能表现略有差异。比如 SCQL 中的 join 和 in 操作，是基于 PSI 算法实现的。如果是使用了支持 AVX512 或 AVX2 指令集的 Intel CPU，那么在选择加密曲线和函数的时候，能够通过 Intel 的加密库进行加速。
此外，SCQL 在两方和三方计算时，底层算子的实现也可能会有差异，这取决于采用的 MPC 协议。
如果两方和三方都用 semi2k 协议，那算子就是一样的；但如果三方用了 aby3 协议，那么底层的加减乘除等基本操作的实现方式就不同了。
6、社区未来是否会推出 "信创 + TEE" 的一体化部署套件？包含预配置的国产化环境镜像与自动化适配工具，提升适配速度？
在国产化信创环境的适配方面，其实我们也做过一些探索。在隐语社区体系里，TrustFlow 目前已经实现了对信创平台的良好支持，可以支持 海光 CSV 和 HyperEncalve。
HyperEnclave 是一个跨平台的 TEE 环境，它可以在不同的信创硬件上运行。
如果社区用户或者厂商还有其他信创软硬件适配的需求，也完全可以在社区中提交 feature request。
如果某些国产化平台的厂商自己有能力，也可以直接参与贡献代码，完成适配流程。整个社区对这些适配的态度都是非常开放和欢迎的。
