【隐语SecretFlow用户案例】亚信科技构建统一隐私计算框架探索实践

作者：亚信科技高级研发工程师 阳仔 蚂蚁密算技术专家 操顺德

排版整理：社区贡献者 曾辉

📖 本文整理自亚信科技高级研发工程师阳仔与隐语社区 Maintainer 操顺德的技术对话。 他们围绕隐语（SecretFlow）在隐私计算、性能优化、互联互通、安全体系以及可信数据空间方向的探索展开了深入讨论， 全面展示了隐语在数据要素时代下的技术演进与产业落地。

引言

在数据要素市场化的浪潮下，我们内部技术面临一个根本性矛盾：既要充分释放数据的流通价值，又必须坚决守护数据主权与隐私安全。而隐私计算技术，正是破解这一矛盾的核心路径。

它旨在实现“数据不出域、价值可流动”的全新范式，确保原始数据不泄露的前提下，实现其计算价值的安全流通。

因此，在国家将数据确立为关键生产要素的战略背景下，发展以隐私计算为关键支撑的可信数据空间，已不再是技术选项，而是构建未来数字经济的必然选择。

为什么选择隐语

在隐私计算领域中，如何选择一个既稳定又高性能的框架，是每个技术团队在产品初期都会面临的问题。

其实我们团队早在两年前便关注到隐语及其核心项目SecretFlow。今年初，为打造具备隐私计算能力的新产品，我们在技术选型阶段对多个开源引擎进行了调研以及综合评估。

最终，在进行了一系列压力测试与性能评估之后，我们发现隐语在性能表现上明显优于同类框架，这成为我们最终选择隐语的重要原因之一。

如何发现隐语？

当初我们发现隐语的渠道也非常自然：

• 一方面是通过隐语社区官方公众号了解了社区的最新动态与使用案例。
• 另一方面是通过GitHub 社区浏览开源项目时发现；

技术选型

当然，性能只是我们考虑的一个指标。 在深入研究的过程中，我们也从技术架构设计和团队工程审美的角度，对隐语进行了全面评估。

隐语给我们留下最深印象的两个特性是：

体系全面性

隐语的技术栈设计全面，系统性地覆盖了隐私计算的核心技术路径与支撑平台。

其能力不仅包含多种基础技术引擎，如安全多方计算（MPC）、联邦学习（FL）、差分隐私（DP）以及可信执行环境（TEE），还提供了面向业务的高级语言SCQL（多方安全数据分析）与统一的任务调度框架Kuscia。

这种从底层算法到上层编排、从通用计算到专用语言的完整技术体系，使得我们在应用落地时无需组合多个异构框架，即可获得开箱即用的系统化能力。

模块化设计的高内聚与低耦合

隐语的模块化理念非常成熟，各组件既能独立使用，也能灵活组合，这对二次开发与定制化场景尤其友好。

例如，它的架构中将密态计算设备与密码学实现完全解耦：

• SPU：密态计算设备，负责MPC场景下的密态算子执行。
• HEU：同态加密设备，封装BFV/CKKS等方案，支持密文状态下的加法和乘法运算。
• YACL：通用密码学基础库，封装各类密码学原语实现。

得益于这种设计，我们可以在不依赖上层系统的情况下，单独引用 SPU 或 HEU 的动态库，实现自定义开发或轻量级封装，这一点在很多其他框架中并不常见。

它不仅包含底层的密码学库，还提供上层的 All-in-One 解决方案 SecretPad，无论开发者从哪一层接入，都能灵活适配隐私计算的不同需求。

基于隐语的典型应用场景

亚信科技围绕隐语技术栈打造产品与解决方案，并在多种业务场景中成功实践，其中有一个经典“银行信用卡精准获客”案例：基于隐私计算的联合营销——运营商与银行的精准客户触达

业务背景与痛点

银行方的需求：

信用卡中心希望找到潜在的高价值客户，特别是那些有消费能力、可能对高端信用卡（如航空联名卡、购物白金卡）感兴趣的用户。

传统方式（如广撒网式的广告）成本高，转化率低。银行拥有用户的金融交易数据（存款、理财、交易地点），但缺乏用户的实时消费行为、兴趣偏好、地理位置轨迹等立体画像。

运营商方的需求：

运营商（移动、联通、电信）拥有海量的用户行为数据，如：App使用偏好：频繁使用旅行类App（如航旅纵横、携程）、经常出入高端商圈/机场火车站。

消费能力：月话费支出、使用高端手机。

位置信息：经常进行跨省/国际漫游。

