業務背景及痛點
作為一家綜合性的證券金融集團，國泰海通證券在探索數據協同與隱私保護方面始終走在行業前列。
我們技術團隊內部在集團推動部署 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_st...
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。
如果某些國產化平台的廠商自己有能力，也可以直接參與貢獻代碼，完成適配流程。整個社區對這些適配的態度都是非常開放和歡迎的。
