读者收益与适用场景
本文适合正在评估同态加密推理成本的工程师或研究者。阅读本文后，你可以：
- 获得一份可复现的性能账本，了解一跳（层内前向 + 自举）的真实耗时构成。
- 明确真正的瓶颈在域变换与密钥切换，而不是多项式乘法。
- 获取精度、复现性、数据一致性等辅助信息，帮助判断是否继续优化。
观测口径
所有数字均来自同一实验环境，且绑定线程数。跨轮次、跨平台的绝对耗时不可比。
| 项 | 值 / 说明 |
|---|---|
| 平台 | AMD Ryzen 7 9800X3D（8 核 16 线程） |
| 线程数 | T23_NT |
| 编译参数 | gcc -O2 -fopenmp -DCKKS_N=2048 |
| 链长 | lay 编译期 112；boot 编译期 2100 |
| 比对方式 | 同轮交错 A/B；不使用跨轮次的绝对耗时 |
一跳的账单
| 阶段 | 耗时 | 判据 | 内存 |
|---|---|---|---|
| lay0 | 1920 s | RESULT=PASS | 工作集 ≈1.0 GB |
| boot0 | 4285 s | BOOT=PASS | 建议 ≥8 GB |
| 合计 | ≈6205 s（约 1.8 h） | — | — |
自举比层内前向贵一倍以上：一跳约 1.8 小时中，约 1.2 小时花在 boot 上。
自举的钱花在哪
boot0 的分段耗时（对应七段流水线）：
| 段 | 耗时 | 占自举比例 |
|---|---|---|
| coeff_to_slot | 1688 s | ~39% |
| slot_to_coeff | 1716 s | ~40% |
| sin_fold | ~850 s | ~20% |
| 其余 | 余下 | 剩余零头 |
| total | 4285.03 s | 100% |
两段域变换合计约 3400 s，占自举耗时约 80%。
瓶颈不在计算
最初的优化直觉是优化最热的内核（NTT / 多项式乘法），但出现次数最多 ≠ 占用时间最多。真正的成本来自：
- 大量 Galois 旋转
- 每次旋转都要做 key-switch
- key-switch 消耗的密钥体积为 nprimes × n × 64 bit 量级，链长 2100 时已大到缓存装不下
因此瓶颈很可能在内存带宽，而非算力。⚠️ 此为推断，未经过微架构 profiling 证实。
精度账本
| 对象 | 结果 | max|err| |
|---|---|---|
| u0（lay0，np=16） | PASS 8/8 | 1.2712e-03 |
| u0r112（自举刷新后） | PASS 8/8 | 1.2706e-03 |
| u26 / u26r112（链尾） | PASS 8/8 | 4.4707e-03 ~ 2.2993e-02 |
| u27（链尾） | ⚠️ 6/8 | t1h1=3.8216e-02、t3h1=7.9687e-02（超默认容差 3e-2） |
三个要点：
- 自举几乎不改变数值：1.2712e-03 → 1.2706e-03。自举是"加油"，不是"纠错"。
- 误差随深度增长：从层 0 的 1.27e-03 到链尾的 2.3e-02，涨了约一个数量级。
- 链尾有超阈项：u27 八项中两项越过 3e-2，照实记账，不调容差。
复现与数据
位级复现账
- u0 × 8 vs 归档：identical 8 / diff 0
- u0r112 × 8 vs 归档：identical 8 / diff 0
- lay0.out 日志：213 / 213 行，差异 4 处全是耗时行
- boot0.out 日志：19 / 19 行，差异 1 处（profile 总耗时）
数据账
- 自助生成权重 vs 分发物：各 9/9 逐字节相同
- silu0..25.bin（26 个）：26/26 逐字节相同
- 归档 manifest 自校验：主包 104/104、链尾 45/45、工具包 6/6
约 7 GB 数据包不随仓库分发，但可用同一模型重新生成，逐字节相同。
安全边界
本文参数为机制验证级（n=2048、112 素数内层链、2100 素数自举链），远低于 128-bit 安全水平，不得用于保护真实数据。本文主张的是本实现在特定机器上的工程量账本，不主张安全强度、性能优越性或与任何其他方案的对比。
未解问题
- 域变换为何如此昂贵，缺乏微架构归因（缓存命中、带宽、指令数），这是当前收益最大的分析方向。
- 没有"最小可用链长"的扫描（boot 编到 2100、实际用多少、能否压到 1500 未测）。
- 精度预算没有闭环（从 28 层反推每层可用误差的推导缺失）。
- 单跳耗时里"内存带宽"的占比未测。
参考来源
- cnblogs.com：本文实测数据的主要出处。https://www.cnblogs.com/haliuhome/p/23178401
- wavect.io：CKKS 方案适用场景、FHE 性能提升背景。https://wavect.io/blog/fully-homomorphic-encryption-practical-2026/
- dualitytech.com：FHE 性能提升 1,000x–10,000x 的驱动因素。https://dualitytech.com/blog/homomorphic-encryption-performance-2026/
下一步：若需进一步分析，建议优先对域变换段进行微架构 profiling（缓存命中、带宽、指令数），以验证瓶颈是否为内存带宽——这是当前未解问题中收益最大的一项。