Split Learning 論文閱讀分析：很多企業想把 LLM 微調外包上雲，真正先外洩的不是模型，而是中間那層看起來不像資料的資料

本文由 AI 產生、整理與撰寫。

論文基本資訊

• 論文標題：A Survey on Split Learning for LLM Fine-Tuning: Models, Systems, and Privacy Optimizations
• 作者：Zihan Liu、Yizhen Wang、Rui Wang、Xiu Tang、Sai Wu
• 年份：2026
• 來源：arXiv:2604.24468
• 論文連結：https://arxiv.org/abs/2604.24468
• DOI：10.48550/arXiv.2604.24468
• 主題：Split Learning、LLM Fine-Tuning、Privacy-Preserving Training、Collaborative AI、Differential Privacy、AI Security

很多組織其實不是不想把 LLM 微調做起來，而是卡在一個很現實的矛盾：模型太大，自己算力不夠；資料太敏感，又不敢整包丟到雲上。 於是大家常在兩個爛選項之間搖擺：要嘛不上線，要嘛硬著頭皮外包。

這篇 survey 的價值，在於它把第三條路整理得很清楚：把模型切開來訓練。 也就是所謂的 split learning。客戶端保留一部分模型與原始資料，伺服器只處理中間層的 activations、gradients 或其他中介表示，試圖同時兼顧訓練可行性與資料保護。

但這篇真正值得看的地方，不只是它介紹了一堆方法，而是它很誠實地指出：你沒把 raw data 直接送出去，不代表你就安全了。真正危險的，往往是那些看起來不像資料、卻仍然足夠還原資料的中間訊號。

這篇真正想講的，不是「怎麼更有效率地微調 LLM」，而是「當你試圖把敏感資料留在本地時，哪些資訊其實還是偷偷穿過了邊界」。

它在打哪個痛點？

LLM fine-tuning 的現實困境其實很明確：

• 算力壓力大：大型模型微調不是每個企業、醫院、金融機構、研究團隊都養得起。
• 資料敏感：很多高價值任務剛好也是最不能外流的資料，例如醫療紀錄、內部客服對話、金融交易、SOC 事件、威脅情資標註資料。
• 單純上雲不安心：就算雲端有資源，很多單位也不想把受管制資料直接交給第三方。

所以 split learning 的核心誘惑很合理：把模型切成 client-side 與 server-side，資料留在本地，只傳遞中間表示，讓資源受限的單位也能參與協作式微調。

如果只看概念，這很像一個兩全其美的折衷方案。但作者整篇 survey 要提醒的正是：折衷不是免費的。 你把 raw input 藏起來之後，新的攻防焦點就會轉移到 smashed data、cut-layer gradients、label leakage、client-server update imbalance、以及協作訓練流程本身的 integrity。

這篇做得最好的地方：它不是亂列 papers，而是先把整條 training pipeline 拆開

這篇 survey 最對味的部分，是作者不是單純照論文題目分類，而是先抽象出一條統一的 split-based LLM fine-tuning pipeline，再把問題一個個掛回流程節點上。

這種整理方式很重要，因為 split learning 真正麻煩的地方就是：不同問題不是同時在所有地方發生，而是會在特定步驟爆開。

作者大致把問題拆成三大層：

• 模型層（model-level）：訓練是否收斂、泛化會不會爛掉、不同 client 的資料異質性怎麼處理
• 系統層（system-level）：切點怎麼選、通訊成本多高、伺服器會不會變瓶頸、異質裝置如何同步
• 隱私與安全層（privacy/security）：中間表示會不會被反推、梯度會不會洩漏標籤、惡意 server/client 能不能下毒或植入後門

這個 framing 很有用，因為它把 split learning 從「一種分散式訓練技巧」拉高成「一個需要同時處理效能、收斂與邊界外洩的完整系統設計問題」。

第一個關鍵提醒：資料沒離開，不代表語義沒離開

很多人會直覺以為，既然原始文字、標籤都留在 client 端，那就已經比一般 outsourced fine-tuning 安全很多。

這篇最值得帶走的一點，就是它明講：split learning 交換的那些 intermediate representations，仍然可能攜帶足夠強的語義與監督訊號。

作者整理出的代表性風險包括：

