主页
2026 年 8 月 14 日,Google 开源了 HEIR —— 一个能把普通模型自动改写成「在密文上跑」的编译器。这份文档讲清楚:它到底做了什么、怎么上手、什么场景值得用、以及为什么它仍然很慢。
On August 14, 2026, Google open-sourced HEIR — a compiler that rewrites ordinary models so they run directly on ciphertexts. This document covers what it actually does, how to get started, where it's worth using, and why it is still slow.
今天几乎所有云端 AI 都有一个默认前提:你得先把明文数据交给服务器。同态加密(Homomorphic Encryption,简称 HE)推翻了这个前提——它让服务器能在加密后的数据上直接做计算,算完返回一个加密结果,只有你手上的密钥能解开。整个过程中服务器从没见过明文。
Nearly all cloud AI today assumes one thing: you hand the server your plaintext data first. Homomorphic encryption (HE) removes that assumption — the server computes directly on encrypted data, returns an encrypted result, and only your key can open it. The server never sees plaintext at any point.
这不是新想法,但一直卡在两件事上:太慢,以及太难写。Google 的 HEIR 攻的是第二件。Google 官方博客(2026-08-14)的说法是:「手工把一个现有程序高效改造成同态加密版本,需要一支密码学团队」;HEIR 的目标是让你「用 Python 写程序,标注哪些类型是 secret,剩下的交给 HEIR 编译」。
This isn't a new idea, but it has been stuck on two problems: it's too slow, and it's too hard to write. Google's HEIR attacks the second. As Google's blog put it (2026-08-14): "manually converting an existing program to use homomorphic encryption efficiently requires a team of cryptographers." HEIR's pitch is that you "write a program in Python, annotate the types to mark which are secret, and HEIR will compile the rest."
先讲痛点,再讲定义。
Motivation first, definitions later.
Google 的博客把问题说得很直接:标准的端到端加密其实是一笔交易——用户数据能防住数据泄露,但服务提供方也因此没法再提供任何依赖这份数据的功能,比如垃圾邮件检测、病毒检测。
Google's post states the problem plainly: standard end-to-end encryption is a trade-off — user data is protected from breaches, but the service provider then cannot provide any feature that depends on that data, such as spam or virus detection.
那把计算搬到本地呢?博客也否掉了:本地处理「受限于本地设备的能力,以及服务方 IP 的敏感度」——把专有模型发到设备上,就有模型被窃取的风险。所以这是一个三方为难的局面:数据敏感、算力在云上、模型也是资产。
What about moving compute to the device? The post rules that out too: local processing is "limited by the capabilities of the local device and the sensitivity of the service provider's IP" — shipping a proprietary model to a device risks leaking the model. So it is a three-way bind: the data is sensitive, the compute is in the cloud, and the model is itself an asset.
你要把一卷底片送去冲印店。传统做法是把底片交出去——店员看得到每一张照片。同态加密相当于:你把底片装进一个特制暗盒,店员的机器能隔着盒子完成冲印的每一道工序,取出来的成品还在盒子里,只有你手上的钥匙能打开。店员全程知道自己在「冲印」,但从没看过任何一张画面。
You send a roll of film to a lab. Normally you hand over the negatives — the technician sees every frame. Homomorphic encryption is like sealing the roll in a special light-tight box: the lab's machine performs every step of development through the box, and the finished prints come out still inside it, openable only with your key. The technician knows they were developing film, but never saw a single frame.
这件事对哪些行业最要紧?博客点名了医疗和金融——这些领域「对风险更加厌恶,而且严格的法规限制了机构之间的数据共享」。这正是密文推理的价值所在:它不是让现有产品更快,而是让某些本来根本不可能上云的工作负载变得可能。
Which industries care most? The post names healthcare and finance — sectors that are "even more averse to these risks," where "strict regulations limit data sharing across institutions." That is where the value sits: encrypted inference doesn't make existing products faster, it makes certain workloads that could never have gone to the cloud at all possible.
理解这三件事,就能理解 FHE 的全部成本结构。
Understand these three things and you understand FHE's entire cost structure.
这是 FHE 最反直觉、也最决定成本的一点。为了保证安全性,加密时会往密文里掺入随机噪声。问题是:每做一次同态运算,噪声都会变大——而且乘法比加法涨得凶得多。研究文献的描述是:噪声在若干次运算后会指数级增长,一旦超过阈值,解密出来的就是垃圾。
This is FHE's most counter-intuitive property and the one that sets its cost. For security, encryption mixes random noise into the ciphertext. The catch: every homomorphic operation grows that noise — and multiplication grows it far faster than addition. The literature describes noise as increasing exponentially after several operations; past a threshold, decryption returns garbage.
FHE 天生擅长加法和乘法,而神经网络里的矩阵乘法恰好就是这两样——这部分其实还好。真正的麻烦是非线性激活:ReLU、Softmax、GELU 这些函数没法用有限次加乘直接表达。
FHE is natively good at addition and multiplication, and a neural network's matrix multiplications are exactly that — so that part is manageable. The real trouble is nonlinear activations: ReLU, Softmax, GELU cannot be expressed directly with a finite number of adds and multiplies.
通行做法是用高次多项式去逼近它们。但多项式次数越高,乘法链就越深,噪声涨得越猛,越早需要 bootstrapping。研究文献总结得很精炼:FHE 与 Transformer 架构相冲突——「僵硬的密文打包要求昂贵的旋转操作,而非线性所需的深层多项式电路又迫使昂贵的 bootstrapping」。
The standard workaround is to approximate them with high-degree polynomials. But higher degree means a deeper multiplication chain, faster noise growth, and an earlier bootstrap. The literature puts it crisply: FHE clashes with transformer architectures, where "rigid ciphertext packing demands expensive rotations, and deep polynomial circuits for nonlinearities necessitate costly bootstrapping."
ReLU 的定义是「大于 0 就保留,小于 0 就归零」——它需要比较。而密文里的数你根本看不见,没法比较。于是只能画一条尽量像 ReLU 的光滑曲线去替代它,而画得越像,曲线的多项式次数就越高,计算就越贵。在 HEIR 的 MLIR 输入里,这个取舍是明写出来的一个参数:degree = 6,配合 lower / upper 指定逼近的取值范围。
ReLU says "keep it if positive, zero it if negative" — that requires a comparison. Inside a ciphertext you cannot see the value, so you cannot compare. The fix is to draw a smooth curve that resembles ReLU, and the closer the resemblance, the higher the polynomial degree and the higher the cost. In HEIR's MLIR input this trade-off is an explicit parameter: degree = 6, alongside lower / upper bounds for the approximation range.
既然单次密文运算这么贵,自然的优化是:一个密文里塞很多个数,一次运算同时算完——这就是 SIMD 打包。CKKS 方案「在近似实数上计算,配合大量 SIMD 打包,使它成为机器学习和统计场景的首选方案」。
Since a single ciphertext operation is so costly, the natural optimisation is to pack many values into one ciphertext and process them in a single operation — SIMD packing. CKKS "computes on approximate real numbers with heavy SIMD packing, making it the scheme of choice for machine learning and statistics."
代价是:数据在密文的哪个「槽位」(slot)上,就变成了一个需要优化的问题。要把两个不在同一槽位的数加起来,得先做旋转(rotation)把它们对齐,而旋转本身也不便宜。HEIR 把这件事抽象成了「布局(layout)」,并用整数集合库(ISL)做多面体优化来选最优布局——这是它区别于手写 FHE 代码的核心价值之一。
The cost: which "slot" a value sits in becomes an optimisation problem of its own. Adding two values in different slots requires a rotation to align them first, and rotations are not cheap either. HEIR abstracts this as a "layout" and uses the Integer Set Library for polyhedral optimisation over layouts — one of its core advantages over hand-written FHE code.
以下命令与代码全部来自 HEIR 官方 Getting Started 文档(该页最后更新:2026-08-11)。
All commands and code below come from HEIR's official Getting Started page (last updated 2026-08-11).
heir-opt(跑编译 pass)和 heir-translate(后端代码生成)这两个「大杂烩」二进制。另外,预构建的 nightly 二进制官方说明是「用于测试编译器 pass,不用于生产」。
The docs say plainly that the HEIR team is still working on an end-to-end binary for certain workflows (such as converting pre-compiled torch models to a specific backend); in the meantime you use the "kitchen sink" binaries heir-opt (compiler passes) and heir-translate (backend codegen). The prebuilt nightly binary is also explicitly "intended for testing compiler passes and not for production use."
官方发布了 Python 包 heir_py,里面带 heir-opt 和 heir-translate 二进制,还可选带前后端:
There is an official Python package, heir_py, which bundles the heir-opt and heir-translate binaries and optionally front- and backends:
python -m venv venv
source venv/bin/activate
pip install "heir_py[python,openfhe]"
heir-opt --help
heir-translate --help装好支持的后端(如 OpenFHE)后,就能用装饰器写「密文函数」。注意 Secret[I64] —— 这就是官方说的「标注哪些类型是 secret」:
With a supported backend installed (e.g. OpenFHE), you can write an encrypted function with a decorator. Note Secret[I64] — this is the "annotate the types to mark which are secret" part:
from heir import compile
from heir.mlir import I64, Secret
@compile() # defaults to scheme="bgv", OpenFHE backend, and debug=False
def func(x: Secret[I64], y: Secret[I64]):
sum = x + y
diff = x - y
mul = x * y
expression = sum * diff + mul
deadcode = expression * mul
return expression
func.setup()
enc_x = func.encrypt_x(7)
enc_y = func.encrypt_y(8)
result_enc = func.eval(enc_x, enc_y)
result = func.decrypt_result(result_enc)官方的 dot-product 例子最能说明 HEIR 在做什么。输入是一段 MLIR,注意参数上的 {secret.secret} 标注——这就是全部的「加密声明」:
The official dot-product example is the clearest illustration. The input is MLIR; note the {secret.secret} annotation on the arguments — that is the entire "encryption declaration":
func.func @dot_product(%arg0: tensor<8xi16> {secret.secret},
%arg1: tensor<8xi16> {secret.secret}) -> i16 {
%c0 = arith.constant 0 : index
%c0_si16 = arith.constant 0 : i16
%0 = affine.for %arg2 = 0 to 8 iter_args(%iter = %c0_si16) -> (i16) {
%1 = tensor.extract %arg0[%arg2] : tensor<8xi16>
%2 = tensor.extract %arg1[%arg2] : tensor<8xi16>
%3 = arith.muli %1, %2 : i16
%4 = arith.addi %iter, %3 : i16
affine.yield %4 : i16
}
return %0 : i16
}tests/Examples/common/dot_product_8.mlirtests/Examples/common/dot_product_8.mlirheir-opt \
--mlir-to-bgv='min-slot-count=8' \
--scheme-to-openfhe='entry-function=dot_product' \
dot_product_8.mlir > output.mlirheir-translate 产出 OpenFHE 的 C++ 头文件和实现。heir-translate --emit-openfhe-pke-header \
--openfhe-include-type=source-relative output.mlir > heir_output.h
heir-translate --emit-openfhe-pke \
--openfhe-include-type=source-relative output.mlir > heir_output.cpp__encrypt__argN / __decrypt__result0 / __generate_crypto_context / __configure_crypto_context 这几个客户端辅助函数。官方示例的运行结果是 Expected: 240 / Actual: 240。heir-opt \
--mlir-to-bgv='min-slot-count=8' \
--scheme-to-openfhe='entry-function=dot_product' \
dot_product_8.mlir > output.mlirheir-translate to produce the OpenFHE C++ header and implementation.heir-translate --emit-openfhe-pke-header \
--openfhe-include-type=source-relative output.mlir > heir_output.h
heir-translate --emit-openfhe-pke \
--openfhe-include-type=source-relative output.mlir > heir_output.cpp__encrypt__argN, __decrypt__result0, __generate_crypto_context and __configure_crypto_context. The official example prints Expected: 240 / Actual: 240.最能说明「编译器在替你想事情」的是生成出来的 C++:一个朴素的循环点积,被编译成了旋转-归约(rotate-and-reduce)模式——先做一次密文乘法和 relinearize,然后按 4、2、1 三次旋转累加,而不是老老实实循环 8 次。这正是手写 FHE 代码时需要密码学经验才能想到的优化。
The clearest sign that the compiler is thinking for you is the generated C++: a naive loop-based dot product compiles into a rotate-and-reduce pattern — one ciphertext multiply plus relinearize, then rotations by 4, 2 and 1 with accumulation, rather than eight literal loop iterations. That is exactly the optimisation that hand-written FHE code needs cryptography experience to find.
const auto& v4 = v0->EvalMultNoRelin(v1, v2);
const auto& v5 = v0->Relinearize(v4);
const auto& v6 = v0->EvalRotate(v5, 4);
const auto& v7 = v0->EvalAdd(v5, v6);
const auto& v8 = v0->EvalRotate(v7, 2);
const auto& v9 = v0->EvalAdd(v7, v8);
const auto& v10 = v0->EvalRotate(v9, 1);
const auto& v11 = v0->EvalAdd(v9, v10);heir_output.cpp 节选(rotate-and-reduce 模式)heir_output.cpp in HEIR's Getting Started (rotate-and-reduce pattern)如果项目用 bazel,官方推荐 rules_heir,它把连接 HEIR 与应用的大量细节藏了起来。核心是一个 heir_lattigo_lib 宏,把 heir-opt / heir-translate 的 flag 写在 BUILD 文件里:
If your project uses bazel, the docs recommend rules_heir, which hides most of the wiring between HEIR and your application. The core is a heir_lattigo_lib macro that puts the heir-opt / heir-translate flags in your BUILD file:
heir_lattigo_lib(
name = "hello_world",
go_library_name = "helloworld",
heir_opt_flags = [
"--annotate-module=backend=lattigo scheme=ckks",
"--mlir-to-ckks=min-slot-count=2048 first-mod-bits=0",
"--scheme-to-lattigo",
],
mlir_src = "hello_world.mlir",
split_preprocessing = False,
)从源码构建只需 Git 和 bazelisk,其余依赖(C++/Go/Rust 编译器、Python 解释器)全由 bazel 管理:git clone git@github.com:google/heir.git && cd heir,然后 bazel build -c opt @heir//tools:heir-opt。注意 Linux 上不能用 root 身份跑 bazel。想省事就下 nightly 二进制(记住:仅供测试,不用于生产):wget -O heir-opt https://github.com/google/heir/releases/download/nightly/heir-opt-manylinux_2_28_x86_64。
Building from source needs only Git and bazelisk; bazel manages everything else (C++/Go/Rust compilers, Python interpreter): git clone git@github.com:google/heir.git && cd heir, then bazel build -c opt @heir//tools:heir-opt. Note that on Linux your user must not be root. For a shortcut, grab the nightly binary (testing only, not production): wget -O heir-opt https://github.com/google/heir/releases/download/nightly/heir-opt-manylinux_2_28_x86_64.
这一节的内容来自 HEIR 官方设计文档「ML with HEIR」及其对应论文 arXiv:2508.11095。
This section draws on HEIR's official design page "ML with HEIR" and its companion paper, arXiv:2508.11095.
HEIR 的 ML 前端把 PyTorch、TensorFlow、ONNX 三条路,分别经由 torch-mlir、onnx-mlir、StableHLO 汇聚到一个统一的入口层:MLIR 的 linalg 方言。文档解释了为什么选 linalg——这个抽象层级刚好能匹配 ML 的 kernel 操作做优化。
HEIR's ML frontend funnels PyTorch, TensorFlow and ONNX — via torch-mlir, onnx-mlir and StableHLO respectively — into a single entry level: MLIR's linalg dialect. The docs explain the choice: that abstraction level is the one at which ML kernel operations can be matched for optimisation.
官方文档列出的「编译配置」项恰好是一份很好的心智清单——它们就是 FHE 部署里真正要做的决策:
The "compilation configuration" list in the docs doubles as a good mental checklist — these are the decisions an FHE deployment actually involves:
degree)lower / upper)kernel = "diagonal")degree above)lower / upper)kernel = "diagonal")module attributes {backend.openfhe, scheme.ckks} {
func.func @mnist(%input: tensor<784> {secret.secret}) -> tensor<10> {
%matrix1 = arith.constant dense<...> : tensor<512x784>
%0 = linalg.matvec ins(%matrix1, %input) {kernel = "diagonal"}
%1 = arith.addf %0, %bias1
%2 = arith.maximumf %1, %cst {degree = 6, lower = -15.0, upper = 12}
...
}
}degree = 6 就是 ReLU 的多项式逼近次数。degree = 6 is the polynomial approximation degree for ReLU.前面提到「数据在哪个槽位」是个优化问题。HEIR 的做法是把布局形式化为一个部分函数:从明文张量的索引集合,映射到一串密文槽位的索引集合,用 Presburger 关系和拟仿射公式表达。然后用整数集合库(ISL)做多面体分析,来计算 kernel 简化或批处理的槽位利用率。
Recall that "which slot holds which value" is an optimisation problem. HEIR formalises a layout as a partial function from the index set of a cleartext tensor to the index set of a list of ciphertext slots, expressed with Presburger relations and quasi-affine formulas. It then runs polyhedral analysis via the Integer Set Library to compute kernel simplifications and slot utilisation for batching.
优化流程分三步:Propagate(前向分析,给 IR 传播默认布局与 kernel)→ Optimize(用成本模型选最优 kernel,最小化布局转换)→ Simplify(反向遍历,把布局转换提升到编码阶段)。
The flow has three stages: Propagate (forward analysis seeds the IR with default layouts and kernels) → Optimize (cost models pick kernels that minimise cost and layout conversions) → Simplify (a backwards traversal hoists layout conversions into encodings).
这四个例子都用 HEIR 编译,官方给出的延迟数据基于单线程 CPU。
All four were compiled with HEIR; the official latency figures are for a single-threaded CPU.
| 场景 | 解决什么问题 | 合作方 |
|---|---|---|
| 深度学习推荐模型(DLRM) | 提供私密内容推荐——云服务能推荐,却看不到用户特征 | Belfort Labs、LG、纽约大学 |
| 信用卡欺诈检测 | 在不暴露交易明文的前提下判断是否欺诈 | Niobium、hardshell.ai |
| 入侵检测(Kitsune 系统) | 对加密网络流量做异常检测,服务方看不到数据包内容 | Niobium |
| 唤醒词检测 | 让音频触发的 AI Agent 识别唤醒词,同时保护录音隐私 | Belfort Labs |
| Application | What it solves | Partners |
|---|---|---|
| Deep Learning Recommendation Model (DLRM) | Private content recommendations — the service recommends without seeing user features | Belfort Labs, LG, New York University |
| Credit card fraud detection | Judge whether a transaction is fraudulent without exposing it in the clear | Niobium, hardshell.ai |
| Threat intrusion (Kitsune) | Anomaly detection over encrypted network traffic without revealing packet contents | Niobium |
| Hotword detection | Let an audio-triggered AI agent recognise hotwords while protecting the recordings | Belfort Labs |
注意这四个的共同点:模型都不大,输出都很小——一个推荐分数、一个欺诈标签、一个异常判定、一个「是/否唤醒」。这不是巧合,而是 FHE 当前成本结构决定的选型逻辑:输入敏感、模型不深、输出是个标量或短向量的任务,是这条路线的甜点区。
Note what these four share: the models are small and the outputs are tiny — a recommendation score, a fraud flag, an anomaly verdict, a yes/no wake decision. That is not coincidence but the selection logic FHE's current cost structure imposes: tasks with sensitive inputs, shallow models, and a scalar or short-vector output are the sweet spot.
官方博客提到:自 2023 年宣布意向以来,HEIR 已与开发 FHE 硬件加速器的公司合作,包括 Belfort、Niobium、Cornami、Optalysys;学术侧的合作包括佐治亚理工、卡内基梅隆、UC 圣塔芭芭拉、伊利诺伊理工、普渡、爱丁堡大学、清华大学等。截至发文,已有四篇同行评审论文基于 HEIR 完成,更多在准备中。
Google's post notes that since announcing its intentions in 2023, HEIR has partnered with FHE hardware-accelerator companies including Belfort, Niobium, Cornami and Optalysys, and with academic groups at Georgia Tech, Carnegie Mellon, UC Santa Barbara, Illinois Institute of Technology, Purdue, the University of Edinburgh and Tsinghua University. As of publication, four peer-reviewed publications were built on HEIR, with more in preparation.
这一节的判断来自第三方分析文章,属于社区观点而非官方结论,请据此权衡。
This section reflects third-party analysis — community opinion rather than official conclusions. Weigh accordingly.
| 技术 | 信任谁 | 性能量级 | 适合什么 |
|---|---|---|---|
| FHE(本文主角) | 只信数学。安全性是纯密码学的,不依赖硬件厂商 | 据分析文章,面临 10⁶× 量级的减速挑战;另有测算称即使精心设计电路,FHE 运算仍比明文慢 10³–10⁵ 倍 | 硬件信任不可接受的场景;跨机构、强监管行业 |
| TEE(可信执行环境) | 信芯片厂商(Intel / AMD / NVIDIA) | 据分析,开销在个位数百分比;NVIDIA 2023 年把 TEE 扩展到 GPU | 被称为大规模机密工作负载的「务实默认选项」 |
| MPC(安全多方计算) | 信「参与方不合谋」 | 主要瓶颈是通信开销 | 多方各持一部分输入、要联合计算的场景 |
| ZK(零知识证明) | 信数学 | 据称已可用于生产 | 选择性披露、可验证计算——注意它解决的是「证明」不是「保密计算」 |
| Technology | Who you trust | Performance order | Best for |
|---|---|---|---|
| FHE (this article) | Only mathematics. Guarantees are purely cryptographic, not hardware-dependent | Analyses cite a ~10⁶× slowdown challenge; other estimates put carefully engineered FHE at 10³–10⁵× slower than cleartext | Cases where hardware trust is unacceptable; cross-institution, heavily regulated sectors |
| TEE (trusted execution environment) | Chip vendors (Intel / AMD / NVIDIA) | Reported single-digit-percent overhead; NVIDIA extended TEE to GPUs in 2023 | Described as the "pragmatic default" for large confidential workloads |
| MPC (secure multiparty computation) | That the parties do not collude | Main bottleneck is communication overhead | Several parties each hold part of the input and must compute jointly |
| ZK (zero-knowledge proofs) | Mathematics | Reported production-ready | Selective disclosure and verifiable compute — note it solves proving, not confidential computation |
一篇分析文章给出的选型框架很实用,归结为四个问题:谁绝对不能看到这份数据?需要的是「验证」还是「计算」?被隐藏的工作负载有多大?有几方持有输入?把这四个问题回答清楚,技术选型基本就定了。
One analysis offers a practical selection framework built on four questions: who must not see the data; is the need verification or computation; how big is the hidden workload; and how many parties hold inputs? Answer those four and the technology choice largely falls out.
heir-opt 与 heir-translate;OpenFHE 之外的后端支持仍在推进;nightly 二进制明确标注不用于生产。
HEIR's stated vision is "a one-click solution to enable non-experts to incorporate encrypted inference into production applications" — note that this is a vision. Today: the end-to-end binary is still being built, you wire heir-opt and heir-translate by hand, backends beyond OpenFHE are in progress, and the nightly binary is explicitly not for production.
errorThreshold = 0.0001 来做断言。做决策系统时,这个误差必须纳入设计,不能假设精确相等。
CKKS is defined as computing "on approximate real numbers." Results carry a controlled numerical error — HEIR's own Go test for the dot-product example asserts with errorThreshold = 0.0001. If you build a decision system on it, that error must be part of the design; do not assume exact equality.
ckks 方言。cggi 方言,常见于 FPGA 加速器集成。ckks dialect.cggi dialect, common in FPGA accelerator integrations.good first issue 和 contributions welcome 标签入手good first issue and contributions welcome labels