这次我们来看的是一条偏“底层技术路线”的消息。谷歌在近期对外沟通中反复强调一个方向通过同态加密让 AI 在加密数据上直接做计算把“私有 AI”从学术论文带向工程可用。翻译成白话就是数据不用解密AI 也能帮忙分析。放到云端推理、隐私合规、金融风控这类场景里这个能力如果真能落地会直接改变“数据必须交给别人才能用 AI”的现状。这里专门拆开讲清楚三件事同态加密到底是什么Google 为什么说它能让私有 AI 变得实际可用以及这件事对普通开发者和架构师意味着什么。文章会包含密码方案原理、工程链路拆解、接口和批量任务设计思路、性能观察点和落地建议。不会去复述发布会文案重点说清楚能不能用、怎么用、卡点在哪、什么时候该等一等。如果你关心隐私计算、加密推理、机密 AI或者你正在做数据合规要求很高的 AI 服务这篇可以直接当作背景参考。1. 核心能力速览同态加密Homomorphic EncryptionHE是一种可以在密文上直接执行运算的加密技术。普通加密方案里你要先解密再计算最后再加密同态加密则允许你在不解密的前提下对密文做加法和乘法最终解密得到的结果等于直接对原文做同样运算的结果。能力项说明技术类型隐私计算 / 加密计算 / AI 推理隐私保护核心价值数据在加密状态下参与 AI 推理服务方只能看到密文和最终结果主要密码方案CKKS浮点近似、BGV / BFV整数精确等典型使用边界适合对结构化特征、数值向量做模型推理计算计算开销远高于明文推理实际部署需做 SIMD 打包、噪声预算控制、功能裁剪部署方式通常以库或推理服务形式集成常见有 OpenFHE、Microsoft SEAL 等开源库API 能力由具体产品或项目决定不在通用开源库的默认范围内批量任务可以通过编码打包实现多输入并行但不是传统意义上的并发任务队列适合场景跨机构数据联合风控、医疗特征分析、保密性较高的云端推理等不适合场景复杂大模型明文推理、交互式即时对话、无授权的数据处理谷歌的“让私有 AI 更实用”并不是指发明了一种全新的加密算法而是把模型能不能在密文上跑、代价能不能降到工程可接受范围、能不能在真实产品服务中集成这些问题一点点打通。下面先把这条技术路线拆开。2. 为什么偏偏是同态加密私有 AI 的技术选择把“私有 AI”落地通常有三类技术路线。第一类叫可信执行环境TEE。通过 CPU 或 GPU 的特殊安全区域让数据在硬件隔离环境中被处理。代表形态是机密虚拟机、机密容器。优点是对现有 AI 框架改动小缺点是信任链依赖芯片厂商需要接受硬件隔离边界以内的信任模型。第二类叫联邦学习。数据留在本地只交换梯度或模型参数。优点是不直接出域缺点是训练链路复杂推理环节的隐私保护仍然需要配合其他方案。第三类就是同态加密。它提供的是密码学层面的不可信假设就算云端服务完全不可信密文也不会泄露有效信息。这是隐私性最强、也最容易被忽略的一点——在 TEE 里云端只是“看不到”数据在同态加密里云端是“即使想看也看不懂”。对 AI 推理而言同态加密真正适合的形态是加密推理Encrypted Inference。也就是说模型一方可以拥有明文模型参数数据一方把加密后的特征向量发过来模型服务商在密文上完成前向计算返回加密结果只有数据方自己能解密。整个过程服务商只看到密文模型参数也不会暴露给数据方。这个模式适用于“API 式决策服务”或“数据跨机构联合分析”。Google 想解决的现实问题非常直接AI 大模型和云服务的商业模式建立在数据流通的基础上但企业客户的合规、隐私、竞争顾虑让数据很难真正流通。如果加密数据也能推理那么银行之间、医院之间、机构之间就不需要“先信任、再共享”而是“先用密文算、再按需解密”。3. 谷歌的技术路线从机密计算到加密推理目前谷歌对外展示的隐私 AI 体系并不是只靠同态加密单打独斗而是把它放到一整条“隐私增强技术”链路里。更实际的产品形态是分层的第一层是机密计算基础设施。在这个层里虚拟机、容器运行在硬件可信执行环境中内存中的数据默认加密系统管理员、云平台方都无法直接读取。这一层适合跑现有的 AI 工作流部署改动最小。第二层是**机密空间Confidential Space**这类协调方案。它保证参与计算的各方在代码运行前先完成远程证明确认运行环境没有被篡改再把数据拿进来。适用于多方数据联合分析。第三层才是同态加密与密文推理。当业务要求“整个参与过程中除了计算方指定的一方之外包括基础设施在内的任何人都不能接触到有效数据”时就需要用密码学补齐最后一环。如果用一个简单的类比来理解谷歌想推进的阶段可以这样说普通云计算把数据交给别人别人替你算。机密计算数据放在保险柜里别人在保险柜里替你算保险柜由硬件厂商保证锁不会被打开。同态加密推理数据是一堆数独题别人不看到答案也能替你填完最后你自己解开。谷歌在这些年做的事情本质上是给“保险柜模式”增加了一层“密码学保险丝”让客户可以选择更强等级的隐私保护。但必须注意同态加密并不是万能的它仍然有非常明显的计算边界这一点在下面的原理和部署部分会具体展开。4. 加密推理的原理与工程链路4.1 从数学到代码一条完整的加密推理链路要实现一个基于同态加密的 AI 推理服务要处理的不是“如何调用 SDK”而是整个计算图的重新表达。假设你有一个训练好的逻辑回归或者浅层神经网络模型希望让客户端发送加密特征、服务端在密文上推理最终客户端能得到加密的预测结果。整条链路可以拆成五步。第一步是特征标准化。原始数值必须被量化到一个可控范围。同态加密的密文带有“噪声预算”执行的乘法次数越多噪声增长越大。浮点特征如果分布范围过大会让明文数值在保理性上直接出问题。第二步是模型裁剪。标准神经网络里最常用的那些算子比如 ReLU、MaxPool、Softmax在密文上计算代价极高。ReLU 是非线性分段函数通常要用低阶多项式去逼近MaxPool 则需要比较密文大小也必须改写成可计算的多项式形式。一个能上明文 GPU 的模型往往不能直接上密文推理必须做算子级重构。第三步是编码与打包。同态加密的单次密文运算实际上是一次“SIMD 式”的批量运算。一个密文可以被拆成多个“槽位”把多条输入样本的特征向量放进同一条密文的不同槽里就能实现“一条密文同时处理多条记录”的效果。打包设计直接决定实际算力。第四步是推理执行。服务端持有一组模型权重客户端提供加密后的特征向量。服务端执行模型前向计算每层计算完成后立刻做重新线性化和噪声裁剪确保下一位运算仍能正确完成。任务执行完后能分辨回正常密文。第五步是解密与返回。推理结果会以密文形式返回给客户端。由客户端完成解密看到的才是有效的预测结果。若计算结果要给云服务方进行再分析就需要一个“多方参与”的解密协议不能由单一方独立解密。整个过程不能中间出明文要保证除客户端外无人拥有私钥。4.2 同态加密推理的密码学安全边界这里要区分两个术语同态加密和安全多方计算。两者经常放在一起提但侧重点不同。同态加密解决的核心问题是“委托计算”云服务拿到密文后可以执行特定函数但读不到数据。安全多方计算解决的是“多方协作计算”多个参与方各自输入私密数据共同计算某个函数各方只能得到输出不能看到他人输入。如果这个推理服务只是单客户-单服务端模式那么同态加密加一次响应解密就够了。如果是联合风控场景比如三家银行找出共有的高风险客户每一家都不愿意把自己的用户特征泄露给其他银行又希望得到联合计算结果通常就会用“秘密分享 同态加密”的组合方案。这部分的安全边界建议以真实业务需求为导向不建议只在“推理”点上使用。只要还没有进入推理阶段就应该先用底层机制保障数据完整性。5. 环境准备与前置条件同态加密并不是一个开箱即用的“一键服务”而是一个需要做密码学配置、模型适配和性能测试的组件。建议在尝试工程化之前先准备下面的运行环境。检查项建议操作系统Linux 服务器为主Windows 适合开发测试开发语言C 为底层首选Python 适合原型验证加密库OpenFHE、Microsoft SEAL、HElib 等数学基础需要了解多项式环、模运算、噪声预算的含义模型框架先用逻辑回归、线性模型验证再扩展到浅层神经网络数据集使用不含真实身份信息的公开数值数据集做验证性能记录工具记录单条样本的端到端延迟、密文大小、噪声消耗率严格来说这一部分没有“标准出厂包”因为不同项目的参与方数量、隐私粒度、风险模型都不一样。下面给一个偏模板化的项目骨架。# 以基于 CMake 的 C 项目为例用于构建一个实验性加密推理服务 # 实际类库路径和依赖需要按真实版本调整 git clone https://github.com/openfheorg/openfhe-development.git cd openfhe-development mkdir build cd build cmake .. make -j4Python 环境如果想先验证思路可以尝试安装现成的 OpenFHE Python 绑定或者通过包装库加载已有的 C 算子。实验阶段不建议直接自己实现 CRT 分解、密钥切换这些底层逻辑。6. 功能验证与效果评估量化和测试方法在进入功能验证之前需要先建立起一套和明文推理基准对比的实验流程。下面是推荐的基础测试步骤。6.1 明文基准准备先用同一份测试数据集和同一套模型结构在普通环境下完成明文推理记录下每一层的数字输出范围和分布。这个步骤非常重要因为后续使用同态加密的近似激活函数是否能保证输出质量必须有一个原始基准。6.2 同态加密端到端测试测试目的是验证“密文推理结果解密后是否和明文推理结果接近”。输入素材是一份经过标准化和缩放的数值特征向量比如 10 个特征、500 条测试样本。可以采取的步骤是用 CKKS 方案做参数初始化设定安全强度、乘法深度和槽位数。用客户端密钥对测试特征做加密生成密文。服务端加载模型参数在密文上执行前向计算。返回加密预测结果。客户端解密并与明文结果做误差对比。判断成功的标准有两个端到端能正确解密且预测类别一致率满足业务预期。若不一致主要检查量化范围是否合适、激活函数阶数是否过小、噪声预算是否耗尽。下面是伪代码形式实际项目需要按所选库重新实现# 伪代码示例仅用于表达流程不绑定具体 SDK API client HE_Client() server HE_InferenceServer(model_weights) # 客户端随机生成私钥和公钥并分发公钥给服务端 client.generate_keys() server.receive_public_key(client.public_key) # 客户端量化特征并加密 plain_feature quantize(raw_feature) cipher_feature client.encrypt(plain_feature) # 服务端在密文上执行近似模型前向计算 cipher_prediction server.forward(cipher_feature) # 客户端解密 plain_prediction client.decrypt(cipher_prediction)6.3 不同模型结构的测试差异逻辑回归 / 线性模型计算几乎全由乘法组成常用库可较容易实现适合第一轮验证。浅层 MLP主要是矩阵乘法和激活。矩阵乘法用槽位打包可达到不错效果激活多项式逼近会造成一定精度损失。CNN卷积运算可以通过“图像到列”的方式展开但密文尺寸会迅速膨胀性能下降明显。一般只建议对敏感图像特征做一层浅加密。Transformer / 大模型目前整体上跑全密文推理仍然不是一个通用工程选项。更合理做法是分治保护——用 TEE 处理中间阶段用 HE 处理跨机构共享的敏感字段或安全聚合部分。7. 接口 API 与批量任务设计思路同态加密推理在进入实际业务时面临的最大问题不是“能算”而是“怎么让调用方方便地接入”。客户端调用与服务端返回的交互过程天然不是普通方式的“请求 JSON - 得到 JSON”。普通用户调用加密推理服务时必须先完成密钥协商服务端要有远程证明能力同时还要准备处理大体积密文的数据通道。下面是按场景做的接口思路。7.1 核心调用流程建议1. 客户端初始化生成或导入密钥对把公钥发送给服务端 2. 服务端响应校验客户端证书返回可用的推理任务编号和模型版本 3. 客户端构造工具数据把业务字段映射为模型特征做量化、编码、加密 4. 请求发起上传加密后的特征密文 5. 服务端推理通过任务队列获取待执行密文交给具备 HE 计算能力的程序 6. 结果返回服务端将加密预测结果内容返回给客户端 7. 客户端解密离线解密后得到风险分或类别# curl 示例只是外部传输层示意真实请求结构需要按项目接口文档调整 curl -X POST https://your-encrypted-inference.example/api/predict \ -H Authorization: Basic your_api_token \ -H Content-Type: application/octet-stream \ --data-binary encrypted_features.bin在返回结构上如果预测结果只有一条密文可以直接返回二进制如果存在多个分位数、多个模型或多人协作场景则需要考虑再把结果封装成带字段结构的对象。7.2 批量任务的实现方式同态加密里的“批量”和传统 batch 的差别很大。普通 AI 服务里加大 batch 可以提升 GPU 利用率在 HE 推理里如果批大小增加一条密文的槽位装不下就需要做明文分片加密服务端的计算量会线性上升。工程上常见的做法有两种。第一种是槽位打包。尽可能把不同样本放入同一条密文的不同槽。这样一次的矩阵乘成本就能摊给多条样本综合吞吐会上升但这属于并行密文处理不是传统批量队列。第二种是离线异步任务队列。把加密请求放进队列服务端使用多个计算节点处理。该模式的收益来自“计算节点可以做流水线调度”能减少网络等待但不能直接缓解 HE 本身的单条计算延迟。7.3 API 层的合理单位由于 HE 推理返回内容没有可读性不能依赖传统的“响应日志”。建议在接口层内置任务编号机制任何一步前有问题客户端都可以通过任务状态接口确认中间状态。{ job_id: job-2025-0606-0001, model_version: lr-risk-v1.2.0, status: running, progress: encrypted-inference }真实项目中要在客户端把秘钥管理放在最高优先级。如果私钥丢失一批历史密文将不可恢复。这类业务的错误恢复无法靠重放请求做到因为每条请求对应的密钥可能不同。8. 性能观察与资源占用评估要点同态加密的资源占用很难用一个固定数字表述性能与密码参数、打包方式、计算库的实现质量强相关。工程观察主要集中在四个方面。8.1 时间开销不同类型的算子开销差异很大。密文乘法和密钥切换是最耗时的两个环节明文乘法、密文加法相对便宜。矩阵乘法要尽量拆解成密文乘明文的形式因为模型权重由服务端持有它可以保持明文形式不必全部加密。只有特征和中间表示需要保持密文状态。8.2 噪声预算每个密文都带有一个“乘法深度”限制。设计模型时第一件要做的事就是统计从输入到输出有多少层连续乘法。连续的乘法越多需要分配的噪声预算越大密文尺寸和计算时间都会显著增加。每次乘法后做重新线性化可以控制噪声增长但也会拉高计算开销。8.3 参数选择与打包CKKS 参数通常要设定安全强度如 128 bit、多项式模数大小和槽位数。安全强度越高模数越大计算越慢槽位越多单次并行样本数越大内存占用也越大。为了避免过拟合业务需求建议一开始使用较小的向量规模成功跑通后再逐步放大。8.4 显存与内存如果使用 CPU 实现内存占用取决于密文大小和计算队列长度。单条密文的大小可能是原始明文的上百到上千倍。一个能放到明文内存里的特征矩阵打包成 HE 密文后内存可能会从 MB 级别升到 GB 级别。如果依赖 GPU 加速则需要重新实现底层数论变换不能直接复用普通深度学习框架的 CUDA 内核。对网络传输来说每传一个加密特征向量都要考虑二进制密文体的体积和带宽。在网络条件不好的场景中传输时间会比本地计算更早成为瓶颈。9. 常见问题与排查方法问题现象可能原因排查方式解决方案推理结果解密后与明文基准偏差过大特征标准化不足或激活函数近似阶数过低逐层对比明文和密文中间结果减小特征范围提升多项式逼近阶数计算到一半解密失败噪声预算耗尽查看每层重线性化后的噪声余量增加乘法深度参数减少连续乘法次数单次推理耗时过高没有做槽位打包或模型算子没有裁剪逐步统计各算子的耗时调整打包策略用低阶多项式替换非线性算子多条密文乱序返回批量任务中间结果关联错误检查任务编号哈希链条使用任务 ID 贯穿整个请求生命周期客户端服务端密钥错位公钥分发流程不完整检查密钥生成和公钥交换日志增加密钥指纹校验找不到合适的 API 封装底层库不支持以服务形式暴露接口查看 SDK 示例与跨语言绑定用 C 写底层服务通过 socket 或消息队列对接上层同态加密项目最常见的工程事故不是“加密被破解”而是“忘记噪声预算”“忘了量化范围”“把所有算子都一股脑搬过去”。越早上层功能测试越早发现问题成本越低。10. 安全边界与合规使用指南同态加密能为 AI 推理增加安全边界但它不是万能安全壳。以下几点必须单独确认第一模型权重是否也需要保护。上面说的流程中模型权重是明文状态由服务端持有而模型参数本身可能也是被保护的商业秘密。如果要求模型权重也不可见需要引入更复杂的安全多方计算协议。以现在的算力代价来看除非是极简模型否则不建议在常规业务中直接追求“模型权重与输入数据同时加密”的强需求。第二多方场景下解密权限要去中心化。如果一家机构掌握私钥它可以单独解密联合计算结果其他参与方的数据仍然可能被逆推。需要配合门限解密或者引入可信协调者确保每次解密必须达到预设的参与方数量。第三合规底线。凡是涉及个人信息、人脸特征、声音、病历、财务信息的数据使用任何形式的加密处理前都必须确认数据来源正当、授权范围明确。同态加密降低的是数据泄露风险并不能证明数据采集和处理的合法性。项目上线前建议通过隐私合规评审。第四加密机制不替代访问控制。同态加密可以防止云服务方窥探数据但如果一个恶意客户端有权提交查询接口仍然可以通过发大量推理请求来统计推断模型能力。因此接口服务端还需要做访问控制、请求速率限制和异常行为监控。11. 部署评估清单与下一步建议如果你正在考虑在自己的业务中引入同态加密推理可以按下面的步骤走先确定真正需要保护的明文是什么输入特征、模型权重还是最终标签。选择一条最简单的业务问题最好是一个逻辑回归或线性打分模型不要一上来就做 Transformer 全密文推理。准备明文和密文两条推理路径保留逐层中间结果方便定位精度损失。自己构造一批小样本测试观察噪声消耗和推理时间记录完整统计结果。如果延迟过高先优化算子和层融合再考虑加硬件加速卡。不要直接买大量硬件增加并发。只有完成单条推理验证后再接异步队列和 API 层否则会把“密码学问题”和“分布式问题”混在一起极其难排查。上线前做最小隐私影响评估明确密钥生命周期时间越长潜在风险越大。从这条技术路线的结果来看谷歌想表达的不只是“同态加密理论已经成熟”更是“它在工程层已经可以被拆进真实的云服务链路里”。对普通团队来说关键是认识到同态加密的短板。它是隐私最强的选项但它为“强隐私”付出的单样本计算代价也很高。比较现实的落地思路是分层混合使用——低频高敏用同态加密高频高敏用机密计算一般业务用普通云端推理。同态加密不是用来替代当前所有隐私计算方案的而是给那些真正不可信的参与方协作场景补上最后一层密码学保障。建议搞工程的人现在先把数据打包、噪声预算、模型裁剪这三板斧学起来等谷歌或者其他框架把这套推理能力逐步做成标准的云端 API 时你已经知道该怎么接入也知道如何在哪些环节做取舍。