运营商希望将这些数据价值变现，但受《数据安全法》和《个人信息保护法》的严格限制，绝不能将原始用户数据直接提供给银行。

核心矛盾：银行需要运营商的数据来完善用户画像，但运营商不能也绝不应该给出原始数据。

隐私计算解决方案（以“联合建模”为例）

双方采用隐私计算技术（例如联邦学习）构建一个联合模型，整个过程“数据不动，模型动”。

第一步：数据对齐（在隐私计算节点内）

银行和运营商需要确定一个共同的目标用户群体，但不能直接交换用户名单。

采用隐私集合求交技术：双方各自加密自己的用户ID（如手机号的哈希值），在不暴露非重叠用户的前提下，仅找出既是银行客户又是运营商客户的用户群体作为建模的样本基础，原始ID不会泄露。

第二步：数据预处理和特征工程

银行侧：在自己的安全节点内，通过预处理及特征工程，完成特征数据准备，如：年收入区间， 历史信贷表现， 当前持有卡等级。

运营商侧：在自己的安全节点内，准备特征数据，如：常用App类型， 月度话费档次， 主要活动区域。

第三步：联邦建模

1. 模型初始化 双方根据联合建模的目标（如信用评分）确定模型结构，例如逻辑回归、决策树或神经网络，并各自用本地特征初始化模型参数。整个过程通过联邦学习框架来实现。
2. 协同训练 在不共享原始数据的前提下，银行和运营商分别用自己的数据计算局部梯度或中间结果。然后，通过加密技术（如同态加密、秘密分享等）将这些中间结果安全地交换给对方或第三方协调节点。这样双方可以协同完成一次参数更新。例如，在纵向联邦下，银行拥有标签，运营商拥有部分特征，双方需要通过安全协议协同计算损失函数和梯度，然后各自更新本地模型参数。
3. 模型参数更新与收敛 双方反复进行上述协同训练过程，每轮都交换必要的加密中间结果并更新参数。训练过程会持续到模型评估指标（如AUC、准确率等）达到预设标准或损失函数收敛为止。

重复步骤1~3，直到模型收敛，形成一个高性能的“高价值客户预测模型”。银行后续利用该模型对新用户进行预测，模型会输出一个“潜在价值评分”，银行可以根据这个评分，对高价值客户进行精准的电话营销或推送专属办卡优惠。

性能优化实战

隐私计算的底层离不开大数据处理与机器学习场景。无论是 联邦学习（Federated Learning） 还是 多方安全计算（MPC），性能优化始终是绕不开的关键问题。

以联邦学习为例：

• 当训练一个实际可商用的模型时，数据量往往达到千万级样本、上百维特征；
• 模型需要多轮迭代才能收敛；
• 若再叠加加密通信、梯度交换、密态传输等隐私保护机制，其计算复杂度与通信代价会呈倍数增长。

因此，隐语的性能优化必须兼顾：

1. 数据规模；
2. 模型复杂度；
3. 网络通信与硬件性能；
4. 安全协议的密态计算代价。

以下是我们亚信团队在实际落地隐语（SecretFlow）过程中的多层优化实践，希望可以抛砖引玉，给大家带来更多的思路和想法。

本地预处理

因为涉及到加解密过程，密态计算相对明文计算耗时更高，因此优化的第一原则是：尽量在联合计算或训练之前在各自节点内完成一定程度的数据清洗、特征处理、标准化等预处理操作。

实践要点

1. 数据清洗-缺失值填充/剔除
2. 数据清洗-异常值检测与修正
3. 低价值字段剔除（如方差<0.01的特征）
4. 特征预聚合
5. 特征降维

这种 "本地先行"的策略，能显著减少：

1. 网络传输数据量
2. 磁盘读写数据量
3. MPC/FL过程中的计算量

从而整体减少运行时长。

从算法层面减少负担

联邦学习的计算复杂度不仅取决于数据量，还取决于模型的结构复杂度。

优化策略：

• 采用特征探查与特征降维

通过类似基于联邦或者tee技术下的联合探查，协同筛选出贡献比较大的特征，降低特征维度

• 在模型层面选择更轻量的算法，

优先使用线性模型，若需神经网络，尽量采用浅层网络，避免深层或复杂模型结构，降低通信与计算开销。通过 简化模型 + 精选特征的组合策略，可以在不明显牺牲精度的前提下，大幅减少迭代轮数与训练耗时。

算力、存储与带宽

隐私计算场景既是 CPU 密集型，又是 IO 密集型，性能瓶颈往往出现在通信带宽与磁盘 IO。

实践建议：

隐语框架的性能优势在资源充足时尤为突出，其表现不仅得益于多核并行计算，更关键的是对网络带宽和磁盘I/O效率的显著优化。