• smashed data inversion attacks：從中間 activations 反推出原始輸入
• gradient-based label reconstruction：從反向梯度推回標籤資訊
• membership inference attacks：推斷特定樣本是否出現在訓練資料中
• property inference attacks：推斷資料集中的敏感屬性
• data poisoning 與 backdoor attacks：惡意 client 或 server 在協作訓練中破壞模型完整性

換句話說，split learning 不是把隱私問題消滅，而是把隱私問題改寫成中間表示的可逆性問題。 這點跟很多 agent security、RAG security、memory security 的核心邏輯非常像：真正要問的不是「原文有沒有出去」，而是「出去的東西是否仍然可重建原本不該被知道的東西」。

很多系統真正高估自己的地方，不是資料沒出界，而是誤以為中間層就不算資料。

第二個關鍵：切點不是工程細節，而是安全與成本的分水嶺

作者把 split point selection 放在非常前面，這是對的。因為模型切在哪裡，不只是決定誰算多一點、誰算少一點，它其實同時決定了三件事：

• client 端記憶體與算力負擔
• client-server 之間的通訊開銷
• 中間表示的洩漏風險

切得太前面，client 比較省，但 server 看到的表示通常更接近原始輸入，隱私壓力可能更大。切得太後面，隱私也許比較好一些，但 client 本地負擔會變重，對資源有限的單位不友善。

所以這篇其實在提醒一件很現實的事：split learning 沒有單一最佳切法，只有針對威脅模型、網路條件、裝置能力與任務需求的 trade-off。

這也說明為什麼系統論文如果只秀 throughput 或 accuracy，而不談 split point 對洩漏面的影響，基本上就是少講了半套。

模型層真正難的，不是能不能 train，而是多方一起 train 時會不會越訓越歪

Survey 裡另一個很值得注意的部分，是作者沒有把問題簡化成「Split Learning 理論上等價於 centralized training，所以應該沒事」。他們直接指出，一旦進入多 client 協作情境，這種等價性很快就破掉了。

他們整理出的三個典型模型層痛點是：

• 資料異質性（non-IID）：不同客戶端的資料分布差異會讓 server-side model 的收斂方向被拉歪
• server-client update imbalance：server 吃到的是多方聚合後的訊號，更新節奏可能快於 client 端，導致失衡
• catastrophic forgetting：在 sequential 或 partial participation 設定下，新 client 的訓練可能覆蓋掉先前學到的表徵

這些問題很像把 federated learning 的老痛點，疊加上 split learning 的中間表示耦合，最後形成一個更脆弱的混合體。也就是說，你不是只要保住隱私而已，還要保住協作訓練的可收斂性。

如果這部分沒處理好，結果會很尷尬：你花了很多設計成本守住資料不外流，最後卻得到一個性能不穩、泛化不一致、甚至容易忘記事情的模型。

系統層真正燒錢的，不是 GPU 本身，而是來回搬運中間訊號

很多人想到 collaborative fine-tuning，第一反應是「把大頭丟給 server 算就好」。但這篇整理得很清楚：真正會拖垮系統的，常常是中間資料的雙向傳輸與異質裝置同步。

作者特別點出的系統瓶頸包括：

• activation / gradient 的持續雙向傳輸 帶來高通訊成本
• 中央 server 容易成為計算與協調瓶頸
• global aggregation 或同步機制 會在異質環境下製造 straggler problem
• client 裝置差異 讓高能力節點也得等最慢的人

這個 insight 很務實：split learning 不是「本地算一點、雲端算一點」就自然高效，它其實是用更多 pipeline coordination 去換資料不直送。

對企業來說，這代表評估 split learning 時不能只看 paper 裡的 accuracy gain，還要問：

• 網路條件撐不撐得住？
• cut-layer tensor 大不大？
• 客戶端是不是一堆規格不一的弱裝置？
• 同步等待時間會不會把整體吞吐吃掉？

安全面最值得記的一段：這篇把 attack taxonomy 講得很完整

如果你是從 AI security 角度看這篇，第五節應該是最有料的部分。作者把 split-based LLM fine-tuning 的攻擊面整理成一個相當完整的 taxonomy，而且不是只有停在模型反演這種老話題。

它至少把威脅分成幾條清楚的線：

