做 FHE 推理难点往往不在“哪个同态算子实现得漂亮”而在于从明文输入到密文结果这条链路中间的所有环节能不能像一台流水线机器那样咬合紧密。这篇文章是“同态加密推理”系列的第二篇重点把引擎的全景摊开完整走一遍密态推理的数据流明文侧由 Python 负责指挥和预处理密文侧由 C11 实现的底层引擎负责真正的密文计算。看完之后你会对“一次密态推理到底经历了什么、每步在哪里耗时、哪一步最容易爆预算”有个比较清楚的判断也能直接照着后面给出的最小示例搭一个能跑的骨架。1. 为什么要有一个“引擎”密态推理不是写一个函数那么简单1.1 单次调用不复杂复杂的是管住状态如果只是做一次一层的函数计算比如把某个数乘 2 再加 1那谈不上“引擎”。直接调库就行。但推理是另一回事一个普通的三层 MLP哪怕是每层只有几十个神经元放在明文世界也就是几十行矩阵乘换成密文世界立刻变成一系列需要严格排序的密文乘法、密文旋转、明文乘、重缩放rescale、重线性化relinearization。这些操作之间不是独立的每一步都会改变密文的噪声预算、缩放因子、链层级level乱一步就可能解出垃圾。所以我一直认为同态加密推理的项目里最值得先花时间做的不是挑一个性能最好的底层加密库而是把一个“引擎”的框架立起来。所谓引擎在我这里的定义就是把加密参数、密钥生成、编解码、密文执行、序列化传输、明文预处理、结果后处理这些环节统一封装成可复用的模块对外只暴露“你给我明文的输入和模型描述我还给你解密后的推理结果”这样的接口。真正的业务逻辑不要跟具体的 FHE 算子混在一起。1.2 引擎全景六个模块的分工一个能支撑密态推理的引擎在我实践中通常分成六个模块任何一个缺位都会在调试期让你抓狂模块职责常被忽略的细节参数器根据模型结构和精度要求生成加密参数N、scale、链长度等不是随便选要留足深度预算和噪声余量编码器/解码器浮点向量转明文多项式以及逆过程缩放因子的维护全在这个模块里最容易踩坑密钥调度器密钥生成、旋转密钥、重线性化密钥的管理旋转密钥和重线性化密钥都要单独生成并分发很多人会忘记执行器密态运算的封装提供 add、multiply_plain、rotate、rescale 等高层接口要对 level 和 scale 做检测避免静默出错IO 序列化把密文、公钥、参数序列化成字节流供 Python 和 C 两侧传输格式统一否则 Python 发给 C 的密文解析直接断裂跟踪/调试器明文干跑、分步解密、噪声预算打印没有这个模块你会在“解密出乱码”上浪费大量时间这六块里面我见过最多的项目翻车是因为后面三块没做好。加密算法本身的正确性大家反而很少写错因为库都给你封装好了。真正难的是你的模型逻辑要映射到密文运算上还要能中间观测、能序列化、能追踪。所以在设计引擎时第一优先级不是性能优化而是可观测性和可验证性。2. 一次密态推理的完整数据流2.1 明文端归一化与离散化一次推理流程从明文数据进入引擎之前就开始了。这里有一个很容易被新手忽略的点FHE 推理的输入必须是“已经定好范围”的浮点向量。比如明文原始特征是 0 到 1000 的身高、0 到 200 的体重如果不做归一化直接编码进 CKKS很快会因为数值范围太大导致 scale 不够用精度崩掉。所以常规做法是在 Python 侧先用 numpy 或标准库完成归一化、截断、转成 float64然后把数值范围压缩到比如 [-1, 1] 或者 [0, 1] 之间。这个阶段还有一个更隐蔽的问题模型参数的编码。要推理模型权重也是明文状态下就要参与计算的。在 FHE 场景里权重通常作为“明文”直接编码成明文多项式而不是加密成密文。这样做的原因是权重在推理前就是静态的不需要保密输入数据才需要保密。如果你把权重也加密了那计算复杂度和噪声预算会成倍上涨而且毫无必要。所以数据流里输入向量走加密路径模型权重走“明文编码路径”两者在执行器里以密文乘明文的形式结合。2.2 编码与加密从浮点数到多项式拿到归一化后的浮点向量后引擎的第一步是在 C11 侧完成编码也就是把浮点向量嵌入到多项式环里。这个过程在 CKKS 方案中叫做 encoding简单理解就是把一个向量“塞”进一个 N 次单位根对应的高维空间让后续的密文运算能在向量维度上执行 SIMD 式的并行计算。这里会引入一个叫 scale 的参数它本质上是定点数里的精度档位向量每个分量先乘上 scale比如 2^40再量化成整数多项式系数。加密这一步没有太多玄幻的地方基于 RLWE把编码后的明文多项式加上随机噪声并用公钥加密得到一个“两到三个多项式”组成的密文对象。从此这张“密文”就在数学上同时携带了数据和噪声所有后续密态运算都会让原始的噪声一点点长大当噪声大到覆盖有效数值位时解密函数就会把噪声当作数据还原出来结果就是一堆乱码。2.3 推理主链路乘、加、旋转与重缩放进入推理层最常见也最核心的运算是“矩阵乘法”。一个典型的全连接层 y Wx b在密态下并不是直接对整张矩阵做运算而是要把矩阵乘拆解成密文与明文的点积和累加。比较朴素的做法是把权重 W 的每一行编码成一个明文向量对输入密文向量做密文乘明文、然后累加。但这样每一行都要一次密文乘法层宽一大开销和噪声预算都hold不住。更常用的做法是把矩阵的每条对角线上权重打包成明文向量然后对输入密文做逐位的明文乘接着对结果做密文旋转rotate将所有对齐到同一位置的分量累加。这种方式把矩阵乘变成了“乘法 旋转 累加”的组合代价是需要非常密集地使用旋转密钥。这也是为什么在密态推理里旋转密钥的管理比加密密钥更让引擎设计者头疼——不同层要旋转的步数不同每次旋转都要对应一把指定的旋转密钥漏掉一个就会在执行期报错。做完一层线性变换后激活函数又是一个关键环节。CKKS 无法直接执行 ReLU 这种非多项式函数所以我们必须把激活函数替换成多项式近似比如用切比雪夫近似或者简单的最小二乘拟合。在演示和小模型里用平方激活或者低次多项式激活已经足够验证数据流等到了正式场景再针对具体激活函数做多项式逼近的参数搜索。每一步密文乘法执行完以后都要伴随一次重缩放rescale。重缩放的作用是把密文除以 scale把缩放因子降回初始水平同时消耗一个层级level。这个过程本质上就是数值计算里的归一化只不过在密态下完成。所以引擎的参数器必须提前算好模型推理总共有多少层、每层多少次乘法据此来配置初始层数否则算到一半层级耗尽引擎直接罢工。2.4 解密与后处理最后一公里同样要小心推理结果的密文经过解密函数还原成明文多项式后还不能直接拿去跟标准答案比。你必须再做一次解码把多项式分量映射回浮点数再除以 scale。这里有个极为常见的坑如果在推理过程中某一步没有及时重缩放scale 就不是初始 scale解密出来除以初始 scale 后数值会整体偏掉一个 2^k 的倍数。这正是“算出来结果巨大”这类问题最常见的根源。后处理阶段还包括反归一化。比如前面把输入特征压缩到 [-1,1]那推理输出的 logits 往往也要根据训练时的均值方差做恢复甚至还要过一个 softmax 才能得到概率。这部分在一个完整的引擎里通常放在 Python 侧因为已经解密成明文了没有任何加密开销。很多初学的朋友容易忽略密态推理从外部看是一个“黑盒的结果”但在引擎内部后处理阶段还是标准的明文机器学习流程模型训练时的预处理管线要原样搬过来一点点差异都会导致精度漂移。3. 明文 Python × 密文 C11那条“看不见的边界”3.1 为什么边界要画在这里“明文 Python × 密文 C11”这个标题组合在我实际操作下来确实是最舒服的分工方式。先说为什么 Python 要负责明文侧模型训练、数据预处理、结果评估、可视化这些环节的生态全部在 Python 这边你没必要用 C 重新造一遍 numpy 和 sklearn。而且业务逻辑在 Python 侧可以快速迭代调参、看指标都很方便。那为什么密文计算要下沉到 C11 的底层引擎核心原因是性能与内存控制。FHE 的核心运算是多项式乘法底层会用到 NTT数论变换、多线程并行、大数运算。Python 解释执行跑这种计算性能上会有数量级的差距内存分配也不可控。把热路径放在 C 里密文对象本质是若干大整数数组的内存生命周期可以严格控制配合 OpenMP 做并行多项式乘法才算对得起“引擎”两个字。3.2 Python 与 C 引擎交互的三种主流方式这一层是很多项目的隐形瓶颈我见过太多团队把实验性代码跑通后卡在 Python 和 C 的通信上。三种方式按工程复杂度排列第一种是子进程 序列化。Python 把输入明文、模型参数、操作指令序列化成一个文件或字节流用 subprocess 调起 C 可执行程序C 处理完再把结果密文或解密明文写回。这种方式解耦干净、调试直观但每次调用都有进程启动和序列化开销适合离线推理和批处理。我自己的最小引擎原型就是这种最快跑起来不用纠结什么编译链接问题。第二种是 pybind11 做 C 扩展。把 C 引擎类绑定成 Python 模块直接在 Python 进程内调用密文运算。这种方式省掉了进程间通信性能最好但工程复杂度也最高需要处理 Python 对象和 C 对象的生命周期还要保证异常能顺序穿过两边边界。如果是产品化引擎我强烈推荐这种方式但它不适合“先验证想法”的阶段。第三种是服务化。把 C 引擎封装成一个独立的常驻服务通过共享内存、gRPC 或 ZeroMQ 和 Python 通信。最适合部署到多台机器或者要做并发推理的场景。缺点是引入了一个中间层排查问题时要多一层的链路追踪。如果只是单机研究没必要上来就这么重。3.3 数据交换格式与类型安全不管用哪种交互方式Python 和 C 之间交换数据时最容易踩的坑是“默默的类型不一致”。举例来说Python 侧送过去的是一个 float64 的 numpy 数组到了 C 侧解析时如果当成 float32 读数值不会立刻错乱但精度会逐步劣化最后解密结果偏得莫名其妙。所以我的习惯是统一用字节流交换并且第一个字节是版本号第二个字节是类型标记后面再跟长度和内容。序列化密文时同理。现在主流的 FHE 库都提供了 serialize/load 接口你要做的是把它们的输出统一封装成引擎内部的 MessagePack 或者自定义结构。留给未来一个非常实用的建议打印日志时把密文的维度、层级还有 scale 都带上。这两个参数能解释绝大多数“解密结果不对”的问题但日志里往往根本没人打印它们。4. 搭建一个最小可运行的 FHE 推理引擎4.1 环境准备与参数选择要跑通一套最小引擎我建议先用 OpenFHE 或 Microsoft SEAL 这类开源库它们都实现了 RNS-CKKS。为了方便演示这里以 CKKS 方案为例。先看最小环境配置一台普通 Linux 机器编译器支持 C17 即可C11 的语义兼容代码风格我下面的示例中会尽量保持但底层库要求新标准也没关系核心设计不受影响Python 3.8只需要 numpy 和 pybind11。参数选择上我建议第一次跑实验不要追求大模型。多项式模数 N4096logN12、scale_bits40、乘法深度 5 层左右这个组合足够跑一个 16 维输入、10 维输出的两层全连接网络而且单次推理时间能控制在几十秒内不至于等太久。等骨架通了再放大到 N8192 或 16384那时模型宽度和深度才能真正拉起来。4.2 用 CKKS 实现一个两层 MLP 的前向推理下面这个最小示例展示的是核心骨架Python 做明文组织C 做密文执行。代码里刻意省略了部分模板细节重点体现数据流的分工。# python 侧明文编排调用 C 引擎 import numpy as np import my_fhe_engine # 假设 pybind11 绑定后的模块 # 1. 明文预处理 x np.array([0.5, -0.3, 0.2, 0.8], dtypenp.float64) W1 np.random.randn(4, 4).astype(np.float64) # 输入层权重 W2 np.random.randn(4, 2).astype(np.float64) # 输出层权重 # 2. 用明文干跑一遍得到基准结果后续用来对比密文推理 h np.maximum(x.dot(W1), 0) y_ref h.dot(W2) # 3. 调用底层引擎输入明文、权重拿到解密后的结果 engine my_fhe_engine.Engine(logN12, scale_bits40) y_fhe engine.run_mlp_2layers(x, [W1, W2]) print(reference:, y_ref) print(fhe :, y_fhe) print(error :, np.max(np.abs(y_ref - y_fhe)))// cpp 侧核心执行逻辑纯密文运算 // 伪代码水平实际请参考 OpenFHE 或 SEAL 的 API int run_mlp_2layers(const std::vectordouble x, const std::vectorMatrixXd weights) { // 1. 编码加密 Plaintext x_pt; encoder.encode(x, scale, x_pt); Ciphertext x_ct; encryptor.encrypt(x_pt, x_ct); // 2. 第一层密文乘明文 多项式激活 Ciphertext layer1 multiply_plain(x_ct, weights[0]); rescale(layer1); // 消耗一个 level layer1 polynomial_activation(layer1); // 近似多项式 // 3. 第二层密文乘明文 Ciphertext out multiply_plain(layer1, weights[1]); rescale(out); // 4. 解密解码通过绑定返回给 Python Plaintext out_pt; decryptor.decrypt(out, out_pt); std::vectordouble result; encoder.decode(out_pt, result); return result; }这个例子还没有实现旋转和矩阵乘法的对角编排只是最直接的“密文乘明文”线性组合但它足以验证一条核心数据流Python 编好输入和权重C 完成编码、加密、密文乘、激活、解密最后把结果送回来。你只需要跑通这一步后面要加旋转、加更深网络、加多线程都有了可以生长的骨架。4.3 实测性能观察与调优切口按上面的参数跑两层网络我的实测结果是N4096、两层 4x4 矩阵乘单次推理大约 300 到 600 毫秒。如果只算纯多项式乘法单次密文乘大约 20 到 50 毫秒。大部分时间其实消耗在编码/解码和 JSON 序列化如果用子进程而不是真正的大数运算。这也是为什么我强调引擎架构里 IO 模块和编解码模块的优化优先级很高。如果你想提速第一个优化点是把权重明文预编码。训练好的权重如果在推理时反复编码会产生大量不必要的开销在引擎初始化阶段就把所有模型权重编码成明文多项式缓存起来推理时直接拿缓存好的明文对象做乘能省掉大约 15% 的耗时。第二个优化点是开启 OpenMP。OpenFHE、SEAL 底层都支持 OpenMP在编译选项里打开-fopenmp多核机器上多项式乘法会有肉眼可见的加速。第三个优化点是减少重缩放次数。有些线性层连续两次乘法之间可以合并成一次放大从而少做一次 rescale但前提是你对 scale 的变化有精确控制否则不建议新手这样干。5. 常见问题与排查技巧实录5.1 问题速查表现象最可能原因处理方案解密结果全是巨大随机数scale 维护出错解密时除以了错误的 scale打印各级密文的 scale检查是否经过非预期 rescale第一层正确第二层开始乱码乘法深度预算不够噪声在最后崩溃提高 logN 或增加链层级减少每层乘法次数运行时报“invalid modulus chain”序列化密文时层级不匹配确认发送方和接收方的参数一致密文要传输完整链信息旋转结果错位分量跑到想不到的位置旋转步数不对或旋转密钥缺失确认旋转方向、步数针对目标步数提前生成 rotation key性能比预期慢一个数量级没有启用多线程或者编码频繁执行开启 OpenMP预编码权重为明文缓存Python 传给 C 的数组维度对不上numpy 内存布局是 C 顺序还是 F 顺序没控制显式设置np.ascontiguousarray并传 shape 信息5.2 三个“一票否决”级别的坑先谈一个让人印象深刻的坑没有约束输入范围。我早期在跑实验时直接把未归一化的原始特征丢进制编码器结果解出来的 logits 时好时坏误差时而 1e-2 时而 1e2。后来才发现CKKS 的 scale 精度是全局的如果某个输入分量是几百而某个模型权重又恰好在零点几的量级那么浮点编码后有效精度就被大数吃掉了。解决办法就是在 Python 侧先做严格归一化这一点再怎么强调都不为过。第二个坑是过度自信的“明文复算”。很多人在用引擎前会先用 numpy 把整个模型算一遍看看结果但只看最终结果不足以发现中间步骤的 scale 漂移。我后来改成在 C 执行器里加一个 debug 开关在每层计算后强制解密、转回明文、和明文对应的中间结果逐位对比。这样能定位到具体是哪一层的哪一步产生了不可逆误差。第三个坑是把密文当 numpy 数组在用。有人图省事把解密后的结果再加密起来做下一步运算看似没问题实际上这会让噪声预算完全失控。密文只能从一次加密开始一直做下去中间不能“解密再加密”回到密态管线除非你在做私钥重加密或密钥切换的特例。任何让密文“绕回”明文再加密的路径都是架构设计上需要避免的反模式。5.3 调试利器明文干跑与分步解密最后分享一个我自己一直在用的调试方法姑且叫“三层对比”第一层是 Python 侧纯明文推理结果用于给最终精度设上限第二层是 C 引擎里关了噪声/加密直接用明文多项式走完全部逻辑检查的是编解码和矩阵编排的正确性第三层才是开启完整加密的真正密态推理。这三层结果应该逐步接近如果哪一步开始出现剧烈偏差就说明问题出在那一步的引擎环节。具体实现里第二层“明文干跑”甚至不用真的不改动代码只要把引擎内部的加密和解密函数替换成恒等函数就行。很多库都允许用透明密文明文多项式直接做计算这让我们可以在不改变数据流的前提下验证核心逻辑。我建议每个引擎都保留这个开关因为它不止是调试工具还是做模型精度分析时的必备手段——很多情况需要分开判断“是模型近似误差导致的精度下降”还是“是加密噪声导致的精度下降”。结尾我在实际搭这套引擎时最大的感受是FHE 推理真正难的不是密码学而是工程。密码学方案本身有成熟的库和文档但怎么把模型、数据、参数、密钥和性能串成一条可维护的流水线这几乎完全是软件工程问题。你可以先把我上面那个最小的两层 MLP 跑通然后反复去做几件事观察噪声预算打印、对比明文干跑、记录每一层的 scale 和 level。这些数据会推动你逐渐理解 FHE 参数选择的玄机而不是停留在调包侠的水平。最后再分享一个小技巧刻意把引擎参数器设计成“输入模型结构描述就自动输出参数”的函数不要手写死 logN 和乘法深度。因为在迭代模型时一旦层数变深或者输入变宽你会希望引擎自动告诉你“方案要求 N 至少 8192 才能支撑这个深度”而不是你肉眼盯着参数表一个个试错。这个参数器花不了多少代码但对后续所有实验都是一种解放。