计算优化原则

在隐语自身开发与协议设计过程中，性能优化遵循一个通用原则：在保证安全与正确性的前提下，尽量减少密态下的计算与边界转换。

要点：

1. 计算优化：恪守“明文优先”原则，将数据预处理等能在明文阶段完成的计算，置于密态计算之前，从源头降低计算复杂度。
2. 通信优化：优化协议流程与网络交互，尽可能减少多方之间的通信轮次与数据传输量。
3. 硬件优化：充分利用硬件资源，包括采用多核CPU并行计算、专用硬件加速卡（如GPU/FPGA），以及高性能固态硬盘（SSD）来提升I/O效率。

这一原则几乎适用于所有隐私计算框架，是业界默认的性能优化共识。性能是隐私计算产品的“生命线”。

在传统的大数据或 AI 模型训练中，性能优化能提升效率； 但在隐私计算中，性能更是 产品可用性与商业可行性 的关键指标。

经验数据：

• 普通本地训练：约需 1 小时；
• 联邦多方密态训练：若无优化，可能需 3～5 倍时间；
• 通过上述策略优化后，可显著缩短任务时长并保持稳定性。

隐语在这一过程中表现出极佳的性能优势。结合合理的工程策略与硬件规划，隐语的性能不仅达到了业界先进水平，也让产品在商业落地中具备更强竞争力。

技术挑战

全面性与复杂度并存

刚才有介绍过隐语是一个 All-in-One 架构，里面描述的每一个方向都可以独立做成一个复杂产品，且都属于非常专业的领域（例如密码学、同态加密、分布式调度、联邦学习算子等）。

对于企业级产品落地来说，不是“简单集成”，而是深度整合与产品化，需要做适配、场景化扩展及二次开发。要做到这些，团队必须透彻理解隐语各能力与机制，这对工程与架构把控提出了更高要求。

从“全貌”到“细节”

方法论总结：先看全貌 → 再揪细节 → 理论结合实践 → 迭代加深理解，系统性研读官方文档，建立宏观认知。

官方文档完整、全面、质量很高，在众多开源项目中属于Top 级。

通过系统学习文档，快速形成对隐语的整体理解；

• 隐语是什么、能做什么？
• 联邦学习与多方数据分析分别解决什么问题？
• 为什么需要 Kuscia（调度/编排）？
• SPU / HEU / YACL 分别承担什么职责？

逐步击破核心组件，深入源码理解，结合产品实践，深入到关键组件，分析其机制与数据/控制流。

个人经验：隐语的技术核心在于其联邦学习、安全多方计算等算法与密态设备。然而，从产品落地和深度理解系统运行机制的视角看，Kuscia的任务调度与执行引擎尤为关键，它决定了整个系统如何真正运作起来。

因此，我们通过深入分析Kuscia源码，厘清其任务调度与数据流向，以此建立对隐语技术栈的全局认知。

我们坚持“理论认知”与“工程实践”双轮驱动：在产品迭代中进行二次开发与功能扩展，并将从真实场景中衍生出的技术优化反哺社区（如代码贡献、问题反馈），以此形成从学习、实践到贡献的闭环，持续强化团队的技术实力与工程经验。

SecretPad 上手实践

隐语体系完整、层次较多。对工程师而言，从“跑通最小闭环”切入，是最快形成系统观与问题定位能力的方式。

建议步骤：

双线并行：一手拿官方文档，一手实际操SecretPad

• SecretPad 作为 All-in-One 的产品化“白屏”入口，已相对成型，能直接“看见、点得到、跑得动”。

在 SecretPad 上创建最小任务，例如：

• 创建一个多方分析任务（SCQL）；
• 创建一个联邦学习任务（SecretFlow）。

顺着“一个下发请求”做端到端链路追踪，观察 SecretPad 如何处理请求：参数校验、任务构建、状态管理。

看它如何把任务交给 Kuscia（并非简单“透传”，SecretPad 本身有不少逻辑处理与适配），再看 Kuscia 如何调度任务到多方：

• 任务编排 → 资源申请 → 通信会话 → 多方协同执行 → 状态回传；
• 回到 SecretPad，看结果回填与可视化如何落地。

坚持“看代码”与“跑实例”并行，有些“硬骨头”需要通过源码与调试啃下来；

• 通过链路追踪，快速定位与理解：API 层 → 调度层 → 执行层 各自职责与边界。

这样一条“端到端任务链”跑通、看懂、掌握后，团队会在定位问题、性能调优、功能扩展等方面明显提速。

经验要点清单

学习路径

