4.2 硬件加速

4.2 硬件加速

本节摘要：SOURCE 4.2：Kyber/Dilithium 的 NTT、矩阵运算可在 FPGA/ASIC 上加速；对比软件实现与硬件在 IoT、数据中心 TLS 卸载上的 ROI。

你能学到什么

1. 说明 NTT 在格运算中的角色
2. 对比 FPGA 原型与 ASIC 量产路径
3. 判断何时值得硬件卸载

一、加速点（SOURCE 4.2）

二、选型对照

⚠️ 常见坑：FPGA 方案未更新参数集——NIST 标准变更导致硅片作废。

💡 关键直觉：多数企业第一阶段软件 AVX2 足够；硬件是 QPS 瓶颈后手。

本章回顾

• NTT/矩阵是格方案加速核心
• FPGA 验证 → ASIC 量产路径
• IoT 关注密钥与能量
• 与软件 liboqs 保持算法版本一致

深入讨论：NTT 加速格运算的原理与取舍

Kyber 与 Dilithium 的运算核心是多项式乘法，而数论变换（NTT）把多项式乘法从逐系数卷积的 O(n²) 降到 O(n log n)，这既是软件优化（AVX2、BMI2 指令集）的重点，也是硬件加速最值得投入的部分。FPGA 上用并行乘加单元与蝶形运算结构实现 NTT，可以在单个时钟周期内完成多个蝶形计算，从而把一次 Kyber 封装的延迟压到微秒级。但 NTT 不是免费的：它要求模数支持特定的根，算法实现必须严格遵循参数定义，任何「简化」都可能破坏正确性。

硬件方案的工程节奏通常是三段式：先用 FPGA 验证算法与参数集，跑通与软件实现一致的 KAT 向量；确认正确性后再评估吞吐与功耗，决定是否值得流片为 ASIC；量产后再作为 TLS 卸载卡、IPsec 加速器或 IoT 安全芯片集成进产品。这条路径最大的风险点是「参数集冻结」——如果 NIST 或 IETF 调整参数或码点，已经流片的芯片无法通过软件更新完全补救，因此硬件团队必须与标准时间线对齐。

# 硬件加速可行性评估清单
场景                优先手段              硬件化触发条件
云 TLS 网关          软件 AVX2/BMI2 优化    QPS 触顶且 CPU 占用高
CDN 边缘            软件 + 卸载卡试点      延迟预算 < 1 ms
IoT 设备            轻量软件实现          长期批量出货、功耗敏感
量子安全芯片         ASIC 集成            产品生命周期长、需合规背书
FPGA 原型            RTL 验证 NTT 核心     参数冻结确认后
​

值得提醒的是，对大多数企业来说，第一阶段的软件优化通常就够用：现代 CPU 上的 AVX2 实现已经能把 Kyber-768 封装压到几十微秒，远超多数业务对握手的实时性要求。硬件化的收益主要在超高并发或极低功耗场景，把资源投入到「先测软件基准、再评估卸载」的顺序上，可以避免过早的硅片投入。

工程实践扩展：硬件方案的验证与长期维护

硬件化一旦启动，就进入了一条不易回退的路径，因此验证阶段要格外谨慎。FPGA 原型阶段要做的第一件事不是比吞吐，而是与软件实现的 KAT 向量对齐——任何输出不一致都意味着 RTL 实现了错误的算法或错误的参数集，此时性能数字毫无意义。第二步是测功耗与面积，评估在目标工艺下是否能达到量产预期，这一步决定了产品形态（独立芯片、片上加速核还是边缘卡）。

长期维护是硬件方案最容易漏掉的成本项。PQC 参数集可能随标准修订而调整，已流片芯片若无法通过固件更新适配，就只能退役，这意味着产品发布时就要规划「算法升级槽位」：预留给未来新算法的算力余量、可更新的 NIST 功能接口、以及与软件实现的共存策略。不预留升级路径的硬件产品，本质上是在把今天的参数集冻结成明天的债。

# 硬件化生命周期检查点
1. RTL 与软件 KAT 完全一致后再进入性能优化
2. 测功耗与面积，对比软件实现的性价比拐点
3. 确认参数集冻结状态，与 NIST/IETF 时间线对齐
4. 规划算法升级槽位：预留算力与可更新接口
5. 设计软件回退路径：芯片失效时仍可软件降级
6. 明确量产与验证的分工与版本记录
​

把生命周期检查点纳入项目计划，硬件加速就从「一次性流片」变成「可演进的密码平台」。即便未来算法切换，芯片留下的算力与接口仍可服务新参数集，这正是「加速器」与「密码引擎」两种产品定位的本质区别。