在 AI 应用大规模部署的今天,数据隐私和安全已成为无法回避的核心挑战。传统的 AI 服务模式要求用户将原始数据上传至云端服务器进行推理,这带来了巨大的隐私泄露风险。为了解决这一矛盾,隐私计算技术应运而生,而同态加密作为其中理论最完备、安全性最高的分支,长期以来因其巨大的计算开销和复杂性,一直被视为“学术界的瑰宝”,难以在实际生产环境中落地。谷歌近期开源的同态加密编译器项目 HEIR,正是试图打破这一僵局的关键一步。它旨在为开发者提供一套工具链,将高级语言编写的程序自动编译、优化为适合同态加密执行的形式,从而显著降低隐私保护 AI 推理的应用门槛。本文将深入探讨 HEIR 项目的技术背景、核心价值,并通过一个模拟的 AI 推理隐私保护场景,展示如何理解并初步尝试使用这类工具来构建一个“数据可用不可见”的推理服务原型。无论你是关注前沿技术的算法工程师,还是负责构建安全、合规 AI 应用的架构师,理解同态加密的实用化路径都将为你打开新的设计思路。
1. 理解同态加密与 HEIR 的使命:从理论到实践的桥梁
在深入 HEIR 之前,必须首先厘清同态加密和它在 AI 推理中的独特价值。这并非一个可以跳过的概念,因为不理解“为什么”,就无法真正用好“怎么做”。
1.1 同态加密:在密文上直接计算的“魔法”
想象一个场景:你有一份敏感的医疗影像需要 AI 诊断,但你不信任任何云服务商能看到你的原始数据。传统加密方法(如 AES)能加密你的数据,但加密后的数据只是一堆乱码,服务器无法对其进行任何有意义的计算。你不得不先解密,这又回到了隐私泄露的原点。
同态加密则像一种“魔法”:它允许对加密后的数据(密文)直接执行特定的计算(如加法、乘法),得到的结果仍然是加密的。当你拿回这个加密的结果并用自己的密钥解密后,得到的就是原始数据经过相同计算后的结果。在整个过程中,服务器(计算方)从未接触过任何明文数据。
根据支持的计算类型,同态加密分为几个级别:
- 部分同态加密:仅支持无限次加法或无限次乘法中的一种。例如 Paillier 算法支持加法。
- 近似同态加密:支持加法和乘法,但次数有限,超过后噪声会淹没信息。
- 全同态加密:支持任意次数的加法和乘法,理论上可以执行任何计算。现代 FHE 方案(如 BGV、BFV、CKKS)通过“自举”操作来消除噪声,实现任意深度计算,但这也是开销最大的部分。
对于 AI 推理,尤其是基于神经网络的推理,其核心计算是向量和矩阵的加法和乘法,这正是同态加密,特别是 BFV 和 CKKS 等方案可以高效处理的。CKKS 方案还能直接支持浮点数近似计算,与 AI 模型的需求更为契合。
1.2 实用化瓶颈:为什么 FHE 难以落地?
尽管原理美妙,但全同态加密距离实用一直有巨大鸿沟,主要瓶颈有三:
- 极高的计算开销:密文运算比明文运算慢数个数量级(万倍到百万倍),且密文数据膨胀严重(一个浮点数可能膨胀为数 KB 的密文)。
- 复杂的电路设计:FHE 操作基于“电路”模型,开发者需要将计算任务(如一个神经网络的前向传播)手动转换为一系列特定的同态操作序列(加、乘、旋转等)。这要求开发者同时是密码学专家和领域专家。
- 工具链缺失:没有成熟、易用的编译器、优化器和运行时库,将高级语言(如 C++、Python)自动、高效地映射到 FHE 原语上。
1.3 HEIR 的目标:充当高级语言与 FHE 后端的翻译官与优化器
这就是谷歌开源 HEIR 项目的意义所在。HEIR 并非一个全新的 FHE 算法库,而是一个编译器基础设施。它的定位是成为连接上层应用与底层多种 FHE 后端(如 Google 自己的TFHE、OpenFHE等)的中间层。
其核心工作流程可以简化为:
你的 AI 推理程序 (C++/MLIR Dialect) -> HEIR 编译器 (转换、优化) -> 针对特定 FHE 后端的优化程序 -> 链接 FHE 库执行HEIR 的关键贡献在于:
- 抽象与自动化:让开发者用更接近传统编程的方式描述计算,由编译器负责将其分解、转换为正确的 FHE 操作序列。
- 中间表示与优化:基于 MLIR 框架,HEIR 提供了用于表示 FHE 操作的中间表示层,可以在此层进行跨后端的通用优化(如常量折叠、操作融合),大幅提升生成代码的效率。
- 后端无关性:理想情况下,开发者只需关注计算逻辑本身,通过切换编译器后端,即可将同一份代码适配到不同的 FHE 库上。
简而言之,HEIR 试图将 FHE 的复杂性封装在编译器内部,让应用开发者能够以可接受的开发成本,享受到同态加密带来的顶级隐私保护能力。这对于推动私有化 AI 推理走向实用至关重要。
2. 环境准备:构建 HEIR 的探索与开发环境
HEIR 是一个处于活跃开发阶段的研究型项目,直接用于生产尚不成熟。但对于学习和探索,搭建其开发环境是理解其工作原理的第一步。以下步骤基于其开源仓库的说明,并补充了实践中可能遇到的问题。
2.1 系统与工具链要求
HEIR 严重依赖 LLVM/MLIR 生态,因此对构建工具链有特定要求。
- 操作系统:推荐 Ubuntu 20.04/22.04 LTS 或 macOS。在 Windows 上可通过 WSL2 使用 Ubuntu 环境。
- 包管理器:
apt(Ubuntu) 或brew(macOS)。 - 核心依赖:
git: 版本控制。cmake(>= 3.19): 构建系统生成器。ninja: 高效的构建工具。- Python 3 及相关开发包。
- 一个现代的 C++ 编译器(如
g++-11,clang-12或更高版本)。
在 Ubuntu 22.04 上,可以使用以下命令安装基础依赖:
sudo apt update sudo apt install -y git cmake ninja-build python3 python3-pip python3-venv \ g++-11 llvm-14-dev llvm-14-tools clang-14 libz-dev注意:HEIR 对 LLVM 版本可能有特定要求(例如要求 LLVM/MLIR 14.x)。请务必查阅项目
README.md或CMakeLists.txt中的最新要求,版本不匹配是编译失败最常见的原因。
2.2 获取 HEIR 源代码
使用git克隆 HEIR 仓库及其子模块:
git clone https://github.com/google/heir.git cd heir git submodule update --init --recursive这个过程会下载 HEIR 主代码以及它所依赖的 MLIR 等相关子模块,可能需要一些时间。
2.3 配置与编译 HEIR
HEIR 使用 CMake 进行构建。建议创建一个独立的构建目录。
# 在 heir 目录下 mkdir -p build && cd build # 配置 CMake。关键是指定 LLVM 的安装路径。 # 假设你通过 apt 安装了 llvm-14,路径可能是 /usr/lib/llvm-14 # 如果你自己编译了 LLVM,则指向你的安装目录,如 /path/to/llvm/install cmake .. -G Ninja \ -DCMAKE_C_COMPILER=clang-14 \ -DCMAKE_CXX_COMPILER=clang++-14 \ -DLLVM_DIR=/usr/lib/llvm-14/cmake/llvm \ -DMLIR_DIR=/usr/lib/llvm-14/cmake/mlir \ -DCMAKE_BUILD_TYPE=Release # 开始编译,使用所有可用的 CPU 核心以加快速度 ninja编译过程耗时较长,因为需要编译整个 MLIR 和 HEIR 框架。成功完成后,在build/bin目录下会生成heir-opt,heir-translate等可执行文件。
2.4 验证安装与常见问题排查
编译完成后,运行一个简单的测试命令检查核心工具是否正常:
./bin/heir-opt --help你应该能看到heir-opt的命令行帮助信息,其中包含一系列可用的编译优化通道。
常见问题与排查:
| 问题现象 | 可能原因 | 检查与解决 |
|---|---|---|
cmake配置失败,提示找不到 LLVM/MLIR | 1. LLVM 未安装。 2. 安装的版本不对。 3. LLVM_DIR路径错误。 | 1. 运行llvm-config-14 --version确认安装。2. 使用 find /usr -name \"LLVMConfig.cmake\" 2>/dev/null查找正确的LLVM_DIR路径。 |
ninja编译失败,大量 C++ 语法错误 | C++ 编译器版本过低或与 LLVM 不兼容。 | 确保使用g++-11或clang-12+。在cmake命令中显式指定-DCMAKE_CXX_COMPILER。 |
| 链接错误,缺少某些符号 | 依赖库版本不匹配,或者构建目录残留旧配置。 | 1. 彻底删除build目录,从头开始cmake和ninja。2. 确保所有子模块已更新 ( git submodule update --recursive)。 |
运行heir-opt提示动态库找不到 | 编译生成的二进制文件依赖的 LLVM 库路径未加入动态链接器搜索路径。 | 1. 临时解决:LD_LIBRARY_PATH=/usr/lib/llvm-14/lib:$LD_LIBRARY_PATH ./bin/heir-opt。2. 永久解决:将库路径添加到系统配置中,或使用静态编译选项重新构建。 |
环境搭建是接触任何前沿开源项目的第一步,也是筛选掉大部分问题的环节。成功构建 HEIR 意味着你已经拥有了探索同态加密编译技术的实验平台。
3. 核心概念与工作流程:HEIR 如何编译一个程序
HEIR 不是一个“开箱即用”的 AI 推理隐私保护 SDK。要利用它,必须理解其基于 MLIR 的编译流水线。本节将剖析一个简化的工作流程,说明从高级语言到可执行 FHE 代码的转换过程。
3.1 MLIR 与 Dialect:多层抽象的基石
MLIR 是一个用于构建可重用、可扩展编译基础设施的框架。其核心思想是“多层中间表示”。不同抽象层次的 IR 通过Dialect来定义。
HEIR 定义了自己的 Dialect,用于表示同态加密领域的特定操作和类型。例如:
heir.secret:用于表示加密的(秘密的)数据类型。heir.add_eint,heir.mul_eint:表示在加密整数上的加法和乘法操作。heir.rotate:表示密文旋转操作(用于 SIMD 风格的批处理)。
编译过程就是逐步将高级的、与加密无关的操作, lowering(降级)到这些 FHE 原生操作的过程。
3.2 一个简化的 HEIR 编译流水线
假设我们有一个最简单的计算:result = (a + b) * c,其中a, b, c都是需要加密的私有输入。在 HEIR 的视角下,处理流程如下:
前端输入:程序可能以多种形式输入。
- 高级语言:通过一个前端编译器(如从 C/C++ 通过
clang生成 MLIR)产生初始 MLIR。 - 手工编写 MLIR:直接使用 HEIR Dialect 和标准 MLIR Dialect 编写计算图。这是学习和测试时常用的方式。
一个手写的、未加密的 MLIR 片段可能看起来像这样(使用
arithDialect 表示算术):func.func @main(%a : i32, %b : i32, %c : i32) -> i32 { %sum = arith.addi %a, %b : i32 %result = arith.muli %sum, %c : i32 return %result : i32 }- 高级语言:通过一个前端编译器(如从 C/C++ 通过
类型转换与操作替换:这是 HEIR 的核心转换阶段。编译器需要识别出哪些数据是秘密的,并将其类型从
i32转换为!heir.secret<i32>。同时,将对应的操作(arith.addi,arith.muli)替换为 FHE 操作(heir.add_eint,heir.mul_eint)。转换后的 MLIR 可能类似于:
func.func @main(%a_secret : !heir.secret<i32>, %b_secret : !heir.secret<i32>, %c_secret : !heir.secret<i32>) -> !heir.secret<i32> { %sum_secret = heir.add_eint %a_secret, %b_secret : !heir.secret<i32> %result_secret = heir.mul_eint %sum_secret, %c_secret : !heir.secret<i32> return %result_secret : !heir.secret<i32> }注意,此时操作已经变成了
heirDialect 中的同态操作。FHE 方案特定 lowering:上一步的
heir.add_eint仍然是抽象的。接下来需要根据目标 FHE 后端(例如 BFV 方案)进行 lowering。这一步会将抽象操作转换为该后端库所支持的具体函数调用或内联操作,并处理诸如模数、多项式环维度等参数。代码生成:将最终 lowering 后的 MLIR 模块,通过
heir-translate等工具,生成目标代码。这可能是:- C++ 代码:调用特定 FHE 库(如
OpenFHE)API 的代码。 - 某种中间表示:供后续工具链使用。
- C++ 代码:调用特定 FHE 库(如
编译与链接:将生成的 C++ 代码与实际的 FHE 库(如
libOPENFHE.so)一起编译,最终生成一个可执行文件或库。这个程序就能在加密的输入上执行计算了。
3.3 使用 HEIR 工具链的示例命令
虽然完整流程复杂,但我们可以通过 HEIR 自带的示例和工具来管中窥豹。假设我们有一个简单的 MLIR 文件simple.mlir,内容就是上面的非加密版本。
# 1. 使用 heir-opt 进行转换和优化 # `--convert-arith-to-heir` 是一个假设的转换通道,用于演示。实际通道名称需参考项目文档。 ./build/bin/heir-opt simple.mlir \ --convert-arith-to-heir \ --cse --canonicalize \ # 一些通用的优化 -o simple_heir.mlir # 2. 查看转换后的结果 cat simple_heir.mlir # 3. 将 MLIR 转换为 LLVM IR (假设已 lowering 到 LLVM Dialect) ./build/bin/heir-translate simple_heir.mlir \ --mlir-to-llvmir \ -o simple_heir.ll # 4. 使用 clang 将 LLVM IR 编译为目标文件 clang-14 -c simple_heir.ll -o simple_heir.o注意:以上命令中的转换通道 (
--convert-arith-to-heir) 是示意性的,HEIR 项目实际提供的转换通道名称和流程需要查阅其最新文档和测试用例。这个示例旨在展示工具链的串联方式。
理解这个流水线至关重要。它意味着作为应用开发者,未来的理想工作模式是:编写或生成标准计算逻辑的 MLIR -> 使用 HEIR 编译器(配置好目标 FHE 后端)进行编译 -> 获得一个自动处理了所有 FHE 复杂性的可执行隐私计算模块。
4. 模拟实战:构建一个隐私保护的线性推理服务原型
为了将概念具体化,我们设计一个高度简化的模拟场景:一个服务端提供线性模型y = w * x + b的推理能力,客户端希望在不泄露输入x的情况下获得预测结果y。我们将使用 HEIR 的思想来设计流程,并给出关键部分的模拟代码。请注意,由于 HEIR 本身仍在演进,且直接集成完整的 FHE 库(如 OpenFHE)步骤繁琐,本例将侧重于架构设计和关键接口模拟,并给出一个使用 Python 伪代码和概念演示的“端到端”流程。
4.1 系统架构设计
我们的原型系统包含三个角色:
- 客户端:持有私有数据
x,拥有同态加密的密钥对(公钥pk,私钥sk)。 - 服务端:持有模型参数
w和b(明文),提供同态计算服务。它只有客户端的公钥pk。 - HEIR 编译产物:一个由服务端预先编译好的、能够对密文执行
w * ctxt_x + b计算的共享库或函数。
工作流程如下:
客户端: 1. 使用 pk 加密数据 x,得到密文 ctxt_x。 2. 将 ctxt_x 发送给服务端。 服务端: 3. 加载预编译好的同态计算模块。 4. 调用该模块,传入 ctxt_x, w, b,在密文上计算,得到结果密文 ctxt_y。 5. 将 ctxt_y 返回给客户端。 客户端: 6. 使用 sk 解密密文 ctxt_y,得到明文结果 y。4.2 服务端:模型准备与“HEIR 编译模块”模拟
假设我们的模型参数为:w = 2.5,b = 1.0。
在理想情况下,服务端会使用 HEIR 编译一个计算内核。这里我们模拟这个内核为一个 Python 函数,它接收一个“密文”对象和明文参数,返回一个“密文”结果。我们用一个简单的类来模拟密文对象。
# server.py - 模拟服务端同态计算模块 class MockCiphertext: """模拟密文对象,实际应为 FHE 库的密文类型""" def __init__(self, data=None): # 在实际中,这里封装的是多项式环上的向量等复杂数据 # 此处仅用于模拟流程 self.data = data def __repr__(self): return f"MockCiphertext({self.data})" def compile_heir_linear_kernel(): """ 模拟 HEIR 编译后的计算函数。 在实际中,这个函数是由 HEIR 生成,并调用底层 FHE 库(如 OpenFHE)的 API。 此处用纯 Python 逻辑模拟计算过程。 """ def linear_computation(ctxt_x: MockCiphertext, w: float, b: float) -> MockCiphertext: print(f"[Server] Performing homomorphic computation: {w} * ctxt_x + {b}") # !!! 关键模拟点 !!! # 在实际 FHE 中,这里的计算发生在密文上,服务端看不到 ctxt_x.data。 # 我们在此模拟计算,但强调真实场景中服务端无法进行此明文操作。 # 假设有一种“魔法”可以在密文上计算线性函数。 # 对于模拟,我们假设 ctxt_x.data 就是加密后的值,我们直接计算。 # 这仅用于演示流程,完全失去了安全意义。 result_data = w * ctxt_x.data + b # 这在实际 FHE 中是不可行的明文操作 return MockCiphertext(result_data) return linear_computation # 服务端持有的模型参数 MODEL_WEIGHT = 2.5 MODEL_BIAS = 1.0 # 加载“编译好的”同态计算函数 heir_linear_fn = compile_heir_linear_kernel()4.3 客户端:加密、解密与通信模拟
客户端需要模拟生成密钥、加密和解密操作。我们使用一个简单的“加密”函数来模拟。
# client.py - 模拟客户端 import random class MockKeyPair: """模拟密钥对""" def __init__(self): # 模拟公钥和私钥。实际是复杂的数学对象。 self.pk = lambda x: x * 1000 + random.randint(1, 99) # 模拟加密:放大并加随机噪声 self.sk = lambda y: (y // 1000) # 模拟解密:去除放大因子和噪声(取整) def client_process(): # 1. 客户端生成密钥 keypair = MockKeyPair() print(f"[Client] Key pair generated.") # 2. 客户端私有数据 private_x = 3.0 print(f"[Client] Private input x = {private_x}") # 3. 加密数据 (模拟) # 在实际中,这里调用 FHE 库的 Encrypt(pk, x) 函数 encrypted_x = MockCiphertext(data=keypair.pk(private_x)) print(f"[Client] Encrypted x to: {encrypted_x}") # 4. 发送密文到服务端 (模拟网络发送) # 在实际中,这里进行网络序列化 print("[Client] Sending ciphertext to server...") # 模拟服务端接收 from server import heir_linear_fn, MODEL_WEIGHT, MODEL_BIAS encrypted_y = heir_linear_fn(encrypted_x, MODEL_WEIGHT, MODEL_BIAS) print(f"[Server] Computed ciphertext result: {encrypted_y}") # 5. 服务端返回密文结果 (模拟网络接收) print("[Client] Received ciphertext result from server.") # 6. 客户端解密结果 (模拟) # 在实际中,这里调用 FHE 库的 Decrypt(sk, ctxt_y) 函数 decrypted_y = keypair.sk(encrypted_y.data) print(f"[Client] Decrypted result y = {decrypted_y}") # 7. 验证 (仅用于演示,实际中客户端无法直接计算明文结果) expected_y = MODEL_WEIGHT * private_x + MODEL_BIAS print(f"[Client] Expected result (plaintext): {expected_y}") print(f"[Client] Result matches: {abs(decrypted_y - expected_y) < 1e-9}") if __name__ == "__main__": client_process()4.4 运行模拟与结果分析
将server.py和client.py放在同一目录,运行客户端脚本:
python client.py预期输出类似于:
[Client] Key pair generated. [Client] Private input x = 3.0 [Client] Encrypted x to: MockCiphertext(3082) # 3000 + 随机噪声82 [Client] Sending ciphertext to server... [Server] Performing homomorphic computation: 2.5 * ctxt_x + 1.0 [Server] Computed ciphertext result: MockCiphertext(7706.0) # 3082 * 2.5 + 1.0 = 7706.0 [Client] Received ciphertext result from server. [Client] Decrypted result y = 7.0 # 7706 // 1000 = 7 [Client] Expected result (plaintext): 8.5 [Client] Result matches: False关键分析:
- 流程模拟成功:我们模拟了加密、发送、计算、返回、解密的完整流程。
- 安全模拟失败:为了演示,我们在服务端直接对“密文数据”进行了明文运算 (
w * ctxt_x.data + b)。这在真正的同态加密中是绝对不允许的,服务端只能看到真正的密文(复杂的数学结构),无法进行这种操作。我们的模拟在安全上毫无意义。 - 结果误差:由于我们使用了整数除法模拟解密,并引入了随机噪声,导致结果 (
7.0) 与期望 (8.5) 不符。这恰恰反映了 FHE 的两个现实问题:噪声管理和精度损失(CKKS 方案是近似计算)。
这个模拟的核心价值在于理解架构和流程。真正的实现需要:
- 集成一个真实的 FHE 库(如 OpenFHE)。
- 使用 HEIR 或手动编写代码,调用该库的 API 实现真正的密文加法和乘法。
- 处理密钥生成、序列化、噪声控制、参数选择等一系列复杂问题。
5. 挑战、最佳实践与未来展望
将 HEIR 与同态加密用于实际的私有 AI 推理,目前仍面临诸多挑战。理解这些挑战和应对策略,比单纯跑通一个 demo 更重要。
5.1 当前面临的主要挑战
- 性能开销:这是最显著的障碍。即使是经过 HEIR 等编译器优化,FHE 的计算速度仍比明文慢千倍以上,内存占用也大得多。这限制了其应用场景主要是对延迟不敏感、但隐私要求极高的低频、高价值推理。
- 计算复杂度限制:FHE 操作(尤其是乘法)的深度受噪声增长限制。复杂的神经网络(如深度 CNN、Transformer)需要大量的乘加操作,可能超出当前 FHE 方案在可用参数下的计算深度。需要通过模型剪枝、量化、使用低深度近似激活函数(如多项式近似 ReLU)等技术来简化模型。
- 精度与噪声平衡:CKKS 方案提供近似计算,存在精度损失。需要在安全参数(噪声预算)、精度和性能之间进行精细权衡。
- 通信开销:密文尺寸巨大(从 KB 到 MB 级),客户端上传密文输入和下载密文结果会产生显著的网络带宽消耗。
- 工具链成熟度:HEIR 本身仍处于早期阶段,文档、示例、与流行 AI 框架(如 TensorFlow, PyTorch)的集成都不完善,需要较高的技术门槛进行集成和调试。
- 密钥管理:在实际系统中,密钥的生成、分发、轮换、存储和备份是一套复杂的工程,需要专门的安全基础设施支持。
5.2 开发与部署最佳实践建议
尽管处于早期,但如果你决定探索或预研此项技术,以下实践能帮你少走弯路:
- 从微小模型开始:不要试图一开始就加密整个 ResNet 或 BERT。从一个只有几层、几十个参数的线性或逻辑回归模型开始,验证整个流程。
- 明确安全假设:同态加密保护的是数据在计算过程中的机密性。它不解决模型本身的保护(模型提取攻击)、计算完整性(恶意服务器返回错误结果)或输入/输出隐私(从结果反推输入)等所有问题。需要结合可信执行环境、零知识证明等其他技术构建完整方案。
- 深度参与 HEIR 社区:关注其 GitHub Issues、Discussions 和邮件列表。早期的项目,社区的帮助和代码贡献是解决问题最快的方式。
- 性能分析与瓶颈定位:使用 profiling 工具分析生成的代码,计算开销主要在哪里?是密钥切换、自举,还是普通的乘加?这有助于指导模型优化和编译器优化策略的选择。
- 设计可降级的服务架构:考虑到 FHE 的性能限制,设计系统时应允许在负载过高或计算过于复杂时,回退到基于可信硬件(如 Intel SGX)或联邦学习等其他隐私计算方案,确保服务可用性。
5.3 未来展望与学习路径
HEIR 代表了 FHE 实用化的一条重要路径:通过编译器技术降低开发难度。未来的演进可能包括:
- 更高级的 DSL:提供更贴近数据科学家习惯的领域特定语言来描述计算。
- 自动化优化:编译器自动进行算子融合、调度优化、选择最优的 FHE 参数和方案。
- 硬件加速:与 GPU、FPGA 甚至专用 ASIC 的 FHE 加速器协同工作。
对于开发者而言,循序渐进的学习路径是:
- 理解基础:学习现代 FHE 的基本原理(BFV, CKKS 方案),理解密文、明文、密钥、噪声、自举等核心概念。
- 上手库:直接使用
OpenFHE或Microsoft SEAL库,编写简单的密文加法和乘法程序,直观感受其 API 和性能。 - 探索编译器:学习 MLIR 基础,然后研究 HEIR 项目的代码结构、示例和文档,尝试编译和运行其测试用例。
- 尝试集成:将一个简单的 ONNX 模型或 PyTorch 模型,通过工具转换为 MLIR 表示,再尝试用 HEIR 流水线进行编译(这可能需要自己编写或寻找模型到 MLIR 的转换器)。
- 关注生态:关注
TF-Encrypted,Concrete ML等其他隐私机器学习框架的发展,了解不同的技术路线。
私有化 AI 推理的需求只会越来越强烈。同态加密作为提供最强安全保证的技术,其工程化道路虽然漫长,但像 HEIR 这样的项目正在为其铺平道路。现在开始积累相关知识,不是为了立刻投产,而是为了在技术拐点到来时,能够拥有设计和评估解决方案的能力。从理解一个编译器的使命开始,到能够勾勒出一个隐私保护推理服务的架构图,这本身就是一次有价值的技术前瞻。