• 先“全貌导览”（官方文档/白皮书/架构图），再“局部突破”（Kuscia/SCQL/SecretFlow 核心路径）。
• 以“最小可运行闭环”为目标，形成能跑、能查、能改的能力。

工程策略

• 明确组件边界：SecretPad（产品层） ↔ Kuscia（编排层） ↔ SecretFlow/SCQL（执行层） ↔ SPU/HEU/YACL（密码/算子层）。
• 所有自研/扩展遵循“可替换、可插拔、低耦合”的原则。

排障方法

• 日志优先：SecretPad 任务流转日志、Kuscia 调度日志、执行侧算子/协议日志分层查看。
• 最小化复现：把问题收敛到一个最小任务与最小数据集，以便快速定位。
• 组件隔离：先判断是产品层（SecretPad）、还是调度层（Kuscia）、还是执行层（SCQL/SecretFlow）的问题。

社区协作

• 遇到不支持或边缘场景，及时到社区 GitHub 提 Issue；
• 将通用性扩展与修复回馈给社区，减少自有分叉维护成本。

都读到这里啦～打开链接点亮社区Star，照亮技术的前进之路。每一个点赞，都是社区技术大佬前进的动力

Github 地址： https://github.com/secretflow/secretflow

阶段性成效

通过“文档 → 源码 → 实操”的方法路径，我们逐步建立起对隐语的系统认知；在产品迭代中完成了多项二次开发与扩展，并部分回馈社区。

随着对隐语技术栈整体架构、各个repo代码、数据链路流向的理解加深，我们在问题定位、场景扩展、产品化打磨上的效率显著提升，核心挑战也随之被逐步化解。

给初学者的建议

1. 用 SecretPad 跑通一个最小任务闭环（多方分析 / 联邦学习二选一）。
2. 抓住一次“任务下发”，从 SecretPad → Kuscia → 执行层，端到端跟踪请求与状态。
3. 对照官方文档，把实际链路与文档模型一一对应，形成自有笔记与“问题地图”。
4. 把难点打散：先理解“调度怎么协同多方”，再看“密态算子/协议怎么执行”。
5. 多做小实验：换一个函数、换一种数据类型、换一类任务，看差异与日志，强化理解。
6. 保持反馈闭环：把问题与改进点沉淀到团队知识库，并向社区提 Issue/PR。

技术话题延伸

从隐私计算到可信数据空间

近年来，我国在数据要素领域的顶层设计不断强化。从国家数据局的成立到数标委系列标准的发布，再到《可信数据空间技术架构白皮书》的提出， 可以看到国家层面正在系统性地推进 数据要素化、数据流通化、数据可信化。

在这一战略背景下，“数据可信流通”成为建设数字中国的重要基础设施。 其中，隐私计算 作为“可信数据空间”的核心支撑技术之一， 承担着 打破数据孤岛、实现安全共享与协同计算 的关键使命。

隐语（SecretFlow）最初以隐私计算为核心，而在 2024 年后，随着产业需求与国家政策的同步推进，在今年8月份隐语三周年活动中，已官宣从“隐私计算框架”升级为“可信数据流通流动技术社区”，将技术覆盖范围“单一隐私计算”拓展为“六大可信数据要素技术路线”，涵盖数据流通的各个层面，同时也在成为 可信数据空间生态建设的重要开源力量。

隐语社区针对可信数据空间的开源，会从协议、组件源码以及开放平台体验三个层面进行开放，预计将在今年年底前陆续推出。

未来，随着可信数据空间生态的成熟，隐语的性能优化、算子扩展与多方协同能力，都将成为支撑这一生态的重要基础。

📢 社区将通过官方网站与 GitHub 公告（以这个为准），第一时间同步相关 roadmap 与版本信息。请大家持续关注社区，目前社区已成立可信数据空间专项讨论群，感兴趣的朋友可以添加小助手进群。

（添加小助手微信排版时候删除）

隐私计算互联互通难点

在隐私计算的发展过程中，“互联互通” 已经成为行业关注的核心议题之一。

当前业界主要存在两类互联互通需求：

1. 可信数据空间层面的互联互通

• 以“数据三统一”（统一身份、统一协议、统一治理）为特征；
• 聚焦在数据空间/平台层面的连接与治理。

1. 隐私计算框架层面的互联互通

• 关注的是 隐私计算算子、协议和调度层的兼容性；
• 比如：SecretFlow ↔ FATE、SecretFlow ↔ Rosetta 等框架之间的任务互通与算法互认。

其实互联互通这个话题，在隐私计算领域这两年一直被反复提及，尤其在算子层面实现互通，工作量是非常大的。”