• 輸入重建：從 smashed data 反推原文、token 或語義內容
• 標籤洩漏：從梯度統計或梯度匹配反推 supervision
• 雙向重建：結合 forward 與 backward 的泄漏面，突破單向資訊瓶頸
• 成員與屬性推論：在不直接接觸資料的前提下，推測資料集的存在性與特徵
• poisoning / backdoor：把 collaborative fine-tuning 變成模型完整性破壞入口

這裡最重要的啟發是：協作式訓練不是只怕 confidentiality 失守，也怕 integrity 被慢慢做壞。 你如果只防 reconstruction，卻不防 server 操縱梯度或 client 偷植 trigger，最後拿到的仍然可能是一個不可信的模型。

防禦部分也很有意思：不是只有加噪，而是整個 pipeline 都得重寫

很多人一講隱私保護就直接想到 differential privacy。這篇當然有談，而且談得不少，但它最有價值的地方是：作者把 defenses 分成多條路，而不是假裝「加點 noise 就萬事大吉」。

幾個主要防線包括：

• perturbation-based defenses：在 token、embedding、smashed data 或 gradients 上加噪，降低可重建性
• learning-based defenses：直接把 mutual information minimization、dependency reduction 之類的隱私目標寫進訓練
• detection-based defenses：監控 gradient attributes 或參數異常，嘗試即時抓出 hijacking、poisoning、backdoor
• split unlearning：讓特定 client 的資料可以後續被移除或重訓
• protocol modification：直接修改 split learning 架構，例如引入 aggregator 或禁止特定權重共享

這代表一件事：真正成熟的 split learning，不會只是「切開模型」而已，而是要把通訊、表徵、監測、回滾與 unlearning 一起納進治理面。

從安全工程角度看，這非常合理。因為只要邊界上還有高語義中間訊號流動，防禦就不可能只做在單一層。

這篇對 CTI / 安全產業有什麼實際意義？

雖然這篇是 survey，不是專門講威脅情資，但它對 CTI 與安全產業其實很有現實價值。原因很簡單：安全領域恰好同時擁有高敏感資料、跨組織協作需求，以及想導入 domain-specific LLM 的強烈動機。

例如：

• SOC 想用內部告警、ticket、case notes 微調模型
• MSSP 想跨客戶學到更好的 triage 或 summarization 能力
• 威脅情資團隊想把內部 IOC、TTP 分析流程轉成專用模型
• 醫療、金融、政府部門想做垂直領域 adaptation，卻不想把資料直接外送

這時 split learning 就很有吸引力。但這篇也提醒你：別因為資料沒整包上傳，就誤以為法遵、隱私與威脅模型問題都已經解掉。 你仍然得問：

• 中間表示能不能被反推？
• server 是否值得信任？
• 惡意 client 會不會投毒？
• 梯度與 activation 的保護措施是否足夠？
• 出事時能不能審計與回滾？

如果這些問題沒答，split learning 只是把風險藏到比較不直覺的地方而已。

這篇的邊界也要講清楚

當然，這篇畢竟是 survey，也有幾個自然限制：

• 它提供的是地圖，不是單一萬用解法。 你還是得自己決定 threat model、切點與部署方式。
• 不少方法仍在早期驗證階段。 有些來自 split learning 通用文獻，再投射到 LLM fine-tuning 場景，距離 production-ready 還有距離。
• privacy-utility-efficiency 三角關係沒有被消滅。 它只是被更系統化地攤開而已。
• survey 很完整，但真實部署還要面對法遵、可觀測性、密鑰管理、惡意 insider、跨境資料政策等額外問題。

不過這些都不影響它的價值。因為它至少把問題講對了：協作式 LLM 微調最大的難題，不是把模型搬到哪裡，而是資料、表徵、控制權與訓練責任到底怎麼切。

一句話總結

這篇論文最值得看的地方，不是它替 split learning 補了一份文獻整理，而是它提醒我們：很多組織想安全地微調 LLM 時，真正要治理的從來不只是「原始資料有沒有上雲」，而是整條 collaborative training pipeline 裡，哪些中間表示仍然足以洩漏語義、標籤、成員資訊與模型完整性，並且該如何在效能、收斂與隱私之間做出可被審計的工程選擇。