← 返回 Siami 首頁

Google 把私有 AI 變實用 HEIR 同態加密編譯器正式開源

▲ 205 💬 129
Google 把私有 AI 變實用 HEIR 同態加密編譯器正式開源

Google 於 8 月 14 日正式對外公開 HEIR(Homomorphic Encryption Intermediate Representation),這是一款開源編譯器工具鏈,可讓開發者用一般 Python 程式碼打造「加密狀態下仍可運算」的 AI 推論系統。HEIR 是 Google 私有運算工具包(Private Computing Toolkit)的最新成員,目的是把過去只有密碼學博士才能駕馭的全同態加密(Fully Homomorphic Encryption,FHE)技術,變成一般工程師也能在自家產品中使用的工具。

同態加密為何重要

隨著 AI 能力擴張,隱私與功能之間的取捨變得更加尖銳。傳統的端對端加密雖然能擋下資料外洩,卻讓服務供應商完全看不到資料內容,因此無法提供垃圾訊息偵測、病毒掃描、個性化推薦等需要讀取資料才能運作的功能。醫療與金融等高度監管產業尤其敏感,機構之間的資料共用受到嚴格法規限制。

替代方案也不是完美解。本機端處理受限於裝置效能與模型大小,更致命的是把專有模型直接送到使用者裝置執行,等於把智慧財產權雙手奉上。全同態加密則改寫了這道選擇題:伺服器可以在密文狀態下完成計算並回傳加密結果,全程不接觸任何明文。Google 在官方部落格中示範的其中一個應用場景,就是讓雲端服務提供內容推薦,卻完全看不到使用者的特徵資料。

「同態加密並非魔法,但它把『能不能保護隱私』的問題,從工程難度轉換成了『成本多少』的問題。而這個成本正在快速下降。」— Google 部落格原文


HEIR 是什麼

HEIR 全名為 Homomorphic Encryption Intermediate Representation,是建立在 MLIR(Multi-Level Intermediate Representation)編譯器框架之上的開源工具鏈。其核心功能是把已經訓練好的、原本運作於明文資料的 AI 模型,自動轉換成能處理加密輸入的版本。Google 的願景是把 HEIR 變成「一鍵啟用加密推論」的標準方案,讓非密碼學專家也能在產品中加入隱私保護層。

這項工作源自 Google 2023 年的承諾。三年來,HEIR 社群已吸引多家硬體加速器廠商加入,包括 Belfort(FPGA)、Niobium(BASALISC ASIC)、Cornami、Optalysys(光學加速器)等。Google 也在論文中揭露已與喬治亞理工、卡內基梅隆、加州大學聖塔芭芭拉分校、伊利諾理工、普渡大學、愛丁堡大學、清華大學等學術機構展開合作。目前已有四篇經同儕審查的學術論文以 HEIR 為基礎發表,累積引用數持續攀升。

編按:本文綜合整理自 Google 部落格〈How Google is making private AI practical with homomorphic encryption〉(2026-08-14)、arXiv 論文〈HEIR: A Universal Compiler for Homomorphic Encryption〉、Google Developers Blog 2023 原始公告,並加入 Siami 編輯部觀點與分析。


HEIR 展示的四個實際應用

為了證明技術已走出實驗室,Google 與合作夥伴共同編譯並釋出四個私人推論示範案例,全部以單執行緒 CPU 跑出延遲數字,所有原始碼皆開源於 GitHub:

  1. 深度學習推薦模型:與 Belfort Labs、LG 以及紐約大學合作,可在不窺探使用者特徵的情況下提供內容推薦。
  2. 信用卡詐欺偵測:與 Niobium、hardshell.ai 合作,把詐欺偵測模型編譯成 FHE 版本,金融機構能在保護持卡人資料的前提下即時攔截可疑交易。
  3. 網路威脅入侵偵測:與 Niobium 合作,把 Kitsune 異常偵測系統改寫成同態版本,服務供應商可在不看到封包內容的前提下辨識攻擊行為。
  4. 熱詞喚醒偵測:與 Belfort Labs 合作,把喚醒詞模型加密化,未來智慧音箱或 AI 助理可在不錄下使用者對話內容的情況下辨識觸發指令。

四個場景恰好對應 FHE 最被看好的商業化路徑:個資敏感性高、即時性要求中等、模型規模可被壓縮到「在合理延遲內可執行」的小型任務。


為什麼這件事重要

從密碼學史的角度來看,HEIR 並非憑空冒出來的新點子。早在 1978 年,RSA 的共同發明人 Ron Rivest 就把同態加密列為密碼學的「聖杯」。然而過去近五十年,這道聖杯一直被「運算速度慢到不實用」的詛咒綁架。傳統的 FHE 加密推論在 CPU 上比明文計算慢上 1,000 到 10,000 倍,這個數字直到近五年才開始鬆動。

Duality Technologies 在 2026 年的基準報告中指出,FHE 效能改善幅度介於 1,000 倍到 10,000 倍之間,主要來自三股力量的疊加:CKKS 等演算法的改良、編譯器層級的電路自動優化、以及 DARPA DPRIVE 等硬體加速器計畫的挹注。Wavect 進一步整理市場實況:五年前對萬筆資料做加密邏輯回歸推論可能要跑數小時,現在於優化後的 CKKS 加上批次運算只要 2 到 10 秒,GPU 加速的批次分析更能在幾分鐘內處理百萬筆紀錄。