2023 年，北京金融科技产业联盟牵头制定了互联互通协议，由 中国银联 牵头，联合 60 家机构 共同制定行业标准。 隐语（SecretFlow）团队作为重要参与方之一，承担了标准中部分协议与实现验证 的工作。

相关标准与实现均开源在隐语的 SecretFlow/InterOp 仓库下。该仓库实现了从 控制层、数据传输层到算法协议层 的多层互联互通能力。

当前的互联互通体系分为两种模式：

黑盒互联互通

主要由 Kuscia 组件负责，在控制层和数据传输层的互联互通。

当前 Kuscia 已实现与 FATE 的 任务级互通，

• 即可在 FATE 上执行 SecretFlow 的任务，或在 SecretFlow 上执行 FATE 的任务。

白盒互联互通

对应的是开放算法协议，关注算法与协议的互通，即不同框架下的算子级互通。

当前已支持的协议包括：

• ECDH-PSI
• SS-LR
• Secure Gradient Boosting(SGB) 这些协议的算法逻辑较固定，因此相对容易实现互联互通。

当前状态：

白盒互联互通仍以具体算法为单位推进，而非通用算子，对于更复杂的 AI/BI 通用算法互通，目前仍处于探索阶段。

通用算法互通为何难？

“单个算法好做，但要实现‘通用算法互联互通’，路还很长。”

核心矛盾

因此，隐语团队目前的策略是：

先从典型算法（PSI、XGB、SS-LR）入手，逐步完善算法协议栈，然后在此基础上，通过 SPU 框架抽象底层接口，最终形成可通用的算法规范。

为何减少RayFed依赖？

在隐语早期版本中，SecretFlow 的底层执行框架依赖 RayFed 进行多方任务调度。RayFed 基于 Ray 的分布式计算框架，可在单控制器视角下协调多方执行任务，编程体验极为便捷。

然而，随着项目规模扩大与技术架构成熟，社区发现：

• RayFed 本身社区已超过一年未更新；
• Ray 的分布式能力在中小规模 MPC 场景中未被充分利用；
• Ray 带来的额外内存与维护成本较高。

移除依赖的技术决策

因此，在 SecretFlow v1.10.0b0 版本中，团队进行了重大架构优化：

• 移除了对 RayFed 的部分依赖；
• 保留了对 RayFed 接口的兼容；
• 实现了SecretFlow 本地调度；
• 将MPC 算法与 SecretPad 组件 迁移至 SecretFlow 自身的 Feed 模块；
• 仅保留部分非 MPC 场景（如联邦 XGBoost）继续使用 RayFed。

这一优化显著提升了系统的轻量化与独立性。

性能优化结果

在迁移过程中，团队进行了系统性能测试（Benchmark）：

测试结果显示，本地调度架构消除了 Ray 集群的额外内存占用，系统整体更为精简与高效。

这种 轻量化改造 对隐语在企业私有部署和边缘计算环境下的适配具有重要意义，同时也大幅降低了维护复杂度与资源开销。

SCQL 数据源兼容性解析

在隐语（SecretFlow）生态中，SCQL 是密态数据分析的重要组成部分。它使得多方数据可以在加密状态下通过类 SQL 语法进行联合查询，实现 “数据可用不可见” 的分析能力。

目前 SCQL 对 MySQL 语法的支持是完备的，文档里面对 PostgreSQL 的支持说明上不完全支持，为什么呢？

事实上SCQL是支持PostgreSQL数据源，只是文档中写得比较保守，接下来我解释给大家听：

MySQL 优先兼容的原因

SCQL 的查询语法本身基于 MySQL 协议实现：

• 用户输入的语句默认按照 MySQL 语法规则 进行解析；
• 如果底层数据源也是 MySQL，那么语法翻译可以做到 100% 对齐；
• 因此在单方数据获取场景下，MySQL 的兼容性最优。

这也是为什么当前文档中会标明 “对 MySQL 完全支持，对 PostgreSQL 暂不完全支持” 的主要原因。

不完全支持的技术根因

PostgreSQL 与 MySQL 在以下几个方面存在差异：

同理兼容MySQL数据库语法的其他数据库，理论上也是支持的，如果数据源的语法和能力（函数）是不一样的就会报错。

结语

随着国家数据要素战略的推进，隐语从“隐私计算框架”向“数据可信流动社区”的进化，不仅是技术范式的拓展，更是数据基础设施层面的跃迁。

未来，隐语将继续以开源为核心驱动力，通过技术共建、标准共创、生态协同，为可信数据空间的落地提供强有力的技术支撑。