TFHE-rs v1.1：细粒度的 GPU 控制和更多运算符
- ZamaFHE
- 发布于 2025-04-11 11:36
- 阅读 18
Zama 发布了 TFHE-rs v1.1 版本，GPU 后端升级，采用与 CPU 相同的默认加密参数，降低了计算错误的概率。多 GPU 支持也得到了显著改善，开发者可以选择要使用的 GPU，在 8×H100 GPU 上每秒可进行接近 500 次加密的 64 位加法。CPU 方面，此版本通过支持更多标量情况扩展了运算符集，从而使同态计算更加通用和高效。
/
TFHE-rs v1.1: 精细化的 GPU 控制和更多算子
2025年4月10日
-
Jean-Baptiste Orfila, Arthur Meyre, Agnes Leroy
本月，Zama 发布了 TFHE-rs v1.1，为 GPU 和 CPU 后端带来了多项重大改进和新功能。
在 GPU 方面，后端已升级为采用与 CPU 相同的默认加密参数，从而将计算错误的可能性降低到 2⁻¹²⁸ 以下——所有这些都对性能影响极小。多 GPU 支持也得到了显著改善：用户现在可以显式选择在哪个 GPU 上运行，从而在 8×H100 GPU 上实现接近每秒 500 次加密 64 位加法。
在 CPU 方面，此版本通过支持更多标量情况来扩展算子集，从而使同态计算更加通用和高效。
在这篇博文中，我们将深入探讨 TFHE-rs v1.1 中的新功能。
更好的多 GPU 吞吐量
在 v1.1 之前，TFHE-rs 的高级 API 使用硬编码策略自动在所有可用 GPU 上调度工作负载，以进行任何加密操作。虽然这对于非常大的整数精度（>128 位）以及大量加载 GPU 的操作（例如乘法）有效，但对于较小的操作（通常是 64 位加密加法或比较）来说并不理想。
从 v1.1 开始，开发人员可以选择对每个操作使用哪个 GPU，从而优化多 GPU 设置的性能。
这是一个快速示例，展示了如何在每个 GPU 上并行执行一百个 64 位加密加法，其中每个加法都在单个 GPU 上计算：
use tfhe::{ConfigBuilder, set_server_key, ClientKey, CompressedServerKey, FheUint64, GpuIndex};
use tfhe::prelude::*;
use rayon::prelude::*;
use tfhe::core_crypto::gpu::get_number_of_gpus;
use rand::{thread_rng, Rng};
fn main() {
let config = ConfigBuilder::default().build();
let client_key = ClientKey::generate(config);
let compressed_server_key = CompressedServerKey::new(&client_key);
let num_gpus = get_number_of_gpus();
let sks_vec = (0..num_gpus)
.map(|i| compressed_server_key.decompress_to_specific_gpu(GpuIndex::new(i)))
.collect::>();
let batch_size = num_gpus * 100;
let mut rng = thread_rng();
let left_inputs = (0..batch_size)
.map(|_| FheUint64::encrypt(rng.gen::(), &client_key))
.collect::>();
let right_inputs = (0..batch_size)
.map(|_| FheUint64::encrypt(rng.gen::(), &client_key))
.collect::>();
let chunk_size = (batch_size / num_gpus) as usize;
left_inputs
.par_chunks(chunk_size)
.zip(
right_inputs
.par_chunks(chunk_size)
)
.enumerate()
.for_each(
|(i, (left_inputs_on_gpu_i, right_inputs_on_gpu_i))| {
left_inputs_on_gpu_i
.par_iter()
.zip(right_inputs_on_gpu_i.par_iter())
.for_each(|(left_input, right_input)| {
set_server_key(sks_vec[i].clone());
left_input + right_input;
});
},
);
}
这里发生了什么？与使用 TFHE-rs 进行的常规 GPU 计算不同的是，服务器密钥的定义方式：
let sks_vec = (0..num_gpus)
.map(|i| compressed_server_key.decompress_to_specific_gpu(GpuIndex::new(i)))
.collect::>();在这里，创建了一个服务器密钥向量，每个密钥都在特定的 GPU 上。
然后，不是像通常那样在输入上调用 par_iter()，而是将输入分块以分布到所有 GPU 上：
left_inputs
.par_chunks(chunk_size)
.zip(
right_inputs
.par_chunks(chunk_size)
)
.enumerate()
.for_each(
|(i, (left_inputs_on_gpu_i, right_inputs_on_gpu_i))| {
left_inputs_on_gpu_i
.par_iter()
.zip(right_inputs_on_gpu_i.par_iter())
.for_each(|(left_input, right_input)| {
set_server_key(sks_vec[i].clone());
left_input + right_input;
});
},
);通过使用 set_server_key(sks_vec[i].clone()) 设置与每个块关联的 GPU 对应的服务器密钥，加法将在所有 GPU 上独立计算。请注意，当执行 sks_vec[i].clone() 时，服务器密钥的指针会复制到特定线程，而不是服务器密钥本身的内容，因此不会产生额外的开销。你可以按照我们的专用教程进一步最大化多 GPU 吞吐量。
通过设置此逻辑，TFHE-rs 现在可以在 8xH100 GPU 上实现接近每秒 500 次 64 位加密整数的加法。
CPU 后端上的新算子
TFHE-rs v1.1 为 CPU 后端带来了一些新增功能和改进：
-
对 select 的标量支持：以前，select 操作仅适用于加密值。在 v1.1 中，你现在可以使用标量（明文）值作为可选择的操作数。对于 64 位输入，此操作大约在 20 毫秒内执行。
-
改进的减法：减法现在支持左侧的标量，从而可以进行像 scalar - encrypted 这样的表达式。对于 64 位操作数，此操作大约需要 79 毫秒。
-
新的点积算子：v1.1 引入了 FheBool 值的向量与任何支持的标量类型之间的点积运算。在包含 1,024 个元素的向量上，执行时间约为 2 秒。
所有性能基准均在 AWS hpc7a.96xlarge 实例上测量。
更智能的密钥生成
为了更好地支持内存受限环境中的操作，v1.1 还引入了“分块”引导密钥生成。此功能允许以较小的块生成引导密钥，这些块稍后可以在用于加密计算的更高容量的服务器上组装成完整密钥。
TFHE-rs 的下一个版本将继续提高性能并引入新功能。敬请关注！
额外链接
- 给 Zama 的 TFHE-rs GitHub 存储库 加星，以支持我们的工作。
- 查看 Zama 的 TFHE-rs 文档。
- 在我们的社区频道上获得支持。
- 参与 Zama Bounty Program 以获得现金奖励。
阅读更多相关帖子
未找到任何项目。
库
Concrete ↗ Concrete ML ↗ FHEVM ↗ TFHE-rs ↗
产品与服务
开发人员
博客 文档 ↗ GITHUB ↗ FHE 资源 ↗ 研究论文 ↗ 赏金计划 ↗ FHE 状态操作系统
公司
联系方式
与专家交谈 联系我们 X Discord Telegram 所有社区频道
在电子时代，隐私对于一个开放的社会是必要的。隐私不是秘密。私事是不想让全世界知道的事，而秘密是不想让任何人知道的事。隐私是有选择地向世界展示自己的力量。如果双方有某种交易，那么双方都会记住他们的互动。每一方都可以谈论他们自己对这件事的记忆；谁能阻止它呢？可以制定法律来反对它，但言论自由，甚至比隐私更重要，对一个开放的社会来说是根本的；我们不寻求限制任何言论。如果许多方在同一个论坛一起发言，每个人都可以向所有其他人发言，并将关于个人和其他方的知识汇总在一起。电子通信的力量使这种群体言论成为可能，它不会仅仅因为我们可能想要它消失而消失。既然我们渴望隐私，我们必须确保交易的每一方只知道直接必要的信息。由于任何信息都可以被谈论，我们必须确保我们尽可能少地透露信息。在大多数情况下，个人身份并不重要。当我在商店购买杂志并将现金交给店员时，没有必要知道我是谁。当我要求我的电子邮件提供商发送和接收消息时，我的提供商不需要知道我在和谁说话，我在说什么，或者别人在对我说什么；我的提供商只需要知道如何将消息送到那里，以及我欠他们多少费用。当我的身份通过交易的底层机制暴露出来时，我就没有隐私了。我不能在这里有选择地展示自己；我必须始终展示自己。因此，开放社会中的隐私需要匿名交易系统。到目前为止，现金一直是主要的此类系统。匿名交易系统不是秘密交易系统。匿名系统使个人能够在需要时以及仅在需要时展示自己的身份；这是隐私的本质。开放社会中的隐私也需要密码学。如果我说了一些话，我希望只有我打算让其听到的人才能听到。如果我的言论的内容对世界开放，我就没有隐私。加密是表明对隐私的渴望，而使用弱密码加密是表明对隐私的渴望并不强烈。此外，当默认设置为匿名时，为了有保障地泄露自己的身份，需要密码签名。我们不能期望政府、公司或其他大型、没有面孔的组织出于他们的恩惠而给予我们隐私。谈论我们对他们有利，我们应该期望他们会谈论。试图阻止他们的言论是与信息的现实作斗争。信息不仅仅是想自由，它渴望自由。信息扩展到填满可用的存储空间。信息是谣言的更年轻、更强大的表弟；信息脚步更快，眼睛更多，知道更多，理解更少。如果我们希望拥有任何隐私，我们必须捍卫自己的隐私。我们必须走到一起，创建允许进行匿名交易的系统。几个世纪以来，人们一直在用窃窃私语、黑暗、信封、紧闭的门、秘密握手和信使来捍卫自己的隐私。过去的技术不允许强大的隐私，但电子技术可以。我们这些密码朋克致力于构建匿名系统。我们正在用密码学、匿名邮件转发系统、数字签名和电子货币来捍卫我们的隐私。密码朋克编写代码。我们知道必须有人编写软件来捍卫隐私，而且由于除非我们所有人都这样做，否则我们无法获得隐私，所以我们将编写它。我们发布我们的代码，以便我们的密码朋克伙伴可以练习和使用它。我们的代码可供所有人免费使用，在全球范围内。如果你不赞成我们编写的软件，我们不太关心。我们知道软件无法被销毁，而且广泛分散的系统无法被关闭。密码朋克谴责对密码学的法规，因为加密从根本上来说是一种私人行为。事实上，加密行为将信息从公共领域移除。即使是反对密码学的法律也只能达到一个国家的边界和暴力的手臂。密码学将不可避免地传播到整个地球，随之而来的是它使之成为可能的匿名交易系统。为了使隐私得到广泛传播，它必须成为社会契约的一部分。人们必须走到一起，为了共同利益而部署这些系统。隐私的范围仅限于一个人在社会中的同伴的合作。我们，密码朋克们，征求你的问题和你的疑虑，并希望我们能够与你互动，以免我们欺骗自己。但是，我们不会因为某些人可能不同意我们的目标而改变我们的路线。密码朋克们正在积极致力于使网络对隐私更安全。让我们一起快速前进。前进。埃里克·休斯著。1993 年 3 月 9 日。
- 原文链接： zama.ai/post/tfhe-rs-v1-...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