HEIR 真正的戰略意義在於它是一座「編譯器層級的抽象化平台」。過去每換一個硬體加速器、每一套新的 FHE 演算法,研究團隊都必須從頭改寫整個編譯鏈。HEIR 則把 Python 程式碼編譯到 MLIR 中介層,再根據目標硬體(Belfort FPGA、Niobium ASIC、Google TPU、Intel HERACLES)選擇最佳後端。對應用開發者來說,學一次 HEIR 就能在所有支援的後端之間切換,跨廠商移植成本大幅下降。

從產業面觀察,HEIR 選在 2026 年中發表並非偶然。Fortune Business Insights 預估全球同態加密市場將從 2025 年的 4.16 億美元成長到 2032 年的 23.8 億美元,CAGR 28.3%;Future Market Insights 更樂觀,預估 2036 年將達 39 億美元。Apple、微軟、Zama、Duality、Intel、Cornami 等大廠都已投入,Google 把 HEIR 開源,等於把標準制定的主導權握在自家手裡。

編按:HEIR 的開源策略與 Apple Private Compute、Microsoft SEAL 的封閉或半封閉路線形成對比。Google 想當的是「FHE 時代的 LLVM」 — 把基礎建設標準化,再從雲端服務與 TPU 加速器獲利。


數據解讀與質疑

雖然 Google 的展示令人振奮,但仍有幾個值得質疑的環節。

成本依然是最大瓶頸。 Hacker News 討論串中,多位開發者指出即便有 HEIR 編譯器加持,FHE 在單執行緒 CPU 上跑小模型仍有「數秒到數十秒」的延遲,這對於需要即時回應的消費者應用(例如聊天機器人、語音助理)仍難以接受。Wavect 的結論也呼應這一點:能上線的只有「小模型 + 高敏感資料」的組合,例如信用評分、醫療前篩、詐欺訊號。

「Trust Me Bro」質疑未解。 HN 留言區有使用者直接挑戰:客戶端有沒有辦法驗證服務供應商真的無法窺探輸入?目前 FHE 的數學保證是「就算你想看也看不到」,但前提是供應商沒有在編譯階段偷偷插入後門、或在硬體層動手腳。Google 沒有在部落格文章中正面回應這個質疑,僅用「強加密保證是純密碼學的」一句帶過。

商業夥伴的進展速度落差大。 在四個合作對象中,Belfort 與 Niobium 有實機展示(FPGA 與 ASIC),Cornami 與 Optalysys 仍停留在白皮書階段。Niobium 的 BASALISC ASIC 雖已宣布與 SEMIFIVE、三星晶圓代工合作走向量產,但首批商用樣品時程仍未公布。

論文 vs 實品的鴻溝。 Google 在部落格引用了「單執行緒 CPU」延遲數字,但沒有揭露與 GPU、TPU 加速器的對比。Wavect 與 Duality 的基準都顯示 GPU 加速能再快 200 倍,但這需要 H100 等級硬體才能享受到。對中小型企業來說,硬體採購成本仍是導入 FHE 的實際門檻。


延伸閱讀與參考資料


「同態加密的成本正在快速下降,但『快速下降』與『足夠便宜』之間還有十年以上的距離。」— Wavect 2026 年評測結論

觀察重點

HEIR 的發表時點值得玩味。Google 選在 Apple Private AI、Microsoft SEAL 之後公開 FHE 編譯器技術,等於宣告在「隱私運算」這條賽道上加入戰局。三家公司的策略截然不同:Apple 走端到端封閉生態,Microsoft 推函式庫但商業化緩慢,Google 則把編譯器開源、把硬體與雲端服務綁在一起。對開發者來說,HEIR 降低的不只是入門門�,更是「跨硬體平台移植」的工程摩擦。

值得持續關注的訊號包含:Google 何時把 HEIR 整合進 Vertex AI 或 Gemini API、Niobium 與 Belfort 的 ASIC/FPGA 何時進入量產、以及是否有主流瀏覽器或行動裝置直接內建 FHE 加速指令集。這三個訊號任一實現,「私有 AI」將從技術展示走向真正的消費級應用。

網友熱門留言 (5)

#1 Hacker News 用戶 ▲ 20
「聽起來很棒,但我想知道商業上是否真的可行。各國政府會不會在下一個 E2E 加密普及前先出手介入?」
#2 Hacker News 用戶 ▲ 18
「FHE 的設計有個根本限制:它保證你需要金鑰才能看到運算的輸入或輸出,但沒辦法保證這個運算本身是你想要的那個。舉例來說,運算的過程對某些輸入可能是對抗性的,或者攻擊者可以在計算鏈中插入自己的運算。」
#3 Hacker News 用戶 ▲ 14
「不管有沒有加密,只要資料在別人的伺服器上,它就不屬於你。我不相信 Google 會把我的最大利益放在心上。」
#4 Hacker News 用戶 ▲ 11
「客戶端有辦法驗證供應商真的無法看到我的輸入嗎?這還是要『Trust Me Bro』嗎?」
#5 Hacker News 用戶 ▲ 9
「FHE 在數學上完全沒問題,但傳統上慢得離譜,很難想像能跑超過玩具模型。他們列的應用應該都是被大幅精簡過的。」