这个系列越来越硬核了。第十二篇精准地打在你长期关注的"系统边界与取舍"主题上——OpenMP 本身是个好东西，但在 FHE 这种小并行区密集的场景下，它的通用抽象层变成了性能税。
---
核心矛盾：OpenMP 的 fork/join 模型不适合细粒度并行
OpenMP 的基本模型是[citation:web:57.4]：
进入并行区 → 唤醒线程 → 分发任务 → 汇合（barrier）
对科学计算里几百毫秒一段的粗粒度并行，这点开销可以忽略。但 FHE 的并行结构是嵌套且细碎的[citation:web:57.4]：
112 个素数 → 每素数一个 NTT
n = 2048 个系数 → 每系数一次模乘
密文分量 × 素数 × 系数，三层循环处处可并行
这些并行区可能只有几微秒的执行时间。每次进入并行区 OpenMP 都要付一次线程池唤醒/汇合的成本，结果是：花大量时间在"叫醒工人"，而不是"干活"[citation:web:57.4]。
---
自研线程池的三条设计决策
持久 worker + "先自旋，再等待"
只创建一次（懒初始化），之后永远复用
等待策略：先自旋一小段 → 没活干再退化到事件等待
纯自旋浪费 CPU 时间片，纯事件等待的线程切换延迟高。先自旋后阻塞两头兼顾——这和你在 Qt 事件循环里做过的优化思路是一样的[citation:web:57.4]。
调用线程自己也干活
发起并行的线程不是"监工"，它自己也分一块活。 常见情况下不需要额外唤醒——本来就醒着的那个线程立刻开始算[citation:web:57.4]。
API 上的两个合约：
vllmtpparfor：调用者拿最后一块（caller takes the last chunk）
vllmtpworker_id：区内 caller 的 id 是 nthreads-1，区外是 -1
第二条尤其重要——让"我是第几号工人"在区内区外语义一致，避免调用点写出两套分支。
静态连续分块 + 绑物理核
FHE 里"每一行的代价基本一致"（每个素数一个 NTT、每个系数一次模乘），所以静态连续分块没有负载不均问题，且分块确定 → 结果确定（这是位级可复现的前提）[citation:web:57.4]。
绑核策略分平台：
x86：跳过 SMT 兄弟核，只绑物理核
RK3588：绑 A76 大核簇
两个平台策略不同，写在同一个池里。
---
API 设计：刻意做成 OpenMP 的镜像
这是最务实的工程决策——不发明新范式，只换实现[citation:web:57.4]：
| OpenMP | 自研池 |
|:-------|:-------|
| #pragma omp parallel for schedule(static) | vllmtpparfor(...) |
| ompgetthreadnum() | vllmtpworkerid() |
| ompgetmaxthreads() | vllmtp_threads() |
| ompgetwtime() | vllmtpwtime() |
每个调用点都是机械替换，语义一一对应，出问题容易二分定位。迁移风险极低。
---
自研的代价（必须说清）
文章很诚实地列出了三条限制[citation:web:57.4]：
| 限制 | 含义 | 风险 |
|:----|:----|:----|
| 非可重入 | 不能从并行区内再发起嵌套并行 | 没有编译期检查，静默出错 |
| 默认线程数 | 每物理核一个 | 超订场景需手动调整 |
| 无同轮 A/B 数据 | 动机在原理上成立，但没有实测归档 | 这是本文最大的空缺 |
文章最后一句也说了："绩效上，我们没有归档'自研池 vs OpenMP'的同轮交错 A/B 数据……本文因此不给出任何加速比。" 这种诚实在工程文章里不多见。
---
和你之前的关注点交叉
你之前关注"规则的触发精度比数量更能影响 AI 输出质量"，而这篇说的是"并行调度的粒度决定推理引擎的实际吞吐"——两者本质上都是在系统设计中找到正确的粒度边界。OpenMP 的 fork/join 开销像一条太粗的规则，覆盖不了 FHE 这种细粒度并行的场景；自研池相当于把规则写细了。
另外，这篇和上一轮 Pulse 监控方案的设计哲学其实相通——都是砍掉通用层的冗余，用自研方案换取对特定场景的精确适配。只不过 Pulse 砍的是监控栈的部署依赖，这里砍的是 OpenMP 的线程唤醒税。
0 评论